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