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

Nicolas Pouillard nicolas.pouillard at gmail.com
Fri Sep 18 12:21:33 EDT 2009


Excerpts from Edward Kmett's message of Fri Sep 18 16:04:47 +0200 2009:
> I'ved chewed on the associativity and precedence issue for <> a little bit.
> Here are my thoughts.
> 
> infixl 6 <> would match the precedence of +, which is nice on paper, and how
> I happen to implement (+) in Data.Monoid.Sugar in the monoids library. I now
> believe that it is not quite right.
> 
> On paper infixr vs. infixl is basically irrelevant because the result is
> monoidal, but in practice infixr tends to work better for a lot of real
> world monoids we care about like list appending. Take a look at the behavior
> of ((... ++ b) ++ c) vs (a ++ (b ++ ...) for a compelling justification for
> why infixr is probably better in practice for the poster child of the monoid
> lineup.
> 
> 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
> <>.
> 
> So, in light of all of that, it would seem that the most compatible general
> change would be to set:

Good work.

> infixr 6 <>

+1

-- 
Nicolas Pouillard
http://nicolaspouillard.fr


More information about the Libraries mailing list