
On 2/18/07, David Tolpin
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 +46(0)736-818655 UIN: 44640862