
Eric,
Could you expound on why you try to avoid Flexible{Contexts,Instances} in
your own code? That might be useful to look at here.
On Fri, Mar 13, 2020, 9:22 PM Zemyla
Also, keeping it Haskell98 compliant makes it easier for newer users to grok.
On Fri, Mar 13, 2020, 23:15 Eric Mertens
wrote: I prefer to avoid FlexibleInstances wherever I can. The last thing I'd heard about quantified constraints was that they were buggy and I've been avoiding relying on them. (I should probably review that assumptions at some point.) Having a class like Eq1 is the cleaner option. I'd rather fix up these classes than work to get rid of them.
On Fri, Mar 13, 2020 at 8:59 PM chessai .
wrote: Consider the Eq instance for these types. Currently we rely on:
(Eq1 f, Eq1 g, Eq a)
But some potential improvements include changing to:
(Eq (f (g a))) (FlexibleContexts)
or
(forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a) (QuantifiedConstraints)
There was a discussion sometime last year about the same thing regarding Semigroup/Monoid instances for `Compose` [1]. Additionally, the question has been raised again for Data.Functor.{Product,Sum} on Gitlab [2, 3]. There has been no consensus in either case, but that's not too worrying as both discussions have been brief. I'm currently not happy with the {Eq,Ord,Show}{1,2} family of classes, and would hope to work toward their removal, or at least the shrinking of their presence in base. Even though the linked proposals are about a single type, I think it's important that we come up with a decision and stick with it. Having different APIs for different types here would be pretty confusing, and some could even say sloppy.
Please let me know your thoughts.
[1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015 [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-- Eric Mertens _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries