0

I'm working on some parsec code. At the bottom of the script, there's a parseFromFile call, where ParseFromFile comes from Text.Parsec.String

parseFromFile parserCode inFile

If I comment this out, my code no longer compiles and I get a host of ambiguous type errors:

DeleteMe.hs:47:18-23: No instance for (Stream s0 Data.Functor.Identity.Identity Char) …
      arising from a use of ‘noneOf’
    The type variable ‘s0’ is ambiguous
    Relevant bindings include
      parseSeq :: ParsecT s0 u Data.Functor.Identity.Identity [Char]...

with ambiguities like between the strict and lazy forms of streams:

Note: there are several potential instances:
  instance Monad m =>
           Stream Data.ByteString.Internal.ByteString m Char
    -- Defined in ‘Text.Parsec.Prim’
  instance Monad m =>
           Stream Data.ByteString.Lazy.Internal.ByteString m Char
    -- Defined in ‘Text.Parsec.Prim’
  instance Monad m => Stream Text m Char
    -- Defined in ‘Text.Parsec.Prim’

parseFromFile must be disambiguating the type inference. What's the right way to resolve this ambiguity? Including the parseFromFile call will get it to compile, but I don't want to have to have to call it for that purpose. I could type annotate all combinator code, but that's messy.

daj
  • 6,962
  • 9
  • 45
  • 79

1 Answers1

1

parseFromFile has type

parseFromFile :: Text.Parsec.String.Parser a -> String -> IO (Either Text.Parsec.Error.ParseError a)

So adding a type annotation to parserCode should solve the issue:

parserCode :: Text.Parsec.String.Parser a

This is not as general as it could be now (we might want to use Text.Parsec.ByteString.parseFromFile as well for example). For that case, we can probably use something like

parserCode :: Stream s Identity Char => Parsec s () a
Fabian Schmitthenner
  • 1,696
  • 10
  • 22