<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: Denotational design with type class morphisms</title>
	<atom:link href="http://conal.net/blog/posts/denotational-design-with-type-class-morphisms/feed" rel="self" type="application/rss+xml" />
	<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms</link>
	<description>Inspirations &#38; experiments, mainly about denotative/functional programming in Haskell</description>
	<lastBuildDate>Sat, 26 Sep 2020 21:06:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.1.17</generator>
	<item>
		<title>By: Conal</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-73644</link>
		<dc:creator><![CDATA[Conal]]></dc:creator>
		<pubDate>Wed, 02 Jan 2019 19:12:02 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-73644</guid>
		<description><![CDATA[&lt;p&gt;Hi Michal. Thanks for the comment. I think that equation is as I intended. Writing “&lt;code class=&quot;sourceCode haskell&quot;&gt;⟦m⟧&lt;/code&gt;” instead as “&lt;code class=&quot;sourceCode haskell&quot;&gt;μ m&lt;/code&gt;” may help clarify. Then&lt;/p&gt;

&lt;div class=&quot;sourceCode&quot; id=&quot;cb4&quot;&gt;&lt;pre class=&quot;sourceCode haskell&quot;&gt;&lt;code class=&quot;sourceCode haskell&quot;&gt;&lt;a class=&quot;sourceLine&quot; id=&quot;cb4-1&quot; title=&quot;1&quot; rel=&quot;nofollow&quot;&gt;    &lt;span class=&quot;ot&quot;&gt;∀&lt;/span&gt; m&lt;span class=&quot;fu&quot;&gt;.&lt;/span&gt; μ (&lt;span class=&quot;fu&quot;&gt;fmap&lt;/span&gt; f m) ≡ &lt;span class=&quot;fu&quot;&gt;fmap&lt;/span&gt; f (μ m)&lt;/a&gt;
&lt;a class=&quot;sourceLine&quot; id=&quot;cb4-2&quot; title=&quot;2&quot; rel=&quot;nofollow&quot;&gt; ⟺ &lt;span class=&quot;ot&quot;&gt;∀&lt;/span&gt; m&lt;span class=&quot;fu&quot;&gt;.&lt;/span&gt; (μ ∘ &lt;span class=&quot;fu&quot;&gt;fmap&lt;/span&gt; f) m ≡ (&lt;span class=&quot;fu&quot;&gt;fmap&lt;/span&gt; f ∘ μ) m&lt;/a&gt;
&lt;a class=&quot;sourceLine&quot; id=&quot;cb4-3&quot; title=&quot;3&quot; rel=&quot;nofollow&quot;&gt; ⟺ μ ∘ &lt;span class=&quot;fu&quot;&gt;fmap&lt;/span&gt; f ≡ &lt;span class=&quot;fu&quot;&gt;fmap&lt;/span&gt; f ∘ μ&lt;/a&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;

&lt;p&gt;&lt;/body&gt;&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hi Michal. Thanks for the comment. I think that equation is as I intended. Writing “<code class="sourceCode haskell">⟦m⟧</code>” instead as “<code class="sourceCode haskell">μ m</code>” may help clarify. Then</p>

<div class="sourceCode" id="cb4"><pre class="sourceCode haskell"><code class="sourceCode haskell"><a class="sourceLine" id="cb4-1" title="1" rel="nofollow">    <span class="ot">∀</span> m<span class="fu">.</span> μ (<span class="fu">fmap</span> f m) ≡ <span class="fu">fmap</span> f (μ m)</a>
<a class="sourceLine" id="cb4-2" title="2" rel="nofollow"> ⟺ <span class="ot">∀</span> m<span class="fu">.</span> (μ ∘ <span class="fu">fmap</span> f) m ≡ (<span class="fu">fmap</span> f ∘ μ) m</a>
<a class="sourceLine" id="cb4-3" title="3" rel="nofollow"> ⟺ μ ∘ <span class="fu">fmap</span> f ≡ <span class="fu">fmap</span> f ∘ μ</a></code></pre></div>

<p></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michał Ciaszczyk</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-73432</link>
		<dc:creator><![CDATA[Michał Ciaszczyk]]></dc:creator>
		<pubDate>Mon, 31 Dec 2018 04:24:10 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-73432</guid>
		<description><![CDATA[&lt;p&gt;Hello!
I have been thoroughly enjoying watching your talks on FRP and denotational design. This is fantastic work.&lt;/p&gt;

&lt;p&gt;Since you seem to still update this paper occasionally, here&#039;s a typo I noticed:
In the end of section 5.2 on page 5, in the equation [[fmap f m]] = fmap f [[m]], I&#039;m pretty sure fmap f [[m]] should be the composition fmap f ◦ [[m]] - so the expression can type check and be consistent with the following line.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hello!
I have been thoroughly enjoying watching your talks on FRP and denotational design. This is fantastic work.</p>

<p>Since you seem to still update this paper occasionally, here&#8217;s a typo I noticed:
In the end of section 5.2 on page 5, in the equation [[fmap f m]] = fmap f [[m]], I&#8217;m pretty sure fmap f [[m]] should be the composition fmap f ◦ [[m]] &#8211; so the expression can type check and be consistent with the following line.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Is program proving viable and useful?</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-372</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Is program proving viable and useful?]]></dc:creator>
		<pubDate>Sun, 03 Jan 2010 03:22:52 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-372</guid>
		<description><![CDATA[&lt;p&gt;[...] more examples of formally simple specifications, see the papers Denotational design with type class morphisms and Beautiful [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] more examples of formally simple specifications, see the papers Denotational design with type class morphisms and Beautiful [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Why program with continuous time?</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-371</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Why program with continuous time?]]></dc:creator>
		<pubDate>Sun, 03 Jan 2010 02:40:53 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-371</guid>
		<description><![CDATA[&lt;p&gt;[...] been integral to FRP since the first incarnation as ActiveVRML. I&#8217;ve written several things recently about denotational [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] been integral to FRP since the first incarnation as ActiveVRML. I&#8217;ve written several things recently about denotational [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Thoughts on semantics for 3D graphics</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-370</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Thoughts on semantics for 3D graphics]]></dc:creator>
		<pubDate>Mon, 23 Nov 2009 07:42:36 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-370</guid>
		<description><![CDATA[&lt;p&gt;[...] Recall that we&#8217;re looking for a semantics for 3D geometry. The type for Geometry might be abstract, with (-&gt;) being its semantic model. In that case, the model suggests that Geometry have all of the same type class instances that (-&gt;) (and its full or partial applications) has, including Monoid, Functor, Applicative, Monad, and Arrow. The semantics of these instances would be given by the corresponding instances for (-&gt;). (See posts on type class morphisms and the paper Denotational design with type class morphisms.) [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] Recall that we&#8217;re looking for a semantics for 3D geometry. The type for Geometry might be abstract, with (-&gt;) being its semantic model. In that case, the model suggests that Geometry have all of the same type class instances that (-&gt;) (and its full or partial applications) has, including Monoid, Functor, Applicative, Monad, and Arrow. The semantics of these instances would be given by the corresponding instances for (-&gt;). (See posts on type class morphisms and the paper Denotational design with type class morphisms.) [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip Wadler</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-369</link>
		<dc:creator><![CDATA[Philip Wadler]]></dc:creator>
		<pubDate>Mon, 23 Feb 2009 15:43:45 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-369</guid>
		<description><![CDATA[&lt;p&gt;I posted on this paper in my &lt;a href=&quot;http://wadler.blogspot.com/2009/02/conal-elliot-on-type-class-morphisms.html&quot; rel=&quot;nofollow&quot;&gt;blog&lt;/a&gt;.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>I posted on this paper in my <a href="http://wadler.blogspot.com/2009/02/conal-elliot-on-type-class-morphisms.html" rel="nofollow">blog</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bas van Dijk</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-368</link>
		<dc:creator><![CDATA[Bas van Dijk]]></dc:creator>
		<pubDate>Fri, 20 Feb 2009 19:40:37 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-368</guid>
		<description><![CDATA[&lt;p&gt;Nice paper! Two small points I found so far (still reading...)&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;I think the (a -&gt; b -&gt; c) in the type of &#039;unionMb&#039; should be removed. (In the end of section 3 on page 3)&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Shouldn&#039;t the &#039;ma&#039; and &#039;mb&#039; be introduced in the lhs of the methods of the semantic instance Monoid (TMap k v) (In section 5, page 4)?&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;
]]></description>
		<content:encoded><![CDATA[<p>Nice paper! Two small points I found so far (still reading&#8230;)</p>

<ul>
<li><p>I think the (a -&gt; b -&gt; c) in the type of &#8216;unionMb&#8217; should be removed. (In the end of section 3 on page 3)</p></li>
<li><p>Shouldn&#8217;t the &#8216;ma&#8217; and &#8216;mb&#8217; be introduced in the lhs of the methods of the semantic instance Monoid (TMap k v) (In section 5, page 4)?</p></li>
</ul>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Weston</title>
		<link>http://conal.net/blog/posts/denotational-design-with-type-class-morphisms#comment-367</link>
		<dc:creator><![CDATA[Dan Weston]]></dc:creator>
		<pubDate>Thu, 19 Feb 2009 21:04:15 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=84#comment-367</guid>
		<description><![CDATA[&lt;p&gt;Enjoyed reading your draft of &quot;Denotational design with type class morphisms&quot;.&lt;/p&gt;

&lt;p&gt;I think it would benefit the paper to mention (without explanation) categorical concepts as they apply. For instance, it seems that untrie (creating a suspension) is left adjoint to trie (deep seq). So hyperstrict would be the natural transformation epsilon. Also, section 1.11 seems like too much to tackle in a paper of this scope. You would need to explain the role of functor strength and costrength (aren&#039;t those just the laws you listed in the seconnd equation there?) And the Hm. note begs for mention of a universal property.&lt;/p&gt;

&lt;p&gt;It seems like the basic thrust of your argument is how to create a type class (interface) that is left-adjoint to the forgetful functor mapping an implementation to its denotational semantics (in the sense that any valid imstance must not only satisfy the meaning of the canonical instance but also have no extra meaning beyond it). This interface then (uniquely, up to isomorphism) tells &quot;the truth, the whole truth, and nothing but the truth&quot; about the abstract data type, which is effectively the above-mentioned epsilon natural trnansformation applied to the concrete data type. Words like this up front may help readers orient themselves.&lt;/p&gt;

&lt;p&gt;Finally, the role of bottom seems to be central to the examples, with the goal of design to manifest the role of bottomn om the interface, instead of leaving each imstance free to treat it independently. Is this the main problem you see in interfaces today?&lt;/p&gt;

&lt;p&gt;I notice you did not include Danielsson et al, 2006. &quot;Fast and loose reasoning is morally correct.&quot; in your references, but it seems relevant to your paper.&lt;/p&gt;

&lt;p&gt;Also, in Related Work, you might consider Hagino&#039;s dissertation 1987, &quot;A Categorical Programming Language&quot;. It seems to break functors into adjoint pairs (as I alluded to above) to more explicitly expose the role of strictness as I alluded to above. I may be way off base on this, because Hagino&#039;s work is somewhat beyond my reach.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Enjoyed reading your draft of &#8220;Denotational design with type class morphisms&#8221;.</p>

<p>I think it would benefit the paper to mention (without explanation) categorical concepts as they apply. For instance, it seems that untrie (creating a suspension) is left adjoint to trie (deep seq). So hyperstrict would be the natural transformation epsilon. Also, section 1.11 seems like too much to tackle in a paper of this scope. You would need to explain the role of functor strength and costrength (aren&#8217;t those just the laws you listed in the seconnd equation there?) And the Hm. note begs for mention of a universal property.</p>

<p>It seems like the basic thrust of your argument is how to create a type class (interface) that is left-adjoint to the forgetful functor mapping an implementation to its denotational semantics (in the sense that any valid imstance must not only satisfy the meaning of the canonical instance but also have no extra meaning beyond it). This interface then (uniquely, up to isomorphism) tells &#8220;the truth, the whole truth, and nothing but the truth&#8221; about the abstract data type, which is effectively the above-mentioned epsilon natural trnansformation applied to the concrete data type. Words like this up front may help readers orient themselves.</p>

<p>Finally, the role of bottom seems to be central to the examples, with the goal of design to manifest the role of bottomn om the interface, instead of leaving each imstance free to treat it independently. Is this the main problem you see in interfaces today?</p>

<p>I notice you did not include Danielsson et al, 2006. &#8220;Fast and loose reasoning is morally correct.&#8221; in your references, but it seems relevant to your paper.</p>

<p>Also, in Related Work, you might consider Hagino&#8217;s dissertation 1987, &#8220;A Categorical Programming Language&#8221;. It seems to break functors into adjoint pairs (as I alluded to above) to more explicitly expose the role of strictness as I alluded to above. I may be way off base on this, because Hagino&#8217;s work is somewhat beyond my reach.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
