return when desugaring to closures

Yuh-Ruey Chen maian330 at
Fri Oct 10 19:28:05 PDT 2008

Brendan Eich wrote:
> There was general aversion to 'let function f() ...', an earlier ES4  
> idea already on the ropes. Separating binding forms from function  
> definition and other options (such as const) avoids too many binding  
> forms ('let const', 'let function', etc.). But too many binding forms  
> is just too many, and the committee strongly favored using grammatical  
> placement to avoid adding more syntactic complexity.
> > but the good news is
> > the door has been left open for real lambdas to snatch up the
> > available "var a(){}" and "let a(){}" syntaxes.
> There's no reason to add var a() {} given function a() {} as a direct  
> child of a program or function body. It seems to me let a(){} is  
> Dave's define. So we're back to function vs. define/lambda.

I wonder if we really need named lambdas in the first place. I consider
the whole named function/let/var thing to be messy enough already. Is it
really that too difficult to do this:

let f = lambda() { ... }

And if predictable recursion is an issue, you can always do this
(assuming this form is in ES-Harmony):

let (f = lambda() { ... }) ...

I don't consider keeping symmetry with named functions to be a
convincing argument, since the proposed named lamda works on the block
level rather than the function level, unlike named functions. There's
bound to be confusion regardless.

More information about the Es-discuss mailing list