This is a much cleaner definition of Iteratee and I'm happy to see it. When are you going to move from your FTP site to Github, by the way? :) Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Apr 21, 2011, at 12:32 AM, oleg@okmij.org wrote:

Daniel Schuessler wrote:

...

The thing I don't understand yet is the last line: Why is it OK to discard the leftover input from the (f x) Iteratee and yield just the leftover input from the first one (m0)?

First of all, the question is about an older version of Iteratee. For example, the following code http://okmij.org/ftp/Haskell/Iteratee/Iteratee.hs defines Iteratee a bit differently so the question does not apply.

...

data Iteratee a = IE_done a | IE_cont (Maybe ErrMsg) (Stream -> (Iteratee a,Stream))

instance Monad Iteratee where return = IE_done IE_done a >>= f = f a IE_cont e k >>= f = IE_cont e (docase . k) where docase (IE_done a, stream) = case f a of IE_cont Nothing k -> k stream i -> (i,stream) docase (i, s) = (i >>= f, s)

No left-over is discarded any more.

Your question is about the previous design, called `The second design' described in Iteratee.hs. The corresponding comment block answers your question, please search for ``Justification for the case IE_done x s >>= f''.

Please see http://okmij.org/ftp/Haskell/Iteratee/IterateeM.hs for the `production' case of Iteratee in a base monad. The file IterateeM.hs talks about one more design, and its drawbacks.

It's all about finding the optimal trade-off, I guess.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe