Re: [Haskell-cafe] understanding enumerator/iteratee

[Artyom Shalkhakov]

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] 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] understanding enumerator/iteratee

[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?

--
Jason Dusek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] understanding enumerator/iteratee

[Artyom Shalkhakov]

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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] understanding enumerator/iteratee

[Jason Dusek]

  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/Control/Stream/OneWay.hs
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] understanding enumerator/iteratee

[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?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] understanding enumerator/iteratee

[Jason Dusek]

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.

--
Jason Dusek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] understanding enumerator/iteratee

[Henning Thielemann]

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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] understanding enumerator/iteratee

[Jason Dusek]

Henning Thielemann  wrote:
> 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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe