[E-Lang] Syntax Reductions: Consensus so far

[Mark S. Miller]

Having read and, I think, absorbed all the syntax arguments to date, 
here's my sense of where we have and have not achieved consensus.  And 
largely (not fully) in synch with this, here's my new proposal about what to 
do to the grammar as of the next release.  After this message, I hope to 
have one more brief round of argument before settling on what's in the next 
release.  Further argument is always welcome, but releases must take 
snapshots in time.

But first, of course, yet more terminology.  Besides "in the pocket" and 
"deprecated"...

* A "pocket warning" means that it is still in the official grammar as of 
that release, and is still accepted by the parser without turning on any 
switches.  However, the "pocket warning" is notice that this feature may 
disappear from the official language in an upcoming release, whether to go 
in the pocket, be deprecated, or simply disappear.

* As per Dean's recent email and my reply, "experimental" means it's in the 
pocket for now because it's semantics aren't yet settled.  But once we've 
figured it out, we expect to revive it and make it part of official E.


At 09:35 PM Thursday 3/1/01, Mark S. Miller wrote:
[Note that I've edited my own quoted text below in order to adopt a more 
explicit BNF notation.  --MarkM]

>1) VBish syntax is gone.  Not even in the pocket or deprecated.  No switch 
>turns it back on.

Like Generalissimo Francisco Franco, this one is still dead.


>2) The dot syntax for JavaBeans properties (get/set methods) goes in the 
>pocket.

Yup.


>3) The "define" synonym for "def" is deprecated.  As a keyword, once it is 
>no longer even deprecated, it will move to the reserved keywords list.

Yup.


>4) I find the "command-line completion argument" for parens compelling.  
>Therefore, the no-paren invocation goes in the pocket, both on invocation 
>and on definition.  We should start thinking about concrete command line 
>completion rules, and a concrete algorithm for implementing these rules.  
>But I don't think there's any hurry to actually implement these.

Yup.


>5) I don't think command line completion can provide the Java-like 
>invocation dot.  Therefore, and because #2 remains in the pocket, and also
>because the invocation dot simply makes my eyeballs hurt, E continues to use 
>whitespace rather than dot for invocation.  No change on this one.

Yup.  No consensus, but my decision is that whitespace invocation stays.


>6) The "delegate" shorthand for a matcher goes in the pocket.

Nope.  I found MarcS's counter-argument compelling.  "delegate" is fully 
revived without even a pocket warning.  Consider it here to stay.  But it's 
now restricted to the uses shown in #7a and #7f below.  Other uses are 
simply gone, not in the pocket or deprecated.


>7) Of the many shorthands for an object expression, the following remain in 
>the language:
>
>
>a) The explicit vTable with zero or more matchers:
>
>    "def" <name> "{" <method>* <matcher>* "}"

The <matcher> production is redefined to include only the "match" construct:

    <matcher> ::= "match" <pattern> "{" <expr> "}"

The "delegate" construct now gets its own separate <delegator> production:

    <delegator> ::= "delegate" "{" <expr> "}"

And the above object definition production becomes

     "def" <name> "{" <method>* <matcher>* <delegator>? "}"



>b) The function shorthand:
>
>    "def" <name> "(" <patterns> ")" <guard>? "{" <expr> "}"

Yup.  Stays.


>c) The thunk shorthand:
>
>    "_" "{" <expr> "}"

There seems to be consensus on having some lightweight way to express a 
no-argument value-returning thunk, but no consensus on "_" as the indicator. 
After mulling over Ping's suggestions, and despite my earlier attempted
counter-argument, I'm inclined to put this use of "_" in the pocket along 
with #7e below, and instead adopt Ping's suggested

    "thunk" "{" <expr> "}"

This would make "thunk" a keyword.  Since "thunk" in not currently reserved, 
this is not strictly an upwards compatible change.


>and the following go into the pocket:
>
>
>d) The single method object definition, eg,
>
>    "def" <name> <verb> "(" <patterns> ")" <guard>? "{" <expr> "}"

Pocket warning instead.  See #7g below.


>e) Anonymous object definition that leaves off the "def" while keeping the 
>function signature, eg,
>
>    "_" "(" <patterns> ")" <guard>? "{" <expr> "}"

Yup.  Stays in the pocket, to be joined by #7c as a single case (with a 
single switch).


>f) The plumbing expression[s] (it was always flagged as experimental anyway):
>
>    "def" <name> <matcher>
>    "def" <name> <delegator>

>But note that #7f (the plumbing expression) isn't a shorthand.  It's part 
>of Kernel-E.  #7f proposes to put this part of Kernel-E in the pocket.  

As per Dean's recent email, this becomes "experimental".  (In pocket with 
expectations of revival.)



>g) The class shorthand, for supporting inheritance:
>
>    "class" <name> "(" <patterns> ")" <guard>? "{" <expr> "}"
>
>If the dreaded political issue raises its ugly head, we can quickly pull 
>inheritance back out of the pocket.

Keeping in mind that consensus is different from unanimity or any other 
objective voting rule, I'd say there's consensus that we be able to continue 
to say, truthfully of course, that E has inheritance, but not yet consensus 
on what we mean when we say that.

Seemingly separate, but actually closely related, is issue #7d, the single 
method object definition.  We agree it must remain possible to introduce 
class-based programmers to E's capabilities and concurrency before really 
teaching them lambda-based object instantiation. Just like MarcS was able to 
repeat the old Maker/new pattern by rote, and keep a fading class-based 
model in his head while he was learning the rest of the language, he must be 
able to write Walnut so that new E programmers can do likewise.

The pocketing of both #7d and #7g *possibly* leaves Walnut, and therefore 
these new E programmers, with need to climb the lambda wall before they get 
to the walls we really care about.  I see three approaches:

* I say *possibly* above because the Maker pattern with "new" or "class" may 
actually be fine as a class-like construct for new Java programmers.  MarcS 
and I disagree on this, but we both agree that we're long ruined as able to 
judge.  Just as Zooko has provided us the useful perspective of a naive 
Python programmer, we may need a sacrificial Java programmer to resolve this 
matter.  Note that we also have very differing opinions and supporting 
statistics on the importance of Java compared to other OO languages.

* Leave #7d in, allowing the simple definition of Makers that respond to 
"new" instead of "run".  This leaves Walnut mostly undamaged I think.

* Leave #7g in, which provides us both painless "new"-based instantiation 
and real inheritance (by supporting a pattern static delegation).  Rewrite 
all the class-like example in Walnut to use "class" instead of #7d.  The 
downside is, E's "class" doesn't allow multiple constructors.  If we do 
this, I'd like Walnut to say the "class" construct is only training wheels, 
especially since I know MarcS can get this point across in a less pejorative 
way. ;)

Until we make progress on this, #7d and #7g are both only in pocket warning. 
Therefore, they both remain in official E for now.



>8) Kill (not pocket or deprecate) the "loop" syntaxes, and therefore the 
>Kernel-E loop construct.  Instead, put a primitive one-argument function 
>named "loop" in the universalScope, where this function takes a 
>zero-argument function (a thunk) as argument and just repeatedly invokes it 
>forever.  In order words, what would have been written:
>
>    loop { ... }
>
>would now be written
>
>    loop( _{ ... })
>
>The main reason for this isn't syntax reduction, but (as Danfuzz advocated 
>when he suggested it) to make automated analysis of Kernel-E easier.  Why?  
>Because now variables would only be newly instantiated [per] entry to a method 
>or a matcher.  Period.  [Therefore they can be allocated on entry.  Period.]  
>This should make it easier to write a simple 
>compiler, and no harder to write a high-ambition compiler.  (Though it does 
>make it harder to write a medium ambition compiler.)

Yup.  Gone.


New issues:

9) Having E no longer be an expression language.

Forget it.  Sorry.  I'm just not interested in revisiting this one.  See below.


10) Having function/methods go back to defaulting to ":any" rather than 
":void".

I might have something to say for it if I were willing to reconsider #9, which 
I'm not.  Given that E remains an expression language, all the issues from 
the original threads about why ":void" is the right default remain valid.  
Note: I've discussed this with Zooko on the phone, and I think we now 
jointly understand that this isn't equivalent to the type-checking-oriented 
issue he was raising.  Zooko, it would be great if you posted a summary of 
how you now see this issue.


11) Having an explicit "return" construct.  (Let's not yet worry whether 
it's spelled "^" or "return".)  

This issue has force from a familiarity point of view, but given my stubborn 
intransigence on #9, all the arguments against "^" in that earlier thread 
are still valid.


Seeing that #10 and #11 depend on #9, there are two possible reactions:

"See, if you'd just follow your Bartlerian pan-critical rationalist 
principles and at least listen to arguments, we could also make progress 
elsewhere in the language."

"If you follow your ... principles and started arguing #9, the floodgates 
would open and we'd be back at square one on designing a concrete language.  
There are another dozen issues we can't see standing in line behind #10 and 
#11.  Leave 'em there."

Needless to say, the second quote is the fear in my head.  As I said before, 
#9 is a fine thing to raise when we design E's successor.



Ok.  Fire away.  But's let's try to converge on something for the next 
release quickly.  I think the #7d/#7g pair is the hard one.



        Cheers,
        --MarkM