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