Edward A Kmett <ekmett@gmail.com> writes:

[...]

> Sadly, I've mostly given up on even convincing folks to refactor
> Monoid to pull out Semigroup which I view pragmatically as a
> prerequisite to including something like Apply or Bind in a serious
> hierarchy reform proposal.
>
> When someone raised adding Semigroup during the (<>) = mappend
> proposal the idea was quickly derided and dismissed.

btw, I didn't have the impression that it was "derided" but the issue
seemed to be (iirc -- please correct me if I got it wrong) that adding
'Semigroup' as a separate typeclass would break code, as it would
require to replace occurences of the constraint 'Monoid a =>' to
'(Monoid a, Semigroup a) =>', and for some reason I don't recall right
now making Semigroup a superclass of Monoid wasn't an option either.

IMHO, if we have a Monoid class in the standard/base libraries, we
should have a Semigroup class as well there sooner or later..

This comes up once every so often (typically in discussion about Functor, Applicative, and Monad). I don't want to rehash the arguments here (they are in the archives). Adding new superclasses breaks a lot of code for little gain for most people. We need a technical solution to this problem first, before we can refactor our type hierarchy.

-- Johan