What I'm doing is pushing out a new major version of semigroups that adds the export of Monoid(..) to the subset of Data.Monoid that it re-exports. I'm also changing its associativity to the right to match the one that tibbe is going to put into Data.Monoid. <div>
<br></div><div>This is arguably better behavior as it causes <> to be incompatible with + so you have to parenthesize (good), but associates to the right so that libraries like pretty printers (those which didn't have the foresight to use codensity to fix up the asymptotics of left associated <>) get the right asymptotic behaviors. <div>
<br></div><div>This way if you want to work with semigroups and monoids you </div><div><br></div><div>import Data.Semigroup</div><div><br></div><div>And if you want to work with monoids using the <> operator, then you </div>
<div><br></div><div>import Data.Monoid</div><div><br></div><div>This will let me more or less just go through and delete the import Data.Monoid lines from each of my other packages,</div><div>and means that the users of semigroups don't have to muck around with qualified imports.</div>
<div><br></div><div>Semantically the fact that Data.Semigroup exports Monoid is a bit wrong, but it is less wrong than forcing every user to juggle qualified imports.</div><div><br></div><div>Malcolm sent out a downstream list for semigroups, almost all of the direct dependencies are mine. </div>
<div><br></div><div>I will make this change immediately to my other libraries.</div><div><br></div><div>The indirect dependencies don't import Data.Semigroup and as of last week, I no longer re-export Data.Semigroup from any package, so the indirect dependencies should have no problems.</div>
<div><br></div><div>-Edward<br><br><div class="gmail_quote">On Mon, Aug 15, 2011 at 11:09 AM, Yitzchak Gale <span dir="ltr"><<a href="mailto:gale@sefer.org">gale@sefer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Sebastian Fischer wrote:<br>
> The proposal is not to replace 'mappend' in the Monoid class with <>. The<br>
> proposal is to add the top-level definition<br>
> (<>) = mappend<br>
> to Data.Monoid.<br>
<br>
</div>Thanks Sebastian, you're right, I misread that. I wouldn't have<br>
made nearly as much noise then. It's still bad to have two<br>
definitions of <> that appear to be the same but are in reality<br>
two different functions. But in the short term, that won't cause<br>
me nearly as much damage.<br>
<br>
In the long term, it is perhaps worse. It means that now even<br>
superclass defaulting won't completely solve the problem -<br>
you can silently get the wrong function without noticing.<br>
That would be a very difficult bug to find.<br>
<br>
Note that this is worse than, for example, libraries that shadow<br>
Prelude functions. There, if you don't use the right qualified/hiding<br>
incantation, you'll generally get a compile error.<br>
<br>
Anyway, I apologize for grossly overreacting. If anyone needs<br>
me in the near future, please look inside the hole I am<br>
currently digging for myself.<br>
<div><div></div><div class="h5"><br>
Thanks,<br>
Yitz<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div>