Proposal: Add a wrapped applicative type to Data.Monoid

Andrew Martin andrew.thaddeus at gmail.com
Wed Apr 11 17:51:07 UTC 2018


How would such Applicative-based instances intended to be written?

    instance (Applicative f, Eq a) => Eq (Ap f a) where
      (==) = liftA2 (==)

That does not typecheck, and I don't believe it's possible to write
something like this. Still, I would prefer

    instance (Eq1 f, Eq a) => Ap f a

to the approach that uses FlexibleContexts.

On Wed, Apr 11, 2018 at 1:25 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> One thing that is not clear to me: is this Ap type intended to be a
> catch-all for defining instances that are "lifted" through an
> Applicative? Or are you deliberately restricting that to the Semigroup
> and Monoid instances? For instance, I noticed that you currently
> derive Ap's Eq, Ord, Read, and Show instances, which would give:
>
>     instance Eq (f a) => Eq (Ap f a)
>     instance Ord (f a) => Ord (Ap f a)
>     instance Read (f a) => Read (Ap f a)
>     instance Show (f a) => Show (Ap f a)
>
> Would you not want this instead, to be in line with the Semigroup and
> Monoid instances?
>
>     instance (Applicative f, Eq a) => Eq (Ap f a)
>     instance (Applicative f, Ord a) => Ord (Ap f a)
>     instance (Applicative f, Read a) => Read (Ap f a)
>     instance (Applicative f, Show a) => Show (Ap f a)
>
> I would be fine with either option, but if we should be clear about
> Ap's intentions when we end up documenting it.
>
> Ryan S.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180411/78037ad7/attachment.html>


More information about the Libraries mailing list