Hi, Daan said:
Personally, I feel that this problem might be better solved by making a lot of the implicit assumptions (and semantics) of type classes more explicit, and bring them under user control. Of course, I do have not have any idea of how this should be done concretely ;-)
(although type class directives might be a step in the right direction?)
Well, you might not need to look that far :) To a great extent you can use Constraint Handling Rules (CHRs) to explain type classes. E.g., consider Gregory J. Duck, Simon Peyton-Jones, Peter J. Stuckey and Martin Sulzmann "Sound and Decidable Type Inference for Functional Dependencies" Peter J. Stuckey and Martin Sulzmann "A Theory of Overloading" I've just skimmed through the "Type Class Directives" paper. Pl correct me if I'm wrong but it appears that the disjoint directive can be modeled by CHRs. Example: disjoint (Integral, Fractional) can be encoded by rule Integral a, Fractional a ==> False (1) The never directive is in fact a special instance of disjoint. E.g., never Num Bool can be encoded by rule Num Bool ==> False (2) Note that the Chameleon type debugger provides type error explanation support if the error is due to rule applications such as (1) and (2). Martin