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

Claus Reinke claus.reinke at talk21.com
Mon May 9 09:27:25 PDT 2011


>>   function bodies extend as far as possible **
> 
> I see.  So, a function body would be just like an if-block or loop
> body.  One full statement, or a block.  There is precedent for that in
> the rest of the language.  So, then, this case:
> 
> x = function () y; z
> 
> would be:
> 
> x = function () { return y }; z

Is that a trick question?-) Your interpretation is one plausible
extrapolation of this maximal munch rule to cover javascript's 
function body blocks but it might not be the only one. 

In particular, you have chosen to combine maximal munch for
expressions with minimal munch for statement lists, while one 
might want to apply maximal munch to both expressions and 
statement lists (if the braces around function bodies were to
be made optional). One would need to look at the design options 
in detail before making a decision. 

Javascript's handling of the statement/expression divide could
do with some work, e.g., we want to be able to use functions to 
build control abstractions; but javascript has chosen to make
assignments into expressions, and expressions into statements;
javascript statements/blocks are currently not expressions, and
if we tried to correct that, we'd run into the question of what to
do with assignments (pass them around or execute them).

In the meantime, the only way to abstract over blocks is to
wrap them in functions, so if we wanted to emulate conditional
statements with conditional expressions (or other use cases 
where we want to work with blocks as values), we'd write 
something like this:

(condition ? function() { ..blockA.. } : function() { ..blockB.. })();

The use of function wrappers to delay execution is yet another
motivation for concise (but readable and unambiguous) function 
syntax.

Claus
 


More information about the es-discuss mailing list