Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #94049 > unrolled thread

Re: Proposed keyword to transfer control to another function

Started bySerhiy Storchaka <storchaka@gmail.com>
First post2015-07-18 06:48 +0300
Last post2015-07-18 20:06 -0700
Articles 2 — 2 participants

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Proposed keyword to transfer control to another function Serhiy Storchaka <storchaka@gmail.com> - 2015-07-18 06:48 +0300
    Re: Proposed keyword to transfer control to another function Rustom Mody <rustompmody@gmail.com> - 2015-07-18 20:06 -0700

#94049 — Re: Proposed keyword to transfer control to another function

FromSerhiy Storchaka <storchaka@gmail.com>
Date2015-07-18 06:48 +0300
SubjectRe: Proposed keyword to transfer control to another function
Message-ID<mailman.672.1437191299.3674.python-list@python.org>
On 17.07.15 02:46, Chris Angelico wrote:
> Out of the lengthy thread on tail call optimization has come one broad
> theory that might be of interest, so I'm spinning it off into its own
> thread.
>
> The concept is like the Unix exec[vlpe] family of functions: replace
> the current stack frame with a new one. This can be used for explicit
> tail recursion without repeated stack frames, or for a pre-check that
> then disappears out of the stack. Like any other feature, it can be
> misused to make debugging difficult, but among consenting adults,
> hopefully it can be used sensibly.

I think there is no chance that this proposition will be accepted by 
Guido, because it makes debugging harder.

[toc] | [next] | [standalone]


#94087

FromRustom Mody <rustompmody@gmail.com>
Date2015-07-18 20:06 -0700
Message-ID<4c0b6646-f5c9-4dee-8686-00beafb46205@googlegroups.com>
In reply to#94049
On Saturday, July 18, 2015 at 9:18:32 AM UTC+5:30, Serhiy Storchaka wrote:
> On 17.07.15 02:46, Chris Angelico wrote:
> > Out of the lengthy thread on tail call optimization has come one broad
> > theory that might be of interest, so I'm spinning it off into its own
> > thread.
> >
> > The concept is like the Unix exec[vlpe] family of functions: replace
> > the current stack frame with a new one. This can be used for explicit
> > tail recursion without repeated stack frames, or for a pre-check that
> > then disappears out of the stack. Like any other feature, it can be
> > misused to make debugging difficult, but among consenting adults,
> > hopefully it can be used sensibly.
> 
> I think there is no chance that this proposition will be accepted by 
> Guido, because it makes debugging harder.

I personally thought Chris was being tongue-in-cheek with this suggestion.

Taking it more seriously, here are some thoughts.
Given:
1. A new keyword is a more deep change than a new optimzation flag
2. The tail-call site is (arguably!) more crucial than the tail-call

So why not have a tco decorator such that

@tco
def foo(...):
  body

will have tail-calls in body optimized?

My guess is that someone who knows enough of python's code generator may
even be able to do it in pure python; ie with no change to the language
in foo.__code__.co_code, replace code of the form "... call; ret..." with 
"...goto..."

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web