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

[Chris Eidhof]

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
> <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
>> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe