Sat, 12 Jul 2003 10:58:21 +0100
> 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
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.