[philbo]

Realistically, how much data is it practical to stash inside these continuations? It seems like it could get out of hand quite quickly for non-toy examples.

If you were propagating e.g. game state, you'd still want to stick that in a db, so the continuation would just be a session id?

[sheenobu]

A continuation is a function that, when called, jumps back to a specific part of the program that was frozen (meaning current memory, the call stack, the line number). So it can't really be stored. If your game state was stored in a db, you'd still have to load it memory to perform operations on it. Those operations, if using continuations, would then stick around in memory while waiting the continuation to be resumed. If it's a multi-player game, then you'd be in real trouble as your continuation could end up with stale data.

Game state has to be propagated from the server to the client so the player knows what is happening where-as continuations as used in this article are more about avoiding this propagation (the hidden field in the example is replaced by dispatch-table tag which acts as a session id / location in the dispatch-table for finding the continuation function)

[kmill]

Just to clarify, continuations don't have a snapshot of the whole heap, and they can be thought of as being a snapshot of just the interpreter state for a particular execution thread (roughly the call stack and source position). If heap objects are modified between creating a continuation and calling it, then the continuation will see the modified versions of all those objects. When it comes to garbage collection, continuations keep any objects referred to in their saved call stack alive. This is similar to any other closure, but instead of keeping things alive according to lexical scope, this is more of a dynamic scope thing (it's based on whatever functions happened to call this one).

Persisting a continuation seems like it's similarly as challenging as persisting an arbitrary closure. Like usual there are things you can't really persist, for example in your call stack you might have some unwind handlers for closing files -- how do you persist file handles?

[foldr]

It’s certainly possible to store continuations. You just store the program counter and a copy of the stack at the point where the continuation was captured. (There may be more efficient representations - I’m just talking conceptually here.)

If you google ‘serializable continuations’ you’ll find a reasonable amount of prior art (e.g. http://wiki.call-cc.org/eggref/5/s11n). I think there has never been a good solution to versioning then against changes to the code.