It is possible as long as there is a empty event and there is a operation that mix two events to créate an state and an operation that mix an state and a event to créate an state.
Then, if the events are serializable, the deserialization of the state from a serialized list of events would be deserialize list= mconcat . read $ list it is a way to have a general expression for the deserialization instead of a ad-hoc loop. 2013/3/25 Corentin Dupont <corentin.dup...@gmail.com> > What do you mean by monoid? It's not clear to me how a state (essentially > a structure with many fields) can be a monoid... > I figured out that the Writer monad may be good for that purpose. > > > On Mon, Mar 25, 2013 at 1:50 AM, Alberto G. Corona <agocor...@gmail.com>wrote: > >> 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. >> >> >> 2013/3/24 Corentin Dupont <corentin.dup...@gmail.com> >> >>> Hi Brandon, >>> 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. >>> But I always bothered me that this state is not serializable... >>> >>> >>> On Sun, Mar 24, 2013 at 10:02 PM, Brandon Allbery >>> <allber...@gmail.com>wrote: >>> >>>> On Sun, Mar 24, 2013 at 4:16 PM, Corentin Dupont < >>>> corentin.dup...@gmail.com> wrote: >>>> >>>>> Hi Daniel, >>>>> 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. >>>>> So there is an infinite number of handlers... >>>>> >>>> >>>> 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. >>>> >>>> -- >>>> brandon s allbery kf8nh sine nomine >>>> associates >>>> allber...@gmail.com >>>> ballb...@sinenomine.net >>>> unix, openafs, kerberos, infrastructure, xmonad >>>> http://sinenomine.net >>>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Alberto. >> > > -- Alberto.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe