On 8/15/11 7:44 AM, Conor McBride wrote:
This is a recurring issue, at least as far as mailing list heat is concerned, but it would be good to have more evidence of substantial impact. The Monoid vs Semigroup issue is a case in point, perhaps. Folks, what do you think?
For my work it'd certainly be helpful to have Semigroup broken out as a superclass of Monoid. So far it hasn't been important enough to make me want to pull in the semigroups package, but adding it to base would help clean things up.
One problem I see, though, is the question of what exactly is the "right" hierarchy to use. In particular, for the work I do, refactoring Monoid very quickly runs into the need for a Semiring class to replace/refactor Num, which opens an enormous can of worms. This is part of the reason why I continually bring up the fact that the various attempts at refactoring the numeric hierarchy fail, in that they ignore semirings and run off headlong towards fields and vector spaces (which are of less concern for my work; though I'd like to see modules in lieu of vector spaces).
Of course, the real problem is that we are only allowed to have one instance for a given type, whereas semirings/rings/fields/etc are defined by having two instances which interlock in special ways. This means that a proper semiring/monoid/group hierarchy is going to be inherently at odds with a proper semiring/ring/field hierarchy. I've yet to come up with a solution to this conundrum which I actually like.
-- Live well, ~wren _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
