On 5/6/11 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 believe "transducer" is the proper term. (Of course, producers and consumers are both special cases of transducers, trivializing the input or output stream, respectively.) Though, IMO, I don't find the names "producer" and "consumer" enlightening as to why this particular pattern of iteration/enumeration is different from the conventional pattern found in OOP's iterators. Any time you have a bunch of things being created and passed around you have producers and consumers; the terminology is insufficient to define the pattern. The shift from "iterator" to "enumerator" helps to capture that difference. Given as there's no common name for the code calling an iterator, it's not immediately apparent what the push-based enumerative version should be called; "iteratee" seems as good as any other name, because it expresses the duality involved in the switch from the iterative style. control : pull, push producer : iterator, enumerator consumer : ???, iteratee Of course, this pattern of names suggests that "enumeratee" should properly be a backformation for naming the consumer of the pull-based iterative pattern. But then we're still left with the problem of what the transducers should be called in both cases. -- Live well, ~wren