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
