<div dir="auto"><div>Well, the motivation to make them associative was that (==) is logical XNOR, and (/=) is logical XOR. Perhaps we want an alias for Bool-instantization of them.<br><br><div class="gmail_quote"><div dir="ltr">2018년 9월 19일 (수) 00:34, Eric Mertens <<a href="mailto:emertens@gmail.com">emertens@gmail.com</a>>님이 작성:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Do we have any other good examples where we've got an operator that is considered associative where the result type isn't identical to the argument types? It's much more common to allow the types to vary when there's only one associativity that makes sense for the way an operator is intended to be used.<div><br></div><div><font face="monospace">a -> a -> a<br></font><div><br></div><div>While it's true that focusing on Bool, (==) satisfies associativity in its truth table, the types don't work out so cleanly. Outside of Bool it starts to matter which associativity you pick.</div><div><br></div><div>





<p class="m_4294869913521577400inbox-inbox-p1"><span style="font-family:monospace">(\x y z -> (x == y) == z) :: Eq a => a -> a -> Bool -> Bool</span><br></p>
<p class="m_4294869913521577400inbox-inbox-p2"><span style="font-family:monospace">(\x y z -> x == (y == z)) :: Eq a => Bool -> a -> a -> Bool</span><br></p></div><div><br></div><div>Making == associative is just going to lead to harder to understand code and will require people to memorize which arbitrary choice about the associativity of the operation was selected by the mailing list in order to make sense of the types of code using multiple ==.</div><div><br></div><div>I see no gain here, and I'd prefer to leave == as is.</div><div><br></div><div>Best regards,</div><div>Eric Mertens</div></div></div>
</blockquote></div></div></div>