Expression Closures in JS 1.8.1

Brendan Eich brendan at mozilla.com
Mon Aug 3 10:09:48 PDT 2009


On Aug 3, 2009, at 9:42 AM, Michael Haufe wrote:

> The documentation is a little sparse on the Mozilla page: https://developer.mozilla.org/en/New_in_JavaScript_1.8 
> #Expression_closures
> and the wiki doesn't have a page created for it yet on the subject,  
> so I have a generic question on the grammar:
>
> Is their an ambiguity that prevents the following from being a valid  
> syntax?
>
> function foo();
>
> being the equivalent of
>
> function foo(){ return };

No, that's future proofing to allow for new meaning to be given to  
that new syntactic form. We require an expression, if only void 0 or  
undefined or 42:

function foo() void 0;

But for such a useless function, the shortest and best form is still:

function foo() {}

You don't need an explicit return with implicit undefined return  
value, if you don't need an explicit return value.


> Also, how is it that the following is not misinterpreted to  
> "function() { return false, true; }"?
>
> addEventListener("click", function() false, true)

The production is essentially

ExpressionClosure:
      function Identifier[opt] ( FormalParameterList[opt] )  
AssignmentExpression

and an AssignmentExpression cannot produce an unparenthesized comma  
Expression.

The JS1.8.1 expression closure grammar as implemented is buggy, as  
noted here:

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007883.html

Bottom-up grammar checking is part of the ECMA-262 standardization  
process (for Harmony by recent agreement, and it was for ES3; ES5 has  
no significant new syntax to check). The JS1.8.1 expression closure  
syntax will have to change, in order for it to be standardized.

/be


More information about the es-discuss mailing list