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

Wed Apr 28 18:55:02 EDT 2010

I think y'all are talking past each other, a little bit.  There are two ways to serialize a function:

1) Serialize the bytecode for the function.
2) Serialize a persistant reference to a function that resides inside the executable.

Personally, I think that either strategy is dubious.  If you really need this, I would recommend building a DSL to support your specific needs.  When I was working in Java I trusted the default serializer about as far as I could physically throw it, and IIRC my associates at the time had the same instinct.

Functions in general can contain references to any data, including objects such as MVar's who's behavior is actually determined by unreachable entities.

There's no amount of type system magic that can hold off monsters like _|_ or things like lazy bytestrings that are finite but never intended to be fully resident in memory.  Or do we intend to serialize unevaluated thunks?

Friendly,
--Lane

>
>
> 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
>>
>

On Wed, 28 Apr 2010, Peter Verswyvelen wrote:

> As a side note, it's interesting that C# doesn't allow serialization
> of closures (anonymous delegates). The compiler-generated name
> assigned to an anonymous delegate can be different after each
> re-compilation. This is also really annoying in C#/.NET, since one
> must explicitly add a named method if serialization is needed. So I
> wander how Clean solves this. I mean, consider
>
>
> data MyData = MD (Int->Int)
>
> myFunc x = x+1
> myState1 = MyData myFunc
> myState2 = MyData (\x -> x+1)
>
> I can imagine that serializing myState1 is not too difficult, since it
> should be possible to lookup the name of the compiled function
> "myFunc".
>
> However, what about serializing myState2? The lambda function has no
> name, and it is not obvious to me how to give it a name that is unique
> enough to survive a couple of iterations of source code modifications.
>
>
>
>
>
> On Wed, Apr 28, 2010 at 9:56 PM, Gregory Crosswhite
> <gcross at phys.washington.edu> wrote:
>>
>> On Apr 28, 2010, at 3:41 PM, Limestra?l wrote:
>>
>>> 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.
>>
>> Is this true?  I thought that ghc has separate machine code and byte-code modes, and inferred that the latter was platform-independent.  Is the latter platform-specific because it is just a different way of organizing different ways of (unlinked) machine code, or because parts of the byte-code depend on things like the size of integers in the compilation machine that are platform-dependent?
>>
>> Also, it is worth noting that Clean supports serialization of values including closures.  It's not entirely clear to me how they do this, but looks like some combination of seeing whether a referenced routine is already in the current executable, then seeing whether it is in a nearby library, and then finally just-in-type compiling the serialized platform-independent bytecode into native code.
>>
>> Cheers,
>> Greg
>>
>> _______________________________________________
>> 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
>