Generic combinators to derive type class instances.
Orphans
The
Orphans module should be imported to derive the following
classes using this library:
Minor discrepancies
Here are documented some corner cases of deriving, both by GHC and
generic-data. They are all minor and unlikely to cause problems in
practice.
Empty types
- Some of the derived methods are lazy, which might result in errors
being silenced, though unlikely.
- The only generic-data implementation which differs from GHC stock
instances is gfoldMap.
TODO: table
Single-constructor single-field types
data types with one constructor and one field are extremely
rare.
newtype is almost always more appropriate (for which
there is no issue).
That said, for
data types both strict and lazy, all
generic-data implementations are lazy (they don't even force the
constructor), whereas GHC stock implementations, when they exist, are
strict.
Functor composition
Fields of functors involving the composition of two or more functors
f (g (h a)) result in some overhead using
GHC.Generics.Generic1.
This is due to a particular encoding choice of
GHC.Generics,
where composition are nested to the right instead of to the left.
f (g (h _)) is represented by the functor
f :.: (g
:.: Rec1 h), so one must use
fmap on
f to convert that back to
f (g (h _)). A better
choice would have been to encode it as
(Rec1 f :.:
g) :.: h, because that is coercible back to
f (g (h
_)).