Multi Parameter Type Classes Dilemma

MultiParamTypeClasses are very useful, but mostly in the context of FunctionalDependencies. They are particularly used in the monad transformer library found in fptools. The dilemma is that functional dependencies are "very, very tricky" (spj). AssociatedTypes are promising but unproven. Without a solution, Haskell' will be somewhat obsolete before it gets off the ground.

References

• Understanding functional dependencies via Constraint Handling Rules, Martin Sulzmann, Gregory J. Duck, Simon Peyton Jones, and Peter J. Stuckey. Revised Feb 2006
• P. J. Stuckey and M. Sulzmann. A theory of overloading. ACM Transactions on Programming Languages and Systems (TOPLAS), 27(6):1-54, 2005.

Options for solving the dilemma

1. Examine a limited version of functional dependencies (see below for one solution)
2. Put AssociatedTypes on the fast-track for sainthood
3. Punt: declare FunctionalDependencies as an extension and figure out a way to "bless" extensions
4. Find a subset of FunctionalDependencies that is guarenteed to be a subset of what is expressible with AssociatedTypes. This would ensure no Haskell' programs become unexpressable if FDs switched to AssociatedTypes in the future.

Options that don't actually solve the dilemma

1. Standardize without MultiParamTypeClasses or FunctionalDependencies
2. Standardize FunctionalDependencies even though they are tricky.

Tickets

• solve the MultiParamTypeClassDilemma

Proposed Solutions

1. Adopt functional dependencies with the FD-conditions from the CHR paper together with the "complex relaxation rule" described at the bottom of the FunctionalDependencies page (also see the CHR paper, sect. 6).

Pro:

• allows a safe version of FunctionalDependencies that can support the monad transformer library

Con:

• complex specification for what is and is not allowed in classes and instance with functional dependencies
• not clear whether this could be forwards-compatible with associated types