<?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: Rotten Bananas</title>
	<atom:link href="http://comonad.com/reader/2008/rotten-bananas/feed/" rel="self" type="application/rss+xml" />
	<link>http://comonad.com/reader/2008/rotten-bananas/</link>
	<description>types, (co)monads, substructural logic</description>
	<lastBuildDate>Wed, 28 Jul 2010 13:34:03 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: The Comonad.Reader &#187; Unnatural Transformations</title>
		<link>http://comonad.com/reader/2008/rotten-bananas/comment-page-1/#comment-1076</link>
		<dc:creator>The Comonad.Reader &#187; Unnatural Transformations</dc:creator>
		<pubDate>Sun, 27 Apr 2008 00:38:00 +0000</pubDate>
		<guid isPermaLink="false">http://comonad.com/reader/2008/rotten-bananas/#comment-1076</guid>
		<description>[...] Note that while 3 &#039;Functors&#039; e, f and g are involved, only f needs to be a Functor in Hask because we do the duplication, hylomorphism and join all inside f in either case. And most of the time e = f = g. For instance e or g could be exponential or contravariant. [...]</description>
		<content:encoded><![CDATA[<p>[...] Note that while 3 &#8216;Functors&#8217; e, f and g are involved, only f needs to be a Functor in Hask because we do the duplication, hylomorphism and join all inside f in either case. And most of the time e = f = g. For instance e or g could be exponential or contravariant. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darin Morrison</title>
		<link>http://comonad.com/reader/2008/rotten-bananas/comment-page-1/#comment-1020</link>
		<dc:creator>Darin Morrison</dc:creator>
		<pubDate>Sat, 05 Apr 2008 12:00:22 +0000</pubDate>
		<guid isPermaLink="false">http://comonad.com/reader/2008/rotten-bananas/#comment-1020</guid>
		<description>The idea behind the Beluga project is to develop a dependently typed functional programming language that supports HOAS in a natural way.  The connection to LF is that the Beluga language is split into two layers -- a data layer which combines LF with constructs from contextual modal type theory in order to encode (open) data objects (which could represent terms in an object languages with binding described by HOAS), and a computation layer where things like recursion and case analysis happen.  In Beluga, LF objects serve the same purpose as (G)ADTs in Haskell.

HOAS has been with LF and Twelf (which is just an implementation of LF + a logic programming engine and some other stuff) from the beginning, and Beluga has nothing to do with that specifically.  What Beluga is trying to do that is new is to solve the problem of practical functional programming with HOAS.  Compiler construction would be an obvious application.

In any case, it doesn&#039;t really help you program easily with HOAS in Haskell... :)</description>
		<content:encoded><![CDATA[<p>The idea behind the Beluga project is to develop a dependently typed functional programming language that supports HOAS in a natural way.  The connection to LF is that the Beluga language is split into two layers &#8212; a data layer which combines LF with constructs from contextual modal type theory in order to encode (open) data objects (which could represent terms in an object languages with binding described by HOAS), and a computation layer where things like recursion and case analysis happen.  In Beluga, LF objects serve the same purpose as (G)ADTs in Haskell.</p>
<p>HOAS has been with LF and Twelf (which is just an implementation of LF + a logic programming engine and some other stuff) from the beginning, and Beluga has nothing to do with that specifically.  What Beluga is trying to do that is new is to solve the problem of practical functional programming with HOAS.  Compiler construction would be an obvious application.</p>
<p>In any case, it doesn&#8217;t really help you program easily with HOAS in Haskell&#8230; :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Apple</title>
		<link>http://comonad.com/reader/2008/rotten-bananas/comment-page-1/#comment-992</link>
		<dc:creator>Jim Apple</dc:creator>
		<pubDate>Tue, 25 Mar 2008 19:51:06 +0000</pubDate>
		<guid isPermaLink="false">http://comonad.com/reader/2008/rotten-bananas/#comment-992</guid>
		<description>It&#039;s true that the goal of the project is different. The similarity I mean is that HOAS has *traditionally* had the problem of trading case analysis for safety. That is to say, it&#039;s not a just a Haskell problem.</description>
		<content:encoded><![CDATA[<p>It&#8217;s true that the goal of the project is different. The similarity I mean is that HOAS has *traditionally* had the problem of trading case analysis for safety. That is to say, it&#8217;s not a just a Haskell problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Edward Kmett</title>
		<link>http://comonad.com/reader/2008/rotten-bananas/comment-page-1/#comment-991</link>
		<dc:creator>Edward Kmett</dc:creator>
		<pubDate>Tue, 25 Mar 2008 19:14:33 +0000</pubDate>
		<guid isPermaLink="false">http://comonad.com/reader/2008/rotten-bananas/#comment-991</guid>
		<description>The Beluga project seems to be focused on the idea of how to represent HOAS in logical frameworks like LF, TWELF, etc. 

My main focus is on using HOAS practically in a compiler in Haskell. Consequently, I wind up with a fair bit less control over exotic terms, because I don&#039;t get to roll nearly as much of my own structure in the meta-language. 

As a result I&#039;m not sure how much what the Beluga folks are doing really helps, beyond the fact that it was fun getting a chance to pick at another HOAS encoding over lunch. 

I had hoped that the Washburn/Weirich encoding would give me a &#039;no exotic terms  other than bottom&#039; security blanket, but it appears that I just have to suck it up. =)</description>
		<content:encoded><![CDATA[<p>The Beluga project seems to be focused on the idea of how to represent HOAS in logical frameworks like LF, TWELF, etc. </p>
<p>My main focus is on using HOAS practically in a compiler in Haskell. Consequently, I wind up with a fair bit less control over exotic terms, because I don&#8217;t get to roll nearly as much of my own structure in the meta-language. </p>
<p>As a result I&#8217;m not sure how much what the Beluga folks are doing really helps, beyond the fact that it was fun getting a chance to pick at another HOAS encoding over lunch. </p>
<p>I had hoped that the Washburn/Weirich encoding would give me a &#8216;no exotic terms  other than bottom&#8217; security blanket, but it appears that I just have to suck it up. =)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Apple</title>
		<link>http://comonad.com/reader/2008/rotten-bananas/comment-page-1/#comment-989</link>
		<dc:creator>Jim Apple</dc:creator>
		<pubDate>Tue, 25 Mar 2008 10:32:25 +0000</pubDate>
		<guid isPermaLink="false">http://comonad.com/reader/2008/rotten-bananas/#comment-989</guid>
		<description>I think the Beluga project (http://www.cs.mcgill.ca/~complogic/beluga/) addresses your issue. The first paper listed on the page is titled &quot;Case analysis of higher-order data&quot;. :-)</description>
		<content:encoded><![CDATA[<p>I think the Beluga project (<a href="http://www.cs.mcgill.ca/~complogic/beluga/" rel="nofollow">http://www.cs.mcgill.ca/~complogic/beluga/</a>) addresses your issue. The first paper listed on the page is titled &#8220;Case analysis of higher-order data&#8221;. :-)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
