May be I am reading it wrong....&nbsp; Shouldn&#39;t&nbsp; the second &quot;instance&quot; in &quot;The instance&#39;s meaning is the meaning&#39;s instance&quot;&nbsp; be plural as &quot;meaning&#39;s instances&quot; rather than &quot;meaning&#39;s instance&quot;?<br>
<br>I am reading it similar to the&nbsp; &quot;you are who you know&quot; saying.&nbsp;&nbsp; It seems to say that the meaning of your data types (&quot;The instance&#39;s meaning&quot;)&nbsp; is defined by the instances of known classes (with predefined meaning, defined by it properties, as in functor, monoid..) that is defined for your type.&nbsp;&nbsp; <br>
<br><br>Daryoush<br><br><div class="gmail_quote">2009/2/19 Sjoerd Visscher <span dir="ltr">&lt;<a href="mailto:sjoerd@w3future.com">sjoerd@w3future.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div>Hi,</div><div><br></div><div>Thanks for this very interesting and inspiring paper. I&#39;m certainly going to try some other data types, and see what kind of implementations you get when using the TCM property.</div>
<div><br></div><div>I was wondering if any of this could be automated, given the semantic function? If not in Haskell, then could this be a nice basis for a new language?</div><div><br></div><div>If something still needs to be cut, I&#39;d consider much or even all of chapter 8. I found the tone and style unfitting for the rest of the paper, as it deals with the (imho)&nbsp;ugliness&nbsp;of bottom and strictness issues, instead of the beautiful relations found in the rest of the paper.</div>
<div><br></div><div>greetings,</div><div>Sjoerd Visscher</div><br><div><div><div></div><div class="Wj3C7c"><div>On Feb 19, 2009, at 4:21 AM, Conal Elliott wrote:</div><br></div></div><blockquote type="cite"><div><div></div>
<div class="Wj3C7c">I have a draft paper some of you might enjoy, called &quot;Denotational design with type class morphisms&quot;.<br><br>Abstract:<br><br>&nbsp;&nbsp;&nbsp; Type classes provide a mechanism for varied implementations of standard<br>
&nbsp;&nbsp;&nbsp; interfaces. Many of these interfaces are founded in mathematical<br> &nbsp;&nbsp;&nbsp; tradition and so have regularity not only of *types* but also of<br>&nbsp;&nbsp;&nbsp; *properties* (laws) that must hold. Types and properties give strong<br>
&nbsp;&nbsp;&nbsp; guidance to the library implementor, while leaving freedom as well. Some<br> &nbsp;&nbsp;&nbsp; of the remaining freedom is in *how* the implementation works, and some<br>&nbsp;&nbsp;&nbsp; is in *what* it accomplishes.<br><br>&nbsp;&nbsp;&nbsp; To give additional guidance to the *what*, without impinging on the<br>
&nbsp;&nbsp;&nbsp; *how*, this paper proposes a principle of *type class morphisms* (TCMs),<br> &nbsp;&nbsp;&nbsp; which further refines the compositional style of denotational<br>&nbsp;&nbsp;&nbsp; semantics. The TCM idea is simply that *the instance&#39;s meaning is the<br>
&nbsp;&nbsp;&nbsp; meaning&#39;s instance*. This principle determines the meaning of each type<br> &nbsp;&nbsp;&nbsp; class instance, and hence defines correctness of implementation. In some<br>&nbsp;&nbsp;&nbsp; cases, it also provides a systematic guide to implementation, and in<br>
&nbsp;&nbsp;&nbsp; some cases, valuable design feedback.<br><br>&nbsp;&nbsp;&nbsp; The paper is illustrated with several examples of type, meanings, and<br> &nbsp;&nbsp;&nbsp; morphisms.<br><br>You&#39;ll find the paper at <a href="http://conal.net/papers/type-class-morphisms/" target="_blank">http://conal.net/papers/type-class-morphisms/</a> .&nbsp; <br>
<br>I&#39;d sure appreciate feedback on it, especially if in time for the *March 2* ICFP deadline.&nbsp; Pointers to related work would be particularly appreciated, as well as what&#39;s unclear and what could be cut.&nbsp; This draft is an entire page over the limit, so I&#39;ll have to do some trimming before submitting.<br>
 <br>Enjoy, and thanks!<br><br>&nbsp;&nbsp; - Conal<br></div></div> _______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org" target="_blank">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></blockquote></div><font color="#888888"><br><div> <div style=""><div>--</div><div>
Sjoerd Visscher</div><div><a href="mailto:sjoerd@w3future.com" target="_blank">sjoerd@w3future.com</a></div><div><br></div></div><br> </div><br></font></div><br>_______________________________________________<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>
<br></blockquote></div><br><br>