[Haskell-cafe] ANNOUNCE: enumerator 0.4.8
John A. De Goes
john at n-brain.net
Sat Mar 26 21:33:09 CET 2011
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.
John A. De Goes
On Mar 26, 2011, at 1:03 PM, John Millikin wrote:
> On Mar 26, 10:46 am, Michael Snoyman <mich... at 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe