On 2011/04/21 18:03, Colin Putney wrote:
> On Thu, Apr 21, 2011 at 9:01 AM, Matthew Fulmer<tapplek at gmail.com>  wrote:
>
>> I never did understand the functional difference between
>> continuations and suspended processes.
>
> It's true, they are very similar in that the state they contain is
> exactly the same. However, suspended process can only be resumed once,
> where a continuation can be evaluated more than once. Evaluating a
> continuation boils down to creating a suspended process, replacing the
> current process with it, and resuming.
>
>> Do you have any links to how partial continuations are useful?
>
> I think it just boils down to memory consumption. Everything you can
> do with partial continuations you can also do by composing full
> continuations.

Indeed. What's useful about partial continuations (as opposed to full 
ones) is precisely that they're _delimited_. That lets you divide your 
code into "kernel" and "user" spaces. With a full continuation, the 
captured call stack will capture part of the "kernel" calls, which is 
probably not desirable. Instead, when the user-space continuation makes 
a call to the kernel-space facilities, the kernel captures the delimited 
continuation, does its thing, and then resumes the continuation.

Kiselyov's and Shan's "Delimited continuations in operating systems" [1] 
makes the case that operating systems implicitly use partial 
continuations all over the place, even if it's never stated. Kiselyov 
says "Explicitly recognizing these uses of delimited continuations helps 
us design a system of concurrent, isolated transactions where desirable 
features such as snapshots, undo, copy-on-write, reconciliation, and 
interposition fall out by default. It also lets us take advantage of 
efficient implementation techniques from programming-language research."

As Colin mentions, partial continuations are also lighter weight than 
full ones, obviously, since they capture less. If you're doing heavy 
backtracking, that would quickly pay dividends, I suspect.

Of course in Smalltalk we have full continuations at our fingertips all 
the time, in the form of thisContext sender. (This is what allows 
Generator to have such a trivial implementation.) But using thisContext 
willy-nilly sounds like a Bad Idea(tm). What my library provides is a 
more structured way of using continuations.

(And I've already implemented delimited continuations in the form of 
zippers, so I had to balance things!)

For more papers on continuations (and dynamic binding, and the 
interactions between the two) than you can shake a stick at: 
http://okmij.org/ftp/continuations/

frank

[1] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.8610&rep=rep1&type=pdf