Question

First, I understand the how of iteratees, well enough that I could probably write a simplistic and buggy implementation without referring back to any existing ones.

What I’d really like to know is why people seem to find them so fascinating, or under what circumstances their benefits justify their complexity. Comparing them to lazy I/O there is a very clear benefit, but that seems an awful lot like a straw man to me. I never felt comfortable about lazy I/O in the first place, and I avoid it except for the occasional hGetContents or readFile, mostly in very simple programs.

In real-world scenarios I generally use traditional I/O interfaces with control abstractions appropriate to the task. In that context I just don’t see the benefit of iteratees, or to what task they are an appropriate control abstraction. Most of the time they seem more like unnecessary complexity or even a counterproductive inversion of control.

I’ve read a fair number of articles about them and sources that make use of them, but have not yet found a compelling example that actually made me think anything along the lines of “oh, yea, I’d have used them there too.” Maybe I just haven’t read the right ones. Or perhaps there is a yet-to-be-devised interface, simpler than any I’ve yet seen, that would make them feel less like a Swiss Army Chainsaw.

Am I just suffering from not-invented-here syndrome or is my unease well-founded? Or is it perhaps something else entirely?

Answer 1

As to why people find them so fascinating, I think because they’re such a simple idea. The recent discussion on Haskell-cafe about a denotational semantics for iteratees devolved into a consensus that they’re so simple they’re barely worth describing. The phrase “little more than a glorified left-fold with a pause button” sticks out to me from that thread. People who like Haskell tend to be fond of simple, elegant structures, so the iteratee idea is likely very appealing.

For me, the chief benefits of iteratees are

1. Composability. Not only can iteratees be composed, but enumerators can too. This is very powerful.
2. Safe resource usage. Resources (memory and handles mostly) cannot escape their local scope. Compare to strict I/O, where it’s easier to create space leaks by not cleaning up.
3. Efficient. Iteratees can be highly efficient; competitive with or better than both lazy I/O and strict I/O.

I have found that iteratees provide the greatest benefits when working with single logical data that comes from multiple sources. This is when the composability is most helpful, and resource management with strict I/O most annoying (e.g. nested allocas or brackets).

For an example, in a work-in-progress audio editor, a single logical chunk of sound data is a set of offsets into multiple audio files. I can process that single chunk of sound by doing something like this (from memory, but I think this is right):

enumSound :: MonadIO m => Sound -> Enumerator s m a
enumSound snd = foldr (>=>) enumEof . map enumFile $ sndFiles snd

This seems clear, concise, and elegant to me, much more so than the equivalent strict I/O. Iteratees are also powerful enough to incorporate any processing I want to do, including writing output, so I find this very nice. If I used lazy I/O I could get something as elegant, but the extra care to make sure resources are consumed and GC’d would outweigh the advantages IMO.

I also like that you need to explicitly retain data in iteratees, which avoids the notorious mean xs = sum xs / length xs space leak.

Of course, I don’t use iteratees for everything. As an alternative I really like the with* idiom, but when you have multiple resources that need to be nested that gets complex very quickly.