Why Are Continuations So Confusing, and What Do They Really Do?

His hypothetical continuations don't quite work.<p><pre><code> theSite = mark(); puts "Hello, World!" theSite.return(); </code></pre> This is the first example in the post, and one which it's claimed will loop continually. Translating to Scheme (where we can actually run the pseudo-code):<p><pre><code> (begin (define theSite #f) (set! theSite (call/cc (lambda (c) c))) (print "Hello, World!") (newline) (theSite #f)) </code></pre> And we get:<p><pre><code> &#62; (begin (define theSite #f) (set! theSite (call/cc (lambda (c) c))) (print "Hello, World!") (newline) (theSite #f)) "Hello, World!" "Hello, World!" procedure application: expected procedure, given: #f; arguments were: #f </code></pre> This translation to Scheme seems fair, since the definition of mark() explicitly states that it "allows you to pass information back to the original site, so that it evaluates to a different value" -- which means that the return value of mark() itself is clearly significant, and therefore that the step of "set theSite to the result of evaluating the current form" is considered part of the continuation (or "mark").<p>In this case, theSite gets set to #f, and the continuation is then "broken".<p>It might seem tedious to nitpick here, but continuations are so mysterious exactly because of these issues. mark() _can't be fixed_ without drastically changing the semantics of continuations. This is kinda non-obvious, and something that people often discover suddenly when wondering why call/cc is implemented in such a roundabout fashion.<p>Continuations are confusing to point where even toy examples in pedagogical blog posts are easy to mess up.

A few years ago, I woke up to my alarm, really groggy, and accidentally hit alarm off when I meant to hit the snooze button. Then I thought to myself, "I think I'll stay in bed for a few more minutes. I'll just remember my current continuation and if I oversleep I'll call it back with an error".<p>I overslept.

The following article is my functional programming bible. I always refer to it when things start to get a little hazy.<p><a href="http://www.defmacro.org/ramblings/fp.html" rel="nofollow">http://www.defmacro.org/ramblings/fp.html</a><p>If you read it (the continuations section) you <i>will</i> understand continuations. I stake my HN reputation on it (whatever that's worth).

The best way to understand continuations may be to think of them as copies of the stack.

I found this explanation far more confusing than a good explanation of continuations (of which I've seen several). And giving them a new name is bad mojo.<p>I believe the brief description being derided in this article, "the remaining work to be done", would be fine if it included the important bit: state. As he rightly points out, the work isn't the important bit...it's the state of the work+data that matters in continuations, and I didn't find his explanation really made that as clear as several other tutorials out there. Comparing it to goto was particularly uncomfortable for me (because again, it's the state that matters...and goto is effectively stateless in this context, and has the same flaw as just saying "the remaining work to be done"). The key to continuations is that you pick up where you left off with all data (the stack, as pg points out) intact.<p>So, pg has it right, of course, but I'm not sure very many dynamic language developers really have a very good comprehension of "the stack".

This is a very out-of-fashion confusing concept on which to write tutorials in your blog! Monads are the new continuations. Try to keep up.