Conversions between pipes and conduit

[Dan Burton]

https://github.com/DanBurton/pipes-conduit/blob/master/Data/PipesConduit.hs

I've spent a little time throwing this together. What do you think? My goal is to keep exploring this space in search of sensible idioms for converting between the two libraries. After installing a layer of interoperability, we might be able to start merging the projects.

Proxies provide an upstream and a downstream interface, where "requests" and "responses" are specific (or polymorphic) types for each interface. Conduits are only designed to send meaningful information downstream (send responses downstream, and wait for responses from upstream).

Let the notation A :-> B designate a conduit which accepts inputs from upstream of type A, and sends outputs downstream of type B.

Let the notation A -> B designate a proxy interface on one side, where requests are of type A, and responses are of type B.

When turning a proxy into a conduit, it can only accept trivial requests from downstream (unit), and the requests it sends upstream can be anything, since upstream conduits do not understand the meaning of requests other than as a signal for more. Hence, the upstream interface is A' ~> A, while the downstream interface is () -> B, which gets turned into the conduit A :-> B.

When turning a conduit into a proxy, it can only send trivial requests upstream (unit), and the requests it receives from downstream can be anything, since it does not understand the meaning of requests other than as a signal for more. Hence, the conduit A :-> B gets turned into the proxy with upstream interface () ~> A, and downstream interface of B' ~> B.

Conduit adds the following features on top of FastProxy:

1. ability to recover from upstream termination, inspecting the upstream termination signal of type U

2. pass finalizers of type M () to run in the event of downstream termination

3. inject leftovers back into its own stream for later consumption

When turning a FastProxy into a Conduit, I chose to:

1. provide a trivial recovery from upstream termination, by terminating with the same value

2. provide the trivial finalizer (return ())

3. ignore the leftover functionality

When turning a Conduit into a Proxy, I chose to:

1. limit the transformation to conduits whose upstream termination signal is trivial: ()

2. use pipes-safe to handle finalization

3. use pipes-parse to handle leftovers

This leaves a lot to be desired, but at least it is a start. What are your thoughts?