By the way, what is the advantage of using iteratees here? For my testing, I just used: main = printit . freqs . B.words =<< B.readFile "words" (where 'printit' writes some data to stdout just to make sure stuff is evaluated, and you've already seen some 'freqs' examples) I have a bunch of old code, parsers etc, which are based on the 'readFile' paradigm: type Str = Data.ByteString.Lazy.Char8.ByteString -- usually decodeFoo :: Str -> Foo encodeFoo :: Foo -> Str readFoo = decodeFoo . readFile writeFoo f = writeFile f . encodeFoo hReadFoo = decodeFoo . hRead : (etc) This works pretty well, as long as Foo is strict enough that you don't retain all or huge parts of input, and as long as you can process input in a forward, linear fashion. And, like my frequency count above, I can't really see how this can be made much simpler. I haven't used iteratees or enumartors in anger, but it appears to me that they are most useful when the input is unpredictable or needs to be controlled in some way - for instance, when recv() can return a blocks of data that may be too little or too much. Would there be any great advantage to rewriting my stuff to use iterators? Or at least, use iterators for new stuff? As I see it, iterators are complex and the dust is only starting to settle on implementations and interfaces, and will introduce more dependencies. So my instinct is to stick with the worse-is-better approach, but I'm willing to be educated. -k -- If I haven't seen further, it is by standing in the footprints of giants