MIME-Version: 1.0
In-Reply-To: <d1060jF9h2gU1@mid.individual.net>
References: <mailman.617.1437090408.3674.python-list@python.org> <d1060jF9h2gU1@mid.individual.net>
Date: Sun, 19 Jul 2015 10:21:30 +1000
Subject: Re: Proposed keyword to transfer control to another function
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.690.1437265299.3674.python-list@python.org>
Lines: 66
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!news.stben.net!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python:94076

On Sun, Jul 19, 2015 at 9:32 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> Possible alternate syntax:
>>
>> transfer func[, (arg1, arg2, arg3)[, {'kw1': val1, 'kw2': val2}]]
>>
>> This makes it very clear that this is NOT accepting an arbitrary
>> expression, but MUST be used with a single function and its arguments.
>> Downside: It doesn't look like a function call any more. Upside: It's
>> easy to parse.
>
>
> Personally I'd be fine with your initial syntax, but
> something else might be needed to get it past Guido.
> He didn't like my 'cocall f()' construct in PEP 3152,
> which is syntactically isomorphic to 'transfer f()'.

Maybe it should get written up and rejected, then, to be something to
point to any time anyone advocates TCO.

>> Is there anything that I've missed out in speccing this up? I've a
>> suspicion that this might turn out to be as complicated as 'yield
>> from' in all its handling of edge cases.
>
>
> Presumably it would only work on functions implemented
> in Python? It's no use discarding the Python stack frame
> unless the C recursion in the ceval loop can be avoided
> as well.

Hmm. Conceptually, I'd like it to work like this:

def f(x):
    return from g(x+1)

x = f(3)
# absolutely identical to
x = g(4)

Is it possible to strip away the current Python stack frame and
replace it with a C stack frame? That would be the most logical, if
it's viable. It'd also mean that other Python implementations are all
looking at things on the same footing. Obviously 'return from' (or
whatever keyword is used) would be valid only from a Python function,
but ideally it could chain to a function written in any form.

>> Current candidates:
>> "transfer", "goto", "recurse", and anything else you suggest.
>
>
> Another possibility is "chain", which I've seen in some
> contexts for an sh exec-like operation.

Hah, that brings me back! "Chaining was attempted from a REXX batch
file". I never understood why typing the name of a batch file would do
a one-way chain/exec rather than a more logical call. Unix has that
much better.

Downside: The name "chain" is highly likely to exist in people's code.
I'm liking "return from", as it's currently illegal, uses existing
keywords, and parallels with "yield from". But as a term for
describing what happens, "chain" works well.

ChrisA