Re: Proposed keyword to transfer control to another function
On 07/19/2015 02:21 AM, Chris Angelico wrote: On Sun, Jul 19, 2015 at 9:32 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: 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. Those who remember the history of pep 308 will not find that a strong deterrent. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Wed, Jul 22, 2015 at 3:33 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: On 07/19/2015 02:21 AM, Chris Angelico wrote: On Sun, Jul 19, 2015 at 9:32 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: 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. Those who remember the history of pep 308 will not find that a strong deterrent. It doesn't have to be a deterrent. It just has to say Here's all the arguments we came up with in 2015, so find answers to those if you want to reopen the debate. It's effectively a way of rapidly onboarding the conclusions from a lengthy discussion, much more easily than pointing someone to the archive and expecting him/her to read through it all. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Mon, Jul 20, 2015 at 2:24 AM, MRAB pyt...@mrabarnett.plus.com wrote: On 2015-07-19 17:13, Chris Angelico wrote: On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. HHMLL stands for hashed-head multiple-linked list, a phrase from a little earlier in the post. D'oh. I skimmed the post, looking for expressions matching that, and somehow missed it. Of course, it's right there when I go back and check again. I'm pretty sure the universe is out to gaslight me some days, particularly the days when my proposals end up indecisive. Which one of them is, today. This does not bode well. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 2015-07-19 17:13, Chris Angelico wrote: On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. HHMLL stands for hashed-head multiple-linked list, a phrase from a little earlier in the post. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Mon, Jul 20, 2015 at 2:41 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 19/07/2015 17:24, MRAB wrote: On 2015-07-19 17:13, Chris Angelico wrote: On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. HHMLL stands for hashed-head multiple-linked list, a phrase from a little earlier in the post. I want one in the stdlib on the grounds that I like the name :) I like the name Rachel, too, but I don't want her in the stdlib :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. ChrisA [1] https://xkcd.com/1334/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 19/07/2015 17:24, MRAB wrote: On 2015-07-19 17:13, Chris Angelico wrote: On Mon, Jul 20, 2015 at 2:05 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: I've only seen one other application using HHMLL -- and that was the Amiga file system. Okay, I'll bite. What does HHMLL stand for? Google didn't answer my question instantly with the first result, like it usually does. I even got desperate [1] but no luck. HHMLL stands for hashed-head multiple-linked list, a phrase from a little earlier in the post. I want one in the stdlib on the grounds that I like the name :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
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... -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
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()'.
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.
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.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Sun, Jul 19, 2015 at 9:32 AM, Gregory Ewing
greg.ew...@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
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 07/17/2015 01:46 AM, Chris Angelico wrote: Open for bikeshedding: What should the keyword be? We can't use exec, which would match Unix and shell usage, because it's already used in a rather different sense in Python. Current candidates: transfer, goto, recurse, and anything else you suggest. I propose the combination return from. I think it is similar enough with yield from to justify this and it also won't need an extra keyword, so no programs will be broken because they used transfer, goto or whatever other new keyword as an identifier. Should there be someone who is willing to spend time on this, I wish him all luck and strength he can find. I think it would be best if it was done by someone who is interrested in using this in his own programs. Because it is all very fine talking about the pro and cons here and I certainly would use it, the question is, how wide spread would the use become and is it worth the time and effort to introduce it. If future use turns out to be disappointing such a coder can at least think of it as something that was useful for himself. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Fri, Jul 17, 2015 at 5:17 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: On 07/17/2015 01:46 AM, Chris Angelico wrote: Open for bikeshedding: What should the keyword be? We can't use exec, which would match Unix and shell usage, because it's already used in a rather different sense in Python. Current candidates: transfer, goto, recurse, and anything else you suggest. I propose the combination return from. I think it is similar enough with yield from to justify this and it also won't need an extra keyword, so no programs will be broken because they used transfer, goto or whatever other new keyword as an identifier. Oooh I like this. The parallel makes sense, and as you say, no new keyword. Yes, return from is my new preferred command! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 7/17/2015 3:17 AM, Antoon Pardon wrote: On 07/17/2015 01:46 AM, Chris Angelico wrote: Open for bikeshedding: What should the keyword be? We can't use exec, which would match Unix and shell usage, because it's already used in a rather different sense in Python. Current candidates: transfer, goto, recurse, and anything else you suggest. I propose the combination return from. Much better. I believe 'yield from' actually cuts out the middle frame containing yield from. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Friday, July 17, 2015 at 12:17:55 AM UTC-7, Antoon Pardon wrote: On 07/17/2015 01:46 AM, Chris Angelico wrote: Open for bikeshedding: What should the keyword be? We can't use exec, which would match Unix and shell usage, because it's already used in a rather different sense in Python. Current candidates: transfer, goto, recurse, and anything else you suggest. I propose the combination return from. I think it is similar enough with yield from to justify this and it also won't need an extra keyword, so no programs will be broken because they used transfer, goto or whatever other new keyword as an identifier. Should there be someone who is willing to spend time on this, I wish him all luck and strength he can find. I think it would be best if it was done by someone who is interrested in using this in his own programs. Because it is all very fine talking about the pro and cons here and I certainly would use it, the question is, how wide spread would the use become and is it worth the time and effort to introduce it. If future use turns out to be disappointing such a coder can at least think of it as something that was useful for himself. -- Antoon. return from or yield from looks too much like a COMEFROM instruction/statement. https://en.wikipedia.org/wiki/COMEFROM -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 07/17/2015 12:17 AM, Antoon Pardon wrote: On 07/17/2015 01:46 AM, Chris Angelico wrote: Open for bikeshedding: What should the keyword be? We can't use exec, which would match Unix and shell usage, because it's already used in a rather different sense in Python. Current candidates: transfer, goto, recurse, and anything else you suggest. I propose the combination return from. +1 -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
Chris Angelico ros...@gmail.com writes: # derived from Paul Rubin's example def quicksort(array, start, end): midp = partition(array, start, end) Heh, forgot to include the base case, as someone pointed out. Oh well, it's pseudocode, or something. transfer quicksort(array, midp+1, end) Overall I like the idea but though it doesn't seem terribly important in the scheme of things. I think the syntax has converged to return from which seems good to me. Note that this is incompatible with 'try' and 'with' blocks, and is Maybe something can be done about that. 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. Seems worthy of more thought. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 17Jul2015 20:43, Chris Angelico ros...@gmail.com wrote: On Fri, Jul 17, 2015 at 5:17 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: On 07/17/2015 01:46 AM, Chris Angelico wrote: Open for bikeshedding: What should the keyword be? We can't use exec, which would match Unix and shell usage, because it's already used in a rather different sense in Python. Current candidates: transfer, goto, recurse, and anything else you suggest. I propose the combination return from. I think it is similar enough with yield from to justify this and it also won't need an extra keyword, so no programs will be broken because they used transfer, goto or whatever other new keyword as an identifier. Oooh I like this. The parallel makes sense, and as you say, no new keyword. Yes, return from is my new preferred command! +1 Cheers, Cameron Simpson c...@zip.com.au A pessimist is an optimist in full possession of the facts. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On 07/16/2015 04:46 PM, Chris Angelico wrote: Examples: # derived from Paul Rubin's example def quicksort(array, start, end): midp = partition(array, start, end) if midp = (start+end)//2: quicksort(array, start, midp) transfer quicksort(array, midp+1, end) else: quicksort(array, midp+1, end) transfer quicksort(array, start, midp) def count_usage(func): @functools.wraps(func) def wrapper(*args, **kwargs): wrapper.usage += 1 transfer func(*args, **kwargs) wrapper.usage = 0 return wrapper Semantics: * Evaluate the function and all its arguments, exactly as per a current function call. * Leaving them on the stack, remove the current call frame and dispose of all its objects. * Finally, construct a new stack frame for the target function and transfer control to it. In effect, transfer f() is equivalent to return f(), except that the current function finishes before the target is entered. Sounds cool! Code it up and let us know how it goes. :) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
