On Fri, Nov 16, 2012 at 3:06 PM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Edward A Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> writes:<br>
<br>
[...]<br>
<br>
> Sadly, I've mostly given up on even convincing folks to refactor<br>
> Monoid to pull out Semigroup which I view pragmatically as a<br>
> prerequisite to including something like Apply or Bind in a serious<br>
> hierarchy reform proposal.<br>
><br>
> When someone raised adding Semigroup during the (<>) = mappend<br>
> proposal the idea was quickly derided and dismissed.<br>
<br>
btw, I didn't have the impression that it was "derided" but the issue<br>
seemed to be (iirc -- please correct me if I got it wrong) that adding<br>
'Semigroup' as a separate typeclass would break code, as it would<br>
require to replace occurences of the constraint 'Monoid a =>' to<br>
'(Monoid a, Semigroup a) =>', and for some reason I don't recall right<br>
now making Semigroup a superclass of Monoid wasn't an option either.<br>
<br>
IMHO, if we have a Monoid class in the standard/base libraries, we<br>
should have a Semigroup class as well there sooner or later..<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>-- Johan</div><div><br></div></div>