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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
