Proposal: Make Semigroup as a superclass of Monoid

Carter Schonwald carter.schonwald at
Mon Mar 30 00:44:51 UTC 2015

my one concern is that we'd be force to give all the various map data
structures out there a left biased "First" style semigroup instance if we
keep the current default monoid instances that containers and list-tries
provide for historical reasons. and at least in the applications i write, i
want the semigroup that merges those keys.

On Sun, Mar 29, 2015 at 3:14 PM, Evan Laforge <qdunkan at> wrote:

> On Sun, Mar 29, 2015 at 5:20 AM, Jeremy <voldermort at> wrote:
> > 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.
> I think I'm generally in favor, but in my experience is the reverse of
> this.  I have tons of Monoids and only a few Monads.  All of my Monads
> also had Applicative defined because I wanted to use (<$>) and (<*>),
> however none of my Monoids have Semigroup, because they all have a
> natural mempty, and there's nothing "extra" in Semigroup that would
> tempt me to add an instance.  So while AMP meant no changes for me,
> "Semi MP" would definitely force code changes in many places (every
> 'instance .*Monoid', which is 31 in one project).
> That said I don't have to worry about backward compatibility so I
> don't mind.  For someone who maintains libraries, they would have to
> add a dependency on 'semigroup', which is going to pull in a number of
> other dependencies, but it mostly seems to be stuff people are
> probably already depending on.  Except unordered-containers maybe.
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list