[Sam]
Continuations are more powerful than coroutines, though I admit they're a bit esoteric.
[Tim]
"More powerful" is a tedious argument you should always avoid <wink>.
[Sam]
More powerful in the sense that you can use continuations to build lots of different control structures (coroutines, backtracking, exceptions), but not vice versa.
"More powerful" is a tedious argument you should always avoid <frown -- I'm not touching this, but you can fight it out now with Aaron et alia <wink>>.
Then the continuation would (eventually) "return to" the "print repr(saved)" and we'd get an infinite output tail [...] and never reach line 4. Right?
Yes... the continuation object so far isn't very usable.
But it's proper behavior for a continuation all the same! So this aspect shouldn't be "fixed".
... let/cc stores the continuation in a variable binding, while introducing a new scope. It requires a change to the underlying language:
Isn't this often implemented via a macro, though, so that (let/cc name code) "acts like" (call/cc (lambda (name) code)) ? I haven't used a Scheme with native let/cc, but poking around it appears that the real intent is to support exception-style function exits with a mechanism cheaper than 1st-class continuations: twice saw the let/cc object (the thingie bound to "name") defined as being invalid the instant after "code" returns, so it's an "up the call stack" gimmick. That doesn't sound powerful enough for what you're after.
[nice let/cc call/cc tutorialette] ... In order to do useful work like passing values back and forth between coroutines, we have to have some way of returning a value from the continuation when it is reinvoked.
Somehow, I suspect that's the least of our problems <0.5 wink>. If continuations are in Python's future, though, I agree with the need as stated.
I should emphasize that most folks will never see call/cc 'in the raw', it will usually have some nice wrapper around to implement whatever construct is needed.
Python already has well-developed exception and thread facilities, so it's hard to make a case for continuations as a catch-all implementation mechanism. That may be the rub here: while any number of things *can* be implementated via continuations, I think very few *need* to be implemented that way, and full-blown continuations aren't easy to implement efficiently & portably. The Icon language was particularly concerned with backtracking searches, and came up with generators as another clearer/cheaper implementation technique. When it went on to full-blown coroutines, it's hard to say whether continuations would have been a better approach. But the coroutine implementation it has is sluggish and buggy and hard to port, so I doubt they could have done noticeably worse. Would full-blown coroutines be powerful enough for your needs? assuming-the-practical-defn-of-"powerful-enough"-ly y'rs - tim