<div dir="ltr">I find myself somewhat on the fence about this proposal.<div><br></div><div style>Ultimately, I&#39;d like to see semigroups in base.</div><div style><br></div><div style>That said doing so with the current changes in flight is somewhat awkward, and introducing it carries a lot of distributed work.</div>
<div style><br></div><div style>We have two outstanding proposals that have received overwhelming support: namely the Applicative =&gt; Monad (AMP) proposal and the generalization of the types in the Prelude for mapM, etc. to use Foldable and Traversable (FT). Between these two proposals, we wind up with the need to bring in Foldable, Traversable, Applicative and Monoid into the Prelude. Applicative as a superclass of Monad and for traverse and Monoid because Foldable brings in foldMap.</div>
<div style><br></div><div style>Consequently fixing the situation to make Semigroup a superclass of Monoid isn&#39;t something that can be done purely by adding a module to base, but it would infect Prelude. </div><div style>
<b><br></b></div><div style>This makes it have to clear a much higher bar!</div><div style><br></div><div style>A real proposal that involved adding Semigroup as a superclass of Monoid could possibly be concocted like David&#39;s AMP patch, whereupon Monoid would be given a default mappend = (&lt;&gt;)<br>
</div><div style><br></div><div style>That could enable users to just have to write an extra instance line like they would for the AMP, but it has some immediate headaches. </div><div style><br></div><div style>In particular (&lt;&gt;) has been in use in pretty printing libraries since time immemorial. Suddenly exporting a version from the Prelude is likely to be a fairly breaking change to those libraries as the associativity of the (&lt;&gt;) provided by Data.Monoid (and the one provided by Data.Semigroup) both disagree with the (&lt;&gt;) in Text.PrettyPrint.HughesPJ, which is in the platform already. This could lead to some rather annoying breakages -- worse, silent breakages. I seem to recall that there was some concern that this would change the output of some pretty printing in GHC when the associativity issue was last raised on this list over the introduction of (&lt;&gt;).</div>
<div style><br></div><div style>I think to have a serious proposal that could actually be accepted, a lot of work would have to be put into a patch and then it would need to be explored how much the associativity issue bites users in practice along with gauging the amount of effort that would be involved in retrofitting semigroup instances into virtually everyone&#39;s libraries.</div>
<div style><br></div><div style><div>My knee jerk reaction is to try to put this off until the dust has settled from the AMP and FT changes and push back with a request for the necessary analysis.</div><div><br></div></div>
<div style>-Edward</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 11, 2013 at 5:05 PM, Mario Blažević <span dir="ltr">&lt;<a href="mailto:blamario@acanac.net" target="_blank">blamario@acanac.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 06/11/13 14:46, John Wiegley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. I propose that we add the following package to base:<br>
<br>
      <a href="http://hackage.haskell.org/packages/archive/semigroups/0.9.2/doc/html/Data-Semigroup.html" target="_blank">http://hackage.haskell.org/<u></u>packages/archive/semigroups/0.<u></u>9.2/doc/html/Data-Semigroup.<u></u>html</a><br>

<br>
    This is somewhat in the spirit of the AMP proposal: further improving the<br>
    correctness of our algebraic abstractions.<br>
</blockquote>
<br>
<br></div>
    I was wondering how much longer until this proposal came up. +1 from me in general, but I have some quibbles with details.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. That we make Semigroup a superclass of Monoid, so that (minimally):<br>
<br>
      class Semigroup a where<br>
          (&lt;&gt;) :: a -&gt; a -&gt; a<br>
<br>
      class Semigroup a =&gt; Monoid a where<br>
          mempty :: a<br>
          mconcat :: [a] -&gt; a<br>
          mconcat = foldr (&lt;&gt;) mempty<br>
<br>
      mappend :: Semigroup a =&gt; a -&gt; a -&gt; a<br>
      mappend = (&lt;&gt;)<br>
</blockquote>
<br>
<br></div>
    +1, though I&#39;d prefer to leave mappend restricted to the Monoid class. In the long term, I&#39;d rather have it killed off than kept as a synonym for (&lt;&gt;). Besides, it&#39;s m(onoid)append.<div class="im"><br>

<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. (Optional, recommended) There are other useful functions that can be added<br>
    to Semigroup, such as sconcat and times1p, but I will let Edward speak to<br>
    whether those should be proposed at this time.<br>
</blockquote>
<br>
<br></div>
    They should be added in now or never, there&#39;s no reason to break compatibility twice. I don&#39;t think times1p can be accepted in its current form as it depends on a different library. Edward, can you make a concrete proposal for these?<br>

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
4. (Optional, recommended) That we fix the Monoid instance for Maybe to be:<br>
<br></div><div class="im">
     instance Semigroup a =&gt; Monoid (Maybe a) where<br>
          mempty = Nothing<br>
</div></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
     instance Semigroup a =&gt; Semigroup (Maybe a) where<br>
          Just x &lt;&gt; Just y = Just (x &lt;&gt; y)<br></div><div class="im">
          Nothing &lt;&gt; x = x<br>
          x &lt;&gt; Nothing = x<br>
</div></blockquote>
<br>
<br>
+1<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>