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.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
