On Wed, Jul 04, 2007 at 09:44:13PM +1000, Donald Bruce Stewart wrote:
Binary instances are pretty easy to write. For a simple data type:> instance Binary Exp where > put (IntE i) = do put (0 :: Word8) > put i > put (OpE s e1 e2) = do put (1 :: Word8) > put s > put e1 > put e2 > get = do tag <- getWord8 > case tag of > 0 -> liftM IntE get > 1 -> liftM3 OpE get get get
That's quite verbose! Plus I'm a bit concerned by the boxing implied by those IntE / OpE constructors in get. If you were using those values in a pattern match on the result of get, would the compiler be able to eliminate them and refer directly to the values in the source data?
The Data.Binary comes with one tool to derive these. The DrIFT preprocessor also can, as can Stefan O'Rear's SYB deriver. I just write them by hand, or use the tool that comes with the lib. More docs here, http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary.html
This doesn't seem to deal with endianness. Am I missing something?
>>world, you could operate on the packets in place in Haskell where >>possible and save the deserialization overhead... > >Data.ByteString.* for this.
Ah, does Data.Binary fuse with ByteString.* then?
Hack those bytes! Quickly! :-)
:) It's a shame the layout definition is so verbose. Erlang's is quite compact. I wonder if something could be done with template haskell to translate an Erlang-style data layout definition to the Data.Binary form? (Bonus points for being able to parse ASN.1 and generate appropriate Haskell datatypes & serialization primitives automatically :-) ) 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
