[Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators

[John Lato]

>
> From: dm-list-haskell-cafe at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110509/8e4ec10a/attachment.htm>