Proposal: Make Semigroup as a superclass of Monoid

[Erik Hesselink]

While I like the idea, there are some differences from the
Applicative/Monad situation. Most Monads already had an Applicative
instance. Monoids, on the other hand, often don't have a Semigroup
instance, if only because it lives in a different package. In most
cases where I depended on this package, it was because my Semigroup
*wasn't* a Monoid. So if I had to guess, this might cause more work
for people than the AMP.

There are also some details to figure out. There are a couple of name
clashes between the semigroups package and Monoid: (<>), as mentioned,
but also the newtypes First and Last (with different definitions). How
will this all end up, and what is the migration path?

I think ideally we'd want (<>) in Semigroup. As for First and Last, as
the semigroups docs say, you can get the Monoid versions with Option
(First a), but deprecating and removing the Monoid versions will
probably cause a lot of breakage. Alternatively, we could have two
types with the same name in different modules, but that also doesn't
sound ideal, or we could rename the semigroups ones, but that also
seems like it would cause a difficult migration. Does anyone have good
ideas about this?

Regards,

Erik

On Sun, Mar 29, 2015 at 2:20 PM, Jeremy <voldermort at hotmail.com> wrote:
> The proposal to make Semigroup a superclass of Monoid was discussed a while
> ago [1], and the conclusion was to "put this off until the dust has settled
> from the AMP and FT changes".
>
> Now that 7.10 is out, I would like to re-propose. The proposed plan is
> similar to AMP, but less invasive, as (in my subjective experience)
> user-defined Monoids are much less common than user-defined Monads.
>
> 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid
> instances, and anything else which forms a Semigroup, will have a Semigroup
> instance. GHC will issue a warning when it encounters an instance of Monoid
> which is not an instance of Semigroup.
>
> 2. GHC >7.12 will define Monoid as a subclass of Semigroup.
>
> Stage 2 could be delayed - or in the extreme case, cancelled - if the
> warnings following stage 1 indicate that the proposal would cause
> significant breakage of existing code, although this is not anticipated.
>
> The rationale for this change is:
>
> 1. Semigroup is a popular package (this is relevant in combination with the
> following point).
> 2. Using an existing Monoid as a Semigroup requires redefining it (or
> WrappedMonoid), leading to much boilerplate and duplication.
> 3. NonEmpty is often redefined by beginners (or those who don't think it's
> worth having an extra dependency for).
>
> [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html
>
>
>
> --
> View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries