Problems with polymorphic kinds imported from module

[goldfire]

There seems to be a problem when importing polymorphic kinds from a module in a cabalized package. One way to spot the problem is to cabal install singletons, import Singletons.Lib and run :t SNil in ghci. ghci reports a stack overflow. Another way to access (what I think is) the same error is to compile the following:

{-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators,
             GADTs, RankNTypes #-}

import Singletons.Lib

type family Map (f :: k1 -> k2) (a :: [k1]) :: [k2]
type instance Map f '[] = '[]
type instance Map f (h ': t) = (f h) ': (Map f t)

sMap :: forall (f :: k1 -> k2) (b :: [k1]).
        (forall a. Sing a -> Sing (f a)) -> Sing b -> Sing (Map f b)
sMap _ SNil = SNil
sMap f (SCons h t) = SCons (f h) (sMap f t)

The error message is

    Couldn't match kind `BOX' against `[k1]'
    Kind incompatibility when matching types:
      k1 :: BOX
      b :: [k1]
    In the pattern: SNil
    In an equation for `sMap': sMap _ SNil = SNil

Neither of these problems surface when checking the type of SNil or compiling the above code when the singletons sources are at hand and are interpreted.

I tried to make a small test case for this but was unable to reproduce the error after a number of attempts, including using Template Haskell to generate the Sing instance for type-level lists, as is done in the singletons library.

This was all tested on 7.5.20120620. There's a good chance this bug is related to #7022.

[simonpj]

I tried to cabal install singletons but failed:

$ cabal install --with-compiler=c:/code/HEAD-2/inplace/bin/ghc-stage2 singletons
Resolving dependencies...
cabal.exe: cannot configure syb-0.3.6.1. It requires base >=4.0 && <4.6
For the dependency on base >=4.0 && <4.6 there are these packages:
base-4.0.0.0, base-4.1.0.0, base-4.2.0.0, base-4.2.0.1, base-4.2.0.2,
base-4.3.0.0, base-4.3.1.0, base-4.4.0.0, base-4.4.1.0, base-4.5.0.0 and
base-4.5.1.0. However none of them are available.
base-4.0.0.0 was excluded because array-0.3.0.3 requires base >=4.2 && <5
base-4.0.0.0 was excluded because template-haskell-2.6.0.0 requires base >=4.2
&& <5
base-4.0.0.0 was excluded because containers-0.5.0.0 requires base >=4.2 && <5
base-4.0.0.0 was excluded because base-4.6.0.0 was selected instead
base-4.0.0.0 was excluded because of the top level dependency base -any
base-4.1.0.0 was excluded because array-0.3.0.3 requires base >=4.2 && <5
base-4.1.0.0 was excluded because template-haskell-2.6.0.0 requires base >=4.2
&& <5
base-4.1.0.0 was excluded because containers-0.5.0.0 requires base >=4.2 && <5
base-4.1.0.0 was excluded because base-4.6.0.0 was selected instead
base-4.1.0.0 was excluded because of the top level dependency base -any
base-4.2.0.0 was excluded because base-4.6.0.0 was selected instead
base-4.2.0.0 was excluded because of the top level dependency base -any
base-4.2.0.1 was excluded because base-4.6.0.0 was selected instead
base-4.2.0.1 was excluded because of the top level dependency base -any
base-4.2.0.2 was excluded because base-4.6.0.0 was selected instead
base-4.2.0.2 was excluded because of the top level dependency base -any
base-4.3.0.0 was excluded because base-4.6.0.0 was selected instead
base-4.3.0.0 was excluded because of the top level dependency base -any
base-4.3.1.0 was excluded because base-4.6.0.0 was selected instead
base-4.3.1.0 was excluded because of the top level dependency base -any
base-4.4.0.0 was excluded because base-4.6.0.0 was selected instead
base-4.4.0.0 was excluded because of the top level dependency base -any
base-4.4.1.0 was excluded because base-4.6.0.0 was selected instead
base-4.4.1.0 was excluded because of the top level dependency base -any
base-4.5.0.0 was excluded because base-4.6.0.0 was selected instead
base-4.5.0.0 was excluded because of the top level dependency base -any
base-4.5.1.0 was excluded because base-4.6.0.0 was selected instead
base-4.5.1.0 was excluded because of the top level dependency base -any

I manually deleted the dependency on syb (thinking I could comment out the code that depended on syb but that still failed:

$ cabal install --with-compiler=c:/code/HEAD-2/inplace/bin/ghc-stage2
Resolving dependencies...
Downloading mtl-2.1.1...
Configuring mtl-2.1.1...
Preprocessing library mtl-2.1.1...
Building mtl-2.1.1...
[ 1 of 21] Compiling Control.Monad.Writer.Class ( Control\Monad\Writer\Class.hs, dist\build\Control\Monad\Writer\Class.o
 )
[ 2 of 21] Compiling Control.Monad.State.Class ( Control\Monad\State\Class.hs, dist\build\Control\Monad\State\Class.o )
[ 3 of 21] Compiling Control.Monad.Reader.Class ( Control\Monad\Reader\Class.hs, dist\build\Control\Monad\Reader\Class.o
 )
[ 4 of 21] Compiling Control.Monad.RWS.Class ( Control\Monad\RWS\Class.hs, dist\build\Control\Monad\RWS\Class.o )
[ 5 of 21] Compiling Control.Monad.Identity ( Control\Monad\Identity.hs, dist\build\Control\Monad\Identity.o )
[ 6 of 21] Compiling Control.Monad.Error.Class ( Control\Monad\Error\Class.hs, dist\build\Control\Monad\Error\Class.o )

Control\Monad\Error\Class.hs:93:18: Not in scope: `catch'
cabal.exe: Error: some packages failed to install:
mtl-2.1.1 failed during the building phase. The exception was:
ExitFailure 1
singletons-0.8 depends on mtl-2.1.1 which failed to install.

So I'm stuck at the first fence.

GHC should never be unifying BOX with [k]. They belong to different levels. Something is badly wrong. I am eager to reproduce it.

[goldfire]

I ran into those two problems as well with the recent version of GHC, but I thought the problems were local. Here are the fixes I used (package maintainers already notified):

• For the syb problem, change syb.cabal to allow a greater range of version numbers for the base package. I changed my file to allow base >= 4.0 && < 5.0 and it worked.
• For the mtl package, you'll need to edit Control/Monad/Error/Class.hs. Add catch to the import list from Control.Exception on line 55.

I believe these were the only package-related problems I had, so these fixes should allow you to proceed.

[goldfire]

Both the mtl and syb packages have been updated since my last comment (to versions 2.1.2 and 0.3.6.2, respectively) and now work without a hiccup. Thanks, Edward Kmett and José Pedro Magalhães!

[simonpj@…]

commit 3fe3ef509627cb8c9aa7751beb44d1b4408f8b22

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Tue Jul 10 16:02:03 2012 +0100

    More changes to kind inference for type and class declarations
    
    These should fix #7024 and #7022, among others.
    
    The main difficulty was that we were getting occ-name clashes
    between kind and type variables in TyCons, when spat into an
    interface file. The new scheme is to tidy TyCons during the
    conversoin into IfaceSyn, rather than trying to generate them
    pre-tidied, which was the already-unsatisfactory previous plan.
    
    There is the usual wave of refactorig as well.

 compiler/iface/MkIface.lhs          |  129 +++++++++++++++++++++-----------
 compiler/typecheck/TcHsType.lhs     |  143 ++++++++++++++++++++---------------
 compiler/typecheck/TcRnDriver.lhs   |    8 +-
 compiler/typecheck/TcRnTypes.lhs    |   40 +++++++---
 compiler/typecheck/TcRules.lhs      |    3 +-
 compiler/typecheck/TcTyClsDecls.lhs |  110 +++++++++++++-------------
 compiler/types/Kind.lhs             |    9 ++-
 7 files changed, 267 insertions(+), 175 deletions(-)

[simonpj]

It's fixed by the above patch.

The test for #7022 will do for this one. I don't want a regression test that is so elaborate!

Simon