class-system.md

@@ -17,10 +17,22 @@ issue to its own section.
 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.
+
 - [\#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)
 - [\#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
@@ -42,18 +54,7 @@ reasons why not.
 
 - [\#54](https://gitlab.haskell.org//haskell/prime/issues/54)        add overlapping or incoherent instances        
 
->
-> 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
-  ```
+> [Overlapping instances](overlapping-instances) add complexity to an already difficult problem, [incoherent instances](incoherent-instances) even more so.
 
 - [\#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        
@@ -70,8 +71,7 @@ reasons why not.
 - [\#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)
 
-
-The bottom line is that Haskell' should have multiparameter type
+**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