Allen's lambda syntax proposal

Brendan Eich brendan at
Fri Dec 5 13:49:08 PST 2008

On Dec 5, 2008, at 12:49 PM, Allen Wirfs-Brock wrote:

>> From: Brendan Eich [mailto:brendan at]
>> The return hazard exists in Smalltalk too. What's different here that
>> makes you choose differently? Of course, there are more choices than
>> Tennent-to-the-max lambdas or-else classes-as-sugar.
> The difference is in the foundation language we are starting with.  
> Because of the central role of c-style syntactic control constructs  
> in JavaScript it is unlikely that lambda-based control abstractions  
> will ever be as important in JavaScript as they are in Smalltalk.

Agreed so far. The long-term plan here would be macros. Post-Harmony  
at this point.

> [snip] If it is necessary to make a choice I'm inclined to  
> prioritize enhancing object  literals to make them be a better  
> object/class abstraction mechanisms over enhancing lambdas to make  
> them a better control abstraction mechanism.

I question the need to make a choice (yet).

I'm actually concerned about usability of lambdas as anything similar  
to functions. Say they're added, and they prove popular for control  
abstractions and other purposes, including "better functions". Then  
not only will completion-value leaks bite people -- misplaced return  
probably will too, if "better functions" involves porting existing  
code from function to lambda.

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.

[Smalltalk observations snipped -- thanks for those, they make sense  
but I want to keep pushing on what doesn't work in the current  
strawman: wiki space.]

> Don't get me wrong, I like the  semantics of break/continue/return  
> that have been proposed for JavaScript lambdas but given our legacy  
> I can see the return hazard being a real problem.

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  

> And if it is a choice between enhanced object literals and control  
> abstracting lambdas I'd probably go with the object literals.

No false dilemmas yet, please!


More information about the Es-discuss mailing list