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.
signature.asc
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
