[Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[Mario Blažević]

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...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110326/729e72b3/attachment.htm>