[Haskell-cafe] Stream processing

Michael Snoyman michael at snoyman.com
Sat May 11 20:04:31 CEST 2013


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>


More information about the Haskell-Cafe mailing list