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, but add labels starting with, say ':'
(just to pick a prefix).
Then, new syntax, such as arrow functions, could default to
assuming objects when they see '{ identifier: .. }', while
programmers could write '{ :identifier: .. }' if they want a block
starting with a label instead. Disambiguation would not have
to look far ahead and there would be less grammar duplication,
which might translate into reduced potential for things going
wrong. Empty block values are far from useless, but should be
possible as '->{;}' or '->{:empty:;}'.
I would still prefer combining the infix arrow with a prefix marker,
to avoid ambiguities (for human readers and non-human parsers),
some of which might only arise in combinations with future features.
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
