<?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: More Fun With Monoids (and some Functors)</title>
	<atom:link href="http://fmapfixreturn.wordpress.com/2008/02/26/more-fun-with-monoids-and-some-functors/feed/" rel="self" type="application/rss+xml" />
	<link>http://fmapfixreturn.wordpress.com/2008/02/26/more-fun-with-monoids-and-some-functors/</link>
	<description>intercalate " " . ("Haskell" :) . (:[]) $  "Blog"</description>
	<lastBuildDate>Fri, 12 Nov 2010 19:50:53 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: sclv</title>
		<link>http://fmapfixreturn.wordpress.com/2008/02/26/more-fun-with-monoids-and-some-functors/#comment-24</link>
		<dc:creator><![CDATA[sclv]]></dc:creator>
		<pubDate>Thu, 28 Feb 2008 00:02:19 +0000</pubDate>
		<guid isPermaLink="false">http://fmapfixreturn.wordpress.com/?p=9#comment-24</guid>
		<description><![CDATA[You don&#039;t need the type alias at all, actually. That&#039;s just a notational convenience. And you don&#039;t need a typeclass either, and hence no instances.

What you do instead is write functions like the following, which takes an associative list of names and templates and produces a group such that they are able to call one another.


&lt;code&gt;groupStringTemplates :: [(String,StringTemplate)] -&gt; STGroup
groupStringTemplates xs = newGen
&#160;&#160;&#160;&#160;where newGen s = First (M.lookup s ng)
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;ng = M.fromList $ map (second $ sgInsert newGen) xs
&lt;/code&gt;

You&#039;ll notice I&#039;m using a little circular programming hack here too, to set the group of each template as the new group we&#039;re creating, even as we&#039;re still creating the group. It makes the code a little more obscure than necessary, and looking back at it I&#039;m not sure if its actually better or just cuter. Removing the setting of group context entirely, to keep things simple, we get something like (off the top of my head):


&lt;code&gt;groupStringTemplates :: [(String, StringTemplate)] -&gt; STGroup
groupStringTemplates xs = \s -&gt; s = First (M.lookup s myNewMap)
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;where myNewMap = M.fromList xs&lt;/code&gt;


myNewMap is floated into a where clause so that it only gets evaluated once. We just return the function that wraps the results of its lookup into a First. That&#039;s all there is to it -- just return functions directly. addGroups doesn&#039;t need to be written at all. no type instances need to be written at all (well, except for the Functor instance for First, but that&#039;s something that really should be in the standard libs and just isn&#039;t). To add groups g1 and g2 we just write g1 `mappend` g2. It&#039;s hard to see in a way, because thanks to the predefined instances for monoids, everything else comes for free. If someone wants to write a &quot;group&quot; that takes a string and reverses it and then interprets it as perl and returns a StringTemplate built from the result, they just write a function to do just that, and stick First . Just in front of its result. No data declarations, no type declarations, no instances. That function they just wrote is already of the Group type, and for free it can be composed with any other groups of any other sort.

EDIT: Oh, and if you&#039;re asking about what we get with the type before we switch from Maybe to First, the answer above still mainly applies, except we need to write addGroups by hand. However, without the ADTs and typeclasses, we still get away with not needing to write a product type for its result, and we still get away with not needing to write any instance declarations, and we still get away with not needing to write some sort of existential wrapper to avoid an exponential blowup in type signatures or to have multiple groups in a list, etc., and also the need for any class contexts on any functions taking groups as arguments, and suchforth.]]></description>
		<content:encoded><![CDATA[<p>You don&#8217;t need the type alias at all, actually. That&#8217;s just a notational convenience. And you don&#8217;t need a typeclass either, and hence no instances.</p>
<p>What you do instead is write functions like the following, which takes an associative list of names and templates and produces a group such that they are able to call one another.</p>
<p><code>groupStringTemplates :: [(String,StringTemplate)] -&gt; STGroup<br />
groupStringTemplates xs = newGen<br />
&nbsp;&nbsp;&nbsp;&nbsp;where newGen s = First (M.lookup s ng)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ng = M.fromList $ map (second $ sgInsert newGen) xs<br />
</code></p>
<p>You&#8217;ll notice I&#8217;m using a little circular programming hack here too, to set the group of each template as the new group we&#8217;re creating, even as we&#8217;re still creating the group. It makes the code a little more obscure than necessary, and looking back at it I&#8217;m not sure if its actually better or just cuter. Removing the setting of group context entirely, to keep things simple, we get something like (off the top of my head):</p>
<p><code>groupStringTemplates :: [(String, StringTemplate)] -&gt; STGroup<br />
groupStringTemplates xs = \s -&gt; s = First (M.lookup s myNewMap)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;where myNewMap = M.fromList xs</code></p>
<p>myNewMap is floated into a where clause so that it only gets evaluated once. We just return the function that wraps the results of its lookup into a First. That&#8217;s all there is to it &#8212; just return functions directly. addGroups doesn&#8217;t need to be written at all. no type instances need to be written at all (well, except for the Functor instance for First, but that&#8217;s something that really should be in the standard libs and just isn&#8217;t). To add groups g1 and g2 we just write g1 `mappend` g2. It&#8217;s hard to see in a way, because thanks to the predefined instances for monoids, everything else comes for free. If someone wants to write a &#8220;group&#8221; that takes a string and reverses it and then interprets it as perl and returns a StringTemplate built from the result, they just write a function to do just that, and stick First . Just in front of its result. No data declarations, no type declarations, no instances. That function they just wrote is already of the Group type, and for free it can be composed with any other groups of any other sort.</p>
<p>EDIT: Oh, and if you&#8217;re asking about what we get with the type before we switch from Maybe to First, the answer above still mainly applies, except we need to write addGroups by hand. However, without the ADTs and typeclasses, we still get away with not needing to write a product type for its result, and we still get away with not needing to write any instance declarations, and we still get away with not needing to write some sort of existential wrapper to avoid an exponential blowup in type signatures or to have multiple groups in a list, etc., and also the need for any class contexts on any functions taking groups as arguments, and suchforth.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin</title>
		<link>http://fmapfixreturn.wordpress.com/2008/02/26/more-fun-with-monoids-and-some-functors/#comment-23</link>
		<dc:creator><![CDATA[Justin]]></dc:creator>
		<pubDate>Wed, 27 Feb 2008 22:50:10 +0000</pubDate>
		<guid isPermaLink="false">http://fmapfixreturn.wordpress.com/?p=9#comment-23</guid>
		<description><![CDATA[I&#039;m missing how STGroups lets you get away from the typeclass (or makes it simpler) in the third paragraph. Can you expand on how that type alias makes addGroups simpler and/or lets you write fewer Group instances?]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m missing how STGroups lets you get away from the typeclass (or makes it simpler) in the third paragraph. Can you expand on how that type alias makes addGroups simpler and/or lets you write fewer Group instances?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Max</title>
		<link>http://fmapfixreturn.wordpress.com/2008/02/26/more-fun-with-monoids-and-some-functors/#comment-22</link>
		<dc:creator><![CDATA[Max]]></dc:creator>
		<pubDate>Wed, 27 Feb 2008 08:36:39 +0000</pubDate>
		<guid isPermaLink="false">http://fmapfixreturn.wordpress.com/?p=9#comment-22</guid>
		<description><![CDATA[&quot;Get the types and classes right, and the rest of the code almost seems to melt away.&quot;

Amen, brother! :-). I&#039;m constantly surprised at how often constructs from abstract algebra crop up during day to day programming tasks, as long as you look at those. tasks in the right way.

Thanks for the great post!]]></description>
		<content:encoded><![CDATA[<p>&#8220;Get the types and classes right, and the rest of the code almost seems to melt away.&#8221;</p>
<p>Amen, brother! :-). I&#8217;m constantly surprised at how often constructs from abstract algebra crop up during day to day programming tasks, as long as you look at those. tasks in the right way.</p>
<p>Thanks for the great post!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
