Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!bcyclone02.am1.xlned.com!bcyclone02.am1.xlned.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Wed, 15 Jul 2015 11:10:03 +0200
From: Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
References: <CAD+URuj-4e62-9hvpiLsrBP1M6kXRyZhZ6XyL01gWWnDoShvNg@mail.gmail.com> <CAPTjJmrnd2cdA75ROZUKsJfYMdYUXkxRbEN50UE_-r0Jg=c5nQ@mail.gmail.com> <55A3A853.4040006@rece.vub.ac.be> <CAPTjJmr92j+2DDPsZxynoHyZTTCpc-48cWCVrx_fT3dA0j_Osg@mail.gmail.com> <55A3C366.6060602@rece.vub.ac.be> <mailman.468.1436796350.3674.python-list@python.org> <87fv4r1fre.fsf@jester.gateway.sonic.net> <mailman.481.1436851550.3674.python-list@python.org> <87bnff1eks.fsf@jester.gateway.sonic.net> <mailman.499.1436874241.3674.python-list@python.org> <87d1zunctp.fsf@elektro.pacujo.net> <mailman.503.1436878550.3674.python-list@python.org> <87k2u2eu67.fsf@elektro.pacujo.net> <CAPTjJmqtTRHpNZHByn1pKNSfbsG6X--s2d_G0FopKxDugqpjdA@mail.gmail.com> <55A51662.4090007@rece.vub.ac.be> <mo4a7g$mkg$1@ger.gmane.org>
In-Reply-To: <mo4a7g$mkg$1@ger.gmane.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.531.1436951405.3674.python-list@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:93855

On 07/15/2015 02:41 AM, Terry Reedy wrote:
> On 7/14/2015 10:02 AM, Antoon Pardon wrote:
>> On 07/14/2015 03:43 PM, Chris Angelico wrote:
>>> On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa <marko@pacujo.net>
>>> wrote:
>
>>>> No, tail call optimization doesn't change the behavior of the program,
>>>> for the worse anyway.
>>> It does, because you lose traceback records. That's pretty significant
>>> when you come to try to debug something.
>>
>> I doubt it would be really significant. Not compared to writing it
>> iteratively.
>> When you write it iteratively, you don't get to keep a traceback
>> record per time
>> you go throught the loop. So the traceback records you loose in tale
>> call elimination
>> would be the traceback records you wouldn't have anyway in the
>> iterative version.
>
> To repeat: loosing tracebacks is probably fine when the function has a
> single *recursive* tail call.  This are precise the cases when it is
> simple and perhaps preferable to use a loop.  But *recursive* tail
> calls are only a small fraction of all tail calls.  So most of the
> time, the loss *would* be significant.  Consider

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. And when it needs to print
a stacktrace it writes an indication that some tracebacks are missing. I think
that would be a workable compromise between workable tail call recursion
and usefull stacktraces.

Now of course there are some other problems like what if the tail call is into
a C-function. I don't think you want to drop a stack frame in those circumstances.
So I guess implementing this and getting all corner cases right, will not be
trivial and I understand if the core developers don't consider this a high
priority. But one likes to dream sometimes.

-- 
Antoon Pardon