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

Brendan Eich brendan at
Thu May 19 09:13:10 PDT 2011

On May 19, 2011, at 1:46 AM, Claus Reinke wrote:

>> Ok, final and most delicate part of the mission here: allow (v) -> {k: v} and even -> {} to return objects, not make useless block statements.
> .. 
>> Thanks to Doug for pushing on this idea. I believe that it is sound (still to be formalized and tested mechanically) in a bottom-up parser.
>> 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.

> but add labels starting with, say ':'
> (just to pick a prefix).

We really don't want two label syntaxes, especially if there is no strong compatibility argument for stray labels, and they can be detected as early errors in Harmony.

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.

So I say: stray label compatibility is a non-issue and we should focus on the harder nut to crack (the leading parenthesized parameter list).


More information about the es-discuss mailing list