arrow syntax unnecessary and the idea that "function" is too long

Brendan Eich brendan at
Fri May 20 11:06:16 PDT 2011

On May 20, 2011, at 7:07 AM, Claus Reinke wrote:

>> we should focus on the harder nut to crack (the leading parenthesized parameter list).
> Isn't that an example of issues that would not exist if
> arrow functions had a prefix marker?

It is a deeper issue. ECMA-262 currently covers left-hand side of assignment with LeftHandSideExpression, but that produces 42, not a valid LHS. Semantic checks and mandatory errors in spec prose make up for the lack of a precise grammar.

ES5, Clause 16, has

"Attempts to call PutValue on any value for which an early determination can be made that the value is not a Reference (for example, executing the assignment statement 3=4)."

Destructuring assignment -- not the binding forms, e.g. let {x, y} = obj; but just assignment expressions, {x, y} = obj -- takes advantage of this cover grammar approach, but it will require semantic checks. And as Waldemar points out, this constrains RHS "structuring" via object and array initialisers to have the same syntax (unless we add more semantic post-grammar restrictions there too!) as the LHS destructuring patterns.

This may be a bad constraint. Type guards don't seem like they'll be only LHS or RHS, indeed the :: choice for guard prefix was based on easy composing of guards after property names in object initialisers. But some future extension might want LHS and RHS to diverge.

Arrow functions really do want a different ArrorFormalParameters sub-grammar from ( Expression ) where Expression is of course a comma-expression.

So I'm investigating GLR parsing. It can handle all of these cases without ambiguity. It does not require implementatoins to have forking parsers, but it is an attractive spec tool. More on this in a bit.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list