Tim Peters writes:
Isn't this often implemented via a macro, though, so that
(let/cc name code)
"acts like"
(call/cc (lambda (name) code))
Yup, they're equivalent, in the sense that given one you can make a macro to do the other. call/cc is preferred because it doesn't require a new binding construct.
? 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.
Except that since the escape procedure is 'first-class' it can be stored away and invoked (and reinvoked) later. [that's all that 'first-class' means: a thing that can be stored in a variable, returned from a function, used as an argument, etc..] I've never seen a let/cc that wasn't full-blown, but it wouldn't surprise me.
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.
Many Scheme implementors either skip it, or only support non-escaping call/cc (i.e., exceptions in Python).
Would full-blown coroutines be powerful enough for your needs?
Yes, I think they would be. But I think with Python it's going to be just about as hard, either way. -Sam