proper tail calls

Brendan Eich brendan at
Mon Jan 21 16:05:06 PST 2008

On Jan 21, 2008, at 3:33 PM, Jeff Dyer wrote:

>> But we have accepted the proper tail calls proposal for a long while,
>> to serve such currently poorly-served use-cases. We have to evaluate
>> the syntax as well as semantics against usability and other criteria
>> in light of those use-cases. Portability is an end, but not the only
>> end.
> My point is that some of those poorly served use cases have nice  
> solutions
> that might work on some, but not all, implementations without a  
> definition
> of PTCs in ES4. I think we agree about this.

Not sure whether you mean some implementations might implement PTC  
even if the spec does not require it, or something else (some  
implementations might have big stacks -- but no, that's can't be  
right). So yeah, if only some (and currently I think the count is  
zero among popular browsers -- Opera folks please correct me if I am  
wrong) implementations support PTC, then anyone writing portable code  
can't rely on PTC working cross-browser. I believe everyone who has  
spoken up in the committee has favored some kind of PTC, implicit or  

But again, we don't specify detailed storage requirements that would  
improve portability for other use-cases. It's precisely the use-cases  
for PTC that motivate our concern that PTC be reliably portable. That  
makes the use-cases for PTC primary in my book, and portability  
secondary (not more or less important, but dependent on the first  
condition: that the use-cases are worth the language facility).

>> In other words, humans programming in the langauge might benefit from
>> explicit syntax, even if compilers and the (fewer, more expert)
>> humans who write them can get implicit proper tail calls right.
> Okay, I'll take that up in the bug. Suffice to say here that I  
> think clarity
> and debug-ability are at odds with portability, the greater good.

Wait, you were arguing that portability is the only good (not so),  
and that since it wasn't aided by explicit syntax, explicit syntax  
should be dropped. Now you're making a false dilemma between  
portability and explicit syntax for language-user benefits. But  
explicit syntax does not harm portability, you never made that case  
(and it's silly to say explicit syntax for tail calls as a normative  
part of the spec harms portability).

>>>> 2. whether to have a tail annotation if implicit,
>>> Ditto. It won't aid in ensuring portability of code.
>> That's not the only end; another good to serve here is correctness.
> In practice, correctness is only served if implementations are  
> forbidden to
> implement PTC behavior for any but the sanctioned tail call  
> syntaxes. And
> that is not what is being proposed. Am I mistaken?

No, I'm talking about correctness, as in

1. The programmer uses the explicit syntax, let's say "goto f(x)",  
where the call to f is not in tail position. We would like an error  
here. With implicit PTC, the programmer fails to get a tail call and  
the stack may grow, but does QA find out in time?

2. The programmer uses "goto f(x)" where f returns T and the call is  
in g returning Y, and there's a space-accumulating (built-in)  
conversion from X to Y. We would like a strict error if this can be  
detected statically. Without the explicit syntax signalling PTC  
intent, the implementation will just do the conversion and accumulate  
stack space. Will QA find out in time?


More information about the Es4-discuss mailing list