
Yes, you're right about `to . from`. I had it backwards. Vis a vis:
If either function is partial, you will be in a world of pain if you try to use something like generic serialization.
I'm not sure I understand. Deserialization is already partial if we're
considering the source as "all possible strings of bits" and the
target as a specific datatype? I don't see how having the conversion
from a generic be partial as well makes things any different?
(i.e. i think we're in a retract situation already)
-g
On Mon, Mar 20, 2017 at 5:16 PM, David Feuer
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"
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.
Cheers, Gershom _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries