<div dir="ltr">IMO, requiring substitivity (forall a b. if a == b then forall f. f a == f b) is a pretty onerous condition for Eq as it is used in practice. Usually type class laws only govern how the type class methods interact with each other and with super classes. The substitutivity law places a requirement on the entire publicly exported interface for a type. The `Set` type in containers is in violation of this law as well (with `f = splitRoot`).<div><div><br></div><div>Laws are primarily sold to developers as a means of refactoring fearlessly - eg i can rewrite `fmap f . fmap g` into `fmap (f . g)` without altering the meaning of the given program. I'm not sure which refactors are possible with the substitutivity law.<br><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Matt Parsons</div></div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 11, 2019 at 8:32 AM chessai . <<a href="mailto:chessai1996@gmail.com">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">In what way is the documentation for Eq (as of base 4.12) overzealous, and how would you suggest it be changed?<div dir="auto"><br></div><div dir="auto">Thanks</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 11, 2019, 3:35 AM Edward Kmett <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">-1<div><br></div><div>I agree with Henning on this one.<div><br></div><div>(==) provides an equivalence relation.</div><div><br></div><div>Despite the addition of some vocabulary in base 4.12 about how (==) "should" be structural, that is at odds with Arg's actual purpose.</div><div><br></div><div>I'd rather argue that the attempted refinement of (==)'s documentation was rather overzealous than that Arg as it is defined is wrong.</div><div><br></div><div>The instances are useful and follow the intent of the classes, just not the extra paragraph that was bolted on sideways to the text describing Eq.</div><div><br></div><div>-Edward</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 11, 2019 at 9:30 AM Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de" rel="noreferrer" target="_blank">lemming@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Fri, 10 May 2019, David Feuer wrote:<br>
<br>
> There also needs to be some documentation about the fact that the Arg <br>
> constructor allows inspection that does not respect Eq.<br>
<br>
This follows from Arg's purpose.<br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">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-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>