[cryptonector]

Continuations are closures. Closures aren't continuations. Though one can build continuations out of closures by converting code into continuation passing style, which makes continuations explicit, and then `call/cc` is trivial, since all it does is pass (to its function argument) its [now-explicit, after CPS conversion] continuation, thus reifying it.

[gpderetta]

Continuations are just closures in cps. Closures are just functions plus an environment parameter. Functions are just gotos plus a link pointer. Yet each abstraction is more than the sum of its components.

[kazinator]

Continuations are closures because they capture everything that a closure would capture at the same point in the execution. But they also capture more.

In CPS, continuations are often closures. But: those closures also close over the surrounding function's hidden continuation parameter k, and make essential use of it! The last continuation-lambda in the function has to call k to simulate the return.

[sillysaurusx]

Ehh. I think it makes it a lot harder to understand what a continuation is if you say they’re closures.

Continuations capture the stack. Closures capture variables.

[gpderetta]

It is not wrong though. Once you reify the return continuation, a continuation is really just a closure, the stack is implicitly recovered by recursively following the captured return continuations. And with closures you do not necessary have a stack anyway but any arbitrary directed graph.

[cryptonector]

> Continuations capture the stack.

Yes, but if you take 'stack' too literally here then you'll think that `call/cc` copies the stack, when maybe it really doesn't.

> Closures capture variables.

Variables, yes, including the return address of the frame in which those variables are if that return address is make explicit (e.g., because of CPS conversion).

And now you can see that closures can be continuations if they implicitly capture the stack.