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
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
