On Sun, Aug 14, 2011 at 6:54 PM, Yitzchak Gale
Johan Tibell wrote:
This doesn't work well unless SemiGroup is a superclass of Monoid. For example, class constraints would have to include redundant information
Just like for Functor and Monad, Applicative and Monad, etc.
Right. And we have no good way of fixing that, so until we do we leave it alone. The same goes for a different numerical tower etc. However, we can add an operator for monoids, making them easier to use. When we have the language means to add SemiGroups in a way that makes sense, we'll do so. We don't at the moment. We're not going to stop changing base because someone added an operator with the same name as we'd like to use in some package on Hackage.
Semigroup should have been defined at the same time as Monoid. But it wasn't.
In general it's not possible to predict all the levels can could potentially exists "above" a type class. That doesn't mean we shouldn't define the type class we know of at the moment.
This proposal is exactly analogous to proposing that we rename 'return' to 'pure', because it is shorter. And because, after all, Monad is use much more than Applicative. But that would obviously be really wrong. You can already use 'pure' instead of 'return' - just make sure that the Monad also has an Applicative instance. Bother the library author if it doesn't have one yet. Making that change would cause a huge mess.
No it's not the same. Renaming return to pure would break lots of code. Adding <> doesn't have anywhere near the same implications.
Haven't we learned anything from the years of plodding through the Functor - Applicative - Monad situation, and other problems with the class system? Until we get a way of fixing those things, please, let's think very carefully before we make changes like this that have a potential for widespread long-term damage.
There's no way to be careful in this sense. The number of potential superclasses is unknown. Lets instead focus on a way to deal with that. Cheers, Johan