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

[Edward Kmett]

On Fri, Sep 18, 2009 at 5:28 PM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk>wrote:

> 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.


Sorry, I didn't mean to imply that the extra level between <> and == was
purely for compatibility with Eq and Ord. Perhaps those were the wrong
example, but there is a case to be made for wanting to keep the number of
hard-to-predict consequences of precedence changes to a minimum.

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 ++.
>


I don't know, and I don't know that anyone can know what other operators
people have used in code that uses HughesPJ or any of the other pretty
printer combinator libraries. Most compelling, is that there is an implicit
'infixr 5 :' in the Prelude and the pretty printer combinator libraries use
[Doc] all over the place. So moving one level down would break a lot of
pretty printer client code.

As a happy side note Text.PrettyPrint.Leijen already contains infixr 6 <>
and requires no changes other than the optional cleanup of using the new
operator. ;)

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090918/1d0dcd11/attachment-0001.html