Allen's lambda syntax proposal

[Brendan Eich]

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