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.
This way if you want to work with semigroups and monoids you
import Data.Semigroup
And if you want to work with monoids using the <> operator, then you
import Data.Monoid
This will let me more or less just go through and delete the import Data.Monoid lines from each of my other packages,
and means that the users of semigroups don't have to muck around with qualified imports.
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.
Malcolm sent out a downstream list for semigroups, almost all of the direct dependencies are mine.
I will make this change immediately to my other libraries.
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.
-Edward
On Mon, Aug 15, 2011 at 11:09 AM, Yitzchak Gale
<gale@sefer.org> wrote:
Sebastian Fischer wrote:
> The proposal is not to replace 'mappend' in the Monoid class with <>. The
> proposal is to add the top-level definition
> (<>) = mappend
> to Data.Monoid.
Thanks Sebastian, you're right, I misread that. I wouldn't have
made nearly as much noise then. It's still bad to have two
definitions of <> that appear to be the same but are in reality
two different functions. But in the short term, that won't cause
me nearly as much damage.
In the long term, it is perhaps worse. It means that now even
superclass defaulting won't completely solve the problem -
you can silently get the wrong function without noticing.
That would be a very difficult bug to find.
Note that this is worse than, for example, libraries that shadow
Prelude functions. There, if you don't use the right qualified/hiding
incantation, you'll generally get a compile error.
Anyway, I apologize for grossly overreacting. If anyone needs
me in the near future, please look inside the hole I am
currently digging for myself.