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

[David Feuer]

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 gmail.com> 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 gmail.com>
> 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 haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140924/c4501e85/attachment-0001.html>