[Haskell-cafe] Re: FRP for game programming / artifical life
chris at eidhof.nl
Wed Apr 28 14:49:52 EDT 2010
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://firstname.lastname@example.org/msg34054.html
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?
>>>> 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.
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe