Proposal: paren-free function calls and definitions

Claus Reinke claus.reinke at
Mon Jun 20 11:19:31 PDT 2011

>> 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.

> Another approach, used in 
> -- 
> put the new function expression form at AssignmentExpression
> level in the grammar, do not make it a MemberExpression. This
> does not invert precedence.

Thanks - I can't believe I missed this! Obvious, in hindsight: low
priority infix ops should go at the appropriate level in ES' explicitly
unfolded priority tower. I guess I was thinking of establishing an
implicit set of parens, hence different priority level..

Anyway, I will rewrite proposal and prototype, after having
another look and think.

> 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.

> Otherwise as Waldemar has pointed out on this list several times,
> you can get into trouble with "negative match" rules as the
> language evolves: you add something that disambiguates
> differently and changes the meaning of existing code -- which
> means you cannot add that something. It can be very hard to
> see the effects of a change; the problem is not local to a production
> or set of productions.

Yes, I tend to make the fixed lookahead explicit, so that ordered
choice makes no difference (positive guards instead of negative
match; also good for efficiency and parse error messages). Don't
know why I fell into the rely-on-peg trap here.

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").

Or a proof that these in-grammar renderings are equivalent to
the ASI spec (I much prefer the positive, in-grammar rendering,
but it does not follow the spec text).

Thanks for the constructive comments,


More information about the es-discuss mailing list