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@gmail.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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries