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 <bluemangrou...@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 > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe