[E-Lang] Syntax Reductions: Consensus so far

[zooko@zooko.com]

Some quick comments.


I approve of all of the following changes.  (I'm just ignoring changes that 
I dislike, don't have a preference about, or don't understand.)

 MarkM wrote:
>
> >1) VBish syntax is gone.  Not even in the pocket or deprecated.  No switch 
> >2) The dot syntax for JavaBeans properties (get/set methods) goes in the 
> >3) The "define" synonym for "def" is deprecated.  As a keyword, once it is 
> >4) I find the "command-line completion argument" for parens compelling.  
> >5) I don't think command line completion can provide the Java-like 
> >6) The "delegate" shorthand for a matcher goes in the pocket.
> Nope.  I found MarcS's counter-argument compelling.  "delegate" is fully 



Now here's the dreaded (by me) expression-language issue:

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


I'm hoping that we can get something better out of #10 and #11 without having
to touch #9.  Even if not, I'm pretty sure that by examining the issues we can
learn useful things E designers, E programmers, or even "E++" designers (ooh --
I'm sort of sorry I just made up that name...).  I have a couple of essays in
the outgoing pipeline about that, and I'll be working on them today.  


Regards,

Zooko