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.