[Haskell-cafe] Serialization of (a -> b) and IO a

[Jesse Schalken]

Is it possible to serialize and deserialize a function to/from binary form,
perhaps using Data.Binary, for example? What about an IO action? If so, is
there a way the serialized representation could be architecture-independent?

I have been shown how useful it can be to store functions inside data
structures, and while looking at data serialization for the purpose of
persistence I wondered "since functions are just values in Haskell, why
can't we persist them, too?".

To me the idea has interesting implications. For example, an arbitrary
program could simply be represented by a serialization of `IO ()`. In fact,
you could load any program into memory from a file and use
Control.Concurrent.forkIO to run it, and later kill it, giving you the
beginnings of an operating environment. If such a serialization
is architecture independent then to my understanding you have the beginnings
of a virtual machine. You could break your program into pieces and store
them in a database and load them when needed, or even pull updates to each
piece individually from down the web etc, enabling interesting methods of
software distribution. It would make very cool stuff possible.

I have had a look at hs-plugins, but it is unclear how to derive a simple
pair of functions `(a -> b) -> ByteString` and `ByteString -> Either
ParseError (a -> b)`, for example, from the functionality it provides, if it
is possible at all. I guess such a thing requires thorough digging into the
depths of GHC, (or maybe even LLVM if
an architecture independent representation is sought, but I don't know
enough to say.). Perhaps this is more a question for those interested and
knowledgable in Haskell compilation (and, to some extent, decompilation).

If not Haskell, are there any languages which provide a simple serialization
and deserialization of functions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20101111/6a34e1ac/attachment.html