A new module for performing tail-call elimination

[Marko Rauhamaa]

Gregory Ewing <greg.ewing at canterbury.ac.nz>:

> Marko Rauhamaa wrote:
>> At any rate, it demonstrates how the idiom has its place in Python.
>
> Perhaps it does, but I think I'd still prefer it to be explicit.

Don't get me wrong. The method doesn't depend on tail call elimination.
It couldn't because its sibling method has the same recursion depth
without the possibility of tail call elimination.

I was just showing an example of an iteration expressed idiomatically
through a tail call.

> The call in Marko's example is not actually a tail call as written. To
> make it a tail call, a return would need to be added:
>
>>       return child.setvalue(keyseq, value, offset + 1)

Adding the return statement there would be bad because it would suggest
to the maintainer of the code that the method has a meaningful return
value, which it doesn't.

> To someone reading the code, it's not obvious why the return is there.
> It looks redundant, and is likely to get removed by someone who thinks
> it's a mistake.

Exactly. That's why I said also that it is unfortunate for Python to
promise to return None implicitly. That stipulation of the language
specification is against the de-facto semantics of procedures (your
sentence above) and effectively prevents automatic tail call
optimizations.

> Using a dedicated keyword would make it clear that tail call behaviour
> is being relied upon, and avoid looking like a spurious return.

A dedicated keyword would indeed work as advertised. However, I'm not
too keen on the idea. My position is: Python probably should have made
tail call elimination a matter of course, but since it doesn't, oh well.


Marko