Proposal (long term): Remove (/=) from Eq; change the semantics of (==) for floating point

John Lato jwlato at
Thu Sep 25 04:14:59 UTC 2014

My primary objection is that currently all operators have ieee semantics on
Float/Double.  This change would mean that basic arithmatic operators would
have ieee semantics but comparisons would not.  I consider this a
significant added burden on users who are used to thinking in the current
semantics (it makes Eq more uniform at the cost of making Float/Double less
so).  Of course I do concede that it's probably much simpler for people
using Eq to assume reflexivity.

On Thu, Sep 25, 2014 at 11:51 AM, David Feuer <david.feuer at> wrote:

> I'm not sure what you're saying. What I'm saying is that we can make Eq
> faster for some things *other* than Float/Double in some contexts if we
> take away the ability of Eq to deal with the messiness of IEEE
> requirements, which also happens to have the advantage of making sure that
> (a==b) /= _|_ -> (a==b) == not (a /= b). I have my own opinions about the
> numerical typeclass hierarchy (Num et al), but I think this issue is pretty
> much orthogonal.
> On Wed, Sep 24, 2014 at 11:43 PM, John Lato <jwlato at> wrote:
>> This strikes me as a halfway measure between those who want arithmatic
>> operations on Float/Double to be fast (i.e. IEEE754 semantics/machine ops)
>> and those who want more exacting laws associated with arithmatic classes.
>> As such, I think it's a bad idea.  I think it's better that all operations
>> follow the same philosophy.
>> On Thu, Sep 25, 2014 at 11:25 AM, David Feuer <david.feuer at>
>> wrote:
>>> As Edward Kmett explained to me, (/=) is currently needed in Eq to
>>> support IEEE floating point semantics for (==) and (/=). As I see it, those
>>> semantics are badly broken from the perspective of what Eq is supposed to
>>> mean, and really should be supported using special functions (eqIEEE and
>>> neqIEEE or whatever), whereas the most appropriate Eq instance for floating
>>> point would be something more like
>>> instance Eq Double where
>>>   x == y   =  decodeFloat x == decodeFloat y
>>> If this is (eventually) done, that would allow us to remove (/=) from
>>> Eq, reducing its dictionary to a single member, (==), improving efficiency
>>> when the type is not statically known.
>>> David
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list