Class
signature innovation is a slow burner
When Haskell initially proposed type classes as a way of systematically dealing showing and comparing user types I was not happy and avoided using them when I could for years. I still don’t think that was a bad shout (but I boycotted them for too long, of course).
My objections to them were as follows.
Haskell was a designed by committee and that committee should have been steering clear of innovations that had not been already proved in working functional programming languages.
They polluted the beautiful Hindley–Milner type system breaking a number of its desirable properties (equational reasoning is not nearly so clean with type classes).
They added a stunning level of complexity to tidy up a wrinkle of having some magic functions to carry out the displaying and comparison of values.
They introduced a program structuring mechanism that was entirely unproven and named to suggest a coverage of object oriented features that was plain confusing.
I would like these extra dictionary parameters to functions to have been exposed so type class resolution could be explained with source code transformations and so that callers could provide the modified methods to sort functions to control the ordering, etc. (Finally we have a proposal to address this and it will be interesting to see how far it gets.)
I still think that the original type classes — what you get in Haskell 2010 without any language extension pragmas — are really too weak and need proper multi-parameter type classes and selective liberalisation of the original (rightly) conservative restrictions to make proper sense.
That said, what an utterly brilliant innovation type classes have been and I think they have more to give — they are yet still being underused.
Got an issue with any of this? Please share or drop me a line (see below).