Sigh. I'm 43 years old and only really grasped closures this January. It's going to take another ten years for my continuation epiphany.
This is what happens when you start with BASIC.
This is what happens when you start with BASIC.
Are you familiar with setjmp/longjmp in C? Continuations are similar, but allow longjmp-ing to the same point multiple times. As you might expect, this gives you a lot of flexibility in defining control constructs.
You can implement exceptions easily via continuations - pass along an alternative continuation to receive errors. Continuations are more general than exceptions, backtracking, co-routining, etc., but this generality can make them seem overly abstract - it can be hard to see what those constructs have in common.
Hey, and don't worry - I started with BASIC too. (I was five or six.) You gotta start somewhere. After you feel comfortable with continuations, try learning about unification. :)
Yes, unfortunately continuations don't play nice with lazy evaluation.
I have found a discussion about this http://lambda-the-ultimate.org/classic/message10560.html
Also: I envy you your starting at 5 or 6. My parents unfortunately couldn't afford the PDP-11 that would have required in my case.
Anyway, my point was that Dijkstra's just being a grouchypants when he says that BASIC permanently ruins people's minds for programming. Not even C++ could do that.
When you call it with an argument x, what happens is what would have happened if x was the return value of the expression at the point where the continuation was created.
Just like closures; I knew more or less what they were - but this January I ran into my first situation where I really, truly saw how they made a particular situation easier - like, easier in a way that nothing else did - and since then I can't live without closures. That insight suddenly reorganized everything I thought I knew about programming.
I'm still waiting for that to happen with continuations.
Also, the first edition of _Essentials of Programming Languages_ has a great chapter on turning an interpreter into a compiler using continuations (Chapter 12). I hear it got cut from later editions, though.
(Actually, I'm already designing my own language for fun, but it compiles to Perl, so continuations are still not really on the table.)
The epiphany was twofold. First, I realized that passing an anonymous function pointer to a queue is a lot more general than defining, say, a bunch of event names. This makes the design of the event queue really lightweight.
The second part of the epiphany was that anonymous function pointers in Perl are closures, with lexical bindings to the environment at the time the pointer is created. So my event queue reduced to a simple list of times and closures - magic! Events are entirely general and you can spin off just the event queue logic as a separate module without restricting any later options about what types of event you'll be queuing. It was probably the most satisfying programming I'd done in a decade.
I should note that I stopped doing programming for my bread and butter in 2003 or 2004, and switched to technical translation instead (easy to quote, no debugging, no disputes about what was done or whether it met the user's expectations - it's like programming for hire without any of the downsides!) So I program for fun and to build my own tools, with the result that a month or two may go by without my writing much of anything. That's lots of time for the subconscious to reorganize between exposures, so essentially I'm relearning programming a couple of times a year. Lately I think I'm getting kind of good at it.
I would suggest that you learn some basic Scheme, download an interpreter, and just play around with it. Try a few things with call-with-current-continuation. Try to figure out the examples on Wikipedia. It'll might take a few hours of toying with it over a few days, but you'll get it. Don't be discouraged :)
What I need - and what I suspect will take a lot longer - is an actual situation where continuations solve some problem I've encountered. That's when I'll get them, but not earlier, in my experience.