<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi,</div><div><br></div><div>Thanks for this very interesting and inspiring paper. I'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'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) ugliness 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>On Feb 19, 2009, at 4:21 AM, Conal Elliott wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I have a draft paper some of you might enjoy, called "Denotational design with type class morphisms".<br><br>Abstract:<br><br> Type classes provide a mechanism for varied implementations of standard<br> interfaces. Many of these interfaces are founded in mathematical<br> tradition and so have regularity not only of *types* but also of<br> *properties* (laws) that must hold. Types and properties give strong<br> guidance to the library implementor, while leaving freedom as well. Some<br> of the remaining freedom is in *how* the implementation works, and some<br> is in *what* it accomplishes.<br><br> To give additional guidance to the *what*, without impinging on the<br> *how*, this paper proposes a principle of *type class morphisms* (TCMs),<br> which further refines the compositional style of denotational<br> semantics. The TCM idea is simply that *the instance's meaning is the<br> meaning's instance*. This principle determines the meaning of each type<br> class instance, and hence defines correctness of implementation. In some<br> cases, it also provides a systematic guide to implementation, and in<br> some cases, valuable design feedback.<br><br> The paper is illustrated with several examples of type, meanings, and<br> morphisms.<br><br>You'll find the paper at <a href="http://conal.net/papers/type-class-morphisms/">http://conal.net/papers/type-class-morphisms/</a> . <br><br>I'd sure appreciate feedback on it, especially if in time for the *March 2* ICFP deadline. Pointers to related work would be particularly appreciated, as well as what's unclear and what could be cut. This draft is an entire page over the limit, so I'll have to do some trimming before submitting.<br> <br>Enjoy, and thanks!<br><br> - Conal<br> _______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>http://www.haskell.org/mailman/listinfo/haskell-cafe<br></blockquote></div><br><div apple-content-edited="true"> <div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Sjoerd Visscher</div><div><a href="mailto:sjoerd@w3future.com">sjoerd@w3future.com</a></div><div><br></div></div><br class="Apple-interchange-newline"> </div><br></body></html>