[Haskell-cafe] Make a DSL serializable

[Alberto G. Corona]

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.dupont at 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 <agocorona at 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.dupont at 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 <allbery.b at gmail.com>wrote:
>>>
>>>> On Sun, Mar 24, 2013 at 4:16 PM, Corentin Dupont <
>>>> corentin.dupont at 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
>>>> allbery.b at gmail.com
>>>> ballbery at sinenomine.net
>>>> unix, openafs, kerberos, infrastructure, xmonad
>>>> http://sinenomine.net
>>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>>
>> --
>> Alberto.
>>
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130325/f190ba65/attachment.htm>