Possibly Pythonic Tail Call Optimization (TCO/TRE)
antoon.pardon at rece.vub.ac.be
Thu Jul 16 09:31:44 CEST 2015
On 07/16/2015 12:43 AM, Gregory Ewing wrote:
> Antoon Pardon wrote:
>> But it doesn't need to be all or nothing. How about the following possibility.
>> When the runtime detects a serie of tail calls, it will keep the bottom three
>> and the top three backtrace records of the serie.
> Whatever value you choose for N, keeping only the
> first/last N traceback frames will lead to someone
> tearing their hair out.
I would say, that someone should get over himself.
Traceback are not the only or even the most useful
tool for debugging code. The current stack trace
doesn't even contain the value's of the variables
on the stack. So in case of Terry Reedy's example
that stack trace would IMO have been next to useless.
> I recently had an experience with some Java code
> running in an environment which believed that nobody
> would want to see more than about 30 traceback levels,
> and chopped the rest off. Of course, the information
> I desperately wanted was buried deeper than that...
So? My experience is, that if you need to dig that deep
in a stack trace, to find the information you need, you
get it easier and faster by turning debug level logging
on and going through the logs. YMMV.
I also have to wonder, In my suggestion you would only start
to loose traceback records after six consecutive tail calls.
That IMO strongly suggest a loop. Most people suggest such
a loop should be written iteratively. So my example would
allow to keep 6 trace back records through such a loop
while the iterative version would only keep one trace back
record. But no one seems to be tearing their hair out
for not having trace back records of the previous run
through a loop. Yet you protest when trace back records
disappear when such a loop is written recursively.
> So, -1 on any arbitrarily chosen traceback cutoff.
Noted. It just doesn't carry much weight with me.
More information about the Python-list