[Haskell-cafe] Generalizing (++) for monoids instead of using (<>)

[Daniel Peebles]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120401/2bb56aac/attachment.htm>