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

*To*: "'Anton van Straaten'" <address@hidden>*Subject*: RE: Demystifying Continuations*From*: "David Simmons" <address@hidden>*Date*: Fri, 22 Mar 2002 13:39:37 -0800*Cc*: <address@hidden>*Importance*: Normal*In-reply-to*: <3C9B6BA8.7060904@appsolutions.com>*Sender*: 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 >

**Follow-Ups**:**RE: Demystifying Continuations***From:*"Anton van Straaten" <anton@appsolutions.com>

**References**:**Re: Demystifying Continuations***From:*Anton van Straaten <anton@appsolutions.com>

- Prev by Date:
**RE: Demystifying Continuations** - Next by Date:
**RE: Demystifying Continuations** - Previous by thread:
**Re: Demystifying Continuations** - Next by thread:
**RE: Demystifying Continuations** - Index(es):