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

[Mario Blažević]

On 11-05-06 11:15 AM, Alex Mason wrote:
> 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.

     The Producer/Consumer terminology, if I'm not mistaken, is usually 
applied to coroutine pairs. I use these terms myself in the SCC package, 
together with terms Transducer and Splitter. The former term is also 
well established, the latter was my own.

     Though I like and use this terminology, I'm not sure it's a good 
fit for the existing Enumerator/Iteratee pairs, which are not real 
symmetric coroutines. Enumerators are more like the Python (<2.5) 
Generators. I don't know what the Python terminology would be for the 
Iteratee.


On 11-05-06 12:47 PM, dm-list-haskell-cafe at scs.stanford.edu wrote:
> This is a question I struggled a lot with.  I definitely agree that
> the terms are pretty intimidating to new users.
>
> At least one thing I've concluded is that it really should be
> presented as two concepts, rather than three.  So we should talk
> about, e.g., producers, consumers, and pipeline stages that do both.
>
> I'd been thinking about using the terms Source and Sink, but Source is
> very overloaded, and "SinkSource" doesn't exactly roll off the tongue
> or evoke a particularly helpful intuition.

     The SCC package happens to use Source and Sink names as well. They 
are used not for coroutines directly, but instead for references to 
coroutines of the appropriate type. Every consumer thus owns a Source 
from which it fetches its input, and that Source is always bound to 
another coroutine that yields those values through a Sink. Source and 
Sink are a passive handle to a Producer and Consumer. I may be 
subjective, but I find this use of the terms very fitting.