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