Basic Lambdas and Explicit Tail Calls Repackaged

[Brendan Eich]

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