RE: Demystifying Continuations

["David Simmons" <address@hidden>]

> -----Original Message-----
> From: Anton van Straaten [mailto:anton@appsolutions.com]
> Sent: Thursday, March 21, 2002 9:14 PM
> To: David Simmons
> Cc: ll1-discuss@ai.mit.edu
> Subject: Re: Demystifying Continuations
> 
> David Simmons wrote:
> 
> > ...continuations seem to be a very simple
> > concept that is much more easily understood in terms of stacks,
> > call-chains, and frames (activation-records/contexts).
> 
> It is a simple enough concept (although its applications can be
complex),
> but I think continuations are more easily understood in the terms you
> describe, only if those are the terms in which you already think.
> 
> As an abstraction, continuations provide real advantages.  Try to
describe
> the things you can do with continuations in terms of
> stacks/callchains/contexts - I think you'll find that the continuation
> description will be simpler every time.  That's why they're used in
> computing science - they're a more powerful abstraction, which leads
to
> more concise descriptions.
> 
> However, you seem to be talking more about how continuations can be
> implemented, than about how they're used. If you're implementing
> continuations, then your stacks/callchains/contexts are perfectly
valid
> (and common) implementation strategies.
> 
> Thinking about high-level concepts in terms of their implementations
can
> be quite misleading, though.  For example, saying that "objects can be
> understood as arrays associated with a hashtable of functions" may
have
> some technical validity, but it misses important aspects of the bigger
> picture.  To see the advantages of continuations, you have to operate
at
> the level at which they provide an advantage.

Fist, let me say thanks for taking the time to respond to my post. Now,
on to the meat...

I certainly agree with importance of abstraction. I just found that much
of the literature which described a continuation was "apparently"
written by people who were not very good at explaining it in basic terms
[without resorting to tautologies], or were not themselves precisely
clear how they actually worked (what their semantics were). 

In other words, explaining it so obliquely as to tell little or nothing
at all about how they truly work -- in layman's terms. The "concepts" of
activation records and call-chains are not an implementation technique
they are a description of the semantics. A push/pop frame-stack would be
"an" implementation mechanism for activation-records/contexts, but there
are (as you seem to well understand) other approaches that have
classically been used. In most Smalltalk VM's a hybrid combination of
approaches is often used with dynamic morphing between stack-frames and
real-context-objects.

> 
> I think the best way to appreciate continuations is to forget about
> implementations and play with them in a pure functional environment,
like
> lambda calculus or a Scheme subset.  Like any exotic creature, they
tend
> to make more sense in their native habitat...

I disagree. Abstractions are crucial to enabling one to manage
complexity which free's one to think and design at a higher level from a
different vantage point. Nevertheless, it is equally important to
understand the first principles upon which an abstraction's semantics
are made manifest. Without understanding the abstraction itself [and its
possible implementation constraints or characteristics], one can easily
fall prey to bogus patterns of analysis, design, and layered
implementation.

In any case, ignoring the philosophy, my interest was in understanding
the semantics. The implementation approaches allow me to see through the
apparently nebulous/unclear explanations of continuations so that I can
observe and extract their true semantics. From there, I can properly
reconstruct an abstraction that corresponds to the semantics exhibited
by various implementations.

I had long thought that I understood continuations (based soley on the
abstracted descriptions sans the implementation knowledge). I had then
projected my knowledge of implementation techniques for closures and
activation-records/contexts to help me understand how one might
implement a continuation. 

However, in going further and asking various people and reading the
literature I was given the impression that I was completely missing some
level of understanding/nirvana regarding continuations. To be honest, I
do not see why they are so "wonderful" -- keeping in mind that I am far
and away from being limited in my background/experience to an
algol/C/Pascal static language perspective of computing models. 

If my understanding of continuations is correct, then I think a general
context mechanism provides the same capabilities and with first-class
notions of threads it goes further for incorporating other host-OS
notions and inter-operability. But maybe I am just jaded, or maybe I am
still not getting the special character of a continuation.

-- Dave S. [www.smallscript.org]

> 
> Anton
>