On Sun, Nov 1, 2009 at 8:31 PM, Michael Mossey
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?
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
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 : 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 ...
-- Jedaï