[pypy-dev] Getting involved

[Mark Roberts]

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 <arigo at tunes.org> wrote:
> 
> Hi Laurence,
> 
>> On 10 July 2014 13:12, Laurence Tratt <laurie at 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 at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev