Concise functions, Nonexistent lambdas, Explicit tail calls

Brendan Eich brendan at
Tue Dec 9 19:22:04 PST 2008

On Dec 9, 2008, at 5:54 PM, Jon Zeppieri wrote:

> On Tue, Dec 9, 2008 at 7:25 PM, Brendan Eich <brendan at>  
> wrote:
>> The relations are not simple. But I have to say that the lambda- 
>> coded for
>> loop examples:
>> 007822.html
>> were not what I would call clear specifications -- at least not to  
>> the
>> audience of JS implementors working in C++ or a similar language,  
>> and not
>> experienced lambda-coders.
> Those were encodings of a for loop that binds the variables in its
> initialization expression on every iteration.  It's not surprising
> that it would be complicated to take a user's "i++" and, essentially,
> turn it into "rebind i with i + 1."

You're right, that was an extra complication. But something like it  
will come up with for (let x in o), even if we leave the for(let x  
= ...;;) loop binding semantics var-like. There's strong demand for a  
fresh let binding each time through a for-in or for-each-in loop.

> for (initExpr; condExpr, updateExpr) body; ==>
> {
>  initExpr;
>  let $loop = lambda($v) {
>    if (condExpr) {
>      let $v0 = (lambda() { body; })();   // get the completion value  
> of body
>      updateExpr;
>      $loop($v0);
>    } else {
>      $v;
>    }
>  };
>  $loop(<emptyCompletionValue>);
> }

That's not bad, but is it the best spec to actual and likely JS  
implementors? I don't know, I'm asking. Obviously I'm game, since the  
ES4 Reference Implementation was in SML, and so used tail recursion  
for looping. But it did not exhibit the aggressive TCP application  
that's supported by Dave's lambdas proposal.

We never got every TC39 browser-based JS implementor on board with the  
use of SML in the ES4 RI. We should discuss this again before going  
too far down any road.


More information about the Es-discuss mailing list