[Python-ideas] return from (was Re: Tail recursion elimination)

[Nick Coghlan]

On 20 Jan 2014 11:16, "David Mertz" <mertz at gnosis.cx> wrote:
>
> I was mostly disliking the idea of TCO during this discussion.  However,
the idiom of 'return from' seems sufficiently elegant and explicit--and has
exactly the semantics you'd expect from 'yield from'--that I am actually +1
on that idea.

I agree that a PEP for "return from" would be interesting. It also gives
debuggers something to latch on to in order to handle the new scenario
(just as they needed some adjustment to handle "yield from").

"return from" could also be explicitly disallowed in try blocks and with
statements (since those inherently conflict with the idea of reusing the
current frame for a different call).

By keeping a list of references to the ellided calls (perhaps using counts
for more efficient handling of recursive calls), you could even partially
reconstruct the missing parts of the traceback.

> Being an explicit construct, it definitely becomes a case of "consenting
adults" not of implicit magic.  I.e. you are declaring right in the code
that you don't expect to see a frame in a stack trace, which is fair
enough.  I mean, if you *really* wanted to you could muck around with
'sys._getframe(N).f_whatever' already which would give inaccurate
tracebacks too.  Probably there would be a way to removed frames from the
stack even, using some such trick in current python.

Yep, we do that (from C) in importlib to try to reduce the infrastructure
noise in the tracebacks shown to users.

Cheers,
Nick.

>
>
> On Sun, Jan 19, 2014 at 3:13 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>> Proposal (mostly not mine): add 'return from f(args)', in analogy with
'yield from iterator', to return a value to the caller from an execution
frame running f(args) (and either reuse or delete the frame that ran
'return from'). The function name 'f' would not have to match the name of
the function being compiled, this would actually be TCO, even if it were
nearly always used for recursive tail calls. That does mean that is would
work for mutually tail recursive functions.
>>
>> On 1/19/2014 6:57 AM, Joao S. O. Bueno wrote:
>>>
>>> OTOH, since we are at it, we'd better check
>>> 2009 BDLF's opinion on the subject:
>>>
>>>
http://neopythonic.blogspot.com.br/2009/04/tail-recursion-elimination.html
>>
>>
>> I read throught the comments and near the very end, in July 2013, Dan
LaMotte said... '''
>> Definitely seems to be complicated/impossible to determine a function is
tail recursion 'compliant' statically in python, however, what if it were
an 'opt in' feature that uses a different 'return' keyword?
>>
>>     def f(n):
>>     if n > 0:
>>     tailcall f(n - 1)
>>     return 0
>> '''
>> In additional paragraphs, he noted, among other things, that this makes
the feature 'opt-in' on a function by function basis.
>>
>> Guido replied "Dan: your proposal has the redeeming quality of clearly
being a language feature rather than a possible optimization. I don't
really expect there to be enough demand to actually add this to the
language though. Maybe you can use macropy to play around with the idea
though?"
>>
>> 水逝云飞 then suggested 'return from'. My only contribution is to point out
the analogy with the new, and initially strange, 'yield from'.
>>
>> Guido seems to have said that if a) someone tries out the idea with
macropy, and b) someone demonstrates enough demand, he might consider
adding such a feature. So this seems to me the best option to pursue to get
something into CPython. I also think it is the best proposal so far.
>>
>> As for a), I have not looked as macropy, but:
>> On 1/19/2014 4:33 PM, Haoyi Li wrote:> MacroPy's @tco decorator is about
as easy as you could ask for. 'pip
>> > install macropy', 'from macropy.experimental.tco import macros, tco' >
is about as easy as you could ask for. Works for arbitrary tail-calls >
too, not just tail recursion.
>>
>> That leaves b) for those of you who want the feature.
>>
>> Any PEP should admit that the feature might be abused. Someone might
write
>>   return from len(composite)
>> Unless return from refuses to delete the frame making a call to a C
function, the effect would be to save a trivial O(1) space as the cost of
deleting the most important line of a stack trace should len() raise. But I
think this falls under the 'consenting adults' principle. A proposed doc
should make it clear that the intended use is to make deeply recursive or
mutually recursive functions run and not to replace all tail calls.
>>
>> --
>> Terry Jan Reedy
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140120/a3f4465e/attachment-0001.html>