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

Claus Reinke claus.reinke at talk21.com
Thu May 19 01:46:49 PDT 2011


> 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
 


More information about the es-discuss mailing list