I agree that the issues you mention with iteratee do all need to be dealt with. Reading strings (as you tried to do) is probably the most important. I don’t have a great solution yet, but I’m working on it. Thanks for the other issues as well. Solutions are planned for all of them, just a case of limited developer time.

Yes, I had a look at the Examples directory and found both the files you mention. I’ve so far only taken a look at headers.hs. Now I find it rather a lot easier to see what is going on and I realise that what I had problems with was actually more related to Char and streams. What I tried to do was to call readLines in a fileDriver and expected to get a list of all lines. That failed miserably, and all I got was Left []. After writing this post, and reading headers.hs again I realised I needed to map chr . fromIntegral over the stream first. That got me to at least get some output, though I was still surprised (see below).

The main issue I’d try to address is simple examples along the lines of reading and printing (to the screen) a file, line by line and char by char.

I haven’t studied the API extensively (yet) but I’ve already found a few things that surprised me, I’d address those as the second issue. What I’m thinking of is readLines, which for some reason terminates on an empty line and breaks on EOF. The same goes for enumLines. They both seem to be geared to usage for parsing HTTP, but their general-sounding names don’t give that away.

The third issue as I see it is that there are users of the library mixed in with the library itself. Here I’m thinking of Data.Iteratee.Codecs.*. They are nice to have, but I’d argue they deserve their own little package.

Did you look at the “Examples” directory of the iteratee package? You’ll need to download the tarball and unpack it, but those examples are relatively simple. wave_reader.hs is the shortest, but headers.hs is probably more familiar to most programmers. If you did look at these and they weren’t helpful, I would appreciate knowing about it so I can improve them for the next release. Or if you could tell me where you got stuck at the beginning, maybe I can address that.

As you’ve likely figured out, there’s actually a lot that can be done without including monads in the iteratee type. If you have an enumerator defined as

type EnumeratorM m c e a = Iteratee c e a -> m (Iteratee c e a)

you can do input. The IterateeG type in the iteratee package is actually a monad transformer, which allows for some very interesting applications. I’ve considered changing the iteratee package to provide pure iteratees as well as the monadic variety, but I don’t know that they would find much use. You need the monad to stream output, for example.

wren, I think the biggest thing about iteratees is that not many people understand them. I/O in Haskell isn’t quite right yet, and I think most programmers are aware of this either intuitively or explicitly. So they think enumerator I/O could be the Holy Grail that will solve all their problems. The Oleg label adds to the mystique. There are advantages to enumerator I/O, but there are also drawbacks that anyone who tries to use them will surely discover sooner or later. Anyway, iteratees do offer some good features. They’re composable, have predictable memory usage, and allow short-cut evaluation of streams. They also fully encapsulate the handle so it cannot leak and is GC’d when the iteratee finishes processing, either naturally or on exceptions. Finally they can be very efficient; my iter-audio package (not on hackage yet, but public darcs repo) is the fastest Haskell wave library I know of. It’s faster than the hsndfile binding to libsndfile, which is the only real competitor performance-wise.

Also, I don’t know what you mean about an “official release” either. Don released “liboleg”, which is basically a cabal-ization of Oleg’s releases, and the “iteratee” package is released too. If you know of any bugs/problems with “iteratee”, please report them to the maintainer, because right now the trac instance is empty

I do have a limited implementation of iteratee-based IO (only ‘I’ really), which is derived from what I have in this post. I’m not sure it’s worth posting though.