Conversion problem
How often do you import Data.Text.Lazy only to call fromStrict or toStrict?
How about importing Data.ByteString.Builder only to call its
toLazyByteString and then importing
Data.ByteString.Lazy only to call its toStrict?
How often do you convert from DiffTime to NominalDiffTime or back?
These are all instances of one pattern. They are conversions between different
representations of the same information. Codebases that don't attempt to
abstract over this pattern tend to be sprawling with this type of
boilerplate. It's noise to the code reader, it's a burden to implementors
and maintainers.
Why another conversion library?
Many libraries exist that approach the conversion problem. However, most of
them provide lawless typeclasses, leaving it up to the author of the
instance to define what makes a proper conversion. This results in
inconsistencies across instances, their behavior not being evident to
the user and no way to check whether an instance is correct.
This library tackles this problem with a lawful typeclass, making it
evident what any of its instances do, and it provides a property-test for you
to validate your instances.
The insight
The key insight of this library is that if you add a requirement for the
conversion to be lossless and to have a mirror conversion in the opposite
direction, there usually appears to be only one way of defining it. That
makes it very clear what the conversion does to the user and how to define
it for the author of the conversion.
It also gives clear criteria for validating whether the instances are correct, which can be encoded in property-tests.
That insight itself stems from an observation that almost all of the
practical conversions in Haskell share a property: you can restore the
original data from its converted form. E.g., you can get a text from
a text-builder and you can create a text-builder from a text, you can convert
a bytestring into a list of bytes and vice-versa, bytestring to/from bytearray,
strict bytestring to/from lazy, list to/from sequence, sequence to/from
vector, set of ints to/from int-set. In other words, it's always a two-way
street with them and there are many instances of this pattern.
A few other accidental findings like encoding this property with recursive
typeclass constraints and fine-tuning for the use of
the TypeApplications extension resulted in a terse and clear API.
Other work and acknowledgements
Some ideas and concepts are also shared with the following libraries:
