Inferred type is less polymorphic than expected?

Benjamin Franksen benjamin.franksen at
Fri Jul 29 18:23:05 EDT 2005


I get an error message when I compile the following program with 

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

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

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

    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}

    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 

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.


More information about the Glasgow-haskell-users mailing list