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

Sebastian Sylvan sebastian.sylvan at gmail.com
Sun Feb 18 15:04:29 EST 2007

On 2/18/07, David Tolpin <dvd at davidashen.net> wrote:
> >> Why the compiler cannot infer  class constraint on m from class
> >> definition in instance definition while it can in function type
> >> definition?
> >
> > But it can't! If you give a type to a function, it will assume zero
> > class constraints unless you specify them (just like it will when you
> > give a type to an instance declaration). If you do something like:
> >
> Hi Sebastian,
> it is not the example I brought. In the example I brought I showed how in
> function type declaration assertion that an instance of a class is also an
> instance of the other class is used. Take a look at my example. According
> to what part of the type system logic type inference in instances is not
> implemented

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).

The point I'm trying to make is that if you say that something is of a
given type, Haskell will assume that you know what you're talking
about. I.e. if you give a type which has no class constraints, Haskell
will assume that you don't want any class constraints -- if this
conflicts with something else, you will get an error.

I think maybe this is where you're missing the point. *Leaving out*
class constraints says something about the type. In other words, if
you leave out a class constraint that does *not* mean that you don't
care what class constraints the type variable has, it explicitly means
that there are *no* class constraints on it (and using it in a context
where a class constraint is required, is thus an error).

In this case you *require* that any instances of a class is also an
instance of the Monad class. But then you try to instantiate a type
which is *not* in the monad class in this class. This is a conflict,
and you should get an error. If you want to construct a type which is
in the Monad class by constraining the type variable "m" to the Monad
class, then that's fine, but you have to tell Haskell that this is
what you want to do -- if you say that your type has *no* class
constraints, it will take your word for it an report the conflict.
Another alternative is that you want to produce the type by using a
concrete type called, say,  "M" which is in the Monad class, then
that's also fine. Haskell won't guess what you meant (it can either be
a spelling error, "m" for "M", or that you forgot to add "Monad m =>"
in the instance declaration, or anynumber of other errors) and change
it for you. Whenever you write something out, Haskell will take your
word for it, if it fails, it's your fault, and Haskell will tell you
what the problem is.

Sebastian Sylvan
UIN: 44640862

More information about the Haskell-Cafe mailing list