On Dec 5, 2008, at 2:57 PM, Michael Day wrote:
This is all speculation, but here's my non-speculative claim:
lambda syntax should not look so much like function syntax if
return within the body behaves completely differently. We would
want syntax very different from function (i.e., not lambda (args)
{body} -- sorry, Peter Michaux). Or else we should revisit the
wisdom of applying TCP to lambdas.
I'm unconvinced that TCP needs to apply to statements; it seems like
a more valuable property when applied to expressions, even though
JavaScript is not referentially transparent to begin with.
Good points.
Anyway, these three options look good to me:
(1) Expression lambdas: lambdas whose body is an expression.
var x = lambda(y, z) y + z
Would need parens around the body, if this is a primary expression,
else reduce-reduce conflict.
Solves the problem with completion leakage, solves the nested return/
break/continue issue. However, quite limited in usage, and makes it
difficult to use lambdas to replace functions as they can't contain
loop statements. (Hello, recursion! :)
We could mandate tail recursive call sites in the spec so people could
count on it cross-browser.
http://bugs.ecmascript.org/ticket/215
http://bugs.ecmascript.org/ticket/215 (not be necessary for expression-
enclosed tail calls)
(2) Function lambdas: objects just like functions, except no "this"
or "arguments", and perhaps some guarantees about tail calls?
var x = lambda(y, z) { return y + z }
This seems the easiest for programmers to understand, and avoids the
return/break issues. It violates TCP for statements, but I don't
think that really matters in practice; after all, so do functions.
I must agree, since this looks like function syntax, with a new
introductory keyword. TCP must yield.
(3) Parametric blocks: where a block, possibly taking arguments, can
be passed around as an object. The key use-case for this seems to be
creating new control abstractions. I would argue that blocks should
not be usable as expressions, and the completion value cannot be
captured (unless using eval) for consistency with existing statement
behaviour.
var a = block { ... statements ... }
var b = block(x, y) { ... statements using x and y ... }
call b(1, 2); // this is a statement, not an expression
Unfortunately, object literals also look like blocks, and there is
no perfect syntax for this that fits neatly into the existing
language. without using bulky keywords. While this option preserves
TCP, I don't think JavaScript really needs this feature, and the
power/complexity ratio doesn't measure up.
Agreed. Past efforts to add just this kind of block have failed to get
anywhere.
I agree if lambda looks like function or is sold as a "better
function". If it looks more like a block, or something else, that
might mitigate the return hazard. Michael Day wondered if we
confined the body to an expression language -- that would eliminate
the return hazard.
I like options (1) and (2) above. The current proposal on the wiki
feels like all three options mashed together, and I find it
difficult make sense of it as a basic construct.
Including Dave to get his thoughts, in case he is reading es-discuss
in a digest or deferred fashion.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
