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

Brendan Eich brendan at mozilla.com
Sun May 22 02:35:16 PDT 2011


On May 22, 2011, at 2:01 AM, Claus Reinke wrote:

>> Because the LabelledStatement changes in http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax 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.
> 
> Ok, so you want to restrict label use. But syntax alone cannot
> guarantee that a given label prefix is ever actually used, it can
> only rule out alternatives that cannot possibly use the label.

The purpose is not to restrict labels to prefix statements that might possibly refer to them, for that sake. Misplaced labels are harmless.

The purpose is to parse block and object initialiser in the same context, unambiguously.


> Without changes, any grammar that has ObjectLiteral and
> Block as alternatives is ambiguous:
> 
>   ObjectLiteral | Block    // ambiguous

Not for a GLR parser with the proposed label restriction.


> The problem I have with that is that I need to think far
> ahead to figure out whether I'm writing an ObjectLiteral
> or a RestrictedBlock and that I need to be aware of whether the Statement I'm writing follows a label or not.

Not a practical problem. Labels are rare anywhere, even more rare immediately after a {, and of course useless if labeling an expression-statement.


> So I'm looking for a way to introduce a committed choice
> based on limited lookahead instead. It seems that the
> IdentifierName (PropertyName) vs Identifier (label) case
> is the one that can lead to long lookaheads, so breaking
> that seems a step forward. Hence the new-style labels.

Please check the rehashing, you said this last time. I understand new style labels as a disambiguating change, but we would have to prohibit old-style labels, and that's not wanted if we can simply use GLR or better (you mentioned PEG).

You seem to acknowledge that a more powerful parser could handle the disambiguation, so why change the worry to one about "I need to think far ahead [when] writing"? That is a shift of argument, and the new argument is not credible: JS authors do not write labels much, and when they write object initialisers, *under the proposal* they aren't writing labels inside, no way, no how.

If we go this route of allowing block or object initialiser, then the right answer is not to mangle label syntax in Harmony and put some work on JS programmers migrating code into Harmony.

The right answer is for spec-writers (the few, the brave, blah blah) to step up with GLR or better. Provided there's a sound top-down algorithm that implementors can swallow.

/be


More information about the es-discuss mailing list