I don't know if this is an "appropriate" use of overloading both == and /=, but I've done something like the following:
data T a = T a | U (a -> Int)
instance Eq a => Eq (T a) where (T a) == (T a') = a == a' (U _) == (U _ ) = False (T a) /= (T a') = a /= a' (U _) /= (U _ ) = False
This probably isn't "good", but it suited my purposes. I agree in general, though, I don't think /= should be in the class, even though I've capitalized on it. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Fri, 4 Jan 2002, Lauri Alanko wrote:
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 la@iki.fi
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell