Hi -
In
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/versions/HetCATS/docs/Programming-Guidelines.txt
one of the recommendations states:
"Don't put class constraints on a data type, constraints belong only to the
functions that manipulate the data."
This made me think: what on earth was the point of allowing contexts on a
data declaration in the first place? I've always found it a confusing
feature of Haskell since you in any case need to "repeat" all the (relevant)
constraints when declaring the type of any function that manipulates the
data. There does not appear to be any sensible reason for requiring the
constraints for constructor functions, because the constructor functions
would never ever need to use them... Therefore would it be a good idea to
get rid of this feature altogether?
Another confusing thing is the use of the word "inheritance" in
tutorials/books about class declarations. Unlike object oriented languages,
where a class or interface gets all the methods of its ancestor
classes/interfaces in addition to some new methods declared at that level,
each Haskell type class is completely independent of any other type class.
For example, the class Ord contains methods for (<) (<=) (>=) (>) max min
but does not contain the methods of Eq even though this confusing word
"inheritance" or "superclass" would imply that it should. Ord does *not*
"inherit" anything at all - the meaning of the Eq context in the class
declaration is just that we will need the Eq dictionary in addition to the
Ord dictionary when calling any of Ord's methods.
Thus I propose that the contexts don't really have any place in a class
declaration either ie
class Eq a => Ord a where
(<), (<=), ... ::
would be better written as:
class Ord a where
(<), (<=), .... :: Eq a => a->a->Bool
so the language wouldn't be so confusing to learn. Classes are after all
extremely simple! :-)
Regards, Brian.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
