Here I asked:
I get the feeling that it is important to understand continuations conceptually, and specifically not in terms of their implementation. The TSPL book, for example, does so; and I often see it quoted word for word in explanations of continuations. However, the number of articles that describe continuations in terms of the stack far outweigh explaining them conceptually. Does describing them in terms of their implementation serve as a disservice? Will it be an impediment later on?
Here was one reply:
Grant, you're correct in that an understanding of one particular implementation technique for a linguistic construct causes huge and ubiquitous misunderstandings. Procedures and procedure calls are the examples that come to mind. Those things were explained via a stack-based implementation in the 1950s and 1960s although [&] abstract explanations in terms of 8th grade algebra all the way to Lambda Calculus had been around for, oh, a while. [*] As a result, procedure calls had been considered expensive and a thing to be avoided. Steele pointed out our misunderstanding of this issue AND YET, to this day, people don't implement procedures and procedure calls properly and we are still suffering from this perception. People still write huge procedures to avoid another call, and people still want to see complete stack traces in their debuggers for their function calls. So the sentence labeled with [*] uses the incorrect tense. It should use "have been and are" instead. It is one sad state of affairs. Of course, this just refers back to the sentence with [&]: people who design and implement programming languages do not wish to study mathematical models of PLs, can't and won't. But they sure want credit on all fronts. That's why the problem is pervasive. Continuation objects in Scheme are special-purpose procedures. That is, they are procedural representations of the 'rest of the computation with respect to some expression evaluation.' So the story is related but fortunately (or whatever) doesn't have as much of an impact. Continuations aren't as useful as procedure. Yes, there are kids out there who think that if you don't implement continuations with fast code etc your Scheme implementation isn't worth much. But those are just mislead. Continuations can be implemented with at least four basic techniques that I can remember right now. Clinger et al (a nice scientific paper from the 80s revised in the 90s) lays out a beautiful and well- presented comparison of such techniques. I recommend reading it. And of course Dybvig/Hieb's lazy stack copy technique in the original paper. Of course in SML/NJ callcc = cons. So that's that. Continuations can be understood as all kinds of abstract beasts, with little more knowledge than 8th grade algebra or Lambda Calculus. But that is just an abstract form of 'how'. I have spent a good deal of time on this question. Finally, continuations can be understood from a 'pragmatic' perspective ('what are they useful for, and how are they used'). For this question, I recommend two books and a paper: -- Shriram's PLAI -- Friedman and Springers, "Art and Scheme" -- Friedman's POPL talk from 1988 on "Applications of Continuations" Good luck -- Matthias