return when desugaring to closures

[Brendan Eich]

On Oct 9, 2008, at 8:57 PM, Peter Michaux wrote:

> This keyword/scoping problem must already have appeared for functions
> as function declarations have "var" scoping and obtaining "let"
> scoping requires using something like "let a = function(){}". This is
> pretty ugly for functions to have "let" scoping

An agreement from TC39 this past sprint was that function definitions  
directly nested in blocks, not specified by ES3, defined block-local  
(let) bindings.

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.

The idea of a desugaring let statement and let expression require  
lambda, the reformed function (whether define wins or not). But let  
declarations as "the new var" do not desugar to lambdas. They hoist,  
even if forward references (use before set) are errors.

We haven't found a reformed var; I don't think there is one. This does  
not mean let declarations are somehow not worth adding. They're a big  
improvement on var declarations in our experience with let in JS1.7  
and up.

/be