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