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.

What about enumerators? The definition given in Oleg's presentation (http://okmij.org/ftp/Streams.html#iteratee, slide 21) is

> type Enumerator a = Iteratee a -> Iteratee a

Since we have a semantics for Iteratee, we could take this Enumerator definition as is, and we'd have a semantics, i.e.,

> [[Enumerator a]] = [[Iteratee a]] -> [[Iteratee a]]

I don't trust this choice, however.  It could be that, like the Iteratee representation, the Enumerator representation (as a function) is more an *implementation* than a semantics.  That is, like Iteratee,

* there might be a simpler and more natural semantic model; and
* the representation may be junky, i.e., having many representations that we wouldn't want to be denotable.

Is there a simpler model of Enumerator? My intuition is that it's simply a stream:

> [[Enumerator a]] = String

Oddly, 'a' doesn't show up on the RHS.  Maybe the representation ought to be

> type Enumerator = forall a. Iteratee a -> Iteratee a

so

> [[Enumerator]] = String

Are there any enumerator definitions that couldn't use this more restrictive representation type?  Glancing through the slides, the only Enumerator types I see are indeed polymorphic over a (the iteratee's result type.)

Again, there's a terrible abstraction leak here, i.e., many ways to write down enumerators that type-check but are not meaningful within the model.  Can this leak be fixed?

Comments?

  - Conal

On Mon, Aug 23, 2010 at 8:13 PM, Luke Palmer <lrpalmer@gmail.com> wrote:
On Mon, Aug 23, 2010 at 1:06 AM, Heinrich Apfelmus
<apfelmus@quantentunnel.de> wrote:
> Conal Elliott wrote:
>>
>> For anyone interested in iteratees (etc) and not yet on the iteratees
>> mailing list.
>>
>> I'm asking about what iteratees *mean* (denote), independent of the
>> various
>> implementations.  My original note (also at the end below):
>
> In my world view, iteratees are just a monad M with a single operation
>
>    symbol :: M Char
>
> that reads the next symbol from an input stream.

So perhaps this could be a reasonable semantics?

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

symbol [] = Nothing
symbol (c:cs) = Just (c, cs)

I'm not experienced with iteratees. Does this miss something?

Luke
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe