Re: Refactoring Semigroup/Monoid (was: instance Applicative Data.Map)

On Fri, Nov 16, 2012 at 3:06 PM, Herbert Valerio Riedel wrote:

Edward A Kmett 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