<?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: LACSS 2009: Domain Specific Languages and Haskell</title>
	<atom:link href="http://donsbot.wordpress.com/2009/10/16/lacss-2009-domain-specific-languages-and-haskell/feed/" rel="self" type="application/rss+xml" />
	<link>http://donsbot.wordpress.com/2009/10/16/lacss-2009-domain-specific-languages-and-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: solrize</title>
		<link>http://donsbot.wordpress.com/2009/10/16/lacss-2009-domain-specific-languages-and-haskell/#comment-246</link>
		<dc:creator><![CDATA[solrize]]></dc:creator>
		<pubDate>Sat, 17 Oct 2009 22:15:44 +0000</pubDate>
		<guid isPermaLink="false">http://donsbot.wordpress.com/?p=413#comment-246</guid>
		<description><![CDATA[I think Haskell&#039;s suitability for EDSL&#039;s is sort of an accidentally emergent quality that still requires a lot of kludges to really use effectively.  If EDSL&#039;s are supposed to be an important Haskell application area, it may be worth thinking about how to extend Haskell or GHC to help with EDSL implementation.  I&#039;m imagining something along the lines of Liskell, a sort of Template Haskell relative that let you juggle abstract parse trees of Haskell code while still making sure the results were type-checked.  

I&#039;ve been interested for a while in Hedgehog Lisp, a tiny functional Lisp dialect intended for embedded systems.  It would be awesome to have a statically typed variant of it and a Haskell EDSL is the obvious approach.  But while it&#039;s easy to imagine the code inside Hedgehog functions as monadic actions, it&#039;s not so obvious how to express (e.g.) the function definitions themselves.

Maybe there could be an &quot;edo&quot; syntax (embedded do) analogous to mdo.  Among other things all the normal Haskell imports including the Prelude could be completely hidden inside an edo block, so you wouldn&#039;t have to say stuff like &quot;a .+. b&quot; all the time.  Then you&#039;d get a Liskell-ish parse tree which you could rewrite, type-check, and generate code from.]]></description>
		<content:encoded><![CDATA[<p>I think Haskell&#8217;s suitability for EDSL&#8217;s is sort of an accidentally emergent quality that still requires a lot of kludges to really use effectively.  If EDSL&#8217;s are supposed to be an important Haskell application area, it may be worth thinking about how to extend Haskell or GHC to help with EDSL implementation.  I&#8217;m imagining something along the lines of Liskell, a sort of Template Haskell relative that let you juggle abstract parse trees of Haskell code while still making sure the results were type-checked.  </p>
<p>I&#8217;ve been interested for a while in Hedgehog Lisp, a tiny functional Lisp dialect intended for embedded systems.  It would be awesome to have a statically typed variant of it and a Haskell EDSL is the obvious approach.  But while it&#8217;s easy to imagine the code inside Hedgehog functions as monadic actions, it&#8217;s not so obvious how to express (e.g.) the function definitions themselves.</p>
<p>Maybe there could be an &#8220;edo&#8221; syntax (embedded do) analogous to mdo.  Among other things all the normal Haskell imports including the Prelude could be completely hidden inside an edo block, so you wouldn&#8217;t have to say stuff like &#8220;a .+. b&#8221; all the time.  Then you&#8217;d get a Liskell-ish parse tree which you could rewrite, type-check, and generate code from.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dons00</title>
		<link>http://donsbot.wordpress.com/2009/10/16/lacss-2009-domain-specific-languages-and-haskell/#comment-245</link>
		<dc:creator><![CDATA[dons00]]></dc:creator>
		<pubDate>Sat, 17 Oct 2009 16:13:22 +0000</pubDate>
		<guid isPermaLink="false">http://donsbot.wordpress.com/?p=413#comment-245</guid>
		<description><![CDATA[Thanks James. The pdf versions are linked at the start of the article.]]></description>
		<content:encoded><![CDATA[<p>Thanks James. The pdf versions are linked at the start of the article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Britt</title>
		<link>http://donsbot.wordpress.com/2009/10/16/lacss-2009-domain-specific-languages-and-haskell/#comment-244</link>
		<dc:creator><![CDATA[James Britt]]></dc:creator>
		<pubDate>Sat, 17 Oct 2009 16:11:15 +0000</pubDate>
		<guid isPermaLink="false">http://donsbot.wordpress.com/?p=413#comment-244</guid>
		<description><![CDATA[This sounds quite interesting.

Is there a PDF version I can download without needing a user account?]]></description>
		<content:encoded><![CDATA[<p>This sounds quite interesting.</p>
<p>Is there a PDF version I can download without needing a user account?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ravi</title>
		<link>http://donsbot.wordpress.com/2009/10/16/lacss-2009-domain-specific-languages-and-haskell/#comment-243</link>
		<dc:creator><![CDATA[Ravi]]></dc:creator>
		<pubDate>Fri, 16 Oct 2009 21:22:23 +0000</pubDate>
		<guid isPermaLink="false">http://donsbot.wordpress.com/?p=413#comment-243</guid>
		<description><![CDATA[I completely agree with what you&#039;re saying (and wish I&#039;d been there to see it in person). I think there&#039;s a lot of opportunity to build an EDSL that effectively and efficiently straddles a number of different computational models (CPUs, GPUs, FPGAs, &quot;cloud resources&quot;, etc.).]]></description>
		<content:encoded><![CDATA[<p>I completely agree with what you&#8217;re saying (and wish I&#8217;d been there to see it in person). I think there&#8217;s a lot of opportunity to build an EDSL that effectively and efficiently straddles a number of different computational models (CPUs, GPUs, FPGAs, &#8220;cloud resources&#8221;, etc.).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
