[Haskell-cafe] Make a DSL serializable

[Alberto G. Corona]

Corentin:
Thanks. It is not exactly the serialization of IO state computations,
but when re-started,  the IO state is recreated from
the serialized intermediate results.  It makes use of a simple idea,
although it is not easy to realize it practically.

I suppose that scala does something similar for their
serializable delimited continuations.


2013/3/25 Corentin Dupont <corentin.dupont at gmail.com>

> Workflow is impressive! I didn't know you could serialize IO
> states/computations.
>
>
> On Mon, Mar 25, 2013 at 2:06 AM, Alberto G. Corona <agocorona at gmail.com>wrote:
>
>> the package Workflow  serialize also the state of a computation, so it
>> can be re-started and continued. It uses also the above mentioned event
>> trick to serialize the state.
>>
>> By the way you can use the workflow monad transformer to recover the
>> state of the game. You don´t need to serialize anything explicitly, the
>> transformer will do it, but your step results must be serializable.
>>
>>  If you have this code:
>>
>>   loop= do
>>        eventhandlercode <- receive
>>        handler <- compile eventhandlercode
>>        execute handler
>>        loop
>>
>> then the lifted process in the workflow monad would be:
>>
>>   loop=do
>>        eventhandlercode <- step receive
>>        handler <- liftIO $ compile eventhandlercode
>>        liftIO $ execute handler
>>        loop
>>
>> step will store the result and will recover the execution state.
>> Only the step result should be serializable.
>>
>>
>> 2013/3/24 Corentin Dupont <corentin.dupont at gmail.com>
>>
>>> I also came across Scala's Swarm, making use serializable delimited
>>> continuations. Looks good!
>>> http://www.scala-lang.org/node/3485
>>>
>>>
>>> On Sun, Mar 24, 2013 at 11:13 PM, Michael Better <mbetter at gmail.com>wrote:
>>>
>>>> Isn't this similar to the problem Cloud Haskell had to solve to send
>>>> code to another process to run?
>>>>
>>>> Mike
>>>> On Mar 24, 2013 5:06 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:
>>>>
>>>>> On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont <
>>>>> corentin.dupont at gmail.com> wrote:
>>>>>
>>>>>> But I always bothered me that this state is not serializable...
>>>>>
>>>>>
>>>>> I am not quite sure how to respond to that. You seem to be asking for
>>>>> magic.
>>>>>
>>>>> That kind of state has never been sanely serializeable. Not in
>>>>> Haskell, not anywhere else. The usual hack is to dump an entire memory
>>>>> image to disk, either as an executable (see "gcore" and "undump"; also see
>>>>> how the GNU emacs build dumps a "preloaded" emacs executable) or by dumping
>>>>> the data segment as raw bytes and reloading it as such (which doesn't work
>>>>> so well in modern demand paged executables; it can work better with a
>>>>> virtual machine environment, and various Lisp and Smalltalk implementations
>>>>> dump and reload their raw VM images this way).
>>>>>
>>>>> I would not be surprised if what you seem to be asking for turns out
>>>>> to be yet another guise of the halting problem.
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> 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/9dca159c/attachment.htm>