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