May 24-26 rough meeting notes
waldemar at google.com
Fri May 27 12:27:34 PDT 2011
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.
More information about the es-discuss