Re: [Haskell-cafe] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?

On 24 August 2010 14:14, Jason Dagit wrote:

I'm not a semanticist, so I apologize right now if I say something stupid or incorrect.

On Mon, Aug 23, 2010 at 9:57 PM, Conal Elliott wrote:

...

...

So perhaps this could be a reasonable semantics?

Iteratee a = [Char] -> Maybe (a, [Char])

I've been tinkering with this model as well.

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.

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.

I think that's the point, ie. to specify what the invariants should be. For example (to paraphrase, very poorly, something Conal wrote on the whiteboard behind me): run [concat [chunk]] == run [chunk] ie. the (a, [Char]) you maybe get from running an iteratee over any partitioning of chunks should be the same, ie. the same as from running it over the concatenation of all chunks, which is the whole input [Char].

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.

Then I suppose the model for Enumerators is different than that for Iteratees; part of the point of an Enumerator is to control the size of the chunks, so that needs to be part of the model. An Iteratee, on the other hand, should not have to know the size of its chunks. So you don't want to be able to know the length of a chunk (ie. a part of the stream), but you do want to be able to, say, fold over it, and to be able to stop the computation at any time (these being the main point of iteratees ...). Conrad.