<br><br><div class="gmail_quote">On Mon, Aug 23, 2010 at 10:37 PM, Conrad Parker <span dir="ltr"><<a href="mailto:conrad@metadecks.org">conrad@metadecks.org</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">On 24 August 2010 14:14, Jason Dagit <<a href="mailto:dagit@codersbase.com">dagit@codersbase.com</a>> wrote:<br>
> I'm not a semanticist, so I apologize right now if I say something stupid or<br>
> incorrect.<br>
><br>
> On Mon, Aug 23, 2010 at 9:57 PM, Conal Elliott <<a href="mailto:conal@conal.net">conal@conal.net</a>> wrote:<br>
>>><br>
>>> So perhaps this could be a reasonable semantics?<br>
>>><br>
>>> Iteratee a = [Char] -> Maybe (a, [Char])<br>
>><br>
>> I've been tinkering with this model as well.<br>
>><br>
>> However, it doesn't really correspond to the iteratee interfaces I've<br>
>> seen, since those interfaces allow an iteratee to notice size and number of<br>
>> chunks. I suspect this ability is an accidental abstraction leak, which<br>
>> raises the question of how to patch the leak.<br>
><br>
> From a purely practical viewpoint I feel that treating the chunking as an<br>
> abstraction leak might be missing the point. If you said, you wanted the<br>
> semantics to acknowledge the chunking but be invariant under the size or<br>
> number of the chunks then I would be happier.<br>
<br>
</div>I think that's the point, ie. to specify what the invariants should<br>
be. For example (to paraphrase, very poorly, something Conal wrote on<br>
the whiteboard behind me):<br>
<br>
run [concat [chunk]] == run [chunk]<br>
<br>
ie. the (a, [Char]) you maybe get from running an iteratee over any<br>
partitioning of chunks should be the same, ie. the same as from<br>
running it over the concatenation of all chunks, which is the whole<br>
input [Char].<br></blockquote><div><br></div><div>I find this notation foreign. I get [Char], that's the Haskell String type, but what is [chunk]? I doubt you mean a list of one element.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I use iteratees when I need to be explicit about chunking and when I don't<br>
> want the resources to "leak outside" of the stream processing. If you took<br>
> those properties away, I wouldn't want to use it anymore because then it<br>
> would just be an inelegant way to do things.<br>
<br>
</div>Then I suppose the model for Enumerators is different than that for<br>
Iteratees; part of the point of an Enumerator is to control the size<br>
of the chunks, so that needs to be part of the model. An Iteratee, on<br>
the other hand, should not have to know the size of its chunks. So you<br>
don't want to be able to know the length of a chunk (ie. a part of the<br>
stream), but you do want to be able to, say, fold over it, and to be<br>
able to stop the computation at any time (these being the main point<br>
of iteratees ...).<br></blockquote><div><br></div><div>I think I agree with that.</div><div><br></div><div>Jason</div></div>