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