<?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: Functional concurrency with unambiguous choice</title>
	<atom:link href="http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice/feed" rel="self" type="application/rss+xml" />
	<link>http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice</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/functional-concurrency-with-unambiguous-choice#comment-218</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Wed, 14 Jul 2010 16:25:16 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=63#comment-218</guid>
		<description><![CDATA[&lt;p&gt;Thanks for the comment, Peter.  Please note from my post:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;In the examples below, I’ll use “⊥” in place of “undefined“, for brevity.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I&#039;m making the same conventional pun as with &quot;3&quot; when describing an expression and when describing a denotation.  Haskell was originally designed when we were stuck with ASCII, but we aren&#039;t any longer.&lt;/p&gt;

&lt;p&gt;I do appreciate care in distinguishing syntax from semantics.  And I can see how using notation like &quot;3&quot; or &quot;⊥&quot; in both situations might confuse.&lt;/p&gt;

&lt;p&gt;Also, I&#039;ve taken care to treat all operational variations of ⊥ in a denotationally consistent way, including non-termination.  If you think there&#039;s a denotational inconsistency, could you please say what?&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Thanks for the comment, Peter.  Please note from my post:</p>

<blockquote>
  <p>In the examples below, I’ll use “⊥” in place of “undefined“, for brevity.</p>
</blockquote>

<p>I&#8217;m making the same conventional pun as with &#8220;3&#8221; when describing an expression and when describing a denotation.  Haskell was originally designed when we were stuck with ASCII, but we aren&#8217;t any longer.</p>

<p>I do appreciate care in distinguishing syntax from semantics.  And I can see how using notation like &#8220;3&#8221; or &#8220;⊥&#8221; in both situations might confuse.</p>

<p>Also, I&#8217;ve taken care to treat all operational variations of ⊥ in a denotationally consistent way, including non-termination.  If you think there&#8217;s a denotational inconsistency, could you please say what?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Berry</title>
		<link>http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice#comment-217</link>
		<dc:creator><![CDATA[Peter Berry]]></dc:creator>
		<pubDate>Wed, 14 Jul 2010 15:44:14 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=63#comment-217</guid>
		<description><![CDATA[&lt;blockquote&gt;
  &lt;p&gt;In Haskell, ⊥ doesn’t simply block forever; it raises an exception.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Bit of a nitpick here: ⊥ is not a Haskell expression, but the denotational semantics of &lt;code&gt;undefined&lt;/code&gt;. The &lt;em&gt;operational&lt;/em&gt; semantics of &lt;code&gt;undefined&lt;/code&gt; (at least in GHC) is indeed to raise an exception, but other expressions denoting ⊥ may have other operational semantics (including blocking forever, since the halting problem is undecidable).&lt;/p&gt;

&lt;p&gt;Speaking of which, you probably want to catch NonTermination as well :)&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<blockquote>
  <p>In Haskell, ⊥ doesn’t simply block forever; it raises an exception.</p>
</blockquote>

<p>Bit of a nitpick here: ⊥ is not a Haskell expression, but the denotational semantics of <code>undefined</code>. The <em>operational</em> semantics of <code>undefined</code> (at least in GHC) is indeed to raise an exception, but other expressions denoting ⊥ may have other operational semantics (including blocking forever, since the halting problem is undecidable).</p>

<p>Speaking of which, you probably want to catch NonTermination as well <img src="http://conal.net/blog/wp-includes/images/smilies/icon_smile.gif" alt=":)" class="wp-smiley" /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Lazier function definitions by merging partial values</title>
		<link>http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice#comment-216</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Lazier function definitions by merging partial values]]></dc:creator>
		<pubDate>Wed, 21 Jan 2009 01:06:47 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=63#comment-216</guid>
		<description><![CDATA[&lt;p&gt;[...] like zip above, where we want unbiased laziness. (See posts on unambiguous choice and especially Functional concurrency with unambiguous choice.) The unamb operator returns the more defined of its two arguments, which are required to be equal [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] like zip above, where we want unbiased laziness. (See posts on unambiguous choice and especially Functional concurrency with unambiguous choice.) The unamb operator returns the more defined of its two arguments, which are required to be equal [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Another angle on functional future values</title>
		<link>http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice#comment-215</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Another angle on functional future values]]></dc:creator>
		<pubDate>Mon, 05 Jan 2009 05:45:32 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=63#comment-215</guid>
		<description><![CDATA[&lt;p&gt;[...] After a while, I hit upon an idea that really tickled me. My original simple semantics could indeed serve as a correct and workable implementation if I used a subtler form of time that could reveal partial information. Implementing this subtler form of time turned out to be quite tricky, and was my original motivation for the unamb operator described in the paper Simply efficient functional reactivity and the post Functional concurrency with unambiguous choice. [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] After a while, I hit upon an idea that really tickled me. My original simple semantics could indeed serve as a correct and workable implementation if I used a subtler form of time that could reveal partial information. Implementing this subtler form of time turned out to be quite tricky, and was my original motivation for the unamb operator described in the paper Simply efficient functional reactivity and the post Functional concurrency with unambiguous choice. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Smarter termination for thread racing</title>
		<link>http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice#comment-214</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Smarter termination for thread racing]]></dc:creator>
		<pubDate>Fri, 19 Dec 2008 08:11:30 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=63#comment-214</guid>
		<description><![CDATA[&lt;p&gt;[...] shower this morning that there&#8217;s a serious flaw in my unamb implementation as described in Functional concurrency with unambiguous choice. Here&#8217;s the code for racing two [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] shower this morning that there&#8217;s a serious flaw in my unamb implementation as described in Functional concurrency with unambiguous choice. Here&#8217;s the code for racing two [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Merging partial values</title>
		<link>http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice#comment-213</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Merging partial values]]></dc:creator>
		<pubDate>Sun, 23 Nov 2008 00:07:17 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=63#comment-213</guid>
		<description><![CDATA[&lt;p&gt;[...] About      &#171; Functional concurrency with unambiguous choice [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] About      &laquo; Functional concurrency with unambiguous choice [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
