Proposed Resolutions

[Marc Stiegler]

I really like replacing load: with import:. I'm in the middle of building a
new E tool with lots of java imported classes, and this change will give me
one less places to have to translate languages :-)

Uh, if you load:/import: the same class a second time, does E actually load
it again, or does E realize that the class is already loaded?

--marcs

-----Original Message-----
From: Mark S. Miller <markm@caplet.com>
To: E Language Discussions <e-lang@eros.cis.upenn.edu>
Date: Thursday, November 12, 1998 5:16 PM
Subject: Proposed Resolutions


>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?
>
>
>