Understanding Continuations

["Peter J. Wasilko, Esq." <address@hidden>]

Greetings All,

Looking over the continuations threads, I think a large part of the
difficulty people have approaching the concept stems from confusion of
which level of abstraction is being discussed.

The programmer-user-of-continuations level is primarily address in
Scheme texts with Scheme and the Art of Programming providing one of the
most accessible.

But when the question of their implementation is considered there seem
to be two fairly divergent perspectives.

On the one hand, EOPL spends a lot of time talking about code
transformations on interpreters so languages supporting first class
continuations can be defined in languages without such functionality.

Then one sees a completely different set of issues in discussions of
directly supporting continuations with heap allocated structures and
chip level stack manipulation.

What would be nice would be something that tries to bridge these two
views and tie them together. I don't think most
would-be-language-implementors are comfortable with the idea of
preforming CPS transformations on user supplied code, so we would want
to incorporate direct call/cc language level functionality in our
interpreters. EOPL seems to downplay this issue (at least in its first
edition, where the most interesting questions are relegated exercises
for the reader) and focus more on the implementation of less expressive
languages that can be implemented with a more purely stack-oriented
discipline.

[IMHO, trying to put data, context, and control on the same stack is an
invitation for disaster that leads to security nightmares as evidence in
the C/C++ world of buffer overflow exploits.]

A similar gaps seems to exist in the literature surrounding coroutines
and engines where there isn't a clear enough exposition of how to
achieve preemptive multitasking using continuations(as opposed to
co-operative multitasking in which user code explicitly captures a
continuation while yielding control to the executive, as in the many
examples of the Same Fringe problem).

There is the whole question of how much state gets captured by the
continuation and what happens if bindings change behind the scenes (ie.
should an implicit dynamic wind facility be in place as the default
state of affairs when ever continuations are exposed in the defined
language).

And finally, the issues of what if anything in terms of control flow
can't be accomplished using continuations, and what more restrictive
variants of continuations can be employed in their stead.

In the face of these gaps between papers, some days it feels like the
more I read about continuations the further I get from developing a true
understanding of their mysteries.

If only there were a "Tao of Continuations" that would weave together
all of these threads in a coherent fashion.

Warmest Regards,

Peter


_________________________________________________________________

Peter J. Wasilko, Esq.
     J.D., LL.M.               

Executive Director, The Institute for End User Computing, Inc.

Visit us on the web at: http://www.ieuc.org

_________________________________________________________________

Its time to abandon brittle architectures with poorly factored
interfaces, gratuitous complexity, and kludged designs dominated
by sacrifices on the altar of backwards compatibility.

Such artifacts are vulnerable to cyber-attack, weigh down the
economy costing trillions of dollars in lost productivity, and
suffer from an impoverished conceptual model that lacks the
integration and elegance needed to empower end users to
get the most from advanced applications in the future.

_________________________________________________________________
The Institute for End User Computing --- Pursuing Secure, Simple, 
   Supple, & Sophisticated Systems to Unlock Our Human Potential
_________________________________________________________________

* The Institute is incorporated under New York State's
   Not-For-Profit Corporation Law