Another Serialization API Axis
Johan Tibell and I have been working on a Haskell serialization API recently, and he wrote an excellent post outlining the general issues one runs into again and again. This is a follow up that adds another.
Please read Designing a Serialization API first
How many ways can the Haskell types map
In some serialization, there is really on one useful way to map the basic Haskell types. For example, Bool‘s True and False clearly map to and from JSON’s true and false. Any other conversion, while conceivable, probably isn’t realistic. On the other hand, there is no standard way for Int to map onto a stream of bytes. Even within a given protocol, and Int may be serailized different ways at different points in the data stream.
This influences the design of the serialization type classes: Aeson’s toJSON type class can be parameterised by type, because Int, Bool, String, and Text are all going always serialize the same.
On the other hand, Binary’s Put monad allows, at some extra programmer work, the ability to serialize a Int various different ways. via putWord8, putWord16le, putWord16be, etc…
Turns out, Binary also provides the Binary type class, parameterised on type, must like Aeson’s ToJSON and FromJSON type classes. However, it isn’t used as much for serialization to known protocols for precisely the reason that you don’t have enough control over how the basic Haskell types are represented.