return when desugaring to closures

Dave Herman dherman at
Wed Oct 15 16:49:59 PDT 2008

I know you are well aware of the LetExpression form that was in proposed 
ES4 and has been implemented in Firefox since JS 1.7 -- why are you 
sounding like you've never heard of it?

In the grammar for proposed ES4, LetExpression was under 
PrimaryExpression. That's where I'm suggesting LambdaExpression might 
fit. IOW:

PrimaryExpression ::= ...
                    |  LetExpression
                    |  LambdaExpression

LetExpression ::= let ( LetBindingList ) CommaExpression
LambdaExpression ::= lambda FunctionSignature LambdaExpressionBody

> Look at how the ExpressionNoIn cases are handled in the existing 
> grammar.  They are necessary.  If you have an expression that contains a 
> statement that contains an expression that contains the keyword "in" 
> then you'll introduce a grammatical ambiguity into for-in statements.

Okay, sure. This is already a bizarre corner case of the grammar. So it 
means in that case you'd have to parenthesize the lambda expression. 
Let's look at what we're talking about here; you can't write something 
like this:

     for (x = lambda() foo in bar; ....)

I don't imagine this being all that common; how often do loop variables 
get bound to procedures? In fact, this is probably *more* likely to come 
up with let-expressions:

     for (x = let(tmp = f()) tmp in obj; ...)

In any case, parenthesization resolves the issue. A corner case, yes, 
but IMO this is just part of the wartiness of the for-in syntax, and not 
reason enough to ban new expression forms.

> What you'd want to write instead would be:
> f = lambda(x) x;;

It might be possible to patch up this problem with more cleverness in 
the semicolon-insertion algorithm, but that way madness surely lies.

Anyway, I'm already convinced that (lambda Formals Statement) is not 
going to work out. I think we're in agreement there.

>> Do you prefer (lambda Formals Block | lambda Formals Expression)?
> Speaking purely from a syntactic perspective:
> - The block form is fine.
> - The expression form has problems.  It's hard to distinguish an 
> expression that's part of the lambda from an expression that's part of 
> the surrounding expression.

This is a problem with all compound expression forms that end in an 
expression (e.g., yield and let). I don't feel that's reason enough to 
ban them all.

> I don't see enough of a benefit to warrant inclusion of a new lambda 
> concept.  It's just another way of doing what local functions can do.

As I see it, the major benefits of `lambda' are

a) introducing a low-level and compositional primitive that is useful 
for code generation (as a target language for compilers, macros, or 
other language features defined by desugaring), and

b) creating a clearer place in the language syntax to enforce tail 
calling by eliminating `return'

These needs aren't addressed by `function' and almost certainly can't be.

> If there is a bug with local functions, then fix that one instead 
> instead of sowing confusion by having two concepts.

Recall that `lambda' does not include `return', `this', `var', or 
`arguments'. We're not about to eliminate those from `function'! (Nor 
would I advocate doing so-- even if we could somehow rewrite the entire 

Maybe you don't feel that the issues addressed by `lambda' are important 
enough to warrant the new feature, but "just change `function'" is a not 
a realistic argument.


More information about the Es-discuss mailing list