Shelby Moore wrote:
...A "type class" is a polymorphic (relative to data type) interface, and the polymorphism is strictly parameterized for the client/consumer of the interface, i.e. the data type is known to the function that inputs the interface AT COMPILE TIME.
...A problem with virtual (runtime pointer) inheritance is that it hides the subclass from the compiler.
I emphasize that in Haskell, the consuming function knows the interface at compile time (or it can allow the compiler to infer it, if no type class restriction is specified).
Caveat follows. The fundamental theorems I mentioned ( http://www.haskell.org/pipermail/haskell-cafe/2009-November/068432.html ), can not be voided by any programming language that is Turing complete. Thus, it is no surprise that dynamic run-time typing is achievable in Haskell[1], basically a punt of the attempt of strict typing exponential local order (which the theorems predict _MUST_ happen in some cases, unless there is no state diagram), to run-time nondeterminism due to Liskov Substitution Principle (and Linsky Referencing). Alas (good news!), local exponential order wins in vast majority of common use cases in Haskell because it is also possible to use static compile-time typing[1], which I assert is because the static typing architecture is granular and orthogonal. [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html#lan... http://research.microsoft.com/en-us/um/people/simonpj/papers/hmap/gmap3.pdf Ralf Laemmel and Simon Peyton Jones. "Scrap your boilerplate: a practical approach to generic programming", Proc ACM SIGPLAN Workshop on Types in Language Design and Implementation (TLDI 2003), New Orleans, pp26-37, Jan 2003