ghc-7.10: Non type-variable argument (Use FlexibleContexts to permit this)

Question

I was trying to use ghc-7.10 (RC 2) and got this message in a number of cases, e.g.,

src/Text/Regex/XMLSchema/Generic/RegexParser.hs:439:5:
    Non type-variable argument
      in the constraint: Text.Parsec.Prim.Stream s m Char
    (Use FlexibleContexts to permit this)
    When checking that ‘prop’ has the inferred type
      prop :: forall s u (m :: * -> *) (t :: * -> *).
              (Foldable t, Text.Parsec.Prim.Stream s m Char) =>
              Char -> t Char -> Text.Parsec.Prim.ParsecT s u m [Char]
    In an equation for ‘isCategory'’:
        isCategory'
          = (foldr1 (<|>) . map (uncurry prop)
             $ [('L', "ultmo"), ('M', "nce"), ('N', "dlo"), ....])
            <?> "illegal Unicode character property"
          where
              prop c1 cs2
                = do { _ <- char c1;
                       .... }
Failed to install hxt-regex-xmlschema-9.2.0

This must be something that is introduced by the new ghc, or the new base that comes with it, or the new parsec (3.1.8), since it worked before.

source code snippet:

isCategory'     :: Parser String
isCategory'
    = ( foldr1 (<|>) . map (uncurry prop) $
        [ ('L', "ultmo")
        , ('M', "nce")
        , ('N', "dlo")
        , ('P', "cdseifo")
        , ('Z', "slp")
        , ('S', "mcko")
        , ('C', "cfon")
        ]
      ) <?> "illegal Unicode character property"
    where
    prop c1 cs2
        = do
          _ <- char c1
          s2 <- option ""
                ( do
                  c2 <- satisfy (`elem` cs2)
                  return [c2] )
          return $ c1:s2

Note: I am not asking about this specific libray (hxt-*) since I observed this in other places also.

I'm guessing GHC has been changed to require the appropriate language extensions when an *inferred* type requires them. Currently, it will happily infer types with all sorts of exotic things like TypeFamilies and DataKinds without those things enabled in that module. I can't find any documentation of this change, however. The most general type of `prop` is `Stream s m Char => Char -> [Char] -> ParsecT s u m [Char]`, for which you would need FlexibleContexts to write. — user2407038, Feb 02 '15 at 22:28

score 19 · Accepted Answer · answered Feb 02 '15 at 22:35

19

This was a change introduced in GHC 7.10.1-rc1:

GHC now checks that all the language extensions required for the inferred type signatures are explicitly enabled. This means that if any of the type signatures inferred in your program requires some language extension you will need to enable it. The motivation is that adding a missing type signature inferred by GHC should yield a program that typechecks. Previously this was not the case.

This is a breaking change. Code that used to compile in the past might fail with an error message requiring some particular language extension (most likely -XTypeFamilies, -XGADTs or -XFlexibleContexts).

answered Feb 02 '15 at 22:35

bheklilr

53,530
6
107
163

hmm perhaps I'm doing it wrong but this would appear to be the issue in ghci (7.10.1) if you concat two simple strings, e.g. "Has" ++ "kell". I have to say if I didn't know Haskell is the bees knees and was committed to learning it, an error on something simple like string concatenation might nope me the hell away from the language. – engineerDave Jul 08 '15 at 20:22
@engineerDave What is the error you're seeing? The only possible extensions that might come into play are `OverloadedStrings` or `OverloadedLists`, neither of which are enabled by default. – bheklilr Jul 08 '15 at 21:24
Umm. I think this may be an error introduced by a cabal package. Given the lunacy of not being able to concat two strings, I assumed PEKAC and I changed to a "clean" directory, i.e. no cabal sandbox and this error went away. So I guess red faced I have to crawl back into my hidey hole and thank you for your diligent response to my Haskell n00b comment – engineerDave Jul 08 '15 at 21:50
2

@engineerDave Yeah, it can happen if you have `OverloadedStrings` turned on globally for your cabal project, then started ghci using `cabal repl`. I've run into that before too, it's not just a noob problem! – bheklilr Jul 08 '15 at 21:53
@bheklilr, this is one of the reasons most people avoid global cabal options and just live with verbosity. – dfeuer Mar 20 '16 at 05:44

score 1 · Answer 2 · answered Apr 21 '16 at 19:38

I'm having the same issue with my code, part of it that uses Parsec and part of it that doesn't. Most all of these point to functions without signatures in a where block.

The solution that works for me is to add explicit signatures for the functions, where you can use the inferred type you get from the error for the most part, but rather than keeping types such as ParsecT s u m [Char] generic, I supply the concrete type I want, such as Parsec String () [Char].

score 0 · Answer 3 · answered Mar 19 '16 at 19:59

I got this error after setting up a barebone Snap application as described here.

String operations like "" ++ "" or "Haskell" !! 2 were broken. When sourcing a Haskell file from GHCI, I got a variant of this error:

No instance for (Data.String.IsString [a0]) arising from the literal "my string"' The type variablea0' is ambiguous Relevant bindings include myString :: [a0] (bound at myFile.hs:11:1) Note: there is a potential instance available: instance Data.String.IsString [Char] -- Defined in Data.String' In the expression: "my string" In an equation forvariable': variable = "my string"

Solution:

The way to fix this was to remove the line :set -XOverloadedStrings from the .ghci file in my project and restart GHCI.

ghc-7.10: Non type-variable argument (Use FlexibleContexts to permit this)

3 Answers3