proper tail calls

Lars T Hansen lth at
Tue Jan 22 13:05:33 PST 2008

On 1/22/08, Steven Johnson <stejohns at> wrote:
> On 1/22/08 12:14 PM, "Lars T Hansen" <lth at> wrote:
> > IMO, the best design is that (a) a call that is syntatically in tail
> > position is executed as a tail call when that is possible, but as a
> > non-tail call when type conversions or type checking interferes, and
> > that this happens without the programmer having to think about it, and
> > (b) an annotation ("goto", whatever) can be used to check that the
> > tail call is in fact possible, and it will cause an error (at compile
> > time in strict mode, possible) if that is not possible.  Thus we have
> > tail call annotations like we have type annotations; people use them
> > if they feel that provides benefit.  For everyone else it "just works
> > except when it doesn't" -- again, exactly like typing.
> I think you've hit the nail on the head with this one. IMHO this fits well
> with rest of the optional-type-annotation mode of operation in ES4.
> I don't really care what the syntax is, but I do very much like the idea of
> an obvious directive that means "I expect this to be a tail call; please
> fail immediately if it can't be one".
> Question: should an implementation be *required* to execute a tail call as a
> Proper Tail Call when possible, even if said syntax is not present? (or
> merely *permitted* to do so?)

Required -- or we have nothing.  Virtually nobody will use the
annotation.  (As I've noted in the ticket I actually oppose the idea.
But since it's optional and basically free to the implementation, I
don't care too much if it gets adopted anyway, as long as programs
that don't use it are not treated as second class.)


More information about the Es4-discuss mailing list