[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Abstracting continuations



Michael St. Hippolyte wrote:

> I think I need to rephrase my question... I understand how to define
> a continuation by taking a snapshot of the relevant program state at
> a particular point in the running of the program.  What I'm curious
> about is whether there are any languages that let you define a
> continuation without actually having to run the program to that
> point first.

You are right that continuations only let you revisit past points, not
jump to future points.  If a language did let you do that, what you
would have would not be a *continuation*.  BASIC labels are a good
example of this.

Indeed, I find it confusing to explain continuations to beginners as
being "like labels" (or as being "first-class labels", as I've
sometimes also heard them described), because the listener imagines
precisely the kind of scenario you mention, which of course you don't
get with continuations.  Indeed, I was one such confused novice myself.

While there are many control constructs in the continuation family,
I'm not aware of anything that is more powerful than a label that lets
you travel forward in time.

> But I can imagine a more robust sort of label which specifies not
> just a program location but all the rest of the things that a
> continuation needs to know.  Does any such construct exist?

There are four things: program counter, stack, environment, and store.
The operation presumably takes care of the program counter.  The store
is anyway not part of the continuation.  So your construct would have
to create the environment that isn't already there because you haven't
already been to that point of execution yet, then sume [*] execution.
You would have some flexibility re. the stack, but not much, for
fairly obvious reasons ...

Shriram

[*] "sume" = "resume" minus the "re".