Class Multiplicity

[Ketil Z. Malde]

Ashley Yakeley <ashley@semantic.org> writes:

> I have a curious Haskell design pattern. It's called "one class per 
> function".

[...]

> I'm not sure if this is a good thing or a bad thing or what.

In many cases, I think a finer split would be advantageous, e.g. the
much-debated "Num".  One obvious disadvantage is that a lot of inferred
type classes may become less readable (:t saying "Num a => .." is
probably more informative for many than "CommutativeRing a => ..") 

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants