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 | [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > > _______________________________________________ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
