What, by the way, is the rationale behind including /= in the Eq class in the first place?
Since /= is intended to be semantically equivalent to \x y -> not (x == y), the only plausible reason for making it overloaded is optimization. But an optimized implementation of /= can at most be two "not":s faster than just using not and ==, so the performance benefits seem quite minimal here. This is nothing compared to, say, Monad.>>, where an optimized implementation can be quite a lot faster than the default one that uses >>=. So as far as I see, the overloadability of /= is just a source of subtle errors, when the implementation doesn't follow the expected (but non-language-enforceable) semantics. Lauri Alanko [EMAIL PROTECTED] _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
