<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: No monadic headaches: multi-core concurrency is easy in Haskell</title>
	<atom:link href="http://donsbot.wordpress.com/2007/11/26/no-monadic-headaches-multi-core-concurrency-is-easy-in-haskell/feed/" rel="self" type="application/rss+xml" />
	<link>http://donsbot.wordpress.com/2007/11/26/no-monadic-headaches-multi-core-concurrency-is-easy-in-haskell/</link>
	<description>A Journal of Haskell Programming</description>
	<lastBuildDate>Mon, 03 Oct 2011 02:09:43 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: dons00</title>
		<link>http://donsbot.wordpress.com/2007/11/26/no-monadic-headaches-multi-core-concurrency-is-easy-in-haskell/#comment-14</link>
		<dc:creator><![CDATA[dons00]]></dc:creator>
		<pubDate>Tue, 03 Feb 2009 02:45:40 +0000</pubDate>
		<guid isPermaLink="false">http://donsbot.wordpress.com/?p=86#comment-14</guid>
		<description><![CDATA[&gt; better interoperability with other systems

Note that &lt;a href=&quot;http://hackage.haskell.org/cgi-bin/hackage-scripts/package/erlang&quot; rel=&quot;nofollow&quot;&gt;the erlang wire protocol&lt;/a&gt; and &lt;a href=&quot;http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary&quot; rel=&quot;nofollow&quot;&gt;binary parsing&lt;/a&gt; are also available for Haskell. So I really don&#039;t think interoperability is an issue.

Of course, for distributed systems, Erlang&#039;s libraries are far more developed than Haskells, though nothing&#039;s stopping you putting nodes of Haskell runtimes across a cluster speaking, say, the Erlang wire protocol.

The channel-filling-up leading to STM contention issue is intersting. Maybe you should be using Chan rather than STM Chans there.]]></description>
		<content:encoded><![CDATA[<p>&gt; better interoperability with other systems</p>
<p>Note that <a href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/erlang" rel="nofollow">the erlang wire protocol</a> and <a href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary" rel="nofollow">binary parsing</a> are also available for Haskell. So I really don&#8217;t think interoperability is an issue.</p>
<p>Of course, for distributed systems, Erlang&#8217;s libraries are far more developed than Haskells, though nothing&#8217;s stopping you putting nodes of Haskell runtimes across a cluster speaking, say, the Erlang wire protocol.</p>
<p>The channel-filling-up leading to STM contention issue is intersting. Maybe you should be using Chan rather than STM Chans there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian</title>
		<link>http://donsbot.wordpress.com/2007/11/26/no-monadic-headaches-multi-core-concurrency-is-easy-in-haskell/#comment-13</link>
		<dc:creator><![CDATA[Brian]]></dc:creator>
		<pubDate>Mon, 02 Feb 2009 15:37:27 +0000</pubDate>
		<guid isPermaLink="false">http://donsbot.wordpress.com/?p=86#comment-13</guid>
		<description><![CDATA[I wish for an answer this easy for *distributed* Haskell programs.  Erlang does seem to have a better default there, and better interoperability with other systems (using its binary pattern matching syntax).  

I also know I&#039;ve had problems with early experiments with GHC&#039;s parallel Channels.  Channels tend to fill up, as the producer gets scheduled more often than the consumer---or the consumer reliably hits STM retries, so the producer fills memory.  Erlang&#039;s VM has a nice default scheduler: it balances reductions in expressions between threads, and it rewards consumption of messages from channels.  I don&#039;t know how to imitate that behavior in Haskell---how to write one library once and have the scheduling behavior I&#039;d like.]]></description>
		<content:encoded><![CDATA[<p>I wish for an answer this easy for *distributed* Haskell programs.  Erlang does seem to have a better default there, and better interoperability with other systems (using its binary pattern matching syntax).  </p>
<p>I also know I&#8217;ve had problems with early experiments with GHC&#8217;s parallel Channels.  Channels tend to fill up, as the producer gets scheduled more often than the consumer&#8212;or the consumer reliably hits STM retries, so the producer fills memory.  Erlang&#8217;s VM has a nice default scheduler: it balances reductions in expressions between threads, and it rewards consumption of messages from channels.  I don&#8217;t know how to imitate that behavior in Haskell&#8212;how to write one library once and have the scheduling behavior I&#8217;d like.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
