Typechecking problems with pipes-attoparsec

Question

I've been trying out pipes-attoparsec but haven't been having much luck.

It appears that there is a type mismatch between Void and X in (what seems to be) relatively straightforward code. From what I've read in the library (that this will be a type synonym at some point), I'm not sure how to interpret the type error.

Test code:

{-# LANGUAGE OverloadedStrings,RankNTypes #-}
module Main where

import qualified Data.Attoparsec.Char8 as A

import qualified Pipes as P
import qualified Pipes.Attoparsec as PA        
import qualified Pipes.ByteString as PB
import qualified Pipes.Parse  as PP

passthrough :: A.Parser PB.ByteString
passthrough = A.takeWhile (\s->True)

f :: Monad m => PP.StateT (P.Producer PB.ByteString m r) m (Either String  String)
f = do
  r <- PA.parse passthrough
  return $ case r of
    Left e -> Left "a"
    Right (_,r1) -> Right "b"

g = PP.evalStateT f PB.stdin

h = P.runEffect g

This results in the error:

P.hs:16:8:
    Couldn't match type `pipes-4.0.2:Pipes.Internal.Proxy
                           Data.Void.Void () () PB.ByteString m r0'
                  with `P.Proxy P.X () () PB.ByteString m r'
    Expected type: PP.StateT
                     (PP.Producer PB.ByteString m r)
                     m
                     (Either PA.ParsingError (Int, PB.ByteString))
      Actual type: PP.StateT
                     (pipes-4.0.2:Pipes.Core.Producer PB.ByteString m r0)
                     m
                     (Either PA.ParsingError (Int, PB.ByteString))
    In the return type of a call of `PA.parse'
    In a stmt of a 'do' block: r <- PA.parse passthrough
    In the expression:
      do { r <- PA.parse passthrough;
           return
           $ case r of {
               Left e -> Left "a"
               Right (_, r1) -> Right "b" } } Failed, modules loaded: none.

score 1 · Answer 1 · answered Feb 06 '14 at 12:35

1

You need to upgrade to the latest pipes-attoparsec, which restricts its pipes dependency to 4.1.*. I can give you more detailed information for how this might have arisen if you list what versions you have installed for pipes, pipes-parse, and pipes-attoparsec. If you type ghc-pkg list | grep pipes that should be enough.

answered Feb 06 '14 at 12:35

Gabriella Gonzalez

34,863
3
77
135

Thanks, that was exactly the issue, and after fixing the case expression and adding a type signature it now typechecks. – user1219 Feb 07 '14 at 04:05
Before installing the new version: pipes-4.0.2 pipes-4.1.0 pipes-aeson-0.2.1 pipes-attoparsec-0.3.1 pipes-bytestring-2.0.0 pipes-group-1.0.0 pipes-network-0.6.1 pipes-network-tls-0.2.0 pipes-parse-2.0.2 pipes-parse-3.0.1 pipes-safe-2.0.1 – user1219 Feb 07 '14 at 04:06
Yeah, it looks like what happened is `pipes-attoparsec` was compiled against the older `pipes` and `pipes-parse` was compiled against the newer `pipes`. The actual conflict was not the the `X` type synonym, but rather that it was using two versions of `Proxy`. – Gabriella Gonzalez Feb 07 '14 at 04:23

score 0 · Answer 2 · answered Feb 06 '14 at 08:20

It looks like you are using pipes-4.1.0 with a version pipes-attoparsec(or another pipes-* package I can not tell for sure from the error message alone.) that expects pipes-4.0.2.

There is a good chance you need to use ghc-pkg hide to hide an older version of pipes-attoparsec(or other pipes-* package) if you have both the old and the recent version installed. I have had to do this with other packages occasionally, it is not clear to me how cabal/ghci/ghc get in the state where is necessary however.

Use ghc-pkg list | grep pipes-attoparsec to see which versions you have installed and try hiding the older one. If you only have the older one installed then use cabal install to get the new one.

The Void vs X mismatch comes from pipes-4.1.0 way from the void package.

This would happen if he installed `pipes-4.0.2`, then installed `pipes-attoparsec`, then installed `pipes-4.1.0` and hid the previous version of pipes. Just don't install multiple versions of the same package. Bad things happen. — Carl, Feb 06 '14 at 08:23
@Carl I have had this type of problem come up without ever hiding a package, after a series of `cabal install`s. On mac 10.8.5. — Davorak, Feb 06 '14 at 08:28

Typechecking problems with pipes-attoparsec

2 Answers2