On Tue, Nov 25, 2008 at 05:52:06PM +0000, Colin Paul Adams wrote:
Hello,
I'm just reading through Real World Haskell - chapter 6 (typeclasses).
The definition of Eq is shown, and it mentions that you can define either one or both of the two classes.
What would happen if I were two define both == and /= for an instance, in such a way that they were not opposites?
If I were doing this in Eiffel, the function definitions would have postconditions to state the relationships, and the first execution would trigger a violation, telling me what was wrong. Is there any similar facility in Haskell?
Nope. You will just get (possibly) inconsistent results. There are many other typeclasses like this as well (Functor, Monoid, Monad...) where the methods are supposed to satisfy certain laws about how they relate to one another, but Haskell has no way to guarantee this. A meta-level point is that Haskell (and strongly-typed languages in general) are all about *static* (compile-time) verification. Having a program which dynamically (at run-time) checks that certain properties hold, a la Eiffel, is generally a rather un-Haskellish way of doing things. As much as possible, I would like to know for sure that if my Haskell program compiles, it will not exhibit any run-time errors. So, to check constraints statically rather than dynamically, they must be put in the type system. But the sorts of constraints you're asking about (type class laws) often need dependent types (which Haskell doesn't have) to be expressed elegantly. -Brent