Fw: [E-Lang] get, set, and dot

Marc Stiegler marcs@skyhunter.com
Mon, 26 Feb 2001 12:37:08 -0700


(lost mailed, resent)
----- Original Message -----
From: Marc Stiegler <marcs@skyhunter.com>
To: Tyler Close <tclose@oilspace.com>
Cc: E Language Discussions <e-lang@eros.cis.upenn.edu>
Sent: Monday, February 26, 2001 8:46 AM
Subject: Re: [E-Lang] get, set, and dot


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