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

[Alexander Solla]

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.