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

[Edward Kmett]

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:

infixr 6 <>

and to change the associativity of <+> in Text.PrettyPrint.HughesPJ to
match, so that they can be intermixed. Version 3.0 of the HughesPJ
combinators, released back in 1997 has fixed any performance regression that
would be caused by changing the associativity. I hope everyone will have
upgraded by now. ;)

This binds slightly tighter than ++, but retains the same asymptotic
performance, works with == <=, etc. and only requires the minor
associativity tweak to HughesPJ, which should be allowed just fine under the
pretty printer combinator laws, so exxisting HughesPJ code should continue
to run just fine, and other existing code wouldn't be using the new
operator, so shouldn't require any tweaks.

-Edward Kmett

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

> On Thu, 2009-09-17 at 14:37 +0100, Ross Paterson wrote:
>
> > This proposal seems to have got stuck.  Everyone wants an infix operator,
> > but we can't agree what it should be.
> >
> > I prefer using a new operator instead of generalizing ++ (or +, *, &&
> > or ||), because I think that a monoid operation is so abstract that it
> > needs a name that doesn't suggest one of the special cases.  (I like <>)
>
> Nice. For some reason I much prefer a symbol like <> to one like +>.
>
> I want to say that it's because it looks symmetric, though of course
> mappend, ++ are associative not symmetric, so it's not a very good
> argument. But I still like it! :-)
>
> So I guess we should adjust the proposal, or make a new one.
>      * Suggest the name <> (which so far seems to have popular support)
>      * Get rid of the suggestion for a reverse mappend operator
>      * As Krasimir says, include in the proposal that we would deal
>        with the existing libraries that use a local <> for their
>        mappend operator (at least Text.PrettyPrint).
>
> One thing we've not mentioned much is operator precedence. Existing
> uses:
>  infixr 5 Data.Sequence.><
>  infixl 6 Text.PrettyPrint.<>
> Existing proposal about (+>)
>  infixl 4 +>
>
> Duncan
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090918/de887a80/attachment.html