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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
