I have a question about partial evaluation of type classes in Hugs. Consider the function inc99 :: Int->Int inc99 x = x + 99::Int which compiles to the SC inc99 _1 = Prelude.+ Prelude.v28 _1 (Prelude.fromInt Prelude.v28 99) where (the compiler generated dictionary) v28 basically implements "instance Num Int" and has the definition v28 = let _1 = Prelude.v24; -- (==) resolves to primEqInt _2 = Prelude.v40; -- (/=) _3 = Prelude.primPlusInt; -- (+) resolves to primPlusInt _4 = Prelude.primMinusInt; -- (-) resolves to primMinusInt _5 = Prelude.primMulInt; -- etc _6 = Prelude.primNegInt; _7 = Prelude.absReal Prelude.v28 Prelude.v26; _8 = Prelude.signumReal Prelude.v28 Prelude.v28 Prelude.v26; _9 = Prelude.primIntegerToInt; _10 = Prelude.Make.Num _1 _2 _3 _4 _5 _6 _7 _8 _9 Prelude.v1202; in _10; My question is: why doesn't Hugs partially evaluate the inc99 SC (before code generation) to yield the following definition? inc99 _1 = Prelude.primPlusInt _1 99 Doing so seems straightforward and would obviously avoid extra evil evals evolving evanescent heap expressions at run time. My main references are listed below and they imply that the above partial evaluation takes place (in Gofer, at least): John Peterson and Mark Jones: Implementing Type Classes, 1993 Mark Jones: Partial Evaluation for Dictionary-free Overloading, 1993 Is it simply that this kind of specialization was never implemented in Hugs? Or is the above transformation not as straightfoward as it seems?