scalaz/scalaz — comment on commit 76f647ee8ebbb7cc0429447d027dcfb737f7247c
File: iteratee/src/main/scala/scalaz/iteratee/StepT.scala line 8
By jsuereth:

The error channel has no way to reconstitute the iteratee *after* handling
a control message. To have an effective "back and forth" between
Iteratee + Enumerator, you need your control messages to include: "Here, do
this, and then call *me* when done". Which means, all your combinators
need to be able to manipulate the "after a control message" iteratee.

This implies the *easiest* place to put it is with the "processing" state.
I had an implementation where this information was in the Error channel,
and it was just atrocious. That's why I split the error channel such that
control messages are send with the 'next' iteratee processing value. It
simplified the whole library and made it easier to reason/figure out how to
implement things.

Note: What to do with "zipped" Iteratees is also a fun situation. Should
your control messages be Monoids? In the end, I went with a simple,
probably poor in some scenario, assumption and decided each Iteratee in a
zipped Iteratee can contribute control message *sequentially*. In any
case, we should probably just chat about this on a better forum for design
discussions. Just thought I'd make note that the approach you're taking
now is the (much) more difficult one.

- Josh