Proposed Resolutions

[Mark S. Miller]

Last night Ping & I had an extraordinarily productive f2f meeting to try to
resolve some outstanding E design issues.  The big one is sameness (aka,
equality), which in turn is intimately related to defining new pass-by-copy
objects, how object graphs print so they can be read back in, and handling
cyclic data structures.  Since this is the big one, I'll explain it all
after I've explained the other issues.  (Yes, I know this hardly makes me a
master of suspense.)

The proposals have evolved a bit in my head since Ping & I met.  Since
Ping's on-line, I'll just present my current thinking -- so credit us both
but only blame stupidities on me.

			Comments on URI Expressions
		http://www.erights.org/doc/elang/uri-exprs.html

* I HAD A TERRIBLE BRAINO: I had read
http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt as excluding commas from
legal URI expressions.  Wrong.  Like parens, commas are perfectly legal.
Therefore, E's URI Literal Expressions must be terminated with whitespace,
newline, or end-of-file.  However, just as with unbalanced close parens,
there's an accident proneness issue:

Even though an rfc-legal URI may terminate with an unbalanced close paren,
should this case occur, it's more likely the programmer forgot to put in a
space before an E close paren, so such a case is a syntax exception.
Similarly, we propose to say that a URI Literal Expression that *ends with*
a comma is a syntax exception, but internal commas are fine.  As always, if
you want to express a URI that falls outside these rules, use a URI Unary
Expression.

* Rename "load:" to "import:", as its purpose corresponds to the familiar
(especially to Javoids) notion of module/class/package importing.

* "mailto:" is withdrawn until someone contributes a "mailto:" protocol
handler with a sensible behavior.  Ideally, "mailto:frantz@communities.com"
would evaluate to Bill himself, but this might be hard to implement.

* URI Literal Expression bodies could have at most one '#'.  If it has one,
then a two argument lookup is called on the protocol handler -- the first
being the uri body string before the '#', the second being the string after
the '#' (the fragment).  URI protocol handlers (like "file:") that don't
want to accept fragments can simply not implement the two-arg lookup.


			Comments on Text File I/O
		http://www.erights.org/doc/elang/text-file-io.html

* On java.io.File objects, "asString" is easily confused with "toString"
though they have completely different meanings.  Change File's "asString"
to "getText".  This returns a String containing the UTF-8 decoding of the
file, with platform line-ends normalized to '\n's.  It internally takes
care of opening a stream, reading, and closing the stream.

* Provide java.io.File objects with corresponding "setText(string)" and
"appendText(string)" messages.  It would internally take care of opening,
writing, and closing a stream.

* Perl and Python's readLine(), and Perl and E's file iteration behavior,
all yield lines with a '\n' on the end.  (Is this correct??)  However,
Java's readLine() function returns a line of text with newline removed.
Since part of the point of E is to rapidly prototype ideas which get turned
into Java, I can't change this behavior without changing the name.  The two
plausible choices: 1) leave it alone, or 2) withdraw "readLine" from E, and
provide a "readln" that preserves the newline.


			Maker Naming Convention

* In the previous competition, the winning naming convention is

	define PointMaker new(x, y) {
	    define point {
	        to getX {x}
	        to getY {y}
	    }
	}

Since this is both understandable and pleasant, and plays best with Java.
Java constructors are seen by E as "new" messages.  The E object whose
messages correspond to the constructors and static methods in a Java class
declaration will also be called an E maker, as opposed to a java.lang.Class
object, which corresponds to that still mysterious creature, an E type.

The made object is also given a descriptive name, as opposed to saying
"self".  "self" and "super" are, by convention, reserved for
inheritance-like delegation patterns.


		Naming Collections, collecting names

* Returning to our standard matrix, here's a new proposal to shoot at

	               Map    |   List
	           +----------+-----------
	immutable  | ImmuMap  | ImmuList
	           |          |
	 mutable   |  MuMap   |  MuList 
	           |          |

Other possible future columns include Slot and Scope.  Other possible
future rows include read-only.  Biggest disadvantage: try saying "ImmuMap"
out loud.

What do y'all think?