Hi All, I really love the look of this package, but if this is going be *the* iteratee package, I would absolutely love to see it fix some of the biggest mistakes in the other iteratee packages, soecifically naming. A change in naming for the terms iteratee, enumerator and enumeratee would go a hell of a long way here; Peaker on #haskell suggested Consumer/Producer/Transformer, and there is a lot of agreement in the channel that these are vastly better names. They’re also far less intimidating to users. I personally feel that maybe Transformer isn't such a great name (being closely associated with monad transformers), and that maybe something like Mapper would be better, but I'm by no means in love with that name either. More people in #haskell seem to like Transformer, and I don't think my argument against it is very strong, so the hivemind seems to have settled on the Producer/Transformer/Consumer trilogy. I'd love to hear thoughts on the issue, especially from David. Cheers, Alex Mason On 06/05/2011, at 20:17, Maciej Marcin Piechotka wrote:
On Thu, 2011-05-05 at 21:15 -0700, David Mazieres wrote:
Hi, everyone. I'm pleased to announce the release of a new iteratee implementation, iterIO:
http://hackage.haskell.org/package/iterIO
IterIO is an attempt to make iteratees easier to use through an interface based on pipeline stages reminiscent of Unix command pipelines. Particularly if you've looked at iteratees before and been intimidated, please have a look at iterIO to see if it makes them more accessible.
Some aspects of iterIO that should simplify learning and using iteratees are:
* Every aspect of the library is thoroughly document in haddock including numerous examples of use.
* Enumerators are easy to build out of iteratees.
* There is no difference between enumerators and "enumeratees" (i.e., inner pipeline stages). The former is just a type-restricted version of the latter.
* Parsing combinators provide detailed error reporting and support LL(*) rather than LL(1) parsing, leading to fewer non-intuitive parsing failures. A couple of tricks avoid consuming excessive memory for backtracking.
* Super-fast LL(1) parsing is also available through seamless integration with attoparsec.
* A universal exception mechanism works across invocations of mtl monad transformers, thereby unifying error handling.
* All pipe operators have uniform semantics, eliminating corner cases. In particular, if the writing end of a pipe fails, the reading end always gets EOF, allowing it to clean up resources.
* One can catch exceptions thrown by any contiguous subset of stages in a pipeline. Moreover, enumerator exception handlers can resume downstream stages that haven't failed.
* The package is full of useful iteratees and enumerators, including basic file and socket processing, parsec-like combinators, string search, zlib/gzip compression, SSL, HTTP, and "loopback" enumerator/iteratee pairs for testing a protocol implementation against itself.
Please enjoy. I'd love to hear feedback.
David
1. It looks nice - however it causes problem as we have 3 iteratees packages, all of which have some advantages. 4 if we count coroutine. (I don't count original implementations).
2. What is the reason of using Inum/Onum instead of Iteratee/Enumerator/Enumeratee. The latter seems to be a standard naming in the community?
Regards _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe