Interestingly, I'd always assumed the answer was that all comparison
functions should return False for NaN, and mentally just assumed that would
include (/=). I never actually tested if (/=) returned False, but
apparently this isn't the case.
Prelude> (0/0) == (0/0)
False
Prelude> (0/0) /= (0/0)
True
So I can come up with no reason for (/=) to be included in the class today,
other than historical precedent based on the language report.
All the "GHC can optimize it better" things should be something that should
be able to be knocked out with relatively little fanfare, and are likely
dominated by the cost of wrapping up the method in a dictionary in the
cases where it doesn't fully inline away.
-Edward
On Wed, Oct 20, 2021 at 10:40 AM Joachim Breitner
Hi list,
I am revisiting some educational material about Haskell, and I stumble over something that I keep stumbling over. I thought there was prior discussion, but I couldn’t find it (operators hard hard to google for).
Why does Eq have a (/=) method?
Semantically, I don’t see a reason why an instance might want to behave differently than the default method. And (in contrast to, say, Ord), I would be surprised if there are noticable performance benefits to be gained from implementing (/=) separately.
On the other hand, this is likely the first time a learner will encounter a class with default methods, and it’s awkward to explain “this mechanism is useful if you can have an optimized implementation, but, eh, here it isn’t really possible”.
If we’d design the language now, would we include (/=) as a method?
If no: would it be worth removing it?
Yes, every change is annoying, but if are going to keep using Haskell the next 30 days, it may pay off? And it might not be too bad: Remove it from base, but teach GHC to not error out if an instance defines (/=), but print a warning and otherwise ignore it. Libraries can remove it if it is defined, which is a backwards-compatible change.
WDYT? Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries