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

[Johan Tibell]

On Fri, Nov 16, 2012 at 3:06 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> Edward A Kmett <ekmett at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121116/2e098afe/attachment.htm>