Re: Proposal: Add a wrapped applicative type to Data.Monoid

Ah, you're absolutely right. My question is not well formed, in that case. To be honest, I had the Num typeclass in mind when I originally thought about this, since a current pull request to add Ap to base [1] simply derives Num instead of defining something like: instance (Applicative f, Num a) => Num (Ap f a) Unlike my previous suggestions (which were bogus), I'm pretty sure that one works out :) Ryan S. ----- [1] https://github.com/ghc/ghc/pull/122 On Wed, Apr 11, 2018 at 1:51 PM, Andrew Martin wrote:

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin