proper tail calls

Peter Michaux petermichaux at gmail.com
Sat Jan 19 00:31:18 PST 2008


On Jan 18, 2008 10:49 PM, Brendan Eich <brendan at mozilla.org> wrote:
>
> On Jan 18, 2008, at 9:36 PM, Peter Michaux wrote:

[snip]

Some of the shorthand terminology that has developed in the
conversations is a bit unfamiliar to me. Hopefully my questions below
are not ridiculous.

>  Is it not reasonable for
> the spec to simply require implementations to have proper tail calls?
>
> The I,X original proposal from the wiki required this. It's "reasonable",
> maybe, if we can agree on the rules and they are not too complicated, but
> the crucial question is about usability, human factors, avoiding silent bad
> surprises: will programmers wanting proper tail calls be surprised when they
> nest an implicit (built-in among the primitive types) conversion in a big
> state machine, and silently defeat proper tail calls from that particular
> call site, leading to explosive stack growth in the worst case?

I'm thinking in terms of Scheme and tail calls. If a Scheme programmer
puts a recursive call in a non tail position they get explosive stack
growth. If the programmer was required to explicitly state they wanted
a tail call then the explicit system you are suggesting would throw an
error, correct?

It seems like having types in ES4 is adding quite a bit of difficulty
to when a proper tail call can occur. The Scheme folks don't have to
deal with that, I suppose.

> This concern of course led to the ticket; the principle familiar to Python
> folks is EIBTI (E Is Better Than I). Not just for readers (clarity of
> intent) but for writers (I want PTC or error here).
>
> Is it not acceptable for the spec to require certain implementation
> internal optimizations?
> PTC is not an optimization, it's a storage rule. Schemers know to count on
> it, and do. For ~12 years, JS hackers have lacked it, on the other hand. And
> JS hackers have standard looping statement forms. But PTC is helpful for
> state machines, which you do see on the web; you even see setTimeout(fun, 0)
> flows to empty the JS stack in order to avoid overflow. PTC is worthwhile,
> and we have included it among approved proposals for a long time. The
> question remains: explicit or implicit syntax; if explicit, statement only
> or operator form?

I think implicit tail calls are one of the most exciting proposals for
ES4. Can it be implicit with the option of making it explicit so that
it throws an error if the call is not in tail position and will
produce the explosive stack growth? This would have the same feel that
the language is "unsafe" but has optional "safety" features like
optional types. ES3 doesn't have any mandatory safety syntax and to me
it would be best to keep all safety syntax optional.

Peter



More information about the Es4-discuss mailing list