Proposal: paren-free function calls and definitions
claus.reinke at talk21.com
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
> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax --
> 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
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