[Haskell-cafe] Serialization of (a -> b) and IO a
ajs at 2piix.com
Fri Nov 12 16:18:51 EST 2010
On Nov 12, 2010, at 12:44 PM, Andrew Coppin wrote:
> Just today I was thinking about how useful it would be if you could
> send a block of code from one PC to another to execute it remotely.
> The fact that you can't do this is basically why there's no
> distributed Haskell yet, despite what an obviously good idea that
> would be. It would be really cool if we could do this.
What kind of code are you thinking about? If you have a daemon
waiting on a foreign machine, you can send it bytecode to
deserialize. The issue is one of /encodings/. My "naive" approach
(enumerating the functions domain, applying the function, and
serializing a list of pairs of results) doesn't work so well because
it is slow and big. But it has all the properties we want, without
having to go into the compiler and make enormous changes. We need to
find an efficient representation of a function in that can be
serialized. Haskell code is one option, but the compiler would need
to pass it through to the run-time, so that the deserializer could run
a compiler on it. Passing some kind of intermediate level code
through would work as well. But we still face the same problem. We
need to compile the intermediate code into executable Haskell.
There is also the architecture independent approach I have described
previously (with a "Serialize" type class, enumerating the functions
domain and applying the function to each element, etc). This is
architecture independent in virtue of being implemented as plain old
run-time Haskell. It turns Haskell expressions into ByteStrings and
back. In short, the deserializer is an embedded compiler for "Haskell
bytecode". It interprets bytecode in terms architecture specific
code. To be honest, I'm not even sure how architecture independent
Data.Binary and the like really are. I'm guessing some care in the
serialization library could fix any issue, though.
> And yes, it should of course be an IO operation. Because, let's face
> it, any result it produces is inherantly going to be pretty random.
> (Much like my favourite GHC function name, reallyUnsafePtrEquity#...)
Serialization and transport are orthogonal. Serialization is pure.
Transport is not.
More information about the Haskell-Cafe