<?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: Yet Another Reason Not To Be Lazy Or Imperative</title>
	<atom:link href="http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/feed/" rel="self" type="application/rss+xml" />
	<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/</link>
	<description>Abstract types are existential types.</description>
	<lastBuildDate>Tue, 29 Jan 2013 15:10:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Carter Schonwald</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1080</link>
		<dc:creator><![CDATA[Carter Schonwald]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 21:23:06 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1080</guid>
		<description><![CDATA[Hey Bob! (nifty paper)
Nifty! I actually had a soft pen and paper proof about that sort of well defined GC traversal order enabling good memory locality a few months ago. Its a really *easy*  (super scare quotes) property to prove informally :), and at the time I was really shocked that theres not been any work over that insight. Got a bit side tracked so I never finished formalizing it :). I&#039;m glad someones up and done this.

Either way, its a grand first step in really making reasoning about how to get optimal memory locality while writing high level code tractable. 

I&#039;m having a bit of fun presently building up a bit of intuition in this space as I incremental write some high performance functional programming style tools for  numerical computation. Its an area in desperate need of good PL/FP love, and I&#039;m trying do my part.  

-Carter]]></description>
		<content:encoded><![CDATA[<p>Hey Bob! (nifty paper)<br />
Nifty! I actually had a soft pen and paper proof about that sort of well defined GC traversal order enabling good memory locality a few months ago. Its a really *easy*  (super scare quotes) property to prove informally :), and at the time I was really shocked that theres not been any work over that insight. Got a bit side tracked so I never finished formalizing it :). I&#8217;m glad someones up and done this.</p>
<p>Either way, its a grand first step in really making reasoning about how to get optimal memory locality while writing high level code tractable. </p>
<p>I&#8217;m having a bit of fun presently building up a bit of intuition in this space as I incremental write some high performance functional programming style tools for  numerical computation. Its an area in desperate need of good PL/FP love, and I&#8217;m trying do my part.  </p>
<p>-Carter</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Harper</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1078</link>
		<dc:creator><![CDATA[Robert Harper]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 19:57:49 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1078</guid>
		<description><![CDATA[one could say &quot;provably efficient implementation&quot;, which would be appropriately descriptive, but it&#039;s a bit of a mouthful too (and i just hate having to qualify with &quot;provably&quot; to basically say &quot;we&#039;re serious about this, not some jokers with histograms.&quot;]]></description>
		<content:encoded><![CDATA[<p>one could say &#8220;provably efficient implementation&#8221;, which would be appropriately descriptive, but it&#8217;s a bit of a mouthful too (and i just hate having to qualify with &#8220;provably&#8221; to basically say &#8220;we&#8217;re serious about this, not some jokers with histograms.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Harper</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1075</link>
		<dc:creator><![CDATA[Robert Harper]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 19:49:37 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1075</guid>
		<description><![CDATA[it doesn&#039;t exactly slide off the tongue, but it&#039;s definitely better grammar.]]></description>
		<content:encoded><![CDATA[<p>it doesn&#8217;t exactly slide off the tongue, but it&#8217;s definitely better grammar.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chrisdone</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1074</link>
		<dc:creator><![CDATA[chrisdone]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 19:34:23 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1074</guid>
		<description><![CDATA[s/one might reasonable/one might reasonably]]></description>
		<content:encoded><![CDATA[<p>s/one might reasonable/one might reasonably</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Shulman</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1073</link>
		<dc:creator><![CDATA[Mike Shulman]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 17:19:54 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1073</guid>
		<description><![CDATA[I suppose &quot;provably correct implementation&quot; is too many syllables?]]></description>
		<content:encoded><![CDATA[<p>I suppose &#8220;provably correct implementation&#8221; is too many syllables?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Harper</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1070</link>
		<dc:creator><![CDATA[Robert Harper]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 12:13:02 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1070</guid>
		<description><![CDATA[Oh, don&#039;t get me started on this.  I&#039;ve reluctantly adhered to the pre-existing terminology, despite reservations.  If you or anyone can think of a better name, I&#039;m eager to learn it.  Admittedly &quot;proved implementation&quot; is more accurate than &quot;provable implementation&quot;, but it&#039;s not much of an improvement.  I find it ridiculous that we have to emphasize that we can actually prove the validity of our claims, in contrast to standard practice of, at most, showing a few well-chosen histograms and declaring victory.]]></description>
		<content:encoded><![CDATA[<p>Oh, don&#8217;t get me started on this.  I&#8217;ve reluctantly adhered to the pre-existing terminology, despite reservations.  If you or anyone can think of a better name, I&#8217;m eager to learn it.  Admittedly &#8220;proved implementation&#8221; is more accurate than &#8220;provable implementation&#8221;, but it&#8217;s not much of an improvement.  I find it ridiculous that we have to emphasize that we can actually prove the validity of our claims, in contrast to standard practice of, at most, showing a few well-chosen histograms and declaring victory.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: andrejbauer</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1068</link>
		<dc:creator><![CDATA[andrejbauer]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 05:25:11 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1068</guid>
		<description><![CDATA[This is a sociological remark. You PL types always say things like &quot;provable implementation&quot;. Nobody in logic would every say that. I suspect you mean &quot;implementation which was proved correct by cool people&quot;. I can live with the contraction &quot;proved implementation&quot;, but not with &quot;provable&quot; in place of &quot;proved&quot;. So what do you mean when you say &quot;provable X&quot; with &quot;X&quot; a noun?]]></description>
		<content:encoded><![CDATA[<p>This is a sociological remark. You PL types always say things like &#8220;provable implementation&#8221;. Nobody in logic would every say that. I suspect you mean &#8220;implementation which was proved correct by cool people&#8221;. I can live with the contraction &#8220;proved implementation&#8221;, but not with &#8220;provable&#8221; in place of &#8220;proved&#8221;. So what do you mean when you say &#8220;provable X&#8221; with &#8220;X&#8221; a noun?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy Adams-Moran</title>
		<link>http://existentialtype.wordpress.com/2012/08/26/yet-another-reason-not-to-be-lazy-or-imperative/#comment-1067</link>
		<dc:creator><![CDATA[Andy Adams-Moran]]></dc:creator>
		<pubDate>Mon, 27 Aug 2012 05:04:27 +0000</pubDate>
		<guid isPermaLink="false">http://existentialtype.wordpress.com/?p=753#comment-1067</guid>
		<description><![CDATA[Is &quot;Improvement in a lazy context: An operational theory for call-by-need&quot;, http://dl.acm.org/citation.cfm?id=292547 relevant here? We were using cost semantics to give a theory to call-by-need (and so we tracked lookup/update in the heap instead of I/O reads/writes), but many of the same contextual recursion principles should hold (a context lemma being key to our approach).]]></description>
		<content:encoded><![CDATA[<p>Is &#8220;Improvement in a lazy context: An operational theory for call-by-need&#8221;, <a href="http://dl.acm.org/citation.cfm?id=292547" rel="nofollow">http://dl.acm.org/citation.cfm?id=292547</a> relevant here? We were using cost semantics to give a theory to call-by-need (and so we tracked lookup/update in the heap instead of I/O reads/writes), but many of the same contextual recursion principles should hold (a context lemma being key to our approach).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
