<div dir="auto">Suppose we have<div dir="auto"><br></div><div dir="auto">desGen :: DG f => ByteString -> Deserializer (f r)</div><div dir="auto"><br></div><div dir="auto">We can then use</div><div dir="auto"><br></div><div dir="auto">fmap to . desGen</div><div dir="auto"><br></div><div dir="auto">to deserialize a value of a type with a Generic instance. But if `to` is partial, this doesn't produce a deserialization error; it makes the whole program blow up. So you're relying on your "generic" deserializer (the DG instance) to produce only values acceptable to `to`. It isn't actually generic at all!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 20, 2017 5:37 PM, "Gershom B" <<a href="mailto:gershomb@gmail.com">gershomb@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, you're right about `to . from`. I had it backwards.<br>
<br>
Vis a vis:<br>
<br>
> If either function is partial, you will be in a world of pain if<br>
> you try to use something like generic serialization.<br>
<br>
I'm not sure I understand. Deserialization is already partial if we're<br>
considering the source as "all possible strings of bits" and the<br>
target as a specific datatype? I don't see how having the conversion<br>
from a generic be partial as well makes things any different?<br>
<br>
(i.e. i think we're in a retract situation already)<br>
<br>
-g<br>
<br>
<br>
<br>
On Mon, Mar 20, 2017 at 5:16 PM, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
> Ryan Scott has argued that abstract types should not have Generic instances<br>
> at all. I'll let him make those arguments himself, but I think I should<br>
> mention that it's really hard to write instances that set up all the<br>
> appropriate type-level meta-data. Some of it (like the extra-full package<br>
> name) may only be doable with Template Haskell. Furthermore, some of the<br>
> metadata types change from GHC version to version.<br>
><br>
> As for laws, I think you *probably* meant<br>
><br>
> to . from = id<br>
><br>
> That is, that you can convert a value to its generic representation and back<br>
> and get the "same" value back.<br>
><br>
> I think that's likely sufficient for most purposes, but probably not all. At<br>
> the very least, it's something people using your instance would need to be<br>
> aware of. If either function is partial, you will be in a world of pain if<br>
> you try to use something like generic serialization.<br>
><br>
> On Mar 20, 2017 4:53 PM, "Gershom B" <<a href="mailto:gershomb@gmail.com">gershomb@gmail.com</a>> wrote:<br>
><br>
> I had a bit of discussion today on how to handle generic instances for<br>
> abstract types.<br>
><br>
> It resolved to the following question, in a sense -- what are the laws<br>
> for the Generic typeclass?<br>
><br>
> Should require that `from` and `to` be an isomorphism of data types<br>
> (i.e. that `from . to` and `to . from` both be the identity) or should<br>
> we require only the weaker one-sided retract condition (i.e. that<br>
> `from . to` be the identity.). If the latter, is it better that `from`<br>
> be partial (which i  prefer) or that it quotient together "equivalent"<br>
> representations (i.e. representing a map as a `fromList` as<br>
> syb-generics do).<br>
><br>
> The documentation doesn't seem to provide clear guidance here, and it<br>
> might be worth discussing if some should be added.<br>
><br>
> Cheers,<br>
> Gershom<br>
> ______________________________<wbr>_________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
><br>
><br>
</blockquote></div></div>