Report Issues

[Hal Daume III]

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
>