On May 26, 2011, at 4:22 PM, Waldemar wrote:
> Arrow Function/Block:
> function f() {
> a.forEach({| | return 3});
> }
> The return will return out of f. Note also that the implementation of
> forEach could have a try-finally statement that catches and revokes the
> return. This kind of cross-function return catching is new.
And some on TC39 <3 this "Tennent sequel" feature, to quote dherman. Others
cited the new as potentially too much for average users to grok. No one hated
it overtly.
> The cage around block lambda is too tight.
> Luke: Concern about call syntax strangeness. This kind of syntax only works
> if it's designed holistically.
> Debate about completion value leaks.
> Waldemar: Use of | conflicts with common use of trademarks.
> Alex: Objects to new "little pieces of cleverness". Too many things to teach
> to people.
> Not advanced to Harmony.
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).
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.
User testing would be most helpful in providing negative results, for usability
or any other bug (parsing complexity, etc.). To get arrow function syntax into
Harmony we still need a non-LR(1) approach, because the LR(1) way parses too
broad (or even the wrong) a cover grammar: Expression as the arrow formal
parameter list.
So more to do for arrows, but that seems like the winning direction, with block
lambdas a close second.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
