...  ...  @@ 36,7 +36,7 @@ default. 





The major design goal is this:






 **Design goal 1: a class C can be refactored into a class C with a superclass S, without disturbing any clients.**



### Design goal 1: a class C can be refactored into a class C with a superclass S, without disturbing any clients









The difficulty is that if you start with

...  ...  @@ 72,7 +72,30 @@ class S a => C a where 





Design goal 1 is that this change should not force clients to change their code. Haskell 98 does not satisfy this goal. In Haskell 98 the client function `foo` is fine unmodified, but the instance declaration would have to be split into two.






**SLPJ**: are there any other design goals?



### Design goal 2: write implementations of subclasses that imply their superclass implementations






 Example 1: once you say






```wiki



instance Ord (T a) where



compare = ...



```






then the implementation of `(==)` in `Eq` is obvious. So, in the class decl for `Ord` we'd like to say (modulo syntax, see below)






```wiki



class Eq a => Ord a where



...



instance Eq a where



(==) a b = case compare a b of { EQ > True; _ > False }



```






 Example 2: once you say `instance Monad M`, the instances for `Functor M` and `Applicative M` can be derivived from the definitions of `(>>=)` and `return`. And similarly if you say `instance Applicative M`, the `Functor M` instance is derivable.






 Example 3: once you say `instance Traversable T` you can derive `Foldable` and `Functor`.









Obvious question: if something is both `Foldable` and `Applicative`, which `Functor` instance do you get? Answer: the programmer must be able to control this (see "the optout mechanism" below).











...  ...  @@ 84,7 +107,7 @@ Concretely, the proposal is as follows. 


### Default superclass instances









First, we allow a class declaration to include a **default superclass instance declaration** for some, none, or all of its superclass constraints. We say that superclasses with default implementations are **intrinsic** superclasses. Example:



First, we allow a class declaration to include a **default superclass instance declaration** for some, none, or all of its superclass constraints (transitively). We say that superclasses (transitively) with default implementations are **intrinsic** superclasses. Example:






```wiki



class Functor f => Applicative f where

...  ...  @@ 114,6 +137,23 @@ Here is another example: 





Here, `Applicative` is an intrinsic superclass of `Monad`.









We might also want to give a different implementation of `fmap` for monads than the



one generated by the `Applicative` class declaration:






```wiki



class Applicative f => Monad f where



(>>=) :: f a > (a > f b) > f b



instance Applicative f where



hiding instance Functor



ff <*> fs = ff >>= \ f > fs >>= \ s > return (f s)



instance Functor f where



fmap f x = x >>= \y > return (f y)



```









(In fact this `fmap` would, after optimisation of a particular instance and if enough inlining too place, generate the same code, but that might not always be the case.)






### Instance declarations







...  ...  @@ 388,6 +428,15 @@ The common factor is that one instance declaration is expanded into 


several with the method definitions distributed appropriately among



them.






## Feature interactions









What about interaction with other features?






 `deriving`. If you say `deriving(Ord)` do you get the `Eq` by default? What if you want to specify a manual instance for `Eq`? Ditto standalone deriving.



 Generic default methods.



 Associated types, and default type synonyms. Presumably they obey the same rules as for default methods.













# Applications

...  ...  