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