[Haskell-cafe] Why do I have to specify (Monad m) here again?

[Sebastian Sylvan]

On 2/18/07, David Tolpin <david.tolpin at gmail.com> wrote:
>
> > That's completely different. The class in that case guarantees that
> > the type has an "Eq" class, so it's okay to use the functions in the
> > "Eq" class. You're using the guarantees supplied by the class. When
> > you write instances, it's the other way around, the class has
> > *requirements* that you must fulfill -- and there are multiple ways of
> > doing it (Haskell won't guess, it will obey what you tell it -- if you
> > don't give any class constraints it won't assume that they are there).
>
> Hi Sebastian,
>
> could you please point me to a reference (paper/note/something else) that explains that class constraint
> in a class definition is a guarantee with regard to a type declaration but a requirement with regard to an instance
> declaration?
>

Well, I guess the H98 report would be a good start. But there are
multiple tutorials on type classes that will cover this, most of which
are available from haskell.org

The key point is that Haskell won't guess, and in particular it won't
contradict what you tell it. I think that's the major flaw in your
reasoning, you expect Haskell to take an explicit type that you, the
programmer, supplies, and change it into something else. That's
obviously not a very good idea -- when there's a conflict, it should
give an error.
In the original example you are explicitly telling Haskell that "m" is
*not* in the Monad (or any other) class. Why would you want Haskell to
ignore what you are telling it and go behind your back?

Another way to view this specific issue is that it's two-sided -- if
you on the one hand have a guarantee that something holds, then
logically on the other side there must be a requirement to fulfill
that guarantee.
Now, if you have a guarantee (e.g. if a variable is in the Ord class,
you are allowed to use (==) due to Eq being a super class), you can
just make use of that guarantee without any further fuss. But if you
have a *requirement* then it's a completely different story since
there are any number of ways to fulfill that requirement (Haskell is,
sadly, incapable of reading the programmer's mind). Take the example I
gave earlier; maybe the "m" in the original example was supposed to be
"M" (a type in the Monad class), or maybe it was supposed to be
constrained to "Monad", or any other class which has "Monad" in its
class hierarchy. Haskell has *no* way of knowing how you intend to
fulfill the requirement that any instance in your class is a Monad
(which is required to fulfill the guarantee that the functions in
Monad can be used on any instance of your class), and it won't guess.


-- 
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862