Proposal: Add a wrapped applicative type to Data.Monoid

[Ryan Scott]

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.

[David Feuer]

With the instances Ryan suggests, the type seems to belong to
Control.Applicative rather than Data.Monoid.

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

[Andrew Martin]

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.

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

[Ryan Scott]

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

Post by Andrew Martin
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.

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

--
-Andrew Thaddeus Martin