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

[Edward Kmett]

Whichever way you go on this someone might get (slightly) annoyed, since:

Text.PrettyPrint.Leijen
infixr 6 <>,<+>

Text.PrettyPrint.HughesPJ
infixl 6 <>,<+>

So ultimately someone is getting their associativity changed!

However, the motivation for infixr <> is quite simple, it is better for the
list like concatenation and even for the pretty printing scenario you cite.

It was odd to me that the HughesPJ combinators chose to associate to the
left given that the code has lots of hacks to reassociate everything to the
right. There is a discussion of the hacks they introduced in version 3 in
the source code to fix the asymptotics of foldl (<>). However, the code
there operates just fine with either associativity, and even becomes a bit
more efficient when associated to the right a priori. This was the
substance of the discussion back in September of 09 when the final
associativity and fixity were chosen.

It needs to be at least 6 to avoid conflict with (:) and (++). (See the
original analysis for more)

On a more selfish note, when this was proposed a few weeks ago, and the
issue of compatibility with Data.Semigroup was raised, I went through and
changed the associativity of (<>) in Data.Semigroup and its use in all of
its dependents to match the proposed infixr associativity.

I'm loathe to revert a half of those changes and to recolor this bikeshed
again.

Ultimately no code breaks, after all it is changing the associativity of an
operator that is by definition *associative*. ;)

-Edward

On Sun, Nov 6, 2011 at 2:59 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Sun, Nov 6, 2011 at 9:40 AM, Malcolm Wallace <malcolm.wallace at me.com>wrote:
>
>> So what is the rationale for the new Monoidal operator <> to be declared
>> infixr 6?  Why can it not simply preserve the same fixity as already used
>> by Pretty's <> ?
>>
>
> Could someone put together a list of the operators in base and
> their precedence. Does making <> have precedence 6 change anything? It has
> right associativity because it's the right thing for "stream like" uses of
> <> (lists, builders, CPS).
>
> Aside: I don't think we should try to avoid collisions with downstream
> symbols when growing the base libraries. It's just not a scalable approach
> engineering wise. We should use namespaces to distinguish symbols from
> different packages.
>
> -- Johan
>
>
> _______________________________________________
> 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/20111106/1d99a759/attachment.htm>