On 05/27/11 02:01, Brendan Eich wrote:
More was said here that is good feedback for Harmony, no matter what gets into
ES.next.
We talked about how shorter function syntax is hard to do well and standardize.
The traps include:
* do too little by ignoring 'return', jumping a syntax shark and claiming a
sigil wanted otherwise (# as shorthand for 'function'),
* create completion value leak hazards (# + completion reform as in
http://brendaneich.com/2011/01/harmony-of-my-dreams/#functions),
* take on new grammar formalism challenges
(http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax),
* take on other costs (and benefits) by adding semantic value
(http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival).
We didn't get our act together in time to get shorter function syntax into
ES.next at this meeting, which I regard as a personal failure in part. But we
will keep trying. It's important, as Alex Russell argued.
I took a straw poll:
Block lambda revival with feedback issues fixed, in favor (whether 2nd or 1st
choice): 6 hands up.
Arrow function syntax, with grammar formalism addressed: 8 hands up.
There can be only one (of the above): 9 hands up.
Therefore I'll work on the
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax strawman
(I'll update
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival based on
feedback as well, to keep it up to date).
What that poll didn't indicate is the soundness of the reasons for choosing one or the other.
"I slightly prefer A to B" is different from "if we choose B then we'll need to
spend months coming up with a new formalism for the spec."
Peter Hallam kindly offered to help come up with a new grammar formalism for the spec
that can pass the "Waldemar test" (if that is possible; not as hard as the
Turing test). IIRC Peter said he was (had, would) adding arrow support per the strawman
to Traceur (http://code.google.com/p/traceur-compiler/). We talked about Narcissus
support too, to get more user testing.
If we need to come up with a new formalism, that's a very powerful signal that there's
something seriously flawed in the design. Even if it happens to work now, it will
produce surprises down the road as we try to extend the expression or parameter grammar.
The places where the grammar is not LR(1) up in C++ are some of the most frustrating and
surprising ones for users to deal with, and C++ does not even have the feedback from the
parser to the lexer. Perl does and its grammar is both ambiguous and undecidable as a
result. Note that implementations of Perl exist, which in this case simply means that
the documented Perl "spec" is not sound or faithful -- all implementations are
in fact taking shortcuts not reflected in the spec.
Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
