Low-level notation for type classes WAS: [Haskell] A puzzle and an annoying feature

[Martin Sulzmann]

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