Proposal: add Monoid1 and Semigroup1 classes

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.

On 2016-09-30 07:25 PM, David Feuer 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.
If the proposal is to add these directly to base, I'm against it. New classes should first be released in a regular package, and only moved to base once they prove useful.
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.

It seems to me that Data.Functor.Classes is the natural place for these,
but I guess I could stick them somewhere else.
On Sep 30, 2016 9:09 PM, "Mario Blažević"
On 2016-09-30 07:25 PM, David Feuer 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.
If the proposal is to add these directly to base, I'm against it. New classes should first be released in a regular package, and only moved to base once they prove useful.
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.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

"MB" == Mario Blažević
writes:
MB> If the proposal is to add these directly to base, I'm against it. New MB> classes should first be released in a regular package, and only moved to MB> base once they prove useful. I'd like to second this. I like the ideas, and would like to see them develop; but not in base as the starting place. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

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

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
mailto:david.feuer@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@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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ć
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
mailto:david.feuer@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@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
participants (4)
-
David Feuer
-
Edward Kmett
-
John Wiegley
-
Mario Blažević