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

Kam Kasravi kamkasravi at yahoo.com
Fri May 20 11:26:16 PDT 2011


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 <brendan at mozilla.com>
To: Claus Reinke <claus.reinke at talk21.com>
Cc: es-discuss <es-discuss at mozilla.org>
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
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110520/6999b351/attachment-0001.html>


More information about the es-discuss mailing list