<p><br>
On Mar 4, 2011 2:49 AM, &quot;Karthick Gururaj&quot; &lt;<a href="mailto:karthick.gururaj@gmail.com">karthick.gururaj@gmail.com</a>&gt; wrote:<br>
&gt; &gt; Ord has to be compatible with Eq, and none of these are.<br>
&gt; Hmm.. not true. Can you explain what do you mean by &quot;compatibility&quot;?</p>
<p>Compatibility would mean that x == y if and only if compare x y == EQ.  This is not a restricrion enforced by the type system, but it is something that I would think ought to be true (though it is not,for example, for the IEEE floating point types; I personally consider that a bug and believe the IEEE notions of comparison ought to be exposed in a different set of operations rather than instances of Ord and Eq).  In this sense it is much like the monad laws.  So whether it has to be true depends on what you mean by &quot;has to be&quot;.</p>

<p>&gt; Ok - at this stage, I&#39;ll just take your word for it. I&#39;m not able to<br>
&gt; still appreciate the choice of the default ordering order, but I need<br>
&gt; to wait until I get to see/develop some real code.</p>
<p>The most common use of Ord in real code, to be honest, is to use the value in some data structure like Data.Set.Set or Data.Map.Map, which requires Ord instances.  For this purpose, any Ord instance that is compatible with Eq will do fine.</p>

<p>-- <br>
Chris<br>
</p>