Re: [Haskell-beginners] Ensuring consistency in typeclass instances?

26 Nov 2008

      ...
...
...
...
...
"Brent" == Brent Yorgey  writes:
Brent> 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?

    Brent> Nope.  You will just get (possibly) inconsistent results.
    Brent> There are many other typeclasses like this as well
    Brent> (Functor, Monoid, Monad...)  where the methods are supposed
    Brent> to satisfy certain laws about how they relate to one
    Brent> another, but Haskell has no way to guarantee this.

    Brent> A meta-level point is that Haskell (and strongly-typed
    Brent> languages in general) are all about *static* (compile-time)
    Brent> verification.  Having a program which dynamically (at
    Brent> run-time) checks that certain properties hold, a la Eiffel,
    Brent> is generally a rather un-Haskellish way of doing things.

I don't see why. Eiffel is strongly typed too. But current compiler
technology doesn't necessarily permit us to check all we would like
statically (as you say below).

It seems to me, having read further, that QuickCheck does just this
(and is an answer to my own original question). 
But so far I'm only reading. I guess when I try it out I might find
out different.

    Brent> So, to check constraints statically rather than
    Brent> dynamically, they must be put in the type system.  But the
    Brent> sorts of constraints you're asking about (type class laws)
    Brent> often need dependent types (which Haskell doesn't have) to
    Brent> be expressed elegantly.
-- 
Colin Adams
Preston Lancashire