[Haskell-cafe] Stream processing

[Michael Snoyman]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130511/510cec51/attachment.htm>