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

Plus one might argue that using <> to mean different is a bad choice, as it graphically means "strictly inferior or strictly superior" which implies comparability, whereas equality and comparison are two different things. (e.g. Eq and Ord are two distinct classes in Haskell). Le 1 avril 2012 23:06, Daniel Peebles a écrit :

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 wrote:

...

After asking this question:

http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-...

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