Basic Lambdas and Explicit Tail Calls Repackaged
Brendan Eich
brendan at mozilla.com
Sun Dec 7 23:45:07 PST 2008
On Dec 7, 2008, at 1:10 AM, Michael Day wrote:
> Hi,
>
> I thought it might be good to package these two proposals together,
> as they are interrelated.
>
> It would be very much appreciated if anyone could point out major
> use cases that these proposals don't cover, or any other important
> issues that they might currently neglect.
>
> BASIC LAMBDAS
>
> Lambdas are similar to functions, but use the "lambda" keyword
> instead of "function", always have a "this" value of "undefined",
> and do not have an "arguments" object in scope.
If the lambda is enclosing in a function, is that function's arguments
binding visible in the lambda body? Probably you meant to allow outer
arguments to be unshadowed, not somehow censored, but I thought I'd ask.
Same question for |this| could be asked (never mind an enclosing
function, since |this| is bound in global code), although Mark had an
argument against lexical |this| for classes as sugar -- but that
argument may not bear on lambdas.
> LAMBDA EXAMPLES:
>
> var x = lambda(n) { return n + 1 }
>
> var x = lambda fact(n) {
> if (n <= 1)
> return 1;
> else
> return n * fact(n-1);
> };
How about var in lambda? Allowed, or banned in favor of let or const?
> EXPLICIT TAIL CALLS
>
> The JavaScript specification should require implementations to
> treat any ReturnStatement containing a CallExpression as a tail
> call, except in cases when the ReturnStatement is within a
> WithStatement or within a TryStatement.
The ReturnStatement's Expression (if present) must be a
CallExpression, not just contain one, of course. Just picking nits ;-).
I like your thinking here, on both lambdas and tail calls.
/be
More information about the Es-discuss
mailing list