[Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators

[Alex Mason]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe