understanding enumerator/iteratee

So, it looks Iteratee takes a "step" on the resource -- whatever it is -- and Enumerator manages the resource and sequences the steps of the Iteratee. The Enumerator, then, defines our way of managing a particular resource -- how to take a step, how to close it, &c. -- while the Iteratee describes a computation that computes an output and also tells us when to free the resource. Is that a correct interpretation? I find the material on Enumerator and Iterator to be vague (or at least not very concrete). I have seen code for a random access Iteratee/Enumerator pair, as well. In that case, the role of the Iteratee is to provide the "next step" to take -- one of forward <n>, backward <n>, close? -- _jsn

Hi Jason,
2008/12/20 Jason Dusek
So, it looks Iteratee takes a "step" on the resource -- whatever it is -- and Enumerator manages the resource and sequences the steps of the Iteratee. The Enumerator, then, defines our way of managing a particular resource -- how to take a step, how to close it, &c. -- while the Iteratee describes a computation that computes an output and also tells us when to free the resource.
Yes, I believe you are correct.
Is that a correct interpretation? I find the material on Enumerator and Iterator to be vague (or at least not very concrete).
Have you read Oleg's DEFUN'08 talk notes? [1] Having read them more than once, I find them comprehensible. :) Cheers, Artyom Shalkhakov. [1] http://okmij.org/ftp/Haskell/Iteratee/DEFUN08-talk-notes.pdf

So an iteratee is not like a cursor because it does not "own" the collection -- it just tells us how to step it. The enumerator "owns" the collection and provides a way to scope resource use? -- Jason Dusek

Hi Jason!
2008/12/22 Jason Dusek
So an iteratee is not like a cursor because it does not "own" the collection -- it just tells us how to step it. The enumerator "owns" the collection and provides a way to scope resource use?
Iteratee does not know anything about resources, it doesn't need to. It is just a function which, given an input stream (which is either EOF, block of data or an IO error string), decides what to do, one of: * yield with some (useful) results (and with the rest of the input) * request more input by returning a continuation The enumerator on the other hand, decides when to open the resource (a file, for example), when to close it, and how to "step" through it. Iteratee only gets the fruits of this hard work. :)
it just tells us how to step it
I would say that it just tells us how to react to various forms of input. :) This is much like the function you pass to foldr. I hope this clarifies iteratees a bit (and that my understanding is correct). Cheers, Artyom Shalkhakov.

I'm taking a stab at composable streams, starting with cursors. I managed to make a derived cursor today -- as I work through this stuff, I hope to understand Iteratee/Enumerator better. -- Jason Dusek http://github.com/jsnx/streams/tree/554dd69339f027f113a6cfa16f552727ba9d92b3...

Jason Dusek schrieb:
I'm taking a stab at composable streams, starting with cursors. I managed to make a derived cursor today -- as I work through this stuff, I hope to understand Iteratee/Enumerator better.
How about a wiki page on the roles of enumerators and iteratees, best explained using a simple example?

Henning Thielemann
Jason Dusek schrieb:
I'm taking a stab at composable streams, starting with cursors. I managed to make a derived cursor today -- as I work through this stuff, I hope to understand Iteratee/Enumerator better.
How about a wiki page on the roles of enumerators and iteratees, best explained using a simple example?
At present, I am not totally convinced of Iteratee/Enumerator. Why aren't there any functor instances anywhere? Why do filestreams and lists present distinct interfaces? A stream computation is a stream computation; the effect of pulling an item off the stream and handling it is sequenced in these computations so it seems like a monad transformer is in order. So I am just going to keep trying until I can make that transformer. -- Jason Dusek

Jason Dusek schrieb:
Henning Thielemann
wrote: Jason Dusek schrieb:
I'm taking a stab at composable streams, starting with cursors. I managed to make a derived cursor today -- as I work through this stuff, I hope to understand Iteratee/Enumerator better. How about a wiki page on the roles of enumerators and iteratees, best explained using a simple example?
At present, I am not totally convinced of Iteratee/Enumerator. Why aren't there any functor instances anywhere? Why do filestreams and lists present distinct interfaces? A stream computation is a stream computation; the effect of pulling an item off the stream and handling it is sequenced in these computations so it seems like a monad transformer is in order. So I am just going to keep trying until I can make that transformer.
I have put essentially Oleg's explanation to the Wiki: http://haskell.org/haskellwiki/Enumerator_and_iteratee

Henning Thielemann
I have put essentially Oleg's explanation to the Wiki: http://haskell.org/haskellwiki/Enumerator_and_iteratee
The examples given are not really illustrative of how we approach parsing with failure or I/O with media failure using the Iteratee/Enumerator approach. The notion that we just "fold" over the (potentially side-effecting) data structure is probably misleading unless you already understand the design. -- Jason Dusek
participants (3)
-
Artyom Shalkhakov
-
Henning Thielemann
-
Jason Dusek