proper tail calls

Jeff Dyer jodyer at adobe.com
Mon Jan 21 15:33:36 PST 2008




On 1/21/08 2:14 PM, Brendan Eich wrote:

> On Jan 21, 2008, at 1:11 PM, Jeff Dyer wrote:
> 
>> On 1/21/08 12:35 PM, Brendan Eich wrote:
>> 
>>> So the axes of disagreement seem to me to be:
>> 
>> We need to agree on the primary purpose of proper tail calls. I say
>> it is
>> portability of code, and that all other concerns do not have enough
>> weight
>> to influence this proposal.
> 
> I'm pretty sure you mean the primary purpose (or reason) for
> *specifying* proper tail calls, not the purpose of proper tail calls
> for state machines, loops, and other call graphs that (absent other
> allocations) must not accumulate space.

Yes. Thanks for clarifying that.

> If we wanted to dig in our
> heels and repeat "use iteration" (Python sticks to this gun), we could.
> 
> 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.

> 
> The mention of GC is apposite: if implementations don't agree on GC
> scheduling, or some use ref-counting, you can write programs that
> fall over (as in, hit a hard memory limit) by coding for one
> particular memory manager. That's obviously a bad idea, but the ES4
> spec can't require a particular memory management algorithm "for
> portability".

I agree. In the case of PTC, portability comes from the requirement that
certain recursive calls exhibit asymptotic memory use, not from a specific
memory management algorithm.

>>> 1. explicit vs. implicit,
>> 
>> Since PTC is about portability of code then what matters most is that
>> implementations agree on what a tail call is. If the spec is
>> unambiguous
>> about what a tail call is, then implementations will have little
>> trouble
>> agreeing. Anyway, an explicit marking won't help.
> 
> Sure, that's clear. But ticket 323 cites benefits of explicit syntax:
> automated checking for the programmer, clues to the readers
> (especially the debugger drivers), new syntax for a new (to ES1-3 and
> real JS implementations) storage rule.
> 
> 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.

> 
>>> 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?

Jd

> 
>>> 4. whether explicit is required for debug-ability.
>> 
>> PTC should not be for improving debug-ability.
> 
> The argument (which I do not think is decisive) is that PTC breaks
> debugability.
> 
> /be
> 




More information about the Es4-discuss mailing list