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 think that's a great idea. 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.
One good thing I can say for the Enumerator/Iteratee nomenclature is that it
nicely connotes the inversion of control (i.e., the "push" data flow) that
enumerator is all about. Enumera*tor** *feeds Itera*tee* -- subject, verb,
object. Producer/Consumer connotes the same by allusion to the
producer-consumer pattern of thread synchronization.
Tom
On Fri, May 6, 2011 at 9:47 AM,
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.
In the end, I decided just to come up with new terms that wouldn't carry any pre-conceptions (e.g., what's an "Inum"?), and then build the intuition through copious documentation...
I'm open to suggestion here. I've already overhauled the naming conventions in the library once. Initially I used the names EnumI and EnumO for Inum and Onum. I think the old names were much worse, especially since Enum is a fundamental typeclass that has absolutely nothing to do with enumerators.
David
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe