On Mon, Apr 9, 2012 at 2:27 PM, Erik de Castro Lopo wrote:

Michael Snoyman wrote:

...

Hmm... I'd be surprised if you really need the Pipe signature that you're providing.

I'm not providing it, the compiler is suggesting it:

   Network/HTTP/Proxy.hs:835:47:        Couldn't match expected type `ByteString' with actual type `()'        Expected type: C.Pipe Void ByteString (ResourceT IO) ByteString          Actual type: C.Source (ResourceT IO) ByteString        In the return type of a call of `requestBody'        In the second argument of `($)', namely `requestBody req'

For the code:

   HC.requestBody = HC.RequestBodySource contentLength                         $ fmap copyByteString                         $ Wai.requestBody req

but the type of the RequestBodySource constructor and Wai.requestBody hasn't changed.

Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

It's caused by fmap. This is one of the downsides with the move to a single type: some of the instances don't make sense anymore. In particular, Functor will allow you to map the *result* type, not the *output* type. I think I'll add a helper function- mapOutput- to the next version of conduit. Meanwhile, you can use: Wai.requestBody req $= Data.Conduit.List.map copyByteString Michael

On Mon, Apr 9, 2012 at 2:37 PM, Ivan Lazar Miljenovic wrote:

On 9 April 2012 21:34, Michael Snoyman wrote:

...

It's caused by fmap. This is one of the downsides with the move to a single type:

I've been reading the various posts you've been making about Conduit, and this is something I still don't get: wasn't one of the original strengths you touted for Conduit that usage of different types made for better error messages, etc.?  As such, why have you now switched to a single type and thus causing these kinds of problems again?

Honestly, I'm still torn on this. If you read through the arguments in Reddit, you'll see a lot of: Everyone else: Well, obviously this is more elegant because it's a single type Me: Err.... I'm not convinced. There *are* definitely advantages to this new approach, but there are also costs. The fact that such a huge part of the codebase simply disappeared, and that it's easier to step through the remaining code and convince myself that it's doing the right thing, is what put me over the edge on this one. To clarify just a bit: the *main* advantage of conduit's multiple types approach (versus enumerator where everything is an Iteratee) is that (1) it's easier to understand, and (2) it makes it possible to do things like resumable sources. Both of those advantages still hold: writing a Conduit retains its relative simplicity versus an Enumeratee in this new system, for example. The downside is really the error messages and the instances. It might be that we decide to introduces newtype wrappers for Source, Conduit, and Sink in the future to solve these problems, I'm not sure. For now, it seems like an acceptable trade-off. Michael