[Christian Tismer]
... But on the general issues: Can the Python-calls-C and C-calls-Python problem just be solved by turning the whole VM state into a data structure, including a Python call stack which is independent? Maybe this has been mentioned already.
The problem is that when C calls Python, any notion of continuation has to include C's state too, else resuming the continuation won't return into C correctly. The C code that *implements* Python could be reworked to support this, but in the general case you've got some external C extension module calling into Python, and then Python hasn't a clue about its caller's state. I'm not a fan of continuations myself; coroutines can be implemented faithfully via threads (I posted a rather complete set of Python classes for that in the pre-DejaNews days, a bit more flexible than Icon's coroutines); and:
This would automagically produce ICON iterators (duck) and coroutines (cover).
Icon iterators/generators could be implemented today if anyone bothered (Majewski essentially implemented them back around '93 already, but seemed to lose interest when he realized it couldn't be extended to full continuations, because of C/Python stack intertwingling).
If I guess right, continuation passing could be done by just shifting tiny tuples around. Well, Tim, help me :-)
Python-calling-Python continuations should be easily doable in a "stackless" Python; the key ideas were already covered in this thread, I think. The thing that makes generators so much easier is that they always return directly to their caller, at the point of call; so no C frame can get stuck in the middle even under today's implementation; it just requires not deleting the generator's frame object, and adding an opcode to *resume* the frame's execution the next time the generator is called. Unlike as in Icon, it wouldn't even need to be tied to a funky notion of goal-directed evaluation. don't-try-to-traverse-a-tree-without-it-ly y'rs - tim