Re: Continuations for fun and profit
On Mon, 8 Jul 2002, [EMAIL PROTECTED] wrote: 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. :) I've always thought that a language that implemented FREEZE() and THAW() blocks would be very cool indeed. Java's EJB persistence is extremely useful, but there you always need the safety webbing of a container. I'm pretty sure that if we could save the state of everything else on the interpreter level, people won't mind losing and having to reestablish OS-level resources. At least I wouldn't. Currently I have to do twice as much work to resume execution anyhow. Sorry if this has been duly dissected before, I just thought in the context of continuations it would be a worthwhile side avenue. Ted
Re: Continuations for fun and profit
On Mon, 8 Jul 2002 16:54:16 -0400, Dan Sugalski wrote:
while ($foo) {
$foo--;
}
Pretty simple. (For illustrative purposes) To do that with
continuations, it'd look like:
$cont = take_continuation();
if ($foo) {
$foo--;
invoke($cont);
}
When you invoke a continuation you put the call scratchpads and lexical
scratchpads back to the state they were when you took the continuation.
If you restore the lexicals, how does this ever finish?
--
Peter Haworth [EMAIL PROTECTED]
It's not a can of worms, it's a tank of shai-hulud.
-- Jarkko Hietaniemi
Re: Continuations for fun and profit
On Tue, 9 Jul 2002 16:42:03 +0100, Peter Haworth wrote: When you invoke a continuation you put the call scratchpads and lexical scratchpads back to the state they were when you took the continuation. If you restore the lexicals, how does this ever finish? Never mind. It's the *access* to the lexicals, not their values. -- Peter Haworth [EMAIL PROTECTED] Would you like ambiguity or something else? Press any key to continue or any other key to quit
Continuations for fun and profit
Okay, for those of you following along at home, here's a quick
rundown of what a continuation is, and how it works. (This is made
phenomenally easier by the fact that perl has continations--try
explaining this to someone used to allocating local variables on the
system stack and get ready for frustration)
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.
The nice thing about continuations is you can do all the known
control-flow operations (with perhaps the exception of a forward
goto) with them, and you can use them to build new control flow
structures. For example, let's take the while construct:
while ($foo) {
$foo--;
}
Pretty simple. (For illustrative purposes) To do that with
continuations, it'd look like:
$cont = take_continuation();
if ($foo) {
$foo--;
invoke($cont);
}
take_continuation() returns a continuation for the current point (or
it could return one for the start of the next statement--either
works), and invoke takes a continuation and invokes it. When you
invoke a continuation you put the call scratchpads and lexical
scratchpads back to the state they were when you took the
continuation.
Presto--instant while loop. You can do for loops in a similar way, as
well as any number of other control structures.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Continuations for fun and profit
On Mon, 8 Jul 2002, Dan Sugalski wrote:
Pretty simple. (For illustrative purposes) To do that with
continuations, it'd look like:
$cont = take_continuation();
if ($foo) {
$foo--;
invoke($cont);
}
take_continuation() returns a continuation for the current point (or it
could return one for the start of the next statement--either works),
I think starting at the next statement would be cooler in some ways:
$cont = take_continuation() and start_async_op($cont) and return;
# do other stuff with results of async_op
- D
[EMAIL PROTECTED]
Re: Continuations for fun and profit
On Mon, Jul 08, 2002 at 04:54:16PM -0400, Dan Sugalski wrote:
Pretty simple. (For illustrative purposes) To do that with
continuations, it'd look like:
$cont = take_continuation();
if ($foo) {
$foo--;
invoke($cont);
}
take_continuation() returns a continuation for the current point (or
it could return one for the start of the next statement--either
works), and invoke takes a continuation and invokes it. When you
invoke a continuation you put the call scratchpads and lexical
scratchpads back to the state they were when you took the
continuation.
So take_continuation is called once and returns 1 or more times?
(1st return is just after you called it, second and later are for each time
you invoke $cont from somewhere else)
and invoke is goto-on-steroids, and never returns? (except if $cont is duff,
somewhat like the exec system call in Unix only returns on failure)
And everything else is serene and swan-like?
(ie the language gives the appearance of moving smoothly on the surface,
but under water its feet are paddling furiously to implement motion)
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Continuations for fun and profit
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. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/
Re: Continuations for fun and profit
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
Re: Continuations for fun and profit
At 10:24 PM +0100 7/8/02, Nicholas Clark wrote:
On Mon, Jul 08, 2002 at 04:54:16PM -0400, Dan Sugalski wrote:
Pretty simple. (For illustrative purposes) To do that with
continuations, it'd look like:
$cont = take_continuation();
if ($foo) {
$foo--;
invoke($cont);
}
take_continuation() returns a continuation for the current point (or
it could return one for the start of the next statement--either
works), and invoke takes a continuation and invokes it. When you
invoke a continuation you put the call scratchpads and lexical
scratchpads back to the state they were when you took the
continuation.
So take_continuation is called once and returns 1 or more times?
(1st return is just after you called it, second and later are for each time
you invoke $cont from somewhere else)
Yes, Though we could certainly set it up so that $cont represented
the state of the program immediately *after* the statement that
created the continuation.
and invoke is goto-on-steroids, and never returns? (except if $cont is duff,
somewhat like the exec system call in Unix only returns on failure)
More or less, yes.
And everything else is serene and swan-like?
(ie the language gives the appearance of moving smoothly on the surface,
but under water its feet are paddling furiously to implement motion)
I see you've peeked behind the curtain. :)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Continuations for fun and profit
Thus it was written in the epistle of Peter Scott, 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. I think that that would be true only if *all* data was maintained in those scratchpads which are related to the continuation. It doesn't just save all data generally or $foo (from the example) would never really get decremented. Ted -- Ted Ashton ([EMAIL PROTECTED]) | From the Tom Swifty collection: Southern Adventist University| The bank doesn't even want me as a Deep thought to be found at | depositor, said Tom unaccountably. http://www.southern.edu/~ashted |
