[E-Lang] get, set, and dot

[Marc Stiegler]

> There are so many shorthands for defining an object. In my use of E,
> I've silently dropped some of them. This use is one I've dropped. If I
> were making an object with a single method that needed a name other
> than the default "run", I would have explicitly coded:
>
> def notary {
> to setForInspection(obj) { currentNotarizedObject := obj }
> }
>
> When I follow this practice, I always expect there to be a single noun
> after a "def". I was initially very confused to see 2 nouns after the
> def. I actually had to go to the erights.org site to check the grammar
> before I remembered what was going on. Even now that I've regained my
> lost knowledge, I am worried, in fact, almost certain, that there are
> other E shorthands lurking in the darkness. I am not confident that I
> will be able to immediately parse any piece of E code that I come
> across.
>
> It is also noteworthy that this particular "shorthand" saved a grand
> total of 4 characters. That ought to put off an RSI by another couple
> picoseconds.

You have persuaded me that the usage of the 1-method shorthand for things
like the notary is frivolous.  You have also put the last straw on the back
of a camel in E in a Walnut; I have been thinking about rewriting the
section that describes Makers so that it introduces the expanded notation
first:

def blahMaker {
    to new { ...
    }
}

And then introduces the shorthand version second:

def blahMaker new { ...
}

This discussion has persuaded me to go ahead with this rewrite.

While I agree with the usage convention of using the 1-method shortcut only
for Makers, I still think keeping the shortcut in the language is a good
idea. The important thing it saves in Makers is a level of indentation, and
because E creates levels of indentation at a very high rate (particularly in
distributed programming where you may need nested when-catch clauses), this
is a scarce resource.

You mentioned a concern about overlapping syntactic sugars, how many others
are out there in the darkness, waiting to surprise you? There are 4
syntactic sugars that leave me feeling like they can lead to surprises: the
function() shortcut syntax, the Maker shortcut syntax, the dot notation, and
the (shudder!) Visual Basic syntax. The first two shortcuts have reasonably
clear utility. The third is under discussion for elimination. Fortunately,
to my knowledge no one has ever used the VB syntax, and by excluding it from
E in a Walnut, I hope to keep it that way  :-) We can tell all the VB people
that we're really copying the syntactic style of C# , not Java :-)

--marcs