On 2011-04-18, at 18:42, Steve Klabnik wrote:
> Guido has said that any interpreter that implements TCO is not Python.

I recall that quote, and it totally mystifies me. Of course, he IS BDFL, =
and has the right to say what is and is not Python. But it seems like a =
very peculiar comment, and, based on some of the message traffic I saw =
at the time, he seems to misunderstand what this optimization is. There =
are good reasons (relating to the JVM, which I mentioned earlier) why =
one might decide NOT to make it mandatory, but his absolute refusal =
seems somewhat doctrinaire to me.=20

If every environment in which Ruby (or Python) runs supported TCO, then =
there would be little reason to ban it. If that isn't practical, then a =
way of discerning whether it's supported in a given implementation seems =
appropriate.

That said, very few tail recursive methods would likely be written in =
Ruby, given the many other fine ways of looping. So my reason for =
wanting it has more to do with a small set of cases where it's more =
expressive than other techniques, rather than something that =
substantially changes the way we write programs.=20

In reality, the more useful benefit of TCO comes when it's not a =
recursive procedure, but simply invoking another method, and thus using =
less stack. That leads, for example, to a very nice and clean way of =
writing state machines, for example.=20

-- vincent