Diana Shannon wrote: > > On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote: > >> Feel free to ask if you need further clarification about my integration >> proposal. > > > What *I'm* most interested in is a statement you made a while ago on > this list about the difficulties students can have learning about > continuations, from your direct experience teaching continuations.
Why are continuations difficult? -------------------------------- Continuations are a little bit like "goto on steroids". They are used in the study of denotional semantics which is a subarea of theoretical computer science. The aim of denotional semantics, is to describe (and prove properties of) programming constructs in terms of a very small functional language, (lambda calculus) that includes continuations. Continuations are extremely powerfull; program language constructs like assignement, goto, while, for-loops, throw-catch and coroutines to name a few can be defined in terms of a terse and cryptic, (but elegant, if you happen to like mathematical puzzles ;) functional program. Some functional program langages, Scheme e.g. have continuations. A good use for continuations in such languages is to use them together with macros to define new language constructions. You can also use them for building a more intelectually demanding form of spagetti code ;) Why can continuation based code be difficult to grasp? Even if most of us might not remember it anymore, learning to understand and use even the simplest programming language construct required a considerable effort once, allowing ad hoc introduction of new constructs forces us to repeat this effort often. Continuations forces us to think about the whole state of the program rather than about state changes. Continuations introduces non-local effects in the code, non-local effects are the main reason why gotos and exception handling can be hard to follow. Flowmaps and continuations -------------------------- In Flowmaps, continuations are used for implementing something quite similar to coroutines. > Do you have any suggestions for the doc effort in this regard? Focus on the coroutine aspect of the flowmaps, it is fairly easy to understand, while general use of continuations just isn't. For the flowmap user, the fact that flowmaps are implemented in terms of continuations should be of very limited importance otherwise we have a severe mix of concerns in the design. I strongly sugests that we should _not_ make general use of continuations available in the flowmap language as there is no need for it for what flowmaps are intended to do: describing multipage flow in webapps. > In what > aspects do students have problems: understanding the concept, applying > them to real-world situations, etc.? I've read up on continuations, > generally, but so many existing docs are tied to Scheme implementations > (which could frighten users, as has also been discussed). Can you point > to any existing teaching resources that you use? Care to donate anything > of your own, even a teaching outline? Any tips? I tought denotatinal semantics, and the literature in that area is even more frightening than the Scheme literature;) IMO we would make the effort to use flowmaps to high if we require people to learn continuations. I belive that it should be enough to teach about the coroutine like control structure, that happen to be implemented in terms of continuations. If it's not possible I think that is important feedback on that we have to work more on the basic concepts in the flowmap. I have a long unfinished RT where I compare FSM:s with the basics concepts in the Flowmap proposal and develop the coroutine analog a bit further. I'll check if it is in a comprehensible state and, if so, I'll send it to you. I would also like to remind about some mails I wrote a couple of months ago where I explain why it's IMO is FS or even harmfull to allow local variables in the flowmap language: see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101861458122598&w=2 and some other mails in the "continuation fear" thread. /Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
