Inferred type is less polymorphic than expected?

[Benjamin Franksen]

Hi,

I get an error message when I compile the following program with 
ghc-6.4:

\begin{code}
class Catalog c where
  traverse :: c -> Viewer -> IO ()

instance Catalog Int where
  traverse i v = viewShowable v i

type View a = a -> IO ()

data Viewer = Viewer {
    viewShowable :: forall s. Show s => View s,
    viewCatalog :: forall c. Catalog c => View c
  }

printer :: Viewer
--printer = Viewer {
--  viewCatalog = \x -> traverse x printer,
--  viewShowable = putStrLn . show }
printer = Viewer {
  viewCatalog = printCatalog,
  viewShowable = putStrLn . show }

printCatalog :: forall c. Catalog c => View c
printCatalog x = traverse x printer

data X = X {
    cat :: Int
  }

instance Catalog X where
  traverse x v = do
    viewCatalog v (cat x)

main = do
  let x = X { cat = 20 }
  traverse x printer
\end{code}

This is a stripped-down version of my actual code, BTW. The exact mesage 
is:

~> ghc -fallow-undecidable-instances -fglasgow-exts Bug.lhs

Bug.lhs:23:10:
    Inferred type is less polymorphic than expected
      Quantified type variable `c' is mentioned in the environment:
        printCatalog :: c -> IO () (bound at Bug.lhs:28:0)
    In the `viewCatalog' field of a record
    In the record construction: Viewer
                                    {viewCatalog = printCatalog, 
viewShowable = putStrLn . show}
    In the definition of `printer':
        printer = Viewer {viewCatalog = printCatalog, viewShowable = 
putStrLn . show}

Bug.lhs:27:0:
    Contexts differ in length
    When matching the contexts of the signatures for
      printer :: Viewer
      printCatalog :: forall c. (Catalog c) => View c
    The signature contexts in a mutually recursive group should all be 
identical

The code compiles and works fine if the definition of 'printer' is 
replaced by the out-commented version, that is, if a lambda expression 
is used that is identical to the definition of 'printCatalog'. BTW, 
this does not happen with hugs.

It looks like a bug to me, but since I use some non-standard features, 
maybe there is some subtle explanation for this behavior.

Ben