[Andrew Koenig] > Especially because if we allocate such objects in the same way as we > allocate other objects, we no longer need to have an upper bound on the > number of such objects that can exist at one time. > > For that matter, perhaps we could make such objects explicitly accessible by > user programs. If we did that, of course, we would not want to restrict > such objects to the ones that correspond to tail calls--we might as well > create them for all calls. We might even make it possible to "call" such an > object, the effect of which would be to cause execution to continue from the > state it was in when that object was created. Gee, once we do that, we > don't need to keep that information around on the stack any more at all. > > I guess we need a catchy name for such objects. Because we can use them to > make execution continue from an arbitrary point, how about calling such an > object a "continuation?" <very big wink> Every sufficiently advanced implementation of Python will indeed reinvent Stackless, but continuations are a "don't go there" topic even for long-suffering Christian now <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4