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