Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #94049 > unrolled thread
| Started by | Serhiy Storchaka <storchaka@gmail.com> |
|---|---|
| First post | 2015-07-18 06:48 +0300 |
| Last post | 2015-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.
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
| From | Serhiy Storchaka <storchaka@gmail.com> |
|---|---|
| Date | 2015-07-18 06:48 +0300 |
| Subject | Re: 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]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-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