> 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?
> numbers are always big-endian
I have been wondering about the difference in put/get instances of Word types versus the getWord8be, getWord8le, etc. functions. Since the default instances use big-endian, is there any difference between the following:
get (0::Word8)
getWord8be 0
What exactly are the guarantees for Binary instances, only that get and put are inverses? Are all other features possibly different between compiler versions or different implementations of Haskell?
On Mon, May 10, 2010 at 5:49 PM, Stephen Tetley
<stephen.tetley@gmail.com> wrote:
Hi Ashish
Daniel has largely answered this for me (thanks Daniel!).
If you define Binary instances for your data types to match a protocol
- then as Daniel says you can only use them for that protocol.
Similarly the all the regular Haskell types - Int, Word8, Float, etc.
- have Binary instances ready-made which you may not want when dealing
with anything non-Haskell [*]: numbers are always big-endian, the
encodings for Integers, Floats and the like are sparsely documented
and may well handle signs differently to an equivalent C / Java / ...
representation.
[*] Personally I'd go as far as saying, as saying you should avoid
them entirely except for writing other instances of the Binary class.