At 3:01 PM -0700 7/8/02, Peter Scott wrote:
>At 04:54 PM 7/8/02 -0400, Dan Sugalski wrote:
>>A continuation is a sort of super-closure. Like a closure it
>>captures its lexical variables, so every time you use it, you're
>>referring to the same set of variables, which live on until the
>>continuation's destroyed. This works because the variables for a
>>block are kept in a scratchpad--since each block has its own, and
>>each scratchpad's mostly independent (mostly).
>>
>>Now, imagine what would happen if the 'stack', which we track block
>>entries, exits, sub calls, and so forth, was *also* done with a
>>linked list of scratchpads, rather than as a real stack. You could
>>have a sort of "super closure" that both remembered all your
>>scratchpads *and* your spot in the call tree. That, essentially, is
>>what a continuation is. We remember the scratchpads with variables
>>in them *and* the scratchpads with stack information in them.
>>
>>When we invoke a continuation, we put in place both the variables
>>and call scratchpads, making it, in effect, as if we'd never really
>>left the spot we took the continuation at. And, like normal
>>closures, we can do this from wherever we like in the program.
>
>So if you could serialize a continuation, you could freeze your
>program state to disk and restore it later? Cool, makes for easy
>checkpoint/restarts.
Yep. But serializing continuations is either tough, or not completely
doable, since programs tend to have handles on things outside their
direct control like filehandles, sockets, database connections, and
suchlike things. Resuming a continuation that's been frozen but also
has an open DB handle is... an interesting problem. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
