Superclass defaults

[wren ng thornton]

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