Some references to parsers that do not share ambiguity problems due to limited
lookahead such as GLR and PEG parsers.
http://www.cs.nyu.edu/rgrimm/papers/pldi06.pdf
http://www.cs.rit.edu/~ats/projects/jsm/paper.xml
http://www.cs.ucla.edu/~awarth/papers/dls07.pdf
________________________________
From: Brendan Eich <[email protected]>
To: Claus Reinke <[email protected]>
Cc: es-discuss <[email protected]>
Sent: Friday, May 20, 2011 11:06 AM
Subject: Re: arrow syntax unnecessary and the idea that "function" is too long
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_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
