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
