Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <XnsA24F724671D8duncanbooth@127.0.0.1>
References: <mailman.571.1380663065.18130.python-list@python.org> <87had0axxy.fsf@dpt-info.u-strasbg.fr> <XnsA24EA12FAD49Cduncanbooth@127.0.0.1> <bb5ireFbpf3U1@mid.individual.net> <XnsA24F724671D8duncanbooth@127.0.0.1>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Fri, 4 Oct 2013 04:41:28 -0600
Subject: Re: Tail recursion to while iteration in 2 easy steps
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.717.1380883336.18130.python-list@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:55467

On Fri, Oct 4, 2013 at 4:16 AM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Neil Cerutti <neilc@norwich.edu> wrote:
>> On 2013-10-03, Duncan Booth <duncan.booth@invalid.invalid> wrote:
>>> It isn't hard to imagine adding a TAIL_CALL opcode to the
>>> interpreter that checks whether the function to be called is
>>> the same as the current function and if it is just updates the
>>> arguments and jumps to the start of the code block.
>>
>> Tail call optimization doesn't involve verification that the
>> function is calling itself; you just have to verfify that the
>> call is in tail position.
>
> You misunderstood me. As usually implemented tail call recursion doesn't
> require verifying that the function is calling itself, but in Python the
> function could be rebound so a check would be a necessary protection
> against this unlikely situation. Consider this Python:
>
> @some_decorator
> def fact(n, acc=1):
>    if n <= 1:
>        return acc
>    return fact(n-1, n*acc)
>
> Is that tail recursion or not?
>
> You cannot tell whether or not that is tail recursion unless you know the
> definition of 'some_decorator' and even then the answer may vary from run
> to run.

There is no doubt that it's a tail call.  Whether it is recursion is
irrelevant to optimizing it.  The reason we talk about "tail call
recursion" specifically is because the recursive case is the one that
makes the optimization worthwhile, not because the recursion is
necessary to perform the optimization.

It is possible that fact is recursive but that some_decorator adds
additional stack frames that are not tail calls and not optimizable.
If this were the case, then the recursion would still eventually hit
the stack limit, but there would still be benefit in optimizing the
"fact" frames, as it would increase the allowable depth before the
stack limit is reached.  So I see no reason to check the identity of
the called function before optimizing the tail call.