phil:
On Sun, Jul 01, 2007 at 06:07:13PM +0100, Andrew Coppin wrote:
I haven't actually tried, but presumably a TCP connection is represented in the same way as a file, and so has the same problems.
Basically doing binary I/O seems to be one of those things that in Haskell falls into the class of "it's possibly but annoyingly messy"...
In an ideal world there would be a 'deriving Serializable[1]' you
derive Binary (use an external tool for this)
could do on datatypes which would get this right. In a really ideal world, you could specify the data layout somehow[2][2a], which would
Directly in Haskell data type decls -- see the ICFP 05 paper on the House OS, which added packing annotations, and bit syntax. In current Haskell, you specify the layout in instances Storable or Binary.
make integrating Haskell code into a wider distributed network of processes exchanging binary data a cinch. In a super really ideal
Definitely. See things like the zlib or iconv Data.Binary/Data.ByteString bindings, for prototypes. The 'tar' reader/writer on hackage.haskell.org is also a good example.
world, you could operate on the packets in place in Haskell where possible and save the deserialization overhead...
Data.ByteString.* for this.
Anyone trying to do any of this?
Yeah, its a bit of a hot topic currently. :) Gotta chase Erlang for hacking network data. -- Don