<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 11-03-26 04:33 PM, John A. De Goes wrote:
    <blockquote
      cite="mid:F214DD66-3156-4C20-BD64-62D69E14A9CE@n-brain.net"
      type="cite">
      <div><br>
      </div>
      <div>I noticed this problem some time ago. Beyond just breaking
        monadic associativity, there are many other issues with standard
        definitions of iteratees:</div>
      <div><br>
      </div>
      <blockquote class="webkit-indent-blockquote" style="margin: 0pt
        0pt 0pt 40px; border: medium none; padding: 0px;">
        <div>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;</div>
        <div><br>
        </div>
        <div>2. Error recovery is ill-defined because errors do not
          describe what portion of the input they have already consumed;</div>
        <div><br>
        </div>
        <div>3. Iteratees sometimes need to manage resources, but
          they're not designed to do so which leads to hideous
          workarounds;</div>
        <div><br>
        </div>
        <div>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.</div>
      </blockquote>
      <div><br>
      </div>
      <div>Overall, I regard iteratees as only a partial success.
        They're leaky and somewhat unsafe abstractions.</div>
    </blockquote>
    <br>
        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.<br>
    <br>
    <br>
    <blockquote
      cite="mid:F214DD66-3156-4C20-BD64-62D69E14A9CE@n-brain.net"
      type="cite">
      <div>I'm experimenting with Mealy machines because I think they
        have more long-term promise to solve the problems of iteratees.</div>
    </blockquote>
    <br>
        Do you mean a sort of a transducer monad transformer or an
    actual finite state machine? The latter would seem rather
    restrictive.<br>
    <br>
  </body>
</html>