[Haskell-beginners] Haskell Serialization

Stephen Tetley stephen.tetley at gmail.com
Tue May 11 13:45:42 EDT 2010

On 11 May 2010 18:00, Ashish Agarwal <agarwal1975 at gmail.com> wrote:
> Thanks for your responses.
>> Only it might give rise to confusion if somebody wants to transmit those
>> types according to another protocol.
> So are Binary instances perceived to be just for (de)serializing from/to
> Haskell? Would it be better style for me to define a new type class with
> methods getProt and putProt, where Prot is whatever protocol I'm supporting?

Hi Ashish

For the first question - my opinion would be yes, though I might be in
a minority of one on that point.

For the second question - its just a matter of taste, personally I
like type class to be a bit more than a naming convenience e.g. the
Monad class communicates a strong notion of, ahem, "monads" and there
are many valuable functions that can be built using just the
operations of monad class without knowing the implementation
(sequence, liftM, mapM etc.). For say pretty printing, I can live
happily just prefixing my type with pp rather than hankering after a
class (e.g ppInt, ppFloat, ppSyntaxTree...). Again this is an entirely
personal taste - and when a Pretty class is provided (as in wl-pprint,
but not HughesPJ) I use it.

> is there any difference between the following:
>     get (0::Word8)
>     getWord8be 0

Did you mean this, as there is no `getWord8`:

> get (0::Word8)
> getWord8 0

This will always be fine for a single Word8, as there's no notion of
endian-ness (as far as my understanding goes). Also the Binary
instance for Word8 is implemented as:

> instance Binary Word8 where
>   get = getWord8
>   put = putWord8

... so the code is the same.

An Int8 is a bit more problematic - I think works as 0x00 to 0x0E
covers 0..127, 0x10 is -128, going to 0xEE for -1. Whilst I think this
would be the expected behaviour in C, I can't remember if its true, so
I wouldn't like to rely on it for inter-working between Haskell and C.
For floating point numbers - representations are quite likely to
diverge, one would hope any good protocol would pick a proper
representation (e.g. IEEE-754).

Data.Binary is a "Standard Library" so any Haskell compiler should use
the same code and produce the same binary layout.

Best wishes


More information about the Beginners mailing list