Re: Strings and Method Names Mark S. Miller (markm@erights.org)
Wed, 11 Nov 1998 14:49:12 -0800

At 10:16 AM 10/22/98 , Bill Frantz wrote:
>...
>I think there are at least 3 kinds of languages in the world. They are:
>
>(1) Write only: HP calculator language for example. ...
>
>(2) Write and revise: C, Algol and most such are examples. ...
>
>(3) Algorithm publication: MIX?, C with buffer overruns? ...
>...
>Where in this spectrum does E stand.

[a] E intends to support all three styles of use, in order from highest to lowest priority: #2, #3, #1

Even though it's last, E takes #1 quite seriously. Not that we seek to enable programs to be hard to read, but that, in order to be a command language, we have to support well the short program that only gets executed once.

There are two interpretations of #2: "revise" as in rapid prototyping, and "revise" as in serious large-scale software engineering and maintenance. E should support both as well as Smalltalk & Self. But as with Smalltalk & Self, E sacrifices two needs of large-scale efforts: static type checking and close-to-the-machine implementation. The first helps catch errors early, and the second enables the programmer to better predict a program's performance (as opposed to enabling a program to perform better).

Your distinction between #2 and #3 is dead on. E code and E pseudo code properly differ in three ways

  1. whether *appropriate* exceptions are thrown,
  2. whether exception recovery is attempted,
  3. concessions for performance.

Using more words,

  1. E pseudo code must compute the correct answer on the success case, and must fail exactly when it should fail, but may fail by throwing something silly.
  2. E pseudo code may be safely fail-stop when actual E code would have correctly recovered from exception or attack. Under no circumstances should E pseudo code (or E code!) lose consistency.
  3. E pseudo code may suffer any finite slowdown compared to acceptable real code.

Such E pseudo code is a fine executable specification for real E code.

>There is one case in the E runtime where we iterate over a changing
>collection. Consider the connection building operation. The basic call
>is:
>
> getConnection(String vatID, String[] plsList);
>
>... If the address is a VLS, the
>address(es) it returns will be added to the set and tried next. ...
>
>This process would be a lot more difficult with static snapshots.

[+] Don't snapshot in this case.
The "snapshot" semantics is only meant to explain E's for-loop, and the table class's Enumeration-yielding operations -- they all iterate over a snapshot of the collection made when either the for-loop was started or the Enumeration was requested. Since the above doesn't use either for its iteration, there's no conflict.