On Wed, Jul 04, 2007 at 09:02:15PM +1000, Donald Bruce Stewart wrote:
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)
such as?
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.
I'll have a look.
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.
OK. Maybe this is the sort of stuff which ought to go into the new
Haskell book? 'Integrating Haskell with external data sources' or
something...
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.
Absolutely. Ta for the pointers anyway.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
