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

Claus Reinke claus.reinke at
Fri May 20 07:07:07 PDT 2011

>>> The top-down approach by default is to parse a cover grammar 
>>> until an unambiguous decision point is reached, then depending 
>>> on the decision, rewrite the AST (e.g., to make a labeled statement 
>>> in a block instead of an object initializer).
>> A somewhat less intrusive way to disambiguate blocks/objects
>> might be to separate labels from identifiers - keep the old labels
>> for backward compatibility,
> Why do we need the old useless (unusable, literally) labels for 
> backward compatibility?
> Yes, stray labels creep into JS. Typically you find javascript: at 
> the front of scripts. But finding and fixing these is a one time 
> migration step caught by an early error.

I don't understand how these comments relate to my suggestion,
so let me try to clarify what I was suggesting, and why:

- the grammars for block and objects share common prefixes,
    leading to ambiguities that can be resolved by lookahead

- your proposal suggests parsing a cover grammar until
    disambiguation, plus restrictions to LabelledStatement

- both LabelledStatement and PropertyAssignment permit
    IdentifierName followed by ':', followed by something,
    so disambiguation has to be in the something following
    the ':', where overlaps like ExpressionStatement further
    extend the ambiguity

My suggestion was simply to remove IdentifierName from
one of the two, by prefixing labels, thereby moving the
disambiguation point forward. By my estimate, that should
reduce the range of lookahead, the size of cover grammars,
and the need for restricted grammars.

I don't know what that has to do with stray labels, and it
is obviously not possible to remove the old label syntax
immediately. But it would be possible to disambiguate
conflicts between property names and block labels in
favour of property names.

>> but add labels starting with, say ':' (just to pick a prefix).
> We really don't want two label syntaxes, ..

Right. The old syntax could be deprecated (when opting in
for ES/next) - it also doesn't allow label parameters or
label variables.

> The block vs. object literal disambiguation part of the 
> proposal is at least as solid as the leading formal 
> parameter list, which parses as a comma expression 
> until you get to the arrow. Indeed TC39 may want the 
> label restriction and block vs. object literal part pulled 
> out -- we shall see.

I'm not trying to decide whether the proposal's version is 
solid, but it is a non-trivial change, and I've seen non-trivial
suggestions shot down because they were thought to be 
risky. The more options there are for dealing with the 
object literals vs blocks ambiguity, the better the chances 
for it actually happening. Also, special-casing labelled
statements increases the complexity of the grammar.

As a third, extreme option, one could disambiguate by
always preferring the object literal interpretation, and 
ask programmers to start blocks in otherwise ambiguous 
contexts with an empty statement ('{; ..}' cannot be an 
object literal). That would require the fewest changes, 
and perhaps it is all we need, but I'm not sure how 
well it would work in practice, with existing code.

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



More information about the es-discuss mailing list