On 11-03-26 04:33 PM, John A. De Goes wrote:

I noticed this problem some time ago. Beyond just breaking monadic associativity, there are many other issues with standard definitions of iteratees:

1. It does not make sense in general to bind with an iteratee that has already consumed input, but there's no type-level difference between a "virgin" iteratee and one that has already consumed input;

2. Error recovery is ill-defined because errors do not describe what portion of the input they have already consumed;

3. Iteratees sometimes need to manage resources, but they're not designed to do so which leads to hideous workarounds;

4. Iteratees cannot incrementally produce output, it's all or nothing, which makes them terrible for many real world problems that require both incremental input and incremental output.

Overall, I regard iteratees as only a partial success. They're leaky and somewhat unsafe abstractions.

Out of curiosity, have you looked at the monad-coroutine library? It's a more generic and IMO much cleaner model, though I wouldn't recommend it as a replacement because the enumerator and iteratee libraries come with more predefined plumbing. I think your point #1 still stands, but others can all be made to disappear - as long as you define your suspension functors properly.

I'm experimenting with Mealy machines because I think they have more long-term promise to solve the problems of iteratees.

Do you mean a sort of a transducer monad transformer or an actual finite state machine? The latter would seem rather restrictive.