Allen's lambda syntax proposal

[Michael Day]

> 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