Laws for GHC.Generics

David Feuer david.feuer at
Mon Mar 20 21:16:12 UTC 2017

Ryan Scott has argued that abstract types should not have Generic instances
at all. I'll let him make those arguments himself, but I think I should
mention that it's really hard to write instances that set up all the
appropriate type-level meta-data. Some of it (like the extra-full package
name) may only be doable with Template Haskell. Furthermore, some of the
metadata types change from GHC version to version.

As for laws, I think you *probably* meant

to . from = id

That is, that you can convert a value to its generic representation and
back and get the "same" value back.

I think that's likely sufficient for most purposes, but probably not all.
At the very least, it's something people using your instance would need to
be aware of. If either function is partial, you will be in a world of pain
if you try to use something like generic serialization.

On Mar 20, 2017 4:53 PM, "Gershom B" <gershomb at> wrote:

I had a bit of discussion today on how to handle generic instances for
abstract types.

It resolved to the following question, in a sense -- what are the laws
for the Generic typeclass?

Should require that `from` and `to` be an isomorphism of data types
(i.e. that `from . to` and `to . from` both be the identity) or should
we require only the weaker one-sided retract condition (i.e. that
`from . to` be the identity.). If the latter, is it better that `from`
be partial (which i  prefer) or that it quotient together "equivalent"
representations (i.e. representing a map as a `fromList` as
syb-generics do).

The documentation doesn't seem to provide clear guidance here, and it
might be worth discussing if some should be added.

Libraries mailing list
Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list