Basic Lambdas and Explicit Tail Calls Repackaged
mikeday at yeslogic.com
Sun Dec 7 23:56:53 PST 2008
> 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).
Print XML with Prince!
More information about the Es-discuss