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

[Yves Parès]

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 <pumpkingod at gmail.com> 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 <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
>>
>>
>
> _______________________________________________
> 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/20120402/e78b795c/attachment.htm>