For anyone interested in iteratees (etc) and not yet on the iteratees mailing list.<br><br>I&#39;m asking about what iteratees *mean* (denote), independent of the various implementations.  My original note (also at the end below):<br>

<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">With the encouragement &amp; help of Conrad Parker, I&#39;ve been looking at
 iteratees, enumerators, enumeratees.  I can find plenty written about 
them, but only about benefits and implementation.  In sifting through 
chunks, error/control messages, and continuations, I find myself longing
 for a precise semantic basis.  I keep wondering: what simpler &amp; 
precise semantic notions do these mechanisms implement?  Has anyone 
worked out a denotational semantics for iteratees, enumerators, 
enumeratees -- something that simplifies away the performance advantages
 &amp; complexities?  I&#39;ve worked out something tentative, but perhaps 
I&#39;m covering old ground.<br></blockquote><div><br>     - Conal <br></div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Conal Elliott</b> <span dir="ltr">&lt;<a href="mailto:conal@conal.net">conal@conal.net</a>&gt;</span><br>

Date: Sun, Aug 22, 2010 at 11:02 PM<br>Subject: Re: Semantics of iteratees, enumerators, enumeratees?<br>To: John Lato &lt;<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>&gt;<br><br><br>Hi John,<br><br>I just remembered: Luke Palmer wrote an accessible &amp; helpful description of this approach to library design.  See his post <i><a href="http://lukepalmer.wordpress.com/2008/07/18/semantic-design/" target="_blank">Semantic Design</a></i>.<br>



<br>
(I&#39;ve switched to using the more specific term &quot;denotational design&quot;, 
since I specifically intend denotational semantics, not operational.)<br><br>Denotational design is at the heart of most of what I do, particularly including the three pieces of work you mentioned: functional images (Pan), FRP, and automatic differentiation.<br>


<br>My main goal is simplicity with precision.  Without the precision, I can&#39;t tell whether the simplicity is real or illusory.<br><br>We functional programmers have a strong advantage over imperative programming (including OO) in that we can achieve semantic precision.  I want to see us exploit this advantage!  And not settle for being a power tool for generating semantically inscrutable imperative computations.<br>


<br>Regards,<br><font color="#888888">
<br>
  - Conal</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Sun, Aug 22, 2010 at 10:43 PM, John Lato <span dir="ltr">&lt;<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@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;">
Hi Conal,<br><br>I&#39;ve always regarded your work in essentially the same category as Edward Kmett&#39;s (and most of Oleg&#39;s): stuff that&#39;s incredible powerful and concise, but I can&#39;t understand at all what it means.  I&#39;ve admired a lot of your work, particularly on Pan, FRP, and automatic differentiation, but most of the rest I couldn&#39;t understand at all.<br>



<br>I&#39;ll take a look at your <i>Denotational Design</i> paper again; maybe now that I have a lot more experience I&#39;ll be able to make sense of it.<br><font color="#888888"><br>John</font><div><div></div><div>
<br><br><div class="gmail_quote">On Sun, Aug 22, 2010 at 8:18 AM, Conal Elliott <span dir="ltr">&lt;<a href="mailto:conal@conal.net" target="_blank">conal@conal.net</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;">Hi John,<br><br>Thanks for the reply.  A denotational semantics would be independent of any implementation, so it would apply to any of them, as long as they have the same programming interface.  The purpose is to simply &amp; precisely say what the types and their building blocks (API) mean by providing a precise, implementation-independent, and simple-as-possible math model.  Such a semantics can be used to prove properties and to define correctness of any implementation.  It also gives clear feedback on how elegant or inelegant a library design is.<br>





<br>For instance, given a type, Map k v, of finite maps, we might say the meaning is the type of partial functions from k to v, either k -&gt; v (where absent is _|_) or k -&gt; Maybe v (where absent is Nothing).  Then we&#39;d give the meaning of each Map operation as a function of the meanings of its arguments.  This example and several others are given in the paper <i><a href="http://conal.net/papers/type-class-morphisms/" target="_blank">Denotational design with type class morphisms</a></i>.<br>





<br>Regards,  - Conal<br><br><div class="gmail_quote">On Sun, Aug 22, 2010 at 8:31 PM, John Lato <span dir="ltr">&lt;<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@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;">





Hi Conal,<br><br>To my knowledge, nobody has attempted this.  Oleg may have some ideas, but I don&#39;t think he&#39;s written about it.  I really don&#39;t know anything about denotational semantics, so I couldn&#39;t do this myself.  For some time I&#39;ve thought it would be good if somebody were able to put together a formal semantics for iteratees, so I&#39;d be very interested if you&#39;d share what you have so far.<br>






<br>Would a denotational semantics apply equally to multiple implementations, or would it be tied to a specific implementation?<br><br>John<br><br><div class="gmail_quote">On Sun, Aug 22, 2010 at 3:47 AM, Conal Elliott <span dir="ltr">&lt;<a href="mailto:conal@conal.net" target="_blank">conal@conal.net</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;">With the encouragement &amp; help of Conrad Parker, I&#39;ve been looking at iteratees, enumerators, enumeratees.  I can find plenty written about them, but only about benefits and implementation.  In sifting through chunks, error/control messages, and continuations, I find myself longing for a precise semantic basis.  I keep wondering: what simpler &amp; precise semantic notions do these mechanisms implement?  Has anyone worked out a denotational semantics for iteratees, enumerators, enumeratees -- something that simplifies away the performance advantages &amp; complexities?  I&#39;ve worked out something tentative, but perhaps I&#39;m covering old ground.<br>






<font color="#888888">

<br>   - Conal<br>
</font><br>_______________________________________________<br>
Iteratee mailing list<br>
<a href="mailto:Iteratee@projects.haskell.org" target="_blank">Iteratee@projects.haskell.org</a><br>
<a href="http://projects.haskell.org/cgi-bin/mailman/listinfo/iteratee" target="_blank">http://projects.haskell.org/cgi-bin/mailman/listinfo/iteratee</a><br>
<br></blockquote></div><br>
</blockquote></div><br>
</blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></div><br>