[Haskell-beginners] several questions: multi-param typeclasses, etc.

Chaddaï Fouché chaddai.fouche at gmail.com
Mon Nov 2 04:15:34 EST 2009

On Sun, Nov 1, 2009 at 8:31 PM, Michael Mossey <mpm at alumni.caltech.edu> wrote:
> In OO, which I am more familiar with, one person will write a class with a
> limited API in order to help put guarantees on the correct behavior of the
> class. In a sense, that person is saying: "I release my class to the world
> to do what it will, but before doing that I put some constraints on it so no
> one can distort my intentions."
> Is this functional dependency a similar situation? Does it make sense from
> the "point of view" of the author of the class definition?
> Or is it more a practical necessity?

In this particular case of MonadError, I think the constraint is more
of the first variety but most functional constraints are more
practical than moral... The case in point being when you want to put a
method in the class that don't include all the type parameters of the
class in its type : you NEED to have functional constraints for
Haskell to accept that the correct method can be determined with this
partial information (and determine it later on).

It is worth noting that many case where multi-param classes are used
with a mandatory practical functional constraint are better expressed
by the new indexed type family extension and a single param type class
(though this is not always the case) :

For instance the classic Collection type class :

> class Collection collection elt | collection -> elt where
>   add :: elt -> collection -> collection
>   merge :: collection -> collection -> collection
>   ...
(merge is the function that makes the functional constraint a
practical necessity)

Can be better (or at least more cleanly, depending on who you ask)
expressed as :

> class Collection c where
>   type Elt c :: *
>   add :: Elt c -> c -> c
>   merge :: c -> c -> c
>   ...


More information about the Beginners mailing list