> I'm glad to hear there isn't a _serious_ cost (i.e. performance penalty) > for fine-grained hierarchies.
One cost which doesn't seem to have been mentioned is the programmer cost. With the current Haskell Prelude, a matrix operation (say) might have type: invert :: Num a => Matrix a -> Matrix a but, if we had one operation per class, the type might be: invert :: (Add a, Subtract a, FromInteger a, Eq a, Multiply a) => Matrix a -> Matrix a More flexible but quite unwieldy. One way to overcome part of this problem would be to generalize the idea of 'type synonyms' to allow 'context synonyms'. For example, we have type synonyms like: type Point = (Int,Int) we could have 'context synonyms' like: class Num a => (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) Adding context synonyms would make it possible to write types concisely when using fine-grained class hierarchies and would also be useful with extensions like Hugs' T-REX or implicit parameters. Adding context synonyms would not help with type error messages though. When using TREX to encode an abstract syntax tree for the C language, I once got an error message that was over two pages long (i.e., about 4000 characters long). The error message amounted to saying that one list of fields didn't match another list of fields but with two pages of field names to look at, it was impossible to say what the differences between the types were. Things would not be that bad with the example types above but they would certainly be harder than the current error messages. -- Alastair Reid _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe