Proposal: paren-free function calls and definitions

Brendan Eich brendan at mozilla.com
Mon Jun 20 11:44:49 PDT 2011


On Jun 20, 2011, at 11:19 AM, Claus Reinke wrote:

>>> No ambiguity intended - function bodies extend as far to the right
>>> as possible (see Note 1).
>> 
>> It doesn't matter what you intend. There are multiple ways to parse,
>> at many precedence levels, due to the precedence inversion. The
>> grammar is ambiguous.
> 
> Nitpick: I used ambiguity resolution mechanisms (notes in the text
> and peg non-backtracking choice in the implementation) that are
> not suitable for the ES spec.

I know, you've been clear about this. But the problem remains how ever to specify something like what you want in the standard, unless you do move the expression-body form to AssignmentExpression level.


>> ECMA-262 needs an unambiguous formal grammar in which
>> there is always only one way to parse. That grammar should
>> be validated mechanically -- no Notes apply, just LR(1).
> 
> Btw, does the spec state that the grammar is supposed to be
> LR(1)? I missed that detail when reading, only got it from this list.

I'm not sure why the spec does not contain the string "LR(1)" (according to Adobe Reader). Waldemar may know the history.


> While we're on the topic: isn't the ASI spec a big counter-example
> to this recommended practice? I've yet to see an ASI-supporting
> Javascript parser that doesn't try to translate the negative-match
> ASI spec ("if an offending token is not allowed by any production")
> into a constructive description ("if a semicolon would help here").

ASI is an error correction algorithm, plus the restricted productions. Yes, it has the negative match hazard. Big time. The point is: no more; ASI, we are stuck with, but do not add more like it.

/be


More information about the es-discuss mailing list