Brian Hulley wrote:
"Don't put class constraints on a data type, constraints belong only to the functions that manipulate the data."
So according to this guideline you're not supposed to think of associating contraints with data: constraints are only relevant for functions which manipulate the data, therefore (if you agree with this view) the very idea of associating constraints with data is wrong.
I wonder what the reasoning for this guideline is. It seems that it would require one to repeat the constraint over and over. For the Prelude Data.Map type, for instance, wouldn't almost every function have to have the constraint that the key type is ordered? Also, I think it would push detection of the error further from the place where it could have been detected. Doesn't it make more sense to detect that there is an error when a user tries to instantiate a map with an unordered type rather than later when an attempt is made to use it? Regards, Brock