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.
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
