Anonymous blocks: Thunks or iterators?

Brian Sabbey:
It is possible to implement thunks without them creating their own frame. They can reuse the frame of the surrounding function ...
Michael Hudson:
Woo. That's cute.
It *sounds* horrendous, but is actually pretty reasonable. Conceptually, a thunk replaces a suite in the caller. Most frame members are intended to be shared, and changes should be visible -- so they don't have to (and shouldn't) be restored. The only members that need special attention are (f_code, f_lasti) and possibly (f_blockstack, f_iblock). (f_code, f_lasti) would need to be replaced with a stack of pairs. Finishing a code string would mean popping this stack, rather than popping the whole frame. Since a completed suite leaves the blockstack where it started, (f_blockstack, f_iblock) *can* be ignored, though debugging and CO_MAXBLOCKS both *suggest* replacing the pair with a stack of pairs. -jJ

Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti) and possibly (f_blockstack, f_iblock).
You don't even need to take care of f_code. The thunk and its surrounding function can share the same code. The thunk gets compiled into the function the same way the body of a for loop would.
There doesn't need to be a stack; each thunk can store its own f_lasti. One also needs to store f_back, and, to avoid exception weirdness, f_exc_XXX. In this way, calling the thunk is much like resuming a generator. -Brian

On 4/29/05, Brian Sabbey <sabbey@u.washington.edu> wrote:
Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti) and possibly (f_blockstack, f_iblock).
This only works if you already know what the thunk's code will be when you compile the function. (Just splicing it in messes up jump targets.)
One also needs to store f_back, and, to avoid exception weirdness, f_exc_XXX.
f_back lists the previous stack frame (which shouldn't change during a thunk[1]), and f_exc_XXX is for the most recent exception -- I don't see any reason to treat thunks differently from loop bodies in that regard. [1] If the thunk calls another function (that needs its own frame), then that is handled the same as any regular function call. -jJ

On 29 apr 2005, at 20.10, Brian Sabbey wrote:
This seems really, truly, nasty! Wouldn't this require you to check the source code of the function you want to integrate your thunk into to avoid namespace collisions? Well, no, not to avoid collisions I guess, if it's truly regarded as part of the function. But this means it would use the function's global namespace, etc. You'd be unable to use anything from the scopes in which the thunk is defined, which makes it really, really ... wierd. Or have I not gotten it? //Simon

Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti) and possibly (f_blockstack, f_iblock).
You don't even need to take care of f_code. The thunk and its surrounding function can share the same code. The thunk gets compiled into the function the same way the body of a for loop would.
There doesn't need to be a stack; each thunk can store its own f_lasti. One also needs to store f_back, and, to avoid exception weirdness, f_exc_XXX. In this way, calling the thunk is much like resuming a generator. -Brian

On 4/29/05, Brian Sabbey <sabbey@u.washington.edu> wrote:
Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti) and possibly (f_blockstack, f_iblock).
This only works if you already know what the thunk's code will be when you compile the function. (Just splicing it in messes up jump targets.)
One also needs to store f_back, and, to avoid exception weirdness, f_exc_XXX.
f_back lists the previous stack frame (which shouldn't change during a thunk[1]), and f_exc_XXX is for the most recent exception -- I don't see any reason to treat thunks differently from loop bodies in that regard. [1] If the thunk calls another function (that needs its own frame), then that is handled the same as any regular function call. -jJ

On 29 apr 2005, at 20.10, Brian Sabbey wrote:
This seems really, truly, nasty! Wouldn't this require you to check the source code of the function you want to integrate your thunk into to avoid namespace collisions? Well, no, not to avoid collisions I guess, if it's truly regarded as part of the function. But this means it would use the function's global namespace, etc. You'd be unable to use anything from the scopes in which the thunk is defined, which makes it really, really ... wierd. Or have I not gotten it? //Simon
participants (3)
-
Brian Sabbey
-
Jim Jewett
-
Simon Percivall