Proposal: add Monoid1 and Semigroup1 classes

[Edward Kmett]

Re 2 for rank-2, there is already precedent for using 2 for lifting over
two arguments, so semantic confusion sadly remains:

E.g.

Eq2 p means Eq a, Eq b => Eq (p a b)

or

Eq2 p means Eq a => Eq1 (p a)

-Edward

On Sat, Oct 1, 2016 at 11:08 AM, Mario Blažević <blamario at ciktel.net> wrote:

> On 2016-10-01 04:07 AM, Edward Kmett wrote:
>
>> I'm somewhat weakly against these, simply because they haven't seen broad
>> adoption in the wild in any of the attempts to introduce them elsewhere,
>> and they don't quite fit the naming convention of the other Foo1 classes in
>> Data.Functor.Classes
>>
>> Eq1 f says more or less that Eq a => Eq (f a).
>>
>> Semigroup1 in your proposal makes a stronger claim. Semgiroup1 f  is
>> saying forall a. (f a) is a semigroup parametrically. Both of these
>> constructions could be useful, but they ARE different constructions.
>>
>
>     The standard fully parametric classes like Functor and Monad have no
> suffix at all. It makes sense to reserve the suffix "1" for non-parametric
> lifting classes. Can you suggest a different naming scheme for parametric
> classes of a higher order?
>
>     I'm also guilty of abusing the suffix "1", at least provisionally, but
> these are different beasts yet again:
>
>   -- | Equivalent of 'Functor' for rank 2 data types
>   class Functor1 g where
>   fmap1 :: (forall a. p a -> q a) -> g p -> g q
>
> https://github.com/blamario/grampa/blob/master/Text/Grampa/Classes.hs
>
>     What would be a proper suffix here? I guess Functor2 would make sense,
> for a rank-2 type?
>
>
>
>> If folks had actually been using, say, the Plus and Alt classes from
>> semigroupoids or the like more or less at all pretty much anywhere, I could
>> maybe argue towards bringing them up towards base, but I've seen almost
>> zero adoption of the ideas over multiple years -- and these represent yet
>> _another_ point in the design space where we talk about semigroupal and
>> monoidal structures where f is a Functor instead. =/
>>
>> Many points in the design space, and little demonstrated will for
>> adoption seems to steers me to think that the community isn't ready to pick
>> one and enshrine it some place central yet.
>>
>> Overall, -1.
>>
>> -Edward
>>
>> On Fri, Sep 30, 2016 at 7:25 PM, David Feuer <david.feuer at gmail.com
>> <mailto:david.feuer at gmail.com>> wrote:
>>
>>     I've been playing around with the idea of writing Haskell 2010
>>     type classes for finite sequences and non-empty sequences,
>>     somewhat similar to Michael Snoyman's Sequence class in
>>     mono-traversable. These are naturally based on Monoid1 and
>>     Semigroup1, which I think belong in base.
>>
>>     class Semigroup1 f where
>>       (<<>>) :: f a -> f a -> f a
>>     class Semigroup1 f => Monoid1 f where
>>       mempty1 :: f a
>>
>>     Then I can write
>>
>>     class (Monoid1 t, Traversable t) => Sequence t where
>>       singleton :: a -> t a
>>       -- and other less-critical methods
>>
>>     class (Semigroup1 t, Traversable1 t) => NESequence where
>>       singleton1 :: a -> t a
>>       -- etc.
>>
>>     I can, of course, just write my own, but I don't think I'm the
>>     only one using such.
>>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>>
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161001/7284b72e/attachment.html>