Proposal: paren-free function calls and definitions

Brendan Eich brendan at
Mon Jun 20 08:31:07 PDT 2011

On Jun 20, 2011, at 1:49 AM, Claus Reinke wrote:

>> This is not just awkward, of course -- the grammar you propose is
>> ambiguous.
> 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.

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

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.

This is the future-hostility problem of ambiguous grammars.

>> The precedence inversion means there are two ways to parse
>> z = a + function (b) => b ? c : d;
>> ..
>> z = a + (function (b) => (b ? c : d));
> This is the intended parse, and also the one used by the prototype
> (you can change 'opts ="pu"' to 'opts = "pua"' to get the ast). To
> get the other parse, one would need explicit parens.

Yes, I know. BTW, SpiderMonkey and Rhino (I believe) implement "expression closures", the same thing you're proposing but without the => (it's not necessary). They have the same ambiguity problem.

>> function f(x) => x;
>> z = a + function (b) => b ? f : x++(1);
>> parses awkwardly, as ( z = ( a + ( function (b) => ( b ? f : ( x ++ ) ) ) (1) ) ).
> I'm not following yet - what parse would you like to see instead
> of this one? If you wanted the function body to end earlier, you
> can get that by adding parens, right?

The awkwardness here is the lack of mandatory parentheses around the entire function expression, ending before the application via (1).

I've factored the grammar differently in to avoid precedence inversion, and I've done some preliminary validation work to make sure there are no ambiguities. See the InitialValue nonterminal and the new assignment statement forms.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list