## Superclass methods could be more aggressively specialised.

Say `R`

is a superclass of `MR`

but only uses one of the type variables. If this type variable is fixed then we know that we are going to use a specific instance for `R`

. Thus, the optimiser *could* specialise all methods
from the superclass at this point leading to better code.

```
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleContexts #-}
module Foo where
class R t => MR t m where
push :: t -> m -> Int
class R t where
pull :: t -> Int
--type MR2 t m = (R t, MR t m)
instance MR Int Int where
push = max
instance R Int where
pull = negate
myf :: (MR Int a) => a -> Int -> Int
myf _ = pull
```

To give a concrete example, `R`

is a super class of `MR`

but only mentions the first type variable. Thus when we fix it in `myf`

, we could optimise the definition to `myf _ = negate`

by inlining the class method.

Reid points out that if you have a definition like

```
data X = X
f :: R X => Int -> Int
f = pull
```

then the instance for `R X`

could be provided by another module. However it is common to structure large applications with super class constraints so it would be desirable to do better.

See also

- #5835 (closed), which will be fixed when this one is fixed.