proper tail calls

Brendan Eich brendan at
Mon Jan 21 23:54:29 PST 2008

On Jan 21, 2008, at 11:37 PM, Maciej Stachowiak wrote:

> What I meant to point out is that the motivating use case for  
> additional up-front checking can't in general be checked until  
> runtime, which somewhat undermines the point you made that many non- 
> tail cases could be caught at compile time.

My (imputed, but I don't disagree) "many" needs proof, but so does  
your "somewhat undermines". Upon this question of how often implicit  
conversions actually gum up the compile-time checking hangs much of  
the debate. But not all: suppose we had implicit tail calls as  
proposed in the wiki. Jon Zeppieri argues for the value of a "tail"  
assertion, an annotation on a call expression, assuming implicit PTC  
and independent of compile- vs. runtime checking.

ES4 is a dynamic language, and the strict mode (optional to  
implementations) won't catch everything. The * type is an intentional  
loophole in the static type checker. But there are lots of programs  
that benefit from such a checker, even with the loopholes and their  
uses. It's not all-or-nothing. Same goes for explicit tail syntax of  
some sort. I'm warming up to the idea that tail annotations are like  
type annotations and should be optional, even with mandatory and  
implicit PTC.


More information about the Es4-discuss mailing list