Implementing type classes in Hugs - question

[Stephen Milborrow]

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?