There are many reasons, but some of the more cited ones are that (<>) will break less code than (++) would, since (++) is ubiquitous and (<>) is most used in some pretty printers. Yes, mappend's type can be refined to that of the current list (++), but the increased polymorphism still has the potential to break existing code by making it harder to resolve instances.

As for (<>) meaning not equal to, do you also have a problem with Monad's (>>) meaning a right bitwise shift, or the mutationey form of it, (>>=)? :) I don't think anyone in Haskell has ever used (<>) to mean (/=), so the fact that there exist a couple of languages out there that do use it that way shouldn't affect our decision.

Dan

On Sun, Apr 1, 2012 at 4:58 PM, aditya bhargava <bluemangroupie@gmail.com> wrote:
After asking this question:
http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-texts-without-mappend

I found out that the new infix operator for `mappend` is (<>). I'm wondering why ghc 7.4 didn't generalize (++) to work on monoids instead. To me, (++) is much more clear. (<>) means "not equal to" for me. Can anyone shed light on this decision?


Adit

--
adit.io

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe