Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Mon, 07 Oct 2013 22:39:40 +0100
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Tail recursion to while iteration in 2 easy steps
References: <mailman.571.1380663065.18130.python-list@python.org> <87had0axxy.fsf@dpt-info.u-strasbg.fr> <CAMjeLr9KPf=Z4pJoQtU8LXiT686dABg-fpNoWYb9reEPRSsYjA@mail.gmail.com> <524C80B6.3010204@unistra.fr> <mailman.651.1380747919.18130.python-list@python.org> <87li292wnt.fsf@dpt-info.u-strasbg.fr> <mailman.732.1380925974.18130.python-list@python.org> <878uy52ea0.fsf@dpt-info.u-strasbg.fr> <5252F610.9040403@rece.vub.ac.be>
In-Reply-To: <5252F610.9040403@rece.vub.ac.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: python-list@python.org
Newsgroups: comp.lang.python
Message-ID: <mailman.820.1381181988.18130.python-list@python.org>
Lines: 62
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:56333

On 07/10/2013 18:57, Antoon Pardon wrote:
> Op 07-10-13 19:15, Alain Ketterlin schreef:
>>> I want to consider here what it would mean to concretely
>>> implement the abstract notion 'disallow rebinding of function
>>> names' and show what would be behind calling the idea 'not
>>> feasible'.
>>
>> Again, I'm more concerned about the function than about the name.
>>
>> And the fact that "disallow rebinding of function names" is not
>> feasible in Python is a design choice, not an essential
>> characteristic of every programming language.
>>
>> That's fine. My point was: you can't at the same time have full
>> dynamicity *and* procedural optimizations (like tail call opt).
>> Everybody should be clear about the trade-off.
>
> Your wrong. Full dynamics is not in contradiction with tail call
> optimisation. Scheme has already done it for years. You can rebind
> names to other functions in scheme and scheme still has working tail
> call optimisatiosn.
>
Consider this code:

def fact(n, acc=1):
    if n <= 1:
        return acc
    return fact(n-1, n*acc)

It compiles to this:

 >>> dis.dis(fact)
   2           0 LOAD_FAST                0 (n)
               3 LOAD_CONST               1 (1)
               6 COMPARE_OP               1 (<=)
               9 POP_JUMP_IF_FALSE       16

   3          12 LOAD_FAST                1 (acc)
              15 RETURN_VALUE

   4     >>   16 LOAD_GLOBAL              0 (fact)
              19 LOAD_FAST                0 (n)
              22 LOAD_CONST               1 (1)
              25 BINARY_SUBTRACT
              26 LOAD_FAST                0 (n)
              29 LOAD_FAST                1 (acc)
              32 BINARY_MULTIPLY
              33 CALL_FUNCTION            2 (2 positional, 0 keyword pair)
              36 RETURN_VALUE

I think that CALL_FUNCTION immediately followed by RETURN_VALUE could
be tail-call optimised by dropping the caller's stack frame provided
that (like in this case) the callee doesn't refer to any name in the
callers stack frame (nonlocal).

You could also consider replacing the caller's stack frame with a
smaller pseudo-frame, perhaps compressing multiple pseudo-frames or
repeated sequences of pseudo-frames into a single pseudo-frame, so that
it could still generate the same traceback as before (or an compressed
traceback like what was discussed on python-ideas in the threads
"Compressing excepthook output" and "Idea: Compressing the stack on the
fly").