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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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

On Wed, Apr 11, 2018, 1:25 PM Ryan Scott <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Andrew Martin
In reply to this post by Ryan Scott
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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
<[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>
> --
> -Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries