<div><div dir="auto">I think we should pre address any maturity issues or composition/ generality concerns before folding quantified constraint instances into base </div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 2:08 PM David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Okay, but I still don't see the practical problem.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020, 2:05 PM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">andrew.thaddeus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>You're right. I botched that. The scenario I meant to describe was:</div><div><br></div><div><div> foo :: _ => f a -> f a -> Bool<br></div><div> foo x y = Compose (Just x) == Compose (Just y) && Compose [x] == Compose [y]</div><div><br></div><div>The different results are:<br></div><div>* FlexibleContexts approach: `(Eq (Maybe (f a)), Eq [f a])`</div><div>* Eq1 typeclass: `(Eq1 f, Eq a)`</div><div>* Quantified Constraints: `(forall x. Eq x => Eq (f x), Eq a)`</div><div><br></div><div>Only the FlexibleContexts approach mentions Maybe and [] in the constraints.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 1:56 PM David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer" target="_blank">david.feuer@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">Why is that a problem? `Eq a` is still sufficient.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020, 1:51 PM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com" rel="noreferrer" target="_blank">andrew.thaddeus@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"><div>I dislike the FlexibleContexts approach because it gives you constraints that do not compose. Consider this minimal example:</div><div><br></div><div> foo :: _ => a -> a -> Bool<br></div><div> foo x y = Compose (Just (Just x)) == Compose (Just (Just y)) && Compose [Just x] == Compose [Just y]</div><div><br></div><div>What do we expect the constraint to be? With the Eq1 machinery or with QuantifiedConstraints, it's `Eq a` (GHC will infer this). However, with FlexibleContexts, it's `(Eq (Compose Maybe Maybe a), Eq (Compose [] Maybe a)`.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 12:45 PM David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer noreferrer" target="_blank">david.feuer@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"><div>I oppose the QuantifiedConstraints version because:</div><div dir="auto"><br></div><div dir="auto">1. It is more complicated than the FlexibleConstraints one.</div><div dir="auto"><br></div><div dir="auto">2. It is strictly less general than the FlexibleConstraints one.</div><div dir="auto"><br></div><div dir="auto">3. There is no apparent benefit to pay for detriments 1 and 2.</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Mar 13, 2020, 11:59 PM chessai . <<a href="mailto:chessai1996@gmail.com" rel="noreferrer noreferrer" target="_blank">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">Consider the Eq instance for these types. Currently we rely on:<br>
<br>
(Eq1 f, Eq1 g, Eq a)<br>
<br>
But some potential improvements include changing to:<br>
<br>
(Eq (f (g a))) (FlexibleContexts)<br>
<br>
or<br>
<br>
(forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a)<br>
(QuantifiedConstraints)<br>
<br>
There was a discussion sometime last year about the same thing<br>
regarding Semigroup/Monoid instances for `Compose` [1]. Additionally,<br>
the question has been raised again for Data.Functor.{Product,Sum} on<br>
Gitlab [2, 3]. There has been no consensus in either case, but that's<br>
not too worrying as both discussions have been brief. I'm currently<br>
not happy with the {Eq,Ord,Show}{1,2} family of classes, and would<br>
hope to work toward their removal, or at least the shrinking of their<br>
presence in base. Even though the linked proposals are about a single<br>
type, I think it's important that we come up with a decision and stick<br>
with it. Having different APIs for different types here would be<br>
pretty confusing, and some could even say sloppy.<br>
<br>
Please let me know your thoughts.<br>
<br>
[1]: <a href="https://mail.haskell.org/pipermail/libraries/2019-July/029771.html" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://mail.haskell.org/pipermail/libraries/2019-July/029771.html</a><br>
[2]: <a href="https://gitlab.haskell.org/ghc/ghc/issues/17015" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/issues/17015</a><br>
[3]: <a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/1704" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/merge_requests/1704</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr">-Andrew Thaddeus Martin</div>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr">-Andrew Thaddeus Martin</div>
</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></div>