Proposal #3339: Add (+>) as a synonym for mappend

[Johan Tibell]

On Sun, Aug 14, 2011 at 6:54 PM, Yitzchak Gale <gale at sefer.org> wrote:
> 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