Improving the instances of Data.Functor.{Product,Sum}

chessai . chessai1996 at gmail.com
Sat Mar 14 05:49:14 UTC 2020


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 <zemyla at gmail.com> wrote:

> Also, keeping it Haskell98 compliant makes it easier for newer users to
> grok.
>
> On Fri, Mar 13, 2020, 23:15 Eric Mertens <emertens at gmail.com> 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 . <chessai1996 at gmail.com> 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 at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>
>>
>> --
>> Eric Mertens
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200313/6c4fdbcb/attachment.html>


More information about the Libraries mailing list