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.<br>
<br>It wouldn't make much sense if, when sending functions through network, the receiver had to have the exact same system as the sender.<br><br>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.<br>
<br><br><div class="gmail_quote">2010/4/28 Chris Eidhof <span dir="ltr"><<a href="mailto:chris@eidhof.nl">chris@eidhof.nl</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
However, I think it is not easy to do this: traversing the heap should be relatively simple, however: what if a function implementation changes?<br>
<br>
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: <a href="http://www.mail-archive.com/haskell-cafe@haskell.org/msg34054.html" target="_blank">http://www.mail-archive.com/haskell-cafe@haskell.org/msg34054.html</a><br>
<font color="#888888"><br>
-chris<br>
</font><div><div></div><div class="h5"><br>
On 28 apr 2010, at 19:50, Peter Verswyvelen wrote:<br>
<br>
> Interesting topic. I find it a bit annoying that Haskell doesn't<br>
> provide support to save functions. I understand this is problematic,<br>
> but it would be very nice if the Haskell runtime provided a way to<br>
> serialize (part of) the heap, making sure that pointers to compiled<br>
> functions get resolved correctly.<br>
><br>
><br>
><br>
> On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson<br>
> <<a href="mailto:lane@downstairspeople.org">lane@downstairspeople.org</a>> wrote:<br>
>><br>
>> On Wed, 28 Apr 2010, Ben wrote:<br>
>><br>
>>> I want to save the state of the system to disk, I want to be able to<br>
>>> play the game, pick a point to stop, freeze it and turn off the<br>
>>> computer, and then come back later and resume. Why is that unwise?<br>
>>> What are the alternatives?<br>
>>><br>
>>> B<br>
>>><br>
>>>> On Tue, 27 Apr 2010, Ben wrote:<br>
>>>><br>
>>>>> slightly off topic, but how does one handle pausing / saving /<br>
>>>>> restarting in the FRP framework, especially the arrowized version?<br>
>><br>
>> If we're about Arrow FRP, remember that the arrow typeclass includes a<br>
>> function, 'arr', that admits any function as a parameter, and these are in<br>
>> general impossible to serialize to disk. Since Arrow FRP ends up roughly in<br>
>> a form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually the<br>
>> state of the system. There are a few tactics that would get us around this<br>
>> limitation, but they are rather severe. You could render 'arr' useless in<br>
>> several ways, or you could save all the input to a system and replay it.<br>
>><br>
>> But I would argue that even if you wanted to do this, "saving an FRP system"<br>
>> is, to me, like "saving a system in the IO monad," (which, there are tactics<br>
>> that would let you do this, too). It's probablematic in part because the<br>
>> FRP system probably has active hooks into the user interface, such as<br>
>> windows and other widgits that it owns, and possibly other devices (such as<br>
>> physical rocket engines). Even if the FRP system is completely pure and can<br>
>> be referenced by a single pointer, it is easily and rightfully aware of<br>
>> specific details of the hardware it is embedded in.<br>
>><br>
>> So it seems to me that what we actually want, to do complex simulations with<br>
>> persistance, is not an FRP system that interacts with the outside world, but<br>
>> a "self-contained, self-interacting, differential equation hairball." Such<br>
>> a system would be very cool, but I think that the numerical algorithms<br>
>> needed exceed what an FRP system should try to provide.<br>
>><br>
>> Friendly,<br>
>> --Lane<br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>