proper tail calls

Lars Hansen lhansen at
Tue Jan 22 15:25:54 PST 2008

> -----Original Message-----
> From: es4-discuss-bounces at 
> [mailto:es4-discuss-bounces at] On Behalf Of Dave Herman
> Sent: 21. januar 2008 16:58
> To: Peter Hall
> Cc: Brendan Eich; es4-discuss at; Jeff Dyer; Erik Arvidsson
> Subject: Re: proper tail calls
> > I am a bit out of my depth in this discussion, but explicit syntax 
> > feels wrong to me. However, if it's going to be implicit, 
> it has to be 
> > completely invisible (aside from the benefits) - developers 
> are going 
> > to want their debugging tools to work as before.
> > 
> > Is there a practical approach to recursion counting, that ES4 could 
> > require, so that Error.getStackTrace() can use it to produce the 
> > "expected" result?  I must admit, It doesn't feel as trivial in my 
> > head as that sentence reads...
> You can easily circumvent an expression being in tail 
> position. For example, if EXP is in tail position and you 
> want it not to be, just wrap it as:
>      let (r = EXP) r
> The program behaves the same, except for the fact that EXP is 
> no longer in tail position, so it cannot perform a tail call.

Of course some implementations would optimize away r, and EXP would be
back in tail position.  ISTR that the R5RS made a point of saying that
an implementation would be allowed to do that, and I think this ought to
be true for ES4 too.  Ditto, interprocedural analysis and/or inlining
may prove that the body of a "try" can't throw an exception, thereby
allowing the exception handler to be removed, thereby exposing a
possibility for TCO.  And so on.

Maybe we need a directive for turning off tail calls:

  please don't goto f(37)


More information about the Es4-discuss mailing list