[Mark Hammond]
Im a little unhappy as this [stackless Python] will break the Active Debugging stuff ... ... So the solution MS came up with was, surprise surprise, the machine stack! :-) The assumption is that all languages will make _some_ use of the stack, so they ask a language to report its "stack base address" and "stack size". Using this information, the debugger sorts into the correct call sequence.
Mark, you can't *really* believe Chris is incapable of hacking around this, right? It's not even clear there's something to be hacked around, since Python is only Python and there's nothing Christian can do to stop other languages that call into Python from using the machine stack, or to call other languages from Python without using the machine stack. So Python "shows up on the stack" no matter what, cross-language.
... Bit I also understand completely the silence on this issue. When the thread started, there was much discussion about exactly what the hell these continuation/coroutine thingies even were.
The Fuchs paper Sam referenced explained it in simple C terms: a continuation is exactly what C setjmp/longjmp would do if setjmp saved (& longjmp restored) the C stack *in addition* to the program counter and machine registers (which they already save/restore). That's all there is to it, at heart: objects capture data state, continuations capture control flow state. Whenever the OS services an interrupt and drops into kernel mode, it captures a continuation for user mode -- they don't *call* it that, but that's what they're doing, and it's as practical as a pencil (well, *more* practical, actually <wink>).
However, there were precious few real-world examples where they could be used.
Nobody asked for any before now <0.5 wink> -- and I see Sam provided some marvelous ones in response to this.
A few acedemic, theoretical places,
I think you undervalue those: people working on the underpinnings of languages strive very hard to come up with the simplest possible examples that don't throw away the core of the problem to be solved. That doesn't mean the theoreticians are too air-headed to understand "real world problems"; it's much more that, e.g., "if you can't compare the fringes of two trees cleanly, you can't possibly do anything harder than that cleanly either -- but if you can do this little bit cleanly, we have strong reason to believe there's a large class of difficult real problems you can also do cleanly". If you need a "practical" example of that, picture e.g. a structure-based diff engine for HTML source. Which are really trees defined by tags, and where text-based comparison can be useless (you don't care if "<LI>" moved from column 12 of line 16 to column 1 of line 17, but you care a lot if the *number* of <LI> tags changed -- so have you have to compare two trees *as* trees). But that's a problem easy enough for generators to solve cleanly. Knuth writes a large (for his books) elevator-simulation program to illustrate coroutines (which are more powerful than generators), and complains that he can't come up with a simpler example that illustrates any point worth making. And he's right! The "literature standard" text-manipulation example at the end of my coroutine module illustrates what Sam was talking about wrt writing straightforward "pull" algorithms for a "push" process, but even that one can be solved with simpler pipeline control flow. At least for *that*, nobody who ever used Unix would doubt the real-world utility of the pipeline model for a nanosecond <1e-9 wink>. If you want a coroutine example, go to a restaurant and order a meal. When you leave, glance back *real quick*. If everyone in the restaurant is dead, they were a meal-generating subroutine; but if they're still serving other customers, your meal-eating coroutine and their meal-generating coroutine worked to mutual benefit <wink>.
but the only real contender I have seen brought up was Medusa. There were certainly no clear examples of "as soon as we have this, I could change abc to take advantage, and this would give us the very cool xyz"
So, if anyone else if feeling at all like me about this issue, they are feeling all warm and fuzzy knowing that a few smart people are giving us the facility to do something we hope we never, ever have to do. :-)
Actually, you'll want to do it a lot <wink>. Christian & I have bantered about this a few times a year in pvt, usually motivated by some horrendous kludge posted to c.l.py to solve a problem that any Assistant Professor of Medieval English could solve without effort in Icon. The *uses* aren't esoteric at all. or-at-least-not-more-than-you-make-'em-ly y'rs - tim