[Haskell-cafe] Context in data and class declarations (was haskell programming guidelines)

[Brian Hulley]

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.