Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon"

[igloo]

With GHC 6.6, this module:

module G where

testL = foo undefined

class Foo t where
    foo :: m a -> t m a

leaks some debugging info(?):

Urk! Inventing strangely-kinded void TyCon:
    :t{tc ae2}
    (* -> *) -> * -> *

tmp.hs:4:8:
    Ambiguous type variable `t' in the constraint:
      `Foo t' arising from use of `foo' at tmp.hs:4:8-20
    Possible cause: the monomorphism restriction applied to the following:
      testL :: forall (m :: * -> *) a. t m a (bound at tmp.hs:4:0)
    Probable fix: give these definition(s) an explicit type signature
                  or use -fno-monomorphism-restriction

I haven't managed to get this message in an acceptable program.

(found by fasta on IRC)

[simonpj]

The leakage is actually deliberate.

In this program there is nothing to fix 'm' in the call to 'foo', so GHC makes up a fake type constructor, of kind (*->*)->*, and uses that at the call to foo.

Now the trouble is that if this fake type constructor should show up in an interface file, GHC would not recognise the type constructor when reading the interface. So I left the warning in, so that people would yell if it actually happened.

This is really a bug, and I'm sure there's a way round it, but it has not occurred in a real program so far, so I've been postponing fixing it, and propose to continue to postpone.

The relevant code is in TcHsSyn.mkArbitraryType

[guest]

Here's a program that provokes the message (in 6.6.1), but otherwise passes the typechecker:

{-# OPTIONS_GHC -fglasgow-exts #-}

data D (f :: (* -> *) -> * -> *) (af :: * -> *) (ax :: *) =
  D (af (f af ax))

data CList (f :: (* -> *) -> * -> *) (a :: *) =
  RCons a (CList (D f) a)

type CycleList a = forall f. CList f a

chead :: CycleList a -> a
chead ys = case ys of (RCons x xs) -> x

Andres

[igloo]

Andres ran into this in a real program, so I'm reclassifying it.

[simonmar]

confirmed in 6.8.1.

[simonpj]

OK, I have

• turned the "trace" into a civilised warning
• added a tiny bit of advice about how to suppress the warning (add a type signature)
• given a reference to this page
• added a test case

None of this is the Real Fix, which is to provide a way to robustly export strangely-kinded Any TyCons across interface files. But that's a bigger job, and I'm still unconvinced it's worth doing.

If you trip over the new warning in a real program, and have thereby found your way to this page, please add a comment to say so. Better still, please upload a small example, so we can gather evidence about how important this is.

Ian: merge to the 6.8 branch; then change milestone to _|_, and type to 'Bug'

Mon Nov 19 12:29:38 GMT 2007  simonpj@microsoft.com
  * Improve the situation for Trac #959: civilised warning 
          instead of a trace msg

[igloo]

Merged

[magnushiie]

A real-world example of the same error:

-- Specifying -fno-monomorphism-restriction removes the error
--{-# OPTIONS_GHC -fno-monomorphism-restriction #-}

module ParsecWrap where

import Control.Monad.Trans
import qualified Text.ParserCombinators.Parsec as P

-- these work without type signature
many1 f = lift $ P.many1 f
oneOf cs = lift $ P.oneOf cs
{-
:t many1
many1 :: (MonadTrans t) =>
P.GenParser tok st a -> t (P.GenParser tok st) [a]
:t oneOf
oneOf :: (MonadTrans t) => [Char] -> t (P.GenParser Char st) Char
-}
--anyChar :: MonadTrans t => t (P.GenParser Char st) Char
anyChar = lift $ P.anyChar
{-
Without type signature on anyChar, gives:
Urk! Inventing strangely-kinded void TyCon:
    :t{tc a1vc}
    (* -> *) -> * -> *

D:\Dev\Test\ParseCpp\src\ParsecWrap.hs:30:10:
    Ambiguous type variable `t' in the constraint:
      `MonadTrans t'
        arising from use of `lift'
        at D:\Dev\Test\ParseCpp\src\ParsecWrap.hs:30:10-13
    Possible cause: the monomorphism restriction applied to the following:
      anyChar :: forall st. t (P.GenParser Char st) Char
        (bound at D:\Dev\Test\ParseCpp\src\ParsecWrap.hs:30:0)
    Probable fix: give these definition(s) an explicit type signature
                  or use -fno-monomorphism-restriction
Failed, modules loaded: none.
-}

[ganesh]

I have encountered this in darcs when trying to make our phantom types be of some complicated (and arbitrarily chosen) kind to minimise the risk of them being instantiated with a real type (which would then lead to a risk of unsafeCoerce happening on those real types due to other aspects of the way we use phantom types).

[simonpj]

I finally got around to fixing this

Thu Oct 15 13:28:10 BST 2009  simonpj@microsoft.com
  * Fix Trac #959: a long-standing bug in instantiating 
    otherwise-unbound type variables
      
     DO NOT MERGE TO GHC 6.12 branch
     (Reason: interface file format change.)
  
  The typechecker needs to instantiate otherwise-unconstraint type variables to
  an appropriately-kinded constant type, but we didn't have a supply of 
  arbitrarily-kinded tycons for this purpose.  Now we do.
  
  The details are described in Note [Any types] in TysPrim.  The
  fundamental change is that there is a new sort of TyCon, namely
  AnyTyCon, defined in TyCon.
  
  There's a small change to interface-file binary format, because the new
  AnyTyCons have to be serialised.
  
  I tided up the handling of uniques a bit too, so that mkUnique is not
  exported, so that we can see all the different name spaces in one module.
  

    M ./compiler/basicTypes/OccName.lhs -10 +11
    M ./compiler/basicTypes/Unique.lhs -4 +20
    M ./compiler/deSugar/DsBinds.lhs -25 +23
    M ./compiler/iface/BinIface.hs -1 +5
    M ./compiler/iface/IfaceType.lhs -11 +22
    M ./compiler/iface/TcIface.lhs +3
    M ./compiler/nativeGen/Reg.hs -2 +2
    M ./compiler/nativeGen/RegAlloc/Graph/ArchBase.hs -2 +2
    M ./compiler/nativeGen/RegAlloc/Graph/SpillClean.hs -3 +3
    M ./compiler/nativeGen/RegClass.hs -3 +3
    M ./compiler/prelude/PrelNames.lhs -5 +3
    M ./compiler/prelude/TysPrim.lhs -56 +120
    M ./compiler/prelude/TysWiredIn.lhs -4 +2
    M ./compiler/stgSyn/CoreToStg.lhs -1 +1
    M ./compiler/typecheck/TcHsSyn.lhs -75 +1
    M ./compiler/types/TyCon.lhs -16 +44
    M ./compiler/types/TypeRep.lhs -8 +5
    M ./compiler/vectorise/VectUtils.hs -1 +1

IAN: Don't merge to the 6.12 branch, because it changes interface file formats slightly.

tcfail188 now compiles ok.

BEN: as part of the mkUnique tidy-up I moved a few lines from nativeGen to Unique. Can you just review the patch (the bits affecting nativeGen are only a few lines) to check it's ok. It seems to validate.

Simon

[benl]

Looks ok to me.