Basic Lambdas and Explicit Tail Calls Repackaged

[Brendan Eich]

On Dec 7, 2008, at 9:55 PM, Michael Day wrote:

>> I agree with you: lambdas in http://wiki.ecmascript.org/doku.php?id=strawman:lambdas 
>>  look useless too. They don't have a clearly articulated vision nor  
>> compelling use cases (at least not in the document).
>
> Right, can anyone clarify this? Is there a summary anywhere stating  
> exactly why lambdas are needed in JavaScript and which use cases  
> they are intended to satisfy?

We started with lambdas as better functions. They evolved due to a  
combination of TCP idolatry (sorry, I call it as I see it :-P) and  
some preference for Scheme-ish modeling of statements as if they were  
part of an expression language (based on completion value precedent  
used by eval).

We should back up and reconsider the goals. It seems to me that these  
two main goals are in conflict:

1. Better functions, better meaning no |this| parameter and no  
arguments object, possibly no var. For this item alone, TCP for var,  
return, etc. seems undesirable. We could ban var, and make return  
apply to the immediately enclosing lambda, which would thus not be  
anything comparable to a Smalltalk block.

2. The ability to desugar existing and future syntax into kernel  
semantics primarily using lambda coding and lexical bindings. As the  
for loop desugarings Mark and David-Sarah worked out demonstrate, this  
item wants var TCP at least, probably the full monty: |this|, return,  
break, continue all apply to the lexically enclosing function, loop,  
switch, etc.

About return, break, and continue, I think Michael Day is onto  
something in arguing that TCP loses when it comes to block-bodied  
lambdas (if we have such, and we think we should, because the JS  
expression language is too weak as Jon Zeppieri colorfully asserts).  
What motivates aggressive TCP application is the second goal.

Is it possible to reconcile these goals? I don't think so. If not,  
then 1 trumps 2 for a language catering to humans rather than, or  
primarily over against, code generator programs or a relatively few  
specifications that want to desugar, no matter the loss of clarity or  
usability to most hand-coding users of the language. 2 trumps 1 if  
it's all about Schemers and GWT or Volta or OpenLaszlo or Skynet :-P.

I say 1 trumps 2 for the reason given in the last paragraph: human  
programmers first, meaning the fat bell curve (sorry, Schemers).

/be