Strings and Method Names

[Bill Frantz]

At 02:04 AM 10/22/98 -0700, Ka-Ping Yee wrote:
>
>> I decided to break with Java conventions and allow both literal strings and
>> quasi-strings to span multiple lines.  I liked this in Tcl.
>
>Interesting.  Potentially dangerous, as it can sometimes yield
>far-flung syntax errors -- but then i guess the same is true of
>unmatched parentheses or braces.  By the way, i hope the E
>interpreter is smart enough to look for more input when you
>leave a paren or bracket unclosed on a line (Python does this).
>Wayne's STIPPLE language also had the neat idea of expecting a
>continuation when an operator was found dangling at the end of
>a line.  These two things together might almost entirely obviate
>the need for icky \-continuations.

I think there are at least 3 kinds of languages in the world.  They are:

(1) Write only: HP calculator language for example.  The language is not
designed to be easy to read, but is designed so you can do fairly complex
things as a stream of consciousness, write once, exorcise.  They tend to
avoid matching delimiters because they are hard to keep track of in write
only mode.

(2) Write and revise:  C, Algol and most such are examples.  They are
designed to allow a programmer familiar with the code to read the details
and revise the program to behave differently.  However, the details, e.g.
error handling, tend to overwhelm the algorithm and make it hard for a
first time reader.

(3) Algorithm publication:  MIX?, C with buffer overruns?  These language
are designed to convey an algorithm from one human to another.  They tend
to ignore issues such as error handling which are not germane to the basic
algorithm.

In case 2 and 3, the human reader tends to use the 2 dimensional structure
of the "printed page" to determine the basic tree structure of the language
while the computer is matching delimiters (such as open/close brace).  Many
bugs hide in this difference of perception.  As a result, editors have
learned about syntax and have "balance" operations, and syntax coloring.

Where in this spectrum does E stand.


>> I hadn't thought of that.  Currently all iteration operations implicitly
>> iterate over a snapshot of the collection, and the implementation of
>> mappings and tables knows not to actually make a copy unless needed
>> (copy-on-write).
>
>That sounds like a pretty good answer to me, too.  It seems like
>a reasonable assumption, since the only thing you would want to
>do if you did have a mutable sequence is get a snapshot anyway --
>forcing the author to say so seems a little pedantic if there isn't
>really any other possibility.

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);

The plsList is parsed into a DynamicCollection which is an ordered set
(i.e. an element appears only once) which can be added to while it is being
enumerated.  The addition occurs through the Enumeration, so that the next
element returned by that Enumeration is the one most recently added.

The way the whole thing is designed to work is that the plsList is a list
of Vat (nee Process) Location Services (VLS) to search for the vatID.
(When resuming after suspend, the first element will be the IP:port where
the vat was found before the suspend.)  The connection protocol steps thru
the enumeration trying each address in turn.  If the address is a VLS, the
address(es) it returns will be added to the set and tried next.  No address
will be tried more than once (based on the string value of the address, not
the resolved IP:port).

This process would be a lot more difficult with static snapshots.