[Haskell-cafe] ANNOUNCE: enumerator 0.4.8
blamario at acanac.net
Sat Mar 26 23:24:24 CET 2011
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe