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.
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
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.
Thanks, Yitz
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries