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.dup...@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 <agocor...@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.dup...@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 <mbet...@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" <allber...@gmail.com> wrote: >>>> >>>>> On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont < >>>>> corentin.dup...@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 >>>>> 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 >>>>> >>>>> >>> >>> _______________________________________________ >>> 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