#3339: Data.Monoid: Add (+>) as a synonym for mappend
------------------------------+---------------------------------------------
Reporter: bos | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/base | Version: 6.10.3
Severity: normal | Resolution:
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
------------------------------+---------------------------------------------
Comment (by JulesBean):
There is no universal convention that symmetric-looking operators should
be commutative.
However, it is certainly a handy visual guide.
To address specific points:
(&&) looks commutative to me, and it *is* commutative, in the _|_ free
fragment of haskell. That's the fragment I most commonly reason about. You
don't get many algebraic laws without that. Similarly (||).
(>>) looks uncommutative - it's not about repeated symbols, it's about the
way the > symbols obviously 'point' in one direction. And, (>>) *is*
noncommutative, of course.
Concrete advantages for (+>):
* It has a symbol which visually indicates direction, and mappend is
often a directional operation in some sense;
* It can be 'naturally' flipped to yield <+; it's useful to have a short
name for flip mappend.
The latter is the key point. The reason to use +> is so we can use <+.
I rejected using (++) not just because it looks too symmetric (that's not
a big problem, it doesn't confuse people too much) but simply because the
backwards-compatibility damage of changing the type of a very very widely
used operator is very significant.
By contrast, (+>) is not used in any widely used libraries, certainly not
in base, and the backwards-compatibility damage of adding a new symbol to
Data.Monoid is relatively low. No worse than adding any other new function
to an API.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3339#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
