From: dm-list-haskell-cafe@scs.stanford.edu
At Fri, 6 May 2011 10:10:26 -0300,
Felipe Almeida Lessa wrote:
> So, in the enumerator vs. iterIO challenge, the only big differences I see are:
>
> a) iterIO has a different exception handling mechanism.
> b) iterIO can have pure iteratees that don't touch the monad.
> c) iterIO's iteratees can send control messages to ther enumerators.
> d) iterIO's enumerators are enumeratees, but enumerator's enumerators
> are simpler.
> e) enumerator has fewer dependencies.
> f) enumerator uses conventional nomenclature.
> g) enumerator is Haskell 98, while iterIO needs many extensions (e.g.
> MPTC and functional dependencies).
>
> Anything that I missed?
>
> The bottomline: the biggest advantage I see right now in favor of
> iterIO is c),
I basically agree with this list, but think you are underestimating
the value of a. I would rank a as the most important difference
between the packages. (a also is the reason for d.)
'a' is important, but I think a lot of people underestimate the value of 'c', which is why a control system was implemented in 'iteratee'. I would argue that iteratee's control system is more powerful than you say. For example, the only reason iteratee can't implement tell is because it doesn't keep track of the position in the stream, it's relatively simple for an enumerator to return data to an iteratee using an IORef for example. And adding support to keep track of the stream position would be a pretty simple (and possibly desirable) change. But it's definitely not as sophisticated as IterIO, and probably won't become so unless I have need of those features.
I like the MonadTrans implementation a lot. The vast majority of iteratees are pure, and GHC typically produces more efficient code for pure functions, so this is possibly a performance win. Although it makes something like the mutable-iter package very difficult to implement...
John Lato