[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Continuations with pictures
I hope that at least some of you can indulge my ignorance,
but although I've read several explanations of continuations
I haven't been able to grasp the idea.
So here is a picture -- maybe you can tell me what's wrong
Two nights ago my six-year-old daughter's room was such
a mess that it was difficult to walk through it. Suddenly,
on a whim, she cleaned the place to perfection. I was
Last night two of her friends came over, and at the time
they left, the room was in worse disorder than before.
Now, can we say that if I'd taken a very comprensive
photo of the room when it was clean -- would that be
analogous to a continuation? With that photo, I could
go into the mess and put things back the way they were
at the moment the photo was taken. I could take the
junk out of the bookcase and put the books back into
their original order (the bookcase represents the stack).
Certainly if any global variables were altered (writing on
the wall, pictures broken, etc.) they would remain
in their altered state.
As far as temporary variables (represented by drawings
scattered on the floor), I could keep or destroy them
as I pleased.
AND if I'd taken a photo of the mess, I could go back to
*that* state, although the temporary variables would
be missing, and the globals would be in whatever
state they happened to find themselves.
However, this "going back" is not like time travel. It's
a sort of reset, like in TV shows where you find out
that "it was all just a dream" at the end and that
nothing has changed at all.
Are these good analogies?
So I can understand one could pass a continuation
as a sort of snapshot, and tell another function
"go to the place in this picture when you're done."
But the statement that continuations are "the rest
of the program" is at variance with this. Is there
a difference between future continuations (program
states yet to be reached) and past continuations
(a state we can return to)? Is a continuation ever
as simple as an address on the instruction stack?
Kevin Kelleher <firstname.lastname@example.org>