Basic Lambdas and Explicit Tail Calls Repackaged

[Michael Day]

Hi Brendan,

> 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.

Yes, I meant that activation object for a lambda execution context would 
not contain an arguments object, such that 10.1.6 and 10.1.8 would only 
apply to execution contexts for function objects.

> 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.

Every execution context has a this value, and I assumed that it would be 
set to 'undefined' when entering a lambda.

> How about var in lambda? Allowed, or banned in favor of let or const?

Well, without thinking about it very deeply, I would say that if it's 
not banned then lambdas are too similar to functions, and not worth 
introducing at all. So I guess I would say banned :)

> The ReturnStatement's Expression (if present) must be a CallExpression, 
> not just contain one, of course. Just picking nits ;-).

Right, that's what I meant :)

(It technically means that one could disable tail calls by wrapping the 
call in parentheses, but this is a fairly minor issue either way).

Cheers,

Michael

-- 
Print XML with Prince!
http://www.princexml.com