It's quite old at this point, but you may be interested in reading the initial motivations for creating conduit when the iteratee pattern (and enumerator library in particular) already existed:

https://github.com/snoyberg/conduit/blob/master/README.md#general-goal

I would say the only real component missing from your list is being able to structure significantly more complicated control flows, such as the use case of combining a web server and web client into a web proxy. That was probably the example which finally pushed me to start thinking seriously about an enumerator replacement. In conduit, this use case is addressed by connect-and-resume, which essentially allows you to escape the inversion of control normally introduced by the conduit pattern.


On Fri, May 10, 2013 at 5:56 PM, Ertugrul Söylemez <es@ertes.de> wrote:
Hello everybody,

I'm trying to formulate the stream processing problem, which doesn't
seem to be solved fully by the currently existing patterns.  I'm
experimenting with a new idea, but I want to make sure that I don't miss
any defining features of the problem, so here is my list.  A stream
processing abstraction should:

  * have a categorically proven design (solved by iteratees, pipes),

  * be composable (solved by all of them),

  * be reasonably easy to understand and work with (solved by conduit,
    pipes),

  * support leftovers (solved by conduit and to some degree by
    iteratees),

  * be reliable in the presence of async exceptions (solved by conduit,
    pipes-safe),

  * hold on to resources only as long as necessary (solved by conduit
    and to some degree by pipes-safe),

  * ideally also allow upstream communication (solved by pipes and to
    some degree by conduit).

  * be fast (solved by all of them).

Anything else you would put in that list?


Greets,
Ertugrul

--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.

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