Proposal: Make Semigroup as a superclass of Monoid

[Edward Kmett]

Consider me a +1 on this.

There are some unmentioned caveats here:

* We may want/need a slightly longer release schedule.
* `Monoid` is in the Prelude, so this would drag `Semigroup` into the
Prelude.

I see two ways to proceed.

The long path:

A straw-man fleshed out version of your proposal that addresses the "sudden
change to Prelude" issues some folks have would be:

7.12: Move Data.Semigroup and Data.List.NonEmpty into base. Add a warning
about definitions of an operator named (<>) that indicate it will be coming
into Prelude in 7.14. We should warn about missing Semigroup instances at
any use site of (<>) as they'll break in 7.14.

7.14: Move Semigroup and (<>) into the Prelude in 7.14. Add a warning about
missing Semigroup instances for any Monoid instance at all.

7.16: Make Semigroup a superclass of Monoid. Fix the instance Semigroup a
=> Monoid (Maybe a).

Alternate long path:

Simplify the warnings. Simply warn about any missing Semigroup instance
when you define a Monoid instance in 7.12, so the 7.14 changes become
simply a migration into Prelude. The downside is that people would now get
a warning that force them to import a module that will be redundant in the
next release. =/

The short path:

Collapse the first two steps into one step, but this means that nobody gets
any warning of new names coming into the Prelude. On the other hand this
would get us all the way to done by 7.14. On one hand, the first order
consequence the amount of breakage caused by adding Semigroup to Prelude
and taking (<>) is almost entirely confined to a handful of pretty printing
libraries -- and we already broke those same libraries by taking (<$>).
Sadly a second order consequence is that folks import Data.Monoid to get
(<>) today, and this would change to demanding a Semigroup constraint, so
the fused release would actually cause almost as much breakage as doing it
all in one go, among anybody that actually uses the (<>) in Data.Monoid.

I have a preference for one of the long paths, as they at no point break
someone without warning.

We could run a poll to see which folks would prefer.

Having default superclass instance machinery would go a long way towards
simplifying this story, but I think we've held up all progress on almost
everything for the better part of two decades waiting for that situation to
resolve without progress.

-Edward Kmett

On Sun, Mar 29, 2015 at 8:20 AM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150330/12eace63/attachment.html>