Does this mean that you cannot implement an interpreter for a language requiring TCO with PyPy/RPython?
-Mark > On Jul 11, 2014, at 1:57, Armin Rigo <ar...@tunes.org> wrote: > > Hi Laurence, > >> On 10 July 2014 13:12, Laurence Tratt <lau...@tratt.net> wrote: >> Tail call optimisation has trade-offs: one can always construct cases where >> it loses debugging information. If you'll permit the immodesty, one of my old >> blog articles gives one example of this [1]. > > A comment about this, if I can make it here: for languages like > Python, there are two slightly different issues. The first is to use > a constant amount of memory to do unbounded calls. This is difficult > because of the stack trace issue you mention. However, a second and > smaller issue would be to use a constant amount of *stack*, allowing a > non-constant amount of *heap* to be used. > > If you want full tracebacks and full compatibility with Python, this > would be a rather fine solution nowadays. Nobody cares much if there > is a temporary chained-list of 100'000 objects in memory. This is > what I had in mind above: add a TAIL_CALL bytecode that tries to > allocate a new "Python Frame" object and attach it on the chained > list, but then instead of recursively calling the interpreter, it > would run the same-level interpreter with the newly allocated frame. > This may be enough to make happy people with what I'm going to call > the "tail calls! grudge". I would be hard-pressed to know if the > result would be faster or slower, or if the JIT would need tweaks to > perform better, but I'm certainly willing to let them try that (and > help a bit). > > Now maybe the "tail calls! grudge" runs deeper and this solution would > not be acceptable either. Such people would like a fully > constant-memory recursion, and would actually *not* like full > tracebacks, simply on the grounds that it doesn't help anybody to > print a traceback of 100'000 entries or more. These are the people > that occasionally go to python-dev and try to design what is basically > language-level changes to support tail calls, only to be generally > flatly rejected. If John Smith is in this category, then his ideas > will be equally flatly rejected from PyPy --- with the exception that > we might consider it if he at some point would like some core support > from PyPy (like a new bytecode) in order to implement his ideas (e.g. > in pure Python module that he could distribute on pip, which would > give e.g. a decorator that hacks at the bytecode of its function.) > > > A bientôt, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
