Allen's lambda syntax proposal

Maciej Stachowiak mjs at apple.com
Fri Dec 5 09:39:31 PST 2008


On Dec 4, 2008, at 10:27 PM, Brendan Eich wrote:

> On Dec 4, 2008, at 10:12 PM, Brendan Eich wrote:
>
>> On Dec 4, 2008, at 7:45 PM, Michael Day wrote:
>>
>>> Hi Brendan,
>>>
>>>> The main contention about lambdas ignoring syntax is whether the  
>>>> completion-value creates a hazard that needs to be treated  
>>>> somehow, or even judged as fatal to the proposal.
>>>
>>> Completion value, like the last thing to be evaluated in the  
>>> lambda? What exactly is the nature of the hazard?
>>
>> Functional programming favors using completion values -- function  
>> call results propagate back up naturally this way. Chaining,  
>> filters, etc. all work the way you want. Here's the Y combinator:
>>
>> const fact = lambda(proc) {
>>   return lambda (n) { (n <= 1) ? 1 : n * proc(n-1); }
>
> D'oh -- I wrote return incorrectly there. That means, by Tennent's  
> Correspondence Principle, that if the above were embedded in a  
> function, the return would force control flow to return from the  
> function as well as the outer lambda (the one assigned to const  
> fact), and the return value would be the inner lambda.
>
> This is the other hazard with lambdas. The program equivalences  
> Tennent's Correspondence Principle enables are  good for  
> refactoring, but bad for thinkos like the above.
>
> (Honest, I didn't do it on purpose!)

What exactly does return from a lambda mean? Let's say I do this:

function F(x) { return lambda(n) { return x + n; } }
function G(h) { return h(1) +1; }
var H = F(1);
G(H);

What is the value of the last expression and why?

Regards,
Maciej



More information about the Es-discuss mailing list