[Python-Dev] 'stackless' python?

[Tim Peters]

[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