Proposal: Add a wrapped applicative type to Data.Monoid

Ryan Scott ryan.gl.scott at gmail.com
Wed Apr 11 17:58:26 UTC 2018


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
<andrew.thaddeus at gmail.com> 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 <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


More information about the Libraries mailing list