I&#39;d say that any polymorphic code that assumes that x==y implies x=y is broken.<br>But apart from that, floating point numbers break all kinds of laws that we might expect to hold.&nbsp; Even so, they are convenient to have instances of various classes.<br>
<br><div class="gmail_quote">On Wed, Mar 12, 2008 at 7:31 PM, Adrian Hey &lt;<a href="mailto:ahey@iee.org">ahey@iee.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Remi Turk wrote:<br>
&gt; I wouldn&#39;t bet on it either:<br>
&gt;<br>
&gt; Prelude&gt; 0.0 == -0.0<br>
&gt; True<br>
&gt; Prelude&gt; isNegativeZero 0.0 == isNegativeZero (-0.0)<br>
&gt; False<br>
&gt;<br>
&gt; Although isNegativeZero might be considered a ``private,<br>
&gt; &quot;internal&quot; interface that exposes implementation details.&#39;&#39;<br>
<br>
</div>Interesting example.<br>
<br>
So is the correct conclusion from this that all (polymorphic) code<br>
that assumes (x == y) = True implies x=y is inherently broken,<br>
or is just this particular Eq instance that&#39;s broken?<br>
<br>
Regards<br>
--<br>
<font color="#888888">Adrian Hey<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>