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,
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
- your proposal suggests parsing a cover grammar until
disambiguation, plus restrictions to LabelledStatement
- both LabelledStatement and PropertyAssignment permit
IdentifierName followed by ':', followed by something,
so disambiguation has to be in the something following
the ':', where overlaps like ExpressionStatement further
extend the ambiguity
My suggestion was simply to remove IdentifierName from
one of the two, by prefixing labels, thereby moving the
disambiguation point forward. By my estimate, that should
reduce the range of lookahead, the size of cover grammars,
and the need for restricted grammars.
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. But it would be possible to disambiguate
conflicts between property names and block labels in
favour of property names.
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.
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.
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.
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?
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
