<blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">So perhaps this could be a reasonable semantics?<br><br>Iteratee a = [Char] -&gt; Maybe (a, [Char])<br>

</blockquote><br>I&#39;ve been tinkering with this model as well.<br><br>However, it doesn&#39;t really correspond to the iteratee interfaces I&#39;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.<br>

<br>What about enumerators? The definition given in Oleg&#39;s presentation (<a href="http://okmij.org/ftp/Streams.html#iteratee">http://okmij.org/ftp/Streams.html#iteratee</a>, slide 21) is<br><br>&gt; type Enumerator a = Iteratee a -&gt; Iteratee a<br>

<br>Since we have a semantics for Iteratee, we could take this Enumerator definition as is, and we&#39;d have a semantics, i.e.,<br><br>&gt; [[Enumerator a]] = [[Iteratee a]] -&gt; [[Iteratee a]]<br><br>I don&#39;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,<br>

<br>* there might be a simpler and more natural semantic model; and<br>* the representation may be junky, i.e., having many representations that we wouldn&#39;t want to be denotable.<br><br>Is there a simpler model of Enumerator? My intuition is that it&#39;s simply a stream:<br>

<br>&gt; [[Enumerator a]] = String<br><br>Oddly, &#39;a&#39; doesn&#39;t show up on the RHS.  Maybe the representation ought to be<br><br>&gt; type Enumerator = forall a. Iteratee a -&gt; Iteratee a<br><br>so<br><br>&gt; [[Enumerator]] = String<br>

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

<br>Again, there&#39;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?<br><br>Comments?<br><br>  - Conal<br><br>

<div class="gmail_quote">On Mon, Aug 23, 2010 at 8:13 PM, Luke Palmer <span dir="ltr">&lt;<a href="mailto:lrpalmer@gmail.com">lrpalmer@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Mon, Aug 23, 2010 at 1:06 AM, Heinrich Apfelmus<br>
&lt;<a href="mailto:apfelmus@quantentunnel.de">apfelmus@quantentunnel.de</a>&gt; wrote:<br>
&gt; Conal Elliott wrote:<br>
&gt;&gt;<br>
&gt;&gt; For anyone interested in iteratees (etc) and not yet on the iteratees<br>
&gt;&gt; mailing list.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m asking about what iteratees *mean* (denote), independent of the<br>
&gt;&gt; various<br>
&gt;&gt; implementations.  My original note (also at the end below):<br>
&gt;<br>
&gt; In my world view, iteratees are just a monad M with a single operation<br>
&gt;<br>
&gt;    symbol :: M Char<br>
&gt;<br>
&gt; that reads the next symbol from an input stream.<br>
<br>
</div>So perhaps this could be a reasonable semantics?<br>
<br>
Iteratee a = [Char] -&gt; Maybe (a, [Char])<br>
           = MaybeT (State [Char]) a<br>
<br>
symbol [] = Nothing<br>
symbol (c:cs) = Just (c, cs)<br>
<br>
I&#39;m not experienced with iteratees. Does this miss something?<br>
<font color="#888888"><br>
Luke<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>