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

Brendan Eich brendan at
Fri May 20 07:43:51 PDT 2011

On May 20, 2011, at 7:07 AM, Claus Reinke wrote:

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

Because the LabelledStatement changes in restrict labels to prefix only LabelUsingStatements. I was addressing the backward incompatibility here: ES1-5 allow useless labels. You seemed to think that incompatibility was important enough to require new label syntax, but I argued that it is (a) not important; (b) caught by early error during migration.

> 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

Only by arbitrarily long lookahead, alas.

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

I'm still working on the proposal. Cover grammar doesn't quite do the trick, in the formalism we want. We don't want always to parse a MaybeBlockOrObjectLiteral and handle the difference once we see a label on a label-using-statement, or else a property name labeling an expression, by semantics in the prose. We need a proper grammar for blocks and object literals.

> - both LabelledStatement and PropertyAssignment permit
>   IdentifierName followed by ':', followed by something,

(LabelledStatement begins with Identifier, not IdentifierName. That only complicates things a bit more ;-), but seems worth pointing out.)

>   so disambiguation has to be in the something following
>   the ':', where overlaps like ExpressionStatement further
>   extend the ambiguity

No, ExpressionStatement cannot be a LabelUsingStatement.

To be concrete, the problem is {L1:{L2:{L3:{L4:{....LN: XYZZY .... where XYZZY is neither of the form Identifier : nor {. Ignoring syntax errors, if XYZZY is a reserved identifier, it must begin a LabelUsingStatement (or syntax error, in the proposal). Otherwise, it must begin an InitialValue giving LN's property value.

> My suggestion was simply to remove IdentifierName from
> one of the two, by prefixing labels, thereby moving the
> disambiguation point forward.

I understood your proposal but perhaps I misunderstood that part of the motivation seemed to be stray-label backward compatibility.

> By my estimate, that should
> reduce the range of lookahead, the size of cover grammars,
> and the need for restricted grammars.

Indeed, just not sure anyone is up for an incompatible new label syntax. It may be the least evil, though!

Labels are not much used intentionally in JS (for break and continue to label, which came in only in ES3).

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

Now I don't see any solution in adding new label syntax. Having to parse the old one leaves us with the ambiguity. What am I missing?

> But it would be possible to disambiguate
> conflicts between property names and block labels in
> favour of property names.

Being able to disambiguate != having an unambiguous grammar, unfortunately. Unless Harmony bans old label syntax, this doesn't help us write a spec-grammar.

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

Do you mean prohibited or deprecated? Usually deprecation means a warning, obsolescence or prohibition means removal.

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

Truly, I'm living on the edge here. More work to do, but this is a non-trivial syntactic change. Paren-free is a walk in the park. Still may be worth it, but more work needed. Thanks for the comments.

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

That is simpler, but I believe I have seen code like this:

  L: { S1; S2; S3; } where S2 is a label-using statement, specifically a break from the outer block, a sugared downward goto that skips S3.

Probably only in tests for labels!

Yes, the strawman proposes to break such code. So requiring {; or similar would be a simpler change and non-breaking in the sense that one can rescue such code so it works in Harmony as it used to, by adding one character. Good idea!

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

Yes, but then why have arrows (at least why mandate them) at all?

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

More information about the es-discuss mailing list