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

[Limestraël]

I think the problem with function serialization is that unlike languages
which run over a virtual machine, bytecode generated by GHC is
platform-specific (just as compilated C or C++) and therefore can run
directly on top of the system, which is far faster but less portable.

It wouldn't make much sense if, when sending functions through network, the
receiver had to have the exact same system as the sender.

Back to FRP, now. I was wondering, Ben, which FRP framework you were using.
I'm trying to get into the whole FRP stuff, but I don't know which one is
better/simpler when you have almost no knowledge about the field.


2010/4/28 Chris Eidhof <chris at eidhof.nl>

> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100428/4f221c44/attachment.html