<p><br>
On Sep 21, 2013 4:17 PM, &quot;Bob Hutchison&quot; &lt;<a href="mailto:hutch-lists@recursive.ca">hutch-lists@recursive.ca</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On 2013-09-21, at 4:46 AM, Stijn van Drongelen &lt;<a href="mailto:rhymoid@gmail.com">rhymoid@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; I do have to agree with Damodar Kulkarni that different laws imply different classes. However, this will break **a lot** of existing software.<br>
&gt;<br>
&gt;<br>
&gt; You could argue that the existing software is already broken.<br>
&gt;</p>
<p>I agree, but that might also be hardly relevant when fixing an existing language.</p>
<p>&gt;&gt; If we would do this, only Eq and Ord need to be duplicated, as they cause most of the problems. Qualified imports should suffice to differentiate between the two.<br>
&gt;&gt;<br>
&gt;&gt;     import qualified Data.Eq.Approximate as A<br>
&gt;&gt;     import qualified Data.Ord.Approximate as A<br>
&gt;&gt;<br>
&gt;&gt;     main = print $ 3.16227766016837956 A.== 3.16227766016837955<br>
&gt;<br>
&gt;<br>
&gt; As soon as you start doing computations with fp numbers things get much worse.</p>
<p>Only when you start reasoning about (in)equalities. Really, in (a + b) * c = a * c + b * c, it isn&#39;t + or * that&#39;s causing problems, but =.</p>
<p>I&#39;m going to look at Kmett&#39;s work and that ltu link when I&#39;m home ;)</p>