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.

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

Regards,

John A. De Goes

Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes

On Mar 26, 2011, at 1:03 PM, John Millikin wrote:

On Mar 26, 10:46 am, Michael Snoyman <mich...@snoyman.com> wrote:
As far as the left-over data in a yield issue: does that require a
breaking API change, or a change to the definition of >>= which would
change semantics??

It requires a pretty serious API change, as the definition of
'Iteratee' itself is at fault. Unfortunately, Oleg's new definitions
also have problems (they can yield extra on a continue step), so I'm
at a bit of a loss as to what to do. Either way, underlying primitives
allow users to create iteratees with invalid/undefined behavior. Not
very Haskell-y.

All of the new high-level functions added in recent versions are part
of an attempted workaround. I'd like to move the Iteratee definitions
themselves to a ``Data.Enumerator.Internal`` module, and add some
words discouraging their direct use. There would still be some API
breaks (the >>== , $$, and >==> operators would go away) but at least
clients wouldn't be subjected to a complete rewrite.

Since the API is being broken anyway, I'm also going to take the
opportunity to change the Stream type so it can represent "EOF + some
data". That should allow lots of interesting behaviors, such as
arbitrary lookahead.

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