RE: Demystifying Continuations

["David Simmons" <address@hidden>]

> -----Original Message-----
> From: Anton van Straaten [mailto:anton@appsolutions.com]
> Sent: Friday, March 22, 2002 9:37 AM
> To: David Simmons
> Cc: ll1-discuss@ai.mit.edu
> Subject: Re: Demystifying Continuations
> 
> Dave S.,
> 
> Your reply to me included a number of statements like this:
> 
> 	"explaining it in basic terms"
> 	"how they actually worked"
> 	"how they truly work -- in layman's terms"
> 	"understand the first principles upon which an
> 	 abstraction's semantics are made manifest."
> 
> Implicit in all this is your particular focus on wanting to know how
> continuations are implemented, or to put it more generally, you want
to
> understand the semantics of continuations by translating them from one
> model to another model that you're particularly interested in.  Your
> "basic terms", "actual", "truly", and "first principles" are all
> references to a particular model which you're axiomatizing as most
basic,
> actual, and true.
> 
> But one can define continuations mathematically without resorting to
the
> kind of explanation you want.
> Guy really hit the nail on the head here - as an implementor of a
certain
> type of language, you're steeped in ideas like reifiable cloneable
> contexts, and that's the model that you want to translate
continuations
> into.  

Anton,

Perhaps I misunderstood his humor. I thought he was alluding to the fact
the the terms I used were, in and of themselves, non-trivial concepts.
Which in turn meant that my using those terms to explain continuations
was perhaps no simpler or easier to understand than "explanations" I had
complained about in my original missive.

> However, this isn't necessarily going to make for a wonderfully
> clear explanation for a broader audience, which is probably why most
> discussions of continuations don't go there.  Implementing
continuations
> is very different thing from understanding how to use them and even
"how
> they actually work" (depending on your definition of "actually").
> 
> (BTW, papers on implementing continuations do exist - someone's
already
> mentioned Clinger et al, "Implementation strategies for
continuations".)
> 
> > 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.
> 
> That's also the reason I suggested studying them in a purer
environment.
> Otherwise, I think you run the risk of confusing characteristics of
the
> abstraction with implementation concerns.  It's possible that what you
see
> as nebulous and unclear is simply non-trivial to translate into your
> favored model.
> 
> > 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"
> 
> Why they are wonderful is easy. :)  Continuations provide a high-level
> mathematical abstraction for control flow.  An abstraction which,
despite
> any appearances to the contrary, is actually quite simple compared to
most
> alternatives.  If there's a nirvana that you're missing, it may exist
on
> the other side of the mathematical fence, i.e. you're concerned with
> implementing first-class continuations in a programming language, but
> there *is* more to continuations than that specific set of concerns.
> 
> And again, that's why studying them in a continuation-oriented
environment
> can be helpful.  Can a C programmer who's never used an OO language
really
> grok objects by implementing them within his programs?  Maybe, but it
sure
> seems like the hard way to do it.

All in all, I find myself needing to disagree with you. I take the view
more of a physicist wanting to know the first principles and build the
ideas from there. That gives me much more latitude to explore new ideas
and understand what is possible. It is the same approach that has
allowed me to build a Smalltalk architecture that was richer than the
classic Smalltalk-80 designs that had preceded it.

You're suggestion of observing them in a "continuation-oriented"
environment and viewing continuations from a mathematical viewpoint
doesn't provide that -- and it means I need to examine multiple
continuation-oriented implementations to assure that I've covered
possible variances. Although, to one degree or another, the mathematical
definition can be mapped by "me" onto a physical-world computing model.
However, I want to understand the general practice solutions to that
mapping so that I provide the same kind of "compromise" behavior or at
least remain consistent with the intent of other implementations.

I.e., It means I need to observe their behavior to understand their
actual nature (as they would execute/perform within a given language
execution environment -- which makes it unclear where they would fail
and what there true (as they would run) invariants are. This is not
precise -- and it is the problem with an observational or an idealistic
mathematical model of a continuation. What I am looking for is a
computational model that discusses the physical-world constraints of
cpu/ram/thread/os computing machinery. 

I am trying to minimize/avoid having to make a study of this involving
carefully designed experiments on different continuation-calling
systems. I want to go beyond the observational level. In addition, I
want to go-beyond the mathematical level to understanding the
design-thinking that has gone into the implementation compromise
decisions that are typically involved in mapping the mathematical
definition to a physical-world system. [<g> There are many paths to a
deeper understanding of this kind of problem -- eventually the
mathematical definition is the archetype, it is just not my ideal
Rosetta Stone].

For me, the shortest path is to begin with physical-world first
principle explanations for a physical-world constrained system design.
>From where I was, before receiving these posts/responses, I could have
continued to ferret through abstracted definitions, but, as I was
observing, this resulted in ambiguous implementation solutions. Which
left me with unresolved ambiguity questions regarding best/preferred
practice solutions.

OTOH, the various responses I have received from people include a
significant number of papers and other references which I now need to
follow up on. And there are also some additional explanations/references
regarding the R5RS semantics of continuations (which I was not aware
of).

P.S., Everyone has been providing helpful e-mail and thread-post
responses. I really appreciate it...

Thanks,

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

> 
> Anton
>