v4.0.0 tutorial failure ?

[chrisprobst]

The latest v4.0.0 tutorial says that:

$easytobuild Haskell pipes are simple to write. For example, here's the code for 'P.stdout':

import Control.Monad
import Pipes
stdout :: () -> Consumer String IO r
stdout () = forever $ do
    str <- request ()
    lift $ putStrLn str

---

But trying this using GHC 7.6.3 gives me:

Illegal polymorphic or qualified type: Consumer String IO r
Perhaps you intended to use -XRankNTypes or -XRank2Types
In the type signature for stdout':
stdout' :: () -> Consumer String IO r
Main.hs /haskell-test/src   line 70 Haskell Problem

---

Code:

module Main where

import           Control.Monad
import           Pipes
import qualified Pipes.Prelude      as P
import qualified System.IO as IO

stdin' :: () -> Producer String IO ()
stdin' () = loop
  where
    loop = do
        eof <- lift $ IO.hIsEOF IO.stdin
        unless eof $ do
            str <- lift getLine
            respond str
            loop

stdout' :: () -> Consumer String IO r
stdout' () = forever $ do
    str <- request ()
    lift $ putStrLn str

main :: IO ()
main = runEffect $ (stdin' >-> stdout') ()

---

Is this switch really necessary or did I make a mistake ?

[Gabriella439]

I'm actually going to switch to the concrete versions as the default (I.e. no apostrophe) and only use the polymorphic versions for library utilities. This will fix your problem.

[Gabriella439]

Leave it open for now so I don't forget to fix this.

Sorry about not explaining my terminology. Allow me to explain.

pipes uses two types of type synonyms: concrete and polymorphic type synonyms.

Here's an example concrete type synonym:

type Consumer' a m r = Proxy () a () C m r

Here's an example of a polymorphic type synonym:

type Consumer a m r = forall b' b . Proxy () a b' b m r

The advantage of the polymorphic versions is that they will type-check as more general types. For example, you can use a Consumer where something expects a Pipe. The disadvantage of the polymorphic versions is that they require higher rank types when you use them in type signatures, causing the sort of problems that you just noticed.

So what I'm going to do is switch the concrete type synonyms to the default version (i.e. make the type synonyms without apostrophes use concrete types) and have the polymorphic type synonyms use the apostrophes. Then I will only use the polymorphic type synonyms for defining library utilities but users can use the concrete versions and get nice type inference without requiring any extensions.

Sorry if that's still possibly not a bit clear, but I'm typing this in a hurry because my wife wants me to go shopping with her right now.

[chrisprobst]

I just realized this, too. That's why I thought this issue might be useless. Now what you wrote makes totally sense for me. Thanks and have fun shopping ;)

[Shimuuar]

On 04.07.2013 22:09, Gabriel Gonzalez wrote:

I'm actually going to switch to the concrete versions as the default (I.e. no apostrophe) and only use the polymorphic versions for library utilities. This will fix your problem.

It could lead to problems with impredicativity too. It could arise when pipe is returned as result of monadic action.

test :: Show a => IO (Consumer a IO r) test = undefined

It;s a bit of corner case so I'm not sure it's important.

[Gabriella439]

Actually, impredicativity is a very important case. I have already been bitten by it multiple times in my experiments, which is why I was already considering switching.

[Gabriella439]

Ok, I switched the type synonyms so now the versions without an apostrophe use all concrete types, so you should not have any problems any more. Just double-check that the tutorial examples now work for you without any extensions enabled, although I don't see any reason why they shouldn't.

[chrisprobst]

Thanks! Awesome!

[Gabriella439]

Alright, I will go ahead and close this, then. If you have any other problems then feel free to let me know.