Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <python@mrabarnett.plus.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.001
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'cpython': 0.05; '*is*': 0.09; 'instruction.': 0.09; 'wrong,': 0.09; 'python': 0.10; ':-)': 0.12; 'stack': 0.13; 'from:addr:mrabarnett.plus.com': 0.16; 'from:addr:python': 0.16; 'from:name:mrab': 0.16; 'gregory': 0.16; 'iirc': 0.16; 'message-id:@mrabarnett.plus.com': 0.16; 'operation.': 0.16; 'received:192.168.1.4': 0.16; 'received:84.93': 0.16; 'received:84.93.230': 0.16; 'wrote:': 0.16; 'language': 0.19; '>>>': 0.20; 'explicit': 0.22; 'function,': 0.22; 'lawrence': 0.22; 'seems': 0.23; 'tried': 0.24; 'header:In-Reply-To:1': 0.24; 'wondering': 0.25; 'header:User- Agent:1': 0.26; "doesn't": 0.26; 'chris': 0.26; 'restrict': 0.27; 'assembly': 0.29; 'tail': 0.29; 'instruction': 0.29; "i'm": 0.30; 'subject:/': 0.30; 'code': 0.30; 'implement': 0.32; 'anybody': 0.32; 'received:84': 0.32; 'problem': 0.33; 'jump': 0.33; 'languages': 0.34; 'could': 0.35; 'too': 0.36; 'instead': 0.36; 'alone': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'itself': 0.38; 'or,': 0.38; 'received:192': 0.39; 'to:addr:python.org': 0.40; 'mark': 0.40; 'still': 0.40; 'some': 0.40; 'ever': 0.60; 'designers': 0.72; 'succeed.': 0.91
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=OoyysHLt c=1 sm=1 tr=0 a=0nF1XD0wxitMEM03M9B4ZQ==:117 a=0nF1XD0wxitMEM03M9B4ZQ==:17 a=0Bzu9jTXAAAA:8 a=EBOSESyhAAAA:8 a=AGkejYDSTmIA:10 a=IkcTkHD0fZMA:10 a=LlEUEuY70IjBvp8RRc4A:9 a=QEXdDO2ut3YA:10
X-AUTH: mrabarnett@:2500
Date: Wed, 15 Jul 2015 13:00:48 +0100
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/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> <d0mmguFr51gU1@mid.individual.net> <mo5fpv$fpe$1@ger.gmane.org>
In-Reply-To: <mo5fpv$fpe$1@ger.gmane.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.20+
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.538.1436961652.3674.python-list@python.org>
Lines: 24
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1436961652 news.xs4all.nl 2893 [2001:888:2000:d::a6]:59913
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:93869

On 2015-07-15 12:22, Mark Lawrence wrote:
> On 15/07/2015 10:13, Gregory Ewing wrote:
>> Chris Angelico wrote:
>>> I'm still interested in the explicit "replace current stack frame with
>>> this call" operation. Calling it "goto" seems wrong, as most languages
>>> with goto restrict it to _within_ a function,
>>
>> This just suggests to me is that most language designers
>> are not very imaginative. :-)
>>
>> A tail call *is* a goto. That's how you implement one in
>> assembly language -- you write a jump instruction instead
>> of a call instruction. The jump doesn't have to be to
>> the same function.
>>
>
> IIRC the realms of the C setjmp and longjmp.  I'm just wondering out
> aloud if anybody has ever tried playing with cPython using these, or
> whether the code and/or Python itself is just too complex to allow this
> to even be tried, let alone succeed.
>
The problem with longjmp is that it could inadvertently bypass some
clean-up code or deallocation, or, in the case of CPython, a DECREF.