I'm not a semanticist, so I apologize right now if I say something stupid or incorrect.<br><br><div class="gmail_quote">On Mon, Aug 23, 2010 at 9:57 PM, Conal Elliott <span dir="ltr"><<a href="mailto:conal@conal.net">conal@conal.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex" class="gmail_quote">
So perhaps this could be a reasonable semantics?<br><br>Iteratee a = [Char] -> Maybe (a, [Char])<br>
</blockquote><br></div>I've been tinkering with this model as well.<br><br>However, it doesn't really correspond to the iteratee interfaces I've seen, since those interfaces allow an iteratee to notice size and number of chunks. I suspect this ability is an accidental abstraction leak, which raises the question of how to patch the leak.<br>
</blockquote><div><br></div><div>From a purely practical viewpoint I feel that treating the chunking as an abstraction leak might be missing the point. If you said, you wanted the semantics to acknowledge the chunking but be invariant under the size or number of the chunks then I would be happier.</div>
<div><br></div><div>I use iteratees when I need to be explicit about chunking and when I don't want the resources to "leak outside" of the stream processing. If you took those properties away, I wouldn't want to use it anymore because then it would just be an inelegant way to do things.</div>
<div><br></div><div>I won't comment further in this email because I think I lack the formal training to follow the rest of your discussion. And that is unfortunate for me.</div><div><br></div><div>Thanks,</div><div>Jason</div>
</div>