I agree. This would be an extremely useful feature, not only for game development, but also for web development. We often use continuations as a way to add state to the web, but this fails for two reasons: whenever the server restarts, or when we scale to multiple machines.
However, I think it is not easy to do this: traversing the heap should be relatively simple, however: what if a function implementation changes? An interesting approach is taken by the Clean guys: they use dynamics, which can store a function, a type representation and the heap to disk. See also this old thread: http://www.mail-archive.com/haskell-cafe@haskell.org/msg34054.html -chris On 28 apr 2010, at 19:50, Peter Verswyvelen wrote: > Interesting topic. I find it a bit annoying that Haskell doesn't > provide support to save functions. I understand this is problematic, > but it would be very nice if the Haskell runtime provided a way to > serialize (part of) the heap, making sure that pointers to compiled > functions get resolved correctly. > > > > On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson > <l...@downstairspeople.org> wrote: >> >> On Wed, 28 Apr 2010, Ben wrote: >> >>> I want to save the state of the system to disk, I want to be able to >>> play the game, pick a point to stop, freeze it and turn off the >>> computer, and then come back later and resume. Why is that unwise? >>> What are the alternatives? >>> >>> B >>> >>>> On Tue, 27 Apr 2010, Ben wrote: >>>> >>>>> slightly off topic, but how does one handle pausing / saving / >>>>> restarting in the FRP framework, especially the arrowized version? >> >> If we're about Arrow FRP, remember that the arrow typeclass includes a >> function, 'arr', that admits any function as a parameter, and these are in >> general impossible to serialize to disk. Since Arrow FRP ends up roughly in >> a form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually the >> state of the system. There are a few tactics that would get us around this >> limitation, but they are rather severe. You could render 'arr' useless in >> several ways, or you could save all the input to a system and replay it. >> >> But I would argue that even if you wanted to do this, "saving an FRP system" >> is, to me, like "saving a system in the IO monad," (which, there are tactics >> that would let you do this, too). It's probablematic in part because the >> FRP system probably has active hooks into the user interface, such as >> windows and other widgits that it owns, and possibly other devices (such as >> physical rocket engines). Even if the FRP system is completely pure and can >> be referenced by a single pointer, it is easily and rightfully aware of >> specific details of the hardware it is embedded in. >> >> So it seems to me that what we actually want, to do complex simulations with >> persistance, is not an FRP system that interacts with the outside world, but >> a "self-contained, self-interacting, differential equation hairball." Such >> a system would be very cool, but I think that the numerical algorithms >> needed exceed what an FRP system should try to provide. >> >> Friendly, >> --Lane >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe