Allen's lambda syntax proposal
Michael Day
mikeday at yeslogic.com
Fri Dec 5 14:57:19 PST 2008
> 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.
Anyway, these three options look good to me:
(1) Expression lambdas: lambdas whose body is an expression.
var x = lambda(y, z) y + z
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! :)
(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.
(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.
> 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.
Cheers,
Michael
--
Print XML with Prince!
http://www.princexml.com
More information about the Es-discuss
mailing list