The Class System

This page summarizes the current status of proposals related to the Class System. This discussion has mostly focused on the issues surrounded by MultiParamTypeClassesDilemma, but there are a number of proposals that have been discussed.

Below, the major sections divide the proposals that probably will be included from those that probably won't, leaving the MPTC issue to its own section.

Probably yes

These are the proposals that seem to have some support.

#32 add FlexibleInstances

MultiParamTypeClasses and TypeSynonymInstances are little use without generalizing the form of instances. The proposal is to generalize but retain guaranteed termination of instance inference via (necessarily conservative) syntactic restrictions.

#31 add FlexibleContexts

With FlexibleInstances, more contexts become irreducible.

#70 allow TypeSynonymInstances
#17 relax restriction on signatures of class methods
#81 scoping of type variables in class instances

An opportunity for ScopedTypeVariables that is already present in the syntax.

#52 Generalised deriving for newtype

Probably no

Based on current discussion, these proposals will probably not make it into the next Haskell standard. For each one, we summarize the reasons why not.

#71 Allow Undecidable Instances

Undecidable instances destroy desirable properties of programming languages: decidable type checking and a specification of what programs are an are not allowed in the language. Although some sort of dynamic check could be used to ensure termination, this makes the type system brittle, and it is not clear that programs will be portable from one implementation to another.

#54 add overlapping or incoherent instances

Overlapping instances add complexity to an already difficult problem, incoherent instances even more so.

#18 add closed classes
#19 control export and import of class instances
#22 create DerivedInstances A general form of DerivedInstances hasn't really been discussed. But, the special case of NewtypeDeriving is a likely adoption.
Defaults for superclass methods (no ticket, see List Discussion, and more list discussion, and yet more list discussion)

Multiparameter Type Class Dilemma

#90 solve the MultiParamTypeClassesDilemma
#49 add multi parameter type classes (MPTCs)
#36 add FunctionalDependencies (FDs)
#14 add Associated Types (ATs)

Proposal: Haskell' should have multiparameter type classes and functional dependencies. Multiparameter type classes are useful for programming, and something like functional dependencies are necessary to make them work. There has been a lot of discussion about whether Haskell' should include FDs or ATs, but FDs are emerging as the appropriate choice.

Comparison of FDs and ATs

Points in favor of FDs:

FDs and ATs are the same order of technical difficulty
We have more experience programming with FDs
We have a better handle on just what restrictions make type inference tractable for FDs
ATs are (perhaps) bit weaker in expressiveness, but nicer to program with in some cases. In a few other examples, FDs are nicer.
ATs are not likely to be implemented in GHC soon

Points against FDs:

Versions of FDs that are powerful enough for examples (monad transformer library) need complex restrictions to ensure termination and confluence. (It is not clear whether ATs would also need such complex restrictions.)
ATs may win out in the end, and then we would have standardized too early. But perhaps FDs would not be that prevalent in code and so would be "easy" to update to a newer standard.

What version of FDs to use ?

Current discussion has focused more on the particular restrictions on FDs that should be adopted. See the FunctionalDependencies page for more info.

class system