<div dir="ltr">Consider me a +1 on this.<div><br></div><div>There are some unmentioned caveats here:</div><div><br></div><div>* We may want/need a slightly longer release schedule.</div><div>* `Monoid` is in the Prelude, so this would drag `Semigroup` into the Prelude.</div><div><br></div><div>I see two ways to proceed.</div><div><br></div><div>The long path:</div><div><br></div><div>A straw-man fleshed out version of your proposal that addresses the "sudden change to Prelude" issues some folks have would be:</div><div><br></div><div>7.12: Move Data.Semigroup and Data.List.NonEmpty into base. Add a warning about definitions of an operator named (<>) that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of (<>) as they'll break in 7.14.</div><div><br></div><div>7.14: Move Semigroup and (<>) into the Prelude in 7.14. Add a warning about missing Semigroup instances for any Monoid instance at all.</div><div><br></div><div>7.16: Make Semigroup a superclass of Monoid. Fix the instance Semigroup a => Monoid (Maybe a).</div><div><br></div><div><div>Alternate long path:</div><div><br></div><div>Simplify the warnings. Simply warn about any missing Semigroup instance when you define a Monoid instance in 7.12, so the 7.14 changes become simply a migration into Prelude. The downside is that people would now get a warning that force them to import a module that will be redundant in the next release. =/</div></div><div><br></div><div>The short path:</div><div><br></div><div>Collapse the first two steps into one step, but this means that nobody gets any warning of new names coming into the Prelude. On the other hand this would get us all the way to done by 7.14. On one hand, the first order consequence the amount of breakage caused by adding Semigroup to Prelude and taking (<>) is almost entirely confined to a handful of pretty printing libraries -- and we already broke those same libraries by taking (<$>). Sadly a second order consequence is that folks import Data.Monoid to get (<>) today, and this would change to demanding a Semigroup constraint, so the fused release would actually cause almost as much breakage as doing it all in one go, among anybody that actually uses the (<>) in Data.Monoid.</div><div><br></div><div>I have a preference for one of the long paths, as they at no point break someone without warning. <br></div><div><br></div><div>We could run a poll to see which folks would prefer.</div><div><br></div><div>Having default superclass instance machinery would go a long way towards simplifying this story, but I think we've held up all progress on almost everything for the better part of two decades waiting for that situation to resolve without progress.</div><div><br></div><div><div>-Edward Kmett</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 29, 2015 at 8:20 AM, Jeremy <span dir="ltr"><<a href="mailto:voldermort@hotmail.com" target="_blank">voldermort@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The proposal to make Semigroup a superclass of Monoid was discussed a while<br>
ago [1], and the conclusion was to "put this off until the dust has settled<br>
from the AMP and FT changes".<br>
<br>
Now that 7.10 is out, I would like to re-propose. The proposed plan is<br>
similar to AMP, but less invasive, as (in my subjective experience)<br>
user-defined Monoids are much less common than user-defined Monads.<br>
<br>
1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid<br>
instances, and anything else which forms a Semigroup, will have a Semigroup<br>
instance. GHC will issue a warning when it encounters an instance of Monoid<br>
which is not an instance of Semigroup.<br>
<br>
2. GHC >7.12 will define Monoid as a subclass of Semigroup.<br>
<br>
Stage 2 could be delayed - or in the extreme case, cancelled - if the<br>
warnings following stage 1 indicate that the proposal would cause<br>
significant breakage of existing code, although this is not anticipated.<br>
<br>
The rationale for this change is:<br>
<br>
1. Semigroup is a popular package (this is relevant in combination with the<br>
following point).<br>
2. Using an existing Monoid as a Semigroup requires redefining it (or<br>
WrappedMonoid), leading to much boilerplate and duplication.<br>
3. NonEmpty is often redefined by beginners (or those who don't think it's<br>
worth having an extra dependency for).<br>
<br>
[1] <a href="https://mail.haskell.org/pipermail/libraries/2013-June/020188.html" target="_blank">https://mail.haskell.org/pipermail/libraries/2013-June/020188.html</a><br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html" target="_blank">http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html</a><br>
Sent from the Haskell - Libraries mailing list archive at Nabble.com.<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>