Allen's lambda syntax proposal

Brendan Eich brendan at mozilla.com
Thu Dec 4 22:12:25 PST 2008


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); }
}

const Y = lambda(outer) {
     const inner = lambda (proc) {
         outer(lambda (arg) { proc(proc)(arg); });
     }
     inner(inner);
}

print("5! is " + Y(fact)(5));

Adding return keywords just adds overhead, noise. One might even want  
to get rid of the curly braces around lambda bodies, but the only way  
to do it in the ES grammar and avoid ambiguity is to replace braces  
with mandatory parentheses.

On the other hand, much JS on the web is imperative, and a lot uses a  
mixed functional/imperative style. Often the last value in a function  
is not the return value you want callers to be able to get, and with  
functions all is well: falling off the end returns undefined.

But with lambdas, falling off the end returns the last statement's  
completion value. This means people will have to write

lambda (secret) { compute(secret); void 0; }

and similar. Of course too few will remember to do this, so implicit  
return values will tend to leak.

How severe a problem this might be is arguable, but we don't want to  
gamble. We want user feedback based on trial implementations, and  
other convincing evidence for or against.

/be


More information about the Es-discuss mailing list