three small proposals: the bikeshed cometh!

Brendan Eich brendan at
Thu Apr 29 18:11:14 PDT 2010

On Apr 29, 2010, at 4:18 PM, Mark S. Miller wrote:

> Second, +1 on "#" as a short way to define closures, whether they  
> are simply replacing the "function" keyword or introducing a genuine  
> lambda.

The ƒ fans are still strong, so we'll have to run a txt-your-vote  
dancing with the stars elimination round ;-)>

> Third, given the first two, +1 on "#" reviving lambda, with Dave's  
> same "=>" replacing the notion of completion value within the lambda  
> body.

This goes beyond what we've agreed to, though -- TCP making return in  
your example return from the outer function (which you didn't show  

>     arr.forEach(#(ev) {
>         // ...
>         if (pred(el)) { return el; }
>         // ...
>     });

I'm not sure everyone on es-discuss groks this. You're supposing the  
above is in a function, and the return el forces control flow to  
return from that outer function. Full example:

function findElementSatisfyingPredicateWhileDoingOtherStuff(arr, pred) {
   arr.forEach(#(el) {
     // ...
     if (pred(el)) return el;
     // ...
   return null;

We discussed this on the list. Maciej argued strongly against TCP as  
maximum good that trumps other considerations:

Quoting his words:

"So return from a lambda is sometimes but not always a runtime error?
Other times it can return through multiple levels of function calls
without raising an exception? That seems pretty bad for ease of
understanding and for performance of implementations. If you do this:
   [1 2 3].map(lambda (x) { return x + 1; })
I think it would be better for that to be a syntax error than to make
the containing function return 2.
It seems to me the current design prioritizes lambda as a desugaring
construct or building block for imperative-style control flow, over
use as an actual first-class function. I assume break and continue
inside a lambda have similar issues."
--- end quote ---

Then you replied:
And Allen agreed:

Quoting Allen: "In which case perhaps we should abandon this style of  
lambda and work harder at developing a concise construct that is a  
reformed function."

The explicit completion value here-syntax in Dave's let expression  
proposal does not address all the concerns from this end-of-2008  
lambda thread. We can't keep going around on this. I'm all in favor of  
shorthand for function, but TC39 virtually dropped lambda. Do we  
really need to revive it (and return to label, and probably other  
things we probably can't afford)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list