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, <dm-list-haskell-cafe@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.

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