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

[Duncan Coutts]

On Fri, 2009-09-18 at 10:04 -0400, Edward Kmett wrote:
> I'ved chewed on the associativity and precedence issue for <> a little
> bit. Here are my thoughts.

Thanks for the analysis. There's just one bit I don't quite follow.

> Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity
> as ++, which also seems like a good answer at first, but infixr 5 <>
> would change the behavior of programs that use
> Text.PrettyPrint.HughesPJ, which relies on the fixity of <> and <+>
> being higher than $$ and $+$ which are infixl 5.

> The original proposed infixr/l 4 is low enough that you couldn't even
> mix the use of <> with the various comparators from Eq and Ord, and it
> exacerbates all of the above issues -- by inverting the precedence of
> $$ and <> -- so I think it should be off the table. For similar
> reasons I don't like lowering the fixity off $$ and $+$ in HughesPJ to
> 4 to permit infixr 5 <>.

It's not clear to me why changing the fixity of $$ and $+$ would be bad.
I see that using infixl/r for <> would be bad because we cannot mix >=
etc with <> and there are obviously many types that can be in Monoid and
Ord. On the other hand Doc is not in any type classes except Show. So I
don't see that the point applies to the HughesPJ lib.

> So, in light of all of that, it would seem that the most compatible
> general change would be to set:
> 
> infixr 6 <>

Of course one could argue that you might want a type in Monoid and Ord
and have a spare precedence level between <> and >=. But I don't see how
we can claim it's necessary for compatibility reasons.

If we do need a spare precedence level between <> and >= then fine, but
all things being equal it seems preferable to go with the same
precedence as ++.

Duncan