<div dir="ltr"><div>That is the advantage of recording the sequence of events instead of the final state: that the state donīt need to be seriallizable. And this indeed the way to serlize something that can be decomposed in events. I think that this is elegant.. Specially if the events and the state are elements of a Monoid instance.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/24 Corentin Dupont <span dir="ltr"><<a href="mailto:corentin.dupont@gmail.com" target="_blank">corentin.dupont@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Brandon,<br>in fact, that's what I'm doing. I record the list of actions performed by the players, including the submission of the code. I serialize this list of actions instead of the state of the game. When deserializing, I replay all the players actions from scratch to get back to the same state than before. This is the only way to do it (replaying from scratch), since the pieces of code submitted can interact with other pieces of code submitted earlier: they are not independant.<br>
But I always bothered me that this state is not serializable...<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Sun, Mar 24, 2013 at 10:02 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div>On Sun, Mar 24, 2013 at 4:16 PM, Corentin Dupont <span dir="ltr"><<a href="mailto:corentin.dupont@gmail.com" target="_blank">corentin.dupont@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Hi Daniel,<br>in my game the handlers are supplied by the players as part of little programs that they submit. An haskell interpreter is reading the program code submitted and inserts it in the game.<br>So there is an infinite number of handlers...<br>
</blockquote><div><br></div></div><div>You might store both the compiled code and the originally submitted code, and serialize the latter in a form that restart can recompile. I don't think that can be any less safe than the original submission/compilation/insertion.</div>
<span><font color="#888888">
<div><br></div></font></span></div><span><font color="#888888">-- <br><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div>
<div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</font></span></div>
</blockquote></div><br>
</div></div><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></blockquote></div><br><br clear="all"><br>-- <br>Alberto.
</div>