[Haskell-cafe] Re: FRP for game programming / artifical life simulation

[Peter Verswyvelen]

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
<lane at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>