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

[John Lato]

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 gmail.com> 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 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/20140925/1a55faf2/attachment.html>