class-system.md

 # 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](multi-param-type-classes-dilemma), 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
 
+## Probably yes
 
-These are the proposals that seem to have some support.
 
-- [\#32](https://gitlab.haskell.org//haskell/prime/issues/32)  add [FlexibleInstances](flexible-instances)
 
-> [MultiParamTypeClasses](multi-param-type-classes) and [TypeSynonymInstances](type-synonym-instances) 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.
+These are the proposals that seem to have some support.
 
-- [\#31](https://gitlab.haskell.org//haskell/prime/issues/31)  add [FlexibleContexts](flexible-contexts)
 
->
-> With [FlexibleInstances](flexible-instances), more contexts become irreducible.
-
-- [\#70](https://gitlab.haskell.org//haskell/prime/issues/70)  allow [TypeSynonymInstances](type-synonym-instances)
+- [\#32](https://gitlab.haskell.org//haskell/prime/issues/32)  add [FlexibleInstances](flexible-instances)        
+- [\#31](https://gitlab.haskell.org//haskell/prime/issues/31)  add [FlexibleContexts](flexible-contexts)        
+- [\#70](https://gitlab.haskell.org//haskell/prime/issues/70)  allow [TypeSynonymInstances](type-synonym-instances)        
 - [\#17](https://gitlab.haskell.org//haskell/prime/issues/17)  relax restriction on signatures of class methods        
 - [\#81](https://gitlab.haskell.org//haskell/prime/issues/81)  scoping of type variables in class instances
-
->
-> An opportunity for [ScopedTypeVariables](scoped-type-variables) that is already present in the syntax.
-
 - [\#52](https://gitlab.haskell.org//haskell/prime/issues/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](https://gitlab.haskell.org//haskell/prime/issues/71)        Allow Undecidable Instances        
 
+>
 >
 > Undecidable instances destroy desirable properties of programming
 > languages: decidable type checking and a specification of what
@@ -51,10 +50,30 @@ reasons why not.
 > 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](https://gitlab.haskell.org//haskell/prime/issues/54)        add overlapping or incoherent instances        
 
-> [Overlapping instances](overlapping-instances) add complexity to an already difficult problem, [incoherent instances](incoherent-instances) even more so.
+
+      
+
+
+>
+>
+> Overlapping instances add complexity to an already difficult problem. With overlapping instances:
+>
+>
+
+- Haskell would need to be a lot more specific about exactly where context reduction takes place. 
+- A program that type checks can have its meaning changed by adding an instance declaration
+- Similarly adding "import M()" can change the meaning of a program (by  changing which instances are visible
+- When exactly is overlap permitted?  Is this ok?
+
+  ```wiki
+             instance C a Int
+  	   instance C Bool b
+  ```
 
 - [\#18](https://gitlab.haskell.org//haskell/prime/issues/18)        add closed classes
 - [\#19](https://gitlab.haskell.org//haskell/prime/issues/19)        control export and import of class instances        
@@ -62,27 +81,32 @@ reasons why not.
   A general form of [DerivedInstances](derived-instances) hasn't really been
   discussed. But, the special case of [NewtypeDeriving](newtype-deriving) is a likely
   adoption.
-- Defaults for superclass methods (no ticket, see [ List Discussion](http://www.haskell.org//pipermail/libraries/2005-March/003494.html), and [ more list discussion](http://www.haskell.org//pipermail/haskell-prime/2006-April/001344.html), and [ yet more list discussion](http://www.haskell.org//pipermail/haskell-prime/2006-August/001582.html))
+- Defaults for superclass methods (no ticket, see [ List Discussion](http://www.haskell.org//pipermail/libraries/2005-March/003494.html))
 
 ## Multiparameter Type Class Dilemma
 
-- [\#90](https://gitlab.haskell.org//haskell/prime/issues/90)        solve the [MultiParamTypeClassesDilemma](multi-param-type-classes-dilemma)
+
+- [\#90](https://gitlab.haskell.org//haskell/prime/issues/90)        solve the [MultiParamTypeClassesDilemma](multi-param-type-classes-dilemma)        
 - [\#49](https://gitlab.haskell.org//haskell/prime/issues/49)        add multi parameter type classes         (MPTCs)
 - [\#36](https://gitlab.haskell.org//haskell/prime/issues/36)        add [FunctionalDependencies](functional-dependencies)        (FDs)
 - [\#14](https://gitlab.haskell.org//haskell/prime/issues/14)        add Associated Types (ATs)
 
-**Proposal:** Haskell' should have multiparameter type
+
+The bottom line is that 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
@@ -92,14 +116,18 @@ Points in favor of FDs:
 
 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](functional-dependencies) page for
 more info.
    
+
+