https://wiki.haskell.org/api.php?action=feedcontributions&user=Imz&feedformat=atomHaskellWiki - User contributions [en]2024-03-19T03:26:41ZUser contributionsMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=TypeCompose&diff=59882TypeCompose2015-06-29T13:08:35Z<p>Imz: /* References */ updated a rotten link</p>
<hr />
<div>[[Category:Composition]]<br />
[[Category:Applicative Functor]]<br />
[[Category:Libraries]]<br />
[[Category:Packages]]<br />
[[Category:Type-level programming]]<br />
<br />
== Abstract ==<br />
<br />
'''TypeCompose''' provides some classes & instances for forms of type composition, as well as some modules that haven't found another home.<br />
<br />
Besides this wiki page, here are more ways to find out about TypeCompose:<br />
* Visit the [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TypeCompose Hackage page] for library documentation and to download & install.<br />
* Or install with <tt>cabal install TypeCompose</tt>.<br />
* Get the code repository: <tt>darcs get http://code.haskell.org/~conal/code/TypeCompose</tt>.<br />
<!--* See the [[TypeCompose/Versions| version history]].--><br />
<br />
== Type composition ==<br />
<br />
The <hask>Control.Compose</hask> module includes<br />
* Various type compositions (unary/unary, binary/unary, etc). Most are from [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative Programming with Effects]. In particular, <hask>g `O` f</hask> composes functors in to functors and applicative functors (AFs) into AFs. (In contrast, monads do not in general compose.) Composition makes AF-based programming simple and elegant, partly because we don't need an AF counterpart to monad transformers.<br />
* Cofunctors (contravariant functors). Great for "consumer" types, just as functors suit "producer" (container) types. There are several composition options.<br />
* Type argument flip. Handy for cofunctors: use <hask>Flip (->) o</hask>, for <hask>(-> o)</hask>.<br />
* Constructor in pairs: <hask>(f a, g a)</hask>.<br />
* Constructor in arrows/functions: <hask>f a ~> g a</hask>.<br />
<br />
== Other features ==<br />
<br />
=== Composable bijections ===<br />
<br />
Given all the type constructors and compositions of them, I found myself writing some pretty awkward code to wrap & unwrap through multiple layers. Composable bijections help a lot.<br />
<br />
The <hask>Data.Bijection</hask> module is inspired by [http://citeseer.ist.psu.edu/alimarine05there.html There and Back Again: Arrows for Invertible Programming], though done here in a less general setting.<br />
<br />
=== Pair- & function-like types ===<br />
<br />
The <hask>Data.Zip</hask> and <hask>Data.Lambda</hask> patterns emerged while working on [[DeepArrow]] and [[Eros]]. <hask>Data.Zip</hask> generalizes <hask>zip</hask> and <hask>unzip</hask> from <hask>[]</hask> to other functors. It also provides variants of type <hask>f a -> f (a,b)</hask> and <hask>f a -> f (a,b)</hask>. <hask>Data.Lambda</hask> is similar with classes for lambda-like constructions.<br />
<br />
For example uses of <hask>Pair</hask> and <hask>Lambda</hask>, see [[TV]] and [[Eros]].<br />
<br />
=== References ===<br />
<br />
Monads with references. Direct rip-off from [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.145 Global Variables in Haskell].<br />
<br />
=== Titling ===<br />
<br />
For giving titles to things. I know it sounds kind of random. More useful than I first thought. Used in [[Phooey]], [[TV]], and [[Eros]].<br />
<br />
=== Partial values ===<br />
<br />
A monoid of partial values. See the [http://conal.net/blog/posts/a-type-for-partial-values/ teaser] and [http://conal.net/blog/posts/implementing-a-type-for-partial-values/ solution] blog<br />
posts.<br />
<br />
=== Context-dependent monoids ===<br />
<br />
Bit of an oddball also. <hask>Data.CxMonoid</hask> defines a sort of meta-monoid, that can be supplied dynamically with choices of <hask>mempty</hask> and <hask>mappend</hask>. Used in [[Phooey]] (starting with version 1.3) so that layout could be a monoid but still vary in style.</div>Imzhttps://wiki.haskell.org/index.php?title=Typeclassopedia&diff=59691Typeclassopedia2015-04-21T19:58:23Z<p>Imz: /* Further reading */ fix a link (and hopefully it will be version-independent; is it good?)</p>
<hr />
<div>''By [[User:Byorgey|Brent Yorgey]], byorgey@cis.upenn.edu''<br />
<br />
''Originally published 12 March 2009 in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13] of [http://themonadreader.wordpress.com/ the Monad.Reader]. Ported to the Haskell wiki in November 2011 by [[User:Geheimdienst|Geheimdienst]].''<br />
<br />
''This is now the official version of the Typeclassopedia and supersedes the version published in the Monad.Reader. Please help update and extend it by editing it yourself or by leaving comments, suggestions, and questions on the [[Talk:Typeclassopedia|talk page]].''<br />
<br />
=Abstract=<br />
<br />
The standard Haskell libraries feature a number of type classes with algebraic or category-theoretic underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs.<br />
<br />
The goal of this document is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading.<br />
<br />
=Introduction=<br />
<br />
Have you ever had any of the following thoughts?<br />
* What the heck is a monoid, and how is it different from a mon<u>a</u>d?<br />
<br />
* I finally figured out how to use [[Parsec]] with do-notation, and someone told me I should use something called <code>Applicative</code> instead. Um, what?<br />
<br />
* Someone in the [[IRC channel|#haskell]] IRC channel used <code>(***)</code>, and when I asked Lambdabot to tell me its type, it printed out scary gobbledygook that didn’t even fit on one line! Then someone used <code>fmap fmap fmap</code> and my brain exploded.<br />
<br />
* When I asked how to do something I thought was really complicated, people started typing things like <code>zip.ap fmap.(id &&& wtf)</code> and the scary thing is that they worked! Anyway, I think those people must actually be robots because there’s no way anyone could come up with that in two seconds off the top of their head.<br />
<br />
If you have, look no further! You, too, can write and understand concise, elegant, idiomatic Haskell code with the best of them.<br />
<br />
There are two keys to an expert Haskell hacker’s wisdom:<br />
# Understand the types.<br />
# Gain a deep intuition for each type class and its relationship to other type classes, backed up by familiarity with many examples.<br />
<br />
It’s impossible to overstate the importance of the first; the patient student of type signatures will uncover many profound secrets. Conversely, anyone ignorant of the types in their code is doomed to eternal uncertainty. “Hmm, it doesn’t compile ... maybe I’ll stick in an<br />
<code>fmap</code> here ... nope, let’s see ... maybe I need another <code>(.)</code> somewhere? ... um ...”<br />
<br />
The second key—gaining deep intuition, backed by examples—is also important, but much more difficult to attain. A primary goal of this document is to set you on the road to gaining such intuition. However—<br />
<br />
:''There is no royal road to Haskell. {{h:title|Well, he probably would have said it if he knew Haskell.|—Euclid}}''<br />
<br />
This document can only be a starting point, since good intuition comes from hard work, [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ not from learning the right metaphor]. Anyone who reads and understands all of it will still have an arduous journey ahead—but sometimes a good starting point makes a big difference.<br />
<br />
It should be noted that this is not a Haskell tutorial; it is assumed that the reader is already familiar with the basics of Haskell, including the standard <code>[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html Prelude]</code>, the type system, data types, and type classes.<br />
<br />
The type classes we will be discussing and their interrelationships:<br />
<br />
[[Image:Typeclassopedia-diagram.png]]<br />
<br />
{{note|<code>Semigroup</code> can be found in the [http://hackage.haskell.org/package/semigroups <code>semigroups</code> package], <code>Apply</code> in the [http://hackage.haskell.org/package/semigroupoids <code>semigroupoids</code> package], and <code>Comonad</code> in the [http://hackage.haskell.org/package/comonad <code>comonad</code> package].}}<br />
<br />
* <span style="border-bottom: 2px solid black">Solid arrows</span> point from the general to the specific; that is, if there is an arrow from <code>Foo</code> to <code>Bar</code> it means that every <code>Bar</code> is (or should be, or can be made into) a <code>Foo</code>.<br />
* <span style="border-bottom: 2px dotted black">Dotted arrows</span> indicate some other sort of relationship.<br />
* <code>Monad</code> and <code>ArrowApply</code> are equivalent.<br />
* <code>Semigroup</code>, <code>Apply</code> and <code>Comonad</code> are greyed out since they are not actually (yet?) in the standard Haskell libraries {{noteref}}.<br />
<br />
One more note before we begin. The original spelling of “type class” is with two words, as evidenced by, for example, the [http://www.haskell.org/onlinereport/haskell2010/ Haskell 2010 Language Report], early papers on type classes like [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.5639 Type classes in Haskell] and [http://research.microsoft.com/en-us/um/people/simonpj/papers/type-class-design-space/ Type classes: exploring the design space], and [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.168.4008 Hudak et al.’s history of Haskell]. However, as often happens with two-word phrases that see a lot of use, it has started to show up as one word (“typeclass”) or, rarely, hyphenated (“type-class”). When wearing my prescriptivist hat, I prefer “type class”, but realize (after changing into my descriptivist hat) that there's probably not much I can do about it.<br />
<br />
We now begin with the simplest type class of all: <code>Functor</code>.<br />
<br />
=Functor=<br />
<br />
The <code>Functor</code> class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Functor haddock]) is the most basic and ubiquitous type class in the Haskell libraries. A simple intuition is that a <code>Functor</code> represents a “container” of some sort, along with the ability to apply a function uniformly to every element in the container. For example, a list is a container of elements, and we can apply a function to every element of a list, using <code>map</code>. As another example, a binary tree is also a container of elements, and it’s not hard to come up with a way to recursively apply a function to every element in a tree.<br />
<br />
Another intuition is that a <code>Functor</code> represents some sort of “computational context”. This intuition is generally more useful, but is more difficult to explain, precisely because it is so general. Some examples later should help to clarify the <code>Functor</code>-as-context point of view.<br />
<br />
In the end, however, a <code>Functor</code> is simply what it is defined to be; doubtless there are many examples of <code>Functor</code> instances that don’t exactly fit either of the above intuitions. The wise student will focus their attention on definitions and examples, without leaning too heavily on any particular metaphor. Intuition will come, in time, on its own.<br />
<br />
==Definition==<br />
<br />
Here is the type class declaration for <code>Functor</code>:<br />
<br />
<haskell><br />
class Functor f where<br />
fmap :: (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
<code>Functor</code> is exported by the <code>Prelude</code>, so no special imports are needed to use it.<br />
<br />
First, the <code>f a</code> and <code>f b</code> in the type signature for <code>fmap</code> tell us that <code>f</code> isn’t just a type; it is a ''type constructor'' which takes another type as a parameter. (A more precise way to say this is that the ''kind'' of <code>f</code> must be <code>* -> *</code>.) For example, <code>Maybe</code> is such a type constructor: <code>Maybe</code> is not a type in and of itself, but requires another type as a parameter, like <code>Maybe Integer</code>. So it would not make sense to say <code>instance Functor Integer</code>, but it could make sense to say <code>instance Functor Maybe</code>.<br />
<br />
Now look at the type of <code>fmap</code>: it takes any function from <code>a</code> to <code>b</code>, and a value of type <code>f a</code>, and outputs a value of type <code>f b</code>. From the container point of view, the intention is that <code>fmap</code> applies a function to each element of a container, without altering the structure of the container. From the context point of view, the intention is that <code>fmap</code> applies a function to a value without altering its context. Let’s look at a few specific examples.<br />
<br />
==Instances==<br />
<br />
{{note|Recall that <code>[]</code> has two meanings in Haskell: it can either stand for the empty list, or, as here, it can represent the list type constructor (pronounced “list-of”). In other words, the type <code>[a]</code> (list-of-<code>a</code>) can also be written <code>[] a</code>.}}<br />
<br />
{{note|You might ask why we need a separate <code>map</code> function. Why not just do away with the current list-only <code>map</code> function, and rename <code>fmap</code> to <code>map</code> instead? Well, that’s a good question. The usual argument is that someone just learning Haskell, when using <code>map</code> incorrectly, would much rather see an error about lists than about <code>Functor</code>s.}}<br />
<br />
As noted before, the list constructor <code>[]</code> is a functor {{noteref}}; we can use the standard list function <code>map</code> to apply a function to each element of a list {{noteref}}. The <code>Maybe</code> type constructor is also a functor, representing a container which might hold a single element. The function <code>fmap g</code> has no effect on <code>Nothing</code> (there are no elements to which <code>g</code> can be applied), and simply applies <code>g</code> to the single element inside a <code>Just</code>. Alternatively, under the context interpretation, the list functor represents a context of nondeterministic choice; that is, a list can be thought of as representing a single value which is nondeterministically chosen from among several possibilities (the elements of the list). Likewise, the <code>Maybe</code> functor represents a context with possible failure. These instances are:<br />
<br />
<haskell><br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : fmap g xs<br />
-- or we could just say fmap = map<br />
<br />
instance Functor Maybe where<br />
fmap _ Nothing = Nothing<br />
fmap g (Just a) = Just (g a)<br />
</haskell><br />
<br />
As an aside, in idiomatic Haskell code you will often see the letter <code>f</code> used to stand for both an arbitrary <code>Functor</code> and an arbitrary function. In this document, <code>f</code> represents only <code>Functor</code>s, and <code>g</code> or <code>h</code> always represent functions, but you should be aware of the potential confusion. In practice, what <code>f</code> stands for should always be clear from the context, by noting whether it is part of a type or part of the code.<br />
<br />
There are other <code>Functor</code> instances in the standard libraries; below are a few. Note that some of these instances are not exported by the <code>Prelude</code>; to access them, you can import <code>Control.Monad.Instances</code>.<br />
<br />
* <code>Either e</code> is an instance of <code>Functor</code>; <code>Either e a</code> represents a container which can contain either a value of type <code>a</code>, or a value of type <code>e</code> (often representing some sort of error condition). It is similar to <code>Maybe</code> in that it represents possible failure, but it can carry some extra information about the failure as well.<br />
<br />
* <code>((,) e)</code> represents a container which holds an “annotation” of type <code>e</code> along with the actual value it holds. It might be clearer to write it as <code>(e,)</code>, by analogy with an operator section like <code>(1+)</code>, but that syntax is not allowed in types (although it is allowed in expressions with the <code>TupleSections</code> extension enabled). However, you can certainly ''think'' of it as <code>(e,)</code>.<br />
<br />
* <code>((->) e)</code> (which can be thought of as <code>(e ->)</code>; see above), the type of functions which take a value of type <code>e</code> as a parameter, is a <code>Functor</code>. As a container, <code>(e -> a)</code> represents a (possibly infinite) set of values of <code>a</code>, indexed by values of <code>e</code>. Alternatively, and more usefully, <code>((->) e)</code> can be thought of as a context in which a value of type <code>e</code> is available to be consulted in a read-only fashion. This is also why <code>((->) e)</code> is sometimes referred to as the ''reader monad''; more on this later.<br />
<br />
* <code>IO</code> is a <code>Functor</code>; a value of type <code>IO a</code> represents a computation producing a value of type <code>a</code> which may have I/O effects. If <code>m</code> computes the value <code>x</code> while producing some I/O effects, then <code>fmap g m</code> will compute the value <code>g x</code> while producing the same I/O effects.<br />
<br />
* Many standard types from the [http://hackage.haskell.org/package/containers/ containers library] (such as <code>Tree</code>, <code>Map</code>, and <code>Sequence</code>) are instances of <code>Functor</code>. A notable exception is <code>Set</code>, which cannot be made a <code>Functor</code> in Haskell (although it is certainly a mathematical functor) since it requires an <code>Ord</code> constraint on its elements; <code>fmap</code> must be applicable to ''any'' types <code>a</code> and <code>b</code>. However, <code>Set</code> (and other similarly restricted data types) can be made an instance of a suitable generalization of <code>Functor</code>, either by [http://article.gmane.org/gmane.comp.lang.haskell.cafe/78052/ making <code>a</code> and <code>b</code> arguments to the <code>Functor</code> type class themselves], or by adding an [http://blog.omega-prime.co.uk/?p=127 associated constraint].<br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement <code>Functor</code> instances for <code>Either e</code> and <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> instances for <code>((,) e)</code> and for <code>Pair</code>, defined as <br />
<br />
<haskell>data Pair a = Pair a a</haskell><br />
<br />
Explain their similarities and differences.<br />
</li><br />
<li>Implement a <code>Functor</code> instance for the type <code>ITree</code>, defined as<br />
<br />
<haskell><br />
data ITree a = Leaf (Int -> a) <br />
| Node [ITree a]<br />
</haskell><br />
</li><br />
<li>Give an example of a type of kind <code>* -> *</code> which cannot be made an instance of <code>Functor</code> (without using <code>undefined</code>).<br />
</li><br />
<li>Is this statement true or false? <br />
<br />
:''The composition of two <code>Functor</code>s is also a <code>Functor</code>.''<br />
<br />
If false, give a counterexample; if true, prove it by exhibiting some appropriate Haskell code.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Laws==<br />
<br />
As far as the Haskell language itself is concerned, the only requirement to be a <code>Functor</code> is an implementation of <code>fmap</code> with the proper type. Any sensible <code>Functor</code> instance, however, will also satisfy the ''functor laws'', which are part of the definition of a mathematical functor. There are two:<br />
<br />
<haskell><br />
fmap id = id<br />
fmap (g . h) = (fmap g) . (fmap h)<br />
</haskell><br />
<br />
{{note|Technically, these laws make <code>f</code> and <code>fmap</code> together an endofunctor on ''Hask'', the category of Haskell types (ignoring [[Bottom|&perp;]], which is a party pooper). See [http://en.wikibooks.org/wiki/Haskell/Category_theory Wikibook: Category theory].}}<br />
<br />
Together, these laws ensure that <code>fmap g</code> does not change the ''structure'' of a container, only the elements. Equivalently, and more simply, they ensure that <code>fmap g</code> changes a value without altering its context {{noteref}}.<br />
<br />
The first law says that mapping the identity function over every item in a container has no effect. The second says that mapping a composition of two functions over every item in a container is the same as first mapping one function, and then mapping the other.<br />
<br />
As an example, the following code is a “valid” instance of <code>Functor</code> (it typechecks), but it violates the functor laws. Do you see why?<br />
<br />
<haskell><br />
-- Evil Functor instance<br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : g x : fmap g xs<br />
</haskell><br />
<br />
Any Haskeller worth their salt would reject this code as a gruesome abomination.<br />
<br />
Unlike some other type classes we will encounter, a given type has at most one valid instance of <code>Functor</code>. This [http://article.gmane.org/gmane.comp.lang.haskell.libraries/15384 can be proven] via the [http://homepages.inf.ed.ac.uk/wadler/topics/parametricity.html#free ''free theorem''] for the type of <code>fmap</code>. In fact, [http://byorgey.wordpress.com/2010/03/03/deriving-pleasure-from-ghc-6-12-1/ GHC can automatically derive] <code>Functor</code> instances for many data types.<br />
<br />
{{note|Actually, if <code>seq</code>/<code>undefined</code> are considered, it [http://stackoverflow.com/a/8323243/305559 is possible] to have an implementation which satisfies the first law but not the second. The rest of the comments in this section should considered in a context where <code>seq</code> and <code>undefined</code> are excluded.}}<br />
<br />
A [https://github.com/quchen/articles/blob/master/second_functor_law.md similar argument also shows] that any <code>Functor</code> instance satisfying the first law (<code>fmap id = id</code>) will automatically satisfy the second law as well. Practically, this means that only the first law needs to be checked (usually by a very straightforward induction) to ensure that a <code>Functor</code> instance is valid.{{noteref}}<br />
<br />
{{Exercises|<br />
# Although it is not possible for a <code>Functor</code> instance to satisfy the first <code>Functor</code> law but not the second (excluding <code>undefined</code>), the reverse is possible. Give an example of a (bogus) <code>Functor</code> instance which satisfies the second law but not the first.<br />
# Which laws are violated by the evil <code>Functor</code> instance for list shown above: both laws, or the first law alone? Give specific counterexamples.<br />
}}<br />
<br />
==Intuition==<br />
<br />
There are two fundamental ways to think about <code>fmap</code>. The first has already been mentioned: it takes two parameters, a function and a container, and applies the function “inside” the container, producing a new container. Alternately, we can think of <code>fmap</code> as applying a function to a value in a context (without altering the context).<br />
<br />
Just like all other Haskell functions of “more than one parameter”, however, <code>fmap</code> is actually ''curried'': it does not really take two parameters, but takes a single parameter and returns a function. For emphasis, we can write <code>fmap</code>’s type with extra parentheses: <code>fmap :: (a -> b) -> (f a -> f b)</code>. Written in this form, it is apparent that <code>fmap</code> transforms a “normal” function (<code>g :: a -> b</code>) into one which operates over containers/contexts (<code>fmap g :: f a -> f b</code>). This transformation is often referred to as a ''lift''; <code>fmap</code> “lifts” a function from the “normal world” into the “<code>f</code> world”.<br />
<br />
==Further reading==<br />
<br />
A good starting point for reading about the category theory behind the concept of a functor is the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page on category theory].<br />
<br />
=Applicative=<br />
<br />
A somewhat newer addition to the pantheon of standard Haskell type classes, ''applicative functors'' represent an abstraction lying in between <code>Functor</code> and <code>Monad</code> in expressivity, first described by McBride and Paterson. The title of their classic paper, [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative Programming with Effects], gives a hint at the intended intuition behind the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html <code>Applicative</code>] type class. It encapsulates certain sorts of “effectful” computations in a functionally pure way, and encourages an “applicative” programming style. Exactly what these things mean will be seen later.<br />
<br />
==Definition==<br />
<br />
Recall that <code>Functor</code> allows us to lift a “normal” function to a function on computational contexts. But <code>fmap</code> doesn’t allow us to apply a function which is itself in a context to a value in a context. <code>Applicative</code> gives us just such a tool, <code>(<*>)</code>. It also provides a method, <code>pure</code>, for embedding values in a default, “effect free” context. Here is the type class declaration for <code>Applicative</code>, as defined in <code>Control.Applicative</code>:<br />
<br />
<haskell><br />
class Functor f => Applicative f where<br />
pure :: a -> f a<br />
(<*>) :: f (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
Note that every <code>Applicative</code> must also be a <code>Functor</code>. In fact, as we will see, <code>fmap</code> can be implemented using the <code>Applicative</code> methods, so every <code>Applicative</code> is a functor whether we like it or not; the <code>Functor</code> constraint forces us to be honest.<br />
<br />
{{note|Recall that <code>($)</code> is just function application: <code>f $ x {{=}} f x</code>.}}<br />
<br />
As always, it’s crucial to understand the type signatures. First, consider <code>(<*>)</code>: the best way of thinking about it comes from noting that the type of <code>(<*>)</code> is similar to the type of <code>($)</code> {{noteref}}, but with everything enclosed in an <code>f</code>. In other words, <code>(<*>)</code> is just function application within a computational context. The type of <code>(<*>)</code> is also very similar to the type of <code>fmap</code>; the only difference is that the first parameter is <code>f (a -> b)</code>, a function in a context, instead of a “normal” function <code>(a -> b)</code>.<br />
<br />
<code>pure</code> takes a value of any type <code>a</code>, and returns a context/container of type <code>f a</code>. The intention is that <code>pure</code> creates some sort of “default” container or “effect free” context. In fact, the behavior of <code>pure</code> is quite constrained by the laws it should satisfy in conjunction with <code>(<*>)</code>. Usually, for a given implementation of <code>(<*>)</code> there is only one possible implementation of <code>pure</code>.<br />
<br />
(Note that previous versions of the Typeclassopedia explained <code>pure</code> in terms of a type class <code>Pointed</code>, which can still be found in the [http://hackage.haskell.org/package/pointed <code>pointed</code> package]. However, the current consensus is that <code>Pointed</code> is not very useful after all. For a more detailed explanation, see [[Why not Pointed?]])<br />
<br />
==Laws==<br />
<br />
{{note|See<br />
[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html haddock for Applicative] and [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative programming with effects]}}<br />
<br />
Traditionally, there are four laws that <code>Applicative</code> instances should satisfy {{noteref}}. In some sense, they are all concerned with making sure that <code>pure</code> deserves its name:<br />
<br />
* The identity law:<br /><haskell>pure id <*> v = v</haskell><br />
* Homomorphism:<br /><haskell>pure f <*> pure x = pure (f x)</haskell>Intuitively, applying a non-effectful function to a non-effectful argument in an effectful context is the same as just applying the function to the argument and then injecting the result into the context with <code>pure</code>.<br />
* Interchange:<br /><haskell>u <*> pure y = pure ($ y) <*> u</haskell>Intuitively, this says that when evaluating the application of an effectful function to a pure argument, the order in which we evaluate the function and its argument doesn't matter.<br />
* Composition:<br /><haskell>u <*> (v <*> w) = pure (.) <*> u <*> v <*> w </haskell>This one is the trickiest law to gain intuition for. In some sense it is expressing a sort of associativity property of <code>(<*>)</code>. The reader may wish to simply convince themselves that this law is type-correct.<br />
<br />
Considered as left-to-right rewrite rules, the homomorphism, interchange, and composition laws actually constitute an algorithm for transforming any expression using <code>pure</code> and <code>(<*>)</code> into a canonical form with only a single use of <code>pure</code> at the very beginning and only left-nested occurrences of <code>(<*>)</code>. Composition allows reassociating <code>(<*>)</code>; interchange allows moving occurrences of <code>pure</code> leftwards; and homomorphism allows collapsing multiple adjacent occurrences of <code>pure</code> into one.<br />
<br />
There is also a law specifying how <code>Applicative</code> should relate to <code>Functor</code>:<br />
<br />
<haskell><br />
fmap g x = pure g <*> x<br />
</haskell><br />
<br />
It says that mapping a pure function <code>g</code> over a context <code>x</code> is the same as first injecting <code>g</code> into a context with <code>pure</code>, and then applying it to <code>x</code> with <code>(<*>)</code>. In other words, we can decompose <code>fmap</code> into two more atomic operations: injection into a context, and application within a context. The <code>Control.Applicative</code> module also defines <code>(<$>)</code> as a synonym for <code>fmap</code>, so the above law can also be expressed as:<br />
<br />
<code>g <$> x = pure g <*> x</code>.<br />
<br />
{{Exercises|<br />
# (Tricky) One might imagine a variant of the interchange law that says something about applying a pure function to an effectful argument. Using the above laws, prove that<haskell>pure f <*> x = pure (flip ($)) <*> x <*> pure f</haskell><br />
}}<br />
<br />
==Instances==<br />
<br />
Most of the standard types which are instances of <code>Functor</code> are also instances of <code>Applicative</code>.<br />
<br />
<code>Maybe</code> can easily be made an instance of <code>Applicative</code>; writing such an instance is left as an exercise for the reader.<br />
<br />
The list type constructor <code>[]</code> can actually be made an instance of <code>Applicative</code> in two ways; essentially, it comes down to whether we want to think of lists as ordered collections of elements, or as contexts representing multiple results of a nondeterministic computation (see Wadler’s [http://www.springerlink.com/content/y7450255v2670167/ How to replace failure by a list of successes]).<br />
<br />
Let’s first consider the collection point of view. Since there can only be one instance of a given type class for any particular type, one or both of the list instances of <code>Applicative</code> need to be defined for a <code>newtype</code> wrapper; as it happens, the nondeterministic computation instance is the default, and the collection instance is defined in terms of a <code>newtype</code> called <code>ZipList</code>. This instance is:<br />
<br />
<haskell><br />
newtype ZipList a = ZipList { getZipList :: [a] }<br />
<br />
instance Applicative ZipList where<br />
pure = undefined -- exercise<br />
(ZipList gs) <*> (ZipList xs) = ZipList (zipWith ($) gs xs)<br />
</haskell><br />
<br />
To apply a list of functions to a list of inputs with <code>(<*>)</code>, we just match up the functions and inputs elementwise, and produce a list of the resulting outputs. In other words, we “zip” the lists together with function application, <code>($)</code>; hence the name <code>ZipList</code>. <br />
<br />
The other <code>Applicative</code> instance for lists, based on the nondeterministic computation point of view, is:<br />
<br />
<haskell><br />
instance Applicative [] where<br />
pure x = [x]<br />
gs <*> xs = [ g x | g <- gs, x <- xs ]<br />
</haskell><br />
<br />
Instead of applying functions to inputs pairwise, we apply each function to all the inputs in turn, and collect all the results in a list.<br />
<br />
Now we can write nondeterministic computations in a natural style. To add the numbers <code>3</code> and <code>4</code> deterministically, we can of course write <code>(+) 3 4</code>. But suppose instead of <code>3</code> we have a nondeterministic computation that might result in <code>2</code>, <code>3</code>, or <code>4</code>; then we can write<br />
<br />
<haskell><br />
pure (+) <*> [2,3,4] <*> pure 4<br />
</haskell><br />
<br />
or, more idiomatically,<br />
<br />
<haskell><br />
(+) <$> [2,3,4] <*> pure 4.<br />
</haskell><br />
<br />
There are several other <code>Applicative</code> instances as well:<br />
<br />
* <code>IO</code> is an instance of <code>Applicative</code>, and behaves exactly as you would think: to execute <code>m1 <*> m2</code>, first <code>m1</code> is executed, resulting in a function <code>f</code>, then <code>m2</code> is executed, resulting in a value <code>x</code>, and finally the value <code>f x</code> is returned as the result of executing <code>m1 <*> m2</code>.<br />
<br />
* <code>((,) a)</code> is an <code>Applicative</code>, as long as <code>a</code> is an instance of <code>Monoid</code> ([[#Monoid|section Monoid]]). The <code>a</code> values are accumulated in parallel with the computation.<br />
<br />
* The <code>Applicative</code> module defines the <code>Const</code> type constructor; a value of type <code>Const a b</code> simply contains an <code>a</code>. This is an instance of <code>Applicative</code> for any <code>Monoid a</code>; this instance becomes especially useful in conjunction with things like <code>Foldable</code> ([[#Foldable|section Foldable]]).<br />
<br />
* The <code>WrappedMonad</code> and <code>WrappedArrow</code> newtypes make any instances of <code>Monad</code> ([[#Monad|section Monad]]) or <code>Arrow</code> ([[#Arrow|section Arrow]]) respectively into instances of <code>Applicative</code>; as we will see when we study those type classes, both are strictly more expressive than <code>Applicative</code>, in the sense that the <code>Applicative</code> methods can be implemented in terms of their methods.<br />
<br />
{{Exercises|<br />
# Implement an instance of <code>Applicative</code> for <code>Maybe</code>.<br />
# Determine the correct definition of <code>pure</code> for the <code>ZipList</code> instance of <code>Applicative</code>—there is only one implementation that satisfies the law relating <code>pure</code> and <code>(<*>)</code>.<br />
}}<br />
<br />
==Intuition==<br />
<br />
McBride and Paterson’s paper introduces the notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> to denote function application in a computational context. If each <math>x_i\ </math> has type <math>f \; t_i\ </math> for some applicative functor <math>f\ </math>, and <math>g\ </math> has type <math>t_1 \to t_2 \to \dots \to t_n \to t\ </math>, then the entire expression <math>[[g \; x_1 \; \cdots \; x_n]]\ </math> has type <math>f \; t\ </math>. You can think of this as applying a function to multiple “effectful” arguments. In this sense, the double bracket notation is a generalization of <code>fmap</code>, which allows us to apply a function to a single argument in a context.<br />
<br />
Why do we need <code>Applicative</code> to implement this generalization of <code>fmap</code>? Suppose we use <code>fmap</code> to apply <code>g</code> to the first parameter <code>x1</code>. Then we get something of type <code>f (t2 -> ... t)</code>, but now we are stuck: we can’t apply this function-in-a-context to the next argument with <code>fmap</code>. However, this is precisely what <code>(<*>)</code> allows us to do.<br />
<br />
This suggests the proper translation of the idealized notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> into Haskell, namely<br />
<haskell><br />
g <$> x1 <*> x2 <*> ... <*> xn,<br />
</haskell><br />
<br />
recalling that <code>Control.Applicative</code> defines <code>(<$>)</code> as convenient infix shorthand for <code>fmap</code>. This is what is meant by an “applicative style”—effectful computations can still be described in terms of function application; the only difference is that we have to use the special operator <code>(<*>)</code> for application instead of simple juxtaposition.<br />
<br />
Note that <code>pure</code> allows embedding “non-effectful” arguments in the middle of an idiomatic application, like<br />
<haskell><br />
g <$> x1 <*> pure x2 <*> x3<br />
</haskell><br />
which has type <code>f d</code>, given<br />
<haskell><br />
g :: a -> b -> c -> d<br />
x1 :: f a<br />
x2 :: b<br />
x3 :: f c<br />
</haskell><br />
<br />
The double brackets are commonly known as “idiom brackets”, because they allow writing “idiomatic” function application, that is, function application that looks normal but has some special, non-standard meaning (determined by the particular instance of <code>Applicative</code> being used). Idiom brackets are not supported by GHC, but they are supported by the [http://personal.cis.strath.ac.uk/~conor/pub/she/ Strathclyde Haskell Enhancement], a preprocessor which (among many other things) translates idiom brackets into standard uses of <code>(<$>)</code> and <code>(<*>)</code>. This can result in much more readable code when making heavy use of <code>Applicative</code>.<br />
<br />
==Alternative formulation==<br />
<br />
An alternative, equivalent formulation of <code>Applicative</code> is given by<br />
<br />
<haskell><br />
class Functor f => Monoidal f where<br />
unit :: f ()<br />
(**) :: f a -> f b -> f (a,b)<br />
</haskell><br />
<br />
{{note|In category-theory speak, we say <code>f</code> is a ''lax'' monoidal functor because there aren't necessarily functions in the other direction, like <code>f (a, b) -> (f a, f b)</code>.}}<br />
Intuitively, this states that a <i>monoidal</i> functor{{noteref}} is one which has some sort of "default shape" and which supports some sort of "combining" operation. <code>pure</code> and <code>(<*>)</code> are equivalent in power to <code>unit</code> and <code>(**)</code> (see the Exercises below). More technically, the idea is that <code>f</code> preserves the "monoidal structure" given by the pairing constructor <code>(,)</code> and unit type <code>()</code>. This can be seen even more clearly if we rewrite the types of <code>unit</code> and <code>(**)</code> as<br />
<haskell><br />
unit' :: () -> f ()<br />
(**') :: (f a, f b) -> f (a, b)<br />
</haskell><br />
<br />
Furthermore, to deserve the name "monoidal" (see the [[#Monoid|section on Monoids]]), instances of <code>Monoidal</code> ought to satisfy the following laws, which seem much more straightforward than the traditional <code>Applicative</code> laws:<br />
<br />
{{note|In this and the following laws, <code>≅</code> refers to <i>isomorphism</i> rather than equality. In particular we consider <code>(x,()) ≅ x ≅ ((),x)</code> and <code>((x,y),z) ≅ (x,(y,z))</code>.}}<br />
* Left identity{{noteref}}: <haskell>unit ** v ≅ v</haskell><br />
* Right identity: <haskell>u ** unit ≅ u</haskell><br />
* Associativity: <haskell>u ** (v ** w) ≅ (u ** v) ** w</haskell><br />
<br />
These turn out to be equivalent to the usual <code>Applicative</code> laws. In a category theory setting, one would also require a naturality law:<br />
<br />
{{note|Here <code>g *** h {{=}} \(x,y) -> (g x, h y)</code>. See [[#Arrow|Arrows]].}}<br />
* Naturality: <haskell>fmap (g *** h) (u ** v) = fmap g u ** fmap h v</haskell><br />
<br />
but in the context of Haskell, this is a free theorem.<br />
<br />
Much of this section was taken from [http://blog.ezyang.com/2012/08/applicative-functors/ a blog post by Edward Z. Yang]; see his actual post for a bit more information.<br />
<br />
{{Exercises|<br />
# Implement <code>pure</code> and <code>(<*>)</code> in terms of <code>unit</code> and <code>(**)</code>, and vice versa.<br />
# Are there any <code>Applicative</code> instances for which there are also functions <code>f () -> ()</code> and <code>f (a,b) -> (f a, f b)</code>, satisfying some "reasonable" laws?<br />
# (Tricky) Prove that given your implementations from the previous exercise, the usual <code>Applicative</code> laws and the <code>Monoidal</code> laws stated above are equivalent.<br />
}}<br />
<br />
==Further reading==<br />
<br />
There are many other useful combinators in the standard libraries implemented in terms of <code>pure</code> and <code>(<*>)</code>: for example, <code>(*>)</code>, <code>(<*)</code>, <code>(<**>)</code>, <code>(<$)</code>, and so on (see [http://hackage.haskell.org/package/base/docs/Control-Applicative.html haddock for Applicative]). Judicious use of such secondary combinators can often make code using <code>Applicative</code>s much easier to read.<br />
<br />
[http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s original paper] is a treasure-trove of information and examples, as well as some perspectives on the connection between <code>Applicative</code> and category theory. Beginners will find it difficult to make it through the entire paper, but it is extremely well-motivated—even beginners will be able to glean something from reading as far as they are able.<br />
<br />
{{note|Introduced by [http://conal.net/papers/simply-reactive/ an earlier paper] that was since superseded by [http://conal.net/papers/push-pull-frp/ Push-pull functional reactive programming].}}<br />
<br />
Conal Elliott has been one of the biggest proponents of <code>Applicative</code>. For example, the [http://conal.net/papers/functional-images/ Pan library for functional images] and the reactive library for functional reactive programming (FRP) {{noteref}} make key use of it; his blog also contains [http://conal.net/blog/tag/applicative-functor many examples of <code>Applicative</code> in action]. Building on the work of McBride and Paterson, Elliott also built the [[TypeCompose]] library, which embodies the observation (among others) that <code>Applicative</code> types are closed under composition; therefore, <code>Applicative</code> instances can often be automatically derived for complex types built out of simpler ones.<br />
<br />
Although the [http://hackage.haskell.org/package/parsec Parsec parsing library] ([http://legacy.cs.uu.nl/daan/download/papers/parsec-paper.pdf paper]) was originally designed for use as a monad, in its most common use cases an <code>Applicative</code> instance can be used to great effect; [http://www.serpentine.com/blog/2008/02/06/the-basics-of-applicative-functors-put-to-practical-work/ Bryan O’Sullivan’s blog post] is a good starting point. If the extra power provided by <code>Monad</code> isn’t needed, it’s usually a good idea to use <code>Applicative</code> instead.<br />
<br />
A couple other nice examples of <code>Applicative</code> in action include the [http://web.archive.org/web/20090416111947/chrisdone.com/blog/html/2009-02-10-applicative-configfile-hsql.html ConfigFile and HSQL libraries] and the [http://groups.inf.ed.ac.uk/links/formlets/ formlets library].<br />
<br />
Gershom Bazerman's [http://comonad.com/reader/2012/abstracting-with-applicatives/ post] contains many insights into applicatives.<br />
<br />
=Monad=<br />
<br />
It’s a safe bet that if you’re reading this, you’ve heard of monads—although it’s quite possible you’ve never heard of <code>Applicative</code> before, or <code>Arrow</code>, or even <code>Monoid</code>. Why are monads such a big deal in Haskell? There are several reasons.<br />
<br />
* Haskell does, in fact, single out monads for special attention by making them the framework in which to construct I/O operations.<br />
* Haskell also singles out monads for special attention by providing a special syntactic sugar for monadic expressions: the <code>do</code>-notation.<br />
* <code>Monad</code> has been around longer than other abstract models of computation such as <code>Applicative</code> or <code>Arrow</code>.<br />
* The more monad tutorials there are, the harder people think monads must be, and the more new monad tutorials are written by people who think they finally “get” monads (the [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ monad tutorial fallacy]).<br />
<br />
I will let you judge for yourself whether these are good reasons.<br />
<br />
In the end, despite all the hoopla, <code>Monad</code> is just another type class. Let’s take a look at its definition.<br />
<br />
==Definition==<br />
<br />
The type class declaration for [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Monad <code>Monad</code>] is:<br />
<br />
<haskell><br />
class Monad m where<br />
return :: a -> m a<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
(>>) :: m a -> m b -> m b<br />
m >> n = m >>= \_ -> n<br />
<br />
fail :: String -> m a<br />
</haskell><br />
<br />
The <code>Monad</code> type class is exported by the <code>Prelude</code>, along with a few standard instances. However, many utility functions are found in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>], and there are also several instances (such as <code>((->) e)</code>) defined in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-Instances.html <code>Control.Monad.Instances</code>].<br />
<br />
{{note|However, as of GHC 7.10 this will be fixed!}}<br />
Let’s examine the methods in the <code>Monad</code> class one by one. The type of <code>return</code> should look familiar; it’s the same as <code>pure</code>. Indeed, <code>return</code> ''is'' <code>pure</code>, but with an unfortunate name. (Unfortunate, since someone coming from an imperative programming background might think that <code>return</code> is like the C or Java keyword of the same name, when in fact the similarities are minimal.) From a mathematical point of view, every monad is an applicative functor, but for historical reasons, the <code>Monad</code> type class declaration unfortunately does not require this.{{noteref}}<br />
<br />
We can see that <code>(>>)</code> is a specialized version of <code>(>>=)</code>, with a default implementation given. It is only included in the type class declaration so that specific instances of <code>Monad</code> can override the default implementation of <code>(>>)</code> with a more efficient one, if desired. Also, note that although <code>_ >> n = n</code> would be a type-correct implementation of <code>(>>)</code>, it would not correspond to the intended semantics: the intention is that <code>m >> n</code> ignores the ''result'' of <code>m</code>, but not its ''effects''.<br />
<br />
The <code>fail</code> function is an awful hack that has no place in the <code>Monad</code> class; more on this later.<br />
<br />
The only really interesting thing to look at—and what makes <code>Monad</code> strictly more powerful than <code>Applicative</code>—is <code>(>>=)</code>, which is often called ''bind''. An alternative definition of <code>Monad</code> could look like:<br />
<br />
<haskell><br />
class Applicative m => Monad' m where<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
</haskell><br />
<br />
We could spend a while talking about the intuition behind <code>(>>=)</code>—and we will. But first, let’s look at some examples.<br />
<br />
==Instances==<br />
<br />
Even if you don’t understand the intuition behind the <code>Monad</code> class, you can still create instances of it by just seeing where the types lead you. You may be surprised to find that this actually gets you a long way towards understanding the intuition; at the very least, it will give you some concrete examples to play with as you read more about the <code>Monad</code> class in general. The first few examples are from the standard <code>Prelude</code>; the remaining examples are from the [http://hackage.haskell.org/package/transformers <code>transformers</code> package].<br />
<br />
<ul><br />
<li>The simplest possible instance of <code>Monad</code> is [http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Monad-Identity.html <code>Identity</code>], which is described in Dan Piponi’s highly recommended blog post on [http://blog.sigfpe.com/2007/04/trivial-monad.html The Trivial Monad]. Despite being “trivial”, it is a great introduction to the <code>Monad</code> type class, and contains some good exercises to get your brain working.<br />
</li><br />
<li>The next simplest instance of <code>Monad</code> is <code>Maybe</code>. We already know how to write <code>return</code>/<code>pure</code> for <code>Maybe</code>. So how do we write <code>(>>=)</code>? Well, let’s think about its type. Specializing for <code>Maybe</code>, we have<br />
<br />
<haskell><br />
(>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b.<br />
</haskell><br />
<br />
If the first argument to <code>(>>=)</code> is <code>Just x</code>, then we have something of type <code>a</code> (namely, <code>x</code>), to which we can apply the second argument—resulting in a <code>Maybe b</code>, which is exactly what we wanted. What if the first argument to <code>(>>=)</code> is <code>Nothing</code>? In that case, we don’t have anything to which we can apply the <code>a -> Maybe b</code> function, so there’s only one thing we can do: yield <code>Nothing</code>. This instance is:<br />
<br />
<haskell><br />
instance Monad Maybe where<br />
return = Just<br />
(Just x) >>= g = g x<br />
Nothing >>= _ = Nothing<br />
</haskell><br />
<br />
We can already get a bit of intuition as to what is going on here: if we build up a computation by chaining together a bunch of functions with <code>(>>=)</code>, as soon as any one of them fails, the entire computation will fail (because <code>Nothing >>= f</code> is <code>Nothing</code>, no matter what <code>f</code> is). The entire computation succeeds only if all the constituent functions individually succeed. So the <code>Maybe</code> monad models computations which may fail.<br />
</li><br />
<br />
<li>The <code>Monad</code> instance for the list constructor <code>[]</code> is similar to its <code>Applicative</code> instance; see the exercise below.<br />
</li><br />
<br />
<li>Of course, the <code>IO</code> constructor is famously a <code>Monad</code>, but its implementation is somewhat magical, and may in fact differ from compiler to compiler. It is worth emphasizing that the <code>IO</code> monad is the ''only'' monad which is magical. It allows us to build up, in an entirely pure way, values representing possibly effectful computations. The special value <code>main</code>, of type <code>IO ()</code>, is taken by the runtime and actually executed, producing actual effects. Every other monad is functionally pure, and requires no special compiler support. We often speak of monadic values as “effectful computations”, but this is because some monads allow us to write code ''as if'' it has side effects, when in fact the monad is hiding the plumbing which allows these apparent side effects to be implemented in a functionally pure way.<br />
</li><br />
<br />
<li>As mentioned earlier, <code>((->) e)</code> is known as the ''reader monad'', since it describes computations in which a value of type <code>e</code> is available as a read-only environment.<br />
<br />
The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Reader.html <code>Control.Monad.Reader</code>] module provides the <code>Reader e a</code> type, which is just a convenient <code>newtype</code> wrapper around <code>(e -> a)</code>, along with an appropriate <code>Monad</code> instance and some <code>Reader</code>-specific utility functions such as <code>ask</code> (retrieve the environment), <code>asks</code> (retrieve a function of the environment), and <code>local</code> (run a subcomputation under a different environment).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Writer-Lazy.html <code>Control.Monad.Writer</code>] module provides the <code>Writer</code> monad, which allows information to be collected as a computation progresses. <code>Writer w a</code> is isomorphic to <code>(a,w)</code>, where the output value <code>a</code> is carried along with an annotation or “log” of type <code>w</code>, which must be an instance of <code>Monoid</code> (see [[#Monoid|section Monoid]]); the special function <code>tell</code> performs logging.<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-State-Lazy.html <code>Control.Monad.State</code>] module provides the <code>State s a</code> type, a <code>newtype</code> wrapper around <code>s -> (a,s)</code>. Something of type <code>State s a</code> represents a stateful computation which produces an <code>a</code> but can access and modify the state of type <code>s</code> along the way. The module also provides <code>State</code>-specific utility functions such as <code>get</code> (read the current state), <code>gets</code> (read a function of the current state), <code>put</code> (overwrite the state), and <code>modify</code> (apply a function to the state).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Cont.html <code>Control.Monad.Cont</code>] module provides the <code>Cont</code> monad, which represents computations in continuation-passing style. It can be used to suspend and resume computations, and to implement non-local transfers of control, co-routines, other complex control structures—all in a functionally pure way. <code>Cont</code> has been called the [http://blog.sigfpe.com/2008/12/mother-of-all-monads.html “mother of all monads”] because of its universal properties.<br />
</li><br />
</ul><br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement a <code>Monad</code> instance for the list constructor, <code>[]</code>. Follow the types!</li><br />
<li>Implement a <code>Monad</code> instance for <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> and <code>Monad</code> instances for <code>Free f</code>, defined as<br />
<haskell><br />
data Free f a = Var a<br />
| Node (f (Free f a))<br />
</haskell><br />
You may assume that <code>f</code> has a <code>Functor</code> instance. This is known as the ''free monad'' built from the functor <code>f</code>.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Intuition==<br />
<br />
Let’s look more closely at the type of <code>(>>=)</code>. The basic intuition is that it combines two computations into one larger computation. The first argument, <code>m a</code>, is the first computation. However, it would be boring if the second argument were just an <code>m b</code>; then there would be no way for the computations to interact with one another (actually, this is exactly the situation with <code>Applicative</code>). So, the second argument to <code>(>>=)</code> has type <code>a -> m b</code>: a function of this type, given a ''result'' of the first computation, can produce a second computation to be run. In other words, <code>x >>= k</code> is a computation which runs <code>x</code>, and then uses the result(s) of <code>x</code> to ''decide'' what computation to run second, using the output of the second computation as the result of the entire computation.<br />
<br />
{{note|Actually, because Haskell allows general recursion, this is a lie: using a Haskell parsing library one can recursively construct ''infinite'' grammars, and hence <code>Applicative</code> (together with <code>Alternative</code>) is enough to parse any context-sensitive language with a finite alphabet. See [http://byorgey.wordpress.com/2012/01/05/parsing-context-sensitive-languages-with-applicative/ Parsing context-sensitive languages with Applicative].}}<br />
Intuitively, it is this ability to use the output from previous computations to decide what computations to run next that makes <code>Monad</code> more powerful than <code>Applicative</code>. The structure of an <code>Applicative</code> computation is fixed, whereas the structure of a <code>Monad</code> computation can change based on intermediate results. This also means that parsers built using an <code>Applicative</code> interface can only parse context-free languages; in order to parse context-sensitive languages a <code>Monad</code> interface is needed.{{noteref}}<br />
<br />
To see the increased power of <code>Monad</code> from a different point of view, let’s see what happens if we try to implement <code>(>>=)</code> in terms of <code>fmap</code>, <code>pure</code>, and <code>(<*>)</code>. We are given a value <code>x</code> of type <code>m a</code>, and a function <code>k</code> of type <code>a -> m b</code>, so the only thing we can do is apply <code>k</code> to <code>x</code>. We can’t apply it directly, of course; we have to use <code>fmap</code> to lift it over the <code>m</code>. But what is the type of <code>fmap k</code>? Well, it’s <code>m a -> m (m b)</code>. So after we apply it to <code>x</code>, we are left with something of type <code>m (m b)</code>—but now we are stuck; what we really want is an <code>m b</code>, but there’s no way to get there from here. We can ''add'' <code>m</code>’s using <code>pure</code>, but we have no way to ''collapse'' multiple <code>m</code>’s into one.<br />
<br />
{{note|1=You might hear some people claim that that the definition in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> is the “math definition” and the definition in terms of <code>return</code> and <code>(>>=)</code> is something specific to Haskell. In fact, both definitions were known in the mathematics community long before Haskell picked up monads.}}<br />
<br />
This ability to collapse multiple <code>m</code>’s is exactly the ability provided by the function <code>join :: m (m a) -> m a</code>, and it should come as no surprise that an alternative definition of <code>Monad</code> can be given in terms of <code>join</code>:<br />
<br />
<haskell><br />
class Applicative m => Monad'' m where<br />
join :: m (m a) -> m a<br />
</haskell><br />
<br />
In fact, the canonical definition of monads in category theory is in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> (often called <math>\eta</math>, <math>T</math>, and <math>\mu</math> in the mathematical literature). Haskell uses an alternative formulation with <code>(>>=)</code> instead of <code>join</code> since it is more convenient to use {{noteref}}. However, sometimes it can be easier to think about <code>Monad</code> instances in terms of <code>join</code>, since it is a more “atomic” operation. (For example, <code>join</code> for the list monad is just <code>concat</code>.)<br />
<br />
{{Exercises|<br />
# Implement <code>(>>{{=}})</code> in terms of <code>fmap</code> (or <code>liftM</code>) and <code>join</code>.<br />
# Now implement <code>join</code> and <code>fmap</code> (<code>liftM</code>) in terms of <code>(>>{{=}})</code> and <code>return</code>.<br />
}}<br />
<br />
==Utility functions==<br />
<br />
The [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>] module provides a large number of convenient utility functions, all of which can be implemented in terms of the basic <code>Monad</code> operations (<code>return</code> and <code>(>>=)</code> in particular). We have already seen one of them, namely, <code>join</code>. We also mention some other noteworthy ones here; implementing these utility functions oneself is a good exercise. For a more detailed guide to these functions, with commentary and example code, see Henk-Jan van Tuyl’s [http://members.chello.nl/hjgtuyl/tourdemonad.html tour].<br />
<br />
{{note|This will most likely change in Haskell 2014 with the implementation of the [[Functor-Applicative-Monad_Proposal|Haskell 2014 Applicative => Monad proposal]].}}<br />
<br />
* <code>liftM :: Monad m => (a -> b) -> m a -> m b</code>. This should be familiar; of course, it is just <code>fmap</code>. The fact that we have both <code>fmap</code> and <code>liftM</code> is an unfortunate consequence of the fact that the <code>Monad</code> type class does not require a <code>Functor</code> instance, even though mathematically speaking, every monad is a functor. However, <code>fmap</code> and <code>liftM</code> are essentially interchangeable, since it is a bug (in a social rather than technical sense) for any type to be an instance of <code>Monad</code> without also being an instance of <code>Functor</code> {{noteref}}.<br />
<br />
* <code>ap :: Monad m => m (a -> b) -> m a -> m b</code> should also be familiar: it is equivalent to <code>(<*>)</code>, justifying the claim that the <code>Monad</code> interface is strictly more powerful than <code>Applicative</code>. We can make any <code>Monad</code> into an instance of <code>Applicative</code> by setting <code>pure = return</code> and <code>(<*>) = ap</code>.<br />
<br />
* <code>sequence :: Monad m => [m a] -> m [a]</code> takes a list of computations and combines them into one computation which collects a list of their results. It is again something of a historical accident that <code>sequence</code> has a <code>Monad</code> constraint, since it can actually be implemented only in terms of <code>Applicative</code>. There is an additional generalization of <code>sequence</code> to structures other than lists, which will be discussed in the [[#Traversable|section on <code>Traversable</code>]].<br />
<br />
* <code>replicateM :: Monad m => Int -> m a -> m [a]</code> is simply a combination of [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:replicate <code>replicate</code>] and <code>sequence</code>.<br />
<br />
* <code>when :: Monad m => Bool -> m () -> m ()</code> conditionally executes a computation, evaluating to its second argument if the test is <code>True</code>, and to <code>return ()</code> if the test is <code>False</code>. A collection of other sorts of monadic conditionals can be found in the [http://hackage.haskell.org/package/IfElse <code>IfElse</code> package].<br />
<br />
* <code>mapM :: Monad m => (a -> m b) -> [a] -> m [b]</code> maps its first argument over the second, and <code>sequence</code>s the results. The <code>forM</code> function is just <code>mapM</code> with its arguments reversed; it is called <code>forM</code> since it models generalized <code>for</code> loops: the list <code>[a]</code> provides the loop indices, and the function <code>a -> m b</code> specifies the “body” of the loop for each index.<br />
<br />
* <code>(=<<) :: Monad m => (a -> m b) -> m a -> m b</code> is just <code>(>>=)</code> with its arguments reversed; sometimes this direction is more convenient since it corresponds more closely to function application.<br />
<br />
* <code>(>=>) :: Monad m => (a -> m b) -> (b -> m c) -> a -> m c</code> is sort of like function composition, but with an extra <code>m</code> on the result type of each function, and the arguments swapped. We’ll have more to say about this operation later. There is also a flipped variant, <code>(<=<)</code>.<br />
<br />
* The <code>guard</code> function is for use with instances of <code>MonadPlus</code>, which is discussed at the end of the [[#Monoid|<code>Monoid</code> section]].<br />
<br />
Many of these functions also have “underscored” variants, such as <code>sequence_</code> and <code>mapM_</code>; these variants throw away the results of the computations passed to them as arguments, using them only for their side effects.<br />
<br />
Other monadic functions which are occasionally useful include <code>filterM</code>, <code>zipWithM</code>, <code>foldM</code>, and <code>forever</code>.<br />
<br />
==Laws==<br />
<br />
There are several laws that instances of <code>Monad</code> should satisfy (see also the [[Monad laws]] wiki page). The standard presentation is:<br />
<br />
<haskell><br />
return a >>= k = k a<br />
m >>= return = m<br />
m >>= (\x -> k x >>= h) = (m >>= k) >>= h<br />
<br />
fmap f xs = xs >>= return . f = liftM f xs<br />
</haskell><br />
<br />
The first and second laws express the fact that <code>return</code> behaves nicely: if we inject a value <code>a</code> into a monadic context with <code>return</code>, and then bind to <code>k</code>, it is the same as just applying <code>k</code> to <code>a</code> in the first place; if we bind a computation <code>m</code> to <code>return</code>, nothing changes. The third law essentially says that <code>(>>=)</code> is associative, sort of. The last law ensures that <code>fmap</code> and <code>liftM</code> are the same for types which are instances of both <code>Functor</code> and <code>Monad</code>—which, as already noted, should be every instance of <code>Monad</code>.<br />
<br />
{{note|I like to pronounce this operator “fish”.}}<br />
<br />
However, the presentation of the above laws, especially the third, is marred by the asymmetry of <code>(>>=)</code>. It’s hard to look at the laws and see what they’re really saying. I prefer a much more elegant version of the laws, which is formulated in terms of <code>(>=>)</code> {{noteref}}. Recall that <code>(>=>)</code> “composes” two functions of type <code>a -> m b</code> and <code>b -> m c</code>. You can think of something of type <code>a -> m b</code> (roughly) as a function from <code>a</code> to <code>b</code> which may also have some sort of effect in the context corresponding to <code>m</code>. <code>(>=>)</code> lets us compose these “effectful functions”, and we would like to know what properties <code>(>=>)</code> has. The monad laws reformulated in terms of <code>(>=>)</code> are:<br />
<br />
<haskell><br />
return >=> g = g<br />
g >=> return = g<br />
(g >=> h) >=> k = g >=> (h >=> k)<br />
</haskell><br />
<br />
{{note|As fans of category theory will note, these laws say precisely that functions of type <code>a -> m b</code> are the arrows of a category with <code>(>{{=}}>)</code> as composition! Indeed, this is known as the ''Kleisli category'' of the monad <code>m</code>. It will come up again when we discuss <code>Arrow</code>s.}}<br />
<br />
Ah, much better! The laws simply state that <code>return</code> is the identity of <code>(>=>)</code>, and that <code>(>=>)</code> is associative {{noteref}}.<br />
<br />
There is also a formulation of the monad laws in terms of <code>fmap</code>, <code>return</code>, and <code>join</code>; for a discussion of this formulation, see the Haskell [http://en.wikibooks.org/wiki/Haskell/Category_theory wikibook page on category theory].<br />
<br />
{{Exercises|<br />
# Given the definition <code>g >{{=}}> h {{=}} \x -> g x >>{{=}} h</code>, prove the equivalence of the above laws and the usual monad laws.<br />
}}<br />
<br />
==<code>do</code> notation==<br />
<br />
Haskell’s special <code>do</code> notation supports an “imperative style” of programming by providing syntactic sugar for chains of monadic expressions. The genesis of the notation lies in realizing that something like <code>a >>= \x -> b >> c >>= \y -> d </code> can be more readably written by putting successive computations on separate lines:<br />
<br />
<haskell><br />
a >>= \x -><br />
b >><br />
c >>= \y -><br />
d<br />
</haskell><br />
<br />
This emphasizes that the overall computation consists of four computations <code>a</code>, <code>b</code>, <code>c</code>, and <code>d</code>, and that <code>x</code> is bound to the result of <code>a</code>, and <code>y</code> is bound to the result of <code>c</code> (<code>b</code>, <code>c</code>, and <code>d</code> are allowed to refer to <code>x</code>, and <code>d</code> is allowed to refer to <code>y</code> as well). From here it is not hard to imagine a nicer notation:<br />
<br />
<haskell><br />
do { x <- a<br />
; b<br />
; y <- c<br />
; d<br />
}<br />
</haskell><br />
<br />
(The curly braces and semicolons may optionally be omitted; the Haskell parser uses layout to determine where they should be inserted.) This discussion should make clear that <code>do</code> notation is just syntactic sugar. In fact, <code>do</code> blocks are recursively translated into monad operations (almost) like this:<br />
<br />
<pre><br />
do e → e<br />
do { e; stmts } → e >> do { stmts }<br />
do { v <- e; stmts } → e >>= \v -> do { stmts }<br />
do { let decls; stmts} → let decls in do { stmts }<br />
</pre><br />
<br />
This is not quite the whole story, since <code>v</code> might be a pattern instead of a variable. For example, one can write<br />
<br />
<haskell><br />
do (x:xs) <- foo<br />
bar x<br />
</haskell><br />
<br />
but what happens if <code>foo</code> produces an empty list? Well, remember that ugly <code>fail</code> function in the <code>Monad</code> type class declaration? That’s what happens. See [http://www.haskell.org/onlinereport/exps.html#sect3.14 section 3.14 of the Haskell Report] for the full details. See also the discussion of <code>MonadPlus</code> and <code>MonadZero</code> in the [[#Other monoidal classes: Alternative, MonadPlus, ArrowPlus|section on other monoidal classes]].<br />
<br />
A final note on intuition: <code>do</code> notation plays very strongly to the “computational context” point of view rather than the “container” point of view, since the binding notation <code>x <- m</code> is suggestive of “extracting” a single <code>x</code> from <code>m</code> and doing something with it. But <code>m</code> may represent some sort of a container, such as a list or a tree; the meaning of <code>x <- m</code> is entirely dependent on the implementation of <code>(>>=)</code>. For example, if <code>m</code> is a list, <code>x <- m</code> actually means that <code>x</code> will take on each value from the list in turn.<br />
<br />
==Further reading==<br />
<br />
Philip Wadler was the first to propose using monads to structure functional programs. [http://homepages.inf.ed.ac.uk/wadler/topics/monads.html His paper] is still a readable introduction to the subject.<br />
<br />
{{note|1=<br />
[[All About Monads]],<br />
[http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers],<br />
[http://en.wikibooks.org/w/index.php?title=Haskell/Understanding_monads Understanding monads],<br />
[[The Monadic Way]],<br />
[http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads! (And Maybe You Already Have.)],<br />
[http://www.haskell.org/pipermail/haskell-cafe/2006-November/019190.html there’s a monster in my Haskell!],<br />
[http://kawagner.blogspot.com/2007/02/understanding-monads-for-real.html Understanding Monads. For real.],<br />
[http://www.randomhacks.net/articles/2007/03/12/monads-in-15-minutes Monads in 15 minutes: Backtracking and Maybe],<br />
[http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation],<br />
[http://metafoo.co.uk/practical-monads.txt Practical Monads]}}<br />
<br />
There are, of course, numerous monad tutorials of varying quality {{noteref}}.<br />
<br />
A few of the best include Cale Gibbard’s [http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers] and [http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation]; Jeff Newbern’s [[All About Monads]], a comprehensive guide with lots of examples; and Dan Piponi’s [http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads!], which features great exercises. If you just want to know how to use <code>IO</code>, you could consult the [[Introduction to IO]]. Even this is just a sampling; the [[monad tutorials timeline]] is a more complete list. (All these monad tutorials have prompted parodies like [http://koweycode.blogspot.com/2007/01/think-of-monad.html think of a monad ...] as well as other kinds of backlash like [http://ahamsandwich.wordpress.com/2007/07/26/monads-and-why-monad-tutorials-are-all-awful/ Monads! (and Why Monad Tutorials Are All Awful)] or [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Abstraction, intuition, and the “monad tutorial fallacy”].)<br />
<br />
Other good monad references which are not necessarily tutorials include [http://members.chello.nl/hjgtuyl/tourdemonad.html Henk-Jan van Tuyl’s tour] of the functions in <code>Control.Monad</code>, Dan Piponi’s [http://blog.sigfpe.com/2006/10/monads-field-guide.html field guide], Tim Newsham’s [http://www.thenewsh.com/~newsham/haskell/monad.html What’s a Monad?], and Chris Smith's excellent article [http://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/ Why Do Monads Matter?]. There are also many blog posts which have been written on various aspects of monads; a collection of links can be found under [[Blog articles/Monads]].<br />
<br />
For help constructing monads from scratch, and for obtaining a "deep embedding" of monad operations suitable for use in, say, compiling a domain-specific language, see [http://projects.haskell.org/operational Apfelmus's operational package].<br />
<br />
One of the quirks of the <code>Monad</code> class and the Haskell type system is that it is not possible to straightforwardly declare <code>Monad</code> instances for types which require a class constraint on their data, even if they are monads from a mathematical point of view. For example, <code>Data.Set</code> requires an <code>Ord</code> constraint on its data, so it cannot be easily made an instance of <code>Monad</code>. A solution to this problem was [http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros first described by Eric Kidd], and later made into a [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmonad library named rmonad] by Ganesh Sittampalam and Peter Gavin.<br />
<br />
There are many good reasons for eschewing <code>do</code> notation; some have gone so far as to [[Do_notation_considered_harmful|consider it harmful]].<br />
<br />
Monads can be generalized in various ways; for an exposition of one possibility, see Robert Atkey’s paper on [http://homepages.inf.ed.ac.uk/ratkey/paramnotions-jfp.pdf parameterized monads], or Dan Piponi’s [http://blog.sigfpe.com/2009/02/beyond-monads.html Beyond Monads].<br />
<br />
For the categorically inclined, monads can be viewed as monoids ([http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html From Monoids to Monads]) and also as closure operators [http://blog.plover.com/math/monad-closure.html Triples and Closure]. Derek Elkins’ article in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13 of the Monad.Reader] contains an exposition of the category-theoretic underpinnings of some of the standard <code>Monad</code> instances, such as <code>State</code> and <code>Cont</code>. Jonathan Hill and Keith Clarke have [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.6497 an early paper explaining the connection between monads as they arise in category theory and as used in functional programming]. There is also a [http://okmij.org/ftp/Computation/IO-monad-history.html web page by Oleg Kiselyov] explaining the history of the IO monad.<br />
<br />
Links to many more research papers related to monads can be found under [[Research papers/Monads and arrows]].<br />
<br />
=Monad transformers=<br />
<br />
One would often like to be able to combine two monads into one: for example, to have stateful, nondeterministic computations (<code>State</code> + <code>[]</code>), or computations which may fail and can consult a read-only environment (<code>Maybe</code> + <code>Reader</code>), and so on. Unfortunately, monads do not compose as nicely as applicative functors (yet another reason to use <code>Applicative</code> if you don’t need the full power that <code>Monad</code> provides), but some monads can be combined in certain ways.<br />
<br />
==Standard monad transformers==<br />
<br />
The [http://hackage.haskell.org/package/transformers transformers] library provides a number of standard ''monad transformers''. Each monad transformer adds a particular capability/feature/effect to any existing monad.<br />
<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Identity.html <code>IdentityT</code>] is the identity transformer, which maps a monad to (something isomorphic to) itself. This may seem useless at first glance, but it is useful for the same reason that the <code>id</code> function is useful -- it can be passed as an argument to things which are parameterized over an arbitrary monad transformer, when you do not actually want any extra capabilities.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-State.html <code>StateT</code>] adds a read-write state.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Reader.html <code>ReaderT</code>] adds a read-only environment.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Writer.html <code>WriterT</code>] adds a write-only log.<br />
* [http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-RWS.html <code>RWST</code>] conveniently combines <code>ReaderT</code>, <code>WriterT</code>, and <code>StateT</code> into one.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Maybe.html <code>MaybeT</code>] adds the possibility of failure.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Error.html <code>ErrorT</code>] adds the possibility of failure with an arbitrary type to represent errors.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-List.html <code>ListT</code>] adds non-determinism (however, see the discussion of <code>ListT</code> below).<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Cont.html <code>ContT</code>] adds continuation handling.<br />
<br />
For example, <code>StateT s Maybe</code> is an instance of <code>Monad</code>; computations of type <code>StateT s Maybe a</code> may fail, and have access to a mutable state of type <code>s</code>. Monad transformers can be multiply stacked. One thing to keep in mind while using monad transformers is that the order of composition matters. For example, when a <code>StateT s Maybe a</code> computation fails, the state ceases being updated (indeed, it simply disappears); on the other hand, the state of a <code>MaybeT (State s) a</code> computation may continue to be modified even after the computation has "failed". This may seem backwards, but it is correct. Monad transformers build composite monads “inside out”; <code>MaybeT (State s) a</code> is isomorphic to <code>s -> (Maybe a, s)</code>. (Lambdabot has an indispensable <code>@unmtl</code> command which you can use to “unpack” a monad transformer stack in this way.)<br />
Intuitively, the monads become "more fundamental" the further inside the stack you get, and the effects of inner monads "have precedence" over the effects of outer ones. Of course, this is just handwaving, and if you are unsure of the proper order for some monads you wish to combine, there is no substitute for using <code>@unmtl</code> or simply trying out the various options.<br />
<br />
==Definition and laws==<br />
<br />
All monad transformers should implement the <code>MonadTrans</code> type class, defined in <code>Control.Monad.Trans.Class</code>:<br />
<br />
<haskell><br />
class MonadTrans t where<br />
lift :: Monad m => m a -> t m a<br />
</haskell><br />
<br />
It allows arbitrary computations in the base monad <code>m</code> to be “lifted” into computations in the transformed monad <code>t m</code>. (Note that type application associates to the left, just like function application, so <code>t m a = (t m) a</code>.)<br />
<br />
<code>lift</code> must satisfy the laws<br />
<haskell><br />
lift . return = return<br />
lift (m >>= f) = lift m >>= (lift . f)<br />
</haskell><br />
which intuitively state that <code>lift</code> transforms <code>m a</code> computations into <code>t m a</code> computations in a "sensible" way, which sends the <code>return</code> and <code>(>>=)</code> of <code>m</code> to the <code>return</code> and <code>(>>=)</code> of <code>t m</code>.<br />
<br />
{{Exercises|<br />
# What is the kind of <code>t</code> in the declaration of <code>MonadTrans</code>?<br />
}}<br />
<br />
==Transformer type classes and "capability" style==<br />
<br />
{{note|The only problem with this scheme is the quadratic number of instances required as the number of standard monad transformers grows—but as the current set of standard monad transformers seems adequate for most common use cases, this may not be that big of a deal.}}<br />
<br />
There are also type classes (provided by the [http://hackage.haskell.org/package/mtl <code>mtl</code> package]) for the operations of each transformer. For example, the <code>MonadState</code> type class provides the state-specific methods <code>get</code> and <code>put</code>, allowing you to conveniently use these methods not only with <code>State</code>, but with any monad which is an instance of <code>MonadState</code>—including <code>MaybeT (State s)</code>, <code>StateT s (ReaderT r IO)</code>, and so on. Similar type classes exist for <code>Reader</code>, <code>Writer</code>, <code>Cont</code>, <code>IO</code>, and others {{noteref}}.<br />
<br />
These type classes serve two purposes. First, they get rid of (most of) the need for explicitly using <code>lift</code>, giving a type-directed way to automatically determine the right number of calls to <code>lift</code>. Simply writing <code>put</code> will be automatically translated into <code>lift . put</code>, <code>lift . lift . put</code>, or something similar depending on what concrete monad stack you are using.<br />
<br />
Second, they give you more flexibility to switch between different concrete monad stacks. For example, if you are writing a state-based algorithm, don't write<br />
<haskell><br />
foo :: State Int Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
but rather<br />
<haskell><br />
foo :: MonadState Int m => m Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
Now, if somewhere down the line you realize you need to introduce the possibility of failure, you might switch from <code>State Int</code> to <code>MaybeT (State Int)</code>. The type of the first version of <code>foo</code> would need to be modified to reflect this change, but the second version of <code>foo</code> can still be used as-is.<br />
<br />
However, this sort of "capability-based" style (<i>e.g.</i> specifying that <code>foo</code> works for any monad with the "state capability") quickly runs into problems when you try to naively scale it up: for example, what if you need to maintain two independent states? A framework for solving this and related problems is described by Schrijvers and Olivera ([http://users.ugent.be/~tschrijv/Research/papers/icfp2011.pdf Monads, zippers and views: virtualizing the monad stack, ICFP 2011]) and is implemented in the [http://hackage.haskell.org/package/Monatron <code>Monatron</code> package].<br />
<br />
==Composing monads==<br />
<br />
Is the composition of two monads always a monad? As hinted previously, the answer is no.<br />
<br />
Since <code>Applicative</code> functors are closed under composition, the problem must lie with <code>join</code>. Indeed, suppose <code>m</code> and <code>n</code> are arbitrary monads; to make a monad out of their composition we would need to be able to implement<br />
<haskell><br />
join :: m (n (m (n a))) -> m (n a)<br />
</haskell><br />
but it is not clear how this could be done in general. The <code>join</code> method for <code>m</code> is no help, because the two occurrences of <code>m</code> are not next to each other (and likewise for <code>n</code>).<br />
<br />
However, one situation in which it can be done is if <code>n</code> ''distributes'' over <code>m</code>, that is, if there is a function<br />
<haskell><br />
distrib :: n (m a) -> m (n a)<br />
</haskell><br />
satisfying certain laws. See Jones and Duponcheel ([http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.2605 Composing Monads]); see also the [[#Traversable|section on Traversable]].<br />
<br />
For a much more in-depth discussion and analysis of the failure of monads to be closed under composition, see [http://stackoverflow.com/questions/13034229/concrete-example-showing-that-monads-are-not-closed-under-composition-with-proo?lq=1 this question on StackOverflow].<br />
<br />
{{Exercises|<br />
* Implement <code>join :: M (N (M (N a))) -> M (N a)</code>, given <code>distrib :: N (M a) -> M (N a)</code> and assuming <code>M</code> and <code>N</code> are instances of <code>Monad</code>.<br />
}}<br />
<br />
==Further reading==<br />
<br />
Much of the monad transformer library (originally [http://hackage.haskell.org/package/mtl <code>mtl</code>], now split between <code>mtl</code> and [http://hackage.haskell.org/package/transformers <code>transformers</code>]), including the <code>Reader</code>, <code>Writer</code>, <code>State</code>, and other monads, as well as the monad transformer framework itself, was inspired by Mark Jones’ classic paper [http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Functional Programming with Overloading and Higher-Order Polymorphism]. It’s still very much worth a read—and highly readable—after almost fifteen years.<br />
<br />
See [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17139 Edward Kmett's mailing list message] for a description of the history and relationships among monad transformer packages (<code>mtl</code>, <code>transformers</code>, <code>monads-fd</code>, <code>monads-tf</code>).<br />
<br />
There are two excellent references on monad transformers. Martin Grabmüller’s [http://www.grabmueller.de/martin/www/pub/Transformers.en.html Monad Transformers Step by Step] is a thorough description, with running examples, of how to use monad transformers to elegantly build up computations with various effects. [http://cale.yi.org/index.php/How_To_Use_Monad_Transformers Cale Gibbard’s article] on how to use monad transformers is more practical, describing how to structure code using monad transformers to make writing it as painless as possible. Another good starting place for learning about monad transformers is a [http://blog.sigfpe.com/2006/05/grok-haskell-monad-transformers.html blog post by Dan Piponi].<br />
<br />
The <code>ListT</code> transformer from the <code>transformers</code> package comes with the caveat that <code>ListT m</code> is only a monad when <code>m</code> is ''commutative'', that is, when <code>ma >>= \a -> mb >>= \b -> foo</code> is equivalent to <code>mb >>= \b -> ma >>= \a -> foo</code> (i.e. the order of <code>m</code>'s effects does not matter). For one explanation why, see Dan Piponi's blog post [http://blog.sigfpe.com/2006/11/why-isnt-listt-monad.html "Why isn't <code><nowiki>ListT []</nowiki></code> a monad"]. For more examples, as well as a design for a version of <code>ListT</code> which does not have this problem, see [http://www.haskell.org/haskellwiki/ListT_done_right <code>ListT</code> done right].<br />
<br />
There is an alternative way to compose monads, using coproducts, as described by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.3581 Lüth and Ghani]. This method is interesting but has not (yet?) seen widespread use. For a more recent alternative, see Kiselyov et al's [http://okmij.org/ftp/Haskell/extensible/exteff.pdf Extensible Effects: An Alternative to Monad Transformers].<br />
<br />
=MonadFix=<br />
<br />
''Note: <code>MonadFix</code> is included here for completeness (and because it is interesting) but seems not to be used much. Skipping this section on a first read-through is perfectly OK (and perhaps even recommended).''<br />
<br />
==<code>mdo</code>/<code>do rec</code> notation==<br />
<br />
{{note|In GHC 7.6, the flag has been changed to <code>-XRecursiveDo</code>.}}<br />
The <code>MonadFix</code> class describes monads which support the special fixpoint operation <code>mfix :: (a -> m a) -> m a</code>, which allows the output of monadic computations to be defined via (effectful) recursion. This is [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation supported in GHC] by a special “recursive do” notation, enabled by the <code>-XDoRec</code> flag{{noteref}}. Within a <code>do</code> block, one may have a nested <code>rec</code> block, like so:<br />
<haskell><br />
do { x <- foo<br />
; rec { y <- baz<br />
; z <- bar<br />
; bob<br />
}<br />
; w <- frob<br />
}<br />
</haskell><br />
Normally (if we had <code>do</code> in place of <code>rec</code> in the above example), <code>y</code> would be in scope in <code>bar</code> and <code>bob</code> but not in <code>baz</code>, and <code>z</code> would be in scope only in <code>bob</code>. With the <code>rec</code>, however, <code>y</code> and <code>z</code> are both in scope in all three of <code>baz</code>, <code>bar</code>, and <code>bob</code>. A <code>rec</code> block is analogous to a <code>let</code> block such as<br />
<haskell><br />
let { y = baz<br />
; z = bar<br />
}<br />
in bob<br />
</haskell><br />
because, in Haskell, every variable bound in a <code>let</code>-block is in scope throughout the entire block. (From this point of view, Haskell's normal <code>do</code> blocks are analogous to Scheme's <code>let*</code> construct.)<br />
<br />
What could such a feature be used for? One of the motivating examples given in the original paper describing <code>MonadFix</code> (see below) is encoding circuit descriptions. A line in a <code>do</code>-block such as <br />
<haskell><br />
x <- gate y z<br />
</haskell><br />
describes a gate whose input wires are labeled <code>y</code> and <code>z</code> and whose output wire is labeled <code>x</code>. Many (most?) useful circuits, however, involve some sort of feedback loop, making them impossible to write in a normal <code>do</code>-block (since some wire would have to be mentioned as an input ''before'' being listed as an output). Using a <code>rec</code> block solves this problem.<br />
<br />
==Examples and intuition==<br />
<br />
Of course, not every monad supports such recursive binding. However, as mentioned above, it suffices to have an implementation of <code>mfix :: (a -> m a) -> m a</code>, satisfying a few laws. Let's try implementing <code>mfix</code> for the <code>Maybe</code> monad. That is, we want to implement a function<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
</haskell><br />
{{note|Actually, <code>fix</code> is implemented slightly differently for efficiency reasons; but the given definition is equivalent and simpler for the present purpose.}}<br />
Let's think for a moment about the implementation {{noteref}} of the non-monadic <code>fix :: (a -> a) -> a</code>:<br />
<haskell><br />
fix f = f (fix f)<br />
</haskell><br />
Inspired by <code>fix</code>, our first attempt at implementing <code>maybeFix</code> might be something like<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = maybeFix f >>= f<br />
</haskell><br />
This has the right type. However, something seems wrong: there is nothing in particular here about <code>Maybe</code>; <code>maybeFix</code> actually has the more general type <code>Monad m => (a -> m a) -> m a</code>. But didn't we just say that not all monads support <code>mfix</code>?<br />
<br />
The answer is that although this implementation of <code>maybeFix</code> has the right type, it does ''not'' have the intended semantics. If we think about how <code>(>>=)</code> works for the <code>Maybe</code> monad (by pattern-matching on its first argument to see whether it is <code>Nothing</code> or <code>Just</code>) we can see that this definition of <code>maybeFix</code> is completely useless: it will just recurse infinitely, trying to decide whether it is going to return <code>Nothing</code> or <code>Just</code>, without ever even so much as a glance in the direction of <code>f</code>.<br />
<br />
The trick is to simply ''assume'' that <code>maybeFix</code> will return <code>Just</code>, and get on with life!<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = ma<br />
where ma = f (fromJust ma)<br />
</haskell><br />
This says that the result of <code>maybeFix</code> is <code>ma</code>, and assuming that <code>ma = Just x</code>, it is defined (recursively) to be equal to <code>f x</code>.<br />
<br />
Why is this OK? Isn't <code>fromJust</code> almost as bad as <code>unsafePerformIO</code>? Well, usually, yes. This is just about the only situation in which it is justified! The interesting thing to note is that <code>maybeFix</code> ''will never crash'' -- although it may, of course, fail to terminate. The only way we could get a crash is if we try to evaluate <code>fromJust ma</code> when we know that <code>ma = Nothing</code>. But how could we know <code>ma = Nothing</code>? Since <code>ma</code> is defined as <code>f (fromJust ma)</code>, it must be that this expression has already been evaluated to <code>Nothing</code> -- in which case there is no reason for us to be evaluating <code>fromJust ma</code> in the first place! <br />
<br />
To see this from another point of view, we can consider three possibilities. First, if <code>f</code> outputs <code>Nothing</code> without looking at its argument, then <code>maybeFix f</code> clearly returns <code>Nothing</code>. Second, if <code>f</code> always outputs <code>Just x</code>, where <code>x</code> depends on its argument, then the recursion can proceed usefully: <code>fromJust ma</code> will be able to evaluate to <code>x</code>, thus feeding <code>f</code>'s output back to it as input. Third, if <code>f</code> tries to use its argument to decide whether to output <code>Just</code> or <code>Nothing</code>, then <code>maybeFix f</code> will not terminate: evaluating <code>f</code>'s argument requires evaluating <code>ma</code> to see whether it is <code>Just</code>, which requires evaluating <code>f (fromJust ma)</code>, which requires evaluating <code>ma</code>, ... and so on.<br />
<br />
There are also instances of <code>MonadFix</code> for lists (which works analogously to the instance for <code>Maybe</code>), for <code>ST</code>, and for <code>IO</code>. The [http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/System-IO.html#fixIO instance for <code>IO</code>] is particularly amusing: it creates a new (empty) <code>MVar</code>, immediately reads its contents using <code>unsafeInterleaveIO</code> (which delays the actual reading lazily until the value is needed), uses the contents of the <code>MVar</code> to compute a new value, which it then writes back into the <code>MVar</code>. It almost seems, spookily, that <code>mfix</code> is sending a value back in time to itself through the <code>MVar</code> -- though of course what is really going on is that the reading is delayed just long enough (via <code>unsafeInterleaveIO</code>) to get the process bootstrapped.<br />
<br />
{{Exercises|<br />
* Implement a <code>MonadFix</code> instance for <code>[]</code>.<br />
}}<br />
<br />
==GHC 7.6 changes==<br />
<br />
GHC 7.6 reinstated the old <code>mdo</code> syntax, so the example at the start of this section can be written<br />
<br />
<haskell><br />
mdo { x <- foo<br />
; y <- baz<br />
; z <- bar<br />
; bob<br />
; w <- frob<br />
}<br />
</haskell><br />
<br />
which will be translated into the original example (assuming that, say, <code>bar</code> and <code>bob</code> refer to <code>y</code>. The difference is that <code>mdo</code> will analyze the code in order to find minimal recursive blocks, which will be placed in <code>rec</code> blocks, whereas <code>rec</code> blocks desugar directly into calls to <code>mfix</code> without any further analysis. <br />
==Further reading==<br />
<br />
For more information (such as the precise desugaring rules for <code>rec</code> blocks), see Levent Erkök and John Launchbury's 2002 Haskell workshop paper, [http://sites.google.com/site/leventerkok/recdo.pdf?attredirects=0 A Recursive do for Haskell], or for full details, Levent Erkök’s thesis, [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.15.1543&rep=rep1&type=pdf Value Recursion in Monadic Computations]. (Note, while reading, that <code>MonadFix</code> used to be called <code>MonadRec</code>.) You can also read the [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation GHC user manual section on recursive do-notation].<br />
<br />
=Semigroup=<br />
<br />
A semigroup is a set <math>S\ </math> together with a binary operation <math>\oplus\ </math> which<br />
combines elements from <math>S\ </math>. The <math>\oplus\ </math> operator is required to be associative<br />
(that is, <math>(a \oplus b) \oplus c = a \oplus (b \oplus c)\ </math>, for any<br />
<math>a,b,c\ </math> which are elements of <math>S\ </math>).<br />
<br />
For example, the natural numbers under addition form a semigroup: the sum of any two natural numbers is a natural number, and <math>(a+b)+c = a+(b+c)\ </math> for any natural numbers <math>a\ </math>, <math>b\ </math>, and <math>c\,\ </math>. The integers under multiplication also form a semigroup, as do the integers (or rationals, or reals) under <math>\max\ </math> or <math>\min\ </math>, Boolean values under conjunction and disjunction, lists under concatenation, functions from a set to itself under composition ... Semigroups show up all over the place, once you know to look for them.<br />
<br />
==Definition==<br />
<br />
Semigroups are not (yet?) defined in the base package, but the {{HackagePackage|id=semigroups}} package provides a standard definition.<br />
<br />
The definition of the <code>Semigroup</code> type class ([http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock]) is as follows:<br />
<br />
<haskell><br />
class Semigroup a where<br />
(<>) :: a -> a -> a<br />
<br />
sconcat :: NonEmpty a -> a<br />
sconcat = sconcat (a :| as) = go a as where<br />
go b (c:cs) = b <> go c cs<br />
go b [] = b<br />
<br />
times1p :: Whole n => n -> a -> a<br />
times1p = ...<br />
</haskell><br />
<br />
The really important method is <code>(<>)</code>, representing the associative binary operation. The other two methods have default implementations in terms of <code>(<>)</code>, and are included in the type class in case some instances can give more efficient implementations than the default. <code>sconcat</code> reduces a nonempty list using <code>(<>)</code>; <code>times1p n</code> is equivalent to (but more efficient than) <code>sconcat . replicate n</code>. See the [http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock documentation] for more information on <code>sconcat</code> and <code>times1p</code>.<br />
<br />
==Laws==<br />
<br />
The only law is that <code>(<>)</code> must be associative:<br />
<br />
<haskell><br />
(x <> y) <> z = x <> (y <> z)<br />
</haskell><br />
<br />
=Monoid=<br />
<br />
Many semigroups have a special element <math>e</math> for which the binary operation <math>\oplus</math> is the identity, that is, <math>e \oplus x = x \oplus e = x</math> for every element <math>x</math>. Such a semigroup-with-identity-element is called a ''monoid''.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Monoid</code> type class (defined in<br />
<code>Data.Monoid</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html haddock]) is:<br />
<br />
<haskell><br />
class Monoid a where<br />
mempty :: a<br />
mappend :: a -> a -> a<br />
<br />
mconcat :: [a] -> a<br />
mconcat = foldr mappend mempty<br />
</haskell><br />
<br />
The <code>mempty</code> value specifies the identity element of the monoid, and <code>mappend</code><br />
is the binary operation. The default definition for <code>mconcat</code><br />
“reduces” a list of elements by combining them all with <code>mappend</code>,<br />
using a right fold. It is only in the <code>Monoid</code> class so that specific<br />
instances have the option of providing an alternative, more efficient<br />
implementation; usually, you can safely ignore <code>mconcat</code> when creating<br />
a <code>Monoid</code> instance, since its default definition will work just fine.<br />
<br />
The <code>Monoid</code> methods are rather unfortunately named; they are inspired<br />
by the list instance of <code>Monoid</code>, where indeed <code>mempty = []</code> and <code>mappend = (++)</code>, but this is misleading since many<br />
monoids have little to do with appending (see these [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 Comments from OCaml Hacker Brian Hurt] on the Haskell-cafe mailing list). This was improved in GHC 7.4, where <code>(<>)</code> was added as an alias to <code>mappend</code>.<br />
<br />
==Laws==<br />
<br />
Of course, every <code>Monoid</code> instance should actually be a monoid in the<br />
mathematical sense, which implies these laws:<br />
<br />
<haskell><br />
mempty `mappend` x = x<br />
x `mappend` mempty = x<br />
(x `mappend` y) `mappend` z = x `mappend` (y `mappend` z)<br />
</haskell><br />
<br />
==Instances==<br />
<br />
There are quite a few interesting <code>Monoid</code> instances defined in <code>Data.Monoid</code>.<br />
<br />
<ul><br />
<li><code>[a]</code> is a <code>Monoid</code>, with <code>mempty = []</code> and <code>mappend = (++)</code>. It is not hard to check that <code>(x ++ y) ++ z = x ++ (y ++ z)</code> for any lists <code>x</code>, <code>y</code>, and <code>z</code>, and that the empty list is the identity: <code>[] ++ x = x ++ [] = x</code>.</li><br />
<br />
<li>As noted previously, we can make a monoid out of any numeric type under either addition or multiplication. However, since we can’t have two instances for the same type, <code>Data.Monoid</code> provides two <code>newtype</code> wrappers, <code>Sum</code> and <code>Product</code>, with appropriate <code>Monoid</code> instances.<br />
<br />
<haskell><br />
> getSum (mconcat . map Sum $ [1..5])<br />
15<br />
> getProduct (mconcat . map Product $ [1..5])<br />
120<br />
</haskell><br />
<br />
This example code is silly, of course; we could just write<br />
<code>sum [1..5]</code> and <code>product [1..5]</code>. Nevertheless, these instances are useful in more generalized settings, as we will see in the [[Foldable|section on <code>Foldable</code>]].</li><br />
<br />
<li><code>Any</code> and <code>All</code> are <code>newtype</code> wrappers providing <code>Monoid</code> instances for <code>Bool</code> (under disjunction and conjunction, respectively).</li><br />
<br />
<li> There are three instances for <code>Maybe</code>: a basic instance which lifts a <code>Monoid</code> instance for <code>a</code> to an instance for <code>Maybe a</code>, and two <code>newtype</code> wrappers <code>First</code> and <code>Last</code> for which <code>mappend</code> selects the first (respectively last) non-<code>Nothing</code> item.</li><br />
<br />
<li><code>Endo a</code> is a newtype wrapper for functions <code>a -> a</code>, which form a monoid under composition.</li><br />
<br />
<li>There are several ways to “lift” <code>Monoid</code> instances to instances with additional structure. We have already seen that an instance for <code>a</code> can be lifted to an instance for <code>Maybe a</code>. There are also tuple instances: if <code>a</code> and <code>b</code> are instances of <code>Monoid</code>, then so is <code>(a,b)</code>, using the monoid operations for <code>a</code> and <code>b</code> in the obvious pairwise manner. Finally, if <code>a</code> is a <code>Monoid</code>, then so is the function type <code>e -> a</code> for any <code>e</code>; in particular, <code>g `mappend` h</code> is the function which applies both <code>g</code> and <code>h</code> to its argument and then combines the results using the underlying <code>Monoid</code> instance for <code>a</code>. This can be quite useful and elegant (see [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/52416 example]).</li><br />
<br />
<li>The type <code>Ordering = LT | EQ | GT</code> is a <code>Monoid</code>, defined in such a way that <code>mconcat (zipWith compare xs ys)</code> computes the lexicographic ordering of <code>xs</code> and <code>ys</code> (if <code>xs</code> and <code>ys</code> have the same length). In particular, <code>mempty = EQ</code>, and <code>mappend</code> evaluates to its leftmost non-<code>EQ</code> argument (or <code>EQ</code> if both arguments are <code>EQ</code>). This can be used together with the function instance of <code>Monoid</code> to do some clever things ([http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx example]).</li><br />
<br />
<li>There are also <code>Monoid</code> instances for several standard data structures in the containers library ([http://hackage.haskell.org/packages/archive/containers/0.2.0.0/doc/html/index.html haddock]), including <code>Map</code>, <code>Set</code>, and <code>Sequence</code>.</li><br />
</ul><br />
<br />
<code>Monoid</code> is also used to enable several other type class instances.<br />
As noted previously, we can use <code>Monoid</code> to make <code>((,) e)</code> an instance of <code>Applicative</code>:<br />
<br />
<haskell><br />
instance Monoid e => Applicative ((,) e) where<br />
pure x = (mempty, x)<br />
(u, f) <*> (v, x) = (u `mappend` v, f x)<br />
</haskell><br />
<br />
<code>Monoid</code> can be similarly used to make <code>((,) e)</code> an instance of <code>Monad</code> as well; this is known as the ''writer monad''. As we’ve already seen, <code>Writer</code> and <code>WriterT</code> are a newtype wrapper and transformer for this monad, respectively.<br />
<br />
<code>Monoid</code> also plays a key role in the <code>Foldable</code> type class (see section [[#Foldable|Foldable]]).<br />
<br />
==Other monoidal classes: Alternative, MonadPlus, ArrowPlus==<br />
<br />
The <code>Alternative</code> type class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html#g:2 haddock])<br />
is for <code>Applicative</code> functors which also have<br />
a monoid structure:<br />
<br />
<haskell><br />
class Applicative f => Alternative f where<br />
empty :: f a<br />
(<|>) :: f a -> f a -> f a<br />
</haskell><br />
<br />
Of course, instances of <code>Alternative</code> should satisfy the monoid laws<br />
<br />
<haskell><br />
empty <|> x = x<br />
x <|> empty = x<br />
(x <|> y) <|> z = x <|> (y <|> z)<br />
</haskell><br />
<br />
Likewise, <code>MonadPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html#t:MonadPlus haddock])<br />
is for <code>Monad</code>s with a monoid structure:<br />
<br />
<haskell><br />
class Monad m => MonadPlus m where<br />
mzero :: m a<br />
mplus :: m a -> m a -> m a<br />
</haskell><br />
<br />
The <code>MonadPlus</code> documentation states that it is intended to model<br />
monads which also support “choice and failure”; in addition to the<br />
monoid laws, instances of <code>MonadPlus</code> are expected to satisfy<br />
<br />
<haskell><br />
mzero >>= f = mzero<br />
v >> mzero = mzero<br />
</haskell><br />
<br />
which explains the sense in which <code>mzero</code> denotes failure. Since<br />
<code>mzero</code> should be the identity for <code>mplus</code>, the computation <code>m1 `mplus` m2</code> succeeds (evaluates to something other than <code>mzero</code>) if<br />
either <code>m1</code> or <code>m2</code> does; so <code>mplus</code> represents choice. The <code>guard</code><br />
function can also be used with instances of <code>MonadPlus</code>; it requires a<br />
condition to be satisfied and fails (using <code>mzero</code>) if it is not. A<br />
simple example of a <code>MonadPlus</code> instance is <code>[]</code>, which is exactly the<br />
same as the <code>Monoid</code> instance for <code>[]</code>: the empty list represents<br />
failure, and list concatenation represents choice. In general,<br />
however, a <code>MonadPlus</code> instance for a type need not be the same as its<br />
<code>Monoid</code> instance; <code>Maybe</code> is an example of such a type. A great<br />
introduction to the <code>MonadPlus</code> type class, with interesting examples<br />
of its use, is Doug Auclair’s ''MonadPlus: What a Super Monad!'' in [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad.Reader issue 11].<br />
<br />
There used to be a type class called <code>MonadZero</code> containing only<br />
<code>mzero</code>, representing monads with failure. The <code>do</code>-notation requires<br />
some notion of failure to deal with failing pattern matches.<br />
Unfortunately, <code>MonadZero</code> was scrapped in favor of adding the <code>fail</code><br />
method to the <code>Monad</code> class. If we are lucky, someday <code>MonadZero</code> will<br />
be restored, and <code>fail</code> will be banished to the bit bucket where it<br />
belongs (see [[MonadPlus reform proposal]]). The idea is that any<br />
<code>do</code>-block which uses pattern matching (and hence may fail) would require<br />
a <code>MonadZero</code> constraint; otherwise, only a <code>Monad</code> constraint would be<br />
required.<br />
<br />
Finally, <code>ArrowZero</code> and <code>ArrowPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#t:ArrowZero haddock])<br />
represent <code>Arrow</code>s ([[#Arrow|see below]]) with a<br />
monoid structure:<br />
<br />
<haskell><br />
class Arrow arr => ArrowZero arr where<br />
zeroArrow :: b `arr` c<br />
<br />
class ArrowZero arr => ArrowPlus arr where<br />
(<+>) :: (b `arr` c) -> (b `arr` c) -> (b `arr` c)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Monoids have gotten a fair bit of attention recently, ultimately due<br />
to<br />
[http://enfranchisedmind.com/blog/posts/random-thoughts-on-haskell/ a blog post by Brian Hurt], in which he<br />
complained about the fact that the names of many Haskell type classes<br />
(<code>Monoid</code> in particular) are taken from abstract mathematics. This<br />
resulted in [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 a long Haskell-cafe thread]<br />
arguing the point and discussing monoids in general.<br />
<br />
{{note|May its name live forever.}}<br />
<br />
However, this was quickly followed by several blog posts about<br />
<code>Monoid</code> {{noteref}}. First, Dan Piponi<br />
wrote a great introductory post, [http://blog.sigfpe.com/2009/01/haskell-monoids-and-their-uses.html Haskell Monoids and their Uses]. This was quickly followed by<br />
Heinrich Apfelmus’ [http://apfelmus.nfshost.com/monoid-fingertree.html Monoids and Finger Trees], an accessible exposition of<br />
Hinze and Paterson’s [http://www.soi.city.ac.uk/%7Eross/papers/FingerTree.html classic paper on 2-3 finger trees], which makes very clever<br />
use of <code>Monoid</code> to implement an elegant and generic data structure.<br />
Dan Piponi then wrote two fascinating articles about using <code>Monoids</code><br />
(and finger trees): [http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html Fast Incremental Regular Expressions] and [http://blog.sigfpe.com/2009/01/beyond-regular-expressions-more.html Beyond Regular Expressions]<br />
<br />
In a similar vein, David Place’s article on improving <code>Data.Map</code> in<br />
order to compute incremental folds (see [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad Reader issue 11])<br />
is also a<br />
good example of using <code>Monoid</code> to generalize a data structure.<br />
<br />
Some other interesting examples of <code>Monoid</code> use include [http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx building elegant list sorting combinators], [http://byorgey.wordpress.com/2008/04/17/collecting-unstructured-information-with-the-monoid-of-partial-knowledge/ collecting unstructured information], [http://izbicki.me/blog/gausian-distributions-are-monoids combining probability distributions], and a brilliant series of posts by Chung-Chieh Shan and Dylan Thurston using <code>Monoid</code>s to [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers1/ elegantly solve a difficult combinatorial puzzle] (followed by [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers2/ part 2], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers3/ part 3], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers4/ part 4]).<br />
<br />
As unlikely as it sounds, monads can actually be viewed as a sort of<br />
monoid, with <code>join</code> playing the role of the binary operation and<br />
<code>return</code> the role of the identity; see [http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html Dan Piponi’s blog post].<br />
<br />
=Foldable=<br />
<br />
The <code>Foldable</code> class, defined in the <code>Data.Foldable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html haddock]), abstracts over containers which can be<br />
“folded” into a summary value. This allows such folding operations<br />
to be written in a container-agnostic way.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Foldable</code> type class is:<br />
<br />
<haskell><br />
class Foldable t where<br />
fold :: Monoid m => t m -> m<br />
foldMap :: Monoid m => (a -> m) -> t a -> m<br />
<br />
foldr :: (a -> b -> b) -> b -> t a -> b<br />
foldl :: (a -> b -> a) -> a -> t b -> a<br />
foldr1 :: (a -> a -> a) -> t a -> a<br />
foldl1 :: (a -> a -> a) -> t a -> a<br />
</haskell><br />
<br />
This may look complicated, but in fact, to make a <code>Foldable</code> instance<br />
you only need to implement one method: your choice of <code>foldMap</code> or<br />
<code>foldr</code>. All the other methods have default implementations in terms<br />
of these, and are presumably included in the class in case more<br />
efficient implementations can be provided.<br />
<br />
==Instances and examples==<br />
<br />
The type of <code>foldMap</code> should make it clear what it is supposed to do:<br />
given a way to convert the data in a container into a <code>Monoid</code> (a<br />
function <code>a -> m</code>) and a container of <code>a</code>’s (<code>t a</code>), <code>foldMap</code><br />
provides a way to iterate over the entire contents of the container,<br />
converting all the <code>a</code>’s to <code>m</code>’s and combining all the <code>m</code>’s with<br />
<code>mappend</code>. The following code shows two examples: a simple<br />
implementation of <code>foldMap</code> for lists, and a binary tree example<br />
provided by the <code>Foldable</code> documentation.<br />
<br />
<haskell><br />
instance Foldable [] where<br />
foldMap g = mconcat . map g<br />
<br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Foldable Tree where<br />
foldMap f Empty = mempty<br />
foldMap f (Leaf x) = f x<br />
foldMap f (Node l k r) = foldMap f l `mappend` f k `mappend` foldMap f r<br />
</haskell><br />
<br />
The <code>foldr</code> function has a type similar to the <code>foldr</code> found in the <code>Prelude</code>, but<br />
more general, since the <code>foldr</code> in the <code>Prelude</code> works only on lists.<br />
<br />
The <code>Foldable</code> module also provides instances for <code>Maybe</code> and <code>Array</code>;<br />
additionally, many of the data structures found in the standard [http://hackage.haskell.org/package/containers containers library] (for example, <code>Map</code>, <code>Set</code>, <code>Tree</code>,<br />
and <code>Sequence</code>) provide their own <code>Foldable</code> instances.<br />
<br />
{{Exercises|<br />
# What is the type of <code>foldMap . foldMap</code>? Or <code>foldMap . foldMap . foldMap</code>, etc.? What do they do?<br />
}}<br />
<br />
==Derived folds==<br />
<br />
Given an instance of <code>Foldable</code>, we can write generic,<br />
container-agnostic functions such as:<br />
<br />
<haskell><br />
-- Compute the size of any container.<br />
containerSize :: Foldable f => f a -> Int<br />
containerSize = getSum . foldMap (const (Sum 1))<br />
<br />
-- Compute a list of elements of a container satisfying a predicate.<br />
filterF :: Foldable f => (a -> Bool) -> f a -> [a]<br />
filterF p = foldMap (\a -> if p a then [a] else [])<br />
<br />
-- Get a list of all the Strings in a container which include the<br />
-- letter a.<br />
aStrings :: Foldable f => f String -> [String]<br />
aStrings = filterF (elem 'a')<br />
</haskell><br />
<br />
The <code>Foldable</code> module also provides a large number of predefined<br />
folds, many of which are generalized versions of <code>Prelude</code> functions of the<br />
same name that only work on lists: <code>concat</code>, <code>concatMap</code>, <code>and</code>,<br />
<code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>),<br />
<code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>.<br />
<br />
The important function <code>toList</code> is also provided, which turns any <code>Foldable</code> structure into a list of its elements in left-right order; it works by folding with the list monoid.<br />
<br />
There are also generic functions that work with <code>Applicative</code> or<br />
<code>Monad</code> instances to generate some sort of computation from each<br />
element in a container, and then perform all the side effects from<br />
those computations, discarding the results: <code>traverse_</code>, <code>sequenceA_</code>,<br />
and others. The results must be discarded because the <code>Foldable</code><br />
class is too weak to specify what to do with them: we cannot, in<br />
general, make an arbitrary <code>Applicative</code> or <code>Monad</code> instance into a <code>Monoid</code>, but we can make <code>m ()</code> into a <code>Monoid</code> for any such <code>m</code>. If we do have an <code>Applicative</code> or <code>Monad</code> with a monoid<br />
structure—that is, an <code>Alternative</code> or a <code>MonadPlus</code>—then we can<br />
use the <code>asum</code> or <code>msum</code> functions, which can combine the results as<br />
well. Consult the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html <code>Foldable</code> documentation] for<br />
more details on any of these functions.<br />
<br />
Note that the <code>Foldable</code> operations always forget the structure of<br />
the container being folded. If we start with a container of type <code>t a</code> for some <code>Foldable t</code>, then <code>t</code> will never appear in the output<br />
type of any operations defined in the <code>Foldable</code> module. Many times<br />
this is exactly what we want, but sometimes we would like to be able<br />
to generically traverse a container while preserving its<br />
structure—and this is exactly what the <code>Traversable</code> class provides,<br />
which will be discussed in the next section.<br />
<br />
{{Exercises|<br />
# Implement <code>toList :: Foldable f {{=}}> f a -> [a]</code>.<br />
# Pick some of the following functions to implement: <code>concat</code>, <code>concatMap</code>, <code>and</code>, <code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>), <code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>. Figure out how they generalize to <code>Foldable</code> and come up with elegant implementations using <code>fold</code> or <code>foldMap</code> along with appropriate <code>Monoid</code> instances.<br />
}}<br />
<br />
==Foldable actually isn't==<br />
<br />
The generic term "fold" is often used to refer to the more technical concept of [[Catamorphisms|catamorphism]]. Intuitively, given a way to summarize "one level of structure" (where recursive subterms have already been replaced with their summaries), a catamorphism can summarize an entire recursive structure. It is important to realize that <code>Foldable</code> does <i>not</i> correspond to catamorphisms, but to something weaker. In particular, <code>Foldable</code> allows observing only the left-right order of elements within a structure, not the actual structure itself. Put another way, every use of <code>Foldable</code> can be expressed in terms of <code>toList</code>. For example, <code>fold</code> itself is equivalent to <code>mconcat . toList</code>.<br />
<br />
This is sufficient for many tasks, but not all. For example, consider trying to compute the depth of a <code>Tree</code>: try as we might, there is no way to implement it using <code>Foldable</code>. However, it <i>can</i> be implemented as a catamorphism.<br />
<br />
==Further reading==<br />
<br />
The <code>Foldable</code> class had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s paper]<br />
introducing <code>Applicative</code>, although it has<br />
been fleshed out quite a bit from the form in the paper.<br />
<br />
An interesting use of <code>Foldable</code> (as well as <code>Traversable</code>) can be<br />
found in Janis Voigtländer’s paper [http://doi.acm.org/10.1145/1480881.1480904 Bidirectionalization for free!].<br />
<br />
=Traversable=<br />
<br />
==Definition==<br />
<br />
The <code>Traversable</code> type class, defined in the <code>Data.Traversable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html haddock]), is:<br />
<br />
<haskell><br />
class (Functor t, Foldable t) => Traversable t where<br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
mapM :: Monad m => (a -> m b) -> t a -> m (t b)<br />
sequence :: Monad m => t (m a) -> m (t a)<br />
</haskell><br />
<br />
As you can see, every <code>Traversable</code> is also a foldable functor. Like<br />
<code>Foldable</code>, there is a lot in this type class, but making instances is<br />
actually rather easy: one need only implement <code>traverse</code> or<br />
<code>sequenceA</code>; the other methods all have default implementations in<br />
terms of these functions. A good exercise is to figure out what the default<br />
implementations should be: given either <code>traverse</code> or <code>sequenceA</code>, how<br />
would you define the other three methods? (Hint for <code>mapM</code>:<br />
<code>Control.Applicative</code> exports the <code>WrapMonad</code> newtype, which makes any<br />
<code>Monad</code> into an <code>Applicative</code>. The <code>sequence</code> function can be implemented in terms<br />
of <code>mapM</code>.)<br />
<br />
==Intuition==<br />
<br />
The key method of the <code>Traversable</code> class, and the source of its<br />
unique power, is <code>sequenceA</code>. Consider its type:<br />
<haskell><br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
</haskell><br />
This answers the fundamental question: when can we commute two<br />
functors? For example, can we turn a tree of lists into a list of<br />
trees?<br />
<br />
The ability to compose two monads depends crucially on this ability to<br />
commute functors. Intuitively, if we want to build a composed monad<br />
<code>M a = m (n a)</code> out of monads <code>m</code> and <code>n</code>, then to be able to<br />
implement <code>join :: M (M a) -> M a</code>, that is,<br />
<code>join :: m (n (m (n a))) -> m (n a)</code>, we have to be able to commute<br />
the <code>n</code> past the <code>m</code> to get <code>m (m (n (n a)))</code>, and then we can use the<br />
<code>join</code>s for <code>m</code> and <code>n</code> to produce something of type <code>m (n a)</code>. See<br />
[http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Mark Jones’ paper] for more details.<br />
<br />
Alternatively, looking at the type of <code>traverse</code>,<br />
<haskell><br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
</haskell><br />
leads us to view <code>Traversable</code> as a generalization of <code>Functor</code>. <code>traverse</code> is an "effectful <code>fmap</code>": it allows us to map over a structure of type <code>t a</code>, applying a function to every element of type <code>a</code> and in order to produce a new structure of type <code>t b</code>; but along the way the function may have some effects (captured by the applicative functor <code>f</code>).<br />
<br />
{{Exercises|<br />
# There are at least two natural ways to turn a tree of lists into a list of trees. What are they, and why?<br />
# Give a natural way to turn a list of trees into a tree of lists.<br />
# What is the type of <code>traverse . traverse</code>? What does it do?<br />
}}<br />
<br />
==Instances and examples==<br />
<br />
What’s an example of a <code>Traversable</code> instance?<br />
The following code shows an example instance for the same<br />
<code>Tree</code> type used as an example in the previous <code>Foldable</code> section. It<br />
is instructive to compare this instance with a <code>Functor</code> instance for<br />
<code>Tree</code>, which is also shown.<br />
<br />
<haskell><br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Traversable Tree where<br />
traverse g Empty = pure Empty<br />
traverse g (Leaf x) = Leaf <$> g x<br />
traverse g (Node l x r) = Node <$> traverse g l<br />
<*> g x<br />
<*> traverse g r<br />
<br />
instance Functor Tree where<br />
fmap g Empty = Empty<br />
fmap g (Leaf x) = Leaf $ g x<br />
fmap g (Node l x r) = Node (fmap g l)<br />
(g x)<br />
(fmap g r)<br />
</haskell><br />
<br />
It should be clear that the <code>Traversable</code> and <code>Functor</code> instances for<br />
<code>Tree</code> are almost identical; the only difference is that the <code>Functor</code><br />
instance involves normal function application, whereas the<br />
applications in the <code>Traversable</code> instance take place within an<br />
<code>Applicative</code> context, using <code>(<$>)</code> and <code>(<*>)</code>. In fact, this will<br />
be<br />
true for any type.<br />
<br />
Any <code>Traversable</code> functor is also <code>Foldable</code>, and a <code>Functor</code>. We can see<br />
this not only from the class declaration, but by the fact that we can<br />
implement the methods of both classes given only the <code>Traversable</code><br />
methods.<br />
<br />
The standard libraries provide a number of <code>Traversable</code> instances,<br />
including instances for <code>[]</code>, <code>Maybe</code>, <code>Map</code>, <code>Tree</code>, and <code>Sequence</code>.<br />
Notably, <code>Set</code> is not <code>Traversable</code>, although it is <code>Foldable</code>.<br />
<br />
{{Exercises|<br />
# Implement <code>fmap</code> and <code>foldMap</code> using only the <code>Traversable</code> methods. (Note that the <code>Traversable</code> module provides these implementations as <code>fmapDefault</code> and <code>foldMapDefault</code>.)<br />
}}<br />
<br />
==Laws==<br />
<br />
Any instance of <code>Traversable</code> must satisfy the following two laws, where <code>Identity</code> is the identity functor (as defined in the [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Data-Functor-Identity.html <code>Data.Functor.Identity</code> module] from the <code>transformers</code> package), and <code>Compose</code> wraps the composition of two functors (as defined in [http://hackage.haskell.org/packages/archive/transformers/0.3.0.0/doc/html/Data-Functor-Compose.html <code>Data.Functor.Compose</code>]):<br />
<br />
# <code>traverse Identity = Identity</code><br />
# <code>traverse (Compose . fmap g . f) = Compose . fmap (traverse g) . traverse f</code><br />
<br />
The first law essentially says that traversals cannot make up arbitrary effects. The second law explains how doing two traversals in sequence can be collapsed to a single traversal.<br />
<br />
Additionally, suppose <code>eta</code> is an "<code>Applicative</code> morphism", that is,<br />
<haskell><br />
eta :: forall a f g. (Applicative f, Applicative g) => f a -> g a<br />
</haskell><br />
and <code>eta</code> preserves the <code>Applicative</code> operations: <code>eta (pure x) = pure x</code> and <code>eta (x <*> y) = eta x <*> eta y</code>. Then, by parametricity, any instance of <code>Traversable</code> satisfying the above two laws will also satisfy <code>eta . traverse f = traverse (eta . f)</code>.<br />
<br />
==Further reading==<br />
<br />
The <code>Traversable</code> class also had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s <code>Applicative</code> paper],<br />
and is described in more detail in Gibbons and Oliveira, [http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf The Essence of the Iterator Pattern],<br />
which also contains a wealth of references to related work.<br />
<br />
<code>Traversable</code> forms a core component of Edward Kmett's [http://hackage.haskell.org/package/lens lens library]. Watching [https://vimeo.com/56063074 Edward's talk on the subject] is a highly recommended way to gain better insight into <code>Traversable</code>, <code>Foldable</code>, <code>Applicative</code>, and many other things besides.<br />
<br />
For references on the <code>Traversable</code> laws, see Russell O'Connor's [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17778 mailing list post] (and subsequent thread).<br />
<br />
=Category=<br />
<br />
<code>Category</code> is a relatively recent addition to the Haskell standard libraries. It generalizes the notion of function composition to general “morphisms”.<br />
<br />
{{note|GHC 7.6.1 changed its rules regarding types and type variables. Now, any operator at the type level is treated as a type ''constructor'' rather than a type ''variable''; prior to GHC 7.6.1 it was possible to use <code>(~&gt;)</code> instead of <code>`arr`</code>. For more information, see [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/21350 the discussion on the GHC-users mailing list]. For a new approach to nice arrow notation that works with GHC 7.6.1, see [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22615 this message] and also [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22616 this message] from Edward Kmett, though for simplicity I haven't adopted it here.}}<br />
The definition of the <code>Category</code> type class (from<br />
<code>Control.Category</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Category.html haddock]) is shown below. For ease of reading, note that I have used an infix type variable <code>`arr`</code>, in parallel with the infix function type constructor <code>(->)</code>. {{noteref}} This syntax is not part of Haskell 2010. The second definition shown is the one used in the standard libraries. For the remainder of this document, I will use the infix type constructor <code>`arr`</code> for <code>Category</code> as well as <code>Arrow</code>.<br />
<br />
<haskell><br />
class Category arr where<br />
id :: a `arr` a<br />
(.) :: (b `arr` c) -> (a `arr` b) -> (a `arr` c)<br />
<br />
-- The same thing, with a normal (prefix) type constructor<br />
class Category cat where<br />
id :: cat a a<br />
(.) :: cat b c -> cat a b -> cat a c<br />
</haskell><br />
<br />
Note that an instance of <code>Category</code> should be a type constructor which takes two type arguments, that is, something of kind <code>* -> * -> *</code>. It is instructive to imagine the type constructor variable <code>cat</code> replaced by the function constructor <code>(->)</code>: indeed, in this case we recover precisely the familiar identity function <code>id</code> and function composition operator <code>(.)</code> defined in the standard <code>Prelude</code>.<br />
<br />
Of course, the <code>Category</code> module provides exactly such an instance of<br />
<code>Category</code> for <code>(->)</code>. But it also provides one other instance, shown below, which should be familiar from the previous discussion of the <code>Monad</code> laws. <code>Kleisli m a b</code>, as defined in the <code>Control.Arrow</code> module, is just a <code>newtype</code> wrapper around <code>a -> m b</code>.<br />
<br />
<haskell><br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Category (Kleisli m) where<br />
id = Kleisli return<br />
Kleisli g . Kleisli h = Kleisli (h >=> g)<br />
</haskell><br />
<br />
The only law that <code>Category</code> instances should satisfy is that <code>id</code> and <code>(.)</code> should form a monoid—that is, <code>id</code> should be the identity of <code>(.)</code>, and <code>(.)</code> should be associative.<br />
<br />
Finally, the <code>Category</code> module exports two additional operators:<br />
<code>(<<<)</code>, which is just a synonym for <code>(.)</code>, and <code>(>>>)</code>, which is <code>(.)</code> with its arguments reversed. (In previous versions of the libraries, these operators were defined as part of the <code>Arrow</code> class.)<br />
<br />
==Further reading==<br />
<br />
The name <code>Category</code> is a bit misleading, since the <code>Category</code> class cannot represent arbitrary categories, but only categories whose objects are objects of <code>Hask</code>, the category of Haskell types. For a more general treatment of categories within Haskell, see the [http://hackage.haskell.org/package/category-extras category-extras package]. For more about category theory in general, see the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page],<br />
[http://books.google.com/books/about/Category_theory.html?id=-MCJ6x2lC7oC Steve Awodey’s new book], Benjamin Pierce’s [http://books.google.com/books/about/Basic_category_theory_for_computer_scien.html?id=ezdeaHfpYPwC Basic category theory for computer scientists], or [http://folli.loria.fr/cds/1999/esslli99/courses/barr-wells.html Barr and Wells category theory lecture notes]. [http://dekudekuplex.wordpress.com/2009/01/19/motivating-learning-category-theory-for-non-mathematicians/ Benjamin Russell’s blog post]<br />
is another good source of motivation and category theory links. You certainly don’t need to know any category theory to be a successful and productive Haskell programmer, but it does lend itself to much deeper appreciation of Haskell’s underlying theory.<br />
<br />
=Arrow=<br />
<br />
The <code>Arrow</code> class represents another abstraction of computation, in a<br />
similar vein to <code>Monad</code> and <code>Applicative</code>. However, unlike <code>Monad</code><br />
and <code>Applicative</code>, whose types only reflect their output, the type of<br />
an <code>Arrow</code> computation reflects both its input and output. Arrows<br />
generalize functions: if <code>arr</code> is an instance of <code>Arrow</code>, a value of<br />
type <code>b `arr` c</code> can be thought of as a computation which takes values of<br />
type <code>b</code> as input, and produces values of type <code>c</code> as output. In the<br />
<code>(->)</code> instance of <code>Arrow</code> this is just a pure function; in general, however,<br />
an arrow may represent some sort of “effectful” computation.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Arrow</code> type class, from<br />
<code>Control.Arrow</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html haddock]), is:<br />
<br />
<haskell><br />
class Category arr => Arrow arr where<br />
arr :: (b -> c) -> (b `arr` c)<br />
first :: (b `arr` c) -> ((b, d) `arr` (c, d))<br />
second :: (b `arr` c) -> ((d, b) `arr` (d, c))<br />
(***) :: (b `arr` c) -> (b' `arr` c') -> ((b, b') `arr` (c, c'))<br />
(&&&) :: (b `arr` c) -> (b `arr` c') -> (b `arr` (c, c'))<br />
</haskell><br />
<br />
{{note|In versions of the <code>base</code><br />
package prior to version 4, there is no <code>Category</code> class, and the<br />
<code>Arrow</code> class includes the arrow composition operator <code>(>>>)</code>. It<br />
also includes <code>pure</code> as a synonym for <code>arr</code>, but this was removed<br />
since it conflicts with the <code>pure</code> from <code>Applicative</code>.}}<br />
<br />
The first thing to note is the <code>Category</code> class constraint, which<br />
means that we get identity arrows and arrow composition for free:<br />
given two arrows <code>g :: b `arr` c</code> and <code>h :: c `arr` d</code>, we can form their<br />
composition <code>g >>> h :: b `arr` d</code> {{noteref}}.<br />
<br />
As should be a familiar pattern by now, the only methods which must be<br />
defined when writing a new instance of <code>Arrow</code> are <code>arr</code> and <code>first</code>;<br />
the other methods have default definitions in terms of these, but are<br />
included in the <code>Arrow</code> class so that they can be overridden with more<br />
efficient implementations if desired.<br />
<br />
==Intuition==<br />
<br />
Let’s look at each of the arrow methods in turn. [http://www.haskell.org/arrows/ Ross Paterson’s web page on arrows] has nice diagrams which can help<br />
build intuition.<br />
<br />
* The <code>arr</code> function takes any function <code>b -> c</code> and turns it into a generalized arrow <code>b `arr` c</code>. The <code>arr</code> method justifies the claim that arrows generalize functions, since it says that we can treat any function as an arrow. It is intended that the arrow <code>arr g</code> is “pure” in the sense that it only computes <code>g</code> and has no “effects” (whatever that might mean for any particular arrow type).<br />
<br />
* The <code>first</code> method turns any arrow from <code>b</code> to <code>c</code> into an arrow from <code>(b,d)</code> to <code>(c,d)</code>. The idea is that <code>first g</code> uses <code>g</code> to process the first element of a tuple, and lets the second element pass through unchanged. For the function instance of <code>Arrow</code>, of course, <code>first g (x,y) = (g x, y)</code>.<br />
<br />
* The <code>second</code> function is similar to <code>first</code>, but with the elements of the tuples swapped. Indeed, it can be defined in terms of <code>first</code> using an auxiliary function <code>swap</code>, defined by <code>swap (x,y) = (y,x)</code>.<br />
<br />
* The <code>(***)</code> operator is “parallel composition” of arrows: it takes two arrows and makes them into one arrow on tuples, which has the behavior of the first arrow on the first element of a tuple, and the behavior of the second arrow on the second element. The mnemonic is that <code>g *** h</code> is the ''product'' (hence <code>*</code>) of <code>g</code> and <code>h</code>. For the function instance of <code>Arrow</code>, we define <code>(g *** h) (x,y) = (g x, h y)</code>. The default implementation of <code>(***)</code> is in terms of <code>first</code>, <code>second</code>, and sequential arrow composition <code>(>>>)</code>. The reader may also wish to think about how to implement <code>first</code> and <code>second</code> in terms of <code>(***)</code>.<br />
<br />
* The <code>(&&&)</code> operator is “fanout composition” of arrows: it takes two arrows <code>g</code> and <code>h</code> and makes them into a new arrow <code>g &&& h</code> which supplies its input as the input to both <code>g</code> and <code>h</code>, returning their results as a tuple. The mnemonic is that <code>g &&& h</code> performs both <code>g</code> ''and'' <code>h</code> (hence <code>&</code>) on its input. For functions, we define <code>(g &&& h) x = (g x, h x)</code>.<br />
<br />
==Instances==<br />
<br />
The <code>Arrow</code> library itself only provides two <code>Arrow</code> instances, both<br />
of which we have already seen: <code>(->)</code>, the normal function<br />
constructor, and <code>Kleisli m</code>, which makes functions of<br />
type <code>a -> m b</code> into <code>Arrow</code>s for any <code>Monad m</code>. These instances are:<br />
<br />
<haskell><br />
instance Arrow (->) where<br />
arr g = g<br />
first g (x,y) = (g x, y)<br />
<br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Arrow (Kleisli m) where<br />
arr f = Kleisli (return . f)<br />
first (Kleisli f) = Kleisli (\ ~(b,d) -> do c <- f b<br />
return (c,d) )<br />
</haskell><br />
<br />
==Laws==<br />
<br />
{{note|See [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 John Hughes: Generalising monads to arrows]; [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf Sam Lindley, Philip Wadler, Jeremy Yallop: The arrow calculus]; [http://www.soi.city.ac.uk/~ross/papers/fop.html Ross Paterson: Programming with Arrows].}}<br />
<br />
There are quite a few laws that instances of <code>Arrow</code> should<br />
satisfy {{noteref}}:<br />
<br />
<haskell><br />
arr id = id<br />
arr (h . g) = arr g >>> arr h<br />
first (arr g) = arr (g *** id)<br />
first (g >>> h) = first g >>> first h<br />
first g >>> arr (id *** h) = arr (id *** h) >>> first g<br />
first g >>> arr fst = arr fst >>> g<br />
first (first g) >>> arr assoc = arr assoc >>> first g<br />
<br />
assoc ((x,y),z) = (x,(y,z))<br />
</haskell><br />
<br />
Note that this version of the laws is slightly different than the laws given in the<br />
first two above references, since several of the laws have now been<br />
subsumed by the <code>Category</code> laws (in particular, the requirements that<br />
<code>id</code> is the identity arrow and that <code>(>>>)</code> is associative). The laws<br />
shown here follow those in Paterson’s Programming with Arrows, which uses the<br />
<code>Category</code> class.<br />
<br />
{{note|Unless category-theory-induced insomnolence is your cup of tea.}}<br />
<br />
The reader is advised not to lose too much sleep over the <code>Arrow</code><br />
laws {{noteref}}, since it is not essential to understand them in order to<br />
program with arrows. There are also laws that <code>ArrowChoice</code>,<br />
<code>ArrowApply</code>, and <code>ArrowLoop</code> instances should satisfy; the interested<br />
reader should consult [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows].<br />
<br />
==ArrowChoice==<br />
<br />
Computations built using the <code>Arrow</code> class, like those built using<br />
the <code>Applicative</code> class, are rather inflexible: the structure of the computation<br />
is fixed at the outset, and there is no ability to choose between<br />
alternate execution paths based on intermediate results.<br />
The <code>ArrowChoice</code> class provides exactly such an ability:<br />
<br />
<haskell><br />
class Arrow arr => ArrowChoice arr where<br />
left :: (b `arr` c) -> (Either b d `arr` Either c d)<br />
right :: (b `arr` c) -> (Either d b `arr` Either d c)<br />
(+++) :: (b `arr` c) -> (b' `arr` c') -> (Either b b' `arr` Either c c')<br />
(|||) :: (b `arr` d) -> (c `arr` d) -> (Either b c `arr` d)<br />
</haskell><br />
<br />
A comparison of <code>ArrowChoice</code> to <code>Arrow</code> will reveal a striking<br />
parallel between <code>left</code>, <code>right</code>, <code>(+++)</code>, <code>(|||)</code> and <code>first</code>,<br />
<code>second</code>, <code>(***)</code>, <code>(&&&)</code>, respectively. Indeed, they are dual:<br />
<code>first</code>, <code>second</code>, <code>(***)</code>, and <code>(&&&)</code> all operate on product types<br />
(tuples), and <code>left</code>, <code>right</code>, <code>(+++)</code>, and <code>(|||)</code> are the<br />
corresponding operations on sum types. In general, these operations<br />
create arrows whose inputs are tagged with <code>Left</code> or <code>Right</code>, and can<br />
choose how to act based on these tags.<br />
<br />
* If <code>g</code> is an arrow from <code>b</code> to <code>c</code>, then <code>left g</code> is an arrow from <code>Either b d</code> to <code>Either c d</code>. On inputs tagged with <code>Left</code>, the <code>left g</code> arrow has the behavior of <code>g</code>; on inputs tagged with <code>Right</code>, it behaves as the identity.<br />
<br />
* The <code>right</code> function, of course, is the mirror image of <code>left</code>. The arrow <code>right g</code> has the behavior of <code>g</code> on inputs tagged with <code>Right</code>.<br />
<br />
* The <code>(+++)</code> operator performs “multiplexing”: <code>g +++ h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and as <code>h</code> on inputs tagged with <code>Right</code>. The tags are preserved. The <code>(+++)</code> operator is the ''sum'' (hence <code>+</code>) of two arrows, just as <code>(***)</code> is the product.<br />
<br />
* The <code>(|||)</code> operator is “merge” or “fanin”: the arrow <code>g ||| h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and <code>h</code> on inputs tagged with <code>Right</code>, but the tags are discarded (hence, <code>g</code> and <code>h</code> must have the same output type). The mnemonic is that <code>g ||| h</code> performs either <code>g</code> ''or'' <code>h</code> on its input.<br />
<br />
The <code>ArrowChoice</code> class allows computations to choose among a finite number of execution paths, based on intermediate results. The possible<br />
execution paths must be known in advance, and explicitly assembled with <code>(+++)</code> or <code>(|||)</code>. However, sometimes more flexibility is<br />
needed: we would like to be able to ''compute'' an arrow from intermediate results, and use this computed arrow to continue the computation. This is the power given to us by <code>ArrowApply</code>.<br />
<br />
==ArrowApply==<br />
<br />
The <code>ArrowApply</code> type class is:<br />
<br />
<haskell><br />
class Arrow arr => ArrowApply arr where<br />
app :: (b `arr` c, b) `arr` c<br />
</haskell><br />
<br />
If we have computed an arrow as the output of some previous<br />
computation, then <code>app</code> allows us to apply that arrow to an input,<br />
producing its output as the output of <code>app</code>. As an exercise, the<br />
reader may wish to use <code>app</code> to implement an alternative “curried”<br />
version, <code>app2 :: b `arr` ((b `arr` c) `arr` c)</code>.<br />
<br />
This notion of being able to ''compute'' a new computation<br />
may sound familiar:<br />
this is exactly what the monadic bind operator <code>(>>=)</code> does. It<br />
should not particularly come as a surprise that <code>ArrowApply</code> and<br />
<code>Monad</code> are exactly equivalent in expressive power. In particular,<br />
<code>Kleisli m</code> can be made an instance of <code>ArrowApply</code>, and any instance<br />
of <code>ArrowApply</code> can be made a <code>Monad</code> (via the <code>newtype</code> wrapper<br />
<code>ArrowMonad</code>). As an exercise, the reader may wish to try<br />
implementing these instances:<br />
<br />
<haskell><br />
instance Monad m => ArrowApply (Kleisli m) where<br />
app = -- exercise<br />
<br />
newtype ArrowApply a => ArrowMonad a b = ArrowMonad (a () b)<br />
<br />
instance ArrowApply a => Monad (ArrowMonad a) where<br />
return = -- exercise<br />
(ArrowMonad a) >>= k = -- exercise<br />
</haskell><br />
<br />
==ArrowLoop==<br />
<br />
The <code>ArrowLoop</code> type class is:<br />
<br />
<haskell><br />
class Arrow a => ArrowLoop a where<br />
loop :: a (b, d) (c, d) -> a b c<br />
<br />
trace :: ((b,d) -> (c,d)) -> b -> c<br />
trace f b = let (c,d) = f (b,d) in c<br />
</haskell><br />
<br />
It describes arrows that can use recursion to compute results, and is<br />
used to desugar the <code>rec</code> construct in arrow notation (described<br />
below).<br />
<br />
Taken by itself, the type of the <code>loop</code> method does not seem to tell<br />
us much. Its intention, however, is a generalization of the <code>trace</code><br />
function which is also shown. The <code>d</code> component of the first arrow’s<br />
output is fed back in as its own input. In other words, the arrow<br />
<code>loop g</code> is obtained by recursively “fixing” the second component of<br />
the input to <code>g</code>.<br />
<br />
It can be a bit difficult to grok what the <code>trace</code> function is doing.<br />
How can <code>d</code> appear on the left and right sides of the <code>let</code>? Well,<br />
this is Haskell’s laziness at work. There is not space here for a<br />
full explanation; the interested reader is encouraged to study the<br />
standard <code>fix</code> function, and to read [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson’s arrow tutorial].<br />
<br />
==Arrow notation==<br />
<br />
Programming directly with the arrow combinators can be painful,<br />
especially when writing complex computations which need to retain<br />
simultaneous reference to a number of intermediate results. With<br />
nothing but the arrow combinators, such intermediate results must be<br />
kept in nested tuples, and it is up to the programmer to remember<br />
which intermediate results are in which components, and to swap,<br />
reassociate, and generally mangle tuples as necessary. This problem<br />
is solved by the special arrow notation supported by GHC, similar to<br />
<code>do</code> notation for monads, that allows names to be assigned to<br />
intermediate results while building up arrow computations. An example<br />
arrow implemented using arrow notation, taken from<br />
Paterson, is:<br />
<br />
<haskell><br />
class ArrowLoop arr => ArrowCircuit arr where<br />
delay :: b -> (b `arr` b)<br />
<br />
counter :: ArrowCircuit arr => Bool `arr` Int<br />
counter = proc reset -> do<br />
rec output <- idA -< if reset then 0 else next<br />
next <- delay 0 -< output + 1<br />
idA -< output<br />
</haskell><br />
<br />
This arrow is intended to<br />
represent a recursively defined counter circuit with a reset line.<br />
<br />
There is not space here for a full explanation of arrow notation; the<br />
interested reader should consult<br />
[http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper introducing the notation], or his later [http://www.soi.city.ac.uk/~ross/papers/fop.html tutorial which presents a simplified version].<br />
<br />
==Further reading==<br />
<br />
An excellent starting place for the student of arrows is the [http://www.haskell.org/arrows/ arrows web page], which contains an<br />
introduction and many references. Some key papers on arrows include<br />
Hughes’ original paper introducing arrows, [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 Generalising monads to arrows], and [http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper on arrow notation].<br />
<br />
Both Hughes and Paterson later wrote accessible tutorials intended for a broader<br />
audience: [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows] and [http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf Hughes: Programming with Arrows].<br />
<br />
Although Hughes’ goal in defining the <code>Arrow</code> class was to<br />
generalize <code>Monad</code>s, and it has been said that <code>Arrow</code> lies “between<br />
<code>Applicative</code> and <code>Monad</code>” in power, they are not directly<br />
comparable. The precise relationship remained in some confusion until<br />
[http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf analyzed by Lindley, Wadler, and Yallop], who<br />
also invented a new calculus of arrows, based on the lambda calculus,<br />
which considerably simplifies the presentation of the arrow laws<br />
(see [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf The arrow calculus]). There is also a precise technical sense in which [http://just-bottom.blogspot.de/2010/04/programming-with-effects-story-so-far.html <code>Arrow</code> can be seen as the intersection of <code>Applicative</code> and <code>Category</code>].<br />
<br />
Some examples of <code>Arrow</code>s include [http://www.haskell.org/yampa/ Yampa], the<br />
[http://www.fh-wedel.de/~si/HXmlToolbox/ Haskell XML Toolkit], and the functional GUI library [[Grapefruit]].<br />
<br />
Some extensions to arrows have been explored; for example, the<br />
<code>BiArrow</code>s of Alimarine et al. ([http://wiki.clean.cs.ru.nl/download/papers/2005/alia2005-biarrowsHaskellWorkshop.pdf "There and Back Again: Arrows for Invertible Programming"]), for two-way instead of one-way<br />
computation.<br />
<br />
The Haskell wiki has [[Research papers/Monads and Arrows|links to many additional research papers relating to <code>Arrow</code>s]].<br />
<br />
=Comonad=<br />
<br />
The final type class we will examine is <code>Comonad</code>. The <code>Comonad</code> class<br />
is the categorical dual of <code>Monad</code>; that is, <code>Comonad</code> is like <code>Monad</code><br />
but with all the function arrows flipped. It is not actually in the<br />
standard Haskell libraries, but it has seen some interesting uses<br />
recently, so we include it here for completeness.<br />
<br />
==Definition==<br />
<br />
The <code>Comonad</code> type class, defined in the <code>Control.Comonad</code> module of<br />
the [http://hackage.haskell.org/package/comonad comonad library], is:<br />
<br />
<haskell><br />
class Functor w => Comonad w where<br />
extract :: w a -> a<br />
<br />
duplicate :: w a -> w (w a)<br />
duplicate = extend id<br />
<br />
extend :: (w a -> b) -> w a -> w b<br />
extend f = fmap f . duplicate<br />
</haskell><br />
<br />
As you can see, <code>extract</code> is the dual of <code>return</code>, <code>duplicate</code> is the dual of <code>join</code>, and <code>extend</code> is the dual of <code>(=<<)</code>. The definition of <code>Comonad</code> is a bit redundant, giving the programmer the choice on whether extend or duplicate are implemented; the other operation then has a default implementation.<br />
<br />
A prototypical example of a <code>Comonad</code> instance is:<br />
<br />
<haskell><br />
-- Infinite lazy streams<br />
data Stream a = Cons a (Stream a)<br />
<br />
-- 'duplicate' is like the list function 'tails'<br />
-- 'extend' computes a new Stream from an old, where the element<br />
-- at position n is computed as a function of everything from<br />
-- position n onwards in the old Stream<br />
instance Comonad Stream where<br />
extract (Cons x _) = x<br />
duplicate s@(Cons x xs) = Cons s (duplicate xs)<br />
extend g s@(Cons x xs) = Cons (g s) (extend g xs)<br />
-- = fmap g (duplicate s)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Dan Piponi explains in a blog post what [http://blog.sigfpe.com/2006/12/evaluating-cellular-automata-is.html cellular automata have to do with comonads]. In another blog post, Conal Elliott has examined [http://conal.net/blog/posts/functional-interactive-behavior/ a comonadic formulation of functional reactive programming]. Sterling Clover’s blog post [http://fmapfixreturn.wordpress.com/2008/07/09/comonads-in-everyday-life/ Comonads in everyday life] explains the relationship between comonads and zippers, and how comonads can be used to design a menu system for a web site.<br />
<br />
Uustalu and Vene have a number of papers exploring ideas related to comonads and functional programming:<br />
* [http://dx.doi.org/10.1016/j.entcs.2008.05.029 Comonadic Notions of Computation]<br />
* [http://www.ioc.ee/~tarmo/papers/sfp01-book.pdf The dual of substitution is redecoration] (Also available as [http://www.cs.ut.ee/~varmo/papers/sfp01-book.ps.gz ps.gz].)<br />
* [http://dx.doi.org/10.1016/j.ic.2005.08.005 Recursive coalgebras from comonads]<br />
* [http://www.fing.edu.uy/~pardo/papers/njc01.ps.gz Recursion schemes from comonads]<br />
* [http://cs.ioc.ee/~tarmo/papers/essence.pdf The Essence of Dataflow Programming].<br />
<br />
Gabriel Gonzalez's [http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html Comonads are objects] points out similarities between comonads and object-oriented programming.<br />
<br />
The [http://hackage.haskell.org/package/comonad-transformers comonad-transformers] package contains comonad transformers.<br />
<br />
=Acknowledgements=<br />
<br />
A special thanks to all of those who taught me about standard Haskell<br />
type classes and helped me develop good intuition for them,<br />
particularly Jules Bean (quicksilver), Derek Elkins (ddarius), Conal<br />
Elliott (conal), Cale Gibbard (Cale), David House, Dan Piponi<br />
(sigfpe), and Kevin Reid (kpreid).<br />
<br />
I also thank the many people who provided a mountain of helpful<br />
feedback and suggestions on a first draft of the Typeclassopedia: David Amos,<br />
Kevin Ballard, Reid Barton, Doug Beardsley, Joachim Breitner, Andrew<br />
Cave, David Christiansen, Gregory Collins, Mark Jason Dominus, Conal<br />
Elliott, Yitz Gale, George Giorgidze, Steven Grady, Travis Hartwell,<br />
Steve Hicks, Philip Hölzenspies, Edward Kmett, Eric Kow, Serge Le<br />
Huitouze, Felipe Lessa, Stefan Ljungstrand, Eric Macaulay, Rob MacAulay, Simon Meier,<br />
Eric Mertens, Tim Newsham, Russell O’Connor, Conrad Parker, Walt<br />
Rorie-Baety, Colin Ross, Tom Schrijvers, Aditya Siram, C. Smith,<br />
Martijn van Steenbergen, Joe Thornber, Jared Updike, Rob Vollmert,<br />
Andrew Wagner, Louis Wasserman, and Ashley Yakeley, as well as a few<br />
only known to me by their IRC nicks: b_jonas, maltem, tehgeekmeister,<br />
and ziman. I have undoubtedly omitted a few inadvertently, which in<br />
no way diminishes my gratitude.<br />
<br />
Finally, I would like to thank Wouter Swierstra for his fantastic work<br />
editing the Monad.Reader, and my wife Joyia for her patience during<br />
the process of writing the Typeclassopedia.<br />
<br />
=About the author=<br />
<br />
Brent Yorgey ([http://byorgey.wordpress.com/ blog], [http://www.cis.upenn.edu/~byorgey/ homepage]) is (as of November 2011) a fourth-year Ph.D. student in the [http://www.cis.upenn.edu/~plclub/ programming languages group] at the [http://www.upenn.edu University of Pennsylvania]. He enjoys teaching, creating EDSLs, playing Bach fugues, musing upon category theory, and cooking tasty lambda-treats for the denizens of #haskell.<br />
<br />
=Colophon=<br />
<br />
The Typeclassopedia was written by Brent Yorgey and initially published in March 2009. Painstakingly converted to wiki syntax by [[User:Geheimdienst]] in November 2011, after asking Brent’s permission.<br />
<br />
If something like this TeX to wiki syntax conversion ever needs to be done again, here are some vim commands that helped:<br />
<br />
* <nowiki>%s/\\section{\([^}]*\)}/=\1=/gc</nowiki><br />
* <nowiki>%s/\\subsection{\([^}]*\)}/==\1==/gc</nowiki><br />
* <nowiki>%s/^ *\\item /\r* /gc</nowiki><br />
* <nowiki>%s/---/—/gc</nowiki><br />
* <nowiki>%s/\$\([^$]*\)\$/<math>\1\\ <\/math>/gc</nowiki> ''Appending “\ ” forces images to be rendered. Otherwise, Mediawiki would go back and forth between one font for short <nowiki><math></nowiki> tags, and another more Tex-like font for longer tags (containing more than a few characters)""<br />
* <nowiki>%s/|\([^|]*\)|/<code>\1<\/code>/gc</nowiki><br />
* <nowiki>%s/\\dots/.../gc</nowiki><br />
* <nowiki>%s/^\\label{.*$//gc</nowiki><br />
* <nowiki>%s/\\emph{\([^}]*\)}/''\1''/gc</nowiki><br />
* <nowiki>%s/\\term{\([^}]*\)}/''\1''/gc</nowiki><br />
<br />
The biggest issue was taking the academic-paper-style citations and turning them into hyperlinks with an appropriate title and an appropriate target. In most cases there was an obvious thing to do (e.g. online PDFs of the cited papers or CiteSeer entries). Sometimes, however, it’s less clear and you might want to check the<br />
[[Media:Typeclassopedia.pdf|original Typeclassopedia PDF]]<br />
with the<br />
[http://code.haskell.org/~byorgey/TMR/Issue13/typeclassopedia.bib original bibliography file].<br />
<br />
To get all the citations into the main text, I first tried processing the source with TeX or Lyx. This didn’t work due to missing unfindable packages, syntax errors, and my general ineptitude with Tex.<br />
<br />
I then went for the next best solution, which seemed to be extracting all instances of “\cite{something}” from the source and ''in that order'' pulling the referenced entries from the .bib file. This way you can go through the source file and sorted-references file in parallel, copying over what you need, without searching back and forth in the .bib file. I used:<br />
<br />
* <nowiki>egrep -o "\cite\{[^\}]*\}" ~/typeclassopedia.lhs | cut -c 6- | tr "," "\n" | tr -d "}" > /tmp/citations</nowiki><br />
* <nowiki>for i in $(cat /tmp/citations); do grep -A99 "$i" ~/typeclassopedia.bib|egrep -B99 '^\}$' -m1 ; done > ~/typeclasso-refs-sorted</nowiki><br />
<br />
[[Category:Applicative Functor]]<br />
[[Category:Arrow]]<br />
[[Category:Functor]]<br />
[[Category:Monad]]<br />
[[Category:Standard classes]]<br />
[[Category:Standard libraries]]<br />
[[Category:Standard packages]]<br />
[[Category:Standard types]]</div>Imzhttps://wiki.haskell.org/index.php?title=Web/Servers&diff=59556Web/Servers2015-03-26T09:57:07Z<p>Imz: /* mighttpd / mighttpd2 */ Its performance is comparable to that of nginx</p>
<hr />
<div>[[Category:Web|*]]<br />
{{Web infobox}}<br />
<br />
== happstack-server ==<br />
<br />
happstack-server contains a low-level HTTP backend, and high-level functions for routing requests, examining request data, and generating responses. happstack-server is part of the Happstack framework, but can be used as an independent entity. The low and high level portions of the server are not cleanly separated into different packages, so it is not the best choice if you only need a low-level backend.<br />
<br />
{| class="wikitable"<br />
! License<br />
| BSD3<br />
|-<br />
! Author:<br />
| Happstack team, HAppS LLC<br />
|-<br />
! Maintainer:<br />
| Happstack team <happs@googlegroups.com><br />
|-<br />
! Home page:<br />
| http://happstack.com<br />
|-<br />
! Documentation:<br />
| http://happstack.com/docs<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/happstack Hackage] - [http://patch-tag.com/r/mae/happstack Darcs]<br />
|}<br />
<br />
== Hyena ==<br />
<br />
Hyena is a simple web application container that can be used to run Haskell web applications behind more robust web servers like Apache.<br />
<br />
{| class="wikitable"<br />
! License<br />
| BSD3<br />
|-<br />
! Author<br />
| Johan Tibell <johan.tibell@gmail.com><br />
|-<br />
! Maintainer<br />
| Johan Tibell <johan.tibell@gmail.com><br />
|-<br />
! Announcement<br />
| [http://www.haskell.org/pipermail/haskell-cafe/2009-June/063058.html Haskell Cafe]<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/hyena Hackage] - [http://github.com/tibbe/hyena Github]<br />
|}<br />
<br />
== Snap Server ==<br />
<br />
Part of the Snap framework, the Snap server is similar to Hyena in that it provides a very fast low level web server. From the Hackage package:<br />
<br />
This is the first developer prerelease of the Snap framework. Snap is a simple and fast web development framework and server written in Haskell. For more information or to download the latest version, you can visit the Snap project website at http://snapframework.com/.<br />
<br />
The Snap HTTP server is a high performance, epoll-enabled, iteratee-based web server library written in Haskell. Together with the snap-core library upon which it depends, it provides a clean and efficient Haskell programming interface to the HTTP protocol.<br />
<br />
Higher-level facilities for building web applications (like user/session management, component interfaces, data modeling, etc.) are planned but not yet implemented, so this release will mostly be of interest for those who:<br />
<br />
* need a fast and minimal HTTP API at roughly the same level of abstraction as Java servlets, or<br />
<br />
* are interested in contributing to the Snap Framework project.<br />
<br />
{| class="wikitable"<br />
! License<br />
| BSD3<br />
|-<br />
! Author<br />
| James Sanders, Gregory Collins, Doug Beardsley<br />
|-<br />
! Maintainer<br />
| snap@snapframework.com<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/snap-server Hackage] - [http://github.com/snapframework/snap-server Github]<br />
|}<br />
<br />
== Warp ==<br />
<br />
The fastest Haskell web server, targeting the WAI [[Web/Framework_Interfaces]]<br />
<br />
{| class="wikitable"<br />
! License:<br />
| BSD3<br />
|-<br />
! Author:<br />
| Michael Snoyman <michael@snoyman.com><br />
|-<br />
! Maintainer:<br />
| Michael Snoyman <michael@snoyman.com><br />
|-<br />
! Announcement:<br />
| http://docs.yesodweb.com/blog/announcing-warp<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/warp Hackage] - [http://github.com/softmechanics/warp Github]<br />
|}<br />
<br />
Example:<br />
<br />
<haskell><br />
{-# LANGUAGE OverloadedStrings #-}<br />
<br />
import Network.Wai<br />
import Network.Wai.Handler.Warp<br />
import Network.HTTP.Types (status200)<br />
import Blaze.ByteString.Builder (copyByteString)<br />
import qualified Data.ByteString.UTF8 as BU<br />
import Data.Monoid<br />
<br />
main = do<br />
let port = 3000<br />
putStrLn $ "Listening on port " ++ show port<br />
run port app<br />
<br />
app req respond = respond $<br />
case pathInfo req of<br />
["yay"] -> yay<br />
x -> index x<br />
<br />
yay = responseBuilder status200 [ ("Content-Type", "text/plain") ] $ mconcat $ map copyByteString<br />
[ "yay" ]<br />
<br />
index x = responseBuilder status200 [("Content-Type", "text/html")] $ mconcat $ map copyByteString<br />
[ "<p>Hello from ", BU.fromString $ show x, "!</p>"<br />
, "<p><a href='/yay'>yay</a></p>\n" ]<br />
<br />
</haskell><br />
<br />
== mighttpd / mighttpd2 ==<br />
<br />
High performance web server to handle static files and CGI on WAI/warp. Reverse proxy functionality is also provided to connect web applications behind.<br />
<br />
Its performance is comparable to that of nginx written in C (according to the Monad.Reader article linked below).<br />
<br />
(Initial version of mighttpd didn't use WAI/warp.)<br />
<br />
{| class="wikitable"<br />
! License:<br />
| BSD3<br />
|-<br />
! Author:<br />
| Kazu Yamamoto <kazu@iij.ad.jp><br />
|-<br />
! Maintainer:<br />
| Kazu Yamamoto <kazu@iij.ad.jp><br />
|-<br />
! Announcement:<br />
| https://themonadreader.wordpress.com/2011/10/26/issue-19/<br />
|-<br />
! Package & repositories<br />
| [https://hackage.haskell.org/package/mighttpd2 Hackage] - [http://www.mew.org/~kazu/proj/mighttpd/ Homepage]<br />
|}</div>Imzhttps://wiki.haskell.org/index.php?title=Web/Libraries/XML_and_HTML&diff=59555Web/Libraries/XML and HTML2015-03-26T09:02:37Z<p>Imz: /* HTML Templating */ +Lucid; +examples from Chris Done's post for xhtml and blaze-html</p>
<hr />
<div>[[Category:Web|*]]<br />
{{Web infobox}}<br />
{{Formal under construction}}<br />
<br />
'''The libraries on this page need checking and sorting into maintained/not maintained.'''<br />
<br />
== HTML Templating ==<br />
<br />
;[http://hackage.haskell.org/package/xhtml XHtml library]<br />
:This is a version of [http://haskell.org/ghc/docs/latest/html/libraries/base/Text-Html.html Text.Html], modified to produce XHTML 1.0 Transitional.<br />
<br />
Example:<br />
<br />
<haskell><br />
header << thetitle << "Page title"<br />
<br />
thediv noHtml ! [theclass "logo"] << "…"<br />
thediv noHtml ! [identifier "login"]<br />
</haskell><br />
<br />
;[http://hackage.haskell.org/package/blaze-html blaze-html]<br />
Later, for [http://chrisdone.com/posts/lucid some people], blaze-html became the new goto HTML writing library. It improved upon the XHTML package by being faster and having a convenient monad instance. It looks like this:<br />
<br />
<haskell><br />
page1 = html $ do<br />
head $ do<br />
title "Introduction page."<br />
link ! rel "stylesheet" ! type_ "text/css" ! href "screen.css"<br />
body $ do<br />
div ! id "header" $ "Syntax"<br />
p "This is an example of BlazeMarkup syntax."<br />
ul $ mapM_ (li . toMarkup . show) [1, 2, 3]<br />
</haskell><br />
<br />
;[http://www.dtek.chalmers.se/~tumm/vieux/ Vieux: A Nevow implementation]<br />
:Vieux is a html-template system for Haskell. The basic idea is to define a xhtml template which is used to generate a xhtml document by Vieux.<br />
<br />
;[http://www.wellquite.org/chunks/ Text.HTML.Chunks]<br />
:Text.HTML.Chunks is a templating system inspired by the Perl HTML::Chunks module. The major change for the Haskell version is that the use of the templates is statically verified.<br />
<br />
;[http://hackage.haskell.org/package/lucid lucid]<br />
Wanting to improve on Xhtml and Blaze-html, Chris Done [http://chrisdone.com/posts/lucid wrote Lucid] ([http://www.reddit.com/r/haskell/comments/2my5bc/lucid_templating_dsl_for_html/ reddit discussion]); a bit later, he [http://chrisdone.com/posts/lucid2 updated] Lucid to major version 2.0 in a way that removes the need for the with combinator.<br />
<br />
Example:<br />
<br />
<haskell><br />
page :: Html ()<br />
page =<br />
html_<br />
(do head_<br />
(do title_ "Introduction page."<br />
link_ [rel_ "stylesheet",type_ "text/css",href_ "screen.css"]<br />
style_ "body{background:red}")<br />
body_<br />
(do div_ [id_ "header",style_ "color:white"] "Syntax"<br />
p_ (span_ (strong_ "This is an example of Lucid syntax."))<br />
hr_ []<br />
ul_ (mapM_ (li_ . toHtml . show)<br />
[1,2,3])<br />
table_ (tr_ (do td_ "Hello!"<br />
td_ [class_ "alt"] "World!"<br />
td_ "Sup?"))))<br />
</haskell><br />
<br />
== HTML Parsing ==<br />
<br />
;[http://community.haskell.org/~ndm/tagsoup/ TagSoup]<br />
: TagSoup is a library for extracting information out of unstructured HTML code, sometimes known as tag-soup. The HTML does not have to be well formed, or render properly within any particular framework. This library is for situations where the author of the HTML is not cooperating with the person trying to extract the information, but is also not trying to hide the information. The library provides a basic data type for a list of unstructured tags, a parser to convert HTML into this tag type, and useful functions and combinators for finding and extracting information.<br />
<br />
== XML ==<br />
<br />
;[http://www.cs.york.ac.uk/fp/HaXml/ HaXml: utilities for using XML with Haskell]<br />
:Includes an XML parser, an HTML parser, a pretty-printer, a combinator library for generic XML transformations, and two Haskell&gt;-&lt;XML converters using type-based translation.<br />
<br />
;[http://www.fh-wedel.de/~si/HXmlToolbox/ HXT: Haskell XML Toolbox]<br />
:The Haskell XML Toolbox (HXT) bases on the ideas of HaXml and HXML, but introduces a more general approach based on arrows for processing XML with Haskell. The Haskell XML Toolbox uses a generic data model for representing XML documents, including the DTD subset and the document subset, in Haskell. It contains an XML parser, an HTML parser, namespaces are supported, XPath expressions can be used for selecting and transforming parts of a document. Validation can be performed with respect to DTDs and RelaxNG schema. A [[HXT|Getting started page]] describes the programming model behind HXT and gives some simple examples.<br />
<br />
;[http://darcs.haskell.org/wraxml WraXML]<br />
:A little wrapper to HaXML and HXT: It provides a more natural data structure for representing XML trees, and converts between HaXML or HXT and its custom tree structure. The operations on the tree need not to be of type (a -> [a]), thus using these functions is a bit more type safe. It has a custom lazy HTML parser using TagSoup and a custom lazy formatter. The library is currently much oriented to HTML rather than XML.<br />
<br />
;[http://wiki.di.uminho.pt/wiki/bin/view/PURe/2LT 2LT: Two-Level Transformation]<br />
:A two-level data transformation consists of a type-level transformation of a data format coupled with value-level transformations of data instances corresponding to that format. Examples of two-level data transformations include XML schema evolution coupled with document migration, and data mappings used for interoperability and persistence. A library of two-level transformation combinators. These combinators are used to compose transformation systems which, when applied to an input type, produce an output type, together with the conversion functions that mediate between input and out types. Front-ends for XML and SQL. These front-ends support (i) reading a schema, (ii) applying a two-level transformation system to produce a new schema, (iii) convert a document/database corresponding to the input schema to a document/database corresponding to the output schema, and vice versa. Referential constraints and primary key information are propagated through the schema transformation.<br />
<br />
;[http://www.mail-archive.com/haskell@haskell.org/msg18396.html HSXML]<br />
:A direct Haskell embedding of SXML<br />
<br />
;[http://m13s07.vlinux.de/darcs/StaticDTD/v2/ StaticDTD]<br />
:StaticDTD: complete static validness against a DTD.</div>Imzhttps://wiki.haskell.org/index.php?title=Web/Servers&diff=59553Web/Servers2015-03-26T08:38:12Z<p>Imz: + mighttpd2</p>
<hr />
<div>[[Category:Web|*]]<br />
{{Web infobox}}<br />
<br />
== happstack-server ==<br />
<br />
happstack-server contains a low-level HTTP backend, and high-level functions for routing requests, examining request data, and generating responses. happstack-server is part of the Happstack framework, but can be used as an independent entity. The low and high level portions of the server are not cleanly separated into different packages, so it is not the best choice if you only need a low-level backend.<br />
<br />
{| class="wikitable"<br />
! License<br />
| BSD3<br />
|-<br />
! Author:<br />
| Happstack team, HAppS LLC<br />
|-<br />
! Maintainer:<br />
| Happstack team <happs@googlegroups.com><br />
|-<br />
! Home page:<br />
| http://happstack.com<br />
|-<br />
! Documentation:<br />
| http://happstack.com/docs<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/happstack Hackage] - [http://patch-tag.com/r/mae/happstack Darcs]<br />
|}<br />
<br />
== Hyena ==<br />
<br />
Hyena is a simple web application container that can be used to run Haskell web applications behind more robust web servers like Apache.<br />
<br />
{| class="wikitable"<br />
! License<br />
| BSD3<br />
|-<br />
! Author<br />
| Johan Tibell <johan.tibell@gmail.com><br />
|-<br />
! Maintainer<br />
| Johan Tibell <johan.tibell@gmail.com><br />
|-<br />
! Announcement<br />
| [http://www.haskell.org/pipermail/haskell-cafe/2009-June/063058.html Haskell Cafe]<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/hyena Hackage] - [http://github.com/tibbe/hyena Github]<br />
|}<br />
<br />
== Snap Server ==<br />
<br />
Part of the Snap framework, the Snap server is similar to Hyena in that it provides a very fast low level web server. From the Hackage package:<br />
<br />
This is the first developer prerelease of the Snap framework. Snap is a simple and fast web development framework and server written in Haskell. For more information or to download the latest version, you can visit the Snap project website at http://snapframework.com/.<br />
<br />
The Snap HTTP server is a high performance, epoll-enabled, iteratee-based web server library written in Haskell. Together with the snap-core library upon which it depends, it provides a clean and efficient Haskell programming interface to the HTTP protocol.<br />
<br />
Higher-level facilities for building web applications (like user/session management, component interfaces, data modeling, etc.) are planned but not yet implemented, so this release will mostly be of interest for those who:<br />
<br />
* need a fast and minimal HTTP API at roughly the same level of abstraction as Java servlets, or<br />
<br />
* are interested in contributing to the Snap Framework project.<br />
<br />
{| class="wikitable"<br />
! License<br />
| BSD3<br />
|-<br />
! Author<br />
| James Sanders, Gregory Collins, Doug Beardsley<br />
|-<br />
! Maintainer<br />
| snap@snapframework.com<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/snap-server Hackage] - [http://github.com/snapframework/snap-server Github]<br />
|}<br />
<br />
== Warp ==<br />
<br />
The fastest Haskell web server, targeting the WAI [[Web/Framework_Interfaces]]<br />
<br />
{| class="wikitable"<br />
! License:<br />
| BSD3<br />
|-<br />
! Author:<br />
| Michael Snoyman <michael@snoyman.com><br />
|-<br />
! Maintainer:<br />
| Michael Snoyman <michael@snoyman.com><br />
|-<br />
! Announcement:<br />
| http://docs.yesodweb.com/blog/announcing-warp<br />
|-<br />
! Package & repositories<br />
| [http://hackage.haskell.org/package/warp Hackage] - [http://github.com/softmechanics/warp Github]<br />
|}<br />
<br />
Example:<br />
<br />
<haskell><br />
{-# LANGUAGE OverloadedStrings #-}<br />
<br />
import Network.Wai<br />
import Network.Wai.Handler.Warp<br />
import Network.HTTP.Types (status200)<br />
import Blaze.ByteString.Builder (copyByteString)<br />
import qualified Data.ByteString.UTF8 as BU<br />
import Data.Monoid<br />
<br />
main = do<br />
let port = 3000<br />
putStrLn $ "Listening on port " ++ show port<br />
run port app<br />
<br />
app req respond = respond $<br />
case pathInfo req of<br />
["yay"] -> yay<br />
x -> index x<br />
<br />
yay = responseBuilder status200 [ ("Content-Type", "text/plain") ] $ mconcat $ map copyByteString<br />
[ "yay" ]<br />
<br />
index x = responseBuilder status200 [("Content-Type", "text/html")] $ mconcat $ map copyByteString<br />
[ "<p>Hello from ", BU.fromString $ show x, "!</p>"<br />
, "<p><a href='/yay'>yay</a></p>\n" ]<br />
<br />
</haskell><br />
<br />
== mighttpd / mighttpd2 ==<br />
<br />
High performance web server to handle static files and CGI on WAI/warp. Reverse proxy functionality is also provided to connect web applications behind.<br />
<br />
(Initial version of mighttpd didn't use WAI/warp.)<br />
<br />
{| class="wikitable"<br />
! License:<br />
| BSD3<br />
|-<br />
! Author:<br />
| Kazu Yamamoto <kazu@iij.ad.jp><br />
|-<br />
! Maintainer:<br />
| Kazu Yamamoto <kazu@iij.ad.jp><br />
|-<br />
! Announcement:<br />
| https://themonadreader.wordpress.com/2011/10/26/issue-19/<br />
|-<br />
! Package & repositories<br />
| [https://hackage.haskell.org/package/mighttpd2 Hackage] - [http://www.mew.org/~kazu/proj/mighttpd/ Homepage]<br />
|}</div>Imzhttps://wiki.haskell.org/index.php?title=Talk:All_About_Monads&diff=59463Talk:All About Monads2015-02-27T14:59:12Z<p>Imz: /* ST monad not covered */ new section</p>
<hr />
<div>== ST monad not covered ==<br />
<br />
I was looking for a Haskell abstraction that would suit my needs (an FFI library), and I suspect that ST would be the one (need to elaborate), but since this article doesn't describe it, I had the impression that although the idea (of ST) is simple, there is no such standard thing in Haskell.--[[User:Imz|Imz]] ([[User talk:Imz|talk]]) 14:59, 27 February 2015 (UTC)</div>Imzhttps://wiki.haskell.org/index.php?title=Applications_and_libraries/Linguistics&diff=59431Applications and libraries/Linguistics2015-02-22T08:38:17Z<p>Imz: /* Other functional or Haskell-related approaches to linguistics */ take a look at a section in "A History of Haskell: Being Lazy With Class"</p>
<hr />
<div>__TOC__<br />
<br />
== Portals and other huge resources ==<br />
<br />
Peter Ljunglöf's many [http://www.cse.chalmers.se/~peb/bibliography.html publications] on natural language processing, parsing, formal semantics. Many of them use Haskell, and there are [http://www.ling.gu.se/~peb/software.html downloadable] Haskell sources too.<br />
<br />
[http://homepages.cwi.nl/~jve/index.html Jan van Eijck's page] contains a huge amount of materials on logic and language:<br />
* computational linguistics<br />
* logics (e.g. dynamic epistemic modelling)<br />
<br />
The [http://projects.haskell.org/nlp Haskell NLP projects] provides a mailing list for Haskellers doing NLP work, as well as a community wiki and darcs repository. Come join us!<br />
<br />
[http://nlpwp.org/ Natural Language Processing for The Working Programmer] is a book that provides an introduction to Haskell and NLP.<br />
<br />
There are many Haskell resources, too.<br />
<br />
== Tools and libraries ==<br />
<br />
* [http://www.w3.org/wiki/Cypher Cypher] is one of the first software program available which generates the metadata representation of natural language input. Cypher produces RDF graph and SeRQL query representations of sentences, clauses, phrases and questions. The Cypher framework provides a set of robust definition languages, which can be used to extend and create grammars and lexicons. Cypher programming is fun to learn and easy to use, and the specifications are designed to allow a novice to quickly and easily build transcoders for processing highly complex sentences and phrases of any natural language, and to cover any vocabulary<br />
* [http://trac.loria.fr/~geni GenI] is a surface realiser for Tree Adjoining Grammars. Surface realisation can be seen as the last stage in a natural language generation pipeline. GenI in particular takes an FB-LTAG grammar and an input semantics (a conjunction of first order terms), and produces the set of sentences associated to the input semantics by the grammar. See also [http://www.loria.fr/~kow/ Eric Kow]'s recent publications on it.<br />
* [http://grammaticalframework.org/ Grammatical Framework] (GF) is a compiler and grammatical programming environment written entirely in Haskell, with an interactive interpreter and two GUI interfaces, one written in Fudgets and another written in Java. GF grammars are written in a subset of Haskell and compile into an internal GF format that may be used as embedded parsers in Haskell, parsers in Java (with an embedded Java interpreter gfc2java.jar) and subsequently converted to applets ([http://www.cs.chalmers.se/~markus/gramlets/ Gramlets]). (GF-Haskell to Java translation is performed through an Open Agent Architecture--the original .NET, see [http://www.cs.chalmers.se/~bringert/gf/gf-oaa.html GF OAA].) The GF grammatical formalism handles linguistic entities (morphemes, etc.) using type theory: an approach especially suited to machine translation of controlled natural languages. The [http://www.cs.chalmers.se/~aarne/GF/lib/resource-1.0/doc/index.html Grammar Resource Library], a set of basic grammars for Danish, English, Finnish, French, German, Italian, Norwegian, Russian, Spanish and Swedish, is available as a separate download. GF has been used to translate a fragment of C code to JVM (see [http://www.cs.chalmers.se/~aarne/GF/doc/gfcc.pdf GFCC (PDF document)]).<br />
* [http://www.cs.chalmers.se/~markus/FM/index.html Functional Morphology] - a toolkit for morphology development. Has been used for Swedish, Spanish, Urdu and more.<br />
* [http://www.umiacs.umd.edu/~hal/HWordNet/ HWordNet] - A Haskell interface to WordNet by Hal Daumé III.<br />
* '''Saxophone''' is a fun translator from German to the Saxon dialect. It is part of the [https://sourceforge.net/projects/parallelweb ParallelWeb] project which aims at translating Web pages including all of their links.<br />
<br />
== Natural language processing and combinatory logic ==<br />
<br />
[[Combinatory logic]] contributed to develop powerful theories in linguistics..<br />
<br />
=== Applicative universal grammar ===<br />
<br />
Now it has got [[/Applicative universal grammar|its own HaskellWiki page]].<br />
<br />
=== Categorial grammar ===<br />
<br />
A general summary of modern semantic theories developed in the century<br />
is provided by [http://citeseer.ist.psu.edu/blackburn97logical.html Logical Aspects of Computational Linguistics: an introduction].<br />
<br />
[http://www-unix.oit.umass.edu/~gmhwww/ Gary Hardegree]'s portal-rich page provides a lot of materials on logic and linguistics, among them<br />
* [http://www-unix.oit.umass.edu/~gmhwww/scholar.htm The Axiomatic Theory of Truth] grasping concepts like truth, quotations, paradoxes, liar's paradox<br />
* [http://www-unix.oit.umass.edu/~gmhwww/scholar.htm Courses] ranging from the introductory level to developed topics, e.g. [http://www-unix.oit.umass.edu/~gmhwww/511/pdf/a3.pdf Basic Categorial Grammar].<br />
<br />
[http://groups.inf.ed.ac.uk/ccg/ The Combinatory Categorial Grammar Site] contains links, papers (both introductory and developed) and software ([http://opennlp.sourceforge.net/ OpenNLP] open source projects, related to natural language processing, and [http://openccg.sourceforge.net/ OpenCCG])<br />
<br />
On natural languages relating to combinatory logic, see also<br />
* Mark Steedman's [http://citeseer.ist.psu.edu/steedman97does.html Does Grammar Make Use of Bound Variables?]<br />
* Mark Hepple: [http://citeseer.ist.psu.edu/hepple90grammar.html The Grammar and Processing of Order and Dependency: a Categorial Approach]<br />
<br />
=== Type-Logical Grammar ===<br />
<br />
Matteo Capelletti's [http://www.let.uu.nl/users/Matteo.Capelletti/personal/Home.html home page] contains a parser based on the Non-associative Lambek calculus. It supports hypothetical reasoning and Montague style semantics. <br />
<br />
=== Tree Adjoining Grammar ===<br />
<br />
* See [http://trac.loria.fr/~geni GenI], mentioned above.<br />
<br />
== Game theoretic semantics ==<br />
<br />
Game theoretic semantics presents an interesting concept of ''truth'' -- in another way than that of Tarski.<br />
Its connections to computer science and computer languages is described in Wikipedia's [http://en.wikipedia.org/wiki/Game_semantics Game semantics] article. Merlijn Sevenster's [http://staff.science.uva.nl/~peter/teaching/merlijns20041129.pdf Game theoretical semantics and -logic] is a good introductory material too.<br />
<br />
Chiaki Ohkura's [http://acl.ldc.upenn.edu/W/W03/W03-1408.pdf The Semantics of Metaphor in the Game Theoretic Semantics with at Least Two Coordination Equilibria] article tries to catch the concept of ''metaphor''.<br />
<br />
=== Relatedness to linear logic ===<br />
<br />
The Wikipedia article mentions also the relatedness of game theoretic semantics to ''linear logic''.<br />
[http://homepages.inf.ed.ac.uk/wadler/ Philip Wadler]'s page on [http://homepages.inf.ed.ac.uk/wadler/topics/linear-logic.html linear logic] describes the topic and its relatedness to many concepts concerning Haskell. [http://homepages.inf.ed.ac.uk/wadler/topics/linear-logic.html#lineartaste A taste of linear logic] can serve as an introductory article.<br />
<br />
== Parsing natural languages ==<br />
===Parsing Natural Language with X-SAIGA parser===<br />
<br />
The goal of the [http://www.cs.uwindsor.ca/~hafiz/proHome.html X-SAIGA] project is to create algorithms and implementations which enable the construction of language processors (recognizers, parsers, interpreters, translators, etc.) to be constructed as modular and efficient embedded executable specifications of grammars. The syntax analysis is done with a set of parser combinators by overcoming some long standing limitations -<br />
# the simple implementations of parser combinators require [[exponential]] time and space when parsing an ambiguous context free grammar.<br />
# like any top-down recursive descent parsing, the conventional parser combinators won't terminate while processing a left-recursive grammar (i.e. <code>s ::= s *> s *> term 'x'|empty</code>).<br />
<br />
As a part of the X-SAIGA project's syntax analysis, a [http://cs.uwindsor.ca/~hafiz/p46-frost.pdf recognition algorithm] that accommodates ambiguous grammars with direct [[left recursion|left-recursive]] rules is described by Frost and Hafiz in 2006. The algorithm curtails the otherwise ever-growing left-recursive parse by imposing depth restrictions. That algorithm was extended to a complete [http://cs.uwindsor.ca/~hafiz/iwpt-07.pdf parsing algorithm] to accommodate indirect as well as direct left-recursion in [[polynomial]] time, and to generate compact polynomial-size representations of the potentially-exponential number of parse trees for highly-ambiguous grammars by Frost, Hafiz and Callaghan in 2007. This extended algorithm accommodates indirect left-recursion by comparing its 'computed-context' with 'current-context'. The same authors also [http://cs.uwindsor.ca/~hafiz/PADL_PAPER_FINAL.pdf described their implementation of a set of parser combinators] written in the [[Haskell]] programming language based on the same algorithm in [http://www.ist.unomaha.edu/padl2008/ PADL 08]. The [http://www.cs.uwindsor.ca/~hafiz/proHome.html X-SAIGA] site has more about the algorithms, implementation details experimental results.<br />
<br />
===Monadic Compositional Parsing===<br />
Gordon J. Pace: [http://www.cs.um.edu.mt/~csaw/CSAW04/Proceedings/08.pdf Monadic Compositional Parsing with Context Using Maltese as a Case Study], see its [http://www.cs.um.edu.mt/~csaw/CSAW04/ context] too.<br />
<br />
== Other functional or Haskell-related approaches to linguistics ==<br />
<br />
* [http://cs.uwindsor.ca/~richard/PUBLICATIONS/NLI_LFP_SURVEY_DRAFT.pdf A Survey on the Use of Haskell in Natural-Language Processing] (Report by Richard A. Frost). It is also a part of Haskell Communities and Activities Report, [http://www.haskell.org/communities/11-2006/html/report.html Eleventh edition – November 30, 2006].<br />
* [http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf A History of Haskell: Being Lazy With Class] (2007) has a section (11.5 on page 40) with material contributed by Paul Callaghan on applications of Haskell to natural-language processing. Perhaps, there are some projects mentioned there which are not (yet) listed here on this page; so take a look.<br />
* From [http://www.cs.chalmers.se/~aarne/ Aarne Ranta's homepage]<br />
** [http://www.cs.chalmers.se/~aarne/course-langtech/ Natural Language Technology], with (among others) [http://www.cs.chalmers.se/~aarne/course-langtech/lectures/lectures.html online course slides]. They give huge insights, for example, see the slide example which discusses [[Dependent type#Type theory|the concept of dependent type and Curry Howard isomorphism]] in lingustical context.<br />
* The [http://sanskrit.inria.fr/ZEN/ Zen Computational Linguistics Toolkit] has tools for efficiently processing linguistic data structures, like trees and automata. It's written in Literate O'Caml, though a Haskell port shouldn't be very hard to do.<br />
* The [http://nlpers.blogspot.com/ natural language processing blog] written by [http://www.isi.edu/~hdaume/ Hal Daume III].<br />
<br />
== Other linguistics-related resources ==<br />
<br />
Dr. [http://www.haskell.org/haskellwiki/Libraries_and_tools/Linguistics Günter Neumann]'s homepage.<br />
<br />
== Specific topics ==<br />
<br />
=== Lojban ===<br />
<br />
Lojban, an artificial language ([[Lojban|see a separate HaskellWiki page on it with references]].) “Lojban was not designed primarily to be an international language, however, but rather as a linguistic tool for studying and understanding language. Its linguistic and computer applications make Lojban unique among international languages...” (NC:WhLoj, page 15 par 1)<br />
<br />
=== Continuations in natural languages ===<br />
<br />
Some phenomena in natural languages can be grasped with the notion of [[continuation]]. For details, see<br />
Chris Barker's paper [http://www.cs.bham.ac.uk/~hxt/cw04/barker.pdf Continuations in Natural Language]. It is quite accessible to non-linguists.<br />
== References ==<br />
<br />
;barker2004cnl<br />
:Barker, Chris: [http://www.cs.bham.ac.uk/~hxt/cw04/barker.pdf Continuations in Natural Language] (pdf), 2004<br />
;nicholas2003wl<br />
:Nicholas, Nick and Cowan, John (ed.): What is Lojban? [http://www.lojban.org/ Logical Language Group], 2003. Available also [http://www.lojban.org/tiki/tiki-index.php?page=What+Is+Lojban%3F%2C+The+Book&bl online].<br />
;frost2006rnl <br />
:Frost, Richard: [http://cs.uwindsor.ca/~richard/PUBLICATIONS/NLI_LFP_SURVEY_DRAFT.pdf Realization of natural language interfaces using lazy functional programming] (pdf), 2006<br />
;frost2008pal<br />
:Frost, Richard; Hafiz, Rahmatullah and Callaghan, Paul: [http://cs.uwindsor.ca/~hafiz/PADL_PAPER_FINAL.pdf Parser Combinators for Ambiguous Left-Recursive Grammars.] Proceedings of the 10th International Symposium on Practical Aspects of Declarative Languages (PADL), ACM-SIGPLAN. January 2008, San Francisco, USA.<br />
;xsaiga2008exg<br />
:Frost, Richard; Hafiz, Rahmatullah and Callaghan, Paul: [http://cs.uwindsor.ca/~hafiz/proHome.html X-SAIGA] website - eXecutable SpecificAtIons of GrAmmars.<br />
<br />
[[Category:Theoretical foundations]]</div>Imzhttps://wiki.haskell.org/index.php?title=Typeclassopedia&diff=59129Typeclassopedia2014-11-27T17:50:59Z<p>Imz: /* Further reading */ fixed wikisyntax for external links</p>
<hr />
<div>''By [[User:Byorgey|Brent Yorgey]], byorgey@cis.upenn.edu''<br />
<br />
''Originally published 12 March 2009 in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13] of [http://themonadreader.wordpress.com/ the Monad.Reader]. Ported to the Haskell wiki in November 2011 by [[User:Geheimdienst|Geheimdienst]].''<br />
<br />
''This is now the official version of the Typeclassopedia and supersedes the version published in the Monad.Reader. Please help update and extend it by editing it yourself or by leaving comments, suggestions, and questions on the [[Talk:Typeclassopedia|talk page]].''<br />
<br />
=Abstract=<br />
<br />
The standard Haskell libraries feature a number of type classes with algebraic or category-theoretic underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs.<br />
<br />
The goal of this document is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading.<br />
<br />
=Introduction=<br />
<br />
Have you ever had any of the following thoughts?<br />
* What the heck is a monoid, and how is it different from a mon<u>a</u>d?<br />
<br />
* I finally figured out how to use [[Parsec]] with do-notation, and someone told me I should use something called <code>Applicative</code> instead. Um, what?<br />
<br />
* Someone in the [[IRC channel|#haskell]] IRC channel used <code>(***)</code>, and when I asked Lambdabot to tell me its type, it printed out scary gobbledygook that didn’t even fit on one line! Then someone used <code>fmap fmap fmap</code> and my brain exploded.<br />
<br />
* When I asked how to do something I thought was really complicated, people started typing things like <code>zip.ap fmap.(id &&& wtf)</code> and the scary thing is that they worked! Anyway, I think those people must actually be robots because there’s no way anyone could come up with that in two seconds off the top of their head.<br />
<br />
If you have, look no further! You, too, can write and understand concise, elegant, idiomatic Haskell code with the best of them.<br />
<br />
There are two keys to an expert Haskell hacker’s wisdom:<br />
# Understand the types.<br />
# Gain a deep intuition for each type class and its relationship to other type classes, backed up by familiarity with many examples.<br />
<br />
It’s impossible to overstate the importance of the first; the patient student of type signatures will uncover many profound secrets. Conversely, anyone ignorant of the types in their code is doomed to eternal uncertainty. “Hmm, it doesn’t compile ... maybe I’ll stick in an<br />
<code>fmap</code> here ... nope, let’s see ... maybe I need another <code>(.)</code> somewhere? ... um ...”<br />
<br />
The second key—gaining deep intuition, backed by examples—is also important, but much more difficult to attain. A primary goal of this document is to set you on the road to gaining such intuition. However—<br />
<br />
:''There is no royal road to Haskell. {{h:title|Well, he probably would have said it if he knew Haskell.|—Euclid}}''<br />
<br />
This document can only be a starting point, since good intuition comes from hard work, [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ not from learning the right metaphor]. Anyone who reads and understands all of it will still have an arduous journey ahead—but sometimes a good starting point makes a big difference.<br />
<br />
It should be noted that this is not a Haskell tutorial; it is assumed that the reader is already familiar with the basics of Haskell, including the standard <code>[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html Prelude]</code>, the type system, data types, and type classes.<br />
<br />
The type classes we will be discussing and their interrelationships:<br />
<br />
[[Image:Typeclassopedia-diagram.png]]<br />
<br />
{{note|<code>Semigroup</code> can be found in the [http://hackage.haskell.org/package/semigroups <code>semigroups</code> package], <code>Apply</code> in the [http://hackage.haskell.org/package/semigroupoids <code>semigroupoids</code> package], and <code>Comonad</code> in the [http://hackage.haskell.org/package/comonad <code>comonad</code> package].}}<br />
<br />
* <span style="border-bottom: 2px solid black">Solid arrows</span> point from the general to the specific; that is, if there is an arrow from <code>Foo</code> to <code>Bar</code> it means that every <code>Bar</code> is (or should be, or can be made into) a <code>Foo</code>.<br />
* <span style="border-bottom: 2px dotted black">Dotted arrows</span> indicate some other sort of relationship.<br />
* <code>Monad</code> and <code>ArrowApply</code> are equivalent.<br />
* <code>Semigroup</code>, <code>Apply</code> and <code>Comonad</code> are greyed out since they are not actually (yet?) in the standard Haskell libraries {{noteref}}.<br />
<br />
One more note before we begin. The original spelling of “type class” is with two words, as evidenced by, for example, the [http://www.haskell.org/onlinereport/haskell2010/ Haskell 2010 Language Report], early papers on type classes like [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.5639 Type classes in Haskell] and [http://research.microsoft.com/en-us/um/people/simonpj/papers/type-class-design-space/ Type classes: exploring the design space], and [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.168.4008 Hudak et al.’s history of Haskell]. However, as often happens with two-word phrases that see a lot of use, it has started to show up as one word (“typeclass”) or, rarely, hyphenated (“type-class”). When wearing my prescriptivist hat, I prefer “type class”, but realize (after changing into my descriptivist hat) that there's probably not much I can do about it.<br />
<br />
We now begin with the simplest type class of all: <code>Functor</code>.<br />
<br />
=Functor=<br />
<br />
The <code>Functor</code> class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Functor haddock]) is the most basic and ubiquitous type class in the Haskell libraries. A simple intuition is that a <code>Functor</code> represents a “container” of some sort, along with the ability to apply a function uniformly to every element in the container. For example, a list is a container of elements, and we can apply a function to every element of a list, using <code>map</code>. As another example, a binary tree is also a container of elements, and it’s not hard to come up with a way to recursively apply a function to every element in a tree.<br />
<br />
Another intuition is that a <code>Functor</code> represents some sort of “computational context”. This intuition is generally more useful, but is more difficult to explain, precisely because it is so general. Some examples later should help to clarify the <code>Functor</code>-as-context point of view.<br />
<br />
In the end, however, a <code>Functor</code> is simply what it is defined to be; doubtless there are many examples of <code>Functor</code> instances that don’t exactly fit either of the above intuitions. The wise student will focus their attention on definitions and examples, without leaning too heavily on any particular metaphor. Intuition will come, in time, on its own.<br />
<br />
==Definition==<br />
<br />
Here is the type class declaration for <code>Functor</code>:<br />
<br />
<haskell><br />
class Functor f where<br />
fmap :: (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
<code>Functor</code> is exported by the <code>Prelude</code>, so no special imports are needed to use it.<br />
<br />
First, the <code>f a</code> and <code>f b</code> in the type signature for <code>fmap</code> tell us that <code>f</code> isn’t just a type; it is a ''type constructor'' which takes another type as a parameter. (A more precise way to say this is that the ''kind'' of <code>f</code> must be <code>* -> *</code>.) For example, <code>Maybe</code> is such a type constructor: <code>Maybe</code> is not a type in and of itself, but requires another type as a parameter, like <code>Maybe Integer</code>. So it would not make sense to say <code>instance Functor Integer</code>, but it could make sense to say <code>instance Functor Maybe</code>.<br />
<br />
Now look at the type of <code>fmap</code>: it takes any function from <code>a</code> to <code>b</code>, and a value of type <code>f a</code>, and outputs a value of type <code>f b</code>. From the container point of view, the intention is that <code>fmap</code> applies a function to each element of a container, without altering the structure of the container. From the context point of view, the intention is that <code>fmap</code> applies a function to a value without altering its context. Let’s look at a few specific examples.<br />
<br />
==Instances==<br />
<br />
{{note|Recall that <code>[]</code> has two meanings in Haskell: it can either stand for the empty list, or, as here, it can represent the list type constructor (pronounced “list-of”). In other words, the type <code>[a]</code> (list-of-<code>a</code>) can also be written <code>[] a</code>.}}<br />
<br />
{{note|You might ask why we need a separate <code>map</code> function. Why not just do away with the current list-only <code>map</code> function, and rename <code>fmap</code> to <code>map</code> instead? Well, that’s a good question. The usual argument is that someone just learning Haskell, when using <code>map</code> incorrectly, would much rather see an error about lists than about <code>Functor</code>s.}}<br />
<br />
As noted before, the list constructor <code>[]</code> is a functor {{noteref}}; we can use the standard list function <code>map</code> to apply a function to each element of a list {{noteref}}. The <code>Maybe</code> type constructor is also a functor, representing a container which might hold a single element. The function <code>fmap g</code> has no effect on <code>Nothing</code> (there are no elements to which <code>g</code> can be applied), and simply applies <code>g</code> to the single element inside a <code>Just</code>. Alternatively, under the context interpretation, the list functor represents a context of nondeterministic choice; that is, a list can be thought of as representing a single value which is nondeterministically chosen from among several possibilities (the elements of the list). Likewise, the <code>Maybe</code> functor represents a context with possible failure. These instances are:<br />
<br />
<haskell><br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : fmap g xs<br />
-- or we could just say fmap = map<br />
<br />
instance Functor Maybe where<br />
fmap _ Nothing = Nothing<br />
fmap g (Just a) = Just (g a)<br />
</haskell><br />
<br />
As an aside, in idiomatic Haskell code you will often see the letter <code>f</code> used to stand for both an arbitrary <code>Functor</code> and an arbitrary function. In this document, <code>f</code> represents only <code>Functor</code>s, and <code>g</code> or <code>h</code> always represent functions, but you should be aware of the potential confusion. In practice, what <code>f</code> stands for should always be clear from the context, by noting whether it is part of a type or part of the code.<br />
<br />
There are other <code>Functor</code> instances in the standard libraries; below are a few. Note that some of these instances are not exported by the <code>Prelude</code>; to access them, you can import <code>Control.Monad.Instances</code>.<br />
<br />
* <code>Either e</code> is an instance of <code>Functor</code>; <code>Either e a</code> represents a container which can contain either a value of type <code>a</code>, or a value of type <code>e</code> (often representing some sort of error condition). It is similar to <code>Maybe</code> in that it represents possible failure, but it can carry some extra information about the failure as well.<br />
<br />
* <code>((,) e)</code> represents a container which holds an “annotation” of type <code>e</code> along with the actual value it holds. It might be clearer to write it as <code>(e,)</code>, by analogy with an operator section like <code>(1+)</code>, but that syntax is not allowed in types (although it is allowed in expressions with the <code>TupleSections</code> extension enabled). However, you can certainly ''think'' of it as <code>(e,)</code>.<br />
<br />
* <code>((->) e)</code> (which can be thought of as <code>(e ->)</code>; see above), the type of functions which take a value of type <code>e</code> as a parameter, is a <code>Functor</code>. As a container, <code>(e -> a)</code> represents a (possibly infinite) set of values of <code>a</code>, indexed by values of <code>e</code>. Alternatively, and more usefully, <code>((->) e)</code> can be thought of as a context in which a value of type <code>e</code> is available to be consulted in a read-only fashion. This is also why <code>((->) e)</code> is sometimes referred to as the ''reader monad''; more on this later.<br />
<br />
* <code>IO</code> is a <code>Functor</code>; a value of type <code>IO a</code> represents a computation producing a value of type <code>a</code> which may have I/O effects. If <code>m</code> computes the value <code>x</code> while producing some I/O effects, then <code>fmap g m</code> will compute the value <code>g x</code> while producing the same I/O effects.<br />
<br />
* Many standard types from the [http://hackage.haskell.org/package/containers/ containers library] (such as <code>Tree</code>, <code>Map</code>, and <code>Sequence</code>) are instances of <code>Functor</code>. A notable exception is <code>Set</code>, which cannot be made a <code>Functor</code> in Haskell (although it is certainly a mathematical functor) since it requires an <code>Ord</code> constraint on its elements; <code>fmap</code> must be applicable to ''any'' types <code>a</code> and <code>b</code>. However, <code>Set</code> (and other similarly restricted data types) can be made an instance of a suitable generalization of <code>Functor</code>, either by [http://article.gmane.org/gmane.comp.lang.haskell.cafe/78052/ making <code>a</code> and <code>b</code> arguments to the <code>Functor</code> type class themselves], or by adding an [http://blog.omega-prime.co.uk/?p=127 associated constraint].<br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement <code>Functor</code> instances for <code>Either e</code> and <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> instances for <code>((,) e)</code> and for <code>Pair</code>, defined as <br />
<br />
<haskell>data Pair a = Pair a a</haskell><br />
<br />
Explain their similarities and differences.<br />
</li><br />
<li>Implement a <code>Functor</code> instance for the type <code>ITree</code>, defined as<br />
<br />
<haskell><br />
data ITree a = Leaf (Int -> a) <br />
| Node [ITree a]<br />
</haskell><br />
</li><br />
<li>Give an example of a type of kind <code>* -> *</code> which cannot be made an instance of <code>Functor</code> (without using <code>undefined</code>).<br />
</li><br />
<li>Is this statement true or false? <br />
<br />
:''The composition of two <code>Functor</code>s is also a <code>Functor</code>.''<br />
<br />
If false, give a counterexample; if true, prove it by exhibiting some appropriate Haskell code.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Laws==<br />
<br />
As far as the Haskell language itself is concerned, the only requirement to be a <code>Functor</code> is an implementation of <code>fmap</code> with the proper type. Any sensible <code>Functor</code> instance, however, will also satisfy the ''functor laws'', which are part of the definition of a mathematical functor. There are two:<br />
<br />
<haskell><br />
fmap id = id<br />
fmap (g . h) = (fmap g) . (fmap h)<br />
</haskell><br />
<br />
{{note|Technically, these laws make <code>f</code> and <code>fmap</code> together an endofunctor on ''Hask'', the category of Haskell types (ignoring [[Bottom|&perp;]], which is a party pooper). See [http://en.wikibooks.org/wiki/Haskell/Category_theory Wikibook: Category theory].}}<br />
<br />
Together, these laws ensure that <code>fmap g</code> does not change the ''structure'' of a container, only the elements. Equivalently, and more simply, they ensure that <code>fmap g</code> changes a value without altering its context {{noteref}}.<br />
<br />
The first law says that mapping the identity function over every item in a container has no effect. The second says that mapping a composition of two functions over every item in a container is the same as first mapping one function, and then mapping the other.<br />
<br />
As an example, the following code is a “valid” instance of <code>Functor</code> (it typechecks), but it violates the functor laws. Do you see why?<br />
<br />
<haskell><br />
-- Evil Functor instance<br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : g x : fmap g xs<br />
</haskell><br />
<br />
Any Haskeller worth their salt would reject this code as a gruesome abomination.<br />
<br />
Unlike some other type classes we will encounter, a given type has at most one valid instance of <code>Functor</code>. This [http://article.gmane.org/gmane.comp.lang.haskell.libraries/15384 can be proven] via the [http://homepages.inf.ed.ac.uk/wadler/topics/parametricity.html#free ''free theorem''] for the type of <code>fmap</code>. In fact, [http://byorgey.wordpress.com/2010/03/03/deriving-pleasure-from-ghc-6-12-1/ GHC can automatically derive] <code>Functor</code> instances for many data types.<br />
<br />
{{note|Actually, if <code>seq</code>/<code>undefined</code> are considered, it [http://stackoverflow.com/a/8323243/305559 is possible] to have an implementation which satisfies the first law but not the second. The rest of the comments in this section should considered in a context where <code>seq</code> and <code>undefined</code> are excluded.}}<br />
<br />
A [https://github.com/quchen/articles/blob/master/second_functor_law.md similar argument also shows] that any <code>Functor</code> instance satisfying the first law (<code>fmap id = id</code>) will automatically satisfy the second law as well. Practically, this means that only the first law needs to be checked (usually by a very straightforward induction) to ensure that a <code>Functor</code> instance is valid.{{noteref}}<br />
<br />
{{Exercises|<br />
# Although it is not possible for a <code>Functor</code> instance to satisfy the first <code>Functor</code> law but not the second (excluding <code>undefined</code>), the reverse is possible. Give an example of a (bogus) <code>Functor</code> instance which satisfies the second law but not the first.<br />
# Which laws are violated by the evil <code>Functor</code> instance for list shown above: both laws, or the first law alone? Give specific counterexamples.<br />
}}<br />
<br />
==Intuition==<br />
<br />
There are two fundamental ways to think about <code>fmap</code>. The first has already been mentioned: it takes two parameters, a function and a container, and applies the function “inside” the container, producing a new container. Alternately, we can think of <code>fmap</code> as applying a function to a value in a context (without altering the context).<br />
<br />
Just like all other Haskell functions of “more than one parameter”, however, <code>fmap</code> is actually ''curried'': it does not really take two parameters, but takes a single parameter and returns a function. For emphasis, we can write <code>fmap</code>’s type with extra parentheses: <code>fmap :: (a -> b) -> (f a -> f b)</code>. Written in this form, it is apparent that <code>fmap</code> transforms a “normal” function (<code>g :: a -> b</code>) into one which operates over containers/contexts (<code>fmap g :: f a -> f b</code>). This transformation is often referred to as a ''lift''; <code>fmap</code> “lifts” a function from the “normal world” into the “<code>f</code> world”.<br />
<br />
==Further reading==<br />
<br />
A good starting point for reading about the category theory behind the concept of a functor is the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page on category theory].<br />
<br />
=Applicative=<br />
<br />
A somewhat newer addition to the pantheon of standard Haskell type classes, ''applicative functors'' represent an abstraction lying in between <code>Functor</code> and <code>Monad</code> in expressivity, first described by McBride and Paterson. The title of their classic paper, [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative Programming with Effects], gives a hint at the intended intuition behind the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html <code>Applicative</code>] type class. It encapsulates certain sorts of “effectful” computations in a functionally pure way, and encourages an “applicative” programming style. Exactly what these things mean will be seen later.<br />
<br />
==Definition==<br />
<br />
Recall that <code>Functor</code> allows us to lift a “normal” function to a function on computational contexts. But <code>fmap</code> doesn’t allow us to apply a function which is itself in a context to a value in a context. <code>Applicative</code> gives us just such a tool, <code>(<*>)</code>. It also provides a method, <code>pure</code>, for embedding values in a default, “effect free” context. Here is the type class declaration for <code>Applicative</code>, as defined in <code>Control.Applicative</code>:<br />
<br />
<haskell><br />
class Functor f => Applicative f where<br />
pure :: a -> f a<br />
(<*>) :: f (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
Note that every <code>Applicative</code> must also be a <code>Functor</code>. In fact, as we will see, <code>fmap</code> can be implemented using the <code>Applicative</code> methods, so every <code>Applicative</code> is a functor whether we like it or not; the <code>Functor</code> constraint forces us to be honest.<br />
<br />
{{note|Recall that <code>($)</code> is just function application: <code>f $ x {{=}} f x</code>.}}<br />
<br />
As always, it’s crucial to understand the type signatures. First, consider <code>(<*>)</code>: the best way of thinking about it comes from noting that the type of <code>(<*>)</code> is similar to the type of <code>($)</code> {{noteref}}, but with everything enclosed in an <code>f</code>. In other words, <code>(<*>)</code> is just function application within a computational context. The type of <code>(<*>)</code> is also very similar to the type of <code>fmap</code>; the only difference is that the first parameter is <code>f (a -> b)</code>, a function in a context, instead of a “normal” function <code>(a -> b)</code>.<br />
<br />
<code>pure</code> takes a value of any type <code>a</code>, and returns a context/container of type <code>f a</code>. The intention is that <code>pure</code> creates some sort of “default” container or “effect free” context. In fact, the behavior of <code>pure</code> is quite constrained by the laws it should satisfy in conjunction with <code>(<*>)</code>. Usually, for a given implementation of <code>(<*>)</code> there is only one possible implementation of <code>pure</code>.<br />
<br />
(Note that previous versions of the Typeclassopedia explained <code>pure</code> in terms of a type class <code>Pointed</code>, which can still be found in the [http://hackage.haskell.org/package/pointed <code>pointed</code> package]. However, the current consensus is that <code>Pointed</code> is not very useful after all. For a more detailed explanation, see [[Why not Pointed?]])<br />
<br />
==Laws==<br />
<br />
{{note|See<br />
[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html haddock for Applicative] and [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative programming with effects]}}<br />
<br />
Traditionally, there are four laws that <code>Applicative</code> instances should satisfy {{noteref}}. In some sense, they are all concerned with making sure that <code>pure</code> deserves its name:<br />
<br />
* The identity law:<br /><haskell>pure id <*> v = v</haskell><br />
* Homomorphism:<br /><haskell>pure f <*> pure x = pure (f x)</haskell>Intuitively, applying a non-effectful function to a non-effectful argument in an effectful context is the same as just applying the function to the argument and then injecting the result into the context with <code>pure</code>.<br />
* Interchange:<br /><haskell>u <*> pure y = pure ($ y) <*> u</haskell>Intuitively, this says that when evaluating the application of an effectful function to a pure argument, the order in which we evaluate the function and its argument doesn't matter.<br />
* Composition:<br /><haskell>u <*> (v <*> w) = pure (.) <*> u <*> v <*> w </haskell>This one is the trickiest law to gain intuition for. In some sense it is expressing a sort of associativity property of <code>(<*>)</code>. The reader may wish to simply convince themselves that this law is type-correct.<br />
<br />
Considered as left-to-right rewrite rules, the homomorphism, interchange, and composition laws actually constitute an algorithm for transforming any expression using <code>pure</code> and <code>(<*>)</code> into a canonical form with only a single use of <code>pure</code> at the very beginning and only left-nested occurrences of <code>(<*>)</code>. Composition allows reassociating <code>(<*>)</code>; interchange allows moving occurrences of <code>pure</code> leftwards; and homomorphism allows collapsing multiple adjacent occurrences of <code>pure</code> into one.<br />
<br />
There is also a law specifying how <code>Applicative</code> should relate to <code>Functor</code>:<br />
<br />
<haskell><br />
fmap g x = pure g <*> x<br />
</haskell><br />
<br />
It says that mapping a pure function <code>g</code> over a context <code>x</code> is the same as first injecting <code>g</code> into a context with <code>pure</code>, and then applying it to <code>x</code> with <code>(<*>)</code>. In other words, we can decompose <code>fmap</code> into two more atomic operations: injection into a context, and application within a context. The <code>Control.Applicative</code> module also defines <code>(<$>)</code> as a synonym for <code>fmap</code>, so the above law can also be expressed as:<br />
<br />
<code>g <$> x = pure g <*> x</code>.<br />
<br />
{{Exercises|<br />
# (Tricky) One might imagine a variant of the interchange law that says something about applying a pure function to an effectful argument. Using the above laws, prove that<haskell>pure f <*> x = pure (flip ($)) <*> x <*> pure f</haskell><br />
}}<br />
<br />
==Instances==<br />
<br />
Most of the standard types which are instances of <code>Functor</code> are also instances of <code>Applicative</code>.<br />
<br />
<code>Maybe</code> can easily be made an instance of <code>Applicative</code>; writing such an instance is left as an exercise for the reader.<br />
<br />
The list type constructor <code>[]</code> can actually be made an instance of <code>Applicative</code> in two ways; essentially, it comes down to whether we want to think of lists as ordered collections of elements, or as contexts representing multiple results of a nondeterministic computation (see Wadler’s [http://www.springerlink.com/content/y7450255v2670167/ How to replace failure by a list of successes]).<br />
<br />
Let’s first consider the collection point of view. Since there can only be one instance of a given type class for any particular type, one or both of the list instances of <code>Applicative</code> need to be defined for a <code>newtype</code> wrapper; as it happens, the nondeterministic computation instance is the default, and the collection instance is defined in terms of a <code>newtype</code> called <code>ZipList</code>. This instance is:<br />
<br />
<haskell><br />
newtype ZipList a = ZipList { getZipList :: [a] }<br />
<br />
instance Applicative ZipList where<br />
pure = undefined -- exercise<br />
(ZipList gs) <*> (ZipList xs) = ZipList (zipWith ($) gs xs)<br />
</haskell><br />
<br />
To apply a list of functions to a list of inputs with <code>(<*>)</code>, we just match up the functions and inputs elementwise, and produce a list of the resulting outputs. In other words, we “zip” the lists together with function application, <code>($)</code>; hence the name <code>ZipList</code>. <br />
<br />
The other <code>Applicative</code> instance for lists, based on the nondeterministic computation point of view, is:<br />
<br />
<haskell><br />
instance Applicative [] where<br />
pure x = [x]<br />
gs <*> xs = [ g x | g <- gs, x <- xs ]<br />
</haskell><br />
<br />
Instead of applying functions to inputs pairwise, we apply each function to all the inputs in turn, and collect all the results in a list.<br />
<br />
Now we can write nondeterministic computations in a natural style. To add the numbers <code>3</code> and <code>4</code> deterministically, we can of course write <code>(+) 3 4</code>. But suppose instead of <code>3</code> we have a nondeterministic computation that might result in <code>2</code>, <code>3</code>, or <code>4</code>; then we can write<br />
<br />
<haskell><br />
pure (+) <*> [2,3,4] <*> pure 4<br />
</haskell><br />
<br />
or, more idiomatically,<br />
<br />
<haskell><br />
(+) <$> [2,3,4] <*> pure 4.<br />
</haskell><br />
<br />
There are several other <code>Applicative</code> instances as well:<br />
<br />
* <code>IO</code> is an instance of <code>Applicative</code>, and behaves exactly as you would think: to execute <code>m1 <*> m2</code>, first <code>m1</code> is executed, resulting in a function <code>f</code>, then <code>m2</code> is executed, resulting in a value <code>x</code>, and finally the value <code>f x</code> is returned as the result of executing <code>m1 <*> m2</code>.<br />
<br />
* <code>((,) a)</code> is an <code>Applicative</code>, as long as <code>a</code> is an instance of <code>Monoid</code> ([[#Monoid|section Monoid]]). The <code>a</code> values are accumulated in parallel with the computation.<br />
<br />
* The <code>Applicative</code> module defines the <code>Const</code> type constructor; a value of type <code>Const a b</code> simply contains an <code>a</code>. This is an instance of <code>Applicative</code> for any <code>Monoid a</code>; this instance becomes especially useful in conjunction with things like <code>Foldable</code> ([[#Foldable|section Foldable]]).<br />
<br />
* The <code>WrappedMonad</code> and <code>WrappedArrow</code> newtypes make any instances of <code>Monad</code> ([[#Monad|section Monad]]) or <code>Arrow</code> ([[#Arrow|section Arrow]]) respectively into instances of <code>Applicative</code>; as we will see when we study those type classes, both are strictly more expressive than <code>Applicative</code>, in the sense that the <code>Applicative</code> methods can be implemented in terms of their methods.<br />
<br />
{{Exercises|<br />
# Implement an instance of <code>Applicative</code> for <code>Maybe</code>.<br />
# Determine the correct definition of <code>pure</code> for the <code>ZipList</code> instance of <code>Applicative</code>—there is only one implementation that satisfies the law relating <code>pure</code> and <code>(<*>)</code>.<br />
}}<br />
<br />
==Intuition==<br />
<br />
McBride and Paterson’s paper introduces the notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> to denote function application in a computational context. If each <math>x_i\ </math> has type <math>f \; t_i\ </math> for some applicative functor <math>f\ </math>, and <math>g\ </math> has type <math>t_1 \to t_2 \to \dots \to t_n \to t\ </math>, then the entire expression <math>[[g \; x_1 \; \cdots \; x_n]]\ </math> has type <math>f \; t\ </math>. You can think of this as applying a function to multiple “effectful” arguments. In this sense, the double bracket notation is a generalization of <code>fmap</code>, which allows us to apply a function to a single argument in a context.<br />
<br />
Why do we need <code>Applicative</code> to implement this generalization of <code>fmap</code>? Suppose we use <code>fmap</code> to apply <code>g</code> to the first parameter <code>x1</code>. Then we get something of type <code>f (t2 -> ... t)</code>, but now we are stuck: we can’t apply this function-in-a-context to the next argument with <code>fmap</code>. However, this is precisely what <code>(<*>)</code> allows us to do.<br />
<br />
This suggests the proper translation of the idealized notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> into Haskell, namely<br />
<haskell><br />
g <$> x1 <*> x2 <*> ... <*> xn,<br />
</haskell><br />
<br />
recalling that <code>Control.Applicative</code> defines <code>(<$>)</code> as convenient infix shorthand for <code>fmap</code>. This is what is meant by an “applicative style”—effectful computations can still be described in terms of function application; the only difference is that we have to use the special operator <code>(<*>)</code> for application instead of simple juxtaposition.<br />
<br />
Note that <code>pure</code> allows embedding “non-effectful” arguments in the middle of an idiomatic application, like<br />
<haskell><br />
g <$> x1 <*> pure x2 <*> x3<br />
</haskell><br />
which has type <code>f d</code>, given<br />
<haskell><br />
g :: a -> b -> c -> d<br />
x1 :: f a<br />
x2 :: b<br />
x3 :: f c<br />
</haskell><br />
<br />
The double brackets are commonly known as “idiom brackets”, because they allow writing “idiomatic” function application, that is, function application that looks normal but has some special, non-standard meaning (determined by the particular instance of <code>Applicative</code> being used). Idiom brackets are not supported by GHC, but they are supported by the [http://personal.cis.strath.ac.uk/~conor/pub/she/ Strathclyde Haskell Enhancement], a preprocessor which (among many other things) translates idiom brackets into standard uses of <code>(<$>)</code> and <code>(<*>)</code>. This can result in much more readable code when making heavy use of <code>Applicative</code>.<br />
<br />
==Alternative formulation==<br />
<br />
An alternative, equivalent formulation of <code>Applicative</code> is given by<br />
<br />
<haskell><br />
class Functor f => Monoidal f where<br />
unit :: f ()<br />
(**) :: f a -> f b -> f (a,b)<br />
</haskell><br />
<br />
{{note|In category-theory speak, we say <code>f</code> is a ''lax'' monoidal functor because there aren't necessarily functions in the other direction, like <code>f (a, b) -> (f a, f b)</code>.}}<br />
Intuitively, this states that a <i>monoidal</i> functor{{noteref}} is one which has some sort of "default shape" and which supports some sort of "combining" operation. <code>pure</code> and <code>(<*>)</code> are equivalent in power to <code>unit</code> and <code>(**)</code> (see the Exercises below). More technically, the idea is that <code>f</code> preserves the "monoidal structure" given by the pairing constructor <code>(,)</code> and unit type <code>()</code>. This can be seen even more clearly if we rewrite the types of <code>unit</code> and <code>(**)</code> as<br />
<haskell><br />
unit' :: () -> f ()<br />
(**') :: (f a, f b) -> f (a, b)<br />
</haskell><br />
<br />
Furthermore, to deserve the name "monoidal" (see the [[#Monoid|section on Monoids]]), instances of <code>Monoidal</code> ought to satisfy the following laws, which seem much more straightforward than the traditional <code>Applicative</code> laws:<br />
<br />
{{note|In this and the following laws, <code>≅</code> refers to <i>isomorphism</i> rather than equality. In particular we consider <code>(x,()) ≅ x ≅ ((),x)</code> and <code>((x,y),z) ≅ (x,(y,z))</code>.}}<br />
* Left identity{{noteref}}: <haskell>unit ** v ≅ v</haskell><br />
* Right identity: <haskell>u ** unit ≅ u</haskell><br />
* Associativity: <haskell>u ** (v ** w) ≅ (u ** v) ** w</haskell><br />
<br />
These turn out to be equivalent to the usual <code>Applicative</code> laws. In a category theory setting, one would also require a naturality law:<br />
<br />
{{note|Here <code>g *** h {{=}} \(x,y) -> (g x, h y)</code>. See [[#Arrow|Arrows]].}}<br />
* Naturality: <haskell>fmap (g *** h) (u ** v) = fmap g u ** fmap h v</haskell><br />
<br />
but in the context of Haskell, this is a free theorem.<br />
<br />
Much of this section was taken from [http://blog.ezyang.com/2012/08/applicative-functors/ a blog post by Edward Z. Yang]; see his actual post for a bit more information.<br />
<br />
{{Exercises|<br />
# Implement <code>pure</code> and <code>(<*>)</code> in terms of <code>unit</code> and <code>(**)</code>, and vice versa.<br />
# Are there any <code>Applicative</code> instances for which there are also functions <code>f () -> ()</code> and <code>f (a,b) -> (f a, f b)</code>, satisfying some "reasonable" laws?<br />
# (Tricky) Prove that given your implementations from the previous exercise, the usual <code>Applicative</code> laws and the <code>Monoidal</code> laws stated above are equivalent.<br />
}}<br />
<br />
==Further reading==<br />
<br />
There are many other useful combinators in the standard libraries implemented in terms of <code>pure</code> and <code>(<*>)</code>: for example, <code>(*>)</code>, <code>(<*)</code>, <code>(<**>)</code>, <code>(<$)</code>, and so on (see [http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.7.0.0/Control-Applicative.html haddock for Applicative]). Judicious use of such secondary combinators can often make code using <code>Applicative</code>s much easier to read.<br />
<br />
[http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s original paper] is a treasure-trove of information and examples, as well as some perspectives on the connection between <code>Applicative</code> and category theory. Beginners will find it difficult to make it through the entire paper, but it is extremely well-motivated—even beginners will be able to glean something from reading as far as they are able.<br />
<br />
{{note|Introduced by [http://conal.net/papers/simply-reactive/ an earlier paper] that was since superseded by [http://conal.net/papers/push-pull-frp/ Push-pull functional reactive programming].}}<br />
<br />
Conal Elliott has been one of the biggest proponents of <code>Applicative</code>. For example, the [http://conal.net/papers/functional-images/ Pan library for functional images] and the reactive library for functional reactive programming (FRP) {{noteref}} make key use of it; his blog also contains [http://conal.net/blog/tag/applicative-functor many examples of <code>Applicative</code> in action]. Building on the work of McBride and Paterson, Elliott also built the [[TypeCompose]] library, which embodies the observation (among others) that <code>Applicative</code> types are closed under composition; therefore, <code>Applicative</code> instances can often be automatically derived for complex types built out of simpler ones.<br />
<br />
Although the [http://hackage.haskell.org/package/parsec Parsec parsing library] ([http://legacy.cs.uu.nl/daan/download/papers/parsec-paper.pdf paper]) was originally designed for use as a monad, in its most common use cases an <code>Applicative</code> instance can be used to great effect; [http://www.serpentine.com/blog/2008/02/06/the-basics-of-applicative-functors-put-to-practical-work/ Bryan O’Sullivan’s blog post] is a good starting point. If the extra power provided by <code>Monad</code> isn’t needed, it’s usually a good idea to use <code>Applicative</code> instead.<br />
<br />
A couple other nice examples of <code>Applicative</code> in action include the [http://web.archive.org/web/20090416111947/chrisdone.com/blog/html/2009-02-10-applicative-configfile-hsql.html ConfigFile and HSQL libraries] and the [http://groups.inf.ed.ac.uk/links/formlets/ formlets library].<br />
<br />
Gershom Bazerman's [http://comonad.com/reader/2012/abstracting-with-applicatives/ post] contains many insights into applicatives.<br />
<br />
=Monad=<br />
<br />
It’s a safe bet that if you’re reading this, you’ve heard of monads—although it’s quite possible you’ve never heard of <code>Applicative</code> before, or <code>Arrow</code>, or even <code>Monoid</code>. Why are monads such a big deal in Haskell? There are several reasons.<br />
<br />
* Haskell does, in fact, single out monads for special attention by making them the framework in which to construct I/O operations.<br />
* Haskell also singles out monads for special attention by providing a special syntactic sugar for monadic expressions: the <code>do</code>-notation.<br />
* <code>Monad</code> has been around longer than other abstract models of computation such as <code>Applicative</code> or <code>Arrow</code>.<br />
* The more monad tutorials there are, the harder people think monads must be, and the more new monad tutorials are written by people who think they finally “get” monads (the [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ monad tutorial fallacy]).<br />
<br />
I will let you judge for yourself whether these are good reasons.<br />
<br />
In the end, despite all the hoopla, <code>Monad</code> is just another type class. Let’s take a look at its definition.<br />
<br />
==Definition==<br />
<br />
The type class declaration for [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Monad <code>Monad</code>] is:<br />
<br />
<haskell><br />
class Monad m where<br />
return :: a -> m a<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
(>>) :: m a -> m b -> m b<br />
m >> n = m >>= \_ -> n<br />
<br />
fail :: String -> m a<br />
</haskell><br />
<br />
The <code>Monad</code> type class is exported by the <code>Prelude</code>, along with a few standard instances. However, many utility functions are found in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>], and there are also several instances (such as <code>((->) e)</code>) defined in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-Instances.html <code>Control.Monad.Instances</code>].<br />
<br />
{{note|However, as of GHC 7.10 this will be fixed!}}<br />
Let’s examine the methods in the <code>Monad</code> class one by one. The type of <code>return</code> should look familiar; it’s the same as <code>pure</code>. Indeed, <code>return</code> ''is'' <code>pure</code>, but with an unfortunate name. (Unfortunate, since someone coming from an imperative programming background might think that <code>return</code> is like the C or Java keyword of the same name, when in fact the similarities are minimal.) From a mathematical point of view, every monad is an applicative functor, but for historical reasons, the <code>Monad</code> type class declaration unfortunately does not require this.{{noteref}}<br />
<br />
We can see that <code>(>>)</code> is a specialized version of <code>(>>=)</code>, with a default implementation given. It is only included in the type class declaration so that specific instances of <code>Monad</code> can override the default implementation of <code>(>>)</code> with a more efficient one, if desired. Also, note that although <code>_ >> n = n</code> would be a type-correct implementation of <code>(>>)</code>, it would not correspond to the intended semantics: the intention is that <code>m >> n</code> ignores the ''result'' of <code>m</code>, but not its ''effects''.<br />
<br />
The <code>fail</code> function is an awful hack that has no place in the <code>Monad</code> class; more on this later.<br />
<br />
The only really interesting thing to look at—and what makes <code>Monad</code> strictly more powerful than <code>Applicative</code>—is <code>(>>=)</code>, which is often called ''bind''. An alternative definition of <code>Monad</code> could look like:<br />
<br />
<haskell><br />
class Applicative m => Monad' m where<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
</haskell><br />
<br />
We could spend a while talking about the intuition behind <code>(>>=)</code>—and we will. But first, let’s look at some examples.<br />
<br />
==Instances==<br />
<br />
Even if you don’t understand the intuition behind the <code>Monad</code> class, you can still create instances of it by just seeing where the types lead you. You may be surprised to find that this actually gets you a long way towards understanding the intuition; at the very least, it will give you some concrete examples to play with as you read more about the <code>Monad</code> class in general. The first few examples are from the standard <code>Prelude</code>; the remaining examples are from the [http://hackage.haskell.org/package/transformers <code>transformers</code> package].<br />
<br />
<ul><br />
<li>The simplest possible instance of <code>Monad</code> is [http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Monad-Identity.html <code>Identity</code>], which is described in Dan Piponi’s highly recommended blog post on [http://blog.sigfpe.com/2007/04/trivial-monad.html The Trivial Monad]. Despite being “trivial”, it is a great introduction to the <code>Monad</code> type class, and contains some good exercises to get your brain working.<br />
</li><br />
<li>The next simplest instance of <code>Monad</code> is <code>Maybe</code>. We already know how to write <code>return</code>/<code>pure</code> for <code>Maybe</code>. So how do we write <code>(>>=)</code>? Well, let’s think about its type. Specializing for <code>Maybe</code>, we have<br />
<br />
<haskell><br />
(>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b.<br />
</haskell><br />
<br />
If the first argument to <code>(>>=)</code> is <code>Just x</code>, then we have something of type <code>a</code> (namely, <code>x</code>), to which we can apply the second argument—resulting in a <code>Maybe b</code>, which is exactly what we wanted. What if the first argument to <code>(>>=)</code> is <code>Nothing</code>? In that case, we don’t have anything to which we can apply the <code>a -> Maybe b</code> function, so there’s only one thing we can do: yield <code>Nothing</code>. This instance is:<br />
<br />
<haskell><br />
instance Monad Maybe where<br />
return = Just<br />
(Just x) >>= g = g x<br />
Nothing >>= _ = Nothing<br />
</haskell><br />
<br />
We can already get a bit of intuition as to what is going on here: if we build up a computation by chaining together a bunch of functions with <code>(>>=)</code>, as soon as any one of them fails, the entire computation will fail (because <code>Nothing >>= f</code> is <code>Nothing</code>, no matter what <code>f</code> is). The entire computation succeeds only if all the constituent functions individually succeed. So the <code>Maybe</code> monad models computations which may fail.<br />
</li><br />
<br />
<li>The <code>Monad</code> instance for the list constructor <code>[]</code> is similar to its <code>Applicative</code> instance; see the exercise below.<br />
</li><br />
<br />
<li>Of course, the <code>IO</code> constructor is famously a <code>Monad</code>, but its implementation is somewhat magical, and may in fact differ from compiler to compiler. It is worth emphasizing that the <code>IO</code> monad is the ''only'' monad which is magical. It allows us to build up, in an entirely pure way, values representing possibly effectful computations. The special value <code>main</code>, of type <code>IO ()</code>, is taken by the runtime and actually executed, producing actual effects. Every other monad is functionally pure, and requires no special compiler support. We often speak of monadic values as “effectful computations”, but this is because some monads allow us to write code ''as if'' it has side effects, when in fact the monad is hiding the plumbing which allows these apparent side effects to be implemented in a functionally pure way.<br />
</li><br />
<br />
<li>As mentioned earlier, <code>((->) e)</code> is known as the ''reader monad'', since it describes computations in which a value of type <code>e</code> is available as a read-only environment.<br />
<br />
The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Reader.html <code>Control.Monad.Reader</code>] module provides the <code>Reader e a</code> type, which is just a convenient <code>newtype</code> wrapper around <code>(e -> a)</code>, along with an appropriate <code>Monad</code> instance and some <code>Reader</code>-specific utility functions such as <code>ask</code> (retrieve the environment), <code>asks</code> (retrieve a function of the environment), and <code>local</code> (run a subcomputation under a different environment).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Writer-Lazy.html <code>Control.Monad.Writer</code>] module provides the <code>Writer</code> monad, which allows information to be collected as a computation progresses. <code>Writer w a</code> is isomorphic to <code>(a,w)</code>, where the output value <code>a</code> is carried along with an annotation or “log” of type <code>w</code>, which must be an instance of <code>Monoid</code> (see [[#Monoid|section Monoid]]); the special function <code>tell</code> performs logging.<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-State-Lazy.html <code>Control.Monad.State</code>] module provides the <code>State s a</code> type, a <code>newtype</code> wrapper around <code>s -> (a,s)</code>. Something of type <code>State s a</code> represents a stateful computation which produces an <code>a</code> but can access and modify the state of type <code>s</code> along the way. The module also provides <code>State</code>-specific utility functions such as <code>get</code> (read the current state), <code>gets</code> (read a function of the current state), <code>put</code> (overwrite the state), and <code>modify</code> (apply a function to the state).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Cont.html <code>Control.Monad.Cont</code>] module provides the <code>Cont</code> monad, which represents computations in continuation-passing style. It can be used to suspend and resume computations, and to implement non-local transfers of control, co-routines, other complex control structures—all in a functionally pure way. <code>Cont</code> has been called the [http://blog.sigfpe.com/2008/12/mother-of-all-monads.html “mother of all monads”] because of its universal properties.<br />
</li><br />
</ul><br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement a <code>Monad</code> instance for the list constructor, <code>[]</code>. Follow the types!</li><br />
<li>Implement a <code>Monad</code> instance for <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> and <code>Monad</code> instances for <code>Free f</code>, defined as<br />
<haskell><br />
data Free f a = Var a<br />
| Node (f (Free f a))<br />
</haskell><br />
You may assume that <code>f</code> has a <code>Functor</code> instance. This is known as the ''free monad'' built from the functor <code>f</code>.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Intuition==<br />
<br />
Let’s look more closely at the type of <code>(>>=)</code>. The basic intuition is that it combines two computations into one larger computation. The first argument, <code>m a</code>, is the first computation. However, it would be boring if the second argument were just an <code>m b</code>; then there would be no way for the computations to interact with one another (actually, this is exactly the situation with <code>Applicative</code>). So, the second argument to <code>(>>=)</code> has type <code>a -> m b</code>: a function of this type, given a ''result'' of the first computation, can produce a second computation to be run. In other words, <code>x >>= k</code> is a computation which runs <code>x</code>, and then uses the result(s) of <code>x</code> to ''decide'' what computation to run second, using the output of the second computation as the result of the entire computation.<br />
<br />
{{note|Actually, because Haskell allows general recursion, this is a lie: using a Haskell parsing library one can recursively construct ''infinite'' grammars, and hence <code>Applicative</code> (together with <code>Alternative</code>) is enough to parse any context-sensitive language with a finite alphabet. See [http://byorgey.wordpress.com/2012/01/05/parsing-context-sensitive-languages-with-applicative/ Parsing context-sensitive languages with Applicative].}}<br />
Intuitively, it is this ability to use the output from previous computations to decide what computations to run next that makes <code>Monad</code> more powerful than <code>Applicative</code>. The structure of an <code>Applicative</code> computation is fixed, whereas the structure of a <code>Monad</code> computation can change based on intermediate results. This also means that parsers built using an <code>Applicative</code> interface can only parse context-free languages; in order to parse context-sensitive languages a <code>Monad</code> interface is needed.{{noteref}}<br />
<br />
To see the increased power of <code>Monad</code> from a different point of view, let’s see what happens if we try to implement <code>(>>=)</code> in terms of <code>fmap</code>, <code>pure</code>, and <code>(<*>)</code>. We are given a value <code>x</code> of type <code>m a</code>, and a function <code>k</code> of type <code>a -> m b</code>, so the only thing we can do is apply <code>k</code> to <code>x</code>. We can’t apply it directly, of course; we have to use <code>fmap</code> to lift it over the <code>m</code>. But what is the type of <code>fmap k</code>? Well, it’s <code>m a -> m (m b)</code>. So after we apply it to <code>x</code>, we are left with something of type <code>m (m b)</code>—but now we are stuck; what we really want is an <code>m b</code>, but there’s no way to get there from here. We can ''add'' <code>m</code>’s using <code>pure</code>, but we have no way to ''collapse'' multiple <code>m</code>’s into one.<br />
<br />
{{note|1=You might hear some people claim that that the definition in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> is the “math definition” and the definition in terms of <code>return</code> and <code>(>>=)</code> is something specific to Haskell. In fact, both definitions were known in the mathematics community long before Haskell picked up monads.}}<br />
<br />
This ability to collapse multiple <code>m</code>’s is exactly the ability provided by the function <code>join :: m (m a) -> m a</code>, and it should come as no surprise that an alternative definition of <code>Monad</code> can be given in terms of <code>join</code>:<br />
<br />
<haskell><br />
class Applicative m => Monad'' m where<br />
join :: m (m a) -> m a<br />
</haskell><br />
<br />
In fact, the canonical definition of monads in category theory is in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> (often called <math>\eta</math>, <math>T</math>, and <math>\mu</math> in the mathematical literature). Haskell uses an alternative formulation with <code>(>>=)</code> instead of <code>join</code> since it is more convenient to use {{noteref}}. However, sometimes it can be easier to think about <code>Monad</code> instances in terms of <code>join</code>, since it is a more “atomic” operation. (For example, <code>join</code> for the list monad is just <code>concat</code>.)<br />
<br />
{{Exercises|<br />
# Implement <code>(>>{{=}})</code> in terms of <code>fmap</code> (or <code>liftM</code>) and <code>join</code>.<br />
# Now implement <code>join</code> and <code>fmap</code> (<code>liftM</code>) in terms of <code>(>>{{=}})</code> and <code>return</code>.<br />
}}<br />
<br />
==Utility functions==<br />
<br />
The [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>] module provides a large number of convenient utility functions, all of which can be implemented in terms of the basic <code>Monad</code> operations (<code>return</code> and <code>(>>=)</code> in particular). We have already seen one of them, namely, <code>join</code>. We also mention some other noteworthy ones here; implementing these utility functions oneself is a good exercise. For a more detailed guide to these functions, with commentary and example code, see Henk-Jan van Tuyl’s [http://members.chello.nl/hjgtuyl/tourdemonad.html tour].<br />
<br />
{{note|This will most likely change in Haskell 2014 with the implementation of the [[Functor-Applicative-Monad_Proposal|Haskell 2014 Applicative => Monad proposal]].}}<br />
<br />
* <code>liftM :: Monad m => (a -> b) -> m a -> m b</code>. This should be familiar; of course, it is just <code>fmap</code>. The fact that we have both <code>fmap</code> and <code>liftM</code> is an unfortunate consequence of the fact that the <code>Monad</code> type class does not require a <code>Functor</code> instance, even though mathematically speaking, every monad is a functor. However, <code>fmap</code> and <code>liftM</code> are essentially interchangeable, since it is a bug (in a social rather than technical sense) for any type to be an instance of <code>Monad</code> without also being an instance of <code>Functor</code> {{noteref}}.<br />
<br />
* <code>ap :: Monad m => m (a -> b) -> m a -> m b</code> should also be familiar: it is equivalent to <code>(<*>)</code>, justifying the claim that the <code>Monad</code> interface is strictly more powerful than <code>Applicative</code>. We can make any <code>Monad</code> into an instance of <code>Applicative</code> by setting <code>pure = return</code> and <code>(<*>) = ap</code>.<br />
<br />
* <code>sequence :: Monad m => [m a] -> m [a]</code> takes a list of computations and combines them into one computation which collects a list of their results. It is again something of a historical accident that <code>sequence</code> has a <code>Monad</code> constraint, since it can actually be implemented only in terms of <code>Applicative</code>. There is an additional generalization of <code>sequence</code> to structures other than lists, which will be discussed in the [[#Traversable|section on <code>Traversable</code>]].<br />
<br />
* <code>replicateM :: Monad m => Int -> m a -> m [a]</code> is simply a combination of [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:replicate <code>replicate</code>] and <code>sequence</code>.<br />
<br />
* <code>when :: Monad m => Bool -> m () -> m ()</code> conditionally executes a computation, evaluating to its second argument if the test is <code>True</code>, and to <code>return ()</code> if the test is <code>False</code>. A collection of other sorts of monadic conditionals can be found in the [http://hackage.haskell.org/package/IfElse <code>IfElse</code> package].<br />
<br />
* <code>mapM :: Monad m => (a -> m b) -> [a] -> m [b]</code> maps its first argument over the second, and <code>sequence</code>s the results. The <code>forM</code> function is just <code>mapM</code> with its arguments reversed; it is called <code>forM</code> since it models generalized <code>for</code> loops: the list <code>[a]</code> provides the loop indices, and the function <code>a -> m b</code> specifies the “body” of the loop for each index.<br />
<br />
* <code>(=<<) :: Monad m => (a -> m b) -> m a -> m b</code> is just <code>(>>=)</code> with its arguments reversed; sometimes this direction is more convenient since it corresponds more closely to function application.<br />
<br />
* <code>(>=>) :: Monad m => (a -> m b) -> (b -> m c) -> a -> m c</code> is sort of like function composition, but with an extra <code>m</code> on the result type of each function, and the arguments swapped. We’ll have more to say about this operation later. There is also a flipped variant, <code>(<=<)</code>.<br />
<br />
* The <code>guard</code> function is for use with instances of <code>MonadPlus</code>, which is discussed at the end of the [[#Monoid|<code>Monoid</code> section]].<br />
<br />
Many of these functions also have “underscored” variants, such as <code>sequence_</code> and <code>mapM_</code>; these variants throw away the results of the computations passed to them as arguments, using them only for their side effects.<br />
<br />
Other monadic functions which are occasionally useful include <code>filterM</code>, <code>zipWithM</code>, <code>foldM</code>, and <code>forever</code>.<br />
<br />
==Laws==<br />
<br />
There are several laws that instances of <code>Monad</code> should satisfy (see also the [[Monad laws]] wiki page). The standard presentation is:<br />
<br />
<haskell><br />
return a >>= k = k a<br />
m >>= return = m<br />
m >>= (\x -> k x >>= h) = (m >>= k) >>= h<br />
<br />
fmap f xs = xs >>= return . f = liftM f xs<br />
</haskell><br />
<br />
The first and second laws express the fact that <code>return</code> behaves nicely: if we inject a value <code>a</code> into a monadic context with <code>return</code>, and then bind to <code>k</code>, it is the same as just applying <code>k</code> to <code>a</code> in the first place; if we bind a computation <code>m</code> to <code>return</code>, nothing changes. The third law essentially says that <code>(>>=)</code> is associative, sort of. The last law ensures that <code>fmap</code> and <code>liftM</code> are the same for types which are instances of both <code>Functor</code> and <code>Monad</code>—which, as already noted, should be every instance of <code>Monad</code>.<br />
<br />
{{note|I like to pronounce this operator “fish”.}}<br />
<br />
However, the presentation of the above laws, especially the third, is marred by the asymmetry of <code>(>>=)</code>. It’s hard to look at the laws and see what they’re really saying. I prefer a much more elegant version of the laws, which is formulated in terms of <code>(>=>)</code> {{noteref}}. Recall that <code>(>=>)</code> “composes” two functions of type <code>a -> m b</code> and <code>b -> m c</code>. You can think of something of type <code>a -> m b</code> (roughly) as a function from <code>a</code> to <code>b</code> which may also have some sort of effect in the context corresponding to <code>m</code>. <code>(>=>)</code> lets us compose these “effectful functions”, and we would like to know what properties <code>(>=>)</code> has. The monad laws reformulated in terms of <code>(>=>)</code> are:<br />
<br />
<haskell><br />
return >=> g = g<br />
g >=> return = g<br />
(g >=> h) >=> k = g >=> (h >=> k)<br />
</haskell><br />
<br />
{{note|As fans of category theory will note, these laws say precisely that functions of type <code>a -> m b</code> are the arrows of a category with <code>(>{{=}}>)</code> as composition! Indeed, this is known as the ''Kleisli category'' of the monad <code>m</code>. It will come up again when we discuss <code>Arrow</code>s.}}<br />
<br />
Ah, much better! The laws simply state that <code>return</code> is the identity of <code>(>=>)</code>, and that <code>(>=>)</code> is associative {{noteref}}.<br />
<br />
There is also a formulation of the monad laws in terms of <code>fmap</code>, <code>return</code>, and <code>join</code>; for a discussion of this formulation, see the Haskell [http://en.wikibooks.org/wiki/Haskell/Category_theory wikibook page on category theory].<br />
<br />
{{Exercises|<br />
# Given the definition <code>g >{{=}}> h {{=}} \x -> g x >>{{=}} h</code>, prove the equivalence of the above laws and the usual monad laws.<br />
}}<br />
<br />
==<code>do</code> notation==<br />
<br />
Haskell’s special <code>do</code> notation supports an “imperative style” of programming by providing syntactic sugar for chains of monadic expressions. The genesis of the notation lies in realizing that something like <code>a >>= \x -> b >> c >>= \y -> d </code> can be more readably written by putting successive computations on separate lines:<br />
<br />
<haskell><br />
a >>= \x -><br />
b >><br />
c >>= \y -><br />
d<br />
</haskell><br />
<br />
This emphasizes that the overall computation consists of four computations <code>a</code>, <code>b</code>, <code>c</code>, and <code>d</code>, and that <code>x</code> is bound to the result of <code>a</code>, and <code>y</code> is bound to the result of <code>c</code> (<code>b</code>, <code>c</code>, and <code>d</code> are allowed to refer to <code>x</code>, and <code>d</code> is allowed to refer to <code>y</code> as well). From here it is not hard to imagine a nicer notation:<br />
<br />
<haskell><br />
do { x <- a<br />
; b<br />
; y <- c<br />
; d<br />
}<br />
</haskell><br />
<br />
(The curly braces and semicolons may optionally be omitted; the Haskell parser uses layout to determine where they should be inserted.) This discussion should make clear that <code>do</code> notation is just syntactic sugar. In fact, <code>do</code> blocks are recursively translated into monad operations (almost) like this:<br />
<br />
<pre><br />
do e → e<br />
do { e; stmts } → e >> do { stmts }<br />
do { v <- e; stmts } → e >>= \v -> do { stmts }<br />
do { let decls; stmts} → let decls in do { stmts }<br />
</pre><br />
<br />
This is not quite the whole story, since <code>v</code> might be a pattern instead of a variable. For example, one can write<br />
<br />
<haskell><br />
do (x:xs) <- foo<br />
bar x<br />
</haskell><br />
<br />
but what happens if <code>foo</code> produces an empty list? Well, remember that ugly <code>fail</code> function in the <code>Monad</code> type class declaration? That’s what happens. See [http://www.haskell.org/onlinereport/exps.html#sect3.14 section 3.14 of the Haskell Report] for the full details. See also the discussion of <code>MonadPlus</code> and <code>MonadZero</code> in the [[#Other monoidal classes: Alternative, MonadPlus, ArrowPlus|section on other monoidal classes]].<br />
<br />
A final note on intuition: <code>do</code> notation plays very strongly to the “computational context” point of view rather than the “container” point of view, since the binding notation <code>x <- m</code> is suggestive of “extracting” a single <code>x</code> from <code>m</code> and doing something with it. But <code>m</code> may represent some sort of a container, such as a list or a tree; the meaning of <code>x <- m</code> is entirely dependent on the implementation of <code>(>>=)</code>. For example, if <code>m</code> is a list, <code>x <- m</code> actually means that <code>x</code> will take on each value from the list in turn.<br />
<br />
==Further reading==<br />
<br />
Philip Wadler was the first to propose using monads to structure functional programs. [http://homepages.inf.ed.ac.uk/wadler/topics/monads.html His paper] is still a readable introduction to the subject.<br />
<br />
{{note|1=<br />
[[All About Monads]],<br />
[http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers],<br />
[http://en.wikibooks.org/w/index.php?title=Haskell/Understanding_monads Understanding monads],<br />
[[The Monadic Way]],<br />
[http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads! (And Maybe You Already Have.)],<br />
[http://www.haskell.org/pipermail/haskell-cafe/2006-November/019190.html there’s a monster in my Haskell!],<br />
[http://kawagner.blogspot.com/2007/02/understanding-monads-for-real.html Understanding Monads. For real.],<br />
[http://www.randomhacks.net/articles/2007/03/12/monads-in-15-minutes Monads in 15 minutes: Backtracking and Maybe],<br />
[http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation],<br />
[http://metafoo.co.uk/practical-monads.txt Practical Monads]}}<br />
<br />
There are, of course, numerous monad tutorials of varying quality {{noteref}}.<br />
<br />
A few of the best include Cale Gibbard’s [http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers] and [http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation]; Jeff Newbern’s [[All About Monads]], a comprehensive guide with lots of examples; and Dan Piponi’s [http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads!], which features great exercises. If you just want to know how to use <code>IO</code>, you could consult the [[Introduction to IO]]. Even this is just a sampling; the [[monad tutorials timeline]] is a more complete list. (All these monad tutorials have prompted parodies like [http://koweycode.blogspot.com/2007/01/think-of-monad.html think of a monad ...] as well as other kinds of backlash like [http://ahamsandwich.wordpress.com/2007/07/26/monads-and-why-monad-tutorials-are-all-awful/ Monads! (and Why Monad Tutorials Are All Awful)] or [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Abstraction, intuition, and the “monad tutorial fallacy”].)<br />
<br />
Other good monad references which are not necessarily tutorials include [http://members.chello.nl/hjgtuyl/tourdemonad.html Henk-Jan van Tuyl’s tour] of the functions in <code>Control.Monad</code>, Dan Piponi’s [http://blog.sigfpe.com/2006/10/monads-field-guide.html field guide], Tim Newsham’s [http://www.thenewsh.com/~newsham/haskell/monad.html What’s a Monad?], and Chris Smith's excellent article [http://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/ Why Do Monads Matter?]. There are also many blog posts which have been written on various aspects of monads; a collection of links can be found under [[Blog articles/Monads]].<br />
<br />
For help constructing monads from scratch, and for obtaining a "deep embedding" of monad operations suitable for use in, say, compiling a domain-specific language, see [http://projects.haskell.org/operational Apfelmus's operational package].<br />
<br />
One of the quirks of the <code>Monad</code> class and the Haskell type system is that it is not possible to straightforwardly declare <code>Monad</code> instances for types which require a class constraint on their data, even if they are monads from a mathematical point of view. For example, <code>Data.Set</code> requires an <code>Ord</code> constraint on its data, so it cannot be easily made an instance of <code>Monad</code>. A solution to this problem was [http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros first described by Eric Kidd], and later made into a [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmonad library named rmonad] by Ganesh Sittampalam and Peter Gavin.<br />
<br />
There are many good reasons for eschewing <code>do</code> notation; some have gone so far as to [[Do_notation_considered_harmful|consider it harmful]].<br />
<br />
Monads can be generalized in various ways; for an exposition of one possibility, see Robert Atkey’s paper on [http://homepages.inf.ed.ac.uk/ratkey/paramnotions-jfp.pdf parameterized monads], or Dan Piponi’s [http://blog.sigfpe.com/2009/02/beyond-monads.html Beyond Monads].<br />
<br />
For the categorically inclined, monads can be viewed as monoids ([http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html From Monoids to Monads]) and also as closure operators [http://blog.plover.com/math/monad-closure.html Triples and Closure]. Derek Elkins’s article in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13 of the Monad.Reader] contains an exposition of the category-theoretic underpinnings of some of the standard <code>Monad</code> instances, such as <code>State</code> and <code>Cont</code>. Jonathan Hill and Keith Clarke have [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.6497 an early paper explaining the connection between monads as they arise in category theory and as used in functional programming]. There is also a [http://okmij.org/ftp/Computation/IO-monad-history.html web page by Oleg Kiselyov] explaining the history of the IO monad.<br />
<br />
Links to many more research papers related to monads can be found under [[Research papers/Monads and arrows]].<br />
<br />
=Monad transformers=<br />
<br />
One would often like to be able to combine two monads into one: for example, to have stateful, nondeterministic computations (<code>State</code> + <code>[]</code>), or computations which may fail and can consult a read-only environment (<code>Maybe</code> + <code>Reader</code>), and so on. Unfortunately, monads do not compose as nicely as applicative functors (yet another reason to use <code>Applicative</code> if you don’t need the full power that <code>Monad</code> provides), but some monads can be combined in certain ways.<br />
<br />
==Standard monad transformers==<br />
<br />
The [http://hackage.haskell.org/package/transformers transformers] library provides a number of standard ''monad transformers''. Each monad transformer adds a particular capability/feature/effect to any existing monad.<br />
<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Identity.html <code>IdentityT</code>] is the identity transformer, which maps a monad to (something isomorphic to) itself. This may seem useless at first glance, but it is useful for the same reason that the <code>id</code> function is useful -- it can be passed as an argument to things which are parameterized over an arbitrary monad transformer, when you do not actually want any extra capabilities.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-State.html <code>StateT</code>] adds a read-write state.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Reader.html <code>ReaderT</code>] adds a read-only environment.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Writer.html <code>WriterT</code>] adds a write-only log.<br />
* [http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-RWS.html <code>RWST</code>] conveniently combines <code>ReaderT</code>, <code>WriterT</code>, and <code>StateT</code> into one.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Maybe.html <code>MaybeT</code>] adds the possibility of failure.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Error.html <code>ErrorT</code>] adds the possibility of failure with an arbitrary type to represent errors.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-List.html <code>ListT</code>] adds non-determinism (however, see the discussion of <code>ListT</code> below).<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Cont.html <code>ContT</code>] adds continuation handling.<br />
<br />
For example, <code>StateT s Maybe</code> is an instance of <code>Monad</code>; computations of type <code>StateT s Maybe a</code> may fail, and have access to a mutable state of type <code>s</code>. Monad transformers can be multiply stacked. One thing to keep in mind while using monad transformers is that the order of composition matters. For example, when a <code>StateT s Maybe a</code> computation fails, the state ceases being updated (indeed, it simply disappears); on the other hand, the state of a <code>MaybeT (State s) a</code> computation may continue to be modified even after the computation has "failed". This may seem backwards, but it is correct. Monad transformers build composite monads “inside out”; <code>MaybeT (State s) a</code> is isomorphic to <code>s -> (Maybe a, s)</code>. (Lambdabot has an indispensable <code>@unmtl</code> command which you can use to “unpack” a monad transformer stack in this way.)<br />
Intuitively, the monads become "more fundamental" the further inside the stack you get, and the effects of inner monads "have precedence" over the effects of outer ones. Of course, this is just handwaving, and if you are unsure of the proper order for some monads you wish to combine, there is no substitute for using <code>@unmtl</code> or simply trying out the various options.<br />
<br />
==Definition and laws==<br />
<br />
All monad transformers should implement the <code>MonadTrans</code> type class, defined in <code>Control.Monad.Trans.Class</code>:<br />
<br />
<haskell><br />
class MonadTrans t where<br />
lift :: Monad m => m a -> t m a<br />
</haskell><br />
<br />
It allows arbitrary computations in the base monad <code>m</code> to be “lifted” into computations in the transformed monad <code>t m</code>. (Note that type application associates to the left, just like function application, so <code>t m a = (t m) a</code>.)<br />
<br />
<code>lift</code> must satisfy the laws<br />
<haskell><br />
lift . return = return<br />
lift (m >>= f) = lift m >>= (lift . f)<br />
</haskell><br />
which intuitively state that <code>lift</code> transforms <code>m a</code> computations into <code>t m a</code> computations in a "sensible" way, which sends the <code>return</code> and <code>(>>=)</code> of <code>m</code> to the <code>return</code> and <code>(>>=)</code> of <code>t m</code>.<br />
<br />
{{Exercises|<br />
# What is the kind of <code>t</code> in the declaration of <code>MonadTrans</code>?<br />
}}<br />
<br />
==Transformer type classes and "capability" style==<br />
<br />
{{note|The only problem with this scheme is the quadratic number of instances required as the number of standard monad transformers grows—but as the current set of standard monad transformers seems adequate for most common use cases, this may not be that big of a deal.}}<br />
<br />
There are also type classes (provided by the [http://hackage.haskell.org/package/mtl <code>mtl</code> package]) for the operations of each transformer. For example, the <code>MonadState</code> type class provides the state-specific methods <code>get</code> and <code>put</code>, allowing you to conveniently use these methods not only with <code>State</code>, but with any monad which is an instance of <code>MonadState</code>—including <code>MaybeT (State s)</code>, <code>StateT s (ReaderT r IO)</code>, and so on. Similar type classes exist for <code>Reader</code>, <code>Writer</code>, <code>Cont</code>, <code>IO</code>, and others {{noteref}}.<br />
<br />
These type classes serve two purposes. First, they get rid of (most of) the need for explicitly using <code>lift</code>, giving a type-directed way to automatically determine the right number of calls to <code>lift</code>. Simply writing <code>put</code> will be automatically translated into <code>lift . put</code>, <code>lift . lift . put</code>, or something similar depending on what concrete monad stack you are using.<br />
<br />
Second, they give you more flexibility to switch between different concrete monad stacks. For example, if you are writing a state-based algorithm, don't write<br />
<haskell><br />
foo :: State Int Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
but rather<br />
<haskell><br />
foo :: MonadState Int m => m Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
Now, if somewhere down the line you realize you need to introduce the possibility of failure, you might switch from <code>State Int</code> to <code>MaybeT (State Int)</code>. The type of the first version of <code>foo</code> would need to be modified to reflect this change, but the second version of <code>foo</code> can still be used as-is.<br />
<br />
However, this sort of "capability-based" style (<i>e.g.</i> specifying that <code>foo</code> works for any monad with the "state capability") quickly runs into problems when you try to naively scale it up: for example, what if you need to maintain two independent states? A framework for solving this and related problems is described by Schrijvers and Olivera ([http://users.ugent.be/~tschrijv/Research/papers/icfp2011.pdf Monads, zippers and views: virtualizing the monad stack, ICFP 2011]) and is implemented in the [http://hackage.haskell.org/package/Monatron <code>Monatron</code> package].<br />
<br />
==Composing monads==<br />
<br />
Is the composition of two monads always a monad? As hinted previously, the answer is no.<br />
<br />
Since <code>Applicative</code> functors are closed under composition, the problem must lie with <code>join</code>. Indeed, suppose <code>m</code> and <code>n</code> are arbitrary monads; to make a monad out of their composition we would need to be able to implement<br />
<haskell><br />
join :: m (n (m (n a))) -> m (n a)<br />
</haskell><br />
but it is not clear how this could be done in general. The <code>join</code> method for <code>m</code> is no help, because the two occurrences of <code>m</code> are not next to each other (and likewise for <code>n</code>).<br />
<br />
However, one situation in which it can be done is if <code>n</code> ''distributes'' over <code>m</code>, that is, if there is a function<br />
<haskell><br />
distrib :: n (m a) -> m (n a)<br />
</haskell><br />
satisfying certain laws. See Jones and Duponcheel ([http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.2605 Composing Monads]); see also the [[#Traversable|section on Traversable]].<br />
<br />
For a much more in-depth discussion and analysis of the failure of monads to be closed under composition, see [http://stackoverflow.com/questions/13034229/concrete-example-showing-that-monads-are-not-closed-under-composition-with-proo?lq=1 this question on StackOverflow].<br />
<br />
{{Exercises|<br />
* Implement <code>join :: M (N (M (N a))) -> M (N a)</code>, given <code>distrib :: N (M a) -> M (N a)</code> and assuming <code>M</code> and <code>N</code> are instances of <code>Monad</code>.<br />
}}<br />
<br />
==Further reading==<br />
<br />
Much of the monad transformer library (originally [http://hackage.haskell.org/package/mtl <code>mtl</code>], now split between <code>mtl</code> and [http://hackage.haskell.org/package/transformers <code>transformers</code>]), including the <code>Reader</code>, <code>Writer</code>, <code>State</code>, and other monads, as well as the monad transformer framework itself, was inspired by Mark Jones’s classic paper [http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Functional Programming with Overloading and Higher-Order Polymorphism]. It’s still very much worth a read—and highly readable—after almost fifteen years.<br />
<br />
See [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17139 Edward Kmett's mailing list message] for a description of the history and relationships among monad transformer packages (<code>mtl</code>, <code>transformers</code>, <code>monads-fd</code>, <code>monads-tf</code>).<br />
<br />
There are two excellent references on monad transformers. Martin Grabmüller’s [http://www.grabmueller.de/martin/www/pub/Transformers.en.html Monad Transformers Step by Step] is a thorough description, with running examples, of how to use monad transformers to elegantly build up computations with various effects. [http://cale.yi.org/index.php/How_To_Use_Monad_Transformers Cale Gibbard’s article] on how to use monad transformers is more practical, describing how to structure code using monad transformers to make writing it as painless as possible. Another good starting place for learning about monad transformers is a [http://blog.sigfpe.com/2006/05/grok-haskell-monad-transformers.html blog post by Dan Piponi].<br />
<br />
The <code>ListT</code> transformer from the <code>transformers</code> package comes with the caveat that <code>ListT m</code> is only a monad when <code>m</code> is ''commutative'', that is, when <code>ma >>= \a -> mb >>= \b -> foo</code> is equivalent to <code>mb >>= \b -> ma >>= \a -> foo</code> (i.e. the order of <code>m</code>'s effects does not matter). For one explanation why, see Dan Piponi's blog post [http://blog.sigfpe.com/2006/11/why-isnt-listt-monad.html "Why isn't <code><nowiki>ListT []</nowiki></code> a monad"]. For more examples, as well as a design for a version of <code>ListT</code> which does not have this problem, see [http://www.haskell.org/haskellwiki/ListT_done_right <code>ListT</code> done right].<br />
<br />
There is an alternative way to compose monads, using coproducts, as described by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.3581 Lüth and Ghani]. This method is interesting but has not (yet?) seen widespread use. For a more recent alternative, see Kiselyov et al's [http://okmij.org/ftp/Haskell/extensible/exteff.pdf Extensible Effects: An Alternative to Monad Transformers].<br />
<br />
=MonadFix=<br />
<br />
''Note: <code>MonadFix</code> is included here for completeness (and because it is interesting) but seems not to be used much. Skipping this section on a first read-through is perfectly OK (and perhaps even recommended).''<br />
<br />
==<code>mdo</code>/<code>do rec</code> notation==<br />
<br />
{{note|In GHC 7.6, the flag has been changed to <code>-XRecursiveDo</code>.}}<br />
The <code>MonadFix</code> class describes monads which support the special fixpoint operation <code>mfix :: (a -> m a) -> m a</code>, which allows the output of monadic computations to be defined via (effectful) recursion. This is [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation supported in GHC] by a special “recursive do” notation, enabled by the <code>-XDoRec</code> flag{{noteref}}. Within a <code>do</code> block, one may have a nested <code>rec</code> block, like so:<br />
<haskell><br />
do { x <- foo<br />
; rec { y <- baz<br />
; z <- bar<br />
; bob<br />
}<br />
; w <- frob<br />
}<br />
</haskell><br />
Normally (if we had <code>do</code> in place of <code>rec</code> in the above example), <code>y</code> would be in scope in <code>bar</code> and <code>bob</code> but not in <code>baz</code>, and <code>z</code> would be in scope only in <code>bob</code>. With the <code>rec</code>, however, <code>y</code> and <code>z</code> are both in scope in all three of <code>baz</code>, <code>bar</code>, and <code>bob</code>. A <code>rec</code> block is analogous to a <code>let</code> block such as<br />
<haskell><br />
let { y = baz<br />
; z = bar<br />
}<br />
in bob<br />
</haskell><br />
because, in Haskell, every variable bound in a <code>let</code>-block is in scope throughout the entire block. (From this point of view, Haskell's normal <code>do</code> blocks are analogous to Scheme's <code>let*</code> construct.)<br />
<br />
What could such a feature be used for? One of the motivating examples given in the original paper describing <code>MonadFix</code> (see below) is encoding circuit descriptions. A line in a <code>do</code>-block such as <br />
<haskell><br />
x <- gate y z<br />
</haskell><br />
describes a gate whose input wires are labeled <code>y</code> and <code>z</code> and whose output wire is labeled <code>x</code>. Many (most?) useful circuits, however, involve some sort of feedback loop, making them impossible to write in a normal <code>do</code>-block (since some wire would have to be mentioned as an input ''before'' being listed as an output). Using a <code>rec</code> block solves this problem.<br />
<br />
==Examples and intuition==<br />
<br />
Of course, not every monad supports such recursive binding. However, as mentioned above, it suffices to have an implementation of <code>mfix :: (a -> m a) -> m a</code>, satisfying a few laws. Let's try implementing <code>mfix</code> for the <code>Maybe</code> monad. That is, we want to implement a function<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
</haskell><br />
{{note|Actually, <code>fix</code> is implemented slightly differently for efficiency reasons; but the given definition is equivalent and simpler for the present purpose.}}<br />
Let's think for a moment about the implementation {{noteref}} of the non-monadic <code>fix :: (a -> a) -> a</code>:<br />
<haskell><br />
fix f = f (fix f)<br />
</haskell><br />
Inspired by <code>fix</code>, our first attempt at implementing <code>maybeFix</code> might be something like<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = maybeFix f >>= f<br />
</haskell><br />
This has the right type. However, something seems wrong: there is nothing in particular here about <code>Maybe</code>; <code>maybeFix</code> actually has the more general type <code>Monad m => (a -> m a) -> m a</code>. But didn't we just say that not all monads support <code>mfix</code>?<br />
<br />
The answer is that although this implementation of <code>maybeFix</code> has the right type, it does ''not'' have the intended semantics. If we think about how <code>(>>=)</code> works for the <code>Maybe</code> monad (by pattern-matching on its first argument to see whether it is <code>Nothing</code> or <code>Just</code>) we can see that this definition of <code>maybeFix</code> is completely useless: it will just recurse infinitely, trying to decide whether it is going to return <code>Nothing</code> or <code>Just</code>, without ever even so much as a glance in the direction of <code>f</code>.<br />
<br />
The trick is to simply ''assume'' that <code>maybeFix</code> will return <code>Just</code>, and get on with life!<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = ma<br />
where ma = f (fromJust ma)<br />
</haskell><br />
This says that the result of <code>maybeFix</code> is <code>ma</code>, and assuming that <code>ma = Just x</code>, it is defined (recursively) to be equal to <code>f x</code>.<br />
<br />
Why is this OK? Isn't <code>fromJust</code> almost as bad as <code>unsafePerformIO</code>? Well, usually, yes. This is just about the only situation in which it is justified! The interesting thing to note is that <code>maybeFix</code> ''will never crash'' -- although it may, of course, fail to terminate. The only way we could get a crash is if we try to evaluate <code>fromJust ma</code> when we know that <code>ma = Nothing</code>. But how could we know <code>ma = Nothing</code>? Since <code>ma</code> is defined as <code>f (fromJust ma)</code>, it must be that this expression has already been evaluated to <code>Nothing</code> -- in which case there is no reason for us to be evaluating <code>fromJust ma</code> in the first place! <br />
<br />
To see this from another point of view, we can consider three possibilities. First, if <code>f</code> outputs <code>Nothing</code> without looking at its argument, then <code>maybeFix f</code> clearly returns <code>Nothing</code>. Second, if <code>f</code> always outputs <code>Just x</code>, where <code>x</code> depends on its argument, then the recursion can proceed usefully: <code>fromJust ma</code> will be able to evaluate to <code>x</code>, thus feeding <code>f</code>'s output back to it as input. Third, if <code>f</code> tries to use its argument to decide whether to output <code>Just</code> or <code>Nothing</code>, then <code>maybeFix f</code> will not terminate: evaluating <code>f</code>'s argument requires evaluating <code>ma</code> to see whether it is <code>Just</code>, which requires evaluating <code>f (fromJust ma)</code>, which requires evaluating <code>ma</code>, ... and so on.<br />
<br />
There are also instances of <code>MonadFix</code> for lists (which works analogously to the instance for <code>Maybe</code>), for <code>ST</code>, and for <code>IO</code>. The [http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/System-IO.html#fixIO instance for <code>IO</code>] is particularly amusing: it creates a new (empty) <code>MVar</code>, immediately reads its contents using <code>unsafeInterleaveIO</code> (which delays the actual reading lazily until the value is needed), uses the contents of the <code>MVar</code> to compute a new value, which it then writes back into the <code>MVar</code>. It almost seems, spookily, that <code>mfix</code> is sending a value back in time to itself through the <code>MVar</code> -- though of course what is really going on is that the reading is delayed just long enough (via <code>unsafeInterleaveIO</code>) to get the process bootstrapped.<br />
<br />
{{Exercises|<br />
* Implement a <code>MonadFix</code> instance for <code>[]</code>.<br />
}}<br />
<br />
==GHC 7.6 changes==<br />
<br />
GHC 7.6 reinstated the old <code>mdo</code> syntax, so the example at the start of this section can be written<br />
<br />
<haskell><br />
mdo { x <- foo<br />
; y <- baz<br />
; z <- bar<br />
; bob<br />
; w <- frob<br />
}<br />
</haskell><br />
<br />
which will be translated into the original example (assuming that, say, <code>bar</code> and <code>bob</code> refer to <code>y</code>. The difference is that <code>mdo</code> will analyze the code in order to find minimal recursive blocks, which will be placed in <code>rec</code> blocks, whereas <code>rec</code> blocks desugar directly into calls to <code>mfix</code> without any further analysis. <br />
==Further reading==<br />
<br />
For more information (such as the precise desugaring rules for <code>rec</code> blocks), see Levent Erkök and John Launchbury's 2002 Haskell workshop paper, [http://sites.google.com/site/leventerkok/recdo.pdf?attredirects=0 A Recursive do for Haskell], or for full details, Levent Erkök’s thesis, [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.15.1543&rep=rep1&type=pdf Value Recursion in Monadic Computations]. (Note, while reading, that <code>MonadFix</code> used to be called <code>MonadRec</code>.) You can also read the [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation GHC user manual section on recursive do-notation].<br />
<br />
=Semigroup=<br />
<br />
A semigroup is a set <math>S\ </math> together with a binary operation <math>\oplus\ </math> which<br />
combines elements from <math>S\ </math>. The <math>\oplus\ </math> operator is required to be associative<br />
(that is, <math>(a \oplus b) \oplus c = a \oplus (b \oplus c)\ </math>, for any<br />
<math>a,b,c\ </math> which are elements of <math>S\ </math>).<br />
<br />
For example, the natural numbers under addition form a semigroup: the sum of any two natural numbers is a natural number, and <math>(a+b)+c = a+(b+c)\ </math> for any natural numbers <math>a\ </math>, <math>b\ </math>, and <math>c\,\ </math>. The integers under multiplication also form a semigroup, as do the integers (or rationals, or reals) under <math>\max\ </math> or <math>\min\ </math>, Boolean values under conjunction and disjunction, lists under concatenation, functions from a set to itself under composition ... Semigroups show up all over the place, once you know to look for them.<br />
<br />
==Definition==<br />
<br />
Semigroups are not (yet?) defined in the base package, but the {{HackagePackage|id=semigroups}} package provides a standard definition.<br />
<br />
The definition of the <code>Semigroup</code> type class ([http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock]) is as follows:<br />
<br />
<haskell><br />
class Semigroup a where<br />
(<>) :: a -> a -> a<br />
<br />
sconcat :: NonEmpty a -> a<br />
sconcat = sconcat (a :| as) = go a as where<br />
go b (c:cs) = b <> go c cs<br />
go b [] = b<br />
<br />
times1p :: Whole n => n -> a -> a<br />
times1p = ...<br />
</haskell><br />
<br />
The really important method is <code>(<>)</code>, representing the associative binary operation. The other two methods have default implementations in terms of <code>(<>)</code>, and are included in the type class in case some instances can give more efficient implementations than the default. <code>sconcat</code> reduces a nonempty list using <code>(<>)</code>; <code>times1p n</code> is equivalent to (but more efficient than) <code>sconcat . replicate n</code>. See the [http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock documentation] for more information on <code>sconcat</code> and <code>times1p</code>.<br />
<br />
==Laws==<br />
<br />
The only law is that <code>(<>)</code> must be associative:<br />
<br />
<haskell><br />
(x <> y) <> z = x <> (y <> z)<br />
</haskell><br />
<br />
=Monoid=<br />
<br />
Many semigroups have a special element <math>e</math> for which the binary operation <math>\oplus</math> is the identity, that is, <math>e \oplus x = x \oplus e = x</math> for every element <math>x</math>. Such a semigroup-with-identity-element is called a ''monoid''.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Monoid</code> type class (defined in<br />
<code>Data.Monoid</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html haddock]) is:<br />
<br />
<haskell><br />
class Monoid a where<br />
mempty :: a<br />
mappend :: a -> a -> a<br />
<br />
mconcat :: [a] -> a<br />
mconcat = foldr mappend mempty<br />
</haskell><br />
<br />
The <code>mempty</code> value specifies the identity element of the monoid, and <code>mappend</code><br />
is the binary operation. The default definition for <code>mconcat</code><br />
“reduces” a list of elements by combining them all with <code>mappend</code>,<br />
using a right fold. It is only in the <code>Monoid</code> class so that specific<br />
instances have the option of providing an alternative, more efficient<br />
implementation; usually, you can safely ignore <code>mconcat</code> when creating<br />
a <code>Monoid</code> instance, since its default definition will work just fine.<br />
<br />
The <code>Monoid</code> methods are rather unfortunately named; they are inspired<br />
by the list instance of <code>Monoid</code>, where indeed <code>mempty = []</code> and <code>mappend = (++)</code>, but this is misleading since many<br />
monoids have little to do with appending (see these [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 Comments from OCaml Hacker Brian Hurt] on the Haskell-cafe mailing list). This was improved in GHC 7.4, where <code>(<>)</code> was added as an alias to <code>mappend</code>.<br />
<br />
==Laws==<br />
<br />
Of course, every <code>Monoid</code> instance should actually be a monoid in the<br />
mathematical sense, which implies these laws:<br />
<br />
<haskell><br />
mempty `mappend` x = x<br />
x `mappend` mempty = x<br />
(x `mappend` y) `mappend` z = x `mappend` (y `mappend` z)<br />
</haskell><br />
<br />
==Instances==<br />
<br />
There are quite a few interesting <code>Monoid</code> instances defined in <code>Data.Monoid</code>.<br />
<br />
<ul><br />
<li><code>[a]</code> is a <code>Monoid</code>, with <code>mempty = []</code> and <code>mappend = (++)</code>. It is not hard to check that <code>(x ++ y) ++ z = x ++ (y ++ z)</code> for any lists <code>x</code>, <code>y</code>, and <code>z</code>, and that the empty list is the identity: <code>[] ++ x = x ++ [] = x</code>.</li><br />
<br />
<li>As noted previously, we can make a monoid out of any numeric type under either addition or multiplication. However, since we can’t have two instances for the same type, <code>Data.Monoid</code> provides two <code>newtype</code> wrappers, <code>Sum</code> and <code>Product</code>, with appropriate <code>Monoid</code> instances.<br />
<br />
<haskell><br />
> getSum (mconcat . map Sum $ [1..5])<br />
15<br />
> getProduct (mconcat . map Product $ [1..5])<br />
120<br />
</haskell><br />
<br />
This example code is silly, of course; we could just write<br />
<code>sum [1..5]</code> and <code>product [1..5]</code>. Nevertheless, these instances are useful in more generalized settings, as we will see in the [[Foldable|section on <code>Foldable</code>]].</li><br />
<br />
<li><code>Any</code> and <code>All</code> are <code>newtype</code> wrappers providing <code>Monoid</code> instances for <code>Bool</code> (under disjunction and conjunction, respectively).</li><br />
<br />
<li> There are three instances for <code>Maybe</code>: a basic instance which lifts a <code>Monoid</code> instance for <code>a</code> to an instance for <code>Maybe a</code>, and two <code>newtype</code> wrappers <code>First</code> and <code>Last</code> for which <code>mappend</code> selects the first (respectively last) non-<code>Nothing</code> item.</li><br />
<br />
<li><code>Endo a</code> is a newtype wrapper for functions <code>a -> a</code>, which form a monoid under composition.</li><br />
<br />
<li>There are several ways to “lift” <code>Monoid</code> instances to instances with additional structure. We have already seen that an instance for <code>a</code> can be lifted to an instance for <code>Maybe a</code>. There are also tuple instances: if <code>a</code> and <code>b</code> are instances of <code>Monoid</code>, then so is <code>(a,b)</code>, using the monoid operations for <code>a</code> and <code>b</code> in the obvious pairwise manner. Finally, if <code>a</code> is a <code>Monoid</code>, then so is the function type <code>e -> a</code> for any <code>e</code>; in particular, <code>g `mappend` h</code> is the function which applies both <code>g</code> and <code>h</code> to its argument and then combines the results using the underlying <code>Monoid</code> instance for <code>a</code>. This can be quite useful and elegant (see [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/52416 example]).</li><br />
<br />
<li>The type <code>Ordering = LT | EQ | GT</code> is a <code>Monoid</code>, defined in such a way that <code>mconcat (zipWith compare xs ys)</code> computes the lexicographic ordering of <code>xs</code> and <code>ys</code> (if <code>xs</code> and <code>ys</code> have the same length). In particular, <code>mempty = EQ</code>, and <code>mappend</code> evaluates to its leftmost non-<code>EQ</code> argument (or <code>EQ</code> if both arguments are <code>EQ</code>). This can be used together with the function instance of <code>Monoid</code> to do some clever things ([http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx example]).</li><br />
<br />
<li>There are also <code>Monoid</code> instances for several standard data structures in the containers library ([http://hackage.haskell.org/packages/archive/containers/0.2.0.0/doc/html/index.html haddock]), including <code>Map</code>, <code>Set</code>, and <code>Sequence</code>.</li><br />
</ul><br />
<br />
<code>Monoid</code> is also used to enable several other type class instances.<br />
As noted previously, we can use <code>Monoid</code> to make <code>((,) e)</code> an instance of <code>Applicative</code>:<br />
<br />
<haskell><br />
instance Monoid e => Applicative ((,) e) where<br />
pure x = (mempty, x)<br />
(u, f) <*> (v, x) = (u `mappend` v, f x)<br />
</haskell><br />
<br />
<code>Monoid</code> can be similarly used to make <code>((,) e)</code> an instance of <code>Monad</code> as well; this is known as the ''writer monad''. As we’ve already seen, <code>Writer</code> and <code>WriterT</code> are a newtype wrapper and transformer for this monad, respectively.<br />
<br />
<code>Monoid</code> also plays a key role in the <code>Foldable</code> type class (see section [[#Foldable|Foldable]]).<br />
<br />
==Other monoidal classes: Alternative, MonadPlus, ArrowPlus==<br />
<br />
The <code>Alternative</code> type class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html#g:2 haddock])<br />
is for <code>Applicative</code> functors which also have<br />
a monoid structure:<br />
<br />
<haskell><br />
class Applicative f => Alternative f where<br />
empty :: f a<br />
(<|>) :: f a -> f a -> f a<br />
</haskell><br />
<br />
Of course, instances of <code>Alternative</code> should satisfy the monoid laws<br />
<br />
<haskell><br />
empty <|> x = x<br />
x <|> empty = x<br />
(x <|> y) <|> z = x <|> (y <|> z)<br />
</haskell><br />
<br />
Likewise, <code>MonadPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html#t:MonadPlus haddock])<br />
is for <code>Monad</code>s with a monoid structure:<br />
<br />
<haskell><br />
class Monad m => MonadPlus m where<br />
mzero :: m a<br />
mplus :: m a -> m a -> m a<br />
</haskell><br />
<br />
The <code>MonadPlus</code> documentation states that it is intended to model<br />
monads which also support “choice and failure”; in addition to the<br />
monoid laws, instances of <code>MonadPlus</code> are expected to satisfy<br />
<br />
<haskell><br />
mzero >>= f = mzero<br />
v >> mzero = mzero<br />
</haskell><br />
<br />
which explains the sense in which <code>mzero</code> denotes failure. Since<br />
<code>mzero</code> should be the identity for <code>mplus</code>, the computation <code>m1 `mplus` m2</code> succeeds (evaluates to something other than <code>mzero</code>) if<br />
either <code>m1</code> or <code>m2</code> does; so <code>mplus</code> represents choice. The <code>guard</code><br />
function can also be used with instances of <code>MonadPlus</code>; it requires a<br />
condition to be satisfied and fails (using <code>mzero</code>) if it is not. A<br />
simple example of a <code>MonadPlus</code> instance is <code>[]</code>, which is exactly the<br />
same as the <code>Monoid</code> instance for <code>[]</code>: the empty list represents<br />
failure, and list concatenation represents choice. In general,<br />
however, a <code>MonadPlus</code> instance for a type need not be the same as its<br />
<code>Monoid</code> instance; <code>Maybe</code> is an example of such a type. A great<br />
introduction to the <code>MonadPlus</code> type class, with interesting examples<br />
of its use, is Doug Auclair’s ''MonadPlus: What a Super Monad!'' in [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad.Reader issue 11].<br />
<br />
There used to be a type class called <code>MonadZero</code> containing only<br />
<code>mzero</code>, representing monads with failure. The <code>do</code>-notation requires<br />
some notion of failure to deal with failing pattern matches.<br />
Unfortunately, <code>MonadZero</code> was scrapped in favor of adding the <code>fail</code><br />
method to the <code>Monad</code> class. If we are lucky, someday <code>MonadZero</code> will<br />
be restored, and <code>fail</code> will be banished to the bit bucket where it<br />
belongs (see [[MonadPlus reform proposal]]). The idea is that any<br />
<code>do</code>-block which uses pattern matching (and hence may fail) would require<br />
a <code>MonadZero</code> constraint; otherwise, only a <code>Monad</code> constraint would be<br />
required.<br />
<br />
Finally, <code>ArrowZero</code> and <code>ArrowPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#t:ArrowZero haddock])<br />
represent <code>Arrow</code>s ([[#Arrow|see below]]) with a<br />
monoid structure:<br />
<br />
<haskell><br />
class Arrow arr => ArrowZero arr where<br />
zeroArrow :: b `arr` c<br />
<br />
class ArrowZero arr => ArrowPlus arr where<br />
(<+>) :: (b `arr` c) -> (b `arr` c) -> (b `arr` c)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Monoids have gotten a fair bit of attention recently, ultimately due<br />
to<br />
[http://enfranchisedmind.com/blog/posts/random-thoughts-on-haskell/ a blog post by Brian Hurt], in which he<br />
complained about the fact that the names of many Haskell type classes<br />
(<code>Monoid</code> in particular) are taken from abstract mathematics. This<br />
resulted in [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 a long Haskell-cafe thread]<br />
arguing the point and discussing monoids in general.<br />
<br />
{{note|May its name live forever.}}<br />
<br />
However, this was quickly followed by several blog posts about<br />
<code>Monoid</code> {{noteref}}. First, Dan Piponi<br />
wrote a great introductory post, [http://blog.sigfpe.com/2009/01/haskell-monoids-and-their-uses.html Haskell Monoids and their Uses]. This was quickly followed by<br />
Heinrich Apfelmus’s [http://apfelmus.nfshost.com/monoid-fingertree.html Monoids and Finger Trees], an accessible exposition of<br />
Hinze and Paterson’s [http://www.soi.city.ac.uk/%7Eross/papers/FingerTree.html classic paper on 2-3 finger trees], which makes very clever<br />
use of <code>Monoid</code> to implement an elegant and generic data structure.<br />
Dan Piponi then wrote two fascinating articles about using <code>Monoids</code><br />
(and finger trees): [http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html Fast Incremental Regular Expressions] and [http://blog.sigfpe.com/2009/01/beyond-regular-expressions-more.html Beyond Regular Expressions]<br />
<br />
In a similar vein, David Place’s article on improving <code>Data.Map</code> in<br />
order to compute incremental folds (see [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad Reader issue 11])<br />
is also a<br />
good example of using <code>Monoid</code> to generalize a data structure.<br />
<br />
Some other interesting examples of <code>Monoid</code> use include [http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx building elegant list sorting combinators], [http://byorgey.wordpress.com/2008/04/17/collecting-unstructured-information-with-the-monoid-of-partial-knowledge/ collecting unstructured information], [http://izbicki.me/blog/gausian-distributions-are-monoids combining probability distributions], and a brilliant series of posts by Chung-Chieh Shan and Dylan Thurston using <code>Monoid</code>s to [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers1/ elegantly solve a difficult combinatorial puzzle] (followed by [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers2/ part 2], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers3/ part 3], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers4/ part 4]).<br />
<br />
As unlikely as it sounds, monads can actually be viewed as a sort of<br />
monoid, with <code>join</code> playing the role of the binary operation and<br />
<code>return</code> the role of the identity; see [http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html Dan Piponi’s blog post].<br />
<br />
=Foldable=<br />
<br />
The <code>Foldable</code> class, defined in the <code>Data.Foldable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html haddock]), abstracts over containers which can be<br />
“folded” into a summary value. This allows such folding operations<br />
to be written in a container-agnostic way.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Foldable</code> type class is:<br />
<br />
<haskell><br />
class Foldable t where<br />
fold :: Monoid m => t m -> m<br />
foldMap :: Monoid m => (a -> m) -> t a -> m<br />
<br />
foldr :: (a -> b -> b) -> b -> t a -> b<br />
foldl :: (a -> b -> a) -> a -> t b -> a<br />
foldr1 :: (a -> a -> a) -> t a -> a<br />
foldl1 :: (a -> a -> a) -> t a -> a<br />
</haskell><br />
<br />
This may look complicated, but in fact, to make a <code>Foldable</code> instance<br />
you only need to implement one method: your choice of <code>foldMap</code> or<br />
<code>foldr</code>. All the other methods have default implementations in terms<br />
of these, and are presumably included in the class in case more<br />
efficient implementations can be provided.<br />
<br />
==Instances and examples==<br />
<br />
The type of <code>foldMap</code> should make it clear what it is supposed to do:<br />
given a way to convert the data in a container into a <code>Monoid</code> (a<br />
function <code>a -> m</code>) and a container of <code>a</code>’s (<code>t a</code>), <code>foldMap</code><br />
provides a way to iterate over the entire contents of the container,<br />
converting all the <code>a</code>’s to <code>m</code>’s and combining all the <code>m</code>’s with<br />
<code>mappend</code>. The following code shows two examples: a simple<br />
implementation of <code>foldMap</code> for lists, and a binary tree example<br />
provided by the <code>Foldable</code> documentation.<br />
<br />
<haskell><br />
instance Foldable [] where<br />
foldMap g = mconcat . map g<br />
<br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Foldable Tree where<br />
foldMap f Empty = mempty<br />
foldMap f (Leaf x) = f x<br />
foldMap f (Node l k r) = foldMap f l `mappend` f k `mappend` foldMap f r<br />
</haskell><br />
<br />
The <code>foldr</code> function has a type similar to the <code>foldr</code> found in the <code>Prelude</code>, but<br />
more general, since the <code>foldr</code> in the <code>Prelude</code> works only on lists.<br />
<br />
The <code>Foldable</code> module also provides instances for <code>Maybe</code> and <code>Array</code>;<br />
additionally, many of the data structures found in the standard [http://hackage.haskell.org/package/containers containers library] (for example, <code>Map</code>, <code>Set</code>, <code>Tree</code>,<br />
and <code>Sequence</code>) provide their own <code>Foldable</code> instances.<br />
<br />
{{Exercises|<br />
# What is the type of <code>foldMap . foldMap</code>? Or <code>foldMap . foldMap . foldMap</code>, etc.? What do they do?<br />
}}<br />
<br />
==Derived folds==<br />
<br />
Given an instance of <code>Foldable</code>, we can write generic,<br />
container-agnostic functions such as:<br />
<br />
<haskell><br />
-- Compute the size of any container.<br />
containerSize :: Foldable f => f a -> Int<br />
containerSize = getSum . foldMap (const (Sum 1))<br />
<br />
-- Compute a list of elements of a container satisfying a predicate.<br />
filterF :: Foldable f => (a -> Bool) -> f a -> [a]<br />
filterF p = foldMap (\a -> if p a then [a] else [])<br />
<br />
-- Get a list of all the Strings in a container which include the<br />
-- letter a.<br />
aStrings :: Foldable f => f String -> [String]<br />
aStrings = filterF (elem 'a')<br />
</haskell><br />
<br />
The <code>Foldable</code> module also provides a large number of predefined<br />
folds, many of which are generalized versions of <code>Prelude</code> functions of the<br />
same name that only work on lists: <code>concat</code>, <code>concatMap</code>, <code>and</code>,<br />
<code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>),<br />
<code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>.<br />
<br />
The important function <code>toList</code> is also provided, which turns any <code>Foldable</code> structure into a list of its elements in left-right order; it works by folding with the list monoid.<br />
<br />
There are also generic functions that work with <code>Applicative</code> or<br />
<code>Monad</code> instances to generate some sort of computation from each<br />
element in a container, and then perform all the side effects from<br />
those computations, discarding the results: <code>traverse_</code>, <code>sequenceA_</code>,<br />
and others. The results must be discarded because the <code>Foldable</code><br />
class is too weak to specify what to do with them: we cannot, in<br />
general, make an arbitrary <code>Applicative</code> or <code>Monad</code> instance into a <code>Monoid</code>, but we can make <code>m ()</code> into a <code>Monoid</code> for any such <code>m</code>. If we do have an <code>Applicative</code> or <code>Monad</code> with a monoid<br />
structure—that is, an <code>Alternative</code> or a <code>MonadPlus</code>—then we can<br />
use the <code>asum</code> or <code>msum</code> functions, which can combine the results as<br />
well. Consult the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html <code>Foldable</code> documentation] for<br />
more details on any of these functions.<br />
<br />
Note that the <code>Foldable</code> operations always forget the structure of<br />
the container being folded. If we start with a container of type <code>t a</code> for some <code>Foldable t</code>, then <code>t</code> will never appear in the output<br />
type of any operations defined in the <code>Foldable</code> module. Many times<br />
this is exactly what we want, but sometimes we would like to be able<br />
to generically traverse a container while preserving its<br />
structure—and this is exactly what the <code>Traversable</code> class provides,<br />
which will be discussed in the next section.<br />
<br />
{{Exercises|<br />
# Implement <code>toList :: Foldable f {{=}}> f a -> [a]</code>.<br />
# Pick some of the following functions to implement: <code>concat</code>, <code>concatMap</code>, <code>and</code>, <code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>), <code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>. Figure out how they generalize to <code>Foldable</code> and come up with elegant implementations using <code>fold</code> or <code>foldMap</code> along with appropriate <code>Monoid</code> instances.<br />
}}<br />
<br />
==Foldable actually isn't==<br />
<br />
The generic term "fold" is often used to refer to the more technical concept of [[Catamorphisms|catamorphism]]. Intuitively, given a way to summarize "one level of structure" (where recursive subterms have already been replaced with their summaries), a catamorphism can summarize an entire recursive structure. It is important to realize that <code>Foldable</code> does <i>not</i> correspond to catamorphisms, but to something weaker. In particular, <code>Foldable</code> allows observing only the left-right order of elements within a structure, not the actual structure itself. Put another way, every use of <code>Foldable</code> can be expressed in terms of <code>toList</code>. For example, <code>fold</code> itself is equivalent to <code>mconcat . toList</code>.<br />
<br />
This is sufficient for many tasks, but not all. For example, consider trying to compute the depth of a <code>Tree</code>: try as we might, there is no way to implement it using <code>Foldable</code>. However, it <i>can</i> be implemented as a catamorphism.<br />
<br />
==Further reading==<br />
<br />
The <code>Foldable</code> class had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s paper]<br />
introducing <code>Applicative</code>, although it has<br />
been fleshed out quite a bit from the form in the paper.<br />
<br />
An interesting use of <code>Foldable</code> (as well as <code>Traversable</code>) can be<br />
found in Janis Voigtländer’s paper [http://doi.acm.org/10.1145/1480881.1480904 Bidirectionalization for free!].<br />
<br />
=Traversable=<br />
<br />
==Definition==<br />
<br />
The <code>Traversable</code> type class, defined in the <code>Data.Traversable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html haddock]), is:<br />
<br />
<haskell><br />
class (Functor t, Foldable t) => Traversable t where<br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
mapM :: Monad m => (a -> m b) -> t a -> m (t b)<br />
sequence :: Monad m => t (m a) -> m (t a)<br />
</haskell><br />
<br />
As you can see, every <code>Traversable</code> is also a foldable functor. Like<br />
<code>Foldable</code>, there is a lot in this type class, but making instances is<br />
actually rather easy: one need only implement <code>traverse</code> or<br />
<code>sequenceA</code>; the other methods all have default implementations in<br />
terms of these functions. A good exercise is to figure out what the default<br />
implementations should be: given either <code>traverse</code> or <code>sequenceA</code>, how<br />
would you define the other three methods? (Hint for <code>mapM</code>:<br />
<code>Control.Applicative</code> exports the <code>WrapMonad</code> newtype, which makes any<br />
<code>Monad</code> into an <code>Applicative</code>. The <code>sequence</code> function can be implemented in terms<br />
of <code>mapM</code>.)<br />
<br />
==Intuition==<br />
<br />
The key method of the <code>Traversable</code> class, and the source of its<br />
unique power, is <code>sequenceA</code>. Consider its type:<br />
<haskell><br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
</haskell><br />
This answers the fundamental question: when can we commute two<br />
functors? For example, can we turn a tree of lists into a list of<br />
trees?<br />
<br />
The ability to compose two monads depends crucially on this ability to<br />
commute functors. Intuitively, if we want to build a composed monad<br />
<code>M a = m (n a)</code> out of monads <code>m</code> and <code>n</code>, then to be able to<br />
implement <code>join :: M (M a) -> M a</code>, that is,<br />
<code>join :: m (n (m (n a))) -> m (n a)</code>, we have to be able to commute<br />
the <code>n</code> past the <code>m</code> to get <code>m (m (n (n a)))</code>, and then we can use the<br />
<code>join</code>s for <code>m</code> and <code>n</code> to produce something of type <code>m (n a)</code>. See<br />
[http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Mark Jones’s paper] for more details.<br />
<br />
Alternatively, looking at the type of <code>traverse</code>,<br />
<haskell><br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
</haskell><br />
leads us to view <code>Traversable</code> as a generalization of <code>Functor</code>. <code>traverse</code> is an "effectful <code>fmap</code>": it allows us to map over a structure of type <code>t a</code>, applying a function to every element of type <code>a</code> and in order to produce a new structure of type <code>t b</code>; but along the way the function may have some effects (captured by the applicative functor <code>f</code>).<br />
<br />
{{Exercises|<br />
# There are at least two natural ways to turn a tree of lists into a list of trees. What are they, and why?<br />
# Give a natural way to turn a list of trees into a tree of lists.<br />
# What is the type of <code>traverse . traverse</code>? What does it do?<br />
}}<br />
<br />
==Instances and examples==<br />
<br />
What’s an example of a <code>Traversable</code> instance?<br />
The following code shows an example instance for the same<br />
<code>Tree</code> type used as an example in the previous <code>Foldable</code> section. It<br />
is instructive to compare this instance with a <code>Functor</code> instance for<br />
<code>Tree</code>, which is also shown.<br />
<br />
<haskell><br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Traversable Tree where<br />
traverse g Empty = pure Empty<br />
traverse g (Leaf x) = Leaf <$> g x<br />
traverse g (Node l x r) = Node <$> traverse g l<br />
<*> g x<br />
<*> traverse g r<br />
<br />
instance Functor Tree where<br />
fmap g Empty = Empty<br />
fmap g (Leaf x) = Leaf $ g x<br />
fmap g (Node l x r) = Node (fmap g l)<br />
(g x)<br />
(fmap g r)<br />
</haskell><br />
<br />
It should be clear that the <code>Traversable</code> and <code>Functor</code> instances for<br />
<code>Tree</code> are almost identical; the only difference is that the <code>Functor</code><br />
instance involves normal function application, whereas the<br />
applications in the <code>Traversable</code> instance take place within an<br />
<code>Applicative</code> context, using <code>(<$>)</code> and <code>(<*>)</code>. In fact, this will<br />
be<br />
true for any type.<br />
<br />
Any <code>Traversable</code> functor is also <code>Foldable</code>, and a <code>Functor</code>. We can see<br />
this not only from the class declaration, but by the fact that we can<br />
implement the methods of both classes given only the <code>Traversable</code><br />
methods.<br />
<br />
The standard libraries provide a number of <code>Traversable</code> instances,<br />
including instances for <code>[]</code>, <code>Maybe</code>, <code>Map</code>, <code>Tree</code>, and <code>Sequence</code>.<br />
Notably, <code>Set</code> is not <code>Traversable</code>, although it is <code>Foldable</code>.<br />
<br />
{{Exercises|<br />
# Implement <code>fmap</code> and <code>foldMap</code> using only the <code>Traversable</code> methods. (Note that the <code>Traversable</code> module provides these implementations as <code>fmapDefault</code> and <code>foldMapDefault</code>.)<br />
}}<br />
<br />
==Laws==<br />
<br />
Any instance of <code>Traversable</code> must satisfy the following two laws, where <code>Identity</code> is the identity functor (as defined in the [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Data-Functor-Identity.html <code>Data.Functor.Identity</code> module] from the <code>transformers</code> package), and <code>Compose</code> wraps the composition of two functors (as defined in [http://hackage.haskell.org/packages/archive/transformers/0.3.0.0/doc/html/Data-Functor-Compose.html <code>Data.Functor.Compose</code>]):<br />
<br />
# <code>traverse Identity = Identity</code><br />
# <code>traverse (Compose . fmap g . f) = Compose . fmap (traverse g) . traverse f</code><br />
<br />
The first law essentially says that traversals cannot make up arbitrary effects. The second law explains how doing two traversals in sequence can be collapsed to a single traversal.<br />
<br />
Additionally, suppose <code>eta</code> is an "<code>Applicative</code> morphism", that is,<br />
<haskell><br />
eta :: forall a f g. (Applicative f, Applicative g) => f a -> g a<br />
</haskell><br />
and <code>eta</code> preserves the <code>Applicative</code> operations: <code>eta (pure x) = pure x</code> and <code>eta (x <*> y) = eta x <*> eta y</code>. Then, by parametricity, any instance of <code>Traversable</code> satisfying the above two laws will also satisfy <code>eta . traverse f = traverse (eta . f)</code>.<br />
<br />
==Further reading==<br />
<br />
The <code>Traversable</code> class also had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s <code>Applicative</code> paper],<br />
and is described in more detail in Gibbons and Oliveira, [http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf The Essence of the Iterator Pattern],<br />
which also contains a wealth of references to related work.<br />
<br />
<code>Traversable</code> forms a core component of Edward Kmett's [http://hackage.haskell.org/package/lens lens library]. Watching [https://vimeo.com/56063074 Edward's talk on the subject] is a highly recommended way to gain better insight into <code>Traversable</code>, <code>Foldable</code>, <code>Applicative</code>, and many other things besides.<br />
<br />
For references on the <code>Traversable</code> laws, see Russell O'Connor's [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17778 mailing list post] (and subsequent thread).<br />
<br />
=Category=<br />
<br />
<code>Category</code> is a relatively recent addition to the Haskell standard libraries. It generalizes the notion of function composition to general “morphisms”.<br />
<br />
{{note|GHC 7.6.1 changed its rules regarding types and type variables. Now, any operator at the type level is treated as a type ''constructor'' rather than a type ''variable''; prior to GHC 7.6.1 it was possible to use <code>(~&gt;)</code> instead of <code>`arr`</code>. For more information, see [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/21350 the discussion on the GHC-users mailing list]. For a new approach to nice arrow notation that works with GHC 7.6.1, see [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22615 this message] and also [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22616 this message] from Edward Kmett, though for simplicity I haven't adopted it here.}}<br />
The definition of the <code>Category</code> type class (from<br />
<code>Control.Category</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Category.html haddock]) is shown below. For ease of reading, note that I have used an infix type variable <code>`arr`</code>, in parallel with the infix function type constructor <code>(->)</code>. {{noteref}} This syntax is not part of Haskell 2010. The second definition shown is the one used in the standard libraries. For the remainder of this document, I will use the infix type constructor <code>`arr`</code> for <code>Category</code> as well as <code>Arrow</code>.<br />
<br />
<haskell><br />
class Category arr where<br />
id :: a `arr` a<br />
(.) :: (b `arr` c) -> (a `arr` b) -> (a `arr` c)<br />
<br />
-- The same thing, with a normal (prefix) type constructor<br />
class Category cat where<br />
id :: cat a a<br />
(.) :: cat b c -> cat a b -> cat a c<br />
</haskell><br />
<br />
Note that an instance of <code>Category</code> should be a type constructor which takes two type arguments, that is, something of kind <code>* -> * -> *</code>. It is instructive to imagine the type constructor variable <code>cat</code> replaced by the function constructor <code>(->)</code>: indeed, in this case we recover precisely the familiar identity function <code>id</code> and function composition operator <code>(.)</code> defined in the standard <code>Prelude</code>.<br />
<br />
Of course, the <code>Category</code> module provides exactly such an instance of<br />
<code>Category</code> for <code>(->)</code>. But it also provides one other instance, shown below, which should be familiar from the previous discussion of the <code>Monad</code> laws. <code>Kleisli m a b</code>, as defined in the <code>Control.Arrow</code> module, is just a <code>newtype</code> wrapper around <code>a -> m b</code>.<br />
<br />
<haskell><br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Category (Kleisli m) where<br />
id = Kleisli return<br />
Kleisli g . Kleisli h = Kleisli (h >=> g)<br />
</haskell><br />
<br />
The only law that <code>Category</code> instances should satisfy is that <code>id</code> and <code>(.)</code> should form a monoid—that is, <code>id</code> should be the identity of <code>(.)</code>, and <code>(.)</code> should be associative.<br />
<br />
Finally, the <code>Category</code> module exports two additional operators:<br />
<code>(<<<)</code>, which is just a synonym for <code>(.)</code>, and <code>(>>>)</code>, which is <code>(.)</code> with its arguments reversed. (In previous versions of the libraries, these operators were defined as part of the <code>Arrow</code> class.)<br />
<br />
==Further reading==<br />
<br />
The name <code>Category</code> is a bit misleading, since the <code>Category</code> class cannot represent arbitrary categories, but only categories whose objects are objects of <code>Hask</code>, the category of Haskell types. For a more general treatment of categories within Haskell, see the [http://hackage.haskell.org/package/category-extras category-extras package]. For more about category theory in general, see the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page],<br />
[http://books.google.com/books/about/Category_theory.html?id=-MCJ6x2lC7oC Steve Awodey’s new book], Benjamin Pierce’s [http://books.google.com/books/about/Basic_category_theory_for_computer_scien.html?id=ezdeaHfpYPwC Basic category theory for computer scientists], or [http://folli.loria.fr/cds/1999/esslli99/courses/barr-wells.html Barr and Wells’s category theory lecture notes]. [http://dekudekuplex.wordpress.com/2009/01/19/motivating-learning-category-theory-for-non-mathematicians/ Benjamin Russell’s blog post]<br />
is another good source of motivation and category theory links. You certainly don’t need to know any category theory to be a successful and productive Haskell programmer, but it does lend itself to much deeper appreciation of Haskell’s underlying theory.<br />
<br />
=Arrow=<br />
<br />
The <code>Arrow</code> class represents another abstraction of computation, in a<br />
similar vein to <code>Monad</code> and <code>Applicative</code>. However, unlike <code>Monad</code><br />
and <code>Applicative</code>, whose types only reflect their output, the type of<br />
an <code>Arrow</code> computation reflects both its input and output. Arrows<br />
generalize functions: if <code>arr</code> is an instance of <code>Arrow</code>, a value of<br />
type <code>b `arr` c</code> can be thought of as a computation which takes values of<br />
type <code>b</code> as input, and produces values of type <code>c</code> as output. In the<br />
<code>(->)</code> instance of <code>Arrow</code> this is just a pure function; in general, however,<br />
an arrow may represent some sort of “effectful” computation.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Arrow</code> type class, from<br />
<code>Control.Arrow</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html haddock]), is:<br />
<br />
<haskell><br />
class Category arr => Arrow arr where<br />
arr :: (b -> c) -> (b `arr` c)<br />
first :: (b `arr` c) -> ((b, d) `arr` (c, d))<br />
second :: (b `arr` c) -> ((d, b) `arr` (d, c))<br />
(***) :: (b `arr` c) -> (b' `arr` c') -> ((b, b') `arr` (c, c'))<br />
(&&&) :: (b `arr` c) -> (b `arr` c') -> (b `arr` (c, c'))<br />
</haskell><br />
<br />
{{note|In versions of the <code>base</code><br />
package prior to version 4, there is no <code>Category</code> class, and the<br />
<code>Arrow</code> class includes the arrow composition operator <code>(>>>)</code>. It<br />
also includes <code>pure</code> as a synonym for <code>arr</code>, but this was removed<br />
since it conflicts with the <code>pure</code> from <code>Applicative</code>.}}<br />
<br />
The first thing to note is the <code>Category</code> class constraint, which<br />
means that we get identity arrows and arrow composition for free:<br />
given two arrows <code>g :: b `arr` c</code> and <code>h :: c `arr` d</code>, we can form their<br />
composition <code>g >>> h :: b `arr` d</code> {{noteref}}.<br />
<br />
As should be a familiar pattern by now, the only methods which must be<br />
defined when writing a new instance of <code>Arrow</code> are <code>arr</code> and <code>first</code>;<br />
the other methods have default definitions in terms of these, but are<br />
included in the <code>Arrow</code> class so that they can be overridden with more<br />
efficient implementations if desired.<br />
<br />
==Intuition==<br />
<br />
Let’s look at each of the arrow methods in turn. [http://www.haskell.org/arrows/ Ross Paterson’s web page on arrows] has nice diagrams which can help<br />
build intuition.<br />
<br />
* The <code>arr</code> function takes any function <code>b -> c</code> and turns it into a generalized arrow <code>b `arr` c</code>. The <code>arr</code> method justifies the claim that arrows generalize functions, since it says that we can treat any function as an arrow. It is intended that the arrow <code>arr g</code> is “pure” in the sense that it only computes <code>g</code> and has no “effects” (whatever that might mean for any particular arrow type).<br />
<br />
* The <code>first</code> method turns any arrow from <code>b</code> to <code>c</code> into an arrow from <code>(b,d)</code> to <code>(c,d)</code>. The idea is that <code>first g</code> uses <code>g</code> to process the first element of a tuple, and lets the second element pass through unchanged. For the function instance of <code>Arrow</code>, of course, <code>first g (x,y) = (g x, y)</code>.<br />
<br />
* The <code>second</code> function is similar to <code>first</code>, but with the elements of the tuples swapped. Indeed, it can be defined in terms of <code>first</code> using an auxiliary function <code>swap</code>, defined by <code>swap (x,y) = (y,x)</code>.<br />
<br />
* The <code>(***)</code> operator is “parallel composition” of arrows: it takes two arrows and makes them into one arrow on tuples, which has the behavior of the first arrow on the first element of a tuple, and the behavior of the second arrow on the second element. The mnemonic is that <code>g *** h</code> is the ''product'' (hence <code>*</code>) of <code>g</code> and <code>h</code>. For the function instance of <code>Arrow</code>, we define <code>(g *** h) (x,y) = (g x, h y)</code>. The default implementation of <code>(***)</code> is in terms of <code>first</code>, <code>second</code>, and sequential arrow composition <code>(>>>)</code>. The reader may also wish to think about how to implement <code>first</code> and <code>second</code> in terms of <code>(***)</code>.<br />
<br />
* The <code>(&&&)</code> operator is “fanout composition” of arrows: it takes two arrows <code>g</code> and <code>h</code> and makes them into a new arrow <code>g &&& h</code> which supplies its input as the input to both <code>g</code> and <code>h</code>, returning their results as a tuple. The mnemonic is that <code>g &&& h</code> performs both <code>g</code> ''and'' <code>h</code> (hence <code>&</code>) on its input. For functions, we define <code>(g &&& h) x = (g x, h x)</code>.<br />
<br />
==Instances==<br />
<br />
The <code>Arrow</code> library itself only provides two <code>Arrow</code> instances, both<br />
of which we have already seen: <code>(->)</code>, the normal function<br />
constructor, and <code>Kleisli m</code>, which makes functions of<br />
type <code>a -> m b</code> into <code>Arrow</code>s for any <code>Monad m</code>. These instances are:<br />
<br />
<haskell><br />
instance Arrow (->) where<br />
arr g = g<br />
first g (x,y) = (g x, y)<br />
<br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Arrow (Kleisli m) where<br />
arr f = Kleisli (return . f)<br />
first (Kleisli f) = Kleisli (\ ~(b,d) -> do c <- f b<br />
return (c,d) )<br />
</haskell><br />
<br />
==Laws==<br />
<br />
{{note|See [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 John Hughes: Generalising monads to arrows]; [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf Sam Lindley, Philip Wadler, Jeremy Yallop: The arrow calculus]; [http://www.soi.city.ac.uk/~ross/papers/fop.html Ross Paterson: Programming with Arrows].}}<br />
<br />
There are quite a few laws that instances of <code>Arrow</code> should<br />
satisfy {{noteref}}:<br />
<br />
<haskell><br />
arr id = id<br />
arr (h . g) = arr g >>> arr h<br />
first (arr g) = arr (g *** id)<br />
first (g >>> h) = first g >>> first h<br />
first g >>> arr (id *** h) = arr (id *** h) >>> first g<br />
first g >>> arr fst = arr fst >>> g<br />
first (first g) >>> arr assoc = arr assoc >>> first g<br />
<br />
assoc ((x,y),z) = (x,(y,z))<br />
</haskell><br />
<br />
Note that this version of the laws is slightly different than the laws given in the<br />
first two above references, since several of the laws have now been<br />
subsumed by the <code>Category</code> laws (in particular, the requirements that<br />
<code>id</code> is the identity arrow and that <code>(>>>)</code> is associative). The laws<br />
shown here follow those in Paterson’s Programming with Arrows, which uses the<br />
<code>Category</code> class.<br />
<br />
{{note|Unless category-theory-induced insomnolence is your cup of tea.}}<br />
<br />
The reader is advised not to lose too much sleep over the <code>Arrow</code><br />
laws {{noteref}}, since it is not essential to understand them in order to<br />
program with arrows. There are also laws that <code>ArrowChoice</code>,<br />
<code>ArrowApply</code>, and <code>ArrowLoop</code> instances should satisfy; the interested<br />
reader should consult [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows].<br />
<br />
==ArrowChoice==<br />
<br />
Computations built using the <code>Arrow</code> class, like those built using<br />
the <code>Applicative</code> class, are rather inflexible: the structure of the computation<br />
is fixed at the outset, and there is no ability to choose between<br />
alternate execution paths based on intermediate results.<br />
The <code>ArrowChoice</code> class provides exactly such an ability:<br />
<br />
<haskell><br />
class Arrow arr => ArrowChoice arr where<br />
left :: (b `arr` c) -> (Either b d `arr` Either c d)<br />
right :: (b `arr` c) -> (Either d b `arr` Either d c)<br />
(+++) :: (b `arr` c) -> (b' `arr` c') -> (Either b b' `arr` Either c c')<br />
(|||) :: (b `arr` d) -> (c `arr` d) -> (Either b c `arr` d)<br />
</haskell><br />
<br />
A comparison of <code>ArrowChoice</code> to <code>Arrow</code> will reveal a striking<br />
parallel between <code>left</code>, <code>right</code>, <code>(+++)</code>, <code>(|||)</code> and <code>first</code>,<br />
<code>second</code>, <code>(***)</code>, <code>(&&&)</code>, respectively. Indeed, they are dual:<br />
<code>first</code>, <code>second</code>, <code>(***)</code>, and <code>(&&&)</code> all operate on product types<br />
(tuples), and <code>left</code>, <code>right</code>, <code>(+++)</code>, and <code>(|||)</code> are the<br />
corresponding operations on sum types. In general, these operations<br />
create arrows whose inputs are tagged with <code>Left</code> or <code>Right</code>, and can<br />
choose how to act based on these tags.<br />
<br />
* If <code>g</code> is an arrow from <code>b</code> to <code>c</code>, then <code>left g</code> is an arrow from <code>Either b d</code> to <code>Either c d</code>. On inputs tagged with <code>Left</code>, the <code>left g</code> arrow has the behavior of <code>g</code>; on inputs tagged with <code>Right</code>, it behaves as the identity.<br />
<br />
* The <code>right</code> function, of course, is the mirror image of <code>left</code>. The arrow <code>right g</code> has the behavior of <code>g</code> on inputs tagged with <code>Right</code>.<br />
<br />
* The <code>(+++)</code> operator performs “multiplexing”: <code>g +++ h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and as <code>h</code> on inputs tagged with <code>Right</code>. The tags are preserved. The <code>(+++)</code> operator is the ''sum'' (hence <code>+</code>) of two arrows, just as <code>(***)</code> is the product.<br />
<br />
* The <code>(|||)</code> operator is “merge” or “fanin”: the arrow <code>g ||| h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and <code>h</code> on inputs tagged with <code>Right</code>, but the tags are discarded (hence, <code>g</code> and <code>h</code> must have the same output type). The mnemonic is that <code>g ||| h</code> performs either <code>g</code> ''or'' <code>h</code> on its input.<br />
<br />
The <code>ArrowChoice</code> class allows computations to choose among a finite number of execution paths, based on intermediate results. The possible<br />
execution paths must be known in advance, and explicitly assembled with <code>(+++)</code> or <code>(|||)</code>. However, sometimes more flexibility is<br />
needed: we would like to be able to ''compute'' an arrow from intermediate results, and use this computed arrow to continue the computation. This is the power given to us by <code>ArrowApply</code>.<br />
<br />
==ArrowApply==<br />
<br />
The <code>ArrowApply</code> type class is:<br />
<br />
<haskell><br />
class Arrow arr => ArrowApply arr where<br />
app :: (b `arr` c, b) `arr` c<br />
</haskell><br />
<br />
If we have computed an arrow as the output of some previous<br />
computation, then <code>app</code> allows us to apply that arrow to an input,<br />
producing its output as the output of <code>app</code>. As an exercise, the<br />
reader may wish to use <code>app</code> to implement an alternative “curried”<br />
version, <code>app2 :: b `arr` ((b `arr` c) `arr` c)</code>.<br />
<br />
This notion of being able to ''compute'' a new computation<br />
may sound familiar:<br />
this is exactly what the monadic bind operator <code>(>>=)</code> does. It<br />
should not particularly come as a surprise that <code>ArrowApply</code> and<br />
<code>Monad</code> are exactly equivalent in expressive power. In particular,<br />
<code>Kleisli m</code> can be made an instance of <code>ArrowApply</code>, and any instance<br />
of <code>ArrowApply</code> can be made a <code>Monad</code> (via the <code>newtype</code> wrapper<br />
<code>ArrowMonad</code>). As an exercise, the reader may wish to try<br />
implementing these instances:<br />
<br />
<haskell><br />
instance Monad m => ArrowApply (Kleisli m) where<br />
app = -- exercise<br />
<br />
newtype ArrowApply a => ArrowMonad a b = ArrowMonad (a () b)<br />
<br />
instance ArrowApply a => Monad (ArrowMonad a) where<br />
return = -- exercise<br />
(ArrowMonad a) >>= k = -- exercise<br />
</haskell><br />
<br />
==ArrowLoop==<br />
<br />
The <code>ArrowLoop</code> type class is:<br />
<br />
<haskell><br />
class Arrow a => ArrowLoop a where<br />
loop :: a (b, d) (c, d) -> a b c<br />
<br />
trace :: ((b,d) -> (c,d)) -> b -> c<br />
trace f b = let (c,d) = f (b,d) in c<br />
</haskell><br />
<br />
It describes arrows that can use recursion to compute results, and is<br />
used to desugar the <code>rec</code> construct in arrow notation (described<br />
below).<br />
<br />
Taken by itself, the type of the <code>loop</code> method does not seem to tell<br />
us much. Its intention, however, is a generalization of the <code>trace</code><br />
function which is also shown. The <code>d</code> component of the first arrow’s<br />
output is fed back in as its own input. In other words, the arrow<br />
<code>loop g</code> is obtained by recursively “fixing” the second component of<br />
the input to <code>g</code>.<br />
<br />
It can be a bit difficult to grok what the <code>trace</code> function is doing.<br />
How can <code>d</code> appear on the left and right sides of the <code>let</code>? Well,<br />
this is Haskell’s laziness at work. There is not space here for a<br />
full explanation; the interested reader is encouraged to study the<br />
standard <code>fix</code> function, and to read [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson’s arrow tutorial].<br />
<br />
==Arrow notation==<br />
<br />
Programming directly with the arrow combinators can be painful,<br />
especially when writing complex computations which need to retain<br />
simultaneous reference to a number of intermediate results. With<br />
nothing but the arrow combinators, such intermediate results must be<br />
kept in nested tuples, and it is up to the programmer to remember<br />
which intermediate results are in which components, and to swap,<br />
reassociate, and generally mangle tuples as necessary. This problem<br />
is solved by the special arrow notation supported by GHC, similar to<br />
<code>do</code> notation for monads, that allows names to be assigned to<br />
intermediate results while building up arrow computations. An example<br />
arrow implemented using arrow notation, taken from<br />
Paterson, is:<br />
<br />
<haskell><br />
class ArrowLoop arr => ArrowCircuit arr where<br />
delay :: b -> (b `arr` b)<br />
<br />
counter :: ArrowCircuit arr => Bool `arr` Int<br />
counter = proc reset -> do<br />
rec output <- idA -< if reset then 0 else next<br />
next <- delay 0 -< output + 1<br />
idA -< output<br />
</haskell><br />
<br />
This arrow is intended to<br />
represent a recursively defined counter circuit with a reset line.<br />
<br />
There is not space here for a full explanation of arrow notation; the<br />
interested reader should consult<br />
[http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper introducing the notation], or his later [http://www.soi.city.ac.uk/~ross/papers/fop.html tutorial which presents a simplified version].<br />
<br />
==Further reading==<br />
<br />
An excellent starting place for the student of arrows is the [http://www.haskell.org/arrows/ arrows web page], which contains an<br />
introduction and many references. Some key papers on arrows include<br />
Hughes’s original paper introducing arrows, [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 Generalising monads to arrows], and [http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper on arrow notation].<br />
<br />
Both Hughes and Paterson later wrote accessible tutorials intended for a broader<br />
audience: [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows] and [http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf Hughes: Programming with Arrows].<br />
<br />
Although Hughes’s goal in defining the <code>Arrow</code> class was to<br />
generalize <code>Monad</code>s, and it has been said that <code>Arrow</code> lies “between<br />
<code>Applicative</code> and <code>Monad</code>” in power, they are not directly<br />
comparable. The precise relationship remained in some confusion until<br />
[http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf analyzed by Lindley, Wadler, and Yallop], who<br />
also invented a new calculus of arrows, based on the lambda calculus,<br />
which considerably simplifies the presentation of the arrow laws<br />
(see [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf The arrow calculus]). There is also a precise technical sense in which [http://just-bottom.blogspot.de/2010/04/programming-with-effects-story-so-far.html <code>Arrow</code> can be seen as the intersection of <code>Applicative</code> and <code>Category</code>].<br />
<br />
Some examples of <code>Arrow</code>s include [http://www.haskell.org/yampa/ Yampa], the<br />
[http://www.fh-wedel.de/~si/HXmlToolbox/ Haskell XML Toolkit], and the functional GUI library [[Grapefruit]].<br />
<br />
Some extensions to arrows have been explored; for example, the<br />
<code>BiArrow</code>s of Alimarine et al. ([http://wiki.clean.cs.ru.nl/download/papers/2005/alia2005-biarrowsHaskellWorkshop.pdf "There and Back Again: Arrows for Invertible Programming"]), for two-way instead of one-way<br />
computation.<br />
<br />
The Haskell wiki has [[Research papers/Monads and Arrows|links to many additional research papers relating to <code>Arrow</code>s]].<br />
<br />
=Comonad=<br />
<br />
The final type class we will examine is <code>Comonad</code>. The <code>Comonad</code> class<br />
is the categorical dual of <code>Monad</code>; that is, <code>Comonad</code> is like <code>Monad</code><br />
but with all the function arrows flipped. It is not actually in the<br />
standard Haskell libraries, but it has seen some interesting uses<br />
recently, so we include it here for completeness.<br />
<br />
==Definition==<br />
<br />
The <code>Comonad</code> type class, defined in the <code>Control.Comonad</code> module of<br />
the [http://hackage.haskell.org/package/comonad comonad library], is:<br />
<br />
<haskell><br />
class Functor w => Comonad w where<br />
extract :: w a -> a<br />
<br />
duplicate :: w a -> w (w a)<br />
duplicate = extend id<br />
<br />
extend :: (w a -> b) -> w a -> w b<br />
extend f = fmap f . duplicate<br />
</haskell><br />
<br />
As you can see, <code>extract</code> is the dual of <code>return</code>, <code>duplicate</code> is the dual of <code>join</code>, and <code>extend</code> is the dual of <code>(=<<)</code>. The definition of <code>Comonad</code> is a bit redundant, giving the programmer the choice on whether extend or duplicate are implemented; the other operation then has a default implementation.<br />
<br />
A prototypical example of a <code>Comonad</code> instance is:<br />
<br />
<haskell><br />
-- Infinite lazy streams<br />
data Stream a = Cons a (Stream a)<br />
<br />
-- 'duplicate' is like the list function 'tails'<br />
-- 'extend' computes a new Stream from an old, where the element<br />
-- at position n is computed as a function of everything from<br />
-- position n onwards in the old Stream<br />
instance Comonad Stream where<br />
extract (Cons x _) = x<br />
duplicate s@(Cons x xs) = Cons s (duplicate xs)<br />
extend g s@(Cons x xs) = Cons (g s) (extend g xs)<br />
-- = fmap g (duplicate s)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Dan Piponi explains in a blog post what [http://blog.sigfpe.com/2006/12/evaluating-cellular-automata-is.html cellular automata have to do with comonads]. In another blog post, Conal Elliott has examined [http://conal.net/blog/posts/functional-interactive-behavior/ a comonadic formulation of functional reactive programming]. Sterling Clover’s blog post [http://fmapfixreturn.wordpress.com/2008/07/09/comonads-in-everyday-life/ Comonads in everyday life] explains the relationship between comonads and zippers, and how comonads can be used to design a menu system for a web site.<br />
<br />
Uustalu and Vene have a number of papers exploring ideas related to comonads and functional programming:<br />
* [http://dx.doi.org/10.1016/j.entcs.2008.05.029 Comonadic Notions of Computation]<br />
* [http://www.ioc.ee/~tarmo/papers/sfp01-book.pdf The dual of substitution is redecoration] (Also available as [http://www.cs.ut.ee/~varmo/papers/sfp01-book.ps.gz ps.gz].)<br />
* [http://dx.doi.org/10.1016/j.ic.2005.08.005 Recursive coalgebras from comonads]<br />
* [http://www.fing.edu.uy/~pardo/papers/njc01.ps.gz Recursion schemes from comonads]<br />
* [http://cs.ioc.ee/~tarmo/papers/essence.pdf The Essence of Dataflow Programming].<br />
<br />
Gabriel Gonzalez's [http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html Comonads are objects] points out similarities between comonads and object-oriented programming.<br />
<br />
The [http://hackage.haskell.org/package/comonad-transformers comonad-transformers] package contains comonad transformers.<br />
<br />
=Acknowledgements=<br />
<br />
A special thanks to all of those who taught me about standard Haskell<br />
type classes and helped me develop good intuition for them,<br />
particularly Jules Bean (quicksilver), Derek Elkins (ddarius), Conal<br />
Elliott (conal), Cale Gibbard (Cale), David House, Dan Piponi<br />
(sigfpe), and Kevin Reid (kpreid).<br />
<br />
I also thank the many people who provided a mountain of helpful<br />
feedback and suggestions on a first draft of the Typeclassopedia: David Amos,<br />
Kevin Ballard, Reid Barton, Doug Beardsley, Joachim Breitner, Andrew<br />
Cave, David Christiansen, Gregory Collins, Mark Jason Dominus, Conal<br />
Elliott, Yitz Gale, George Giorgidze, Steven Grady, Travis Hartwell,<br />
Steve Hicks, Philip Hölzenspies, Edward Kmett, Eric Kow, Serge Le<br />
Huitouze, Felipe Lessa, Stefan Ljungstrand, Eric Macaulay, Rob MacAulay, Simon Meier,<br />
Eric Mertens, Tim Newsham, Russell O’Connor, Conrad Parker, Walt<br />
Rorie-Baety, Colin Ross, Tom Schrijvers, Aditya Siram, C. Smith,<br />
Martijn van Steenbergen, Joe Thornber, Jared Updike, Rob Vollmert,<br />
Andrew Wagner, Louis Wasserman, and Ashley Yakeley, as well as a few<br />
only known to me by their IRC nicks: b_jonas, maltem, tehgeekmeister,<br />
and ziman. I have undoubtedly omitted a few inadvertently, which in<br />
no way diminishes my gratitude.<br />
<br />
Finally, I would like to thank Wouter Swierstra for his fantastic work<br />
editing the Monad.Reader, and my wife Joyia for her patience during<br />
the process of writing the Typeclassopedia.<br />
<br />
=About the author=<br />
<br />
Brent Yorgey ([http://byorgey.wordpress.com/ blog], [http://www.cis.upenn.edu/~byorgey/ homepage]) is (as of November 2011) a fourth-year Ph.D. student in the [http://www.cis.upenn.edu/~plclub/ programming languages group] at the [http://www.upenn.edu University of Pennsylvania]. He enjoys teaching, creating EDSLs, playing Bach fugues, musing upon category theory, and cooking tasty lambda-treats for the denizens of #haskell.<br />
<br />
=Colophon=<br />
<br />
The Typeclassopedia was written by Brent Yorgey and initially published in March 2009. Painstakingly converted to wiki syntax by [[User:Geheimdienst]] in November 2011, after asking Brent’s permission.<br />
<br />
If something like this TeX to wiki syntax conversion ever needs to be done again, here are some vim commands that helped:<br />
<br />
* <nowiki>%s/\\section{\([^}]*\)}/=\1=/gc</nowiki><br />
* <nowiki>%s/\\subsection{\([^}]*\)}/==\1==/gc</nowiki><br />
* <nowiki>%s/^ *\\item /\r* /gc</nowiki><br />
* <nowiki>%s/---/—/gc</nowiki><br />
* <nowiki>%s/\$\([^$]*\)\$/<math>\1\\ <\/math>/gc</nowiki> ''Appending “\ ” forces images to be rendered. Otherwise, Mediawiki would go back and forth between one font for short <nowiki><math></nowiki> tags, and another more Tex-like font for longer tags (containing more than a few characters)""<br />
* <nowiki>%s/|\([^|]*\)|/<code>\1<\/code>/gc</nowiki><br />
* <nowiki>%s/\\dots/.../gc</nowiki><br />
* <nowiki>%s/^\\label{.*$//gc</nowiki><br />
* <nowiki>%s/\\emph{\([^}]*\)}/''\1''/gc</nowiki><br />
* <nowiki>%s/\\term{\([^}]*\)}/''\1''/gc</nowiki><br />
<br />
The biggest issue was taking the academic-paper-style citations and turning them into hyperlinks with an appropriate title and an appropriate target. In most cases there was an obvious thing to do (e.g. online PDFs of the cited papers or CiteSeer entries). Sometimes, however, it’s less clear and you might want to check the<br />
[[Media:Typeclassopedia.pdf|original Typeclassopedia PDF]]<br />
with the<br />
[http://code.haskell.org/~byorgey/TMR/Issue13/typeclassopedia.bib original bibliography file].<br />
<br />
To get all the citations into the main text, I first tried processing the source with TeX or Lyx. This didn’t work due to missing unfindable packages, syntax errors, and my general ineptitude with Tex.<br />
<br />
I then went for the next best solution, which seemed to be extracting all instances of “\cite{something}” from the source and ''in that order'' pulling the referenced entries from the .bib file. This way you can go through the source file and sorted-references file in parallel, copying over what you need, without searching back and forth in the .bib file. I used:<br />
<br />
* <nowiki>egrep -o "\cite\{[^\}]*\}" ~/typeclassopedia.lhs | cut -c 6- | tr "," "\n" | tr -d "}" > /tmp/citations</nowiki><br />
* <nowiki>for i in $(cat /tmp/citations); do grep -A99 "$i" ~/typeclassopedia.bib|egrep -B99 '^\}$' -m1 ; done > ~/typeclasso-refs-sorted</nowiki><br />
<br />
[[Category:Applicative Functor]]<br />
[[Category:Arrow]]<br />
[[Category:Functor]]<br />
[[Category:Monad]]<br />
[[Category:Standard classes]]<br />
[[Category:Standard libraries]]<br />
[[Category:Standard packages]]<br />
[[Category:Standard types]]</div>Imzhttps://wiki.haskell.org/index.php?title=Typeclassopedia&diff=59128Typeclassopedia2014-11-27T17:49:11Z<p>Imz: /* Further reading */ fixed a rotten link</p>
<hr />
<div>''By [[User:Byorgey|Brent Yorgey]], byorgey@cis.upenn.edu''<br />
<br />
''Originally published 12 March 2009 in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13] of [http://themonadreader.wordpress.com/ the Monad.Reader]. Ported to the Haskell wiki in November 2011 by [[User:Geheimdienst|Geheimdienst]].''<br />
<br />
''This is now the official version of the Typeclassopedia and supersedes the version published in the Monad.Reader. Please help update and extend it by editing it yourself or by leaving comments, suggestions, and questions on the [[Talk:Typeclassopedia|talk page]].''<br />
<br />
=Abstract=<br />
<br />
The standard Haskell libraries feature a number of type classes with algebraic or category-theoretic underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs.<br />
<br />
The goal of this document is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading.<br />
<br />
=Introduction=<br />
<br />
Have you ever had any of the following thoughts?<br />
* What the heck is a monoid, and how is it different from a mon<u>a</u>d?<br />
<br />
* I finally figured out how to use [[Parsec]] with do-notation, and someone told me I should use something called <code>Applicative</code> instead. Um, what?<br />
<br />
* Someone in the [[IRC channel|#haskell]] IRC channel used <code>(***)</code>, and when I asked Lambdabot to tell me its type, it printed out scary gobbledygook that didn’t even fit on one line! Then someone used <code>fmap fmap fmap</code> and my brain exploded.<br />
<br />
* When I asked how to do something I thought was really complicated, people started typing things like <code>zip.ap fmap.(id &&& wtf)</code> and the scary thing is that they worked! Anyway, I think those people must actually be robots because there’s no way anyone could come up with that in two seconds off the top of their head.<br />
<br />
If you have, look no further! You, too, can write and understand concise, elegant, idiomatic Haskell code with the best of them.<br />
<br />
There are two keys to an expert Haskell hacker’s wisdom:<br />
# Understand the types.<br />
# Gain a deep intuition for each type class and its relationship to other type classes, backed up by familiarity with many examples.<br />
<br />
It’s impossible to overstate the importance of the first; the patient student of type signatures will uncover many profound secrets. Conversely, anyone ignorant of the types in their code is doomed to eternal uncertainty. “Hmm, it doesn’t compile ... maybe I’ll stick in an<br />
<code>fmap</code> here ... nope, let’s see ... maybe I need another <code>(.)</code> somewhere? ... um ...”<br />
<br />
The second key—gaining deep intuition, backed by examples—is also important, but much more difficult to attain. A primary goal of this document is to set you on the road to gaining such intuition. However—<br />
<br />
:''There is no royal road to Haskell. {{h:title|Well, he probably would have said it if he knew Haskell.|—Euclid}}''<br />
<br />
This document can only be a starting point, since good intuition comes from hard work, [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ not from learning the right metaphor]. Anyone who reads and understands all of it will still have an arduous journey ahead—but sometimes a good starting point makes a big difference.<br />
<br />
It should be noted that this is not a Haskell tutorial; it is assumed that the reader is already familiar with the basics of Haskell, including the standard <code>[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html Prelude]</code>, the type system, data types, and type classes.<br />
<br />
The type classes we will be discussing and their interrelationships:<br />
<br />
[[Image:Typeclassopedia-diagram.png]]<br />
<br />
{{note|<code>Semigroup</code> can be found in the [http://hackage.haskell.org/package/semigroups <code>semigroups</code> package], <code>Apply</code> in the [http://hackage.haskell.org/package/semigroupoids <code>semigroupoids</code> package], and <code>Comonad</code> in the [http://hackage.haskell.org/package/comonad <code>comonad</code> package].}}<br />
<br />
* <span style="border-bottom: 2px solid black">Solid arrows</span> point from the general to the specific; that is, if there is an arrow from <code>Foo</code> to <code>Bar</code> it means that every <code>Bar</code> is (or should be, or can be made into) a <code>Foo</code>.<br />
* <span style="border-bottom: 2px dotted black">Dotted arrows</span> indicate some other sort of relationship.<br />
* <code>Monad</code> and <code>ArrowApply</code> are equivalent.<br />
* <code>Semigroup</code>, <code>Apply</code> and <code>Comonad</code> are greyed out since they are not actually (yet?) in the standard Haskell libraries {{noteref}}.<br />
<br />
One more note before we begin. The original spelling of “type class” is with two words, as evidenced by, for example, the [http://www.haskell.org/onlinereport/haskell2010/ Haskell 2010 Language Report], early papers on type classes like [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.5639 Type classes in Haskell] and [http://research.microsoft.com/en-us/um/people/simonpj/papers/type-class-design-space/ Type classes: exploring the design space], and [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.168.4008 Hudak et al.’s history of Haskell]. However, as often happens with two-word phrases that see a lot of use, it has started to show up as one word (“typeclass”) or, rarely, hyphenated (“type-class”). When wearing my prescriptivist hat, I prefer “type class”, but realize (after changing into my descriptivist hat) that there's probably not much I can do about it.<br />
<br />
We now begin with the simplest type class of all: <code>Functor</code>.<br />
<br />
=Functor=<br />
<br />
The <code>Functor</code> class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Functor haddock]) is the most basic and ubiquitous type class in the Haskell libraries. A simple intuition is that a <code>Functor</code> represents a “container” of some sort, along with the ability to apply a function uniformly to every element in the container. For example, a list is a container of elements, and we can apply a function to every element of a list, using <code>map</code>. As another example, a binary tree is also a container of elements, and it’s not hard to come up with a way to recursively apply a function to every element in a tree.<br />
<br />
Another intuition is that a <code>Functor</code> represents some sort of “computational context”. This intuition is generally more useful, but is more difficult to explain, precisely because it is so general. Some examples later should help to clarify the <code>Functor</code>-as-context point of view.<br />
<br />
In the end, however, a <code>Functor</code> is simply what it is defined to be; doubtless there are many examples of <code>Functor</code> instances that don’t exactly fit either of the above intuitions. The wise student will focus their attention on definitions and examples, without leaning too heavily on any particular metaphor. Intuition will come, in time, on its own.<br />
<br />
==Definition==<br />
<br />
Here is the type class declaration for <code>Functor</code>:<br />
<br />
<haskell><br />
class Functor f where<br />
fmap :: (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
<code>Functor</code> is exported by the <code>Prelude</code>, so no special imports are needed to use it.<br />
<br />
First, the <code>f a</code> and <code>f b</code> in the type signature for <code>fmap</code> tell us that <code>f</code> isn’t just a type; it is a ''type constructor'' which takes another type as a parameter. (A more precise way to say this is that the ''kind'' of <code>f</code> must be <code>* -> *</code>.) For example, <code>Maybe</code> is such a type constructor: <code>Maybe</code> is not a type in and of itself, but requires another type as a parameter, like <code>Maybe Integer</code>. So it would not make sense to say <code>instance Functor Integer</code>, but it could make sense to say <code>instance Functor Maybe</code>.<br />
<br />
Now look at the type of <code>fmap</code>: it takes any function from <code>a</code> to <code>b</code>, and a value of type <code>f a</code>, and outputs a value of type <code>f b</code>. From the container point of view, the intention is that <code>fmap</code> applies a function to each element of a container, without altering the structure of the container. From the context point of view, the intention is that <code>fmap</code> applies a function to a value without altering its context. Let’s look at a few specific examples.<br />
<br />
==Instances==<br />
<br />
{{note|Recall that <code>[]</code> has two meanings in Haskell: it can either stand for the empty list, or, as here, it can represent the list type constructor (pronounced “list-of”). In other words, the type <code>[a]</code> (list-of-<code>a</code>) can also be written <code>[] a</code>.}}<br />
<br />
{{note|You might ask why we need a separate <code>map</code> function. Why not just do away with the current list-only <code>map</code> function, and rename <code>fmap</code> to <code>map</code> instead? Well, that’s a good question. The usual argument is that someone just learning Haskell, when using <code>map</code> incorrectly, would much rather see an error about lists than about <code>Functor</code>s.}}<br />
<br />
As noted before, the list constructor <code>[]</code> is a functor {{noteref}}; we can use the standard list function <code>map</code> to apply a function to each element of a list {{noteref}}. The <code>Maybe</code> type constructor is also a functor, representing a container which might hold a single element. The function <code>fmap g</code> has no effect on <code>Nothing</code> (there are no elements to which <code>g</code> can be applied), and simply applies <code>g</code> to the single element inside a <code>Just</code>. Alternatively, under the context interpretation, the list functor represents a context of nondeterministic choice; that is, a list can be thought of as representing a single value which is nondeterministically chosen from among several possibilities (the elements of the list). Likewise, the <code>Maybe</code> functor represents a context with possible failure. These instances are:<br />
<br />
<haskell><br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : fmap g xs<br />
-- or we could just say fmap = map<br />
<br />
instance Functor Maybe where<br />
fmap _ Nothing = Nothing<br />
fmap g (Just a) = Just (g a)<br />
</haskell><br />
<br />
As an aside, in idiomatic Haskell code you will often see the letter <code>f</code> used to stand for both an arbitrary <code>Functor</code> and an arbitrary function. In this document, <code>f</code> represents only <code>Functor</code>s, and <code>g</code> or <code>h</code> always represent functions, but you should be aware of the potential confusion. In practice, what <code>f</code> stands for should always be clear from the context, by noting whether it is part of a type or part of the code.<br />
<br />
There are other <code>Functor</code> instances in the standard libraries; below are a few. Note that some of these instances are not exported by the <code>Prelude</code>; to access them, you can import <code>Control.Monad.Instances</code>.<br />
<br />
* <code>Either e</code> is an instance of <code>Functor</code>; <code>Either e a</code> represents a container which can contain either a value of type <code>a</code>, or a value of type <code>e</code> (often representing some sort of error condition). It is similar to <code>Maybe</code> in that it represents possible failure, but it can carry some extra information about the failure as well.<br />
<br />
* <code>((,) e)</code> represents a container which holds an “annotation” of type <code>e</code> along with the actual value it holds. It might be clearer to write it as <code>(e,)</code>, by analogy with an operator section like <code>(1+)</code>, but that syntax is not allowed in types (although it is allowed in expressions with the <code>TupleSections</code> extension enabled). However, you can certainly ''think'' of it as <code>(e,)</code>.<br />
<br />
* <code>((->) e)</code> (which can be thought of as <code>(e ->)</code>; see above), the type of functions which take a value of type <code>e</code> as a parameter, is a <code>Functor</code>. As a container, <code>(e -> a)</code> represents a (possibly infinite) set of values of <code>a</code>, indexed by values of <code>e</code>. Alternatively, and more usefully, <code>((->) e)</code> can be thought of as a context in which a value of type <code>e</code> is available to be consulted in a read-only fashion. This is also why <code>((->) e)</code> is sometimes referred to as the ''reader monad''; more on this later.<br />
<br />
* <code>IO</code> is a <code>Functor</code>; a value of type <code>IO a</code> represents a computation producing a value of type <code>a</code> which may have I/O effects. If <code>m</code> computes the value <code>x</code> while producing some I/O effects, then <code>fmap g m</code> will compute the value <code>g x</code> while producing the same I/O effects.<br />
<br />
* Many standard types from the [http://hackage.haskell.org/package/containers/ containers library] (such as <code>Tree</code>, <code>Map</code>, and <code>Sequence</code>) are instances of <code>Functor</code>. A notable exception is <code>Set</code>, which cannot be made a <code>Functor</code> in Haskell (although it is certainly a mathematical functor) since it requires an <code>Ord</code> constraint on its elements; <code>fmap</code> must be applicable to ''any'' types <code>a</code> and <code>b</code>. However, <code>Set</code> (and other similarly restricted data types) can be made an instance of a suitable generalization of <code>Functor</code>, either by [http://article.gmane.org/gmane.comp.lang.haskell.cafe/78052/ making <code>a</code> and <code>b</code> arguments to the <code>Functor</code> type class themselves], or by adding an [http://blog.omega-prime.co.uk/?p=127 associated constraint].<br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement <code>Functor</code> instances for <code>Either e</code> and <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> instances for <code>((,) e)</code> and for <code>Pair</code>, defined as <br />
<br />
<haskell>data Pair a = Pair a a</haskell><br />
<br />
Explain their similarities and differences.<br />
</li><br />
<li>Implement a <code>Functor</code> instance for the type <code>ITree</code>, defined as<br />
<br />
<haskell><br />
data ITree a = Leaf (Int -> a) <br />
| Node [ITree a]<br />
</haskell><br />
</li><br />
<li>Give an example of a type of kind <code>* -> *</code> which cannot be made an instance of <code>Functor</code> (without using <code>undefined</code>).<br />
</li><br />
<li>Is this statement true or false? <br />
<br />
:''The composition of two <code>Functor</code>s is also a <code>Functor</code>.''<br />
<br />
If false, give a counterexample; if true, prove it by exhibiting some appropriate Haskell code.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Laws==<br />
<br />
As far as the Haskell language itself is concerned, the only requirement to be a <code>Functor</code> is an implementation of <code>fmap</code> with the proper type. Any sensible <code>Functor</code> instance, however, will also satisfy the ''functor laws'', which are part of the definition of a mathematical functor. There are two:<br />
<br />
<haskell><br />
fmap id = id<br />
fmap (g . h) = (fmap g) . (fmap h)<br />
</haskell><br />
<br />
{{note|Technically, these laws make <code>f</code> and <code>fmap</code> together an endofunctor on ''Hask'', the category of Haskell types (ignoring [[Bottom|&perp;]], which is a party pooper). See [http://en.wikibooks.org/wiki/Haskell/Category_theory Wikibook: Category theory].}}<br />
<br />
Together, these laws ensure that <code>fmap g</code> does not change the ''structure'' of a container, only the elements. Equivalently, and more simply, they ensure that <code>fmap g</code> changes a value without altering its context {{noteref}}.<br />
<br />
The first law says that mapping the identity function over every item in a container has no effect. The second says that mapping a composition of two functions over every item in a container is the same as first mapping one function, and then mapping the other.<br />
<br />
As an example, the following code is a “valid” instance of <code>Functor</code> (it typechecks), but it violates the functor laws. Do you see why?<br />
<br />
<haskell><br />
-- Evil Functor instance<br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : g x : fmap g xs<br />
</haskell><br />
<br />
Any Haskeller worth their salt would reject this code as a gruesome abomination.<br />
<br />
Unlike some other type classes we will encounter, a given type has at most one valid instance of <code>Functor</code>. This [http://article.gmane.org/gmane.comp.lang.haskell.libraries/15384 can be proven] via the [http://homepages.inf.ed.ac.uk/wadler/topics/parametricity.html#free ''free theorem''] for the type of <code>fmap</code>. In fact, [http://byorgey.wordpress.com/2010/03/03/deriving-pleasure-from-ghc-6-12-1/ GHC can automatically derive] <code>Functor</code> instances for many data types.<br />
<br />
{{note|Actually, if <code>seq</code>/<code>undefined</code> are considered, it [http://stackoverflow.com/a/8323243/305559 is possible] to have an implementation which satisfies the first law but not the second. The rest of the comments in this section should considered in a context where <code>seq</code> and <code>undefined</code> are excluded.}}<br />
<br />
A [https://github.com/quchen/articles/blob/master/second_functor_law.md similar argument also shows] that any <code>Functor</code> instance satisfying the first law (<code>fmap id = id</code>) will automatically satisfy the second law as well. Practically, this means that only the first law needs to be checked (usually by a very straightforward induction) to ensure that a <code>Functor</code> instance is valid.{{noteref}}<br />
<br />
{{Exercises|<br />
# Although it is not possible for a <code>Functor</code> instance to satisfy the first <code>Functor</code> law but not the second (excluding <code>undefined</code>), the reverse is possible. Give an example of a (bogus) <code>Functor</code> instance which satisfies the second law but not the first.<br />
# Which laws are violated by the evil <code>Functor</code> instance for list shown above: both laws, or the first law alone? Give specific counterexamples.<br />
}}<br />
<br />
==Intuition==<br />
<br />
There are two fundamental ways to think about <code>fmap</code>. The first has already been mentioned: it takes two parameters, a function and a container, and applies the function “inside” the container, producing a new container. Alternately, we can think of <code>fmap</code> as applying a function to a value in a context (without altering the context).<br />
<br />
Just like all other Haskell functions of “more than one parameter”, however, <code>fmap</code> is actually ''curried'': it does not really take two parameters, but takes a single parameter and returns a function. For emphasis, we can write <code>fmap</code>’s type with extra parentheses: <code>fmap :: (a -> b) -> (f a -> f b)</code>. Written in this form, it is apparent that <code>fmap</code> transforms a “normal” function (<code>g :: a -> b</code>) into one which operates over containers/contexts (<code>fmap g :: f a -> f b</code>). This transformation is often referred to as a ''lift''; <code>fmap</code> “lifts” a function from the “normal world” into the “<code>f</code> world”.<br />
<br />
==Further reading==<br />
<br />
A good starting point for reading about the category theory behind the concept of a functor is the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page on category theory].<br />
<br />
=Applicative=<br />
<br />
A somewhat newer addition to the pantheon of standard Haskell type classes, ''applicative functors'' represent an abstraction lying in between <code>Functor</code> and <code>Monad</code> in expressivity, first described by McBride and Paterson. The title of their classic paper, [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative Programming with Effects], gives a hint at the intended intuition behind the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html <code>Applicative</code>] type class. It encapsulates certain sorts of “effectful” computations in a functionally pure way, and encourages an “applicative” programming style. Exactly what these things mean will be seen later.<br />
<br />
==Definition==<br />
<br />
Recall that <code>Functor</code> allows us to lift a “normal” function to a function on computational contexts. But <code>fmap</code> doesn’t allow us to apply a function which is itself in a context to a value in a context. <code>Applicative</code> gives us just such a tool, <code>(<*>)</code>. It also provides a method, <code>pure</code>, for embedding values in a default, “effect free” context. Here is the type class declaration for <code>Applicative</code>, as defined in <code>Control.Applicative</code>:<br />
<br />
<haskell><br />
class Functor f => Applicative f where<br />
pure :: a -> f a<br />
(<*>) :: f (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
Note that every <code>Applicative</code> must also be a <code>Functor</code>. In fact, as we will see, <code>fmap</code> can be implemented using the <code>Applicative</code> methods, so every <code>Applicative</code> is a functor whether we like it or not; the <code>Functor</code> constraint forces us to be honest.<br />
<br />
{{note|Recall that <code>($)</code> is just function application: <code>f $ x {{=}} f x</code>.}}<br />
<br />
As always, it’s crucial to understand the type signatures. First, consider <code>(<*>)</code>: the best way of thinking about it comes from noting that the type of <code>(<*>)</code> is similar to the type of <code>($)</code> {{noteref}}, but with everything enclosed in an <code>f</code>. In other words, <code>(<*>)</code> is just function application within a computational context. The type of <code>(<*>)</code> is also very similar to the type of <code>fmap</code>; the only difference is that the first parameter is <code>f (a -> b)</code>, a function in a context, instead of a “normal” function <code>(a -> b)</code>.<br />
<br />
<code>pure</code> takes a value of any type <code>a</code>, and returns a context/container of type <code>f a</code>. The intention is that <code>pure</code> creates some sort of “default” container or “effect free” context. In fact, the behavior of <code>pure</code> is quite constrained by the laws it should satisfy in conjunction with <code>(<*>)</code>. Usually, for a given implementation of <code>(<*>)</code> there is only one possible implementation of <code>pure</code>.<br />
<br />
(Note that previous versions of the Typeclassopedia explained <code>pure</code> in terms of a type class <code>Pointed</code>, which can still be found in the [http://hackage.haskell.org/package/pointed <code>pointed</code> package]. However, the current consensus is that <code>Pointed</code> is not very useful after all. For a more detailed explanation, see [[Why not Pointed?]])<br />
<br />
==Laws==<br />
<br />
{{note|See<br />
[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html haddock for Applicative] and [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative programming with effects]}}<br />
<br />
Traditionally, there are four laws that <code>Applicative</code> instances should satisfy {{noteref}}. In some sense, they are all concerned with making sure that <code>pure</code> deserves its name:<br />
<br />
* The identity law:<br /><haskell>pure id <*> v = v</haskell><br />
* Homomorphism:<br /><haskell>pure f <*> pure x = pure (f x)</haskell>Intuitively, applying a non-effectful function to a non-effectful argument in an effectful context is the same as just applying the function to the argument and then injecting the result into the context with <code>pure</code>.<br />
* Interchange:<br /><haskell>u <*> pure y = pure ($ y) <*> u</haskell>Intuitively, this says that when evaluating the application of an effectful function to a pure argument, the order in which we evaluate the function and its argument doesn't matter.<br />
* Composition:<br /><haskell>u <*> (v <*> w) = pure (.) <*> u <*> v <*> w </haskell>This one is the trickiest law to gain intuition for. In some sense it is expressing a sort of associativity property of <code>(<*>)</code>. The reader may wish to simply convince themselves that this law is type-correct.<br />
<br />
Considered as left-to-right rewrite rules, the homomorphism, interchange, and composition laws actually constitute an algorithm for transforming any expression using <code>pure</code> and <code>(<*>)</code> into a canonical form with only a single use of <code>pure</code> at the very beginning and only left-nested occurrences of <code>(<*>)</code>. Composition allows reassociating <code>(<*>)</code>; interchange allows moving occurrences of <code>pure</code> leftwards; and homomorphism allows collapsing multiple adjacent occurrences of <code>pure</code> into one.<br />
<br />
There is also a law specifying how <code>Applicative</code> should relate to <code>Functor</code>:<br />
<br />
<haskell><br />
fmap g x = pure g <*> x<br />
</haskell><br />
<br />
It says that mapping a pure function <code>g</code> over a context <code>x</code> is the same as first injecting <code>g</code> into a context with <code>pure</code>, and then applying it to <code>x</code> with <code>(<*>)</code>. In other words, we can decompose <code>fmap</code> into two more atomic operations: injection into a context, and application within a context. The <code>Control.Applicative</code> module also defines <code>(<$>)</code> as a synonym for <code>fmap</code>, so the above law can also be expressed as:<br />
<br />
<code>g <$> x = pure g <*> x</code>.<br />
<br />
{{Exercises|<br />
# (Tricky) One might imagine a variant of the interchange law that says something about applying a pure function to an effectful argument. Using the above laws, prove that<haskell>pure f <*> x = pure (flip ($)) <*> x <*> pure f</haskell><br />
}}<br />
<br />
==Instances==<br />
<br />
Most of the standard types which are instances of <code>Functor</code> are also instances of <code>Applicative</code>.<br />
<br />
<code>Maybe</code> can easily be made an instance of <code>Applicative</code>; writing such an instance is left as an exercise for the reader.<br />
<br />
The list type constructor <code>[]</code> can actually be made an instance of <code>Applicative</code> in two ways; essentially, it comes down to whether we want to think of lists as ordered collections of elements, or as contexts representing multiple results of a nondeterministic computation (see Wadler’s [http://www.springerlink.com/content/y7450255v2670167/ How to replace failure by a list of successes]).<br />
<br />
Let’s first consider the collection point of view. Since there can only be one instance of a given type class for any particular type, one or both of the list instances of <code>Applicative</code> need to be defined for a <code>newtype</code> wrapper; as it happens, the nondeterministic computation instance is the default, and the collection instance is defined in terms of a <code>newtype</code> called <code>ZipList</code>. This instance is:<br />
<br />
<haskell><br />
newtype ZipList a = ZipList { getZipList :: [a] }<br />
<br />
instance Applicative ZipList where<br />
pure = undefined -- exercise<br />
(ZipList gs) <*> (ZipList xs) = ZipList (zipWith ($) gs xs)<br />
</haskell><br />
<br />
To apply a list of functions to a list of inputs with <code>(<*>)</code>, we just match up the functions and inputs elementwise, and produce a list of the resulting outputs. In other words, we “zip” the lists together with function application, <code>($)</code>; hence the name <code>ZipList</code>. <br />
<br />
The other <code>Applicative</code> instance for lists, based on the nondeterministic computation point of view, is:<br />
<br />
<haskell><br />
instance Applicative [] where<br />
pure x = [x]<br />
gs <*> xs = [ g x | g <- gs, x <- xs ]<br />
</haskell><br />
<br />
Instead of applying functions to inputs pairwise, we apply each function to all the inputs in turn, and collect all the results in a list.<br />
<br />
Now we can write nondeterministic computations in a natural style. To add the numbers <code>3</code> and <code>4</code> deterministically, we can of course write <code>(+) 3 4</code>. But suppose instead of <code>3</code> we have a nondeterministic computation that might result in <code>2</code>, <code>3</code>, or <code>4</code>; then we can write<br />
<br />
<haskell><br />
pure (+) <*> [2,3,4] <*> pure 4<br />
</haskell><br />
<br />
or, more idiomatically,<br />
<br />
<haskell><br />
(+) <$> [2,3,4] <*> pure 4.<br />
</haskell><br />
<br />
There are several other <code>Applicative</code> instances as well:<br />
<br />
* <code>IO</code> is an instance of <code>Applicative</code>, and behaves exactly as you would think: to execute <code>m1 <*> m2</code>, first <code>m1</code> is executed, resulting in a function <code>f</code>, then <code>m2</code> is executed, resulting in a value <code>x</code>, and finally the value <code>f x</code> is returned as the result of executing <code>m1 <*> m2</code>.<br />
<br />
* <code>((,) a)</code> is an <code>Applicative</code>, as long as <code>a</code> is an instance of <code>Monoid</code> ([[#Monoid|section Monoid]]). The <code>a</code> values are accumulated in parallel with the computation.<br />
<br />
* The <code>Applicative</code> module defines the <code>Const</code> type constructor; a value of type <code>Const a b</code> simply contains an <code>a</code>. This is an instance of <code>Applicative</code> for any <code>Monoid a</code>; this instance becomes especially useful in conjunction with things like <code>Foldable</code> ([[#Foldable|section Foldable]]).<br />
<br />
* The <code>WrappedMonad</code> and <code>WrappedArrow</code> newtypes make any instances of <code>Monad</code> ([[#Monad|section Monad]]) or <code>Arrow</code> ([[#Arrow|section Arrow]]) respectively into instances of <code>Applicative</code>; as we will see when we study those type classes, both are strictly more expressive than <code>Applicative</code>, in the sense that the <code>Applicative</code> methods can be implemented in terms of their methods.<br />
<br />
{{Exercises|<br />
# Implement an instance of <code>Applicative</code> for <code>Maybe</code>.<br />
# Determine the correct definition of <code>pure</code> for the <code>ZipList</code> instance of <code>Applicative</code>—there is only one implementation that satisfies the law relating <code>pure</code> and <code>(<*>)</code>.<br />
}}<br />
<br />
==Intuition==<br />
<br />
McBride and Paterson’s paper introduces the notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> to denote function application in a computational context. If each <math>x_i\ </math> has type <math>f \; t_i\ </math> for some applicative functor <math>f\ </math>, and <math>g\ </math> has type <math>t_1 \to t_2 \to \dots \to t_n \to t\ </math>, then the entire expression <math>[[g \; x_1 \; \cdots \; x_n]]\ </math> has type <math>f \; t\ </math>. You can think of this as applying a function to multiple “effectful” arguments. In this sense, the double bracket notation is a generalization of <code>fmap</code>, which allows us to apply a function to a single argument in a context.<br />
<br />
Why do we need <code>Applicative</code> to implement this generalization of <code>fmap</code>? Suppose we use <code>fmap</code> to apply <code>g</code> to the first parameter <code>x1</code>. Then we get something of type <code>f (t2 -> ... t)</code>, but now we are stuck: we can’t apply this function-in-a-context to the next argument with <code>fmap</code>. However, this is precisely what <code>(<*>)</code> allows us to do.<br />
<br />
This suggests the proper translation of the idealized notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> into Haskell, namely<br />
<haskell><br />
g <$> x1 <*> x2 <*> ... <*> xn,<br />
</haskell><br />
<br />
recalling that <code>Control.Applicative</code> defines <code>(<$>)</code> as convenient infix shorthand for <code>fmap</code>. This is what is meant by an “applicative style”—effectful computations can still be described in terms of function application; the only difference is that we have to use the special operator <code>(<*>)</code> for application instead of simple juxtaposition.<br />
<br />
Note that <code>pure</code> allows embedding “non-effectful” arguments in the middle of an idiomatic application, like<br />
<haskell><br />
g <$> x1 <*> pure x2 <*> x3<br />
</haskell><br />
which has type <code>f d</code>, given<br />
<haskell><br />
g :: a -> b -> c -> d<br />
x1 :: f a<br />
x2 :: b<br />
x3 :: f c<br />
</haskell><br />
<br />
The double brackets are commonly known as “idiom brackets”, because they allow writing “idiomatic” function application, that is, function application that looks normal but has some special, non-standard meaning (determined by the particular instance of <code>Applicative</code> being used). Idiom brackets are not supported by GHC, but they are supported by the [http://personal.cis.strath.ac.uk/~conor/pub/she/ Strathclyde Haskell Enhancement], a preprocessor which (among many other things) translates idiom brackets into standard uses of <code>(<$>)</code> and <code>(<*>)</code>. This can result in much more readable code when making heavy use of <code>Applicative</code>.<br />
<br />
==Alternative formulation==<br />
<br />
An alternative, equivalent formulation of <code>Applicative</code> is given by<br />
<br />
<haskell><br />
class Functor f => Monoidal f where<br />
unit :: f ()<br />
(**) :: f a -> f b -> f (a,b)<br />
</haskell><br />
<br />
{{note|In category-theory speak, we say <code>f</code> is a ''lax'' monoidal functor because there aren't necessarily functions in the other direction, like <code>f (a, b) -> (f a, f b)</code>.}}<br />
Intuitively, this states that a <i>monoidal</i> functor{{noteref}} is one which has some sort of "default shape" and which supports some sort of "combining" operation. <code>pure</code> and <code>(<*>)</code> are equivalent in power to <code>unit</code> and <code>(**)</code> (see the Exercises below). More technically, the idea is that <code>f</code> preserves the "monoidal structure" given by the pairing constructor <code>(,)</code> and unit type <code>()</code>. This can be seen even more clearly if we rewrite the types of <code>unit</code> and <code>(**)</code> as<br />
<haskell><br />
unit' :: () -> f ()<br />
(**') :: (f a, f b) -> f (a, b)<br />
</haskell><br />
<br />
Furthermore, to deserve the name "monoidal" (see the [[#Monoid|section on Monoids]]), instances of <code>Monoidal</code> ought to satisfy the following laws, which seem much more straightforward than the traditional <code>Applicative</code> laws:<br />
<br />
{{note|In this and the following laws, <code>≅</code> refers to <i>isomorphism</i> rather than equality. In particular we consider <code>(x,()) ≅ x ≅ ((),x)</code> and <code>((x,y),z) ≅ (x,(y,z))</code>.}}<br />
* Left identity{{noteref}}: <haskell>unit ** v ≅ v</haskell><br />
* Right identity: <haskell>u ** unit ≅ u</haskell><br />
* Associativity: <haskell>u ** (v ** w) ≅ (u ** v) ** w</haskell><br />
<br />
These turn out to be equivalent to the usual <code>Applicative</code> laws. In a category theory setting, one would also require a naturality law:<br />
<br />
{{note|Here <code>g *** h {{=}} \(x,y) -> (g x, h y)</code>. See [[#Arrow|Arrows]].}}<br />
* Naturality: <haskell>fmap (g *** h) (u ** v) = fmap g u ** fmap h v</haskell><br />
<br />
but in the context of Haskell, this is a free theorem.<br />
<br />
Much of this section was taken from [http://blog.ezyang.com/2012/08/applicative-functors/ a blog post by Edward Z. Yang]; see his actual post for a bit more information.<br />
<br />
{{Exercises|<br />
# Implement <code>pure</code> and <code>(<*>)</code> in terms of <code>unit</code> and <code>(**)</code>, and vice versa.<br />
# Are there any <code>Applicative</code> instances for which there are also functions <code>f () -> ()</code> and <code>f (a,b) -> (f a, f b)</code>, satisfying some "reasonable" laws?<br />
# (Tricky) Prove that given your implementations from the previous exercise, the usual <code>Applicative</code> laws and the <code>Monoidal</code> laws stated above are equivalent.<br />
}}<br />
<br />
==Further reading==<br />
<br />
There are many other useful combinators in the standard libraries implemented in terms of <code>pure</code> and <code>(<*>)</code>: for example, <code>(*>)</code>, <code>(<*)</code>, <code>(<**>)</code>, <code>(<$)</code>, and so on (see [http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.7.0.0/Control-Applicative.html haddock for Applicative]). Judicious use of such secondary combinators can often make code using <code>Applicative</code>s much easier to read.<br />
<br />
[http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s original paper] is a treasure-trove of information and examples, as well as some perspectives on the connection between <code>Applicative</code> and category theory. Beginners will find it difficult to make it through the entire paper, but it is extremely well-motivated—even beginners will be able to glean something from reading as far as they are able.<br />
<br />
{{note|Introduced by [http://conal.net/papers/simply-reactive/ an earlier paper] that was since superseded by [http://conal.net/papers/push-pull-frp/ Push-pull functional reactive programming].}}<br />
<br />
Conal Elliott has been one of the biggest proponents of <code>Applicative</code>. For example, the [http://conal.net/papers/functional-images/ Pan library for functional images] and the reactive library for functional reactive programming (FRP) {{noteref}} make key use of it; his blog also contains [http://conal.net/blog/tag/applicative-functor many examples of <code>Applicative</code> in action]. Building on the work of McBride and Paterson, Elliott also built the [[TypeCompose]] library, which embodies the observation (among others) that <code>Applicative</code> types are closed under composition; therefore, <code>Applicative</code> instances can often be automatically derived for complex types built out of simpler ones.<br />
<br />
Although the [http://hackage.haskell.org/package/parsec Parsec parsing library] ([http://legacy.cs.uu.nl/daan/download/papers/parsec-paper.pdf paper]) was originally designed for use as a monad, in its most common use cases an <code>Applicative</code> instance can be used to great effect; [http://www.serpentine.com/blog/2008/02/06/the-basics-of-applicative-functors-put-to-practical-work/ Bryan O’Sullivan’s blog post] is a good starting point. If the extra power provided by <code>Monad</code> isn’t needed, it’s usually a good idea to use <code>Applicative</code> instead.<br />
<br />
A couple other nice examples of <code>Applicative</code> in action include the [http://web.archive.org/web/20090416111947/chrisdone.com/blog/html/2009-02-10-applicative-configfile-hsql.html ConfigFile and HSQL libraries] and the [http://groups.inf.ed.ac.uk/links/formlets/ formlets library].<br />
<br />
Gershom Bazerman's [http://comonad.com/reader/2012/abstracting-with-applicatives/ post] contains many insights into applicatives.<br />
<br />
=Monad=<br />
<br />
It’s a safe bet that if you’re reading this, you’ve heard of monads—although it’s quite possible you’ve never heard of <code>Applicative</code> before, or <code>Arrow</code>, or even <code>Monoid</code>. Why are monads such a big deal in Haskell? There are several reasons.<br />
<br />
* Haskell does, in fact, single out monads for special attention by making them the framework in which to construct I/O operations.<br />
* Haskell also singles out monads for special attention by providing a special syntactic sugar for monadic expressions: the <code>do</code>-notation.<br />
* <code>Monad</code> has been around longer than other abstract models of computation such as <code>Applicative</code> or <code>Arrow</code>.<br />
* The more monad tutorials there are, the harder people think monads must be, and the more new monad tutorials are written by people who think they finally “get” monads (the [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ monad tutorial fallacy]).<br />
<br />
I will let you judge for yourself whether these are good reasons.<br />
<br />
In the end, despite all the hoopla, <code>Monad</code> is just another type class. Let’s take a look at its definition.<br />
<br />
==Definition==<br />
<br />
The type class declaration for [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Monad <code>Monad</code>] is:<br />
<br />
<haskell><br />
class Monad m where<br />
return :: a -> m a<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
(>>) :: m a -> m b -> m b<br />
m >> n = m >>= \_ -> n<br />
<br />
fail :: String -> m a<br />
</haskell><br />
<br />
The <code>Monad</code> type class is exported by the <code>Prelude</code>, along with a few standard instances. However, many utility functions are found in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>], and there are also several instances (such as <code>((->) e)</code>) defined in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-Instances.html <code>Control.Monad.Instances</code>].<br />
<br />
{{note|However, as of GHC 7.10 this will be fixed!}}<br />
Let’s examine the methods in the <code>Monad</code> class one by one. The type of <code>return</code> should look familiar; it’s the same as <code>pure</code>. Indeed, <code>return</code> ''is'' <code>pure</code>, but with an unfortunate name. (Unfortunate, since someone coming from an imperative programming background might think that <code>return</code> is like the C or Java keyword of the same name, when in fact the similarities are minimal.) From a mathematical point of view, every monad is an applicative functor, but for historical reasons, the <code>Monad</code> type class declaration unfortunately does not require this.{{noteref}}<br />
<br />
We can see that <code>(>>)</code> is a specialized version of <code>(>>=)</code>, with a default implementation given. It is only included in the type class declaration so that specific instances of <code>Monad</code> can override the default implementation of <code>(>>)</code> with a more efficient one, if desired. Also, note that although <code>_ >> n = n</code> would be a type-correct implementation of <code>(>>)</code>, it would not correspond to the intended semantics: the intention is that <code>m >> n</code> ignores the ''result'' of <code>m</code>, but not its ''effects''.<br />
<br />
The <code>fail</code> function is an awful hack that has no place in the <code>Monad</code> class; more on this later.<br />
<br />
The only really interesting thing to look at—and what makes <code>Monad</code> strictly more powerful than <code>Applicative</code>—is <code>(>>=)</code>, which is often called ''bind''. An alternative definition of <code>Monad</code> could look like:<br />
<br />
<haskell><br />
class Applicative m => Monad' m where<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
</haskell><br />
<br />
We could spend a while talking about the intuition behind <code>(>>=)</code>—and we will. But first, let’s look at some examples.<br />
<br />
==Instances==<br />
<br />
Even if you don’t understand the intuition behind the <code>Monad</code> class, you can still create instances of it by just seeing where the types lead you. You may be surprised to find that this actually gets you a long way towards understanding the intuition; at the very least, it will give you some concrete examples to play with as you read more about the <code>Monad</code> class in general. The first few examples are from the standard <code>Prelude</code>; the remaining examples are from the [http://hackage.haskell.org/package/transformers <code>transformers</code> package].<br />
<br />
<ul><br />
<li>The simplest possible instance of <code>Monad</code> is [http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Monad-Identity.html <code>Identity</code>], which is described in Dan Piponi’s highly recommended blog post on [http://blog.sigfpe.com/2007/04/trivial-monad.html The Trivial Monad]. Despite being “trivial”, it is a great introduction to the <code>Monad</code> type class, and contains some good exercises to get your brain working.<br />
</li><br />
<li>The next simplest instance of <code>Monad</code> is <code>Maybe</code>. We already know how to write <code>return</code>/<code>pure</code> for <code>Maybe</code>. So how do we write <code>(>>=)</code>? Well, let’s think about its type. Specializing for <code>Maybe</code>, we have<br />
<br />
<haskell><br />
(>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b.<br />
</haskell><br />
<br />
If the first argument to <code>(>>=)</code> is <code>Just x</code>, then we have something of type <code>a</code> (namely, <code>x</code>), to which we can apply the second argument—resulting in a <code>Maybe b</code>, which is exactly what we wanted. What if the first argument to <code>(>>=)</code> is <code>Nothing</code>? In that case, we don’t have anything to which we can apply the <code>a -> Maybe b</code> function, so there’s only one thing we can do: yield <code>Nothing</code>. This instance is:<br />
<br />
<haskell><br />
instance Monad Maybe where<br />
return = Just<br />
(Just x) >>= g = g x<br />
Nothing >>= _ = Nothing<br />
</haskell><br />
<br />
We can already get a bit of intuition as to what is going on here: if we build up a computation by chaining together a bunch of functions with <code>(>>=)</code>, as soon as any one of them fails, the entire computation will fail (because <code>Nothing >>= f</code> is <code>Nothing</code>, no matter what <code>f</code> is). The entire computation succeeds only if all the constituent functions individually succeed. So the <code>Maybe</code> monad models computations which may fail.<br />
</li><br />
<br />
<li>The <code>Monad</code> instance for the list constructor <code>[]</code> is similar to its <code>Applicative</code> instance; see the exercise below.<br />
</li><br />
<br />
<li>Of course, the <code>IO</code> constructor is famously a <code>Monad</code>, but its implementation is somewhat magical, and may in fact differ from compiler to compiler. It is worth emphasizing that the <code>IO</code> monad is the ''only'' monad which is magical. It allows us to build up, in an entirely pure way, values representing possibly effectful computations. The special value <code>main</code>, of type <code>IO ()</code>, is taken by the runtime and actually executed, producing actual effects. Every other monad is functionally pure, and requires no special compiler support. We often speak of monadic values as “effectful computations”, but this is because some monads allow us to write code ''as if'' it has side effects, when in fact the monad is hiding the plumbing which allows these apparent side effects to be implemented in a functionally pure way.<br />
</li><br />
<br />
<li>As mentioned earlier, <code>((->) e)</code> is known as the ''reader monad'', since it describes computations in which a value of type <code>e</code> is available as a read-only environment.<br />
<br />
The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Reader.html <code>Control.Monad.Reader</code>] module provides the <code>Reader e a</code> type, which is just a convenient <code>newtype</code> wrapper around <code>(e -> a)</code>, along with an appropriate <code>Monad</code> instance and some <code>Reader</code>-specific utility functions such as <code>ask</code> (retrieve the environment), <code>asks</code> (retrieve a function of the environment), and <code>local</code> (run a subcomputation under a different environment).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Writer-Lazy.html <code>Control.Monad.Writer</code>] module provides the <code>Writer</code> monad, which allows information to be collected as a computation progresses. <code>Writer w a</code> is isomorphic to <code>(a,w)</code>, where the output value <code>a</code> is carried along with an annotation or “log” of type <code>w</code>, which must be an instance of <code>Monoid</code> (see [[#Monoid|section Monoid]]); the special function <code>tell</code> performs logging.<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-State-Lazy.html <code>Control.Monad.State</code>] module provides the <code>State s a</code> type, a <code>newtype</code> wrapper around <code>s -> (a,s)</code>. Something of type <code>State s a</code> represents a stateful computation which produces an <code>a</code> but can access and modify the state of type <code>s</code> along the way. The module also provides <code>State</code>-specific utility functions such as <code>get</code> (read the current state), <code>gets</code> (read a function of the current state), <code>put</code> (overwrite the state), and <code>modify</code> (apply a function to the state).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Cont.html <code>Control.Monad.Cont</code>] module provides the <code>Cont</code> monad, which represents computations in continuation-passing style. It can be used to suspend and resume computations, and to implement non-local transfers of control, co-routines, other complex control structures—all in a functionally pure way. <code>Cont</code> has been called the [http://blog.sigfpe.com/2008/12/mother-of-all-monads.html “mother of all monads”] because of its universal properties.<br />
</li><br />
</ul><br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement a <code>Monad</code> instance for the list constructor, <code>[]</code>. Follow the types!</li><br />
<li>Implement a <code>Monad</code> instance for <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> and <code>Monad</code> instances for <code>Free f</code>, defined as<br />
<haskell><br />
data Free f a = Var a<br />
| Node (f (Free f a))<br />
</haskell><br />
You may assume that <code>f</code> has a <code>Functor</code> instance. This is known as the ''free monad'' built from the functor <code>f</code>.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Intuition==<br />
<br />
Let’s look more closely at the type of <code>(>>=)</code>. The basic intuition is that it combines two computations into one larger computation. The first argument, <code>m a</code>, is the first computation. However, it would be boring if the second argument were just an <code>m b</code>; then there would be no way for the computations to interact with one another (actually, this is exactly the situation with <code>Applicative</code>). So, the second argument to <code>(>>=)</code> has type <code>a -> m b</code>: a function of this type, given a ''result'' of the first computation, can produce a second computation to be run. In other words, <code>x >>= k</code> is a computation which runs <code>x</code>, and then uses the result(s) of <code>x</code> to ''decide'' what computation to run second, using the output of the second computation as the result of the entire computation.<br />
<br />
{{note|Actually, because Haskell allows general recursion, this is a lie: using a Haskell parsing library one can recursively construct ''infinite'' grammars, and hence <code>Applicative</code> (together with <code>Alternative</code>) is enough to parse any context-sensitive language with a finite alphabet. See [http://byorgey.wordpress.com/2012/01/05/parsing-context-sensitive-languages-with-applicative/ Parsing context-sensitive languages with Applicative].}}<br />
Intuitively, it is this ability to use the output from previous computations to decide what computations to run next that makes <code>Monad</code> more powerful than <code>Applicative</code>. The structure of an <code>Applicative</code> computation is fixed, whereas the structure of a <code>Monad</code> computation can change based on intermediate results. This also means that parsers built using an <code>Applicative</code> interface can only parse context-free languages; in order to parse context-sensitive languages a <code>Monad</code> interface is needed.{{noteref}}<br />
<br />
To see the increased power of <code>Monad</code> from a different point of view, let’s see what happens if we try to implement <code>(>>=)</code> in terms of <code>fmap</code>, <code>pure</code>, and <code>(<*>)</code>. We are given a value <code>x</code> of type <code>m a</code>, and a function <code>k</code> of type <code>a -> m b</code>, so the only thing we can do is apply <code>k</code> to <code>x</code>. We can’t apply it directly, of course; we have to use <code>fmap</code> to lift it over the <code>m</code>. But what is the type of <code>fmap k</code>? Well, it’s <code>m a -> m (m b)</code>. So after we apply it to <code>x</code>, we are left with something of type <code>m (m b)</code>—but now we are stuck; what we really want is an <code>m b</code>, but there’s no way to get there from here. We can ''add'' <code>m</code>’s using <code>pure</code>, but we have no way to ''collapse'' multiple <code>m</code>’s into one.<br />
<br />
{{note|1=You might hear some people claim that that the definition in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> is the “math definition” and the definition in terms of <code>return</code> and <code>(>>=)</code> is something specific to Haskell. In fact, both definitions were known in the mathematics community long before Haskell picked up monads.}}<br />
<br />
This ability to collapse multiple <code>m</code>’s is exactly the ability provided by the function <code>join :: m (m a) -> m a</code>, and it should come as no surprise that an alternative definition of <code>Monad</code> can be given in terms of <code>join</code>:<br />
<br />
<haskell><br />
class Applicative m => Monad'' m where<br />
join :: m (m a) -> m a<br />
</haskell><br />
<br />
In fact, the canonical definition of monads in category theory is in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> (often called <math>\eta</math>, <math>T</math>, and <math>\mu</math> in the mathematical literature). Haskell uses an alternative formulation with <code>(>>=)</code> instead of <code>join</code> since it is more convenient to use {{noteref}}. However, sometimes it can be easier to think about <code>Monad</code> instances in terms of <code>join</code>, since it is a more “atomic” operation. (For example, <code>join</code> for the list monad is just <code>concat</code>.)<br />
<br />
{{Exercises|<br />
# Implement <code>(>>{{=}})</code> in terms of <code>fmap</code> (or <code>liftM</code>) and <code>join</code>.<br />
# Now implement <code>join</code> and <code>fmap</code> (<code>liftM</code>) in terms of <code>(>>{{=}})</code> and <code>return</code>.<br />
}}<br />
<br />
==Utility functions==<br />
<br />
The [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>] module provides a large number of convenient utility functions, all of which can be implemented in terms of the basic <code>Monad</code> operations (<code>return</code> and <code>(>>=)</code> in particular). We have already seen one of them, namely, <code>join</code>. We also mention some other noteworthy ones here; implementing these utility functions oneself is a good exercise. For a more detailed guide to these functions, with commentary and example code, see Henk-Jan van Tuyl’s [http://members.chello.nl/hjgtuyl/tourdemonad.html tour].<br />
<br />
{{note|This will most likely change in Haskell 2014 with the implementation of the [[Functor-Applicative-Monad_Proposal|Haskell 2014 Applicative => Monad proposal]].}}<br />
<br />
* <code>liftM :: Monad m => (a -> b) -> m a -> m b</code>. This should be familiar; of course, it is just <code>fmap</code>. The fact that we have both <code>fmap</code> and <code>liftM</code> is an unfortunate consequence of the fact that the <code>Monad</code> type class does not require a <code>Functor</code> instance, even though mathematically speaking, every monad is a functor. However, <code>fmap</code> and <code>liftM</code> are essentially interchangeable, since it is a bug (in a social rather than technical sense) for any type to be an instance of <code>Monad</code> without also being an instance of <code>Functor</code> {{noteref}}.<br />
<br />
* <code>ap :: Monad m => m (a -> b) -> m a -> m b</code> should also be familiar: it is equivalent to <code>(<*>)</code>, justifying the claim that the <code>Monad</code> interface is strictly more powerful than <code>Applicative</code>. We can make any <code>Monad</code> into an instance of <code>Applicative</code> by setting <code>pure = return</code> and <code>(<*>) = ap</code>.<br />
<br />
* <code>sequence :: Monad m => [m a] -> m [a]</code> takes a list of computations and combines them into one computation which collects a list of their results. It is again something of a historical accident that <code>sequence</code> has a <code>Monad</code> constraint, since it can actually be implemented only in terms of <code>Applicative</code>. There is an additional generalization of <code>sequence</code> to structures other than lists, which will be discussed in the [[#Traversable|section on <code>Traversable</code>]].<br />
<br />
* <code>replicateM :: Monad m => Int -> m a -> m [a]</code> is simply a combination of [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:replicate <code>replicate</code>] and <code>sequence</code>.<br />
<br />
* <code>when :: Monad m => Bool -> m () -> m ()</code> conditionally executes a computation, evaluating to its second argument if the test is <code>True</code>, and to <code>return ()</code> if the test is <code>False</code>. A collection of other sorts of monadic conditionals can be found in the [http://hackage.haskell.org/package/IfElse <code>IfElse</code> package].<br />
<br />
* <code>mapM :: Monad m => (a -> m b) -> [a] -> m [b]</code> maps its first argument over the second, and <code>sequence</code>s the results. The <code>forM</code> function is just <code>mapM</code> with its arguments reversed; it is called <code>forM</code> since it models generalized <code>for</code> loops: the list <code>[a]</code> provides the loop indices, and the function <code>a -> m b</code> specifies the “body” of the loop for each index.<br />
<br />
* <code>(=<<) :: Monad m => (a -> m b) -> m a -> m b</code> is just <code>(>>=)</code> with its arguments reversed; sometimes this direction is more convenient since it corresponds more closely to function application.<br />
<br />
* <code>(>=>) :: Monad m => (a -> m b) -> (b -> m c) -> a -> m c</code> is sort of like function composition, but with an extra <code>m</code> on the result type of each function, and the arguments swapped. We’ll have more to say about this operation later. There is also a flipped variant, <code>(<=<)</code>.<br />
<br />
* The <code>guard</code> function is for use with instances of <code>MonadPlus</code>, which is discussed at the end of the [[#Monoid|<code>Monoid</code> section]].<br />
<br />
Many of these functions also have “underscored” variants, such as <code>sequence_</code> and <code>mapM_</code>; these variants throw away the results of the computations passed to them as arguments, using them only for their side effects.<br />
<br />
Other monadic functions which are occasionally useful include <code>filterM</code>, <code>zipWithM</code>, <code>foldM</code>, and <code>forever</code>.<br />
<br />
==Laws==<br />
<br />
There are several laws that instances of <code>Monad</code> should satisfy (see also the [[Monad laws]] wiki page). The standard presentation is:<br />
<br />
<haskell><br />
return a >>= k = k a<br />
m >>= return = m<br />
m >>= (\x -> k x >>= h) = (m >>= k) >>= h<br />
<br />
fmap f xs = xs >>= return . f = liftM f xs<br />
</haskell><br />
<br />
The first and second laws express the fact that <code>return</code> behaves nicely: if we inject a value <code>a</code> into a monadic context with <code>return</code>, and then bind to <code>k</code>, it is the same as just applying <code>k</code> to <code>a</code> in the first place; if we bind a computation <code>m</code> to <code>return</code>, nothing changes. The third law essentially says that <code>(>>=)</code> is associative, sort of. The last law ensures that <code>fmap</code> and <code>liftM</code> are the same for types which are instances of both <code>Functor</code> and <code>Monad</code>—which, as already noted, should be every instance of <code>Monad</code>.<br />
<br />
{{note|I like to pronounce this operator “fish”.}}<br />
<br />
However, the presentation of the above laws, especially the third, is marred by the asymmetry of <code>(>>=)</code>. It’s hard to look at the laws and see what they’re really saying. I prefer a much more elegant version of the laws, which is formulated in terms of <code>(>=>)</code> {{noteref}}. Recall that <code>(>=>)</code> “composes” two functions of type <code>a -> m b</code> and <code>b -> m c</code>. You can think of something of type <code>a -> m b</code> (roughly) as a function from <code>a</code> to <code>b</code> which may also have some sort of effect in the context corresponding to <code>m</code>. <code>(>=>)</code> lets us compose these “effectful functions”, and we would like to know what properties <code>(>=>)</code> has. The monad laws reformulated in terms of <code>(>=>)</code> are:<br />
<br />
<haskell><br />
return >=> g = g<br />
g >=> return = g<br />
(g >=> h) >=> k = g >=> (h >=> k)<br />
</haskell><br />
<br />
{{note|As fans of category theory will note, these laws say precisely that functions of type <code>a -> m b</code> are the arrows of a category with <code>(>{{=}}>)</code> as composition! Indeed, this is known as the ''Kleisli category'' of the monad <code>m</code>. It will come up again when we discuss <code>Arrow</code>s.}}<br />
<br />
Ah, much better! The laws simply state that <code>return</code> is the identity of <code>(>=>)</code>, and that <code>(>=>)</code> is associative {{noteref}}.<br />
<br />
There is also a formulation of the monad laws in terms of <code>fmap</code>, <code>return</code>, and <code>join</code>; for a discussion of this formulation, see the Haskell [http://en.wikibooks.org/wiki/Haskell/Category_theory wikibook page on category theory].<br />
<br />
{{Exercises|<br />
# Given the definition <code>g >{{=}}> h {{=}} \x -> g x >>{{=}} h</code>, prove the equivalence of the above laws and the usual monad laws.<br />
}}<br />
<br />
==<code>do</code> notation==<br />
<br />
Haskell’s special <code>do</code> notation supports an “imperative style” of programming by providing syntactic sugar for chains of monadic expressions. The genesis of the notation lies in realizing that something like <code>a >>= \x -> b >> c >>= \y -> d </code> can be more readably written by putting successive computations on separate lines:<br />
<br />
<haskell><br />
a >>= \x -><br />
b >><br />
c >>= \y -><br />
d<br />
</haskell><br />
<br />
This emphasizes that the overall computation consists of four computations <code>a</code>, <code>b</code>, <code>c</code>, and <code>d</code>, and that <code>x</code> is bound to the result of <code>a</code>, and <code>y</code> is bound to the result of <code>c</code> (<code>b</code>, <code>c</code>, and <code>d</code> are allowed to refer to <code>x</code>, and <code>d</code> is allowed to refer to <code>y</code> as well). From here it is not hard to imagine a nicer notation:<br />
<br />
<haskell><br />
do { x <- a<br />
; b<br />
; y <- c<br />
; d<br />
}<br />
</haskell><br />
<br />
(The curly braces and semicolons may optionally be omitted; the Haskell parser uses layout to determine where they should be inserted.) This discussion should make clear that <code>do</code> notation is just syntactic sugar. In fact, <code>do</code> blocks are recursively translated into monad operations (almost) like this:<br />
<br />
<pre><br />
do e → e<br />
do { e; stmts } → e >> do { stmts }<br />
do { v <- e; stmts } → e >>= \v -> do { stmts }<br />
do { let decls; stmts} → let decls in do { stmts }<br />
</pre><br />
<br />
This is not quite the whole story, since <code>v</code> might be a pattern instead of a variable. For example, one can write<br />
<br />
<haskell><br />
do (x:xs) <- foo<br />
bar x<br />
</haskell><br />
<br />
but what happens if <code>foo</code> produces an empty list? Well, remember that ugly <code>fail</code> function in the <code>Monad</code> type class declaration? That’s what happens. See [http://www.haskell.org/onlinereport/exps.html#sect3.14 section 3.14 of the Haskell Report] for the full details. See also the discussion of <code>MonadPlus</code> and <code>MonadZero</code> in the [[#Other monoidal classes: Alternative, MonadPlus, ArrowPlus|section on other monoidal classes]].<br />
<br />
A final note on intuition: <code>do</code> notation plays very strongly to the “computational context” point of view rather than the “container” point of view, since the binding notation <code>x <- m</code> is suggestive of “extracting” a single <code>x</code> from <code>m</code> and doing something with it. But <code>m</code> may represent some sort of a container, such as a list or a tree; the meaning of <code>x <- m</code> is entirely dependent on the implementation of <code>(>>=)</code>. For example, if <code>m</code> is a list, <code>x <- m</code> actually means that <code>x</code> will take on each value from the list in turn.<br />
<br />
==Further reading==<br />
<br />
Philip Wadler was the first to propose using monads to structure functional programs. [http://homepages.inf.ed.ac.uk/wadler/topics/monads.html His paper] is still a readable introduction to the subject.<br />
<br />
{{note|1=<br />
[[All About Monads]],<br />
[http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers],<br />
[http://en.wikibooks.org/w/index.php?title=Haskell/Understanding_monads Understanding monads],<br />
[[The Monadic Way]],<br />
[http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads! (And Maybe You Already Have.)],<br />
[http://www.haskell.org/pipermail/haskell-cafe/2006-November/019190.html there’s a monster in my Haskell!],<br />
[http://kawagner.blogspot.com/2007/02/understanding-monads-for-real.html Understanding Monads. For real.],<br />
[http://www.randomhacks.net/articles/2007/03/12/monads-in-15-minutes Monads in 15 minutes: Backtracking and Maybe],<br />
[http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation],<br />
[http://metafoo.co.uk/practical-monads.txt Practical Monads]}}<br />
<br />
There are, of course, numerous monad tutorials of varying quality {{noteref}}.<br />
<br />
A few of the best include Cale Gibbard’s [http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers] and [http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation]; Jeff Newbern’s [[All About Monads]], a comprehensive guide with lots of examples; and Dan Piponi’s [http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads!], which features great exercises. If you just want to know how to use <code>IO</code>, you could consult the [[Introduction to IO]]. Even this is just a sampling; the [[monad tutorials timeline]] is a more complete list. (All these monad tutorials have prompted parodies like [http://koweycode.blogspot.com/2007/01/think-of-monad.html think of a monad ...] as well as other kinds of backlash like [http://ahamsandwich.wordpress.com/2007/07/26/monads-and-why-monad-tutorials-are-all-awful/ Monads! (and Why Monad Tutorials Are All Awful)] or [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Abstraction, intuition, and the “monad tutorial fallacy”].)<br />
<br />
Other good monad references which are not necessarily tutorials include [http://members.chello.nl/hjgtuyl/tourdemonad.html Henk-Jan van Tuyl’s tour] of the functions in <code>Control.Monad</code>, Dan Piponi’s [http://blog.sigfpe.com/2006/10/monads-field-guide.html field guide], Tim Newsham’s [http://www.thenewsh.com/~newsham/haskell/monad.html What’s a Monad?], and Chris Smith's excellent article [http://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/ Why Do Monads Matter?]. There are also many blog posts which have been written on various aspects of monads; a collection of links can be found under [[Blog articles/Monads]].<br />
<br />
For help constructing monads from scratch, and for obtaining a "deep embedding" of monad operations suitable for use in, say, compiling a domain-specific language, see [http://projects.haskell.org/operational Apfelmus's operational package].<br />
<br />
One of the quirks of the <code>Monad</code> class and the Haskell type system is that it is not possible to straightforwardly declare <code>Monad</code> instances for types which require a class constraint on their data, even if they are monads from a mathematical point of view. For example, <code>Data.Set</code> requires an <code>Ord</code> constraint on its data, so it cannot be easily made an instance of <code>Monad</code>. A solution to this problem was [http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros first described by Eric Kidd], and later made into a [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmonad library named rmonad] by Ganesh Sittampalam and Peter Gavin.<br />
<br />
There are many good reasons for eschewing <code>do</code> notation; some have gone so far as to [[Do_notation_considered_harmful|consider it harmful]].<br />
<br />
Monads can be generalized in various ways; for an exposition of one possibility, see Robert Atkey’s paper on [http://homepages.inf.ed.ac.uk/ratkey/paramnotions-jfp.pdf parameterized monads], or Dan Piponi’s [http://blog.sigfpe.com/2009/02/beyond-monads.html Beyond Monads].<br />
<br />
For the categorically inclined, monads can be viewed as monoids ([http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html From Monoids to Monads]) and also as closure operators [http://blog.plover.com/math/monad-closure.html Triples and Closure]. Derek Elkins’s article in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13 of the Monad.Reader] contains an exposition of the category-theoretic underpinnings of some of the standard <code>Monad</code> instances, such as <code>State</code> and <code>Cont</code>. Jonathan Hill and Keith Clarke have [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.6497 an early paper explaining the connection between monads as they arise in category theory and as used in functional programming]. There is also a [http://okmij.org/ftp/Computation/IO-monad-history.html web page by Oleg Kiselyov] explaining the history of the IO monad.<br />
<br />
Links to many more research papers related to monads can be found under [[Research papers/Monads and arrows]].<br />
<br />
=Monad transformers=<br />
<br />
One would often like to be able to combine two monads into one: for example, to have stateful, nondeterministic computations (<code>State</code> + <code>[]</code>), or computations which may fail and can consult a read-only environment (<code>Maybe</code> + <code>Reader</code>), and so on. Unfortunately, monads do not compose as nicely as applicative functors (yet another reason to use <code>Applicative</code> if you don’t need the full power that <code>Monad</code> provides), but some monads can be combined in certain ways.<br />
<br />
==Standard monad transformers==<br />
<br />
The [http://hackage.haskell.org/package/transformers transformers] library provides a number of standard ''monad transformers''. Each monad transformer adds a particular capability/feature/effect to any existing monad.<br />
<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Identity.html <code>IdentityT</code>] is the identity transformer, which maps a monad to (something isomorphic to) itself. This may seem useless at first glance, but it is useful for the same reason that the <code>id</code> function is useful -- it can be passed as an argument to things which are parameterized over an arbitrary monad transformer, when you do not actually want any extra capabilities.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-State.html <code>StateT</code>] adds a read-write state.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Reader.html <code>ReaderT</code>] adds a read-only environment.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Writer.html <code>WriterT</code>] adds a write-only log.<br />
* [http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-RWS.html <code>RWST</code>] conveniently combines <code>ReaderT</code>, <code>WriterT</code>, and <code>StateT</code> into one.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Maybe.html <code>MaybeT</code>] adds the possibility of failure.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Error.html <code>ErrorT</code>] adds the possibility of failure with an arbitrary type to represent errors.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-List.html <code>ListT</code>] adds non-determinism (however, see the discussion of <code>ListT</code> below).<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Cont.html <code>ContT</code>] adds continuation handling.<br />
<br />
For example, <code>StateT s Maybe</code> is an instance of <code>Monad</code>; computations of type <code>StateT s Maybe a</code> may fail, and have access to a mutable state of type <code>s</code>. Monad transformers can be multiply stacked. One thing to keep in mind while using monad transformers is that the order of composition matters. For example, when a <code>StateT s Maybe a</code> computation fails, the state ceases being updated (indeed, it simply disappears); on the other hand, the state of a <code>MaybeT (State s) a</code> computation may continue to be modified even after the computation has "failed". This may seem backwards, but it is correct. Monad transformers build composite monads “inside out”; <code>MaybeT (State s) a</code> is isomorphic to <code>s -> (Maybe a, s)</code>. (Lambdabot has an indispensable <code>@unmtl</code> command which you can use to “unpack” a monad transformer stack in this way.)<br />
Intuitively, the monads become "more fundamental" the further inside the stack you get, and the effects of inner monads "have precedence" over the effects of outer ones. Of course, this is just handwaving, and if you are unsure of the proper order for some monads you wish to combine, there is no substitute for using <code>@unmtl</code> or simply trying out the various options.<br />
<br />
==Definition and laws==<br />
<br />
All monad transformers should implement the <code>MonadTrans</code> type class, defined in <code>Control.Monad.Trans.Class</code>:<br />
<br />
<haskell><br />
class MonadTrans t where<br />
lift :: Monad m => m a -> t m a<br />
</haskell><br />
<br />
It allows arbitrary computations in the base monad <code>m</code> to be “lifted” into computations in the transformed monad <code>t m</code>. (Note that type application associates to the left, just like function application, so <code>t m a = (t m) a</code>.)<br />
<br />
<code>lift</code> must satisfy the laws<br />
<haskell><br />
lift . return = return<br />
lift (m >>= f) = lift m >>= (lift . f)<br />
</haskell><br />
which intuitively state that <code>lift</code> transforms <code>m a</code> computations into <code>t m a</code> computations in a "sensible" way, which sends the <code>return</code> and <code>(>>=)</code> of <code>m</code> to the <code>return</code> and <code>(>>=)</code> of <code>t m</code>.<br />
<br />
{{Exercises|<br />
# What is the kind of <code>t</code> in the declaration of <code>MonadTrans</code>?<br />
}}<br />
<br />
==Transformer type classes and "capability" style==<br />
<br />
{{note|The only problem with this scheme is the quadratic number of instances required as the number of standard monad transformers grows—but as the current set of standard monad transformers seems adequate for most common use cases, this may not be that big of a deal.}}<br />
<br />
There are also type classes (provided by the [http://hackage.haskell.org/package/mtl <code>mtl</code> package]) for the operations of each transformer. For example, the <code>MonadState</code> type class provides the state-specific methods <code>get</code> and <code>put</code>, allowing you to conveniently use these methods not only with <code>State</code>, but with any monad which is an instance of <code>MonadState</code>—including <code>MaybeT (State s)</code>, <code>StateT s (ReaderT r IO)</code>, and so on. Similar type classes exist for <code>Reader</code>, <code>Writer</code>, <code>Cont</code>, <code>IO</code>, and others {{noteref}}.<br />
<br />
These type classes serve two purposes. First, they get rid of (most of) the need for explicitly using <code>lift</code>, giving a type-directed way to automatically determine the right number of calls to <code>lift</code>. Simply writing <code>put</code> will be automatically translated into <code>lift . put</code>, <code>lift . lift . put</code>, or something similar depending on what concrete monad stack you are using.<br />
<br />
Second, they give you more flexibility to switch between different concrete monad stacks. For example, if you are writing a state-based algorithm, don't write<br />
<haskell><br />
foo :: State Int Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
but rather<br />
<haskell><br />
foo :: MonadState Int m => m Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
Now, if somewhere down the line you realize you need to introduce the possibility of failure, you might switch from <code>State Int</code> to <code>MaybeT (State Int)</code>. The type of the first version of <code>foo</code> would need to be modified to reflect this change, but the second version of <code>foo</code> can still be used as-is.<br />
<br />
However, this sort of "capability-based" style (<i>e.g.</i> specifying that <code>foo</code> works for any monad with the "state capability") quickly runs into problems when you try to naively scale it up: for example, what if you need to maintain two independent states? A framework for solving this and related problems is described by Schrijvers and Olivera ([http://users.ugent.be/~tschrijv/Research/papers/icfp2011.pdf Monads, zippers and views: virtualizing the monad stack, ICFP 2011]) and is implemented in the [http://hackage.haskell.org/package/Monatron <code>Monatron</code> package].<br />
<br />
==Composing monads==<br />
<br />
Is the composition of two monads always a monad? As hinted previously, the answer is no.<br />
<br />
Since <code>Applicative</code> functors are closed under composition, the problem must lie with <code>join</code>. Indeed, suppose <code>m</code> and <code>n</code> are arbitrary monads; to make a monad out of their composition we would need to be able to implement<br />
<haskell><br />
join :: m (n (m (n a))) -> m (n a)<br />
</haskell><br />
but it is not clear how this could be done in general. The <code>join</code> method for <code>m</code> is no help, because the two occurrences of <code>m</code> are not next to each other (and likewise for <code>n</code>).<br />
<br />
However, one situation in which it can be done is if <code>n</code> ''distributes'' over <code>m</code>, that is, if there is a function<br />
<haskell><br />
distrib :: n (m a) -> m (n a)<br />
</haskell><br />
satisfying certain laws. See Jones and Duponcheel ([http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.2605 Composing Monads]); see also the [[#Traversable|section on Traversable]].<br />
<br />
For a much more in-depth discussion and analysis of the failure of monads to be closed under composition, see [http://stackoverflow.com/questions/13034229/concrete-example-showing-that-monads-are-not-closed-under-composition-with-proo?lq=1 this question on StackOverflow].<br />
<br />
{{Exercises|<br />
* Implement <code>join :: M (N (M (N a))) -> M (N a)</code>, given <code>distrib :: N (M a) -> M (N a)</code> and assuming <code>M</code> and <code>N</code> are instances of <code>Monad</code>.<br />
}}<br />
<br />
==Further reading==<br />
<br />
Much of the monad transformer library (originally [http://hackage.haskell.org/package/mtl <code>mtl</code>], now split between <code>mtl</code> and [http://hackage.haskell.org/package/transformers <code>transformers</code>]), including the <code>Reader</code>, <code>Writer</code>, <code>State</code>, and other monads, as well as the monad transformer framework itself, was inspired by Mark Jones’s classic paper [http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Functional Programming with Overloading and Higher-Order Polymorphism]. It’s still very much worth a read—and highly readable—after almost fifteen years.<br />
<br />
See [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17139 Edward Kmett's mailing list message] for a description of the history and relationships among monad transformer packages (<code>mtl</code>, <code>transformers</code>, <code>monads-fd</code>, <code>monads-tf</code>).<br />
<br />
There are two excellent references on monad transformers. Martin Grabmüller’s [http://www.grabmueller.de/martin/www/pub/Transformers.en.html Monad Transformers Step by Step] is a thorough description, with running examples, of how to use monad transformers to elegantly build up computations with various effects. [http://cale.yi.org/index.php/How_To_Use_Monad_Transformers Cale Gibbard’s article] on how to use monad transformers is more practical, describing how to structure code using monad transformers to make writing it as painless as possible. Another good starting place for learning about monad transformers is a [http://blog.sigfpe.com/2006/05/grok-haskell-monad-transformers.html blog post by Dan Piponi].<br />
<br />
The <code>ListT</code> transformer from the <code>transformers</code> package comes with the caveat that <code>ListT m</code> is only a monad when <code>m</code> is ''commutative'', that is, when <code>ma >>= \a -> mb >>= \b -> foo</code> is equivalent to <code>mb >>= \b -> ma >>= \a -> foo</code> (i.e. the order of <code>m</code>'s effects does not matter). For one explanation why, see Dan Piponi's blog post [http://blog.sigfpe.com/2006/11/why-isnt-listt-monad.html "Why isn't <code><nowiki>ListT []</nowiki></code> a monad"]. For more examples, as well as a design for a version of <code>ListT</code> which does not have this problem, see [http://www.haskell.org/haskellwiki/ListT_done_right <code>ListT</code> done right].<br />
<br />
There is an alternative way to compose monads, using coproducts, as described by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.3581 Lüth and Ghani]. This method is interesting but has not (yet?) seen widespread use. For a more recent alternative, see Kiselyov et al's [http://okmij.org/ftp/Haskell/extensible/exteff.pdf Extensible Effects: An Alternative to Monad Transformers].<br />
<br />
=MonadFix=<br />
<br />
''Note: <code>MonadFix</code> is included here for completeness (and because it is interesting) but seems not to be used much. Skipping this section on a first read-through is perfectly OK (and perhaps even recommended).''<br />
<br />
==<code>mdo</code>/<code>do rec</code> notation==<br />
<br />
{{note|In GHC 7.6, the flag has been changed to <code>-XRecursiveDo</code>.}}<br />
The <code>MonadFix</code> class describes monads which support the special fixpoint operation <code>mfix :: (a -> m a) -> m a</code>, which allows the output of monadic computations to be defined via (effectful) recursion. This is [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation supported in GHC] by a special “recursive do” notation, enabled by the <code>-XDoRec</code> flag{{noteref}}. Within a <code>do</code> block, one may have a nested <code>rec</code> block, like so:<br />
<haskell><br />
do { x <- foo<br />
; rec { y <- baz<br />
; z <- bar<br />
; bob<br />
}<br />
; w <- frob<br />
}<br />
</haskell><br />
Normally (if we had <code>do</code> in place of <code>rec</code> in the above example), <code>y</code> would be in scope in <code>bar</code> and <code>bob</code> but not in <code>baz</code>, and <code>z</code> would be in scope only in <code>bob</code>. With the <code>rec</code>, however, <code>y</code> and <code>z</code> are both in scope in all three of <code>baz</code>, <code>bar</code>, and <code>bob</code>. A <code>rec</code> block is analogous to a <code>let</code> block such as<br />
<haskell><br />
let { y = baz<br />
; z = bar<br />
}<br />
in bob<br />
</haskell><br />
because, in Haskell, every variable bound in a <code>let</code>-block is in scope throughout the entire block. (From this point of view, Haskell's normal <code>do</code> blocks are analogous to Scheme's <code>let*</code> construct.)<br />
<br />
What could such a feature be used for? One of the motivating examples given in the original paper describing <code>MonadFix</code> (see below) is encoding circuit descriptions. A line in a <code>do</code>-block such as <br />
<haskell><br />
x <- gate y z<br />
</haskell><br />
describes a gate whose input wires are labeled <code>y</code> and <code>z</code> and whose output wire is labeled <code>x</code>. Many (most?) useful circuits, however, involve some sort of feedback loop, making them impossible to write in a normal <code>do</code>-block (since some wire would have to be mentioned as an input ''before'' being listed as an output). Using a <code>rec</code> block solves this problem.<br />
<br />
==Examples and intuition==<br />
<br />
Of course, not every monad supports such recursive binding. However, as mentioned above, it suffices to have an implementation of <code>mfix :: (a -> m a) -> m a</code>, satisfying a few laws. Let's try implementing <code>mfix</code> for the <code>Maybe</code> monad. That is, we want to implement a function<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
</haskell><br />
{{note|Actually, <code>fix</code> is implemented slightly differently for efficiency reasons; but the given definition is equivalent and simpler for the present purpose.}}<br />
Let's think for a moment about the implementation {{noteref}} of the non-monadic <code>fix :: (a -> a) -> a</code>:<br />
<haskell><br />
fix f = f (fix f)<br />
</haskell><br />
Inspired by <code>fix</code>, our first attempt at implementing <code>maybeFix</code> might be something like<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = maybeFix f >>= f<br />
</haskell><br />
This has the right type. However, something seems wrong: there is nothing in particular here about <code>Maybe</code>; <code>maybeFix</code> actually has the more general type <code>Monad m => (a -> m a) -> m a</code>. But didn't we just say that not all monads support <code>mfix</code>?<br />
<br />
The answer is that although this implementation of <code>maybeFix</code> has the right type, it does ''not'' have the intended semantics. If we think about how <code>(>>=)</code> works for the <code>Maybe</code> monad (by pattern-matching on its first argument to see whether it is <code>Nothing</code> or <code>Just</code>) we can see that this definition of <code>maybeFix</code> is completely useless: it will just recurse infinitely, trying to decide whether it is going to return <code>Nothing</code> or <code>Just</code>, without ever even so much as a glance in the direction of <code>f</code>.<br />
<br />
The trick is to simply ''assume'' that <code>maybeFix</code> will return <code>Just</code>, and get on with life!<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = ma<br />
where ma = f (fromJust ma)<br />
</haskell><br />
This says that the result of <code>maybeFix</code> is <code>ma</code>, and assuming that <code>ma = Just x</code>, it is defined (recursively) to be equal to <code>f x</code>.<br />
<br />
Why is this OK? Isn't <code>fromJust</code> almost as bad as <code>unsafePerformIO</code>? Well, usually, yes. This is just about the only situation in which it is justified! The interesting thing to note is that <code>maybeFix</code> ''will never crash'' -- although it may, of course, fail to terminate. The only way we could get a crash is if we try to evaluate <code>fromJust ma</code> when we know that <code>ma = Nothing</code>. But how could we know <code>ma = Nothing</code>? Since <code>ma</code> is defined as <code>f (fromJust ma)</code>, it must be that this expression has already been evaluated to <code>Nothing</code> -- in which case there is no reason for us to be evaluating <code>fromJust ma</code> in the first place! <br />
<br />
To see this from another point of view, we can consider three possibilities. First, if <code>f</code> outputs <code>Nothing</code> without looking at its argument, then <code>maybeFix f</code> clearly returns <code>Nothing</code>. Second, if <code>f</code> always outputs <code>Just x</code>, where <code>x</code> depends on its argument, then the recursion can proceed usefully: <code>fromJust ma</code> will be able to evaluate to <code>x</code>, thus feeding <code>f</code>'s output back to it as input. Third, if <code>f</code> tries to use its argument to decide whether to output <code>Just</code> or <code>Nothing</code>, then <code>maybeFix f</code> will not terminate: evaluating <code>f</code>'s argument requires evaluating <code>ma</code> to see whether it is <code>Just</code>, which requires evaluating <code>f (fromJust ma)</code>, which requires evaluating <code>ma</code>, ... and so on.<br />
<br />
There are also instances of <code>MonadFix</code> for lists (which works analogously to the instance for <code>Maybe</code>), for <code>ST</code>, and for <code>IO</code>. The [http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/System-IO.html#fixIO instance for <code>IO</code>] is particularly amusing: it creates a new (empty) <code>MVar</code>, immediately reads its contents using <code>unsafeInterleaveIO</code> (which delays the actual reading lazily until the value is needed), uses the contents of the <code>MVar</code> to compute a new value, which it then writes back into the <code>MVar</code>. It almost seems, spookily, that <code>mfix</code> is sending a value back in time to itself through the <code>MVar</code> -- though of course what is really going on is that the reading is delayed just long enough (via <code>unsafeInterleaveIO</code>) to get the process bootstrapped.<br />
<br />
{{Exercises|<br />
* Implement a <code>MonadFix</code> instance for <code>[]</code>.<br />
}}<br />
<br />
==GHC 7.6 changes==<br />
<br />
GHC 7.6 reinstated the old <code>mdo</code> syntax, so the example at the start of this section can be written<br />
<br />
<haskell><br />
mdo { x <- foo<br />
; y <- baz<br />
; z <- bar<br />
; bob<br />
; w <- frob<br />
}<br />
</haskell><br />
<br />
which will be translated into the original example (assuming that, say, <code>bar</code> and <code>bob</code> refer to <code>y</code>. The difference is that <code>mdo</code> will analyze the code in order to find minimal recursive blocks, which will be placed in <code>rec</code> blocks, whereas <code>rec</code> blocks desugar directly into calls to <code>mfix</code> without any further analysis. <br />
==Further reading==<br />
<br />
For more information (such as the precise desugaring rules for <code>rec</code> blocks), see Levent Erkök and John Launchbury's 2002 Haskell workshop paper, [http://sites.google.com/site/leventerkok/recdo.pdf?attredirects=0 A Recursive do for Haskell], or for full details, Levent Erkök’s thesis, [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.15.1543&rep=rep1&type=pdf Value Recursion in Monadic Computations]. (Note, while reading, that <code>MonadFix</code> used to be called <code>MonadRec</code>.) You can also read the [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation GHC user manual section on recursive do-notation].<br />
<br />
=Semigroup=<br />
<br />
A semigroup is a set <math>S\ </math> together with a binary operation <math>\oplus\ </math> which<br />
combines elements from <math>S\ </math>. The <math>\oplus\ </math> operator is required to be associative<br />
(that is, <math>(a \oplus b) \oplus c = a \oplus (b \oplus c)\ </math>, for any<br />
<math>a,b,c\ </math> which are elements of <math>S\ </math>).<br />
<br />
For example, the natural numbers under addition form a semigroup: the sum of any two natural numbers is a natural number, and <math>(a+b)+c = a+(b+c)\ </math> for any natural numbers <math>a\ </math>, <math>b\ </math>, and <math>c\,\ </math>. The integers under multiplication also form a semigroup, as do the integers (or rationals, or reals) under <math>\max\ </math> or <math>\min\ </math>, Boolean values under conjunction and disjunction, lists under concatenation, functions from a set to itself under composition ... Semigroups show up all over the place, once you know to look for them.<br />
<br />
==Definition==<br />
<br />
Semigroups are not (yet?) defined in the base package, but the {{HackagePackage|id=semigroups}} package provides a standard definition.<br />
<br />
The definition of the <code>Semigroup</code> type class ([http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock]) is as follows:<br />
<br />
<haskell><br />
class Semigroup a where<br />
(<>) :: a -> a -> a<br />
<br />
sconcat :: NonEmpty a -> a<br />
sconcat = sconcat (a :| as) = go a as where<br />
go b (c:cs) = b <> go c cs<br />
go b [] = b<br />
<br />
times1p :: Whole n => n -> a -> a<br />
times1p = ...<br />
</haskell><br />
<br />
The really important method is <code>(<>)</code>, representing the associative binary operation. The other two methods have default implementations in terms of <code>(<>)</code>, and are included in the type class in case some instances can give more efficient implementations than the default. <code>sconcat</code> reduces a nonempty list using <code>(<>)</code>; <code>times1p n</code> is equivalent to (but more efficient than) <code>sconcat . replicate n</code>. See the [http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock documentation] for more information on <code>sconcat</code> and <code>times1p</code>.<br />
<br />
==Laws==<br />
<br />
The only law is that <code>(<>)</code> must be associative:<br />
<br />
<haskell><br />
(x <> y) <> z = x <> (y <> z)<br />
</haskell><br />
<br />
=Monoid=<br />
<br />
Many semigroups have a special element <math>e</math> for which the binary operation <math>\oplus</math> is the identity, that is, <math>e \oplus x = x \oplus e = x</math> for every element <math>x</math>. Such a semigroup-with-identity-element is called a ''monoid''.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Monoid</code> type class (defined in<br />
<code>Data.Monoid</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html haddock]) is:<br />
<br />
<haskell><br />
class Monoid a where<br />
mempty :: a<br />
mappend :: a -> a -> a<br />
<br />
mconcat :: [a] -> a<br />
mconcat = foldr mappend mempty<br />
</haskell><br />
<br />
The <code>mempty</code> value specifies the identity element of the monoid, and <code>mappend</code><br />
is the binary operation. The default definition for <code>mconcat</code><br />
“reduces” a list of elements by combining them all with <code>mappend</code>,<br />
using a right fold. It is only in the <code>Monoid</code> class so that specific<br />
instances have the option of providing an alternative, more efficient<br />
implementation; usually, you can safely ignore <code>mconcat</code> when creating<br />
a <code>Monoid</code> instance, since its default definition will work just fine.<br />
<br />
The <code>Monoid</code> methods are rather unfortunately named; they are inspired<br />
by the list instance of <code>Monoid</code>, where indeed <code>mempty = []</code> and <code>mappend = (++)</code>, but this is misleading since many<br />
monoids have little to do with appending (see these [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 Comments from OCaml Hacker Brian Hurt] on the Haskell-cafe mailing list). This was improved in GHC 7.4, where <code>(<>)</code> was added as an alias to <code>mappend</code>.<br />
<br />
==Laws==<br />
<br />
Of course, every <code>Monoid</code> instance should actually be a monoid in the<br />
mathematical sense, which implies these laws:<br />
<br />
<haskell><br />
mempty `mappend` x = x<br />
x `mappend` mempty = x<br />
(x `mappend` y) `mappend` z = x `mappend` (y `mappend` z)<br />
</haskell><br />
<br />
==Instances==<br />
<br />
There are quite a few interesting <code>Monoid</code> instances defined in <code>Data.Monoid</code>.<br />
<br />
<ul><br />
<li><code>[a]</code> is a <code>Monoid</code>, with <code>mempty = []</code> and <code>mappend = (++)</code>. It is not hard to check that <code>(x ++ y) ++ z = x ++ (y ++ z)</code> for any lists <code>x</code>, <code>y</code>, and <code>z</code>, and that the empty list is the identity: <code>[] ++ x = x ++ [] = x</code>.</li><br />
<br />
<li>As noted previously, we can make a monoid out of any numeric type under either addition or multiplication. However, since we can’t have two instances for the same type, <code>Data.Monoid</code> provides two <code>newtype</code> wrappers, <code>Sum</code> and <code>Product</code>, with appropriate <code>Monoid</code> instances.<br />
<br />
<haskell><br />
> getSum (mconcat . map Sum $ [1..5])<br />
15<br />
> getProduct (mconcat . map Product $ [1..5])<br />
120<br />
</haskell><br />
<br />
This example code is silly, of course; we could just write<br />
<code>sum [1..5]</code> and <code>product [1..5]</code>. Nevertheless, these instances are useful in more generalized settings, as we will see in the [[Foldable|section on <code>Foldable</code>]].</li><br />
<br />
<li><code>Any</code> and <code>All</code> are <code>newtype</code> wrappers providing <code>Monoid</code> instances for <code>Bool</code> (under disjunction and conjunction, respectively).</li><br />
<br />
<li> There are three instances for <code>Maybe</code>: a basic instance which lifts a <code>Monoid</code> instance for <code>a</code> to an instance for <code>Maybe a</code>, and two <code>newtype</code> wrappers <code>First</code> and <code>Last</code> for which <code>mappend</code> selects the first (respectively last) non-<code>Nothing</code> item.</li><br />
<br />
<li><code>Endo a</code> is a newtype wrapper for functions <code>a -> a</code>, which form a monoid under composition.</li><br />
<br />
<li>There are several ways to “lift” <code>Monoid</code> instances to instances with additional structure. We have already seen that an instance for <code>a</code> can be lifted to an instance for <code>Maybe a</code>. There are also tuple instances: if <code>a</code> and <code>b</code> are instances of <code>Monoid</code>, then so is <code>(a,b)</code>, using the monoid operations for <code>a</code> and <code>b</code> in the obvious pairwise manner. Finally, if <code>a</code> is a <code>Monoid</code>, then so is the function type <code>e -> a</code> for any <code>e</code>; in particular, <code>g `mappend` h</code> is the function which applies both <code>g</code> and <code>h</code> to its argument and then combines the results using the underlying <code>Monoid</code> instance for <code>a</code>. This can be quite useful and elegant (see [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/52416 example]).</li><br />
<br />
<li>The type <code>Ordering = LT | EQ | GT</code> is a <code>Monoid</code>, defined in such a way that <code>mconcat (zipWith compare xs ys)</code> computes the lexicographic ordering of <code>xs</code> and <code>ys</code> (if <code>xs</code> and <code>ys</code> have the same length). In particular, <code>mempty = EQ</code>, and <code>mappend</code> evaluates to its leftmost non-<code>EQ</code> argument (or <code>EQ</code> if both arguments are <code>EQ</code>). This can be used together with the function instance of <code>Monoid</code> to do some clever things ([http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx example]).</li><br />
<br />
<li>There are also <code>Monoid</code> instances for several standard data structures in the containers library ([http://hackage.haskell.org/packages/archive/containers/0.2.0.0/doc/html/index.html haddock]), including <code>Map</code>, <code>Set</code>, and <code>Sequence</code>.</li><br />
</ul><br />
<br />
<code>Monoid</code> is also used to enable several other type class instances.<br />
As noted previously, we can use <code>Monoid</code> to make <code>((,) e)</code> an instance of <code>Applicative</code>:<br />
<br />
<haskell><br />
instance Monoid e => Applicative ((,) e) where<br />
pure x = (mempty, x)<br />
(u, f) <*> (v, x) = (u `mappend` v, f x)<br />
</haskell><br />
<br />
<code>Monoid</code> can be similarly used to make <code>((,) e)</code> an instance of <code>Monad</code> as well; this is known as the ''writer monad''. As we’ve already seen, <code>Writer</code> and <code>WriterT</code> are a newtype wrapper and transformer for this monad, respectively.<br />
<br />
<code>Monoid</code> also plays a key role in the <code>Foldable</code> type class (see section [[#Foldable|Foldable]]).<br />
<br />
==Other monoidal classes: Alternative, MonadPlus, ArrowPlus==<br />
<br />
The <code>Alternative</code> type class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html#g:2 haddock])<br />
is for <code>Applicative</code> functors which also have<br />
a monoid structure:<br />
<br />
<haskell><br />
class Applicative f => Alternative f where<br />
empty :: f a<br />
(<|>) :: f a -> f a -> f a<br />
</haskell><br />
<br />
Of course, instances of <code>Alternative</code> should satisfy the monoid laws<br />
<br />
<haskell><br />
empty <|> x = x<br />
x <|> empty = x<br />
(x <|> y) <|> z = x <|> (y <|> z)<br />
</haskell><br />
<br />
Likewise, <code>MonadPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html#t:MonadPlus haddock])<br />
is for <code>Monad</code>s with a monoid structure:<br />
<br />
<haskell><br />
class Monad m => MonadPlus m where<br />
mzero :: m a<br />
mplus :: m a -> m a -> m a<br />
</haskell><br />
<br />
The <code>MonadPlus</code> documentation states that it is intended to model<br />
monads which also support “choice and failure”; in addition to the<br />
monoid laws, instances of <code>MonadPlus</code> are expected to satisfy<br />
<br />
<haskell><br />
mzero >>= f = mzero<br />
v >> mzero = mzero<br />
</haskell><br />
<br />
which explains the sense in which <code>mzero</code> denotes failure. Since<br />
<code>mzero</code> should be the identity for <code>mplus</code>, the computation <code>m1 `mplus` m2</code> succeeds (evaluates to something other than <code>mzero</code>) if<br />
either <code>m1</code> or <code>m2</code> does; so <code>mplus</code> represents choice. The <code>guard</code><br />
function can also be used with instances of <code>MonadPlus</code>; it requires a<br />
condition to be satisfied and fails (using <code>mzero</code>) if it is not. A<br />
simple example of a <code>MonadPlus</code> instance is <code>[]</code>, which is exactly the<br />
same as the <code>Monoid</code> instance for <code>[]</code>: the empty list represents<br />
failure, and list concatenation represents choice. In general,<br />
however, a <code>MonadPlus</code> instance for a type need not be the same as its<br />
<code>Monoid</code> instance; <code>Maybe</code> is an example of such a type. A great<br />
introduction to the <code>MonadPlus</code> type class, with interesting examples<br />
of its use, is Doug Auclair’s ''MonadPlus: What a Super Monad!'' in [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad.Reader issue 11].<br />
<br />
There used to be a type class called <code>MonadZero</code> containing only<br />
<code>mzero</code>, representing monads with failure. The <code>do</code>-notation requires<br />
some notion of failure to deal with failing pattern matches.<br />
Unfortunately, <code>MonadZero</code> was scrapped in favor of adding the <code>fail</code><br />
method to the <code>Monad</code> class. If we are lucky, someday <code>MonadZero</code> will<br />
be restored, and <code>fail</code> will be banished to the bit bucket where it<br />
belongs (see [[MonadPlus reform proposal]]). The idea is that any<br />
<code>do</code>-block which uses pattern matching (and hence may fail) would require<br />
a <code>MonadZero</code> constraint; otherwise, only a <code>Monad</code> constraint would be<br />
required.<br />
<br />
Finally, <code>ArrowZero</code> and <code>ArrowPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#t:ArrowZero haddock])<br />
represent <code>Arrow</code>s ([[#Arrow|see below]]) with a<br />
monoid structure:<br />
<br />
<haskell><br />
class Arrow arr => ArrowZero arr where<br />
zeroArrow :: b `arr` c<br />
<br />
class ArrowZero arr => ArrowPlus arr where<br />
(<+>) :: (b `arr` c) -> (b `arr` c) -> (b `arr` c)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Monoids have gotten a fair bit of attention recently, ultimately due<br />
to<br />
[http://enfranchisedmind.com/blog/posts/random-thoughts-on-haskell/ a blog post by Brian Hurt], in which he<br />
complained about the fact that the names of many Haskell type classes<br />
(<code>Monoid</code> in particular) are taken from abstract mathematics. This<br />
resulted in [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 a long Haskell-cafe thread]<br />
arguing the point and discussing monoids in general.<br />
<br />
{{note|May its name live forever.}}<br />
<br />
However, this was quickly followed by several blog posts about<br />
<code>Monoid</code> {{noteref}}. First, Dan Piponi<br />
wrote a great introductory post, [http://blog.sigfpe.com/2009/01/haskell-monoids-and-their-uses.html Haskell Monoids and their Uses]. This was quickly followed by<br />
Heinrich Apfelmus’s [http://apfelmus.nfshost.com/monoid-fingertree.html Monoids and Finger Trees], an accessible exposition of<br />
Hinze and Paterson’s [http://www.soi.city.ac.uk/%7Eross/papers/FingerTree.html classic paper on 2-3 finger trees], which makes very clever<br />
use of <code>Monoid</code> to implement an elegant and generic data structure.<br />
Dan Piponi then wrote two fascinating articles about using <code>Monoids</code><br />
(and finger trees): [http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html Fast Incremental Regular Expressions] and [http://blog.sigfpe.com/2009/01/beyond-regular-expressions-more.html Beyond Regular Expressions]<br />
<br />
In a similar vein, David Place’s article on improving <code>Data.Map</code> in<br />
order to compute incremental folds (see [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad Reader issue 11])<br />
is also a<br />
good example of using <code>Monoid</code> to generalize a data structure.<br />
<br />
Some other interesting examples of <code>Monoid</code> use include [http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx building elegant list sorting combinators], [http://byorgey.wordpress.com/2008/04/17/collecting-unstructured-information-with-the-monoid-of-partial-knowledge/ collecting unstructured information], [http://izbicki.me/blog/gausian-distributions-are-monoids combining probability distributions], and a brilliant series of posts by Chung-Chieh Shan and Dylan Thurston using <code>Monoid</code>s to [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers1/ elegantly solve a difficult combinatorial puzzle] (followed by [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers2/ part 2], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers3/ part 3], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers4/ part 4]).<br />
<br />
As unlikely as it sounds, monads can actually be viewed as a sort of<br />
monoid, with <code>join</code> playing the role of the binary operation and<br />
<code>return</code> the role of the identity; see [http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html Dan Piponi’s blog post].<br />
<br />
=Foldable=<br />
<br />
The <code>Foldable</code> class, defined in the <code>Data.Foldable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html haddock]), abstracts over containers which can be<br />
“folded” into a summary value. This allows such folding operations<br />
to be written in a container-agnostic way.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Foldable</code> type class is:<br />
<br />
<haskell><br />
class Foldable t where<br />
fold :: Monoid m => t m -> m<br />
foldMap :: Monoid m => (a -> m) -> t a -> m<br />
<br />
foldr :: (a -> b -> b) -> b -> t a -> b<br />
foldl :: (a -> b -> a) -> a -> t b -> a<br />
foldr1 :: (a -> a -> a) -> t a -> a<br />
foldl1 :: (a -> a -> a) -> t a -> a<br />
</haskell><br />
<br />
This may look complicated, but in fact, to make a <code>Foldable</code> instance<br />
you only need to implement one method: your choice of <code>foldMap</code> or<br />
<code>foldr</code>. All the other methods have default implementations in terms<br />
of these, and are presumably included in the class in case more<br />
efficient implementations can be provided.<br />
<br />
==Instances and examples==<br />
<br />
The type of <code>foldMap</code> should make it clear what it is supposed to do:<br />
given a way to convert the data in a container into a <code>Monoid</code> (a<br />
function <code>a -> m</code>) and a container of <code>a</code>’s (<code>t a</code>), <code>foldMap</code><br />
provides a way to iterate over the entire contents of the container,<br />
converting all the <code>a</code>’s to <code>m</code>’s and combining all the <code>m</code>’s with<br />
<code>mappend</code>. The following code shows two examples: a simple<br />
implementation of <code>foldMap</code> for lists, and a binary tree example<br />
provided by the <code>Foldable</code> documentation.<br />
<br />
<haskell><br />
instance Foldable [] where<br />
foldMap g = mconcat . map g<br />
<br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Foldable Tree where<br />
foldMap f Empty = mempty<br />
foldMap f (Leaf x) = f x<br />
foldMap f (Node l k r) = foldMap f l `mappend` f k `mappend` foldMap f r<br />
</haskell><br />
<br />
The <code>foldr</code> function has a type similar to the <code>foldr</code> found in the <code>Prelude</code>, but<br />
more general, since the <code>foldr</code> in the <code>Prelude</code> works only on lists.<br />
<br />
The <code>Foldable</code> module also provides instances for <code>Maybe</code> and <code>Array</code>;<br />
additionally, many of the data structures found in the standard [http://hackage.haskell.org/package/containers containers library] (for example, <code>Map</code>, <code>Set</code>, <code>Tree</code>,<br />
and <code>Sequence</code>) provide their own <code>Foldable</code> instances.<br />
<br />
{{Exercises|<br />
# What is the type of <code>foldMap . foldMap</code>? Or <code>foldMap . foldMap . foldMap</code>, etc.? What do they do?<br />
}}<br />
<br />
==Derived folds==<br />
<br />
Given an instance of <code>Foldable</code>, we can write generic,<br />
container-agnostic functions such as:<br />
<br />
<haskell><br />
-- Compute the size of any container.<br />
containerSize :: Foldable f => f a -> Int<br />
containerSize = getSum . foldMap (const (Sum 1))<br />
<br />
-- Compute a list of elements of a container satisfying a predicate.<br />
filterF :: Foldable f => (a -> Bool) -> f a -> [a]<br />
filterF p = foldMap (\a -> if p a then [a] else [])<br />
<br />
-- Get a list of all the Strings in a container which include the<br />
-- letter a.<br />
aStrings :: Foldable f => f String -> [String]<br />
aStrings = filterF (elem 'a')<br />
</haskell><br />
<br />
The <code>Foldable</code> module also provides a large number of predefined<br />
folds, many of which are generalized versions of <code>Prelude</code> functions of the<br />
same name that only work on lists: <code>concat</code>, <code>concatMap</code>, <code>and</code>,<br />
<code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>),<br />
<code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>.<br />
<br />
The important function <code>toList</code> is also provided, which turns any <code>Foldable</code> structure into a list of its elements in left-right order; it works by folding with the list monoid.<br />
<br />
There are also generic functions that work with <code>Applicative</code> or<br />
<code>Monad</code> instances to generate some sort of computation from each<br />
element in a container, and then perform all the side effects from<br />
those computations, discarding the results: <code>traverse_</code>, <code>sequenceA_</code>,<br />
and others. The results must be discarded because the <code>Foldable</code><br />
class is too weak to specify what to do with them: we cannot, in<br />
general, make an arbitrary <code>Applicative</code> or <code>Monad</code> instance into a <code>Monoid</code>, but we can make <code>m ()</code> into a <code>Monoid</code> for any such <code>m</code>. If we do have an <code>Applicative</code> or <code>Monad</code> with a monoid<br />
structure—that is, an <code>Alternative</code> or a <code>MonadPlus</code>—then we can<br />
use the <code>asum</code> or <code>msum</code> functions, which can combine the results as<br />
well. Consult the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html <code>Foldable</code> documentation] for<br />
more details on any of these functions.<br />
<br />
Note that the <code>Foldable</code> operations always forget the structure of<br />
the container being folded. If we start with a container of type <code>t a</code> for some <code>Foldable t</code>, then <code>t</code> will never appear in the output<br />
type of any operations defined in the <code>Foldable</code> module. Many times<br />
this is exactly what we want, but sometimes we would like to be able<br />
to generically traverse a container while preserving its<br />
structure—and this is exactly what the <code>Traversable</code> class provides,<br />
which will be discussed in the next section.<br />
<br />
{{Exercises|<br />
# Implement <code>toList :: Foldable f {{=}}> f a -> [a]</code>.<br />
# Pick some of the following functions to implement: <code>concat</code>, <code>concatMap</code>, <code>and</code>, <code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>), <code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>. Figure out how they generalize to <code>Foldable</code> and come up with elegant implementations using <code>fold</code> or <code>foldMap</code> along with appropriate <code>Monoid</code> instances.<br />
}}<br />
<br />
==Foldable actually isn't==<br />
<br />
The generic term "fold" is often used to refer to the more technical concept of [[Catamorphisms|catamorphism]]. Intuitively, given a way to summarize "one level of structure" (where recursive subterms have already been replaced with their summaries), a catamorphism can summarize an entire recursive structure. It is important to realize that <code>Foldable</code> does <i>not</i> correspond to catamorphisms, but to something weaker. In particular, <code>Foldable</code> allows observing only the left-right order of elements within a structure, not the actual structure itself. Put another way, every use of <code>Foldable</code> can be expressed in terms of <code>toList</code>. For example, <code>fold</code> itself is equivalent to <code>mconcat . toList</code>.<br />
<br />
This is sufficient for many tasks, but not all. For example, consider trying to compute the depth of a <code>Tree</code>: try as we might, there is no way to implement it using <code>Foldable</code>. However, it <i>can</i> be implemented as a catamorphism.<br />
<br />
==Further reading==<br />
<br />
The <code>Foldable</code> class had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s paper]<br />
introducing <code>Applicative</code>, although it has<br />
been fleshed out quite a bit from the form in the paper.<br />
<br />
An interesting use of <code>Foldable</code> (as well as <code>Traversable</code>) can be<br />
found in Janis Voigtländer’s paper [http://doi.acm.org/10.1145/1480881.1480904 Bidirectionalization for free!].<br />
<br />
=Traversable=<br />
<br />
==Definition==<br />
<br />
The <code>Traversable</code> type class, defined in the <code>Data.Traversable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html haddock]), is:<br />
<br />
<haskell><br />
class (Functor t, Foldable t) => Traversable t where<br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
mapM :: Monad m => (a -> m b) -> t a -> m (t b)<br />
sequence :: Monad m => t (m a) -> m (t a)<br />
</haskell><br />
<br />
As you can see, every <code>Traversable</code> is also a foldable functor. Like<br />
<code>Foldable</code>, there is a lot in this type class, but making instances is<br />
actually rather easy: one need only implement <code>traverse</code> or<br />
<code>sequenceA</code>; the other methods all have default implementations in<br />
terms of these functions. A good exercise is to figure out what the default<br />
implementations should be: given either <code>traverse</code> or <code>sequenceA</code>, how<br />
would you define the other three methods? (Hint for <code>mapM</code>:<br />
<code>Control.Applicative</code> exports the <code>WrapMonad</code> newtype, which makes any<br />
<code>Monad</code> into an <code>Applicative</code>. The <code>sequence</code> function can be implemented in terms<br />
of <code>mapM</code>.)<br />
<br />
==Intuition==<br />
<br />
The key method of the <code>Traversable</code> class, and the source of its<br />
unique power, is <code>sequenceA</code>. Consider its type:<br />
<haskell><br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
</haskell><br />
This answers the fundamental question: when can we commute two<br />
functors? For example, can we turn a tree of lists into a list of<br />
trees?<br />
<br />
The ability to compose two monads depends crucially on this ability to<br />
commute functors. Intuitively, if we want to build a composed monad<br />
<code>M a = m (n a)</code> out of monads <code>m</code> and <code>n</code>, then to be able to<br />
implement <code>join :: M (M a) -> M a</code>, that is,<br />
<code>join :: m (n (m (n a))) -> m (n a)</code>, we have to be able to commute<br />
the <code>n</code> past the <code>m</code> to get <code>m (m (n (n a)))</code>, and then we can use the<br />
<code>join</code>s for <code>m</code> and <code>n</code> to produce something of type <code>m (n a)</code>. See<br />
[http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Mark Jones’s paper] for more details.<br />
<br />
Alternatively, looking at the type of <code>traverse</code>,<br />
<haskell><br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
</haskell><br />
leads us to view <code>Traversable</code> as a generalization of <code>Functor</code>. <code>traverse</code> is an "effectful <code>fmap</code>": it allows us to map over a structure of type <code>t a</code>, applying a function to every element of type <code>a</code> and in order to produce a new structure of type <code>t b</code>; but along the way the function may have some effects (captured by the applicative functor <code>f</code>).<br />
<br />
{{Exercises|<br />
# There are at least two natural ways to turn a tree of lists into a list of trees. What are they, and why?<br />
# Give a natural way to turn a list of trees into a tree of lists.<br />
# What is the type of <code>traverse . traverse</code>? What does it do?<br />
}}<br />
<br />
==Instances and examples==<br />
<br />
What’s an example of a <code>Traversable</code> instance?<br />
The following code shows an example instance for the same<br />
<code>Tree</code> type used as an example in the previous <code>Foldable</code> section. It<br />
is instructive to compare this instance with a <code>Functor</code> instance for<br />
<code>Tree</code>, which is also shown.<br />
<br />
<haskell><br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Traversable Tree where<br />
traverse g Empty = pure Empty<br />
traverse g (Leaf x) = Leaf <$> g x<br />
traverse g (Node l x r) = Node <$> traverse g l<br />
<*> g x<br />
<*> traverse g r<br />
<br />
instance Functor Tree where<br />
fmap g Empty = Empty<br />
fmap g (Leaf x) = Leaf $ g x<br />
fmap g (Node l x r) = Node (fmap g l)<br />
(g x)<br />
(fmap g r)<br />
</haskell><br />
<br />
It should be clear that the <code>Traversable</code> and <code>Functor</code> instances for<br />
<code>Tree</code> are almost identical; the only difference is that the <code>Functor</code><br />
instance involves normal function application, whereas the<br />
applications in the <code>Traversable</code> instance take place within an<br />
<code>Applicative</code> context, using <code>(<$>)</code> and <code>(<*>)</code>. In fact, this will<br />
be<br />
true for any type.<br />
<br />
Any <code>Traversable</code> functor is also <code>Foldable</code>, and a <code>Functor</code>. We can see<br />
this not only from the class declaration, but by the fact that we can<br />
implement the methods of both classes given only the <code>Traversable</code><br />
methods.<br />
<br />
The standard libraries provide a number of <code>Traversable</code> instances,<br />
including instances for <code>[]</code>, <code>Maybe</code>, <code>Map</code>, <code>Tree</code>, and <code>Sequence</code>.<br />
Notably, <code>Set</code> is not <code>Traversable</code>, although it is <code>Foldable</code>.<br />
<br />
{{Exercises|<br />
# Implement <code>fmap</code> and <code>foldMap</code> using only the <code>Traversable</code> methods. (Note that the <code>Traversable</code> module provides these implementations as <code>fmapDefault</code> and <code>foldMapDefault</code>.)<br />
}}<br />
<br />
==Laws==<br />
<br />
Any instance of <code>Traversable</code> must satisfy the following two laws, where <code>Identity</code> is the identity functor (as defined in the [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Data-Functor-Identity.html <code>Data.Functor.Identity</code> module] from the <code>transformers</code> package), and <code>Compose</code> wraps the composition of two functors (as defined in [http://hackage.haskell.org/packages/archive/transformers/0.3.0.0/doc/html/Data-Functor-Compose.html <code>Data.Functor.Compose</code>]):<br />
<br />
# <code>traverse Identity = Identity</code><br />
# <code>traverse (Compose . fmap g . f) = Compose . fmap (traverse g) . traverse f</code><br />
<br />
The first law essentially says that traversals cannot make up arbitrary effects. The second law explains how doing two traversals in sequence can be collapsed to a single traversal.<br />
<br />
Additionally, suppose <code>eta</code> is an "<code>Applicative</code> morphism", that is,<br />
<haskell><br />
eta :: forall a f g. (Applicative f, Applicative g) => f a -> g a<br />
</haskell><br />
and <code>eta</code> preserves the <code>Applicative</code> operations: <code>eta (pure x) = pure x</code> and <code>eta (x <*> y) = eta x <*> eta y</code>. Then, by parametricity, any instance of <code>Traversable</code> satisfying the above two laws will also satisfy <code>eta . traverse f = traverse (eta . f)</code>.<br />
<br />
==Further reading==<br />
<br />
The <code>Traversable</code> class also had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s <code>Applicative</code> paper],<br />
and is described in more detail in Gibbons and Oliveira, [http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf The Essence of the Iterator Pattern],<br />
which also contains a wealth of references to related work.<br />
<br />
<code>Traversable</code> forms a core component of Edward Kmett's [http://hackage.haskell.org/package/lens lens library]. Watching [https://vimeo.com/56063074 Edward's talk on the subject] is a highly recommended way to gain better insight into <code>Traversable</code>, <code>Foldable</code>, <code>Applicative</code>, and many other things besides.<br />
<br />
For references on the <code>Traversable</code> laws, see Russell O'Connor's [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17778 mailing list post] (and subsequent thread).<br />
<br />
=Category=<br />
<br />
<code>Category</code> is a relatively recent addition to the Haskell standard libraries. It generalizes the notion of function composition to general “morphisms”.<br />
<br />
{{note|GHC 7.6.1 changed its rules regarding types and type variables. Now, any operator at the type level is treated as a type ''constructor'' rather than a type ''variable''; prior to GHC 7.6.1 it was possible to use <code>(~&gt;)</code> instead of <code>`arr`</code>. For more information, see [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/21350 the discussion on the GHC-users mailing list]. For a new approach to nice arrow notation that works with GHC 7.6.1, see [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22615 this message] and also [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22616 this message] from Edward Kmett, though for simplicity I haven't adopted it here.}}<br />
The definition of the <code>Category</code> type class (from<br />
<code>Control.Category</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Category.html haddock]) is shown below. For ease of reading, note that I have used an infix type variable <code>`arr`</code>, in parallel with the infix function type constructor <code>(->)</code>. {{noteref}} This syntax is not part of Haskell 2010. The second definition shown is the one used in the standard libraries. For the remainder of this document, I will use the infix type constructor <code>`arr`</code> for <code>Category</code> as well as <code>Arrow</code>.<br />
<br />
<haskell><br />
class Category arr where<br />
id :: a `arr` a<br />
(.) :: (b `arr` c) -> (a `arr` b) -> (a `arr` c)<br />
<br />
-- The same thing, with a normal (prefix) type constructor<br />
class Category cat where<br />
id :: cat a a<br />
(.) :: cat b c -> cat a b -> cat a c<br />
</haskell><br />
<br />
Note that an instance of <code>Category</code> should be a type constructor which takes two type arguments, that is, something of kind <code>* -> * -> *</code>. It is instructive to imagine the type constructor variable <code>cat</code> replaced by the function constructor <code>(->)</code>: indeed, in this case we recover precisely the familiar identity function <code>id</code> and function composition operator <code>(.)</code> defined in the standard <code>Prelude</code>.<br />
<br />
Of course, the <code>Category</code> module provides exactly such an instance of<br />
<code>Category</code> for <code>(->)</code>. But it also provides one other instance, shown below, which should be familiar from the previous discussion of the <code>Monad</code> laws. <code>Kleisli m a b</code>, as defined in the <code>Control.Arrow</code> module, is just a <code>newtype</code> wrapper around <code>a -> m b</code>.<br />
<br />
<haskell><br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Category (Kleisli m) where<br />
id = Kleisli return<br />
Kleisli g . Kleisli h = Kleisli (h >=> g)<br />
</haskell><br />
<br />
The only law that <code>Category</code> instances should satisfy is that <code>id</code> and <code>(.)</code> should form a monoid—that is, <code>id</code> should be the identity of <code>(.)</code>, and <code>(.)</code> should be associative.<br />
<br />
Finally, the <code>Category</code> module exports two additional operators:<br />
<code>(<<<)</code>, which is just a synonym for <code>(.)</code>, and <code>(>>>)</code>, which is <code>(.)</code> with its arguments reversed. (In previous versions of the libraries, these operators were defined as part of the <code>Arrow</code> class.)<br />
<br />
==Further reading==<br />
<br />
The name <code>Category</code> is a bit misleading, since the <code>Category</code> class cannot represent arbitrary categories, but only categories whose objects are objects of <code>Hask</code>, the category of Haskell types. For a more general treatment of categories within Haskell, see the [http://hackage.haskell.org/package/category-extras category-extras package]. For more about category theory in general, see the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page],<br />
[http://books.google.com/books/about/Category_theory.html?id=-MCJ6x2lC7oC Steve Awodey’s new book], Benjamin Pierce’s [http://books.google.com/books/about/Basic_category_theory_for_computer_scien.html?id=ezdeaHfpYPwC Basic category theory for computer scientists], or [http://folli.loria.fr/cds/1999/esslli99/courses/barr-wells.html Barr and Wells’s category theory lecture notes]. [http://dekudekuplex.wordpress.com/2009/01/19/motivating-learning-category-theory-for-non-mathematicians/ Benjamin Russell’s blog post]<br />
is another good source of motivation and category theory links. You certainly don’t need to know any category theory to be a successful and productive Haskell programmer, but it does lend itself to much deeper appreciation of Haskell’s underlying theory.<br />
<br />
=Arrow=<br />
<br />
The <code>Arrow</code> class represents another abstraction of computation, in a<br />
similar vein to <code>Monad</code> and <code>Applicative</code>. However, unlike <code>Monad</code><br />
and <code>Applicative</code>, whose types only reflect their output, the type of<br />
an <code>Arrow</code> computation reflects both its input and output. Arrows<br />
generalize functions: if <code>arr</code> is an instance of <code>Arrow</code>, a value of<br />
type <code>b `arr` c</code> can be thought of as a computation which takes values of<br />
type <code>b</code> as input, and produces values of type <code>c</code> as output. In the<br />
<code>(->)</code> instance of <code>Arrow</code> this is just a pure function; in general, however,<br />
an arrow may represent some sort of “effectful” computation.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Arrow</code> type class, from<br />
<code>Control.Arrow</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html haddock]), is:<br />
<br />
<haskell><br />
class Category arr => Arrow arr where<br />
arr :: (b -> c) -> (b `arr` c)<br />
first :: (b `arr` c) -> ((b, d) `arr` (c, d))<br />
second :: (b `arr` c) -> ((d, b) `arr` (d, c))<br />
(***) :: (b `arr` c) -> (b' `arr` c') -> ((b, b') `arr` (c, c'))<br />
(&&&) :: (b `arr` c) -> (b `arr` c') -> (b `arr` (c, c'))<br />
</haskell><br />
<br />
{{note|In versions of the <code>base</code><br />
package prior to version 4, there is no <code>Category</code> class, and the<br />
<code>Arrow</code> class includes the arrow composition operator <code>(>>>)</code>. It<br />
also includes <code>pure</code> as a synonym for <code>arr</code>, but this was removed<br />
since it conflicts with the <code>pure</code> from <code>Applicative</code>.}}<br />
<br />
The first thing to note is the <code>Category</code> class constraint, which<br />
means that we get identity arrows and arrow composition for free:<br />
given two arrows <code>g :: b `arr` c</code> and <code>h :: c `arr` d</code>, we can form their<br />
composition <code>g >>> h :: b `arr` d</code> {{noteref}}.<br />
<br />
As should be a familiar pattern by now, the only methods which must be<br />
defined when writing a new instance of <code>Arrow</code> are <code>arr</code> and <code>first</code>;<br />
the other methods have default definitions in terms of these, but are<br />
included in the <code>Arrow</code> class so that they can be overridden with more<br />
efficient implementations if desired.<br />
<br />
==Intuition==<br />
<br />
Let’s look at each of the arrow methods in turn. [http://www.haskell.org/arrows/ Ross Paterson’s web page on arrows] has nice diagrams which can help<br />
build intuition.<br />
<br />
* The <code>arr</code> function takes any function <code>b -> c</code> and turns it into a generalized arrow <code>b `arr` c</code>. The <code>arr</code> method justifies the claim that arrows generalize functions, since it says that we can treat any function as an arrow. It is intended that the arrow <code>arr g</code> is “pure” in the sense that it only computes <code>g</code> and has no “effects” (whatever that might mean for any particular arrow type).<br />
<br />
* The <code>first</code> method turns any arrow from <code>b</code> to <code>c</code> into an arrow from <code>(b,d)</code> to <code>(c,d)</code>. The idea is that <code>first g</code> uses <code>g</code> to process the first element of a tuple, and lets the second element pass through unchanged. For the function instance of <code>Arrow</code>, of course, <code>first g (x,y) = (g x, y)</code>.<br />
<br />
* The <code>second</code> function is similar to <code>first</code>, but with the elements of the tuples swapped. Indeed, it can be defined in terms of <code>first</code> using an auxiliary function <code>swap</code>, defined by <code>swap (x,y) = (y,x)</code>.<br />
<br />
* The <code>(***)</code> operator is “parallel composition” of arrows: it takes two arrows and makes them into one arrow on tuples, which has the behavior of the first arrow on the first element of a tuple, and the behavior of the second arrow on the second element. The mnemonic is that <code>g *** h</code> is the ''product'' (hence <code>*</code>) of <code>g</code> and <code>h</code>. For the function instance of <code>Arrow</code>, we define <code>(g *** h) (x,y) = (g x, h y)</code>. The default implementation of <code>(***)</code> is in terms of <code>first</code>, <code>second</code>, and sequential arrow composition <code>(>>>)</code>. The reader may also wish to think about how to implement <code>first</code> and <code>second</code> in terms of <code>(***)</code>.<br />
<br />
* The <code>(&&&)</code> operator is “fanout composition” of arrows: it takes two arrows <code>g</code> and <code>h</code> and makes them into a new arrow <code>g &&& h</code> which supplies its input as the input to both <code>g</code> and <code>h</code>, returning their results as a tuple. The mnemonic is that <code>g &&& h</code> performs both <code>g</code> ''and'' <code>h</code> (hence <code>&</code>) on its input. For functions, we define <code>(g &&& h) x = (g x, h x)</code>.<br />
<br />
==Instances==<br />
<br />
The <code>Arrow</code> library itself only provides two <code>Arrow</code> instances, both<br />
of which we have already seen: <code>(->)</code>, the normal function<br />
constructor, and <code>Kleisli m</code>, which makes functions of<br />
type <code>a -> m b</code> into <code>Arrow</code>s for any <code>Monad m</code>. These instances are:<br />
<br />
<haskell><br />
instance Arrow (->) where<br />
arr g = g<br />
first g (x,y) = (g x, y)<br />
<br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Arrow (Kleisli m) where<br />
arr f = Kleisli (return . f)<br />
first (Kleisli f) = Kleisli (\ ~(b,d) -> do c <- f b<br />
return (c,d) )<br />
</haskell><br />
<br />
==Laws==<br />
<br />
{{note|See [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 John Hughes: Generalising monads to arrows]; [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf Sam Lindley, Philip Wadler, Jeremy Yallop: The arrow calculus]; [http://www.soi.city.ac.uk/~ross/papers/fop.html Ross Paterson: Programming with Arrows].}}<br />
<br />
There are quite a few laws that instances of <code>Arrow</code> should<br />
satisfy {{noteref}}:<br />
<br />
<haskell><br />
arr id = id<br />
arr (h . g) = arr g >>> arr h<br />
first (arr g) = arr (g *** id)<br />
first (g >>> h) = first g >>> first h<br />
first g >>> arr (id *** h) = arr (id *** h) >>> first g<br />
first g >>> arr fst = arr fst >>> g<br />
first (first g) >>> arr assoc = arr assoc >>> first g<br />
<br />
assoc ((x,y),z) = (x,(y,z))<br />
</haskell><br />
<br />
Note that this version of the laws is slightly different than the laws given in the<br />
first two above references, since several of the laws have now been<br />
subsumed by the <code>Category</code> laws (in particular, the requirements that<br />
<code>id</code> is the identity arrow and that <code>(>>>)</code> is associative). The laws<br />
shown here follow those in Paterson’s Programming with Arrows, which uses the<br />
<code>Category</code> class.<br />
<br />
{{note|Unless category-theory-induced insomnolence is your cup of tea.}}<br />
<br />
The reader is advised not to lose too much sleep over the <code>Arrow</code><br />
laws {{noteref}}, since it is not essential to understand them in order to<br />
program with arrows. There are also laws that <code>ArrowChoice</code>,<br />
<code>ArrowApply</code>, and <code>ArrowLoop</code> instances should satisfy; the interested<br />
reader should consult [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows].<br />
<br />
==ArrowChoice==<br />
<br />
Computations built using the <code>Arrow</code> class, like those built using<br />
the <code>Applicative</code> class, are rather inflexible: the structure of the computation<br />
is fixed at the outset, and there is no ability to choose between<br />
alternate execution paths based on intermediate results.<br />
The <code>ArrowChoice</code> class provides exactly such an ability:<br />
<br />
<haskell><br />
class Arrow arr => ArrowChoice arr where<br />
left :: (b `arr` c) -> (Either b d `arr` Either c d)<br />
right :: (b `arr` c) -> (Either d b `arr` Either d c)<br />
(+++) :: (b `arr` c) -> (b' `arr` c') -> (Either b b' `arr` Either c c')<br />
(|||) :: (b `arr` d) -> (c `arr` d) -> (Either b c `arr` d)<br />
</haskell><br />
<br />
A comparison of <code>ArrowChoice</code> to <code>Arrow</code> will reveal a striking<br />
parallel between <code>left</code>, <code>right</code>, <code>(+++)</code>, <code>(|||)</code> and <code>first</code>,<br />
<code>second</code>, <code>(***)</code>, <code>(&&&)</code>, respectively. Indeed, they are dual:<br />
<code>first</code>, <code>second</code>, <code>(***)</code>, and <code>(&&&)</code> all operate on product types<br />
(tuples), and <code>left</code>, <code>right</code>, <code>(+++)</code>, and <code>(|||)</code> are the<br />
corresponding operations on sum types. In general, these operations<br />
create arrows whose inputs are tagged with <code>Left</code> or <code>Right</code>, and can<br />
choose how to act based on these tags.<br />
<br />
* If <code>g</code> is an arrow from <code>b</code> to <code>c</code>, then <code>left g</code> is an arrow from <code>Either b d</code> to <code>Either c d</code>. On inputs tagged with <code>Left</code>, the <code>left g</code> arrow has the behavior of <code>g</code>; on inputs tagged with <code>Right</code>, it behaves as the identity.<br />
<br />
* The <code>right</code> function, of course, is the mirror image of <code>left</code>. The arrow <code>right g</code> has the behavior of <code>g</code> on inputs tagged with <code>Right</code>.<br />
<br />
* The <code>(+++)</code> operator performs “multiplexing”: <code>g +++ h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and as <code>h</code> on inputs tagged with <code>Right</code>. The tags are preserved. The <code>(+++)</code> operator is the ''sum'' (hence <code>+</code>) of two arrows, just as <code>(***)</code> is the product.<br />
<br />
* The <code>(|||)</code> operator is “merge” or “fanin”: the arrow <code>g ||| h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and <code>h</code> on inputs tagged with <code>Right</code>, but the tags are discarded (hence, <code>g</code> and <code>h</code> must have the same output type). The mnemonic is that <code>g ||| h</code> performs either <code>g</code> ''or'' <code>h</code> on its input.<br />
<br />
The <code>ArrowChoice</code> class allows computations to choose among a finite number of execution paths, based on intermediate results. The possible<br />
execution paths must be known in advance, and explicitly assembled with <code>(+++)</code> or <code>(|||)</code>. However, sometimes more flexibility is<br />
needed: we would like to be able to ''compute'' an arrow from intermediate results, and use this computed arrow to continue the computation. This is the power given to us by <code>ArrowApply</code>.<br />
<br />
==ArrowApply==<br />
<br />
The <code>ArrowApply</code> type class is:<br />
<br />
<haskell><br />
class Arrow arr => ArrowApply arr where<br />
app :: (b `arr` c, b) `arr` c<br />
</haskell><br />
<br />
If we have computed an arrow as the output of some previous<br />
computation, then <code>app</code> allows us to apply that arrow to an input,<br />
producing its output as the output of <code>app</code>. As an exercise, the<br />
reader may wish to use <code>app</code> to implement an alternative “curried”<br />
version, <code>app2 :: b `arr` ((b `arr` c) `arr` c)</code>.<br />
<br />
This notion of being able to ''compute'' a new computation<br />
may sound familiar:<br />
this is exactly what the monadic bind operator <code>(>>=)</code> does. It<br />
should not particularly come as a surprise that <code>ArrowApply</code> and<br />
<code>Monad</code> are exactly equivalent in expressive power. In particular,<br />
<code>Kleisli m</code> can be made an instance of <code>ArrowApply</code>, and any instance<br />
of <code>ArrowApply</code> can be made a <code>Monad</code> (via the <code>newtype</code> wrapper<br />
<code>ArrowMonad</code>). As an exercise, the reader may wish to try<br />
implementing these instances:<br />
<br />
<haskell><br />
instance Monad m => ArrowApply (Kleisli m) where<br />
app = -- exercise<br />
<br />
newtype ArrowApply a => ArrowMonad a b = ArrowMonad (a () b)<br />
<br />
instance ArrowApply a => Monad (ArrowMonad a) where<br />
return = -- exercise<br />
(ArrowMonad a) >>= k = -- exercise<br />
</haskell><br />
<br />
==ArrowLoop==<br />
<br />
The <code>ArrowLoop</code> type class is:<br />
<br />
<haskell><br />
class Arrow a => ArrowLoop a where<br />
loop :: a (b, d) (c, d) -> a b c<br />
<br />
trace :: ((b,d) -> (c,d)) -> b -> c<br />
trace f b = let (c,d) = f (b,d) in c<br />
</haskell><br />
<br />
It describes arrows that can use recursion to compute results, and is<br />
used to desugar the <code>rec</code> construct in arrow notation (described<br />
below).<br />
<br />
Taken by itself, the type of the <code>loop</code> method does not seem to tell<br />
us much. Its intention, however, is a generalization of the <code>trace</code><br />
function which is also shown. The <code>d</code> component of the first arrow’s<br />
output is fed back in as its own input. In other words, the arrow<br />
<code>loop g</code> is obtained by recursively “fixing” the second component of<br />
the input to <code>g</code>.<br />
<br />
It can be a bit difficult to grok what the <code>trace</code> function is doing.<br />
How can <code>d</code> appear on the left and right sides of the <code>let</code>? Well,<br />
this is Haskell’s laziness at work. There is not space here for a<br />
full explanation; the interested reader is encouraged to study the<br />
standard <code>fix</code> function, and to read [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson’s arrow tutorial].<br />
<br />
==Arrow notation==<br />
<br />
Programming directly with the arrow combinators can be painful,<br />
especially when writing complex computations which need to retain<br />
simultaneous reference to a number of intermediate results. With<br />
nothing but the arrow combinators, such intermediate results must be<br />
kept in nested tuples, and it is up to the programmer to remember<br />
which intermediate results are in which components, and to swap,<br />
reassociate, and generally mangle tuples as necessary. This problem<br />
is solved by the special arrow notation supported by GHC, similar to<br />
<code>do</code> notation for monads, that allows names to be assigned to<br />
intermediate results while building up arrow computations. An example<br />
arrow implemented using arrow notation, taken from<br />
Paterson, is:<br />
<br />
<haskell><br />
class ArrowLoop arr => ArrowCircuit arr where<br />
delay :: b -> (b `arr` b)<br />
<br />
counter :: ArrowCircuit arr => Bool `arr` Int<br />
counter = proc reset -> do<br />
rec output <- idA -< if reset then 0 else next<br />
next <- delay 0 -< output + 1<br />
idA -< output<br />
</haskell><br />
<br />
This arrow is intended to<br />
represent a recursively defined counter circuit with a reset line.<br />
<br />
There is not space here for a full explanation of arrow notation; the<br />
interested reader should consult<br />
[http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper introducing the notation], or his later [http://www.soi.city.ac.uk/~ross/papers/fop.html tutorial which presents a simplified version].<br />
<br />
==Further reading==<br />
<br />
An excellent starting place for the student of arrows is the [http://www.haskell.org/arrows/ arrows web page], which contains an<br />
introduction and many references. Some key papers on arrows include<br />
Hughes’s original paper introducing arrows, [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 Generalising monads to arrows], and [http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper on arrow notation].<br />
<br />
Both Hughes and Paterson later wrote accessible tutorials intended for a broader<br />
audience: [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows] and [http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf Hughes: Programming with Arrows].<br />
<br />
Although Hughes’s goal in defining the <code>Arrow</code> class was to<br />
generalize <code>Monad</code>s, and it has been said that <code>Arrow</code> lies “between<br />
<code>Applicative</code> and <code>Monad</code>” in power, they are not directly<br />
comparable. The precise relationship remained in some confusion until<br />
[http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf analyzed by Lindley, Wadler, and Yallop], who<br />
also invented a new calculus of arrows, based on the lambda calculus,<br />
which considerably simplifies the presentation of the arrow laws<br />
(see [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf The arrow calculus]). There is also a precise technical sense in which [http://just-bottom.blogspot.de/2010/04/programming-with-effects-story-so-far.html <code>Arrow</code> can be seen as the intersection of <code>Applicative</code> and <code>Category</code>].<br />
<br />
Some examples of <code>Arrow</code>s include [http://www.haskell.org/yampa/ Yampa], the<br />
[http://www.fh-wedel.de/~si/HXmlToolbox/ Haskell XML Toolkit], and the functional GUI library [[Grapefruit]].<br />
<br />
Some extensions to arrows have been explored; for example, the<br />
<code>BiArrow</code>s of Alimarine et al. (["There and Back Again: Arrows for Invertible Programming"](http://wiki.clean.cs.ru.nl/download/papers/2005/alia2005-biarrowsHaskellWorkshop.pdf)], for two-way instead of one-way<br />
computation.<br />
<br />
The Haskell wiki has [[Research papers/Monads and Arrows|links to many additional research papers relating to <code>Arrow</code>s]].<br />
<br />
=Comonad=<br />
<br />
The final type class we will examine is <code>Comonad</code>. The <code>Comonad</code> class<br />
is the categorical dual of <code>Monad</code>; that is, <code>Comonad</code> is like <code>Monad</code><br />
but with all the function arrows flipped. It is not actually in the<br />
standard Haskell libraries, but it has seen some interesting uses<br />
recently, so we include it here for completeness.<br />
<br />
==Definition==<br />
<br />
The <code>Comonad</code> type class, defined in the <code>Control.Comonad</code> module of<br />
the [http://hackage.haskell.org/package/comonad comonad library], is:<br />
<br />
<haskell><br />
class Functor w => Comonad w where<br />
extract :: w a -> a<br />
<br />
duplicate :: w a -> w (w a)<br />
duplicate = extend id<br />
<br />
extend :: (w a -> b) -> w a -> w b<br />
extend f = fmap f . duplicate<br />
</haskell><br />
<br />
As you can see, <code>extract</code> is the dual of <code>return</code>, <code>duplicate</code> is the dual of <code>join</code>, and <code>extend</code> is the dual of <code>(=<<)</code>. The definition of <code>Comonad</code> is a bit redundant, giving the programmer the choice on whether extend or duplicate are implemented; the other operation then has a default implementation.<br />
<br />
A prototypical example of a <code>Comonad</code> instance is:<br />
<br />
<haskell><br />
-- Infinite lazy streams<br />
data Stream a = Cons a (Stream a)<br />
<br />
-- 'duplicate' is like the list function 'tails'<br />
-- 'extend' computes a new Stream from an old, where the element<br />
-- at position n is computed as a function of everything from<br />
-- position n onwards in the old Stream<br />
instance Comonad Stream where<br />
extract (Cons x _) = x<br />
duplicate s@(Cons x xs) = Cons s (duplicate xs)<br />
extend g s@(Cons x xs) = Cons (g s) (extend g xs)<br />
-- = fmap g (duplicate s)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Dan Piponi explains in a blog post what [http://blog.sigfpe.com/2006/12/evaluating-cellular-automata-is.html cellular automata have to do with comonads]. In another blog post, Conal Elliott has examined [http://conal.net/blog/posts/functional-interactive-behavior/ a comonadic formulation of functional reactive programming]. Sterling Clover’s blog post [http://fmapfixreturn.wordpress.com/2008/07/09/comonads-in-everyday-life/ Comonads in everyday life] explains the relationship between comonads and zippers, and how comonads can be used to design a menu system for a web site.<br />
<br />
Uustalu and Vene have a number of papers exploring ideas related to comonads and functional programming:<br />
* [http://dx.doi.org/10.1016/j.entcs.2008.05.029 Comonadic Notions of Computation]<br />
* [http://www.ioc.ee/~tarmo/papers/sfp01-book.pdf The dual of substitution is redecoration] (Also available as [http://www.cs.ut.ee/~varmo/papers/sfp01-book.ps.gz ps.gz].)<br />
* [http://dx.doi.org/10.1016/j.ic.2005.08.005 Recursive coalgebras from comonads]<br />
* [http://www.fing.edu.uy/~pardo/papers/njc01.ps.gz Recursion schemes from comonads]<br />
* [http://cs.ioc.ee/~tarmo/papers/essence.pdf The Essence of Dataflow Programming].<br />
<br />
Gabriel Gonzalez's [http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html Comonads are objects] points out similarities between comonads and object-oriented programming.<br />
<br />
The [http://hackage.haskell.org/package/comonad-transformers comonad-transformers] package contains comonad transformers.<br />
<br />
=Acknowledgements=<br />
<br />
A special thanks to all of those who taught me about standard Haskell<br />
type classes and helped me develop good intuition for them,<br />
particularly Jules Bean (quicksilver), Derek Elkins (ddarius), Conal<br />
Elliott (conal), Cale Gibbard (Cale), David House, Dan Piponi<br />
(sigfpe), and Kevin Reid (kpreid).<br />
<br />
I also thank the many people who provided a mountain of helpful<br />
feedback and suggestions on a first draft of the Typeclassopedia: David Amos,<br />
Kevin Ballard, Reid Barton, Doug Beardsley, Joachim Breitner, Andrew<br />
Cave, David Christiansen, Gregory Collins, Mark Jason Dominus, Conal<br />
Elliott, Yitz Gale, George Giorgidze, Steven Grady, Travis Hartwell,<br />
Steve Hicks, Philip Hölzenspies, Edward Kmett, Eric Kow, Serge Le<br />
Huitouze, Felipe Lessa, Stefan Ljungstrand, Eric Macaulay, Rob MacAulay, Simon Meier,<br />
Eric Mertens, Tim Newsham, Russell O’Connor, Conrad Parker, Walt<br />
Rorie-Baety, Colin Ross, Tom Schrijvers, Aditya Siram, C. Smith,<br />
Martijn van Steenbergen, Joe Thornber, Jared Updike, Rob Vollmert,<br />
Andrew Wagner, Louis Wasserman, and Ashley Yakeley, as well as a few<br />
only known to me by their IRC nicks: b_jonas, maltem, tehgeekmeister,<br />
and ziman. I have undoubtedly omitted a few inadvertently, which in<br />
no way diminishes my gratitude.<br />
<br />
Finally, I would like to thank Wouter Swierstra for his fantastic work<br />
editing the Monad.Reader, and my wife Joyia for her patience during<br />
the process of writing the Typeclassopedia.<br />
<br />
=About the author=<br />
<br />
Brent Yorgey ([http://byorgey.wordpress.com/ blog], [http://www.cis.upenn.edu/~byorgey/ homepage]) is (as of November 2011) a fourth-year Ph.D. student in the [http://www.cis.upenn.edu/~plclub/ programming languages group] at the [http://www.upenn.edu University of Pennsylvania]. He enjoys teaching, creating EDSLs, playing Bach fugues, musing upon category theory, and cooking tasty lambda-treats for the denizens of #haskell.<br />
<br />
=Colophon=<br />
<br />
The Typeclassopedia was written by Brent Yorgey and initially published in March 2009. Painstakingly converted to wiki syntax by [[User:Geheimdienst]] in November 2011, after asking Brent’s permission.<br />
<br />
If something like this TeX to wiki syntax conversion ever needs to be done again, here are some vim commands that helped:<br />
<br />
* <nowiki>%s/\\section{\([^}]*\)}/=\1=/gc</nowiki><br />
* <nowiki>%s/\\subsection{\([^}]*\)}/==\1==/gc</nowiki><br />
* <nowiki>%s/^ *\\item /\r* /gc</nowiki><br />
* <nowiki>%s/---/—/gc</nowiki><br />
* <nowiki>%s/\$\([^$]*\)\$/<math>\1\\ <\/math>/gc</nowiki> ''Appending “\ ” forces images to be rendered. Otherwise, Mediawiki would go back and forth between one font for short <nowiki><math></nowiki> tags, and another more Tex-like font for longer tags (containing more than a few characters)""<br />
* <nowiki>%s/|\([^|]*\)|/<code>\1<\/code>/gc</nowiki><br />
* <nowiki>%s/\\dots/.../gc</nowiki><br />
* <nowiki>%s/^\\label{.*$//gc</nowiki><br />
* <nowiki>%s/\\emph{\([^}]*\)}/''\1''/gc</nowiki><br />
* <nowiki>%s/\\term{\([^}]*\)}/''\1''/gc</nowiki><br />
<br />
The biggest issue was taking the academic-paper-style citations and turning them into hyperlinks with an appropriate title and an appropriate target. In most cases there was an obvious thing to do (e.g. online PDFs of the cited papers or CiteSeer entries). Sometimes, however, it’s less clear and you might want to check the<br />
[[Media:Typeclassopedia.pdf|original Typeclassopedia PDF]]<br />
with the<br />
[http://code.haskell.org/~byorgey/TMR/Issue13/typeclassopedia.bib original bibliography file].<br />
<br />
To get all the citations into the main text, I first tried processing the source with TeX or Lyx. This didn’t work due to missing unfindable packages, syntax errors, and my general ineptitude with Tex.<br />
<br />
I then went for the next best solution, which seemed to be extracting all instances of “\cite{something}” from the source and ''in that order'' pulling the referenced entries from the .bib file. This way you can go through the source file and sorted-references file in parallel, copying over what you need, without searching back and forth in the .bib file. I used:<br />
<br />
* <nowiki>egrep -o "\cite\{[^\}]*\}" ~/typeclassopedia.lhs | cut -c 6- | tr "," "\n" | tr -d "}" > /tmp/citations</nowiki><br />
* <nowiki>for i in $(cat /tmp/citations); do grep -A99 "$i" ~/typeclassopedia.bib|egrep -B99 '^\}$' -m1 ; done > ~/typeclasso-refs-sorted</nowiki><br />
<br />
[[Category:Applicative Functor]]<br />
[[Category:Arrow]]<br />
[[Category:Functor]]<br />
[[Category:Monad]]<br />
[[Category:Standard classes]]<br />
[[Category:Standard libraries]]<br />
[[Category:Standard packages]]<br />
[[Category:Standard types]]</div>Imzhttps://wiki.haskell.org/index.php?title=Typeclassopedia&diff=59127Typeclassopedia2014-11-27T14:19:35Z<p>Imz: /* Monoid */ (minor) Fixed a link to Monad.Reader</p>
<hr />
<div>''By [[User:Byorgey|Brent Yorgey]], byorgey@cis.upenn.edu''<br />
<br />
''Originally published 12 March 2009 in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13] of [http://themonadreader.wordpress.com/ the Monad.Reader]. Ported to the Haskell wiki in November 2011 by [[User:Geheimdienst|Geheimdienst]].''<br />
<br />
''This is now the official version of the Typeclassopedia and supersedes the version published in the Monad.Reader. Please help update and extend it by editing it yourself or by leaving comments, suggestions, and questions on the [[Talk:Typeclassopedia|talk page]].''<br />
<br />
=Abstract=<br />
<br />
The standard Haskell libraries feature a number of type classes with algebraic or category-theoretic underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs.<br />
<br />
The goal of this document is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading.<br />
<br />
=Introduction=<br />
<br />
Have you ever had any of the following thoughts?<br />
* What the heck is a monoid, and how is it different from a mon<u>a</u>d?<br />
<br />
* I finally figured out how to use [[Parsec]] with do-notation, and someone told me I should use something called <code>Applicative</code> instead. Um, what?<br />
<br />
* Someone in the [[IRC channel|#haskell]] IRC channel used <code>(***)</code>, and when I asked Lambdabot to tell me its type, it printed out scary gobbledygook that didn’t even fit on one line! Then someone used <code>fmap fmap fmap</code> and my brain exploded.<br />
<br />
* When I asked how to do something I thought was really complicated, people started typing things like <code>zip.ap fmap.(id &&& wtf)</code> and the scary thing is that they worked! Anyway, I think those people must actually be robots because there’s no way anyone could come up with that in two seconds off the top of their head.<br />
<br />
If you have, look no further! You, too, can write and understand concise, elegant, idiomatic Haskell code with the best of them.<br />
<br />
There are two keys to an expert Haskell hacker’s wisdom:<br />
# Understand the types.<br />
# Gain a deep intuition for each type class and its relationship to other type classes, backed up by familiarity with many examples.<br />
<br />
It’s impossible to overstate the importance of the first; the patient student of type signatures will uncover many profound secrets. Conversely, anyone ignorant of the types in their code is doomed to eternal uncertainty. “Hmm, it doesn’t compile ... maybe I’ll stick in an<br />
<code>fmap</code> here ... nope, let’s see ... maybe I need another <code>(.)</code> somewhere? ... um ...”<br />
<br />
The second key—gaining deep intuition, backed by examples—is also important, but much more difficult to attain. A primary goal of this document is to set you on the road to gaining such intuition. However—<br />
<br />
:''There is no royal road to Haskell. {{h:title|Well, he probably would have said it if he knew Haskell.|—Euclid}}''<br />
<br />
This document can only be a starting point, since good intuition comes from hard work, [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ not from learning the right metaphor]. Anyone who reads and understands all of it will still have an arduous journey ahead—but sometimes a good starting point makes a big difference.<br />
<br />
It should be noted that this is not a Haskell tutorial; it is assumed that the reader is already familiar with the basics of Haskell, including the standard <code>[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html Prelude]</code>, the type system, data types, and type classes.<br />
<br />
The type classes we will be discussing and their interrelationships:<br />
<br />
[[Image:Typeclassopedia-diagram.png]]<br />
<br />
{{note|<code>Semigroup</code> can be found in the [http://hackage.haskell.org/package/semigroups <code>semigroups</code> package], <code>Apply</code> in the [http://hackage.haskell.org/package/semigroupoids <code>semigroupoids</code> package], and <code>Comonad</code> in the [http://hackage.haskell.org/package/comonad <code>comonad</code> package].}}<br />
<br />
* <span style="border-bottom: 2px solid black">Solid arrows</span> point from the general to the specific; that is, if there is an arrow from <code>Foo</code> to <code>Bar</code> it means that every <code>Bar</code> is (or should be, or can be made into) a <code>Foo</code>.<br />
* <span style="border-bottom: 2px dotted black">Dotted arrows</span> indicate some other sort of relationship.<br />
* <code>Monad</code> and <code>ArrowApply</code> are equivalent.<br />
* <code>Semigroup</code>, <code>Apply</code> and <code>Comonad</code> are greyed out since they are not actually (yet?) in the standard Haskell libraries {{noteref}}.<br />
<br />
One more note before we begin. The original spelling of “type class” is with two words, as evidenced by, for example, the [http://www.haskell.org/onlinereport/haskell2010/ Haskell 2010 Language Report], early papers on type classes like [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.5639 Type classes in Haskell] and [http://research.microsoft.com/en-us/um/people/simonpj/papers/type-class-design-space/ Type classes: exploring the design space], and [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.168.4008 Hudak et al.’s history of Haskell]. However, as often happens with two-word phrases that see a lot of use, it has started to show up as one word (“typeclass”) or, rarely, hyphenated (“type-class”). When wearing my prescriptivist hat, I prefer “type class”, but realize (after changing into my descriptivist hat) that there's probably not much I can do about it.<br />
<br />
We now begin with the simplest type class of all: <code>Functor</code>.<br />
<br />
=Functor=<br />
<br />
The <code>Functor</code> class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Functor haddock]) is the most basic and ubiquitous type class in the Haskell libraries. A simple intuition is that a <code>Functor</code> represents a “container” of some sort, along with the ability to apply a function uniformly to every element in the container. For example, a list is a container of elements, and we can apply a function to every element of a list, using <code>map</code>. As another example, a binary tree is also a container of elements, and it’s not hard to come up with a way to recursively apply a function to every element in a tree.<br />
<br />
Another intuition is that a <code>Functor</code> represents some sort of “computational context”. This intuition is generally more useful, but is more difficult to explain, precisely because it is so general. Some examples later should help to clarify the <code>Functor</code>-as-context point of view.<br />
<br />
In the end, however, a <code>Functor</code> is simply what it is defined to be; doubtless there are many examples of <code>Functor</code> instances that don’t exactly fit either of the above intuitions. The wise student will focus their attention on definitions and examples, without leaning too heavily on any particular metaphor. Intuition will come, in time, on its own.<br />
<br />
==Definition==<br />
<br />
Here is the type class declaration for <code>Functor</code>:<br />
<br />
<haskell><br />
class Functor f where<br />
fmap :: (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
<code>Functor</code> is exported by the <code>Prelude</code>, so no special imports are needed to use it.<br />
<br />
First, the <code>f a</code> and <code>f b</code> in the type signature for <code>fmap</code> tell us that <code>f</code> isn’t just a type; it is a ''type constructor'' which takes another type as a parameter. (A more precise way to say this is that the ''kind'' of <code>f</code> must be <code>* -> *</code>.) For example, <code>Maybe</code> is such a type constructor: <code>Maybe</code> is not a type in and of itself, but requires another type as a parameter, like <code>Maybe Integer</code>. So it would not make sense to say <code>instance Functor Integer</code>, but it could make sense to say <code>instance Functor Maybe</code>.<br />
<br />
Now look at the type of <code>fmap</code>: it takes any function from <code>a</code> to <code>b</code>, and a value of type <code>f a</code>, and outputs a value of type <code>f b</code>. From the container point of view, the intention is that <code>fmap</code> applies a function to each element of a container, without altering the structure of the container. From the context point of view, the intention is that <code>fmap</code> applies a function to a value without altering its context. Let’s look at a few specific examples.<br />
<br />
==Instances==<br />
<br />
{{note|Recall that <code>[]</code> has two meanings in Haskell: it can either stand for the empty list, or, as here, it can represent the list type constructor (pronounced “list-of”). In other words, the type <code>[a]</code> (list-of-<code>a</code>) can also be written <code>[] a</code>.}}<br />
<br />
{{note|You might ask why we need a separate <code>map</code> function. Why not just do away with the current list-only <code>map</code> function, and rename <code>fmap</code> to <code>map</code> instead? Well, that’s a good question. The usual argument is that someone just learning Haskell, when using <code>map</code> incorrectly, would much rather see an error about lists than about <code>Functor</code>s.}}<br />
<br />
As noted before, the list constructor <code>[]</code> is a functor {{noteref}}; we can use the standard list function <code>map</code> to apply a function to each element of a list {{noteref}}. The <code>Maybe</code> type constructor is also a functor, representing a container which might hold a single element. The function <code>fmap g</code> has no effect on <code>Nothing</code> (there are no elements to which <code>g</code> can be applied), and simply applies <code>g</code> to the single element inside a <code>Just</code>. Alternatively, under the context interpretation, the list functor represents a context of nondeterministic choice; that is, a list can be thought of as representing a single value which is nondeterministically chosen from among several possibilities (the elements of the list). Likewise, the <code>Maybe</code> functor represents a context with possible failure. These instances are:<br />
<br />
<haskell><br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : fmap g xs<br />
-- or we could just say fmap = map<br />
<br />
instance Functor Maybe where<br />
fmap _ Nothing = Nothing<br />
fmap g (Just a) = Just (g a)<br />
</haskell><br />
<br />
As an aside, in idiomatic Haskell code you will often see the letter <code>f</code> used to stand for both an arbitrary <code>Functor</code> and an arbitrary function. In this document, <code>f</code> represents only <code>Functor</code>s, and <code>g</code> or <code>h</code> always represent functions, but you should be aware of the potential confusion. In practice, what <code>f</code> stands for should always be clear from the context, by noting whether it is part of a type or part of the code.<br />
<br />
There are other <code>Functor</code> instances in the standard libraries; below are a few. Note that some of these instances are not exported by the <code>Prelude</code>; to access them, you can import <code>Control.Monad.Instances</code>.<br />
<br />
* <code>Either e</code> is an instance of <code>Functor</code>; <code>Either e a</code> represents a container which can contain either a value of type <code>a</code>, or a value of type <code>e</code> (often representing some sort of error condition). It is similar to <code>Maybe</code> in that it represents possible failure, but it can carry some extra information about the failure as well.<br />
<br />
* <code>((,) e)</code> represents a container which holds an “annotation” of type <code>e</code> along with the actual value it holds. It might be clearer to write it as <code>(e,)</code>, by analogy with an operator section like <code>(1+)</code>, but that syntax is not allowed in types (although it is allowed in expressions with the <code>TupleSections</code> extension enabled). However, you can certainly ''think'' of it as <code>(e,)</code>.<br />
<br />
* <code>((->) e)</code> (which can be thought of as <code>(e ->)</code>; see above), the type of functions which take a value of type <code>e</code> as a parameter, is a <code>Functor</code>. As a container, <code>(e -> a)</code> represents a (possibly infinite) set of values of <code>a</code>, indexed by values of <code>e</code>. Alternatively, and more usefully, <code>((->) e)</code> can be thought of as a context in which a value of type <code>e</code> is available to be consulted in a read-only fashion. This is also why <code>((->) e)</code> is sometimes referred to as the ''reader monad''; more on this later.<br />
<br />
* <code>IO</code> is a <code>Functor</code>; a value of type <code>IO a</code> represents a computation producing a value of type <code>a</code> which may have I/O effects. If <code>m</code> computes the value <code>x</code> while producing some I/O effects, then <code>fmap g m</code> will compute the value <code>g x</code> while producing the same I/O effects.<br />
<br />
* Many standard types from the [http://hackage.haskell.org/package/containers/ containers library] (such as <code>Tree</code>, <code>Map</code>, and <code>Sequence</code>) are instances of <code>Functor</code>. A notable exception is <code>Set</code>, which cannot be made a <code>Functor</code> in Haskell (although it is certainly a mathematical functor) since it requires an <code>Ord</code> constraint on its elements; <code>fmap</code> must be applicable to ''any'' types <code>a</code> and <code>b</code>. However, <code>Set</code> (and other similarly restricted data types) can be made an instance of a suitable generalization of <code>Functor</code>, either by [http://article.gmane.org/gmane.comp.lang.haskell.cafe/78052/ making <code>a</code> and <code>b</code> arguments to the <code>Functor</code> type class themselves], or by adding an [http://blog.omega-prime.co.uk/?p=127 associated constraint].<br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement <code>Functor</code> instances for <code>Either e</code> and <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> instances for <code>((,) e)</code> and for <code>Pair</code>, defined as <br />
<br />
<haskell>data Pair a = Pair a a</haskell><br />
<br />
Explain their similarities and differences.<br />
</li><br />
<li>Implement a <code>Functor</code> instance for the type <code>ITree</code>, defined as<br />
<br />
<haskell><br />
data ITree a = Leaf (Int -> a) <br />
| Node [ITree a]<br />
</haskell><br />
</li><br />
<li>Give an example of a type of kind <code>* -> *</code> which cannot be made an instance of <code>Functor</code> (without using <code>undefined</code>).<br />
</li><br />
<li>Is this statement true or false? <br />
<br />
:''The composition of two <code>Functor</code>s is also a <code>Functor</code>.''<br />
<br />
If false, give a counterexample; if true, prove it by exhibiting some appropriate Haskell code.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Laws==<br />
<br />
As far as the Haskell language itself is concerned, the only requirement to be a <code>Functor</code> is an implementation of <code>fmap</code> with the proper type. Any sensible <code>Functor</code> instance, however, will also satisfy the ''functor laws'', which are part of the definition of a mathematical functor. There are two:<br />
<br />
<haskell><br />
fmap id = id<br />
fmap (g . h) = (fmap g) . (fmap h)<br />
</haskell><br />
<br />
{{note|Technically, these laws make <code>f</code> and <code>fmap</code> together an endofunctor on ''Hask'', the category of Haskell types (ignoring [[Bottom|&perp;]], which is a party pooper). See [http://en.wikibooks.org/wiki/Haskell/Category_theory Wikibook: Category theory].}}<br />
<br />
Together, these laws ensure that <code>fmap g</code> does not change the ''structure'' of a container, only the elements. Equivalently, and more simply, they ensure that <code>fmap g</code> changes a value without altering its context {{noteref}}.<br />
<br />
The first law says that mapping the identity function over every item in a container has no effect. The second says that mapping a composition of two functions over every item in a container is the same as first mapping one function, and then mapping the other.<br />
<br />
As an example, the following code is a “valid” instance of <code>Functor</code> (it typechecks), but it violates the functor laws. Do you see why?<br />
<br />
<haskell><br />
-- Evil Functor instance<br />
instance Functor [] where<br />
fmap _ [] = []<br />
fmap g (x:xs) = g x : g x : fmap g xs<br />
</haskell><br />
<br />
Any Haskeller worth their salt would reject this code as a gruesome abomination.<br />
<br />
Unlike some other type classes we will encounter, a given type has at most one valid instance of <code>Functor</code>. This [http://article.gmane.org/gmane.comp.lang.haskell.libraries/15384 can be proven] via the [http://homepages.inf.ed.ac.uk/wadler/topics/parametricity.html#free ''free theorem''] for the type of <code>fmap</code>. In fact, [http://byorgey.wordpress.com/2010/03/03/deriving-pleasure-from-ghc-6-12-1/ GHC can automatically derive] <code>Functor</code> instances for many data types.<br />
<br />
{{note|Actually, if <code>seq</code>/<code>undefined</code> are considered, it [http://stackoverflow.com/a/8323243/305559 is possible] to have an implementation which satisfies the first law but not the second. The rest of the comments in this section should considered in a context where <code>seq</code> and <code>undefined</code> are excluded.}}<br />
<br />
A [https://github.com/quchen/articles/blob/master/second_functor_law.md similar argument also shows] that any <code>Functor</code> instance satisfying the first law (<code>fmap id = id</code>) will automatically satisfy the second law as well. Practically, this means that only the first law needs to be checked (usually by a very straightforward induction) to ensure that a <code>Functor</code> instance is valid.{{noteref}}<br />
<br />
{{Exercises|<br />
# Although it is not possible for a <code>Functor</code> instance to satisfy the first <code>Functor</code> law but not the second (excluding <code>undefined</code>), the reverse is possible. Give an example of a (bogus) <code>Functor</code> instance which satisfies the second law but not the first.<br />
# Which laws are violated by the evil <code>Functor</code> instance for list shown above: both laws, or the first law alone? Give specific counterexamples.<br />
}}<br />
<br />
==Intuition==<br />
<br />
There are two fundamental ways to think about <code>fmap</code>. The first has already been mentioned: it takes two parameters, a function and a container, and applies the function “inside” the container, producing a new container. Alternately, we can think of <code>fmap</code> as applying a function to a value in a context (without altering the context).<br />
<br />
Just like all other Haskell functions of “more than one parameter”, however, <code>fmap</code> is actually ''curried'': it does not really take two parameters, but takes a single parameter and returns a function. For emphasis, we can write <code>fmap</code>’s type with extra parentheses: <code>fmap :: (a -> b) -> (f a -> f b)</code>. Written in this form, it is apparent that <code>fmap</code> transforms a “normal” function (<code>g :: a -> b</code>) into one which operates over containers/contexts (<code>fmap g :: f a -> f b</code>). This transformation is often referred to as a ''lift''; <code>fmap</code> “lifts” a function from the “normal world” into the “<code>f</code> world”.<br />
<br />
==Further reading==<br />
<br />
A good starting point for reading about the category theory behind the concept of a functor is the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page on category theory].<br />
<br />
=Applicative=<br />
<br />
A somewhat newer addition to the pantheon of standard Haskell type classes, ''applicative functors'' represent an abstraction lying in between <code>Functor</code> and <code>Monad</code> in expressivity, first described by McBride and Paterson. The title of their classic paper, [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative Programming with Effects], gives a hint at the intended intuition behind the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html <code>Applicative</code>] type class. It encapsulates certain sorts of “effectful” computations in a functionally pure way, and encourages an “applicative” programming style. Exactly what these things mean will be seen later.<br />
<br />
==Definition==<br />
<br />
Recall that <code>Functor</code> allows us to lift a “normal” function to a function on computational contexts. But <code>fmap</code> doesn’t allow us to apply a function which is itself in a context to a value in a context. <code>Applicative</code> gives us just such a tool, <code>(<*>)</code>. It also provides a method, <code>pure</code>, for embedding values in a default, “effect free” context. Here is the type class declaration for <code>Applicative</code>, as defined in <code>Control.Applicative</code>:<br />
<br />
<haskell><br />
class Functor f => Applicative f where<br />
pure :: a -> f a<br />
(<*>) :: f (a -> b) -> f a -> f b<br />
</haskell><br />
<br />
Note that every <code>Applicative</code> must also be a <code>Functor</code>. In fact, as we will see, <code>fmap</code> can be implemented using the <code>Applicative</code> methods, so every <code>Applicative</code> is a functor whether we like it or not; the <code>Functor</code> constraint forces us to be honest.<br />
<br />
{{note|Recall that <code>($)</code> is just function application: <code>f $ x {{=}} f x</code>.}}<br />
<br />
As always, it’s crucial to understand the type signatures. First, consider <code>(<*>)</code>: the best way of thinking about it comes from noting that the type of <code>(<*>)</code> is similar to the type of <code>($)</code> {{noteref}}, but with everything enclosed in an <code>f</code>. In other words, <code>(<*>)</code> is just function application within a computational context. The type of <code>(<*>)</code> is also very similar to the type of <code>fmap</code>; the only difference is that the first parameter is <code>f (a -> b)</code>, a function in a context, instead of a “normal” function <code>(a -> b)</code>.<br />
<br />
<code>pure</code> takes a value of any type <code>a</code>, and returns a context/container of type <code>f a</code>. The intention is that <code>pure</code> creates some sort of “default” container or “effect free” context. In fact, the behavior of <code>pure</code> is quite constrained by the laws it should satisfy in conjunction with <code>(<*>)</code>. Usually, for a given implementation of <code>(<*>)</code> there is only one possible implementation of <code>pure</code>.<br />
<br />
(Note that previous versions of the Typeclassopedia explained <code>pure</code> in terms of a type class <code>Pointed</code>, which can still be found in the [http://hackage.haskell.org/package/pointed <code>pointed</code> package]. However, the current consensus is that <code>Pointed</code> is not very useful after all. For a more detailed explanation, see [[Why not Pointed?]])<br />
<br />
==Laws==<br />
<br />
{{note|See<br />
[http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html haddock for Applicative] and [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative programming with effects]}}<br />
<br />
Traditionally, there are four laws that <code>Applicative</code> instances should satisfy {{noteref}}. In some sense, they are all concerned with making sure that <code>pure</code> deserves its name:<br />
<br />
* The identity law:<br /><haskell>pure id <*> v = v</haskell><br />
* Homomorphism:<br /><haskell>pure f <*> pure x = pure (f x)</haskell>Intuitively, applying a non-effectful function to a non-effectful argument in an effectful context is the same as just applying the function to the argument and then injecting the result into the context with <code>pure</code>.<br />
* Interchange:<br /><haskell>u <*> pure y = pure ($ y) <*> u</haskell>Intuitively, this says that when evaluating the application of an effectful function to a pure argument, the order in which we evaluate the function and its argument doesn't matter.<br />
* Composition:<br /><haskell>u <*> (v <*> w) = pure (.) <*> u <*> v <*> w </haskell>This one is the trickiest law to gain intuition for. In some sense it is expressing a sort of associativity property of <code>(<*>)</code>. The reader may wish to simply convince themselves that this law is type-correct.<br />
<br />
Considered as left-to-right rewrite rules, the homomorphism, interchange, and composition laws actually constitute an algorithm for transforming any expression using <code>pure</code> and <code>(<*>)</code> into a canonical form with only a single use of <code>pure</code> at the very beginning and only left-nested occurrences of <code>(<*>)</code>. Composition allows reassociating <code>(<*>)</code>; interchange allows moving occurrences of <code>pure</code> leftwards; and homomorphism allows collapsing multiple adjacent occurrences of <code>pure</code> into one.<br />
<br />
There is also a law specifying how <code>Applicative</code> should relate to <code>Functor</code>:<br />
<br />
<haskell><br />
fmap g x = pure g <*> x<br />
</haskell><br />
<br />
It says that mapping a pure function <code>g</code> over a context <code>x</code> is the same as first injecting <code>g</code> into a context with <code>pure</code>, and then applying it to <code>x</code> with <code>(<*>)</code>. In other words, we can decompose <code>fmap</code> into two more atomic operations: injection into a context, and application within a context. The <code>Control.Applicative</code> module also defines <code>(<$>)</code> as a synonym for <code>fmap</code>, so the above law can also be expressed as:<br />
<br />
<code>g <$> x = pure g <*> x</code>.<br />
<br />
{{Exercises|<br />
# (Tricky) One might imagine a variant of the interchange law that says something about applying a pure function to an effectful argument. Using the above laws, prove that<haskell>pure f <*> x = pure (flip ($)) <*> x <*> pure f</haskell><br />
}}<br />
<br />
==Instances==<br />
<br />
Most of the standard types which are instances of <code>Functor</code> are also instances of <code>Applicative</code>.<br />
<br />
<code>Maybe</code> can easily be made an instance of <code>Applicative</code>; writing such an instance is left as an exercise for the reader.<br />
<br />
The list type constructor <code>[]</code> can actually be made an instance of <code>Applicative</code> in two ways; essentially, it comes down to whether we want to think of lists as ordered collections of elements, or as contexts representing multiple results of a nondeterministic computation (see Wadler’s [http://www.springerlink.com/content/y7450255v2670167/ How to replace failure by a list of successes]).<br />
<br />
Let’s first consider the collection point of view. Since there can only be one instance of a given type class for any particular type, one or both of the list instances of <code>Applicative</code> need to be defined for a <code>newtype</code> wrapper; as it happens, the nondeterministic computation instance is the default, and the collection instance is defined in terms of a <code>newtype</code> called <code>ZipList</code>. This instance is:<br />
<br />
<haskell><br />
newtype ZipList a = ZipList { getZipList :: [a] }<br />
<br />
instance Applicative ZipList where<br />
pure = undefined -- exercise<br />
(ZipList gs) <*> (ZipList xs) = ZipList (zipWith ($) gs xs)<br />
</haskell><br />
<br />
To apply a list of functions to a list of inputs with <code>(<*>)</code>, we just match up the functions and inputs elementwise, and produce a list of the resulting outputs. In other words, we “zip” the lists together with function application, <code>($)</code>; hence the name <code>ZipList</code>. <br />
<br />
The other <code>Applicative</code> instance for lists, based on the nondeterministic computation point of view, is:<br />
<br />
<haskell><br />
instance Applicative [] where<br />
pure x = [x]<br />
gs <*> xs = [ g x | g <- gs, x <- xs ]<br />
</haskell><br />
<br />
Instead of applying functions to inputs pairwise, we apply each function to all the inputs in turn, and collect all the results in a list.<br />
<br />
Now we can write nondeterministic computations in a natural style. To add the numbers <code>3</code> and <code>4</code> deterministically, we can of course write <code>(+) 3 4</code>. But suppose instead of <code>3</code> we have a nondeterministic computation that might result in <code>2</code>, <code>3</code>, or <code>4</code>; then we can write<br />
<br />
<haskell><br />
pure (+) <*> [2,3,4] <*> pure 4<br />
</haskell><br />
<br />
or, more idiomatically,<br />
<br />
<haskell><br />
(+) <$> [2,3,4] <*> pure 4.<br />
</haskell><br />
<br />
There are several other <code>Applicative</code> instances as well:<br />
<br />
* <code>IO</code> is an instance of <code>Applicative</code>, and behaves exactly as you would think: to execute <code>m1 <*> m2</code>, first <code>m1</code> is executed, resulting in a function <code>f</code>, then <code>m2</code> is executed, resulting in a value <code>x</code>, and finally the value <code>f x</code> is returned as the result of executing <code>m1 <*> m2</code>.<br />
<br />
* <code>((,) a)</code> is an <code>Applicative</code>, as long as <code>a</code> is an instance of <code>Monoid</code> ([[#Monoid|section Monoid]]). The <code>a</code> values are accumulated in parallel with the computation.<br />
<br />
* The <code>Applicative</code> module defines the <code>Const</code> type constructor; a value of type <code>Const a b</code> simply contains an <code>a</code>. This is an instance of <code>Applicative</code> for any <code>Monoid a</code>; this instance becomes especially useful in conjunction with things like <code>Foldable</code> ([[#Foldable|section Foldable]]).<br />
<br />
* The <code>WrappedMonad</code> and <code>WrappedArrow</code> newtypes make any instances of <code>Monad</code> ([[#Monad|section Monad]]) or <code>Arrow</code> ([[#Arrow|section Arrow]]) respectively into instances of <code>Applicative</code>; as we will see when we study those type classes, both are strictly more expressive than <code>Applicative</code>, in the sense that the <code>Applicative</code> methods can be implemented in terms of their methods.<br />
<br />
{{Exercises|<br />
# Implement an instance of <code>Applicative</code> for <code>Maybe</code>.<br />
# Determine the correct definition of <code>pure</code> for the <code>ZipList</code> instance of <code>Applicative</code>—there is only one implementation that satisfies the law relating <code>pure</code> and <code>(<*>)</code>.<br />
}}<br />
<br />
==Intuition==<br />
<br />
McBride and Paterson’s paper introduces the notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> to denote function application in a computational context. If each <math>x_i\ </math> has type <math>f \; t_i\ </math> for some applicative functor <math>f\ </math>, and <math>g\ </math> has type <math>t_1 \to t_2 \to \dots \to t_n \to t\ </math>, then the entire expression <math>[[g \; x_1 \; \cdots \; x_n]]\ </math> has type <math>f \; t\ </math>. You can think of this as applying a function to multiple “effectful” arguments. In this sense, the double bracket notation is a generalization of <code>fmap</code>, which allows us to apply a function to a single argument in a context.<br />
<br />
Why do we need <code>Applicative</code> to implement this generalization of <code>fmap</code>? Suppose we use <code>fmap</code> to apply <code>g</code> to the first parameter <code>x1</code>. Then we get something of type <code>f (t2 -> ... t)</code>, but now we are stuck: we can’t apply this function-in-a-context to the next argument with <code>fmap</code>. However, this is precisely what <code>(<*>)</code> allows us to do.<br />
<br />
This suggests the proper translation of the idealized notation <math>[[g \; x_1 \; x_2 \; \cdots \; x_n]]\ </math> into Haskell, namely<br />
<haskell><br />
g <$> x1 <*> x2 <*> ... <*> xn,<br />
</haskell><br />
<br />
recalling that <code>Control.Applicative</code> defines <code>(<$>)</code> as convenient infix shorthand for <code>fmap</code>. This is what is meant by an “applicative style”—effectful computations can still be described in terms of function application; the only difference is that we have to use the special operator <code>(<*>)</code> for application instead of simple juxtaposition.<br />
<br />
Note that <code>pure</code> allows embedding “non-effectful” arguments in the middle of an idiomatic application, like<br />
<haskell><br />
g <$> x1 <*> pure x2 <*> x3<br />
</haskell><br />
which has type <code>f d</code>, given<br />
<haskell><br />
g :: a -> b -> c -> d<br />
x1 :: f a<br />
x2 :: b<br />
x3 :: f c<br />
</haskell><br />
<br />
The double brackets are commonly known as “idiom brackets”, because they allow writing “idiomatic” function application, that is, function application that looks normal but has some special, non-standard meaning (determined by the particular instance of <code>Applicative</code> being used). Idiom brackets are not supported by GHC, but they are supported by the [http://personal.cis.strath.ac.uk/~conor/pub/she/ Strathclyde Haskell Enhancement], a preprocessor which (among many other things) translates idiom brackets into standard uses of <code>(<$>)</code> and <code>(<*>)</code>. This can result in much more readable code when making heavy use of <code>Applicative</code>.<br />
<br />
==Alternative formulation==<br />
<br />
An alternative, equivalent formulation of <code>Applicative</code> is given by<br />
<br />
<haskell><br />
class Functor f => Monoidal f where<br />
unit :: f ()<br />
(**) :: f a -> f b -> f (a,b)<br />
</haskell><br />
<br />
{{note|In category-theory speak, we say <code>f</code> is a ''lax'' monoidal functor because there aren't necessarily functions in the other direction, like <code>f (a, b) -> (f a, f b)</code>.}}<br />
Intuitively, this states that a <i>monoidal</i> functor{{noteref}} is one which has some sort of "default shape" and which supports some sort of "combining" operation. <code>pure</code> and <code>(<*>)</code> are equivalent in power to <code>unit</code> and <code>(**)</code> (see the Exercises below). More technically, the idea is that <code>f</code> preserves the "monoidal structure" given by the pairing constructor <code>(,)</code> and unit type <code>()</code>. This can be seen even more clearly if we rewrite the types of <code>unit</code> and <code>(**)</code> as<br />
<haskell><br />
unit' :: () -> f ()<br />
(**') :: (f a, f b) -> f (a, b)<br />
</haskell><br />
<br />
Furthermore, to deserve the name "monoidal" (see the [[#Monoid|section on Monoids]]), instances of <code>Monoidal</code> ought to satisfy the following laws, which seem much more straightforward than the traditional <code>Applicative</code> laws:<br />
<br />
{{note|In this and the following laws, <code>≅</code> refers to <i>isomorphism</i> rather than equality. In particular we consider <code>(x,()) ≅ x ≅ ((),x)</code> and <code>((x,y),z) ≅ (x,(y,z))</code>.}}<br />
* Left identity{{noteref}}: <haskell>unit ** v ≅ v</haskell><br />
* Right identity: <haskell>u ** unit ≅ u</haskell><br />
* Associativity: <haskell>u ** (v ** w) ≅ (u ** v) ** w</haskell><br />
<br />
These turn out to be equivalent to the usual <code>Applicative</code> laws. In a category theory setting, one would also require a naturality law:<br />
<br />
{{note|Here <code>g *** h {{=}} \(x,y) -> (g x, h y)</code>. See [[#Arrow|Arrows]].}}<br />
* Naturality: <haskell>fmap (g *** h) (u ** v) = fmap g u ** fmap h v</haskell><br />
<br />
but in the context of Haskell, this is a free theorem.<br />
<br />
Much of this section was taken from [http://blog.ezyang.com/2012/08/applicative-functors/ a blog post by Edward Z. Yang]; see his actual post for a bit more information.<br />
<br />
{{Exercises|<br />
# Implement <code>pure</code> and <code>(<*>)</code> in terms of <code>unit</code> and <code>(**)</code>, and vice versa.<br />
# Are there any <code>Applicative</code> instances for which there are also functions <code>f () -> ()</code> and <code>f (a,b) -> (f a, f b)</code>, satisfying some "reasonable" laws?<br />
# (Tricky) Prove that given your implementations from the previous exercise, the usual <code>Applicative</code> laws and the <code>Monoidal</code> laws stated above are equivalent.<br />
}}<br />
<br />
==Further reading==<br />
<br />
There are many other useful combinators in the standard libraries implemented in terms of <code>pure</code> and <code>(<*>)</code>: for example, <code>(*>)</code>, <code>(<*)</code>, <code>(<**>)</code>, <code>(<$)</code>, and so on (see [http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.7.0.0/Control-Applicative.html haddock for Applicative]). Judicious use of such secondary combinators can often make code using <code>Applicative</code>s much easier to read.<br />
<br />
[http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s original paper] is a treasure-trove of information and examples, as well as some perspectives on the connection between <code>Applicative</code> and category theory. Beginners will find it difficult to make it through the entire paper, but it is extremely well-motivated—even beginners will be able to glean something from reading as far as they are able.<br />
<br />
{{note|Introduced by [http://conal.net/papers/simply-reactive/ an earlier paper] that was since superseded by [http://conal.net/papers/push-pull-frp/ Push-pull functional reactive programming].}}<br />
<br />
Conal Elliott has been one of the biggest proponents of <code>Applicative</code>. For example, the [http://conal.net/papers/functional-images/ Pan library for functional images] and the reactive library for functional reactive programming (FRP) {{noteref}} make key use of it; his blog also contains [http://conal.net/blog/tag/applicative-functor many examples of <code>Applicative</code> in action]. Building on the work of McBride and Paterson, Elliott also built the [[TypeCompose]] library, which embodies the observation (among others) that <code>Applicative</code> types are closed under composition; therefore, <code>Applicative</code> instances can often be automatically derived for complex types built out of simpler ones.<br />
<br />
Although the [http://hackage.haskell.org/package/parsec Parsec parsing library] ([http://legacy.cs.uu.nl/daan/download/papers/parsec-paper.pdf paper]) was originally designed for use as a monad, in its most common use cases an <code>Applicative</code> instance can be used to great effect; [http://www.serpentine.com/blog/2008/02/06/the-basics-of-applicative-functors-put-to-practical-work/ Bryan O’Sullivan’s blog post] is a good starting point. If the extra power provided by <code>Monad</code> isn’t needed, it’s usually a good idea to use <code>Applicative</code> instead.<br />
<br />
A couple other nice examples of <code>Applicative</code> in action include the [http://web.archive.org/web/20090416111947/chrisdone.com/blog/html/2009-02-10-applicative-configfile-hsql.html ConfigFile and HSQL libraries] and the [http://groups.inf.ed.ac.uk/links/formlets/ formlets library].<br />
<br />
Gershom Bazerman's [http://comonad.com/reader/2012/abstracting-with-applicatives/ post] contains many insights into applicatives.<br />
<br />
=Monad=<br />
<br />
It’s a safe bet that if you’re reading this, you’ve heard of monads—although it’s quite possible you’ve never heard of <code>Applicative</code> before, or <code>Arrow</code>, or even <code>Monoid</code>. Why are monads such a big deal in Haskell? There are several reasons.<br />
<br />
* Haskell does, in fact, single out monads for special attention by making them the framework in which to construct I/O operations.<br />
* Haskell also singles out monads for special attention by providing a special syntactic sugar for monadic expressions: the <code>do</code>-notation.<br />
* <code>Monad</code> has been around longer than other abstract models of computation such as <code>Applicative</code> or <code>Arrow</code>.<br />
* The more monad tutorials there are, the harder people think monads must be, and the more new monad tutorials are written by people who think they finally “get” monads (the [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ monad tutorial fallacy]).<br />
<br />
I will let you judge for yourself whether these are good reasons.<br />
<br />
In the end, despite all the hoopla, <code>Monad</code> is just another type class. Let’s take a look at its definition.<br />
<br />
==Definition==<br />
<br />
The type class declaration for [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Monad <code>Monad</code>] is:<br />
<br />
<haskell><br />
class Monad m where<br />
return :: a -> m a<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
(>>) :: m a -> m b -> m b<br />
m >> n = m >>= \_ -> n<br />
<br />
fail :: String -> m a<br />
</haskell><br />
<br />
The <code>Monad</code> type class is exported by the <code>Prelude</code>, along with a few standard instances. However, many utility functions are found in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>], and there are also several instances (such as <code>((->) e)</code>) defined in [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-Instances.html <code>Control.Monad.Instances</code>].<br />
<br />
{{note|However, as of GHC 7.10 this will be fixed!}}<br />
Let’s examine the methods in the <code>Monad</code> class one by one. The type of <code>return</code> should look familiar; it’s the same as <code>pure</code>. Indeed, <code>return</code> ''is'' <code>pure</code>, but with an unfortunate name. (Unfortunate, since someone coming from an imperative programming background might think that <code>return</code> is like the C or Java keyword of the same name, when in fact the similarities are minimal.) From a mathematical point of view, every monad is an applicative functor, but for historical reasons, the <code>Monad</code> type class declaration unfortunately does not require this.{{noteref}}<br />
<br />
We can see that <code>(>>)</code> is a specialized version of <code>(>>=)</code>, with a default implementation given. It is only included in the type class declaration so that specific instances of <code>Monad</code> can override the default implementation of <code>(>>)</code> with a more efficient one, if desired. Also, note that although <code>_ >> n = n</code> would be a type-correct implementation of <code>(>>)</code>, it would not correspond to the intended semantics: the intention is that <code>m >> n</code> ignores the ''result'' of <code>m</code>, but not its ''effects''.<br />
<br />
The <code>fail</code> function is an awful hack that has no place in the <code>Monad</code> class; more on this later.<br />
<br />
The only really interesting thing to look at—and what makes <code>Monad</code> strictly more powerful than <code>Applicative</code>—is <code>(>>=)</code>, which is often called ''bind''. An alternative definition of <code>Monad</code> could look like:<br />
<br />
<haskell><br />
class Applicative m => Monad' m where<br />
(>>=) :: m a -> (a -> m b) -> m b<br />
</haskell><br />
<br />
We could spend a while talking about the intuition behind <code>(>>=)</code>—and we will. But first, let’s look at some examples.<br />
<br />
==Instances==<br />
<br />
Even if you don’t understand the intuition behind the <code>Monad</code> class, you can still create instances of it by just seeing where the types lead you. You may be surprised to find that this actually gets you a long way towards understanding the intuition; at the very least, it will give you some concrete examples to play with as you read more about the <code>Monad</code> class in general. The first few examples are from the standard <code>Prelude</code>; the remaining examples are from the [http://hackage.haskell.org/package/transformers <code>transformers</code> package].<br />
<br />
<ul><br />
<li>The simplest possible instance of <code>Monad</code> is [http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Monad-Identity.html <code>Identity</code>], which is described in Dan Piponi’s highly recommended blog post on [http://blog.sigfpe.com/2007/04/trivial-monad.html The Trivial Monad]. Despite being “trivial”, it is a great introduction to the <code>Monad</code> type class, and contains some good exercises to get your brain working.<br />
</li><br />
<li>The next simplest instance of <code>Monad</code> is <code>Maybe</code>. We already know how to write <code>return</code>/<code>pure</code> for <code>Maybe</code>. So how do we write <code>(>>=)</code>? Well, let’s think about its type. Specializing for <code>Maybe</code>, we have<br />
<br />
<haskell><br />
(>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b.<br />
</haskell><br />
<br />
If the first argument to <code>(>>=)</code> is <code>Just x</code>, then we have something of type <code>a</code> (namely, <code>x</code>), to which we can apply the second argument—resulting in a <code>Maybe b</code>, which is exactly what we wanted. What if the first argument to <code>(>>=)</code> is <code>Nothing</code>? In that case, we don’t have anything to which we can apply the <code>a -> Maybe b</code> function, so there’s only one thing we can do: yield <code>Nothing</code>. This instance is:<br />
<br />
<haskell><br />
instance Monad Maybe where<br />
return = Just<br />
(Just x) >>= g = g x<br />
Nothing >>= _ = Nothing<br />
</haskell><br />
<br />
We can already get a bit of intuition as to what is going on here: if we build up a computation by chaining together a bunch of functions with <code>(>>=)</code>, as soon as any one of them fails, the entire computation will fail (because <code>Nothing >>= f</code> is <code>Nothing</code>, no matter what <code>f</code> is). The entire computation succeeds only if all the constituent functions individually succeed. So the <code>Maybe</code> monad models computations which may fail.<br />
</li><br />
<br />
<li>The <code>Monad</code> instance for the list constructor <code>[]</code> is similar to its <code>Applicative</code> instance; see the exercise below.<br />
</li><br />
<br />
<li>Of course, the <code>IO</code> constructor is famously a <code>Monad</code>, but its implementation is somewhat magical, and may in fact differ from compiler to compiler. It is worth emphasizing that the <code>IO</code> monad is the ''only'' monad which is magical. It allows us to build up, in an entirely pure way, values representing possibly effectful computations. The special value <code>main</code>, of type <code>IO ()</code>, is taken by the runtime and actually executed, producing actual effects. Every other monad is functionally pure, and requires no special compiler support. We often speak of monadic values as “effectful computations”, but this is because some monads allow us to write code ''as if'' it has side effects, when in fact the monad is hiding the plumbing which allows these apparent side effects to be implemented in a functionally pure way.<br />
</li><br />
<br />
<li>As mentioned earlier, <code>((->) e)</code> is known as the ''reader monad'', since it describes computations in which a value of type <code>e</code> is available as a read-only environment.<br />
<br />
The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Reader.html <code>Control.Monad.Reader</code>] module provides the <code>Reader e a</code> type, which is just a convenient <code>newtype</code> wrapper around <code>(e -> a)</code>, along with an appropriate <code>Monad</code> instance and some <code>Reader</code>-specific utility functions such as <code>ask</code> (retrieve the environment), <code>asks</code> (retrieve a function of the environment), and <code>local</code> (run a subcomputation under a different environment).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Writer-Lazy.html <code>Control.Monad.Writer</code>] module provides the <code>Writer</code> monad, which allows information to be collected as a computation progresses. <code>Writer w a</code> is isomorphic to <code>(a,w)</code>, where the output value <code>a</code> is carried along with an annotation or “log” of type <code>w</code>, which must be an instance of <code>Monoid</code> (see [[#Monoid|section Monoid]]); the special function <code>tell</code> performs logging.<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-State-Lazy.html <code>Control.Monad.State</code>] module provides the <code>State s a</code> type, a <code>newtype</code> wrapper around <code>s -> (a,s)</code>. Something of type <code>State s a</code> represents a stateful computation which produces an <code>a</code> but can access and modify the state of type <code>s</code> along the way. The module also provides <code>State</code>-specific utility functions such as <code>get</code> (read the current state), <code>gets</code> (read a function of the current state), <code>put</code> (overwrite the state), and <code>modify</code> (apply a function to the state).<br />
</li><br />
<br />
<li>The [http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-Cont.html <code>Control.Monad.Cont</code>] module provides the <code>Cont</code> monad, which represents computations in continuation-passing style. It can be used to suspend and resume computations, and to implement non-local transfers of control, co-routines, other complex control structures—all in a functionally pure way. <code>Cont</code> has been called the [http://blog.sigfpe.com/2008/12/mother-of-all-monads.html “mother of all monads”] because of its universal properties.<br />
</li><br />
</ul><br />
<br />
{{Exercises|<br />
<ol><br />
<li>Implement a <code>Monad</code> instance for the list constructor, <code>[]</code>. Follow the types!</li><br />
<li>Implement a <code>Monad</code> instance for <code>((->) e)</code>.</li><br />
<li>Implement <code>Functor</code> and <code>Monad</code> instances for <code>Free f</code>, defined as<br />
<haskell><br />
data Free f a = Var a<br />
| Node (f (Free f a))<br />
</haskell><br />
You may assume that <code>f</code> has a <code>Functor</code> instance. This is known as the ''free monad'' built from the functor <code>f</code>.<br />
</li><br />
</ol><br />
}}<br />
<br />
==Intuition==<br />
<br />
Let’s look more closely at the type of <code>(>>=)</code>. The basic intuition is that it combines two computations into one larger computation. The first argument, <code>m a</code>, is the first computation. However, it would be boring if the second argument were just an <code>m b</code>; then there would be no way for the computations to interact with one another (actually, this is exactly the situation with <code>Applicative</code>). So, the second argument to <code>(>>=)</code> has type <code>a -> m b</code>: a function of this type, given a ''result'' of the first computation, can produce a second computation to be run. In other words, <code>x >>= k</code> is a computation which runs <code>x</code>, and then uses the result(s) of <code>x</code> to ''decide'' what computation to run second, using the output of the second computation as the result of the entire computation.<br />
<br />
{{note|Actually, because Haskell allows general recursion, this is a lie: using a Haskell parsing library one can recursively construct ''infinite'' grammars, and hence <code>Applicative</code> (together with <code>Alternative</code>) is enough to parse any context-sensitive language with a finite alphabet. See [http://byorgey.wordpress.com/2012/01/05/parsing-context-sensitive-languages-with-applicative/ Parsing context-sensitive languages with Applicative].}}<br />
Intuitively, it is this ability to use the output from previous computations to decide what computations to run next that makes <code>Monad</code> more powerful than <code>Applicative</code>. The structure of an <code>Applicative</code> computation is fixed, whereas the structure of a <code>Monad</code> computation can change based on intermediate results. This also means that parsers built using an <code>Applicative</code> interface can only parse context-free languages; in order to parse context-sensitive languages a <code>Monad</code> interface is needed.{{noteref}}<br />
<br />
To see the increased power of <code>Monad</code> from a different point of view, let’s see what happens if we try to implement <code>(>>=)</code> in terms of <code>fmap</code>, <code>pure</code>, and <code>(<*>)</code>. We are given a value <code>x</code> of type <code>m a</code>, and a function <code>k</code> of type <code>a -> m b</code>, so the only thing we can do is apply <code>k</code> to <code>x</code>. We can’t apply it directly, of course; we have to use <code>fmap</code> to lift it over the <code>m</code>. But what is the type of <code>fmap k</code>? Well, it’s <code>m a -> m (m b)</code>. So after we apply it to <code>x</code>, we are left with something of type <code>m (m b)</code>—but now we are stuck; what we really want is an <code>m b</code>, but there’s no way to get there from here. We can ''add'' <code>m</code>’s using <code>pure</code>, but we have no way to ''collapse'' multiple <code>m</code>’s into one.<br />
<br />
{{note|1=You might hear some people claim that that the definition in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> is the “math definition” and the definition in terms of <code>return</code> and <code>(>>=)</code> is something specific to Haskell. In fact, both definitions were known in the mathematics community long before Haskell picked up monads.}}<br />
<br />
This ability to collapse multiple <code>m</code>’s is exactly the ability provided by the function <code>join :: m (m a) -> m a</code>, and it should come as no surprise that an alternative definition of <code>Monad</code> can be given in terms of <code>join</code>:<br />
<br />
<haskell><br />
class Applicative m => Monad'' m where<br />
join :: m (m a) -> m a<br />
</haskell><br />
<br />
In fact, the canonical definition of monads in category theory is in terms of <code>return</code>, <code>fmap</code>, and <code>join</code> (often called <math>\eta</math>, <math>T</math>, and <math>\mu</math> in the mathematical literature). Haskell uses an alternative formulation with <code>(>>=)</code> instead of <code>join</code> since it is more convenient to use {{noteref}}. However, sometimes it can be easier to think about <code>Monad</code> instances in terms of <code>join</code>, since it is a more “atomic” operation. (For example, <code>join</code> for the list monad is just <code>concat</code>.)<br />
<br />
{{Exercises|<br />
# Implement <code>(>>{{=}})</code> in terms of <code>fmap</code> (or <code>liftM</code>) and <code>join</code>.<br />
# Now implement <code>join</code> and <code>fmap</code> (<code>liftM</code>) in terms of <code>(>>{{=}})</code> and <code>return</code>.<br />
}}<br />
<br />
==Utility functions==<br />
<br />
The [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html <code>Control.Monad</code>] module provides a large number of convenient utility functions, all of which can be implemented in terms of the basic <code>Monad</code> operations (<code>return</code> and <code>(>>=)</code> in particular). We have already seen one of them, namely, <code>join</code>. We also mention some other noteworthy ones here; implementing these utility functions oneself is a good exercise. For a more detailed guide to these functions, with commentary and example code, see Henk-Jan van Tuyl’s [http://members.chello.nl/hjgtuyl/tourdemonad.html tour].<br />
<br />
{{note|This will most likely change in Haskell 2014 with the implementation of the [[Functor-Applicative-Monad_Proposal|Haskell 2014 Applicative => Monad proposal]].}}<br />
<br />
* <code>liftM :: Monad m => (a -> b) -> m a -> m b</code>. This should be familiar; of course, it is just <code>fmap</code>. The fact that we have both <code>fmap</code> and <code>liftM</code> is an unfortunate consequence of the fact that the <code>Monad</code> type class does not require a <code>Functor</code> instance, even though mathematically speaking, every monad is a functor. However, <code>fmap</code> and <code>liftM</code> are essentially interchangeable, since it is a bug (in a social rather than technical sense) for any type to be an instance of <code>Monad</code> without also being an instance of <code>Functor</code> {{noteref}}.<br />
<br />
* <code>ap :: Monad m => m (a -> b) -> m a -> m b</code> should also be familiar: it is equivalent to <code>(<*>)</code>, justifying the claim that the <code>Monad</code> interface is strictly more powerful than <code>Applicative</code>. We can make any <code>Monad</code> into an instance of <code>Applicative</code> by setting <code>pure = return</code> and <code>(<*>) = ap</code>.<br />
<br />
* <code>sequence :: Monad m => [m a] -> m [a]</code> takes a list of computations and combines them into one computation which collects a list of their results. It is again something of a historical accident that <code>sequence</code> has a <code>Monad</code> constraint, since it can actually be implemented only in terms of <code>Applicative</code>. There is an additional generalization of <code>sequence</code> to structures other than lists, which will be discussed in the [[#Traversable|section on <code>Traversable</code>]].<br />
<br />
* <code>replicateM :: Monad m => Int -> m a -> m [a]</code> is simply a combination of [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:replicate <code>replicate</code>] and <code>sequence</code>.<br />
<br />
* <code>when :: Monad m => Bool -> m () -> m ()</code> conditionally executes a computation, evaluating to its second argument if the test is <code>True</code>, and to <code>return ()</code> if the test is <code>False</code>. A collection of other sorts of monadic conditionals can be found in the [http://hackage.haskell.org/package/IfElse <code>IfElse</code> package].<br />
<br />
* <code>mapM :: Monad m => (a -> m b) -> [a] -> m [b]</code> maps its first argument over the second, and <code>sequence</code>s the results. The <code>forM</code> function is just <code>mapM</code> with its arguments reversed; it is called <code>forM</code> since it models generalized <code>for</code> loops: the list <code>[a]</code> provides the loop indices, and the function <code>a -> m b</code> specifies the “body” of the loop for each index.<br />
<br />
* <code>(=<<) :: Monad m => (a -> m b) -> m a -> m b</code> is just <code>(>>=)</code> with its arguments reversed; sometimes this direction is more convenient since it corresponds more closely to function application.<br />
<br />
* <code>(>=>) :: Monad m => (a -> m b) -> (b -> m c) -> a -> m c</code> is sort of like function composition, but with an extra <code>m</code> on the result type of each function, and the arguments swapped. We’ll have more to say about this operation later. There is also a flipped variant, <code>(<=<)</code>.<br />
<br />
* The <code>guard</code> function is for use with instances of <code>MonadPlus</code>, which is discussed at the end of the [[#Monoid|<code>Monoid</code> section]].<br />
<br />
Many of these functions also have “underscored” variants, such as <code>sequence_</code> and <code>mapM_</code>; these variants throw away the results of the computations passed to them as arguments, using them only for their side effects.<br />
<br />
Other monadic functions which are occasionally useful include <code>filterM</code>, <code>zipWithM</code>, <code>foldM</code>, and <code>forever</code>.<br />
<br />
==Laws==<br />
<br />
There are several laws that instances of <code>Monad</code> should satisfy (see also the [[Monad laws]] wiki page). The standard presentation is:<br />
<br />
<haskell><br />
return a >>= k = k a<br />
m >>= return = m<br />
m >>= (\x -> k x >>= h) = (m >>= k) >>= h<br />
<br />
fmap f xs = xs >>= return . f = liftM f xs<br />
</haskell><br />
<br />
The first and second laws express the fact that <code>return</code> behaves nicely: if we inject a value <code>a</code> into a monadic context with <code>return</code>, and then bind to <code>k</code>, it is the same as just applying <code>k</code> to <code>a</code> in the first place; if we bind a computation <code>m</code> to <code>return</code>, nothing changes. The third law essentially says that <code>(>>=)</code> is associative, sort of. The last law ensures that <code>fmap</code> and <code>liftM</code> are the same for types which are instances of both <code>Functor</code> and <code>Monad</code>—which, as already noted, should be every instance of <code>Monad</code>.<br />
<br />
{{note|I like to pronounce this operator “fish”.}}<br />
<br />
However, the presentation of the above laws, especially the third, is marred by the asymmetry of <code>(>>=)</code>. It’s hard to look at the laws and see what they’re really saying. I prefer a much more elegant version of the laws, which is formulated in terms of <code>(>=>)</code> {{noteref}}. Recall that <code>(>=>)</code> “composes” two functions of type <code>a -> m b</code> and <code>b -> m c</code>. You can think of something of type <code>a -> m b</code> (roughly) as a function from <code>a</code> to <code>b</code> which may also have some sort of effect in the context corresponding to <code>m</code>. <code>(>=>)</code> lets us compose these “effectful functions”, and we would like to know what properties <code>(>=>)</code> has. The monad laws reformulated in terms of <code>(>=>)</code> are:<br />
<br />
<haskell><br />
return >=> g = g<br />
g >=> return = g<br />
(g >=> h) >=> k = g >=> (h >=> k)<br />
</haskell><br />
<br />
{{note|As fans of category theory will note, these laws say precisely that functions of type <code>a -> m b</code> are the arrows of a category with <code>(>{{=}}>)</code> as composition! Indeed, this is known as the ''Kleisli category'' of the monad <code>m</code>. It will come up again when we discuss <code>Arrow</code>s.}}<br />
<br />
Ah, much better! The laws simply state that <code>return</code> is the identity of <code>(>=>)</code>, and that <code>(>=>)</code> is associative {{noteref}}.<br />
<br />
There is also a formulation of the monad laws in terms of <code>fmap</code>, <code>return</code>, and <code>join</code>; for a discussion of this formulation, see the Haskell [http://en.wikibooks.org/wiki/Haskell/Category_theory wikibook page on category theory].<br />
<br />
{{Exercises|<br />
# Given the definition <code>g >{{=}}> h {{=}} \x -> g x >>{{=}} h</code>, prove the equivalence of the above laws and the usual monad laws.<br />
}}<br />
<br />
==<code>do</code> notation==<br />
<br />
Haskell’s special <code>do</code> notation supports an “imperative style” of programming by providing syntactic sugar for chains of monadic expressions. The genesis of the notation lies in realizing that something like <code>a >>= \x -> b >> c >>= \y -> d </code> can be more readably written by putting successive computations on separate lines:<br />
<br />
<haskell><br />
a >>= \x -><br />
b >><br />
c >>= \y -><br />
d<br />
</haskell><br />
<br />
This emphasizes that the overall computation consists of four computations <code>a</code>, <code>b</code>, <code>c</code>, and <code>d</code>, and that <code>x</code> is bound to the result of <code>a</code>, and <code>y</code> is bound to the result of <code>c</code> (<code>b</code>, <code>c</code>, and <code>d</code> are allowed to refer to <code>x</code>, and <code>d</code> is allowed to refer to <code>y</code> as well). From here it is not hard to imagine a nicer notation:<br />
<br />
<haskell><br />
do { x <- a<br />
; b<br />
; y <- c<br />
; d<br />
}<br />
</haskell><br />
<br />
(The curly braces and semicolons may optionally be omitted; the Haskell parser uses layout to determine where they should be inserted.) This discussion should make clear that <code>do</code> notation is just syntactic sugar. In fact, <code>do</code> blocks are recursively translated into monad operations (almost) like this:<br />
<br />
<pre><br />
do e → e<br />
do { e; stmts } → e >> do { stmts }<br />
do { v <- e; stmts } → e >>= \v -> do { stmts }<br />
do { let decls; stmts} → let decls in do { stmts }<br />
</pre><br />
<br />
This is not quite the whole story, since <code>v</code> might be a pattern instead of a variable. For example, one can write<br />
<br />
<haskell><br />
do (x:xs) <- foo<br />
bar x<br />
</haskell><br />
<br />
but what happens if <code>foo</code> produces an empty list? Well, remember that ugly <code>fail</code> function in the <code>Monad</code> type class declaration? That’s what happens. See [http://www.haskell.org/onlinereport/exps.html#sect3.14 section 3.14 of the Haskell Report] for the full details. See also the discussion of <code>MonadPlus</code> and <code>MonadZero</code> in the [[#Other monoidal classes: Alternative, MonadPlus, ArrowPlus|section on other monoidal classes]].<br />
<br />
A final note on intuition: <code>do</code> notation plays very strongly to the “computational context” point of view rather than the “container” point of view, since the binding notation <code>x <- m</code> is suggestive of “extracting” a single <code>x</code> from <code>m</code> and doing something with it. But <code>m</code> may represent some sort of a container, such as a list or a tree; the meaning of <code>x <- m</code> is entirely dependent on the implementation of <code>(>>=)</code>. For example, if <code>m</code> is a list, <code>x <- m</code> actually means that <code>x</code> will take on each value from the list in turn.<br />
<br />
==Further reading==<br />
<br />
Philip Wadler was the first to propose using monads to structure functional programs. [http://homepages.inf.ed.ac.uk/wadler/topics/monads.html His paper] is still a readable introduction to the subject.<br />
<br />
{{note|1=<br />
[[All About Monads]],<br />
[http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers],<br />
[http://en.wikibooks.org/w/index.php?title=Haskell/Understanding_monads Understanding monads],<br />
[[The Monadic Way]],<br />
[http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads! (And Maybe You Already Have.)],<br />
[http://www.haskell.org/pipermail/haskell-cafe/2006-November/019190.html there’s a monster in my Haskell!],<br />
[http://kawagner.blogspot.com/2007/02/understanding-monads-for-real.html Understanding Monads. For real.],<br />
[http://www.randomhacks.net/articles/2007/03/12/monads-in-15-minutes Monads in 15 minutes: Backtracking and Maybe],<br />
[http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation],<br />
[http://metafoo.co.uk/practical-monads.txt Practical Monads]}}<br />
<br />
There are, of course, numerous monad tutorials of varying quality {{noteref}}.<br />
<br />
A few of the best include Cale Gibbard’s [http://www.haskell.org/haskellwiki/Monads_as_Containers Monads as containers] and [http://www.haskell.org/haskellwiki/Monads_as_computation Monads as computation]; Jeff Newbern’s [[All About Monads]], a comprehensive guide with lots of examples; and Dan Piponi’s [http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You Could Have Invented Monads!], which features great exercises. If you just want to know how to use <code>IO</code>, you could consult the [[Introduction to IO]]. Even this is just a sampling; the [[monad tutorials timeline]] is a more complete list. (All these monad tutorials have prompted parodies like [http://koweycode.blogspot.com/2007/01/think-of-monad.html think of a monad ...] as well as other kinds of backlash like [http://ahamsandwich.wordpress.com/2007/07/26/monads-and-why-monad-tutorials-are-all-awful/ Monads! (and Why Monad Tutorials Are All Awful)] or [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Abstraction, intuition, and the “monad tutorial fallacy”].)<br />
<br />
Other good monad references which are not necessarily tutorials include [http://members.chello.nl/hjgtuyl/tourdemonad.html Henk-Jan van Tuyl’s tour] of the functions in <code>Control.Monad</code>, Dan Piponi’s [http://blog.sigfpe.com/2006/10/monads-field-guide.html field guide], Tim Newsham’s [http://www.thenewsh.com/~newsham/haskell/monad.html What’s a Monad?], and Chris Smith's excellent article [http://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/ Why Do Monads Matter?]. There are also many blog posts which have been written on various aspects of monads; a collection of links can be found under [[Blog articles/Monads]].<br />
<br />
For help constructing monads from scratch, and for obtaining a "deep embedding" of monad operations suitable for use in, say, compiling a domain-specific language, see [http://projects.haskell.org/operational Apfelmus's operational package].<br />
<br />
One of the quirks of the <code>Monad</code> class and the Haskell type system is that it is not possible to straightforwardly declare <code>Monad</code> instances for types which require a class constraint on their data, even if they are monads from a mathematical point of view. For example, <code>Data.Set</code> requires an <code>Ord</code> constraint on its data, so it cannot be easily made an instance of <code>Monad</code>. A solution to this problem was [http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros first described by Eric Kidd], and later made into a [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmonad library named rmonad] by Ganesh Sittampalam and Peter Gavin.<br />
<br />
There are many good reasons for eschewing <code>do</code> notation; some have gone so far as to [[Do_notation_considered_harmful|consider it harmful]].<br />
<br />
Monads can be generalized in various ways; for an exposition of one possibility, see Robert Atkey’s paper on [http://homepages.inf.ed.ac.uk/ratkey/paramnotions-jfp.pdf parameterized monads], or Dan Piponi’s [http://blog.sigfpe.com/2009/02/beyond-monads.html Beyond Monads].<br />
<br />
For the categorically inclined, monads can be viewed as monoids ([http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html From Monoids to Monads]) and also as closure operators [http://blog.plover.com/math/monad-closure.html Triples and Closure]. Derek Elkins’s article in [http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf issue 13 of the Monad.Reader] contains an exposition of the category-theoretic underpinnings of some of the standard <code>Monad</code> instances, such as <code>State</code> and <code>Cont</code>. Jonathan Hill and Keith Clarke have [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.6497 an early paper explaining the connection between monads as they arise in category theory and as used in functional programming]. There is also a [http://okmij.org/ftp/Computation/IO-monad-history.html web page by Oleg Kiselyov] explaining the history of the IO monad.<br />
<br />
Links to many more research papers related to monads can be found under [[Research papers/Monads and arrows]].<br />
<br />
=Monad transformers=<br />
<br />
One would often like to be able to combine two monads into one: for example, to have stateful, nondeterministic computations (<code>State</code> + <code>[]</code>), or computations which may fail and can consult a read-only environment (<code>Maybe</code> + <code>Reader</code>), and so on. Unfortunately, monads do not compose as nicely as applicative functors (yet another reason to use <code>Applicative</code> if you don’t need the full power that <code>Monad</code> provides), but some monads can be combined in certain ways.<br />
<br />
==Standard monad transformers==<br />
<br />
The [http://hackage.haskell.org/package/transformers transformers] library provides a number of standard ''monad transformers''. Each monad transformer adds a particular capability/feature/effect to any existing monad.<br />
<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Identity.html <code>IdentityT</code>] is the identity transformer, which maps a monad to (something isomorphic to) itself. This may seem useless at first glance, but it is useful for the same reason that the <code>id</code> function is useful -- it can be passed as an argument to things which are parameterized over an arbitrary monad transformer, when you do not actually want any extra capabilities.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-State.html <code>StateT</code>] adds a read-write state.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Reader.html <code>ReaderT</code>] adds a read-only environment.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Writer.html <code>WriterT</code>] adds a write-only log.<br />
* [http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-RWS.html <code>RWST</code>] conveniently combines <code>ReaderT</code>, <code>WriterT</code>, and <code>StateT</code> into one.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Maybe.html <code>MaybeT</code>] adds the possibility of failure.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Error.html <code>ErrorT</code>] adds the possibility of failure with an arbitrary type to represent errors.<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-List.html <code>ListT</code>] adds non-determinism (however, see the discussion of <code>ListT</code> below).<br />
* [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Control-Monad-Trans-Cont.html <code>ContT</code>] adds continuation handling.<br />
<br />
For example, <code>StateT s Maybe</code> is an instance of <code>Monad</code>; computations of type <code>StateT s Maybe a</code> may fail, and have access to a mutable state of type <code>s</code>. Monad transformers can be multiply stacked. One thing to keep in mind while using monad transformers is that the order of composition matters. For example, when a <code>StateT s Maybe a</code> computation fails, the state ceases being updated (indeed, it simply disappears); on the other hand, the state of a <code>MaybeT (State s) a</code> computation may continue to be modified even after the computation has "failed". This may seem backwards, but it is correct. Monad transformers build composite monads “inside out”; <code>MaybeT (State s) a</code> is isomorphic to <code>s -> (Maybe a, s)</code>. (Lambdabot has an indispensable <code>@unmtl</code> command which you can use to “unpack” a monad transformer stack in this way.)<br />
Intuitively, the monads become "more fundamental" the further inside the stack you get, and the effects of inner monads "have precedence" over the effects of outer ones. Of course, this is just handwaving, and if you are unsure of the proper order for some monads you wish to combine, there is no substitute for using <code>@unmtl</code> or simply trying out the various options.<br />
<br />
==Definition and laws==<br />
<br />
All monad transformers should implement the <code>MonadTrans</code> type class, defined in <code>Control.Monad.Trans.Class</code>:<br />
<br />
<haskell><br />
class MonadTrans t where<br />
lift :: Monad m => m a -> t m a<br />
</haskell><br />
<br />
It allows arbitrary computations in the base monad <code>m</code> to be “lifted” into computations in the transformed monad <code>t m</code>. (Note that type application associates to the left, just like function application, so <code>t m a = (t m) a</code>.)<br />
<br />
<code>lift</code> must satisfy the laws<br />
<haskell><br />
lift . return = return<br />
lift (m >>= f) = lift m >>= (lift . f)<br />
</haskell><br />
which intuitively state that <code>lift</code> transforms <code>m a</code> computations into <code>t m a</code> computations in a "sensible" way, which sends the <code>return</code> and <code>(>>=)</code> of <code>m</code> to the <code>return</code> and <code>(>>=)</code> of <code>t m</code>.<br />
<br />
{{Exercises|<br />
# What is the kind of <code>t</code> in the declaration of <code>MonadTrans</code>?<br />
}}<br />
<br />
==Transformer type classes and "capability" style==<br />
<br />
{{note|The only problem with this scheme is the quadratic number of instances required as the number of standard monad transformers grows—but as the current set of standard monad transformers seems adequate for most common use cases, this may not be that big of a deal.}}<br />
<br />
There are also type classes (provided by the [http://hackage.haskell.org/package/mtl <code>mtl</code> package]) for the operations of each transformer. For example, the <code>MonadState</code> type class provides the state-specific methods <code>get</code> and <code>put</code>, allowing you to conveniently use these methods not only with <code>State</code>, but with any monad which is an instance of <code>MonadState</code>—including <code>MaybeT (State s)</code>, <code>StateT s (ReaderT r IO)</code>, and so on. Similar type classes exist for <code>Reader</code>, <code>Writer</code>, <code>Cont</code>, <code>IO</code>, and others {{noteref}}.<br />
<br />
These type classes serve two purposes. First, they get rid of (most of) the need for explicitly using <code>lift</code>, giving a type-directed way to automatically determine the right number of calls to <code>lift</code>. Simply writing <code>put</code> will be automatically translated into <code>lift . put</code>, <code>lift . lift . put</code>, or something similar depending on what concrete monad stack you are using.<br />
<br />
Second, they give you more flexibility to switch between different concrete monad stacks. For example, if you are writing a state-based algorithm, don't write<br />
<haskell><br />
foo :: State Int Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
but rather<br />
<haskell><br />
foo :: MonadState Int m => m Char<br />
foo = modify (*2) >> return 'x'<br />
</haskell><br />
Now, if somewhere down the line you realize you need to introduce the possibility of failure, you might switch from <code>State Int</code> to <code>MaybeT (State Int)</code>. The type of the first version of <code>foo</code> would need to be modified to reflect this change, but the second version of <code>foo</code> can still be used as-is.<br />
<br />
However, this sort of "capability-based" style (<i>e.g.</i> specifying that <code>foo</code> works for any monad with the "state capability") quickly runs into problems when you try to naively scale it up: for example, what if you need to maintain two independent states? A framework for solving this and related problems is described by Schrijvers and Olivera ([http://users.ugent.be/~tschrijv/Research/papers/icfp2011.pdf Monads, zippers and views: virtualizing the monad stack, ICFP 2011]) and is implemented in the [http://hackage.haskell.org/package/Monatron <code>Monatron</code> package].<br />
<br />
==Composing monads==<br />
<br />
Is the composition of two monads always a monad? As hinted previously, the answer is no.<br />
<br />
Since <code>Applicative</code> functors are closed under composition, the problem must lie with <code>join</code>. Indeed, suppose <code>m</code> and <code>n</code> are arbitrary monads; to make a monad out of their composition we would need to be able to implement<br />
<haskell><br />
join :: m (n (m (n a))) -> m (n a)<br />
</haskell><br />
but it is not clear how this could be done in general. The <code>join</code> method for <code>m</code> is no help, because the two occurrences of <code>m</code> are not next to each other (and likewise for <code>n</code>).<br />
<br />
However, one situation in which it can be done is if <code>n</code> ''distributes'' over <code>m</code>, that is, if there is a function<br />
<haskell><br />
distrib :: n (m a) -> m (n a)<br />
</haskell><br />
satisfying certain laws. See Jones and Duponcheel ([http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.2605 Composing Monads]); see also the [[#Traversable|section on Traversable]].<br />
<br />
For a much more in-depth discussion and analysis of the failure of monads to be closed under composition, see [http://stackoverflow.com/questions/13034229/concrete-example-showing-that-monads-are-not-closed-under-composition-with-proo?lq=1 this question on StackOverflow].<br />
<br />
{{Exercises|<br />
* Implement <code>join :: M (N (M (N a))) -> M (N a)</code>, given <code>distrib :: N (M a) -> M (N a)</code> and assuming <code>M</code> and <code>N</code> are instances of <code>Monad</code>.<br />
}}<br />
<br />
==Further reading==<br />
<br />
Much of the monad transformer library (originally [http://hackage.haskell.org/package/mtl <code>mtl</code>], now split between <code>mtl</code> and [http://hackage.haskell.org/package/transformers <code>transformers</code>]), including the <code>Reader</code>, <code>Writer</code>, <code>State</code>, and other monads, as well as the monad transformer framework itself, was inspired by Mark Jones’s classic paper [http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Functional Programming with Overloading and Higher-Order Polymorphism]. It’s still very much worth a read—and highly readable—after almost fifteen years.<br />
<br />
See [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17139 Edward Kmett's mailing list message] for a description of the history and relationships among monad transformer packages (<code>mtl</code>, <code>transformers</code>, <code>monads-fd</code>, <code>monads-tf</code>).<br />
<br />
There are two excellent references on monad transformers. Martin Grabmüller’s [http://www.grabmueller.de/martin/www/pub/Transformers.en.html Monad Transformers Step by Step] is a thorough description, with running examples, of how to use monad transformers to elegantly build up computations with various effects. [http://cale.yi.org/index.php/How_To_Use_Monad_Transformers Cale Gibbard’s article] on how to use monad transformers is more practical, describing how to structure code using monad transformers to make writing it as painless as possible. Another good starting place for learning about monad transformers is a [http://blog.sigfpe.com/2006/05/grok-haskell-monad-transformers.html blog post by Dan Piponi].<br />
<br />
The <code>ListT</code> transformer from the <code>transformers</code> package comes with the caveat that <code>ListT m</code> is only a monad when <code>m</code> is ''commutative'', that is, when <code>ma >>= \a -> mb >>= \b -> foo</code> is equivalent to <code>mb >>= \b -> ma >>= \a -> foo</code> (i.e. the order of <code>m</code>'s effects does not matter). For one explanation why, see Dan Piponi's blog post [http://blog.sigfpe.com/2006/11/why-isnt-listt-monad.html "Why isn't <code><nowiki>ListT []</nowiki></code> a monad"]. For more examples, as well as a design for a version of <code>ListT</code> which does not have this problem, see [http://www.haskell.org/haskellwiki/ListT_done_right <code>ListT</code> done right].<br />
<br />
There is an alternative way to compose monads, using coproducts, as described by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.3581 Lüth and Ghani]. This method is interesting but has not (yet?) seen widespread use. For a more recent alternative, see Kiselyov et al's [http://okmij.org/ftp/Haskell/extensible/exteff.pdf Extensible Effects: An Alternative to Monad Transformers].<br />
<br />
=MonadFix=<br />
<br />
''Note: <code>MonadFix</code> is included here for completeness (and because it is interesting) but seems not to be used much. Skipping this section on a first read-through is perfectly OK (and perhaps even recommended).''<br />
<br />
==<code>mdo</code>/<code>do rec</code> notation==<br />
<br />
{{note|In GHC 7.6, the flag has been changed to <code>-XRecursiveDo</code>.}}<br />
The <code>MonadFix</code> class describes monads which support the special fixpoint operation <code>mfix :: (a -> m a) -> m a</code>, which allows the output of monadic computations to be defined via (effectful) recursion. This is [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation supported in GHC] by a special “recursive do” notation, enabled by the <code>-XDoRec</code> flag{{noteref}}. Within a <code>do</code> block, one may have a nested <code>rec</code> block, like so:<br />
<haskell><br />
do { x <- foo<br />
; rec { y <- baz<br />
; z <- bar<br />
; bob<br />
}<br />
; w <- frob<br />
}<br />
</haskell><br />
Normally (if we had <code>do</code> in place of <code>rec</code> in the above example), <code>y</code> would be in scope in <code>bar</code> and <code>bob</code> but not in <code>baz</code>, and <code>z</code> would be in scope only in <code>bob</code>. With the <code>rec</code>, however, <code>y</code> and <code>z</code> are both in scope in all three of <code>baz</code>, <code>bar</code>, and <code>bob</code>. A <code>rec</code> block is analogous to a <code>let</code> block such as<br />
<haskell><br />
let { y = baz<br />
; z = bar<br />
}<br />
in bob<br />
</haskell><br />
because, in Haskell, every variable bound in a <code>let</code>-block is in scope throughout the entire block. (From this point of view, Haskell's normal <code>do</code> blocks are analogous to Scheme's <code>let*</code> construct.)<br />
<br />
What could such a feature be used for? One of the motivating examples given in the original paper describing <code>MonadFix</code> (see below) is encoding circuit descriptions. A line in a <code>do</code>-block such as <br />
<haskell><br />
x <- gate y z<br />
</haskell><br />
describes a gate whose input wires are labeled <code>y</code> and <code>z</code> and whose output wire is labeled <code>x</code>. Many (most?) useful circuits, however, involve some sort of feedback loop, making them impossible to write in a normal <code>do</code>-block (since some wire would have to be mentioned as an input ''before'' being listed as an output). Using a <code>rec</code> block solves this problem.<br />
<br />
==Examples and intuition==<br />
<br />
Of course, not every monad supports such recursive binding. However, as mentioned above, it suffices to have an implementation of <code>mfix :: (a -> m a) -> m a</code>, satisfying a few laws. Let's try implementing <code>mfix</code> for the <code>Maybe</code> monad. That is, we want to implement a function<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
</haskell><br />
{{note|Actually, <code>fix</code> is implemented slightly differently for efficiency reasons; but the given definition is equivalent and simpler for the present purpose.}}<br />
Let's think for a moment about the implementation {{noteref}} of the non-monadic <code>fix :: (a -> a) -> a</code>:<br />
<haskell><br />
fix f = f (fix f)<br />
</haskell><br />
Inspired by <code>fix</code>, our first attempt at implementing <code>maybeFix</code> might be something like<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = maybeFix f >>= f<br />
</haskell><br />
This has the right type. However, something seems wrong: there is nothing in particular here about <code>Maybe</code>; <code>maybeFix</code> actually has the more general type <code>Monad m => (a -> m a) -> m a</code>. But didn't we just say that not all monads support <code>mfix</code>?<br />
<br />
The answer is that although this implementation of <code>maybeFix</code> has the right type, it does ''not'' have the intended semantics. If we think about how <code>(>>=)</code> works for the <code>Maybe</code> monad (by pattern-matching on its first argument to see whether it is <code>Nothing</code> or <code>Just</code>) we can see that this definition of <code>maybeFix</code> is completely useless: it will just recurse infinitely, trying to decide whether it is going to return <code>Nothing</code> or <code>Just</code>, without ever even so much as a glance in the direction of <code>f</code>.<br />
<br />
The trick is to simply ''assume'' that <code>maybeFix</code> will return <code>Just</code>, and get on with life!<br />
<haskell><br />
maybeFix :: (a -> Maybe a) -> Maybe a<br />
maybeFix f = ma<br />
where ma = f (fromJust ma)<br />
</haskell><br />
This says that the result of <code>maybeFix</code> is <code>ma</code>, and assuming that <code>ma = Just x</code>, it is defined (recursively) to be equal to <code>f x</code>.<br />
<br />
Why is this OK? Isn't <code>fromJust</code> almost as bad as <code>unsafePerformIO</code>? Well, usually, yes. This is just about the only situation in which it is justified! The interesting thing to note is that <code>maybeFix</code> ''will never crash'' -- although it may, of course, fail to terminate. The only way we could get a crash is if we try to evaluate <code>fromJust ma</code> when we know that <code>ma = Nothing</code>. But how could we know <code>ma = Nothing</code>? Since <code>ma</code> is defined as <code>f (fromJust ma)</code>, it must be that this expression has already been evaluated to <code>Nothing</code> -- in which case there is no reason for us to be evaluating <code>fromJust ma</code> in the first place! <br />
<br />
To see this from another point of view, we can consider three possibilities. First, if <code>f</code> outputs <code>Nothing</code> without looking at its argument, then <code>maybeFix f</code> clearly returns <code>Nothing</code>. Second, if <code>f</code> always outputs <code>Just x</code>, where <code>x</code> depends on its argument, then the recursion can proceed usefully: <code>fromJust ma</code> will be able to evaluate to <code>x</code>, thus feeding <code>f</code>'s output back to it as input. Third, if <code>f</code> tries to use its argument to decide whether to output <code>Just</code> or <code>Nothing</code>, then <code>maybeFix f</code> will not terminate: evaluating <code>f</code>'s argument requires evaluating <code>ma</code> to see whether it is <code>Just</code>, which requires evaluating <code>f (fromJust ma)</code>, which requires evaluating <code>ma</code>, ... and so on.<br />
<br />
There are also instances of <code>MonadFix</code> for lists (which works analogously to the instance for <code>Maybe</code>), for <code>ST</code>, and for <code>IO</code>. The [http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/System-IO.html#fixIO instance for <code>IO</code>] is particularly amusing: it creates a new (empty) <code>MVar</code>, immediately reads its contents using <code>unsafeInterleaveIO</code> (which delays the actual reading lazily until the value is needed), uses the contents of the <code>MVar</code> to compute a new value, which it then writes back into the <code>MVar</code>. It almost seems, spookily, that <code>mfix</code> is sending a value back in time to itself through the <code>MVar</code> -- though of course what is really going on is that the reading is delayed just long enough (via <code>unsafeInterleaveIO</code>) to get the process bootstrapped.<br />
<br />
{{Exercises|<br />
* Implement a <code>MonadFix</code> instance for <code>[]</code>.<br />
}}<br />
<br />
==GHC 7.6 changes==<br />
<br />
GHC 7.6 reinstated the old <code>mdo</code> syntax, so the example at the start of this section can be written<br />
<br />
<haskell><br />
mdo { x <- foo<br />
; y <- baz<br />
; z <- bar<br />
; bob<br />
; w <- frob<br />
}<br />
</haskell><br />
<br />
which will be translated into the original example (assuming that, say, <code>bar</code> and <code>bob</code> refer to <code>y</code>. The difference is that <code>mdo</code> will analyze the code in order to find minimal recursive blocks, which will be placed in <code>rec</code> blocks, whereas <code>rec</code> blocks desugar directly into calls to <code>mfix</code> without any further analysis. <br />
==Further reading==<br />
<br />
For more information (such as the precise desugaring rules for <code>rec</code> blocks), see Levent Erkök and John Launchbury's 2002 Haskell workshop paper, [http://sites.google.com/site/leventerkok/recdo.pdf?attredirects=0 A Recursive do for Haskell], or for full details, Levent Erkök’s thesis, [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.15.1543&rep=rep1&type=pdf Value Recursion in Monadic Computations]. (Note, while reading, that <code>MonadFix</code> used to be called <code>MonadRec</code>.) You can also read the [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#recursive-do-notation GHC user manual section on recursive do-notation].<br />
<br />
=Semigroup=<br />
<br />
A semigroup is a set <math>S\ </math> together with a binary operation <math>\oplus\ </math> which<br />
combines elements from <math>S\ </math>. The <math>\oplus\ </math> operator is required to be associative<br />
(that is, <math>(a \oplus b) \oplus c = a \oplus (b \oplus c)\ </math>, for any<br />
<math>a,b,c\ </math> which are elements of <math>S\ </math>).<br />
<br />
For example, the natural numbers under addition form a semigroup: the sum of any two natural numbers is a natural number, and <math>(a+b)+c = a+(b+c)\ </math> for any natural numbers <math>a\ </math>, <math>b\ </math>, and <math>c\,\ </math>. The integers under multiplication also form a semigroup, as do the integers (or rationals, or reals) under <math>\max\ </math> or <math>\min\ </math>, Boolean values under conjunction and disjunction, lists under concatenation, functions from a set to itself under composition ... Semigroups show up all over the place, once you know to look for them.<br />
<br />
==Definition==<br />
<br />
Semigroups are not (yet?) defined in the base package, but the {{HackagePackage|id=semigroups}} package provides a standard definition.<br />
<br />
The definition of the <code>Semigroup</code> type class ([http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock]) is as follows:<br />
<br />
<haskell><br />
class Semigroup a where<br />
(<>) :: a -> a -> a<br />
<br />
sconcat :: NonEmpty a -> a<br />
sconcat = sconcat (a :| as) = go a as where<br />
go b (c:cs) = b <> go c cs<br />
go b [] = b<br />
<br />
times1p :: Whole n => n -> a -> a<br />
times1p = ...<br />
</haskell><br />
<br />
The really important method is <code>(<>)</code>, representing the associative binary operation. The other two methods have default implementations in terms of <code>(<>)</code>, and are included in the type class in case some instances can give more efficient implementations than the default. <code>sconcat</code> reduces a nonempty list using <code>(<>)</code>; <code>times1p n</code> is equivalent to (but more efficient than) <code>sconcat . replicate n</code>. See the [http://hackage.haskell.org/packages/archive/semigroups/latest/doc/html/Data-Semigroup.html haddock documentation] for more information on <code>sconcat</code> and <code>times1p</code>.<br />
<br />
==Laws==<br />
<br />
The only law is that <code>(<>)</code> must be associative:<br />
<br />
<haskell><br />
(x <> y) <> z = x <> (y <> z)<br />
</haskell><br />
<br />
=Monoid=<br />
<br />
Many semigroups have a special element <math>e</math> for which the binary operation <math>\oplus</math> is the identity, that is, <math>e \oplus x = x \oplus e = x</math> for every element <math>x</math>. Such a semigroup-with-identity-element is called a ''monoid''.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Monoid</code> type class (defined in<br />
<code>Data.Monoid</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html haddock]) is:<br />
<br />
<haskell><br />
class Monoid a where<br />
mempty :: a<br />
mappend :: a -> a -> a<br />
<br />
mconcat :: [a] -> a<br />
mconcat = foldr mappend mempty<br />
</haskell><br />
<br />
The <code>mempty</code> value specifies the identity element of the monoid, and <code>mappend</code><br />
is the binary operation. The default definition for <code>mconcat</code><br />
“reduces” a list of elements by combining them all with <code>mappend</code>,<br />
using a right fold. It is only in the <code>Monoid</code> class so that specific<br />
instances have the option of providing an alternative, more efficient<br />
implementation; usually, you can safely ignore <code>mconcat</code> when creating<br />
a <code>Monoid</code> instance, since its default definition will work just fine.<br />
<br />
The <code>Monoid</code> methods are rather unfortunately named; they are inspired<br />
by the list instance of <code>Monoid</code>, where indeed <code>mempty = []</code> and <code>mappend = (++)</code>, but this is misleading since many<br />
monoids have little to do with appending (see these [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 Comments from OCaml Hacker Brian Hurt] on the Haskell-cafe mailing list). This was improved in GHC 7.4, where <code>(<>)</code> was added as an alias to <code>mappend</code>.<br />
<br />
==Laws==<br />
<br />
Of course, every <code>Monoid</code> instance should actually be a monoid in the<br />
mathematical sense, which implies these laws:<br />
<br />
<haskell><br />
mempty `mappend` x = x<br />
x `mappend` mempty = x<br />
(x `mappend` y) `mappend` z = x `mappend` (y `mappend` z)<br />
</haskell><br />
<br />
==Instances==<br />
<br />
There are quite a few interesting <code>Monoid</code> instances defined in <code>Data.Monoid</code>.<br />
<br />
<ul><br />
<li><code>[a]</code> is a <code>Monoid</code>, with <code>mempty = []</code> and <code>mappend = (++)</code>. It is not hard to check that <code>(x ++ y) ++ z = x ++ (y ++ z)</code> for any lists <code>x</code>, <code>y</code>, and <code>z</code>, and that the empty list is the identity: <code>[] ++ x = x ++ [] = x</code>.</li><br />
<br />
<li>As noted previously, we can make a monoid out of any numeric type under either addition or multiplication. However, since we can’t have two instances for the same type, <code>Data.Monoid</code> provides two <code>newtype</code> wrappers, <code>Sum</code> and <code>Product</code>, with appropriate <code>Monoid</code> instances.<br />
<br />
<haskell><br />
> getSum (mconcat . map Sum $ [1..5])<br />
15<br />
> getProduct (mconcat . map Product $ [1..5])<br />
120<br />
</haskell><br />
<br />
This example code is silly, of course; we could just write<br />
<code>sum [1..5]</code> and <code>product [1..5]</code>. Nevertheless, these instances are useful in more generalized settings, as we will see in the [[Foldable|section on <code>Foldable</code>]].</li><br />
<br />
<li><code>Any</code> and <code>All</code> are <code>newtype</code> wrappers providing <code>Monoid</code> instances for <code>Bool</code> (under disjunction and conjunction, respectively).</li><br />
<br />
<li> There are three instances for <code>Maybe</code>: a basic instance which lifts a <code>Monoid</code> instance for <code>a</code> to an instance for <code>Maybe a</code>, and two <code>newtype</code> wrappers <code>First</code> and <code>Last</code> for which <code>mappend</code> selects the first (respectively last) non-<code>Nothing</code> item.</li><br />
<br />
<li><code>Endo a</code> is a newtype wrapper for functions <code>a -> a</code>, which form a monoid under composition.</li><br />
<br />
<li>There are several ways to “lift” <code>Monoid</code> instances to instances with additional structure. We have already seen that an instance for <code>a</code> can be lifted to an instance for <code>Maybe a</code>. There are also tuple instances: if <code>a</code> and <code>b</code> are instances of <code>Monoid</code>, then so is <code>(a,b)</code>, using the monoid operations for <code>a</code> and <code>b</code> in the obvious pairwise manner. Finally, if <code>a</code> is a <code>Monoid</code>, then so is the function type <code>e -> a</code> for any <code>e</code>; in particular, <code>g `mappend` h</code> is the function which applies both <code>g</code> and <code>h</code> to its argument and then combines the results using the underlying <code>Monoid</code> instance for <code>a</code>. This can be quite useful and elegant (see [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/52416 example]).</li><br />
<br />
<li>The type <code>Ordering = LT | EQ | GT</code> is a <code>Monoid</code>, defined in such a way that <code>mconcat (zipWith compare xs ys)</code> computes the lexicographic ordering of <code>xs</code> and <code>ys</code> (if <code>xs</code> and <code>ys</code> have the same length). In particular, <code>mempty = EQ</code>, and <code>mappend</code> evaluates to its leftmost non-<code>EQ</code> argument (or <code>EQ</code> if both arguments are <code>EQ</code>). This can be used together with the function instance of <code>Monoid</code> to do some clever things ([http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx example]).</li><br />
<br />
<li>There are also <code>Monoid</code> instances for several standard data structures in the containers library ([http://hackage.haskell.org/packages/archive/containers/0.2.0.0/doc/html/index.html haddock]), including <code>Map</code>, <code>Set</code>, and <code>Sequence</code>.</li><br />
</ul><br />
<br />
<code>Monoid</code> is also used to enable several other type class instances.<br />
As noted previously, we can use <code>Monoid</code> to make <code>((,) e)</code> an instance of <code>Applicative</code>:<br />
<br />
<haskell><br />
instance Monoid e => Applicative ((,) e) where<br />
pure x = (mempty, x)<br />
(u, f) <*> (v, x) = (u `mappend` v, f x)<br />
</haskell><br />
<br />
<code>Monoid</code> can be similarly used to make <code>((,) e)</code> an instance of <code>Monad</code> as well; this is known as the ''writer monad''. As we’ve already seen, <code>Writer</code> and <code>WriterT</code> are a newtype wrapper and transformer for this monad, respectively.<br />
<br />
<code>Monoid</code> also plays a key role in the <code>Foldable</code> type class (see section [[#Foldable|Foldable]]).<br />
<br />
==Other monoidal classes: Alternative, MonadPlus, ArrowPlus==<br />
<br />
The <code>Alternative</code> type class ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html#g:2 haddock])<br />
is for <code>Applicative</code> functors which also have<br />
a monoid structure:<br />
<br />
<haskell><br />
class Applicative f => Alternative f where<br />
empty :: f a<br />
(<|>) :: f a -> f a -> f a<br />
</haskell><br />
<br />
Of course, instances of <code>Alternative</code> should satisfy the monoid laws<br />
<br />
<haskell><br />
empty <|> x = x<br />
x <|> empty = x<br />
(x <|> y) <|> z = x <|> (y <|> z)<br />
</haskell><br />
<br />
Likewise, <code>MonadPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html#t:MonadPlus haddock])<br />
is for <code>Monad</code>s with a monoid structure:<br />
<br />
<haskell><br />
class Monad m => MonadPlus m where<br />
mzero :: m a<br />
mplus :: m a -> m a -> m a<br />
</haskell><br />
<br />
The <code>MonadPlus</code> documentation states that it is intended to model<br />
monads which also support “choice and failure”; in addition to the<br />
monoid laws, instances of <code>MonadPlus</code> are expected to satisfy<br />
<br />
<haskell><br />
mzero >>= f = mzero<br />
v >> mzero = mzero<br />
</haskell><br />
<br />
which explains the sense in which <code>mzero</code> denotes failure. Since<br />
<code>mzero</code> should be the identity for <code>mplus</code>, the computation <code>m1 `mplus` m2</code> succeeds (evaluates to something other than <code>mzero</code>) if<br />
either <code>m1</code> or <code>m2</code> does; so <code>mplus</code> represents choice. The <code>guard</code><br />
function can also be used with instances of <code>MonadPlus</code>; it requires a<br />
condition to be satisfied and fails (using <code>mzero</code>) if it is not. A<br />
simple example of a <code>MonadPlus</code> instance is <code>[]</code>, which is exactly the<br />
same as the <code>Monoid</code> instance for <code>[]</code>: the empty list represents<br />
failure, and list concatenation represents choice. In general,<br />
however, a <code>MonadPlus</code> instance for a type need not be the same as its<br />
<code>Monoid</code> instance; <code>Maybe</code> is an example of such a type. A great<br />
introduction to the <code>MonadPlus</code> type class, with interesting examples<br />
of its use, is Doug Auclair’s ''MonadPlus: What a Super Monad!'' in [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad.Reader issue 11].<br />
<br />
There used to be a type class called <code>MonadZero</code> containing only<br />
<code>mzero</code>, representing monads with failure. The <code>do</code>-notation requires<br />
some notion of failure to deal with failing pattern matches.<br />
Unfortunately, <code>MonadZero</code> was scrapped in favor of adding the <code>fail</code><br />
method to the <code>Monad</code> class. If we are lucky, someday <code>MonadZero</code> will<br />
be restored, and <code>fail</code> will be banished to the bit bucket where it<br />
belongs (see [[MonadPlus reform proposal]]). The idea is that any<br />
<code>do</code>-block which uses pattern matching (and hence may fail) would require<br />
a <code>MonadZero</code> constraint; otherwise, only a <code>Monad</code> constraint would be<br />
required.<br />
<br />
Finally, <code>ArrowZero</code> and <code>ArrowPlus</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#t:ArrowZero haddock])<br />
represent <code>Arrow</code>s ([[#Arrow|see below]]) with a<br />
monoid structure:<br />
<br />
<haskell><br />
class Arrow arr => ArrowZero arr where<br />
zeroArrow :: b `arr` c<br />
<br />
class ArrowZero arr => ArrowPlus arr where<br />
(<+>) :: (b `arr` c) -> (b `arr` c) -> (b `arr` c)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Monoids have gotten a fair bit of attention recently, ultimately due<br />
to<br />
[http://enfranchisedmind.com/blog/posts/random-thoughts-on-haskell/ a blog post by Brian Hurt], in which he<br />
complained about the fact that the names of many Haskell type classes<br />
(<code>Monoid</code> in particular) are taken from abstract mathematics. This<br />
resulted in [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/50590 a long Haskell-cafe thread]<br />
arguing the point and discussing monoids in general.<br />
<br />
{{note|May its name live forever.}}<br />
<br />
However, this was quickly followed by several blog posts about<br />
<code>Monoid</code> {{noteref}}. First, Dan Piponi<br />
wrote a great introductory post, [http://blog.sigfpe.com/2009/01/haskell-monoids-and-their-uses.html Haskell Monoids and their Uses]. This was quickly followed by<br />
Heinrich Apfelmus’s [http://apfelmus.nfshost.com/monoid-fingertree.html Monoids and Finger Trees], an accessible exposition of<br />
Hinze and Paterson’s [http://www.soi.city.ac.uk/%7Eross/papers/FingerTree.html classic paper on 2-3 finger trees], which makes very clever<br />
use of <code>Monoid</code> to implement an elegant and generic data structure.<br />
Dan Piponi then wrote two fascinating articles about using <code>Monoids</code><br />
(and finger trees): [http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html Fast Incremental Regular Expressions] and [http://blog.sigfpe.com/2009/01/beyond-regular-expressions-more.html Beyond Regular Expressions]<br />
<br />
In a similar vein, David Place’s article on improving <code>Data.Map</code> in<br />
order to compute incremental folds (see [http://www.haskell.org/wikiupload/6/6a/TMR-Issue11.pdf the Monad Reader issue 11])<br />
is also a<br />
good example of using <code>Monoid</code> to generalize a data structure.<br />
<br />
Some other interesting examples of <code>Monoid</code> use include [http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx building elegant list sorting combinators], [http://byorgey.wordpress.com/2008/04/17/collecting-unstructured-information-with-the-monoid-of-partial-knowledge/ collecting unstructured information], [http://izbicki.me/blog/gausian-distributions-are-monoids combining probability distributions], and a brilliant series of posts by Chung-Chieh Shan and Dylan Thurston using <code>Monoid</code>s to [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers1/ elegantly solve a difficult combinatorial puzzle] (followed by [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers2/ part 2], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers3/ part 3], [http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers4/ part 4]).<br />
<br />
As unlikely as it sounds, monads can actually be viewed as a sort of<br />
monoid, with <code>join</code> playing the role of the binary operation and<br />
<code>return</code> the role of the identity; see [http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html Dan Piponi’s blog post].<br />
<br />
=Foldable=<br />
<br />
The <code>Foldable</code> class, defined in the <code>Data.Foldable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html haddock]), abstracts over containers which can be<br />
“folded” into a summary value. This allows such folding operations<br />
to be written in a container-agnostic way.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Foldable</code> type class is:<br />
<br />
<haskell><br />
class Foldable t where<br />
fold :: Monoid m => t m -> m<br />
foldMap :: Monoid m => (a -> m) -> t a -> m<br />
<br />
foldr :: (a -> b -> b) -> b -> t a -> b<br />
foldl :: (a -> b -> a) -> a -> t b -> a<br />
foldr1 :: (a -> a -> a) -> t a -> a<br />
foldl1 :: (a -> a -> a) -> t a -> a<br />
</haskell><br />
<br />
This may look complicated, but in fact, to make a <code>Foldable</code> instance<br />
you only need to implement one method: your choice of <code>foldMap</code> or<br />
<code>foldr</code>. All the other methods have default implementations in terms<br />
of these, and are presumably included in the class in case more<br />
efficient implementations can be provided.<br />
<br />
==Instances and examples==<br />
<br />
The type of <code>foldMap</code> should make it clear what it is supposed to do:<br />
given a way to convert the data in a container into a <code>Monoid</code> (a<br />
function <code>a -> m</code>) and a container of <code>a</code>’s (<code>t a</code>), <code>foldMap</code><br />
provides a way to iterate over the entire contents of the container,<br />
converting all the <code>a</code>’s to <code>m</code>’s and combining all the <code>m</code>’s with<br />
<code>mappend</code>. The following code shows two examples: a simple<br />
implementation of <code>foldMap</code> for lists, and a binary tree example<br />
provided by the <code>Foldable</code> documentation.<br />
<br />
<haskell><br />
instance Foldable [] where<br />
foldMap g = mconcat . map g<br />
<br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Foldable Tree where<br />
foldMap f Empty = mempty<br />
foldMap f (Leaf x) = f x<br />
foldMap f (Node l k r) = foldMap f l `mappend` f k `mappend` foldMap f r<br />
</haskell><br />
<br />
The <code>foldr</code> function has a type similar to the <code>foldr</code> found in the <code>Prelude</code>, but<br />
more general, since the <code>foldr</code> in the <code>Prelude</code> works only on lists.<br />
<br />
The <code>Foldable</code> module also provides instances for <code>Maybe</code> and <code>Array</code>;<br />
additionally, many of the data structures found in the standard [http://hackage.haskell.org/package/containers containers library] (for example, <code>Map</code>, <code>Set</code>, <code>Tree</code>,<br />
and <code>Sequence</code>) provide their own <code>Foldable</code> instances.<br />
<br />
{{Exercises|<br />
# What is the type of <code>foldMap . foldMap</code>? Or <code>foldMap . foldMap . foldMap</code>, etc.? What do they do?<br />
}}<br />
<br />
==Derived folds==<br />
<br />
Given an instance of <code>Foldable</code>, we can write generic,<br />
container-agnostic functions such as:<br />
<br />
<haskell><br />
-- Compute the size of any container.<br />
containerSize :: Foldable f => f a -> Int<br />
containerSize = getSum . foldMap (const (Sum 1))<br />
<br />
-- Compute a list of elements of a container satisfying a predicate.<br />
filterF :: Foldable f => (a -> Bool) -> f a -> [a]<br />
filterF p = foldMap (\a -> if p a then [a] else [])<br />
<br />
-- Get a list of all the Strings in a container which include the<br />
-- letter a.<br />
aStrings :: Foldable f => f String -> [String]<br />
aStrings = filterF (elem 'a')<br />
</haskell><br />
<br />
The <code>Foldable</code> module also provides a large number of predefined<br />
folds, many of which are generalized versions of <code>Prelude</code> functions of the<br />
same name that only work on lists: <code>concat</code>, <code>concatMap</code>, <code>and</code>,<br />
<code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>),<br />
<code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>.<br />
<br />
The important function <code>toList</code> is also provided, which turns any <code>Foldable</code> structure into a list of its elements in left-right order; it works by folding with the list monoid.<br />
<br />
There are also generic functions that work with <code>Applicative</code> or<br />
<code>Monad</code> instances to generate some sort of computation from each<br />
element in a container, and then perform all the side effects from<br />
those computations, discarding the results: <code>traverse_</code>, <code>sequenceA_</code>,<br />
and others. The results must be discarded because the <code>Foldable</code><br />
class is too weak to specify what to do with them: we cannot, in<br />
general, make an arbitrary <code>Applicative</code> or <code>Monad</code> instance into a <code>Monoid</code>, but we can make <code>m ()</code> into a <code>Monoid</code> for any such <code>m</code>. If we do have an <code>Applicative</code> or <code>Monad</code> with a monoid<br />
structure—that is, an <code>Alternative</code> or a <code>MonadPlus</code>—then we can<br />
use the <code>asum</code> or <code>msum</code> functions, which can combine the results as<br />
well. Consult the [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html <code>Foldable</code> documentation] for<br />
more details on any of these functions.<br />
<br />
Note that the <code>Foldable</code> operations always forget the structure of<br />
the container being folded. If we start with a container of type <code>t a</code> for some <code>Foldable t</code>, then <code>t</code> will never appear in the output<br />
type of any operations defined in the <code>Foldable</code> module. Many times<br />
this is exactly what we want, but sometimes we would like to be able<br />
to generically traverse a container while preserving its<br />
structure—and this is exactly what the <code>Traversable</code> class provides,<br />
which will be discussed in the next section.<br />
<br />
{{Exercises|<br />
# Implement <code>toList :: Foldable f {{=}}> f a -> [a]</code>.<br />
# Pick some of the following functions to implement: <code>concat</code>, <code>concatMap</code>, <code>and</code>, <code>or</code>, <code>any</code>, <code>all</code>, <code>sum</code>, <code>product</code>, <code>maximum</code>(<code>By</code>), <code>minimum</code>(<code>By</code>), <code>elem</code>, <code>notElem</code>, and <code>find</code>. Figure out how they generalize to <code>Foldable</code> and come up with elegant implementations using <code>fold</code> or <code>foldMap</code> along with appropriate <code>Monoid</code> instances.<br />
}}<br />
<br />
==Foldable actually isn't==<br />
<br />
The generic term "fold" is often used to refer to the more technical concept of [[Catamorphisms|catamorphism]]. Intuitively, given a way to summarize "one level of structure" (where recursive subterms have already been replaced with their summaries), a catamorphism can summarize an entire recursive structure. It is important to realize that <code>Foldable</code> does <i>not</i> correspond to catamorphisms, but to something weaker. In particular, <code>Foldable</code> allows observing only the left-right order of elements within a structure, not the actual structure itself. Put another way, every use of <code>Foldable</code> can be expressed in terms of <code>toList</code>. For example, <code>fold</code> itself is equivalent to <code>mconcat . toList</code>.<br />
<br />
This is sufficient for many tasks, but not all. For example, consider trying to compute the depth of a <code>Tree</code>: try as we might, there is no way to implement it using <code>Foldable</code>. However, it <i>can</i> be implemented as a catamorphism.<br />
<br />
==Further reading==<br />
<br />
The <code>Foldable</code> class had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s paper]<br />
introducing <code>Applicative</code>, although it has<br />
been fleshed out quite a bit from the form in the paper.<br />
<br />
An interesting use of <code>Foldable</code> (as well as <code>Traversable</code>) can be<br />
found in Janis Voigtländer’s paper [http://doi.acm.org/10.1145/1480881.1480904 Bidirectionalization for free!].<br />
<br />
=Traversable=<br />
<br />
==Definition==<br />
<br />
The <code>Traversable</code> type class, defined in the <code>Data.Traversable</code><br />
module ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html haddock]), is:<br />
<br />
<haskell><br />
class (Functor t, Foldable t) => Traversable t where<br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
mapM :: Monad m => (a -> m b) -> t a -> m (t b)<br />
sequence :: Monad m => t (m a) -> m (t a)<br />
</haskell><br />
<br />
As you can see, every <code>Traversable</code> is also a foldable functor. Like<br />
<code>Foldable</code>, there is a lot in this type class, but making instances is<br />
actually rather easy: one need only implement <code>traverse</code> or<br />
<code>sequenceA</code>; the other methods all have default implementations in<br />
terms of these functions. A good exercise is to figure out what the default<br />
implementations should be: given either <code>traverse</code> or <code>sequenceA</code>, how<br />
would you define the other three methods? (Hint for <code>mapM</code>:<br />
<code>Control.Applicative</code> exports the <code>WrapMonad</code> newtype, which makes any<br />
<code>Monad</code> into an <code>Applicative</code>. The <code>sequence</code> function can be implemented in terms<br />
of <code>mapM</code>.)<br />
<br />
==Intuition==<br />
<br />
The key method of the <code>Traversable</code> class, and the source of its<br />
unique power, is <code>sequenceA</code>. Consider its type:<br />
<haskell><br />
sequenceA :: Applicative f => t (f a) -> f (t a)<br />
</haskell><br />
This answers the fundamental question: when can we commute two<br />
functors? For example, can we turn a tree of lists into a list of<br />
trees?<br />
<br />
The ability to compose two monads depends crucially on this ability to<br />
commute functors. Intuitively, if we want to build a composed monad<br />
<code>M a = m (n a)</code> out of monads <code>m</code> and <code>n</code>, then to be able to<br />
implement <code>join :: M (M a) -> M a</code>, that is,<br />
<code>join :: m (n (m (n a))) -> m (n a)</code>, we have to be able to commute<br />
the <code>n</code> past the <code>m</code> to get <code>m (m (n (n a)))</code>, and then we can use the<br />
<code>join</code>s for <code>m</code> and <code>n</code> to produce something of type <code>m (n a)</code>. See<br />
[http://web.cecs.pdx.edu/~mpj/pubs/springschool.html Mark Jones’s paper] for more details.<br />
<br />
Alternatively, looking at the type of <code>traverse</code>,<br />
<haskell><br />
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)<br />
</haskell><br />
leads us to view <code>Traversable</code> as a generalization of <code>Functor</code>. <code>traverse</code> is an "effectful <code>fmap</code>": it allows us to map over a structure of type <code>t a</code>, applying a function to every element of type <code>a</code> and in order to produce a new structure of type <code>t b</code>; but along the way the function may have some effects (captured by the applicative functor <code>f</code>).<br />
<br />
{{Exercises|<br />
# There are at least two natural ways to turn a tree of lists into a list of trees. What are they, and why?<br />
# Give a natural way to turn a list of trees into a tree of lists.<br />
# What is the type of <code>traverse . traverse</code>? What does it do?<br />
}}<br />
<br />
==Instances and examples==<br />
<br />
What’s an example of a <code>Traversable</code> instance?<br />
The following code shows an example instance for the same<br />
<code>Tree</code> type used as an example in the previous <code>Foldable</code> section. It<br />
is instructive to compare this instance with a <code>Functor</code> instance for<br />
<code>Tree</code>, which is also shown.<br />
<br />
<haskell><br />
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)<br />
<br />
instance Traversable Tree where<br />
traverse g Empty = pure Empty<br />
traverse g (Leaf x) = Leaf <$> g x<br />
traverse g (Node l x r) = Node <$> traverse g l<br />
<*> g x<br />
<*> traverse g r<br />
<br />
instance Functor Tree where<br />
fmap g Empty = Empty<br />
fmap g (Leaf x) = Leaf $ g x<br />
fmap g (Node l x r) = Node (fmap g l)<br />
(g x)<br />
(fmap g r)<br />
</haskell><br />
<br />
It should be clear that the <code>Traversable</code> and <code>Functor</code> instances for<br />
<code>Tree</code> are almost identical; the only difference is that the <code>Functor</code><br />
instance involves normal function application, whereas the<br />
applications in the <code>Traversable</code> instance take place within an<br />
<code>Applicative</code> context, using <code>(<$>)</code> and <code>(<*>)</code>. In fact, this will<br />
be<br />
true for any type.<br />
<br />
Any <code>Traversable</code> functor is also <code>Foldable</code>, and a <code>Functor</code>. We can see<br />
this not only from the class declaration, but by the fact that we can<br />
implement the methods of both classes given only the <code>Traversable</code><br />
methods.<br />
<br />
The standard libraries provide a number of <code>Traversable</code> instances,<br />
including instances for <code>[]</code>, <code>Maybe</code>, <code>Map</code>, <code>Tree</code>, and <code>Sequence</code>.<br />
Notably, <code>Set</code> is not <code>Traversable</code>, although it is <code>Foldable</code>.<br />
<br />
{{Exercises|<br />
# Implement <code>fmap</code> and <code>foldMap</code> using only the <code>Traversable</code> methods. (Note that the <code>Traversable</code> module provides these implementations as <code>fmapDefault</code> and <code>foldMapDefault</code>.)<br />
}}<br />
<br />
==Laws==<br />
<br />
Any instance of <code>Traversable</code> must satisfy the following two laws, where <code>Identity</code> is the identity functor (as defined in the [http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Data-Functor-Identity.html <code>Data.Functor.Identity</code> module] from the <code>transformers</code> package), and <code>Compose</code> wraps the composition of two functors (as defined in [http://hackage.haskell.org/packages/archive/transformers/0.3.0.0/doc/html/Data-Functor-Compose.html <code>Data.Functor.Compose</code>]):<br />
<br />
# <code>traverse Identity = Identity</code><br />
# <code>traverse (Compose . fmap g . f) = Compose . fmap (traverse g) . traverse f</code><br />
<br />
The first law essentially says that traversals cannot make up arbitrary effects. The second law explains how doing two traversals in sequence can be collapsed to a single traversal.<br />
<br />
Additionally, suppose <code>eta</code> is an "<code>Applicative</code> morphism", that is,<br />
<haskell><br />
eta :: forall a f g. (Applicative f, Applicative g) => f a -> g a<br />
</haskell><br />
and <code>eta</code> preserves the <code>Applicative</code> operations: <code>eta (pure x) = pure x</code> and <code>eta (x <*> y) = eta x <*> eta y</code>. Then, by parametricity, any instance of <code>Traversable</code> satisfying the above two laws will also satisfy <code>eta . traverse f = traverse (eta . f)</code>.<br />
<br />
==Further reading==<br />
<br />
The <code>Traversable</code> class also had its genesis in [http://www.soi.city.ac.uk/~ross/papers/Applicative.html McBride and Paterson’s <code>Applicative</code> paper],<br />
and is described in more detail in Gibbons and Oliveira, [http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf The Essence of the Iterator Pattern],<br />
which also contains a wealth of references to related work.<br />
<br />
<code>Traversable</code> forms a core component of Edward Kmett's [http://hackage.haskell.org/package/lens lens library]. Watching [https://vimeo.com/56063074 Edward's talk on the subject] is a highly recommended way to gain better insight into <code>Traversable</code>, <code>Foldable</code>, <code>Applicative</code>, and many other things besides.<br />
<br />
For references on the <code>Traversable</code> laws, see Russell O'Connor's [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17778 mailing list post] (and subsequent thread).<br />
<br />
=Category=<br />
<br />
<code>Category</code> is a relatively recent addition to the Haskell standard libraries. It generalizes the notion of function composition to general “morphisms”.<br />
<br />
{{note|GHC 7.6.1 changed its rules regarding types and type variables. Now, any operator at the type level is treated as a type ''constructor'' rather than a type ''variable''; prior to GHC 7.6.1 it was possible to use <code>(~&gt;)</code> instead of <code>`arr`</code>. For more information, see [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/21350 the discussion on the GHC-users mailing list]. For a new approach to nice arrow notation that works with GHC 7.6.1, see [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22615 this message] and also [http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/22616 this message] from Edward Kmett, though for simplicity I haven't adopted it here.}}<br />
The definition of the <code>Category</code> type class (from<br />
<code>Control.Category</code>; [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Category.html haddock]) is shown below. For ease of reading, note that I have used an infix type variable <code>`arr`</code>, in parallel with the infix function type constructor <code>(->)</code>. {{noteref}} This syntax is not part of Haskell 2010. The second definition shown is the one used in the standard libraries. For the remainder of this document, I will use the infix type constructor <code>`arr`</code> for <code>Category</code> as well as <code>Arrow</code>.<br />
<br />
<haskell><br />
class Category arr where<br />
id :: a `arr` a<br />
(.) :: (b `arr` c) -> (a `arr` b) -> (a `arr` c)<br />
<br />
-- The same thing, with a normal (prefix) type constructor<br />
class Category cat where<br />
id :: cat a a<br />
(.) :: cat b c -> cat a b -> cat a c<br />
</haskell><br />
<br />
Note that an instance of <code>Category</code> should be a type constructor which takes two type arguments, that is, something of kind <code>* -> * -> *</code>. It is instructive to imagine the type constructor variable <code>cat</code> replaced by the function constructor <code>(->)</code>: indeed, in this case we recover precisely the familiar identity function <code>id</code> and function composition operator <code>(.)</code> defined in the standard <code>Prelude</code>.<br />
<br />
Of course, the <code>Category</code> module provides exactly such an instance of<br />
<code>Category</code> for <code>(->)</code>. But it also provides one other instance, shown below, which should be familiar from the previous discussion of the <code>Monad</code> laws. <code>Kleisli m a b</code>, as defined in the <code>Control.Arrow</code> module, is just a <code>newtype</code> wrapper around <code>a -> m b</code>.<br />
<br />
<haskell><br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Category (Kleisli m) where<br />
id = Kleisli return<br />
Kleisli g . Kleisli h = Kleisli (h >=> g)<br />
</haskell><br />
<br />
The only law that <code>Category</code> instances should satisfy is that <code>id</code> and <code>(.)</code> should form a monoid—that is, <code>id</code> should be the identity of <code>(.)</code>, and <code>(.)</code> should be associative.<br />
<br />
Finally, the <code>Category</code> module exports two additional operators:<br />
<code>(<<<)</code>, which is just a synonym for <code>(.)</code>, and <code>(>>>)</code>, which is <code>(.)</code> with its arguments reversed. (In previous versions of the libraries, these operators were defined as part of the <code>Arrow</code> class.)<br />
<br />
==Further reading==<br />
<br />
The name <code>Category</code> is a bit misleading, since the <code>Category</code> class cannot represent arbitrary categories, but only categories whose objects are objects of <code>Hask</code>, the category of Haskell types. For a more general treatment of categories within Haskell, see the [http://hackage.haskell.org/package/category-extras category-extras package]. For more about category theory in general, see the excellent [http://en.wikibooks.org/wiki/Haskell/Category_theory Haskell wikibook page],<br />
[http://books.google.com/books/about/Category_theory.html?id=-MCJ6x2lC7oC Steve Awodey’s new book], Benjamin Pierce’s [http://books.google.com/books/about/Basic_category_theory_for_computer_scien.html?id=ezdeaHfpYPwC Basic category theory for computer scientists], or [http://folli.loria.fr/cds/1999/esslli99/courses/barr-wells.html Barr and Wells’s category theory lecture notes]. [http://dekudekuplex.wordpress.com/2009/01/19/motivating-learning-category-theory-for-non-mathematicians/ Benjamin Russell’s blog post]<br />
is another good source of motivation and category theory links. You certainly don’t need to know any category theory to be a successful and productive Haskell programmer, but it does lend itself to much deeper appreciation of Haskell’s underlying theory.<br />
<br />
=Arrow=<br />
<br />
The <code>Arrow</code> class represents another abstraction of computation, in a<br />
similar vein to <code>Monad</code> and <code>Applicative</code>. However, unlike <code>Monad</code><br />
and <code>Applicative</code>, whose types only reflect their output, the type of<br />
an <code>Arrow</code> computation reflects both its input and output. Arrows<br />
generalize functions: if <code>arr</code> is an instance of <code>Arrow</code>, a value of<br />
type <code>b `arr` c</code> can be thought of as a computation which takes values of<br />
type <code>b</code> as input, and produces values of type <code>c</code> as output. In the<br />
<code>(->)</code> instance of <code>Arrow</code> this is just a pure function; in general, however,<br />
an arrow may represent some sort of “effectful” computation.<br />
<br />
==Definition==<br />
<br />
The definition of the <code>Arrow</code> type class, from<br />
<code>Control.Arrow</code> ([http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html haddock]), is:<br />
<br />
<haskell><br />
class Category arr => Arrow arr where<br />
arr :: (b -> c) -> (b `arr` c)<br />
first :: (b `arr` c) -> ((b, d) `arr` (c, d))<br />
second :: (b `arr` c) -> ((d, b) `arr` (d, c))<br />
(***) :: (b `arr` c) -> (b' `arr` c') -> ((b, b') `arr` (c, c'))<br />
(&&&) :: (b `arr` c) -> (b `arr` c') -> (b `arr` (c, c'))<br />
</haskell><br />
<br />
{{note|In versions of the <code>base</code><br />
package prior to version 4, there is no <code>Category</code> class, and the<br />
<code>Arrow</code> class includes the arrow composition operator <code>(>>>)</code>. It<br />
also includes <code>pure</code> as a synonym for <code>arr</code>, but this was removed<br />
since it conflicts with the <code>pure</code> from <code>Applicative</code>.}}<br />
<br />
The first thing to note is the <code>Category</code> class constraint, which<br />
means that we get identity arrows and arrow composition for free:<br />
given two arrows <code>g :: b `arr` c</code> and <code>h :: c `arr` d</code>, we can form their<br />
composition <code>g >>> h :: b `arr` d</code> {{noteref}}.<br />
<br />
As should be a familiar pattern by now, the only methods which must be<br />
defined when writing a new instance of <code>Arrow</code> are <code>arr</code> and <code>first</code>;<br />
the other methods have default definitions in terms of these, but are<br />
included in the <code>Arrow</code> class so that they can be overridden with more<br />
efficient implementations if desired.<br />
<br />
==Intuition==<br />
<br />
Let’s look at each of the arrow methods in turn. [http://www.haskell.org/arrows/ Ross Paterson’s web page on arrows] has nice diagrams which can help<br />
build intuition.<br />
<br />
* The <code>arr</code> function takes any function <code>b -> c</code> and turns it into a generalized arrow <code>b `arr` c</code>. The <code>arr</code> method justifies the claim that arrows generalize functions, since it says that we can treat any function as an arrow. It is intended that the arrow <code>arr g</code> is “pure” in the sense that it only computes <code>g</code> and has no “effects” (whatever that might mean for any particular arrow type).<br />
<br />
* The <code>first</code> method turns any arrow from <code>b</code> to <code>c</code> into an arrow from <code>(b,d)</code> to <code>(c,d)</code>. The idea is that <code>first g</code> uses <code>g</code> to process the first element of a tuple, and lets the second element pass through unchanged. For the function instance of <code>Arrow</code>, of course, <code>first g (x,y) = (g x, y)</code>.<br />
<br />
* The <code>second</code> function is similar to <code>first</code>, but with the elements of the tuples swapped. Indeed, it can be defined in terms of <code>first</code> using an auxiliary function <code>swap</code>, defined by <code>swap (x,y) = (y,x)</code>.<br />
<br />
* The <code>(***)</code> operator is “parallel composition” of arrows: it takes two arrows and makes them into one arrow on tuples, which has the behavior of the first arrow on the first element of a tuple, and the behavior of the second arrow on the second element. The mnemonic is that <code>g *** h</code> is the ''product'' (hence <code>*</code>) of <code>g</code> and <code>h</code>. For the function instance of <code>Arrow</code>, we define <code>(g *** h) (x,y) = (g x, h y)</code>. The default implementation of <code>(***)</code> is in terms of <code>first</code>, <code>second</code>, and sequential arrow composition <code>(>>>)</code>. The reader may also wish to think about how to implement <code>first</code> and <code>second</code> in terms of <code>(***)</code>.<br />
<br />
* The <code>(&&&)</code> operator is “fanout composition” of arrows: it takes two arrows <code>g</code> and <code>h</code> and makes them into a new arrow <code>g &&& h</code> which supplies its input as the input to both <code>g</code> and <code>h</code>, returning their results as a tuple. The mnemonic is that <code>g &&& h</code> performs both <code>g</code> ''and'' <code>h</code> (hence <code>&</code>) on its input. For functions, we define <code>(g &&& h) x = (g x, h x)</code>.<br />
<br />
==Instances==<br />
<br />
The <code>Arrow</code> library itself only provides two <code>Arrow</code> instances, both<br />
of which we have already seen: <code>(->)</code>, the normal function<br />
constructor, and <code>Kleisli m</code>, which makes functions of<br />
type <code>a -> m b</code> into <code>Arrow</code>s for any <code>Monad m</code>. These instances are:<br />
<br />
<haskell><br />
instance Arrow (->) where<br />
arr g = g<br />
first g (x,y) = (g x, y)<br />
<br />
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }<br />
<br />
instance Monad m => Arrow (Kleisli m) where<br />
arr f = Kleisli (return . f)<br />
first (Kleisli f) = Kleisli (\ ~(b,d) -> do c <- f b<br />
return (c,d) )<br />
</haskell><br />
<br />
==Laws==<br />
<br />
{{note|See [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 John Hughes: Generalising monads to arrows]; [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf Sam Lindley, Philip Wadler, Jeremy Yallop: The arrow calculus]; [http://www.soi.city.ac.uk/~ross/papers/fop.html Ross Paterson: Programming with Arrows].}}<br />
<br />
There are quite a few laws that instances of <code>Arrow</code> should<br />
satisfy {{noteref}}:<br />
<br />
<haskell><br />
arr id = id<br />
arr (h . g) = arr g >>> arr h<br />
first (arr g) = arr (g *** id)<br />
first (g >>> h) = first g >>> first h<br />
first g >>> arr (id *** h) = arr (id *** h) >>> first g<br />
first g >>> arr fst = arr fst >>> g<br />
first (first g) >>> arr assoc = arr assoc >>> first g<br />
<br />
assoc ((x,y),z) = (x,(y,z))<br />
</haskell><br />
<br />
Note that this version of the laws is slightly different than the laws given in the<br />
first two above references, since several of the laws have now been<br />
subsumed by the <code>Category</code> laws (in particular, the requirements that<br />
<code>id</code> is the identity arrow and that <code>(>>>)</code> is associative). The laws<br />
shown here follow those in Paterson’s Programming with Arrows, which uses the<br />
<code>Category</code> class.<br />
<br />
{{note|Unless category-theory-induced insomnolence is your cup of tea.}}<br />
<br />
The reader is advised not to lose too much sleep over the <code>Arrow</code><br />
laws {{noteref}}, since it is not essential to understand them in order to<br />
program with arrows. There are also laws that <code>ArrowChoice</code>,<br />
<code>ArrowApply</code>, and <code>ArrowLoop</code> instances should satisfy; the interested<br />
reader should consult [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows].<br />
<br />
==ArrowChoice==<br />
<br />
Computations built using the <code>Arrow</code> class, like those built using<br />
the <code>Applicative</code> class, are rather inflexible: the structure of the computation<br />
is fixed at the outset, and there is no ability to choose between<br />
alternate execution paths based on intermediate results.<br />
The <code>ArrowChoice</code> class provides exactly such an ability:<br />
<br />
<haskell><br />
class Arrow arr => ArrowChoice arr where<br />
left :: (b `arr` c) -> (Either b d `arr` Either c d)<br />
right :: (b `arr` c) -> (Either d b `arr` Either d c)<br />
(+++) :: (b `arr` c) -> (b' `arr` c') -> (Either b b' `arr` Either c c')<br />
(|||) :: (b `arr` d) -> (c `arr` d) -> (Either b c `arr` d)<br />
</haskell><br />
<br />
A comparison of <code>ArrowChoice</code> to <code>Arrow</code> will reveal a striking<br />
parallel between <code>left</code>, <code>right</code>, <code>(+++)</code>, <code>(|||)</code> and <code>first</code>,<br />
<code>second</code>, <code>(***)</code>, <code>(&&&)</code>, respectively. Indeed, they are dual:<br />
<code>first</code>, <code>second</code>, <code>(***)</code>, and <code>(&&&)</code> all operate on product types<br />
(tuples), and <code>left</code>, <code>right</code>, <code>(+++)</code>, and <code>(|||)</code> are the<br />
corresponding operations on sum types. In general, these operations<br />
create arrows whose inputs are tagged with <code>Left</code> or <code>Right</code>, and can<br />
choose how to act based on these tags.<br />
<br />
* If <code>g</code> is an arrow from <code>b</code> to <code>c</code>, then <code>left g</code> is an arrow from <code>Either b d</code> to <code>Either c d</code>. On inputs tagged with <code>Left</code>, the <code>left g</code> arrow has the behavior of <code>g</code>; on inputs tagged with <code>Right</code>, it behaves as the identity.<br />
<br />
* The <code>right</code> function, of course, is the mirror image of <code>left</code>. The arrow <code>right g</code> has the behavior of <code>g</code> on inputs tagged with <code>Right</code>.<br />
<br />
* The <code>(+++)</code> operator performs “multiplexing”: <code>g +++ h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and as <code>h</code> on inputs tagged with <code>Right</code>. The tags are preserved. The <code>(+++)</code> operator is the ''sum'' (hence <code>+</code>) of two arrows, just as <code>(***)</code> is the product.<br />
<br />
* The <code>(|||)</code> operator is “merge” or “fanin”: the arrow <code>g ||| h</code> behaves as <code>g</code> on inputs tagged with <code>Left</code>, and <code>h</code> on inputs tagged with <code>Right</code>, but the tags are discarded (hence, <code>g</code> and <code>h</code> must have the same output type). The mnemonic is that <code>g ||| h</code> performs either <code>g</code> ''or'' <code>h</code> on its input.<br />
<br />
The <code>ArrowChoice</code> class allows computations to choose among a finite number of execution paths, based on intermediate results. The possible<br />
execution paths must be known in advance, and explicitly assembled with <code>(+++)</code> or <code>(|||)</code>. However, sometimes more flexibility is<br />
needed: we would like to be able to ''compute'' an arrow from intermediate results, and use this computed arrow to continue the computation. This is the power given to us by <code>ArrowApply</code>.<br />
<br />
==ArrowApply==<br />
<br />
The <code>ArrowApply</code> type class is:<br />
<br />
<haskell><br />
class Arrow arr => ArrowApply arr where<br />
app :: (b `arr` c, b) `arr` c<br />
</haskell><br />
<br />
If we have computed an arrow as the output of some previous<br />
computation, then <code>app</code> allows us to apply that arrow to an input,<br />
producing its output as the output of <code>app</code>. As an exercise, the<br />
reader may wish to use <code>app</code> to implement an alternative “curried”<br />
version, <code>app2 :: b `arr` ((b `arr` c) `arr` c)</code>.<br />
<br />
This notion of being able to ''compute'' a new computation<br />
may sound familiar:<br />
this is exactly what the monadic bind operator <code>(>>=)</code> does. It<br />
should not particularly come as a surprise that <code>ArrowApply</code> and<br />
<code>Monad</code> are exactly equivalent in expressive power. In particular,<br />
<code>Kleisli m</code> can be made an instance of <code>ArrowApply</code>, and any instance<br />
of <code>ArrowApply</code> can be made a <code>Monad</code> (via the <code>newtype</code> wrapper<br />
<code>ArrowMonad</code>). As an exercise, the reader may wish to try<br />
implementing these instances:<br />
<br />
<haskell><br />
instance Monad m => ArrowApply (Kleisli m) where<br />
app = -- exercise<br />
<br />
newtype ArrowApply a => ArrowMonad a b = ArrowMonad (a () b)<br />
<br />
instance ArrowApply a => Monad (ArrowMonad a) where<br />
return = -- exercise<br />
(ArrowMonad a) >>= k = -- exercise<br />
</haskell><br />
<br />
==ArrowLoop==<br />
<br />
The <code>ArrowLoop</code> type class is:<br />
<br />
<haskell><br />
class Arrow a => ArrowLoop a where<br />
loop :: a (b, d) (c, d) -> a b c<br />
<br />
trace :: ((b,d) -> (c,d)) -> b -> c<br />
trace f b = let (c,d) = f (b,d) in c<br />
</haskell><br />
<br />
It describes arrows that can use recursion to compute results, and is<br />
used to desugar the <code>rec</code> construct in arrow notation (described<br />
below).<br />
<br />
Taken by itself, the type of the <code>loop</code> method does not seem to tell<br />
us much. Its intention, however, is a generalization of the <code>trace</code><br />
function which is also shown. The <code>d</code> component of the first arrow’s<br />
output is fed back in as its own input. In other words, the arrow<br />
<code>loop g</code> is obtained by recursively “fixing” the second component of<br />
the input to <code>g</code>.<br />
<br />
It can be a bit difficult to grok what the <code>trace</code> function is doing.<br />
How can <code>d</code> appear on the left and right sides of the <code>let</code>? Well,<br />
this is Haskell’s laziness at work. There is not space here for a<br />
full explanation; the interested reader is encouraged to study the<br />
standard <code>fix</code> function, and to read [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson’s arrow tutorial].<br />
<br />
==Arrow notation==<br />
<br />
Programming directly with the arrow combinators can be painful,<br />
especially when writing complex computations which need to retain<br />
simultaneous reference to a number of intermediate results. With<br />
nothing but the arrow combinators, such intermediate results must be<br />
kept in nested tuples, and it is up to the programmer to remember<br />
which intermediate results are in which components, and to swap,<br />
reassociate, and generally mangle tuples as necessary. This problem<br />
is solved by the special arrow notation supported by GHC, similar to<br />
<code>do</code> notation for monads, that allows names to be assigned to<br />
intermediate results while building up arrow computations. An example<br />
arrow implemented using arrow notation, taken from<br />
Paterson, is:<br />
<br />
<haskell><br />
class ArrowLoop arr => ArrowCircuit arr where<br />
delay :: b -> (b `arr` b)<br />
<br />
counter :: ArrowCircuit arr => Bool `arr` Int<br />
counter = proc reset -> do<br />
rec output <- idA -< if reset then 0 else next<br />
next <- delay 0 -< output + 1<br />
idA -< output<br />
</haskell><br />
<br />
This arrow is intended to<br />
represent a recursively defined counter circuit with a reset line.<br />
<br />
There is not space here for a full explanation of arrow notation; the<br />
interested reader should consult<br />
[http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper introducing the notation], or his later [http://www.soi.city.ac.uk/~ross/papers/fop.html tutorial which presents a simplified version].<br />
<br />
==Further reading==<br />
<br />
An excellent starting place for the student of arrows is the [http://www.haskell.org/arrows/ arrows web page], which contains an<br />
introduction and many references. Some key papers on arrows include<br />
Hughes’s original paper introducing arrows, [http://dx.doi.org/10.1016/S0167-6423(99)00023-4 Generalising monads to arrows], and [http://www.soi.city.ac.uk/~ross/papers/notation.html Paterson’s paper on arrow notation].<br />
<br />
Both Hughes and Paterson later wrote accessible tutorials intended for a broader<br />
audience: [http://www.soi.city.ac.uk/~ross/papers/fop.html Paterson: Programming with Arrows] and [http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf Hughes: Programming with Arrows].<br />
<br />
Although Hughes’s goal in defining the <code>Arrow</code> class was to<br />
generalize <code>Monad</code>s, and it has been said that <code>Arrow</code> lies “between<br />
<code>Applicative</code> and <code>Monad</code>” in power, they are not directly<br />
comparable. The precise relationship remained in some confusion until<br />
[http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf analyzed by Lindley, Wadler, and Yallop], who<br />
also invented a new calculus of arrows, based on the lambda calculus,<br />
which considerably simplifies the presentation of the arrow laws<br />
(see [http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf The arrow calculus]). There is also a precise technical sense in which [http://just-bottom.blogspot.de/2010/04/programming-with-effects-story-so-far.html <code>Arrow</code> can be seen as the intersection of <code>Applicative</code> and <code>Category</code>].<br />
<br />
Some examples of <code>Arrow</code>s include [http://www.haskell.org/yampa/ Yampa], the<br />
[http://www.fh-wedel.de/~si/HXmlToolbox/ Haskell XML Toolkit], and the functional GUI library [[Grapefruit]].<br />
<br />
Some extensions to arrows have been explored; for example, the<br />
[http://www.cs.ru.nl/A.vanWeelden/bi-arrows/ <code>BiArrow</code>s of Alimarine et al.], for two-way instead of one-way<br />
computation.<br />
<br />
The Haskell wiki has [[Research papers/Monads and Arrows|links to many additional research papers relating to <code>Arrow</code>s]].<br />
<br />
=Comonad=<br />
<br />
The final type class we will examine is <code>Comonad</code>. The <code>Comonad</code> class<br />
is the categorical dual of <code>Monad</code>; that is, <code>Comonad</code> is like <code>Monad</code><br />
but with all the function arrows flipped. It is not actually in the<br />
standard Haskell libraries, but it has seen some interesting uses<br />
recently, so we include it here for completeness.<br />
<br />
==Definition==<br />
<br />
The <code>Comonad</code> type class, defined in the <code>Control.Comonad</code> module of<br />
the [http://hackage.haskell.org/package/comonad comonad library], is:<br />
<br />
<haskell><br />
class Functor w => Comonad w where<br />
extract :: w a -> a<br />
<br />
duplicate :: w a -> w (w a)<br />
duplicate = extend id<br />
<br />
extend :: (w a -> b) -> w a -> w b<br />
extend f = fmap f . duplicate<br />
</haskell><br />
<br />
As you can see, <code>extract</code> is the dual of <code>return</code>, <code>duplicate</code> is the dual of <code>join</code>, and <code>extend</code> is the dual of <code>(=<<)</code>. The definition of <code>Comonad</code> is a bit redundant, giving the programmer the choice on whether extend or duplicate are implemented; the other operation then has a default implementation.<br />
<br />
A prototypical example of a <code>Comonad</code> instance is:<br />
<br />
<haskell><br />
-- Infinite lazy streams<br />
data Stream a = Cons a (Stream a)<br />
<br />
-- 'duplicate' is like the list function 'tails'<br />
-- 'extend' computes a new Stream from an old, where the element<br />
-- at position n is computed as a function of everything from<br />
-- position n onwards in the old Stream<br />
instance Comonad Stream where<br />
extract (Cons x _) = x<br />
duplicate s@(Cons x xs) = Cons s (duplicate xs)<br />
extend g s@(Cons x xs) = Cons (g s) (extend g xs)<br />
-- = fmap g (duplicate s)<br />
</haskell><br />
<br />
==Further reading==<br />
<br />
Dan Piponi explains in a blog post what [http://blog.sigfpe.com/2006/12/evaluating-cellular-automata-is.html cellular automata have to do with comonads]. In another blog post, Conal Elliott has examined [http://conal.net/blog/posts/functional-interactive-behavior/ a comonadic formulation of functional reactive programming]. Sterling Clover’s blog post [http://fmapfixreturn.wordpress.com/2008/07/09/comonads-in-everyday-life/ Comonads in everyday life] explains the relationship between comonads and zippers, and how comonads can be used to design a menu system for a web site.<br />
<br />
Uustalu and Vene have a number of papers exploring ideas related to comonads and functional programming:<br />
* [http://dx.doi.org/10.1016/j.entcs.2008.05.029 Comonadic Notions of Computation]<br />
* [http://www.ioc.ee/~tarmo/papers/sfp01-book.pdf The dual of substitution is redecoration] (Also available as [http://www.cs.ut.ee/~varmo/papers/sfp01-book.ps.gz ps.gz].)<br />
* [http://dx.doi.org/10.1016/j.ic.2005.08.005 Recursive coalgebras from comonads]<br />
* [http://www.fing.edu.uy/~pardo/papers/njc01.ps.gz Recursion schemes from comonads]<br />
* [http://cs.ioc.ee/~tarmo/papers/essence.pdf The Essence of Dataflow Programming].<br />
<br />
Gabriel Gonzalez's [http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html Comonads are objects] points out similarities between comonads and object-oriented programming.<br />
<br />
The [http://hackage.haskell.org/package/comonad-transformers comonad-transformers] package contains comonad transformers.<br />
<br />
=Acknowledgements=<br />
<br />
A special thanks to all of those who taught me about standard Haskell<br />
type classes and helped me develop good intuition for them,<br />
particularly Jules Bean (quicksilver), Derek Elkins (ddarius), Conal<br />
Elliott (conal), Cale Gibbard (Cale), David House, Dan Piponi<br />
(sigfpe), and Kevin Reid (kpreid).<br />
<br />
I also thank the many people who provided a mountain of helpful<br />
feedback and suggestions on a first draft of the Typeclassopedia: David Amos,<br />
Kevin Ballard, Reid Barton, Doug Beardsley, Joachim Breitner, Andrew<br />
Cave, David Christiansen, Gregory Collins, Mark Jason Dominus, Conal<br />
Elliott, Yitz Gale, George Giorgidze, Steven Grady, Travis Hartwell,<br />
Steve Hicks, Philip Hölzenspies, Edward Kmett, Eric Kow, Serge Le<br />
Huitouze, Felipe Lessa, Stefan Ljungstrand, Eric Macaulay, Rob MacAulay, Simon Meier,<br />
Eric Mertens, Tim Newsham, Russell O’Connor, Conrad Parker, Walt<br />
Rorie-Baety, Colin Ross, Tom Schrijvers, Aditya Siram, C. Smith,<br />
Martijn van Steenbergen, Joe Thornber, Jared Updike, Rob Vollmert,<br />
Andrew Wagner, Louis Wasserman, and Ashley Yakeley, as well as a few<br />
only known to me by their IRC nicks: b_jonas, maltem, tehgeekmeister,<br />
and ziman. I have undoubtedly omitted a few inadvertently, which in<br />
no way diminishes my gratitude.<br />
<br />
Finally, I would like to thank Wouter Swierstra for his fantastic work<br />
editing the Monad.Reader, and my wife Joyia for her patience during<br />
the process of writing the Typeclassopedia.<br />
<br />
=About the author=<br />
<br />
Brent Yorgey ([http://byorgey.wordpress.com/ blog], [http://www.cis.upenn.edu/~byorgey/ homepage]) is (as of November 2011) a fourth-year Ph.D. student in the [http://www.cis.upenn.edu/~plclub/ programming languages group] at the [http://www.upenn.edu University of Pennsylvania]. He enjoys teaching, creating EDSLs, playing Bach fugues, musing upon category theory, and cooking tasty lambda-treats for the denizens of #haskell.<br />
<br />
=Colophon=<br />
<br />
The Typeclassopedia was written by Brent Yorgey and initially published in March 2009. Painstakingly converted to wiki syntax by [[User:Geheimdienst]] in November 2011, after asking Brent’s permission.<br />
<br />
If something like this TeX to wiki syntax conversion ever needs to be done again, here are some vim commands that helped:<br />
<br />
* <nowiki>%s/\\section{\([^}]*\)}/=\1=/gc</nowiki><br />
* <nowiki>%s/\\subsection{\([^}]*\)}/==\1==/gc</nowiki><br />
* <nowiki>%s/^ *\\item /\r* /gc</nowiki><br />
* <nowiki>%s/---/—/gc</nowiki><br />
* <nowiki>%s/\$\([^$]*\)\$/<math>\1\\ <\/math>/gc</nowiki> ''Appending “\ ” forces images to be rendered. Otherwise, Mediawiki would go back and forth between one font for short <nowiki><math></nowiki> tags, and another more Tex-like font for longer tags (containing more than a few characters)""<br />
* <nowiki>%s/|\([^|]*\)|/<code>\1<\/code>/gc</nowiki><br />
* <nowiki>%s/\\dots/.../gc</nowiki><br />
* <nowiki>%s/^\\label{.*$//gc</nowiki><br />
* <nowiki>%s/\\emph{\([^}]*\)}/''\1''/gc</nowiki><br />
* <nowiki>%s/\\term{\([^}]*\)}/''\1''/gc</nowiki><br />
<br />
The biggest issue was taking the academic-paper-style citations and turning them into hyperlinks with an appropriate title and an appropriate target. In most cases there was an obvious thing to do (e.g. online PDFs of the cited papers or CiteSeer entries). Sometimes, however, it’s less clear and you might want to check the<br />
[[Media:Typeclassopedia.pdf|original Typeclassopedia PDF]]<br />
with the<br />
[http://code.haskell.org/~byorgey/TMR/Issue13/typeclassopedia.bib original bibliography file].<br />
<br />
To get all the citations into the main text, I first tried processing the source with TeX or Lyx. This didn’t work due to missing unfindable packages, syntax errors, and my general ineptitude with Tex.<br />
<br />
I then went for the next best solution, which seemed to be extracting all instances of “\cite{something}” from the source and ''in that order'' pulling the referenced entries from the .bib file. This way you can go through the source file and sorted-references file in parallel, copying over what you need, without searching back and forth in the .bib file. I used:<br />
<br />
* <nowiki>egrep -o "\cite\{[^\}]*\}" ~/typeclassopedia.lhs | cut -c 6- | tr "," "\n" | tr -d "}" > /tmp/citations</nowiki><br />
* <nowiki>for i in $(cat /tmp/citations); do grep -A99 "$i" ~/typeclassopedia.bib|egrep -B99 '^\}$' -m1 ; done > ~/typeclasso-refs-sorted</nowiki><br />
<br />
[[Category:Applicative Functor]]<br />
[[Category:Arrow]]<br />
[[Category:Functor]]<br />
[[Category:Monad]]<br />
[[Category:Standard classes]]<br />
[[Category:Standard libraries]]<br />
[[Category:Standard packages]]<br />
[[Category:Standard types]]</div>Imzhttps://wiki.haskell.org/index.php?title=Hitchhikers_guide_to_Haskell&diff=39270Hitchhikers guide to Haskell2011-03-30T22:34:43Z<p>Imz: /* Chapter 3: Packing the knapsack and testing it with class, too (and don't forget your towel!) */ +wikilink</p>
<hr />
<div>== Preface: DON'T PANIC! ==<br />
[[Category:Tutorials]]<br />
Recent experiences from a few of my fellow C++/Java programmers<br />
indicate that they read various Haskell tutorials with "exponential<br />
speedup" (think about how TCP/IP session starts up). They start slow<br />
and cautious, but when they see that the first 3-5 pages do not<br />
contain "anything interesting" in terms of code and examples, they<br />
begin skipping paragraphs, then chapters, then whole pages, only to<br />
slow down - often to a complete halt - somewhere on page 50, finding<br />
themselves in the thick of concepts like "type classes", "type<br />
constructors", "monadic IO", at which point they usually panic, think<br />
of a perfectly rational excuse not to read further anymore, and<br />
happily forget this sad and scary encounter with Haskell (as human<br />
beings usually tend to forget sad and scary things).<br />
<br />
This text intends to introduce the reader to the practical aspects of Haskell<br />
from the very beginning (plans for the first chapters include: I/O, darcs,<br />
Parsec, QuickCheck, profiling and debugging, to mention a few). The reader<br />
is expected to know (where to find) at least the basics of Haskell: how to run<br />
"hugs" or "ghci", '''that layout is 2-dimensional''', etc. Other than that, we do<br />
not plan to take radical leaps, and will go one step at a time in order not to<br />
lose the reader along the way. So DON'T PANIC, take your towel with you and<br />
read along.<br />
<br />
'''In case you've skipped over the previous paragraph''', I would like<br />
to stress out once again that Haskell is sensitive to indentation and<br />
spacing, so pay attention to that during cut-n-pastes or manual<br />
alignment of code in the text editor with proportional fonts.<br />
<br />
Oh, almost forgot: author is very interested in ANY feedback. Drop him a line<br />
or a word (see [[User:Adept|Adept]] for contact info) or submit<br />
patches to the tutorial via darcs (<br />
[http://adept.linux.kiev.ua:8080/repos/hhgtth/ repository is here]) or directly to this<br />
Wiki. <br />
<br />
== Chapter 1: Ubiquitous "Hello world!" and other ways to do IO in Haskell ==<br />
<br />
Each chapter will be dedicated to one small real-life task which we will<br />
complete from the ground up.<br />
<br />
So here is the task for this chapter: in order to free up space on<br />
your hard drive for all the Haskell code you are going to write in the<br />
nearest future, you are going to archive some of the old and dusty<br />
information on CDs and DVDs. While CD (or DVD) burning itself is easy<br />
these days, it usually takes some (or quite a lot of) time to decide<br />
how to put several GB of digital photos on CD-Rs, when directories<br />
with images range from 10 to 300 Mb's in size, and you don't want to<br />
burn half-full (or half-empty) CD-Rs.<br />
<br />
So, the task is to write a program which will help us put a given<br />
collection of directories on the minimum possible amount of media,<br />
while packing the media as tightly as possible. Let's name this program<br />
"cd-fit".<br />
<br />
Oh. Wait. Let's do the usual "hello world" thing, before we forget about it,<br />
and then move on to more interesting things:<br />
<br />
<haskell><br />
-- Taken from 'hello.hs'<br />
-- From now on, a comment at the beginning of the code snippet<br />
-- will specify the file which contain the full program from<br />
-- which the snippet is taken. You can get the code from the darcs<br />
-- repository "http://adept.linux.kiev.ua:8080/repos/hhgtth" by issuing<br />
-- command "darcs get http://adept.linux.kiev.ua:8080/repos/hhgtth"<br />
module Main where<br />
main = putStrLn "Hello world!"<br />
</haskell><br />
<br />
Run it:<br />
<br />
$ runhaskell ./hello.hs<br />
Hello world!<br />
<br />
OK, we've done it. Move along now, nothing interesting here :)<br />
<br />
Any serious development must be done with the help of a version control<br />
system, and we will not make an exception. We will use the modern<br />
distributed version control system "darcs". "Modern" means that it is<br />
written in Haskell, "distributed" means that each working copy is<br />
a repository in itself.<br />
<br />
First, let's create an empty directory for all our code, and invoke<br />
"darcs init" there, which will create subdirectory "_darcs" to store<br />
all version-control-related stuff there.<br />
<br />
Fire up your favorite editor and create a new file called "cd-fit.hs"<br />
in our working directory. Now let's think for a moment about how our<br />
program will operate and express it in pseudocode:<br />
<br />
<haskell><br />
main = Read list of directories and their sizes.<br />
Decide how to fit them on CD-Rs.<br />
Print solution.<br />
</haskell><br />
<br />
Sounds reasonable? I thought so.<br />
<br />
Let's simplify our life a little and assume for now that we will<br />
compute directory sizes somewhere outside our program (for example,<br />
with "du -sb *") and read this information from stdin.<br />
Now let me convert all this to Haskell:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-1-1.hs'<br />
module Main where<br />
<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: got input " ++ input)<br />
-- compute solution and print it<br />
</haskell><br />
<br />
Not really working, but pretty close to plain English, eh? Let's stop<br />
for a moment and look more closely at what's written here line-by-line<br />
<br />
Let's begin from the top:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-1-1.hs'<br />
input <- getContents<br />
</haskell><br />
<br />
This is an example of the Haskell syntax for doing IO (namely, input). This<br />
line is an instruction to read all the information available from the stdin,<br />
return it as a single string, and bind it to the symbol "input", so we can<br />
process this string any way we want.<br />
<br />
How did I know that? Did I memorize all the functions by heart? Of course not!<br />
Each function has a type, which, along with function's name, usually tells a<br />
lot about what a function will do.<br />
<br />
Let's fire up an interactive Haskell environment and examine this function<br />
up close:<br />
<br />
$ ghci<br />
___ ___ _<br />
/ _ \ /\ /\/ __(_)<br />
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.<br />
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/<br />
\____/\/ /_/\____/|_| Type :? for help.<br />
<br />
Loading package base-1.0 ... linking ... done.<br />
Prelude> :type getContents<br />
getContents :: IO String<br />
Prelude> <br />
<br />
We see that "getContents" is a function without arguments, that will return<br />
"IO String". Prefix "IO" meant that this is an IO action. It will return<br />
String, when evaluated. Action will be evaluated as soon as we use "<-" to<br />
bind its result to some symbol.<br />
<br />
Note that "<-" is not a fancy way to assign value to variable. It is a way to<br />
evaluate (execute) IO actions, in other words - to actually do some I/O and<br />
return its result (if any). <br />
<br />
We can choose not to evaluate the action obtained from "getContents", but rather carry it around a bit and evaluate later:<br />
<br />
<haskell><br />
let x = getContents<br />
-- 300 lines of code here<br />
input <- x<br />
</haskell><br />
<br />
So, as you see, IO actions can act like an ordinary values. Suppose that we<br />
have built a list of IO actions and have found a way to execute them one by one.<br />
This would be a way to simulate imperative programming with its notion of<br />
"order of execution".<br />
<br />
Haskell allows you to do better than that. <br />
<br />
The standard language library (named "Prelude", by the way) provides<br />
us with lots of functions that return useful primitive IO actions. In<br />
order to combine them to produce an even more complex actions, we use a "do":<br />
<br />
<haskell><br />
c = do a <- someAction<br />
b <- someOtherAction<br />
print (bar b)<br />
print (foo a)<br />
putStrLn "done"<br />
</haskell><br />
<br />
Here we '''bind''' "c" to an action with the following "scenario":<br />
* '''evaluate''' action "someAction" and '''bind''' its result to "a"<br />
* then, '''evaluate''' "someOtherAction" and '''bind''' its result to "b"<br />
* then, process "b" with function "bar" and print result<br />
* then, process "a" with function "foo" and print result<br />
* then, print the word "done"<br />
<br />
When will all this actually be executed? Answer: as soon as we evaluate "c"<br />
using the "<-" (if it returns result, as "getContents" does) or just<br />
by using it as a function name (if it does not return a result, as "print"<br />
does):<br />
<br />
<haskell><br />
process = do putStrLn "Will do some processing"<br />
c<br />
putStrLn "Done"<br />
</haskell><br />
<br />
Notice that we took a bunch of functions ("someAction", "someOtherAction",<br />
"print", "putStrLn") and using "do" created from them a new function, which we<br />
bound to symbol "c". Now we could use "c" as a building block to produce an even<br />
more complex function, "process", and we could carry this on and on.<br />
Eventually, some of the functions will be mentioned in the code of function<br />
"main", to which the ultimate topmost IO action any Haskell program is bound.<br />
<br />
When will the "main" be executed/evaluated/forced? As soon as we run the<br />
program. Read this twice and try to comprehend: <br />
<br />
''The execution of a Haskell program is an evaluation of the symbol "main" to<br />
which we have bound an IO action. Via evaluation we obtain the result of that<br />
action''. <br />
<br />
Readers familiar with advanced C++ or Java programming and that arcane body of<br />
knowledge named "OOP Design Patterns" might note that "build actions from<br />
actions" and "evaluate actions to get result" is essentially a "Command<br />
pattern" and "Composition pattern" combined. Good news: in Haskell you get them<br />
for all your IO, and get them '''for free''' :)<br />
<br />
----<br />
'''Exercise:'''<br />
Consider the following code:<br />
<br />
<haskell><br />
-- Taken from 'exercise-1-1.hs'<br />
module Main where<br />
c = putStrLn "C!"<br />
<br />
combine before after =<br />
do before<br />
putStrLn "In the middle"<br />
after<br />
<br />
main = do combine c c<br />
let b = combine (putStrLn "Hello!") (putStrLn "Bye!")<br />
let d = combine (b) (combine c c)<br />
putStrLn "So long!"<br />
</haskell><br />
<br />
Notice how we carefully indent lines so that source looks neat?<br />
Actually, Haskell code has to be aligned this way, or it will not<br />
compile. If you use tabulation to indent your sources, take into<br />
account that Haskell compilers assume that tabstop is 8 characters<br />
wide.<br />
<br />
Often people complain that it is very difficult to write Haskell<br />
because it requires them to align code. Actually, this is not true. If<br />
you align your code, compiler will guess the beginnings and endings of<br />
syntactic blocks. However, if you don't want to indent your code, you<br />
could explicitly specify end of each and every expression and use<br />
arbitrary layout as in this example: <br />
<haskell><br />
-- Taken from 'exercise-1-2.hs'<br />
combine before after = <br />
do { before; <br />
putStrLn "In the middle"; <br />
after; };<br />
<br />
main = <br />
do { combine c c; let { b = combine (putStrLn "Hello!") (putStrLn "Bye!")};<br />
let {d = combine (b) (combine c c)}; <br />
putStrLn "So long!" };<br />
</haskell><br />
<br />
Back to the exercise - see how we construct code out of thin air? Try<br />
to imagine what this code will do, then run it and check yourself.<br />
<br />
Do you understand why "Hello!" and "Bye!" are not printed?<br />
----<br />
<br />
Let's examine our "main" function closer:<br />
<br />
Prelude> :load cd-fit.hs<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :type main<br />
main :: IO ()<br />
*Main> <br />
<br />
We see that "main" is indeed an IO action which will return nothing<br />
when evaluated. When combining actions with "do", the type of the<br />
result will be the type of the last action, and "putStrLn something" has type<br />
"IO ()": <br />
<br />
*Main> :type putStrLn "Hello world!"<br />
putStrLn "Hello world!" :: IO ()<br />
*Main> <br />
<br />
Oh, by the way: have you noticed that we actually compiled our first<br />
Haskell program in order to examine "main"? :)<br />
<br />
let's celebrate that by putting it under version control: execute<br />
"darcs add cd-fit.hs" and "darcs record", answer "y" to all questions<br />
and provide a commit comment "Skeleton of cd-fit.hs"<br />
<br />
Let's try to run it:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: got input foo<br />
<br />
----<br />
'''Exercises''':<br />
<br />
* Try to write a program that takes your name from the stdin and greets you (keywords: getLine, putStrLn);<br />
<br />
* Try to write a program that asks for you name, reads it, greets you, asks for your favorite color, and prints it back (keywords: getLine, putStrLn).<br />
<br />
== Chapter 2: Parsing the input ==<br />
<br />
OK, now that we have proper understanding of the powers of Haskell IO<br />
(and are awed by them, I hope), let's forget about IO and actually do<br />
some useful work. <br />
<br />
As you remember, we set forth to pack some CD-Rs as tightly as<br />
possible with data scattered in several input directories. We assume<br />
that "du -sb" will compute the sizes of input directories and output<br />
something like:<br />
<br />
65572 /home/adept/photos/raw-to-burn/dir1<br />
68268 /home/adept/photos/raw-to-burn/dir2<br />
53372 /home/adept/photos/raw-to-burn/dir3<br />
713124 /home/adept/photos/raw-to-burn/dir4<br />
437952 /home/adept/photos/raw-to-burn/dir5<br />
<br />
Our next task is to parse that input into some suitable internal<br />
representation.<br />
<br />
For that we will use powerful library of '''parsing combinators''' named<br />
"[[Parsec]]" which ships with most Haskell implementations.<br />
<br />
Much like the IO facilities we have seen in the first chapter, this<br />
library provides a set of basic parsers and means to combine into more<br />
complex parsing constructs.<br />
<br />
Unlike other tools in this area (lex/yacc or JavaCC to name a few),<br />
[[Parsec]] parsers do not require a separate preprocessing stage. Since in<br />
Haskell we can return function as a result of function and thus<br />
construct functions "from the thin air", there is no need for a separate<br />
syntax for parser description. But enough advertisements, let's actually<br />
do some parsing:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
import Text.ParserCombinators.Parsec<br />
<br />
-- parseInput parses output of "du -sb", which consists of many lines,<br />
-- each of which describes single directory<br />
parseInput = <br />
do dirs <- many dirAndSize<br />
eof<br />
return dirs<br />
<br />
-- Datatype Dir holds information about single directory - its size and name<br />
data Dir = Dir Int String deriving Show<br />
<br />
-- `dirAndSize` parses information about single directory, which is:<br />
-- a size in bytes (number), some spaces, then directory name, which extends till newline<br />
dirAndSize = <br />
do size <- many1 digit<br />
spaces<br />
dir_name <- anyChar `manyTill` newline<br />
return (Dir (read size) dir_name)<br />
</haskell><br />
<br />
Just add those lines to "cd-fit.hs", between the declaration of <br />
the Main module and the definition of main.<br />
<br />
Here we see quite a lot of new<br />
things, and several those that we know already. <br />
First of all, note the familiar "do" construct, which, as we know, is<br />
used to combine IO actions to produce new IO actions. Here we use it<br />
to combine "parsing" actions into new "parsing" actions. Does this<br />
mean that "parsing" implies "doing IO"? Not at all. Thing is, I must<br />
admit that I lied to you - "do" is used not only to combine IO<br />
actions. "Do" is used to combine any kind of so-called ''monadic<br />
actions'' or ''monadic values'' together.<br />
<br />
Think about [[monad]] as a "[[:Category:Idioms|design pattern]]" in the functional world.<br />
[[Monad]] is a way to hide from the user (programmer) all the machinery<br />
required for complex functionality to operate.<br />
<br />
As you might have heard, Haskell has no notion of "assignment",<br />
"mutable state", "variables", and is a "pure functional language",<br />
which means that every function called with the same input parameters<br />
will return exactly the same result. Meanwhile "doing IO" requires<br />
hauling around file handles and their states and dealing with IO<br />
errors. "Parsing" requires to track position in the input and dealing<br />
with parsing errors.<br />
<br />
In both cases Wise Men Who Wrote Libraries cared for our needs and<br />
hide all underlying complexities from us, exposing the [http://en.wikipedia.org/wiki/Application_programming_interface API] of their<br />
libraries (IO and parsing) in the form of "monadic action" which we<br />
are free to combine as we see fit. <br />
<br />
Think of programming with monads as of doing the remodelling with the<br />
help of professional remodelling crew. You describe sequence of<br />
actions on the piece of paper (that's us writing in "do" notation),<br />
and then, when required, that sequence will be evaluated by the<br />
remodelling crew ("in the monad") which will provide you with end<br />
result, hiding all the underlying complexity (how to prepare the<br />
paint, which nails to choose, etc) from you.<br />
<br />
let's use the interactive Haskell environment to decipher all the<br />
instructions we've written for the parsing library. As usually, we'll<br />
go top-down:<br />
<br />
*Main> :reload<br />
Ok, modules loaded: Main.<br />
*Main> :t parseInput<br />
parseInput :: GenParser Char st [Dir]<br />
*Main> :t dirAndSize<br />
dirAndSize :: GenParser Char st Dir<br />
*Main> <br />
<br />
Assuming (well, take my word for it) that "GenParser Char st" is our<br />
parsing monad, we could see that "parseInput", when evaluated, will<br />
produce a list of "Dir", and "dirAndSize", when evaluated, will<br />
produce "Dir". Assuming that "Dir" somehow represents information<br />
about single directory, that is pretty much what we wanted, isn't it?<br />
<br />
Let's see what a "Dir" means. We defined ''data[[type]]'' Dir as a record,<br />
which holds an Int and a String:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
data Dir = Dir Int String deriving Show<br />
</haskell><br />
<br />
In order to construct such records, we must use ''data [[constructor]]''<br />
Dir:<br />
<br />
*Main> :t Dir 1 "foo"<br />
Dir 1 "foo" :: Dir<br />
<br />
In order to reduce confusion for newbies, we could have written:<br />
<haskell><br />
data Dir = D Int String deriving Show<br />
</haskell><br />
<br />
, which would define ''data[[type]]'' "Dir" with ''data [[constructor]]'' "D".<br />
However, traditionally name of the data[[type]] and its [[constructor]] are<br />
chosen to be the same.<br />
<br />
Clause "[[deriving]] Show" instructs the compiler to make enough code "behind<br />
the curtains" to make this ''datatype'' conform to the interface of<br />
the ''type [[class]]'' Show. We will explain ''type [[class]]es'' later, for<br />
now let's just say that this will allow us to "print" instances of<br />
"Dir".<br />
<br />
'''Exercises:''' <br />
* examine types of "digit", "anyChar", "many", "many1" and "manyTill" to see how they are used to build more complex parsers from single ones.<br />
<br />
* compare types of "manyTill", "manyTill anyChar" and "manyTill anyChar newline". Note that "anyChar `manyTill` newline" is just another syntax sugar. Note that when function is supplied with less arguments that it actually needs, we get not a value, but a new function, which is called ''partial application''.<br />
<br />
<br />
OK. So, we combined a lot of primitive parsing actions to get ourselves a<br />
parser for output of "du -sb". How can we actually parse something? the [[Parsec]] library supplies us with function "parse":<br />
<br />
*Main> :t parse<br />
parse :: GenParser tok () a<br />
-> SourceName<br />
-> [tok]<br />
-> Either ParseError a<br />
*Main> :t parse parseInput<br />
parse parseInput :: SourceName -> [Char] -> Either ParseError [Dir]<br />
*Main> <br />
<br />
At first the [[type]] might be a bit cryptic, but once we supply "parse" with the parser we made, the compiler gets more information and presents us with a more concise [[type]].<br />
<br />
Stop and consider this for a moment. The compiler figured out type of the function without a single type annotation supplied by us! Imagine if a Java compiler deduced types for you, and you wouldn't have to specify types of arguments and return values of methods, ever.<br />
<br />
OK, back to the code. We can observe that the "parser" is a function, which,<br />
given a parser, a name of the source file or channel (f.e. "stdin"), and<br />
source data (String, which is a list of "Char"s, which is written "[Char]"),<br />
will either produce parse error, or parse us a list of "Dir".<br />
<br />
Datatype "Either" is an example of datatype whose constructor has name, different<br />
from the name of the datatype. In fact, "Either" has two constructors:<br />
<br />
<haskell><br />
data Either a b = Left a | Right b<br />
</haskell><br />
<br />
In order to understand better what does this mean consider the following<br />
example:<br />
<br />
*Main> :t Left 'a'<br />
Left 'a' :: Either Char b<br />
*Main> :t Right "aaa"<br />
Right "aaa" :: Either a [Char]<br />
*Main> <br />
<br />
You see that "Either" is a ''union'' (much like the C/C++ "union") which could<br />
hold value of one of the two distinct types. However, unlike C/C++ "union",<br />
when presented with value of type "Either Int Char" we could immediately see<br />
whether its an Int or a Char - by looking at the constructor which was used to<br />
produce the value. Such datatypes are called "tagged unions", and they are<br />
another [[:Category:Idioms|power tool]] in the Haskell toolset.<br />
<br />
Did you also notice that we provide "parse" with parser, which is a monadic<br />
value, but receive not a new monadic value, but a parsing result? That is<br />
because "parse" is an evaluator for "Parser" monad, much like the [[GHC]] or [[Hugs]] runtime is an evaluator for the IO monad. The function "parser" implements all monadic machinery: it tracks errors and positions in input, implements backtracking and lookahead, etc.<br />
<br />
let's extend our "main" function to use "parse" and actually parse the input<br />
and show us the parsed data structures:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: got input " ++ input)<br />
let dirs = case parse parseInput "stdin" input of<br />
Left err -> error $ "Input:\n" ++ show input ++ <br />
"\nError:\n" ++ show err<br />
Right result -> result<br />
putStrLn "DEBUG: parsed:"; print dirs<br />
</haskell><br />
<br />
'''Exercise:'''<br />
<br />
* In order to understand this snippet of code better, examine (with ghci or hugs) the difference between 'drop 1 ( drop 1 ( drop 1 ( drop 1 ( drop 1 "foobar" ))))' and 'drop 1 $ drop 1 $ drop 1 $ drop 1 $ drop 1 "foobar"'. Examine type of ($).<br />
* Try putStrLn "aaa" and print "aaa" and see the difference, examine their types.<br />
* Try print (Dir 1 "foo") and putStrLn (Dir 1 "foo"). Examine types of print and putStrLn to understand the behavior in both cases.<br />
<br />
Let's try to run what we have so far:<br />
<br />
$ du -sb * | runhaskell ./cd-fit.hs<br />
<br />
DEBUG: got input 22325 Article.txt<br />
18928 Article.txt~<br />
1706 cd-fit.hs<br />
964 cd-fit.hs~<br />
61609 _darcs<br />
<br />
DEBUG: parsed:<br />
[Dir 22325 "Article.txt",Dir 18928 "Article.txt~",<br />
Dir 1706 "cd-fit.hs",Dir 964 "cd-fit.hs~",Dir 61609 "_darcs"]<br />
<br />
Seems to be doing exactly as planned. Now let's try some erroneous<br />
input:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: got input foo<br />
<br />
DEBUG: parsed:<br />
*** Exception: Input:<br />
"foo\n"<br />
Error:<br />
"stdin" (line 1, column 1):<br />
unexpected "f"<br />
expecting digit or end of input<br />
<br />
Seems to be doing fine. <br />
<br />
If you followed advice to put your code under version control, you<br />
could now use "darcs whatsnew" or "darcs diff -u" to examine your<br />
changes to the previous version. Use "darcs record" to commit them. As<br />
an exercise, first record the changes "outside" of function "main" and<br />
then record the changes in "main". Do "darcs changes" to examine a<br />
list of changes you've recorded so far.<br />
<br />
== Chapter 3: Packing the knapsack and testing it with class, too (and don't forget your towel!) ==<br />
<br />
Enough preliminaries already. let's go pack some CDs.<br />
<br />
As you might already have recognized, our problem is a classical one. It is<br />
called a "knapsack problem" ([http://www.google.com/search?q=knapsack+problem google it up], if you don't know already what it<br />
is. There are more than 100000 links).<br />
<br />
let's start from the greedy solution, but first let's slightly modify our "Dir"<br />
datatype to allow easy extraction of its components:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
----<br />
'''Exercise:''' examine types of "Dir", "dir_size" and "dir_name"<br />
----<br />
<br />
From now on, we could use "dir_size d" to get a size of directory, and<br />
"dir_name d" to get its name, provided that "d" is of type "Dir".<br />
<br />
The Greedy algorithm sorts directories from the biggest down, and tries to put<br />
them on CD one by one, until there is no room for more. We will need to track<br />
which directories we added to CD, so let's add another datatype, and code this<br />
simple packing algorithm:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
import Data.List (sortBy)<br />
<br />
-- DirPack holds a set of directories which are to be stored on single CD.<br />
-- 'pack_size' could be calculated, but we will store it separately to reduce<br />
-- amount of calculation<br />
data DirPack = DirPack {pack_size::Int, dirs::[Dir]} deriving Show<br />
<br />
-- For simplicity, let's assume that we deal with standard 700 Mb CDs for now<br />
media_size = 700*1024*1024<br />
<br />
-- Greedy packer tries to add directories one by one to initially empty 'DirPack'<br />
greedy_pack dirs = foldl maybe_add_dir (DirPack 0 []) $ sortBy cmpSize dirs<br />
where<br />
cmpSize d1 d2 = compare (dir_size d1) (dir_size d2)<br />
<br />
-- Helper function, which only adds directory "d" to the pack "p" when new<br />
-- total size does not exceed media_size<br />
maybe_add_dir p d =<br />
let new_size = pack_size p + dir_size d<br />
new_dirs = d:(dirs p)<br />
in if new_size > media_size then p else DirPack new_size new_dirs<br />
</haskell><br />
<br />
----<br />
I'll highlight the areas which you could explore on your own (using other nice<br />
tutorials out there, of which I especially recommend "[[Yet Another Haskell Tutorial]]" by Hal Daume):<br />
* We choose to import a single function "sortBy" from a module [[Data.List]], not the whole thing.<br />
* Instead of coding case-by-case recursive definition of "greedy_pack", we go with higher-order approach, choosing "foldl" as a vehicle for list traversal. Examine its type. Other useful function from the same category are "map", "foldr", "scanl" and "scanr". Look them up!<br />
* To sort list of "Dir" by size only, we use custom sort function and parametrized sort - "sortBy". This sort of setup where the user may provide a custom "modifier" for a generic library function is quite common: look up "deleteBy", "deleteFirstsBy", "groupBy", "insertBy", "intersectBy", "maximumBy", "minimumBy", "sortBy", "unionBy".<br />
* To code the quite complex function "maybe_add_dir", we introduced several '''local definitions''' in the "let" clause, which we can reuse within the function body. We used a "where" clause in the "greedy_pack" function to achieve the same effect. Read about "let" and "where" clauses and the differences between them.<br />
* Note that in order to construct a new value of type "DirPack" (in function "maybe_add_dir") we haven't used the helper accessor functions "pack_size" and "dirs"<br />
----<br />
<br />
In order to actually use our greedy packer we must call it from our "main"<br />
function, so let's add a lines:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
main = do ...<br />
-- compute solution and print it<br />
putStrLn "Solution:" ; print (greedy_pack dirs)<br />
</haskell><br />
<br />
Verify integrity of our definitions by (re)loading our code in ghci. Compiles?<br />
Thought so :) Now, do "darcs record" and add some sensible commit message.<br />
<br />
Now it is time to test our creation. We could do it by actually running it in<br />
the wild like this:<br />
<br />
$ du -sb ~/DOWNLOADS/* | runhaskell ./cd-fit.hs<br />
<br />
This will prove that our code seems to be working. At least, this once. How<br />
about establishing with reasonable degree of certainty that our code, parts<br />
and the whole, works properly, and doing so in re-usable manner? In other<br />
words, how about writing some test?<br />
<br />
Java programmers used to JUnit probably thought about screens of boiler-plate<br />
code and hand-coded method invocations. Never fear, we will not do anything as<br />
silly :)<br />
<br />
Enter '''[[QuickCheck]]'''.<br />
<br />
[[QuickCheck]] is a tool to do automated testing of your functions using<br />
(semi)random input data. In the spirit of "100b of code examples is worth 1kb of<br />
praise" let's show the code for testing the following ''property'': An attempt to pack directories returned by "greedy_pack" should return "DirPack" of exactly the same pack:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
import Test.QuickCheck<br />
import Control.Monad (liftM2, replicateM)<br />
<br />
-- We must teach QuickCheck how to generate arbitrary "Dir"s<br />
instance Arbitrary Dir where<br />
-- Let's just skip "coarbitrary" for now, ok? <br />
-- I promise, we will get back to it later :)<br />
coarbitrary = undefined<br />
-- We generate arbitrary "Dir" by generating random size and random name<br />
-- and stuffing them inside "Dir"<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM n (elements "fubar/")<br />
<br />
-- For convenience and by tradition, all QuickCheck tests begin with prefix "prop_".<br />
-- Assume that "ds" will be a random list of "Dir"s and code your test.<br />
prop_greedy_pack_is_fixpoint ds =<br />
let pack = greedy_pack ds <br />
in pack_size pack == pack_size (greedy_pack (dirs pack))<br />
</haskell><br />
<br />
let's run the test, after which I'll explain how it all works:<br />
<br />
Prelude> :r<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> quickCheck prop_greedy_pack_is_fixpoint<br />
[numbers spinning]<br />
OK, passed 100 tests.<br />
*Main> <br />
<br />
We've just seen our "greedy_pack" run on a 100 completely (well, almost<br />
completely) random lists of "Dir"s, and it seems that property indeed holds.<br />
<br />
let's dissect the code. The most intriguing part is "instance Arbitrary Dir<br />
where", which declares that "Dir" is an '''[[instance]]''' of '''type[[class]]''' "Arbitrary". Whoa, that's a whole lot of unknown words! :) Let's slow down a<br />
bit. <br />
<br />
What is a '''type[[class]]'''? A typeclass is a Haskell way of dealing with the<br />
following situation: suppose that you are writing a library of useful<br />
functions and you don't know in advance how exactly they will be used, so you<br />
want to make them generic. Now, on one hand you don't want to restrict your<br />
users to certain type (e.g. String). On the other hand, you want to enforce<br />
the convention that arguments for your function must satisfy a certain set of<br />
constraints. That is where '''typeclass''' comes in handy. <br />
<br />
Think of typeclass as a '''contract''' (or "interface", in Java terms) that<br />
your type must fulfill in order to be admitted as an argument to certain<br />
functions. <br />
<br />
Let's examine the typeclass "Arbitrary":<br />
<br />
*Main> :i Arbitrary<br />
class Arbitrary a where<br />
arbitrary :: Gen a<br />
coarbitrary :: a -> Gen b -> Gen b<br />
-- Imported from Test.QuickCheck<br />
instance Arbitrary Dir<br />
-- Defined at ./cd-fit.hs:61:0<br />
instance Arbitrary Bool -- Imported from Test.QuickCheck<br />
instance Arbitrary Double -- Imported from Test.QuickCheck<br />
instance Arbitrary Float -- Imported from Test.QuickCheck<br />
instance Arbitrary Int -- Imported from Test.QuickCheck<br />
instance Arbitrary Integer -- Imported from Test.QuickCheck<br />
-- rest skipped --<br />
<br />
It could be read this way: "Any [[type]] (let's name it 'a') could be a member of the [[class]] Arbitrary as soon as we define two functions for it: "arbitrary" and "coarbitrary", with signatures shown. For types Dir, Bool, Double, Float, Int and Integer such definitions were provided, so all those types are instance of class Arbitrary".<br />
<br />
Now, if you write a function which operates on its arguments solely by means<br />
of "arbitrary" and "coarbitrary", you can be sure that this function will work<br />
on any type which is an instance of "Arbitrary"!<br />
<br />
let's say it again. Someone (maybe even you) writes the code (API or library),<br />
which requires that input values implement certain ''interfaces'', which is<br />
described in terms of functions. Once you show how your type implements this<br />
''interface'' you are free to use API or library.<br />
<br />
Consider the function "sort" from standard library:<br />
<br />
*Main> :t Data.List.sort<br />
Data.List.sort :: (Ord a) => [a] -> [a]<br />
<br />
We see that it sorts lists of any values which are instance of typeclass<br />
"Ord". Let's examine that class:<br />
<br />
*Main> :i Ord<br />
class Eq a => Ord a where<br />
compare :: a -> a -> Ordering<br />
(<) :: a -> a -> Bool<br />
(>=) :: a -> a -> Bool<br />
(>) :: a -> a -> Bool<br />
(<=) :: a -> a -> Bool<br />
max :: a -> a -> a<br />
min :: a -> a -> a<br />
-- skip<br />
instance Ord Double -- Imported from GHC.Float<br />
instance Ord Float -- Imported from GHC.Float<br />
instance Ord Bool -- Imported from GHC.Base<br />
instance Ord Char -- Imported from GHC.Base<br />
instance Ord Integer -- Imported from GHC.Num<br />
instance Ord Int -- Imported from GHC.Base<br />
-- skip<br />
*Main> <br />
<br />
We see a couple of interesting things: first, there is an additional<br />
requirement listed: in order to be an instance of "Ord", type must first be an<br />
instance of typeclass "Eq". Then, we see that there is an awful lot of<br />
functions to define in order to be an instance of "Ord". Wait a second, isn't<br />
it silly to define both (<) and (>) when one could be expressed via another? <br />
<br />
Right you are! Usually, typeclass contains several "default" implementation<br />
for its functions, when it is possible to express them through each other (as<br />
it is with "Ord"). In this case it is possible to supply only a minimal<br />
definition (which in case of "Ord" consists of any single function) and others<br />
will be automatically derived. If you supplied fewer functions than are required<br />
for minimal implementation, the compiler/interpreter will say so and<br />
explain which functions you still have to define.<br />
<br />
Once again, we see that a lot of [[type]]s are already instances of typeclass Ord, and thus we are able to sort them.<br />
<br />
Now, let's take a look back to the definition of "Dir":<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
See that "[[deriving]]" clause? It instructs the compiler to automatically derive code to make "Dir" an instance of typeclass Show. The compiler knows about a bunch of standard typeclasses (Eq, Ord, Show, Enum, Bound, Typeable to name a few) and knows how to make a type into a "suitably good" instance of any of them. If you want to derive instances of more than one typeclass, say it this way: "deriving (Eq,Ord,Show)". Voila! Now we can compare, sort and print data of<br />
that type!<br />
<br />
Side note for Java programmers: just imagine java compiler which derives code<br />
for "implements Storable" for you...<br />
<br />
Side note for C++ programmers: just imagine that deep copy constructors are<br />
being written for you by compiler....<br />
<br />
----<br />
'''Exercises:'''<br />
* Examine typeclasses Eq and Show<br />
* Examine types of (==) and "print"<br />
* Try to make "Dir" instance of "Eq"<br />
----<br />
<br />
OK, back to our tests. So, what we have had to do in order to make "Dir" an<br />
instance of "Arbitrary"? Minimal definition consists of "arbitrary". Let's<br />
examine it up close:<br />
<br />
*Main> :t arbitrary<br />
arbitrary :: (Arbitrary a) => Gen a<br />
<br />
See that "Gen a"? Reminds you of something? Right! Think of "IO a" and "Parser<br />
a" which we've seen already. This is yet another example of action-returning<br />
function, which could be used inside "do"-notation. (You might ask yourself,<br />
wouldn't it be useful to generalize that convenient concept of actions and<br />
"do"? Of course! It is already done, the concept is called "[[Monad]]" and we will talk about it in Chapter 400 :) )<br />
<br />
Since 'a' here is a [[type variable]] which is an instance of "Arbitrary", we could substitute "Dir" here. So, how we can make and return an action of type "Gen Dir"?<br />
<br />
Let's look at the code:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM n (elements "fubar/")<br />
</haskell><br />
<br />
We have used the library-provided functions "choose" and "elements" to build up<br />
"gen_size :: Gen Int" and "gen_name :: Gen String" (exercise: don't take my<br />
word on that. Find a way to check types of "gen_name" and "gen_size"). Since<br />
"Int" and "String" are components of "Dir", we sure must be able to use "Gen<br />
Int" and "Gen String" to build "Gen Dir". But where is the "do" block for<br />
that? There is none, and there is only single call to "liftM2". <br />
<br />
Let's examine it:<br />
<br />
*Main> :t liftM2<br />
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r<br />
<br />
Kind of scary, right? Let's provide typechecker with more context:<br />
<br />
*Main> :t liftM2 Dir<br />
liftM2 Dir :: (Monad m) => m Int -> m String -> m Dir<br />
<br />
Since you already heard that "Gen" is a "Monad", you could substitute "Gen" for "m" here, obtaining "liftM2 Dir :: (Monad Gen) => Gen Int -> Gen String -><br />
Gen Dir". Exactly what we wanted!<br />
<br />
Consider "liftM2" to be "advanced topic" of this chapter (which we will cover<br />
later) and just note for now that:<br />
* "2" is a number of arguments for data constructor "Dir" and we have used "liftM2" to construct "Gen Dir" out of "Dir"<br />
* There are also "liftM", "liftM3", "liftM4", "liftM5"<br />
* "liftM2" is defined as "liftM2 f a1 a2 = do x<-a1; y<-a2; return (f x y)"<br />
<br />
Hopefully, this will all make sense after you read it for the third<br />
time ;)<br />
<br />
Oh, by the way - don't forget to "darcs record" your changes!<br />
<br />
== Chapter 4: REALLY packing the knapsack this time == <br />
<br />
In this chapter we are going to write another not-so-trivial packing<br />
method, compare packing methods efficiency, and learn something new<br />
about debugging and profiling of the Haskell programs along the way.<br />
<br />
It might not be immediately obvious whether our packing algorithm is<br />
effective, and if yes - in which particular way? Whether it's runtime,<br />
memory consumption or result are of sufficient quality, are there any<br />
alternative algorithms, and how do they compare to each other?<br />
<br />
Let's code another solution to the knapsack packing problem, called the "dynamic programming method" and put both variants to the test.<br />
<br />
This time, I'll not dissect the listing and explain it bit by bit. Instead, comments are provided in the code:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-1.hs'<br />
----------------------------------------------------------------------------------<br />
-- Dynamic programming solution to the knapsack (or, rather, disk) packing problem<br />
--<br />
-- Let the `bestDisk x' be the "most tightly packed" disk of total <br />
-- size no more than `x'.<br />
precomputeDisksFor :: [Dir] -> [DirPack]<br />
precomputeDisksFor dirs = <br />
-- By calculating `bestDisk' for all possible disk sizes, we could<br />
-- obtain a solution for particular case by simple lookup in our list of<br />
-- solutions :)<br />
let precomp = map bestDisk [0..] <br />
<br />
-- How to calculate `bestDisk'? Lets opt for a recursive definition:<br />
-- Recursion base: best packed disk of size 0 is empty<br />
bestDisk 0 = DirPack 0 []<br />
-- Recursion step: for size `limit`, bigger than 0, best packed disk is<br />
-- computed as follows:<br />
bestDisk limit = <br />
-- 1. Take all non-empty dirs that could possibly fit to that disk by itself.<br />
-- Consider them one by one. Let the size of particular dir be `dir_size d'.<br />
-- Let's add it to the best-packed disk of size <= (limit - dir_size d), thus<br />
-- producing the disk of size <= limit. Lets do that for all "candidate"<br />
-- dirs that are not yet on our disk:<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(limit - dir_size d)<br />
, d `notElem` ds<br />
] of<br />
-- We either fail to add any dirs (probably, because all of them too big).<br />
-- Well, just report that disk must be left empty:<br />
[] -> DirPack 0 []<br />
-- Or we produce some alternative packings. Let's choose the best of them all:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
in precomp<br />
<br />
-- When we precomputed disk of all possible sizes for the given set of dirs, solution to <br />
-- particular problem is simple: just take the solution for the required 'media_size' and<br />
-- that's it!<br />
dynamic_pack dirs = (precomputeDisksFor dirs)!!media_size<br />
</haskell><br />
<br />
Notice that it took almost the same amount of text to describe algorithm and to write implementation for it. Nice, eh?<br />
<br />
----<br />
<br />
'''Exercises:'''<br />
* Make all necessary amendments to the previously written code to make this example compile. Hints: browse modules Data.List and Data.Ix for functions that are "missing" - maybe you will find them there (use ":browse Module.Name" at ghci prompt). Have you had to define some new instances of some classes? How did you do that?<br />
* <tt>[ other_function local_binding | x <- some_list, x > 0, let local_binding = some_function x ]</tt> is called a "list comprehension". This is another example of "syntactic sugar", which could lead to nicely readable code, but, when abused, could lead to syntactic caries :) Do you understand what does this sample do: <tt>let solve x = [ y | x <- [0..], y<-[0..], y == x * x ]</tt>? Could write (with help of decent tutorial) write de-sugared version of this? (Yes, I know that finding a square root does not require list traversals, but for the sake of self-education try and do it)<br />
* Notice that in order to code quite complex implementation of <tt>precomputeDisksFor</tt> we split it up in several smaller pieces and put them as a '''local bindings''' inside '''let''' clause.<br />
* Notice that we use '''pattern matching''' to both define <tt>bestKnap</tt> on case-by-case basis and to "peer into" ('''de-construct''') <tt>DirPack</tt> in the <tt>let (DirPack s ds)=precomp!!(limit - dir_size d)</tt> line<br />
* Notice how we use function composition to compose complex condition to filter the list of dirs<br />
<br />
---- <br />
<br />
Before we move any further, let's do a small cosmetic change to our<br />
code. Right now our solution uses 'Int' to store directory size. In<br />
Haskell, 'Int' is a platform-dependent integer, which imposes certain<br />
limitations on the values of this type. Attempt to compute the value<br />
of type 'Int' that exceeds the bounds will result in overflow error.<br />
Standard Haskell libraries have special typeclass<br />
<hask>Bounded</hask>, which allows to define and examine such bounds:<br />
<br />
Prelude> :i Bounded <br />
class Bounded a where<br />
minBound :: a<br />
maxBound :: a<br />
-- skip --<br />
instance Bounded Int -- Imported from GHC.Enum<br />
<br />
We see that 'Int' is indeed bounded. Let's examine the bounds:<br />
<br />
Prelude> minBound :: Int <br />
-2147483648<br />
Prelude> maxBound :: Int<br />
2147483647<br />
Prelude> <br />
<br />
Those of you who are C-literate, will spot at once that in this case<br />
the 'Int' is so-called "signed 32-bit integer", which means that we<br />
would run into errors trying to operate on directories/directory packs<br />
which are bigger than 2 GB.<br />
<br />
Luckily for us, Haskell has integers of arbitrary precision (limited<br />
only by the amount of available memory). The appropriate type is<br />
called 'Integer':<br />
<br />
Prelude> (2^50) :: Int<br />
0 -- overflow<br />
Prelude> (2^50) :: Integer<br />
1125899906842624 -- no overflow<br />
Prelude><br />
<br />
Lets change definitions of 'Dir' and 'DirPack' to allow for bigger<br />
directory sizes:<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
data Dir = Dir {dir_size::Integer, dir_name::String} deriving (Eq,Show)<br />
data DirPack = DirPack {pack_size::Integer, dirs::[Dir]} deriving Show<br />
</haskell><br />
<br />
Try to compile the code or load it into ghci. You will get the<br />
following errors:<br />
<br />
cd-fit-4-2.hs:73:79:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the expression: limit - (dir_size d)<br />
In the second argument of `(!!)', namely `(limit - (dir_size d))'<br />
<br />
cd-fit-4-2.hs:89:47:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the second argument of `(!!)', namely `media_size'<br />
In the definition of `dynamic_pack':<br />
dynamic_pack dirs = (precomputeDisksFor dirs) !! media_size<br />
<br />
<br />
It seems like Haskell have some troubles using 'Integer' with '(!!)'.<br />
Let's see why:<br />
<br />
Prelude> :t (!!)<br />
(!!) :: [a] -> Int -> a<br />
<br />
Seems like definition of '(!!)' demands that index will be 'Int', not<br />
'Integer'. Haskell never converts any type to some other type<br />
automatically - programmer have to explicitly ask for that.<br />
<br />
I will not repeat the section "Standard Haskell Classes" from<br />
[http://haskell.org/onlinereport/basic.html the Haskell Report] and<br />
explain, why typeclasses for various numbers organized the way they<br />
are organized. I will just say that standard typeclass<br />
<hask>Num</hask> demands that numeric types implement method<br />
<hask>fromInteger</hask>:<br />
<br />
Prelude> :i Num<br />
class (Eq a, Show a) => Num a where<br />
(+) :: a -> a -> a<br />
(*) :: a -> a -> a<br />
(-) :: a -> a -> a<br />
negate :: a -> a<br />
abs :: a -> a<br />
signum :: a -> a<br />
fromInteger :: Integer -> a<br />
-- Imported from GHC.Num<br />
instance Num Float -- Imported from GHC.Float<br />
instance Num Double -- Imported from GHC.Float<br />
instance Num Integer -- Imported from GHC.Num<br />
instance Num Int -- Imported from GHC.Num<br />
<br />
We see that <hask>Integer</hask> is a member of typeclass<br />
<hask>Num</hask>, thus we could use <hask>fromInteger</hask> to make<br />
the type errors go away:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
-- snip<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
] of<br />
-- snip<br />
dynamic_pack dirs = (precomputeDisksFor dirs)!!(fromInteger media_size)<br />
-- snip<br />
</haskell><br />
<br />
Type errors went away, but careful reader will spot at once that when<br />
expression <hask>(limit - dir_size d)</hask> will exceed the bounds<br />
for <hask>Int</hask>, overflow will occur, and we will not access the<br />
correct list element. Don't worry, we will deal with this in a short while.<br />
<br />
Now, lets code the QuickCheck test for this function along the lines of the test for <tt>greedy_pack</tt>:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack ds <br />
in pack_size pack == pack_size (dynamic_pack (dirs pack))<br />
</haskell><br />
<br />
Now, lets try to run (DON'T PANIC and save all you work in other applications first!):<br />
<br />
*Main> quickCheck prop_dynamic_pack_is_fixpoint<br />
<br />
Now, you took my advice seriously, don't you? And you did have your '''Ctrl-C''' handy, didn't you? Most probably, the attempt to run the test resulted in all your memory being taken by <tt>ghci</tt> process, which you hopefully interrupted soon enough by pressing '''Ctrl-C'''.<br />
<br />
What happened? Who ate all the memory? How to debug this problem? GHC comes with profiling abilities, but we could not use them - they produce report after program terminates, and our doesn't seem to do so without consuming several terabytes of memory first. Still, there is a lot of room for maneuver.<br />
<br />
Let's see. Since we called <tt>dynamic_pack</tt> and it ate all the memory, let's not do this again. Instead, let's see what this function does and tweak it a bit to explore it's behavior.<br />
<br />
Since we already know that random lists of "Dir"s generated for our QuickCheck tests are of modest size (after all, <tt>greedy_pack</tt> munches them without significant memory consumption), the size of the input most probably is not the issue. However, <tt>dynamic_pack_is_fixpoint</tt> is building quite a huge list internally (via <tt>precomputeDisksFor</tt>). Could this be a problem?<br />
<br />
Let's turn the timing/memory stats on (":set +s" on ghci prompt) and try to peek into various elements of list returned by <tt>precomputeDisksFor</tt>:<br />
<br />
Prelude> :l cd-fit.hs<br />
Compiling Main ( cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :set +s<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 0<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.06 secs, 1277972 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.00 secs, 0 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.01 secs, 1519064 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 1000<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.03 secs, 1081808 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10000<br />
DirPack {pack_size = 0, dirs = []}<br />
(1.39 secs, 12714088 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100000<br />
Interrupted.<br />
<br />
Aha! This seems to be a problem, since computation of 100000 fails to terminate in "reasonable" time, and to think that we have tried to compute <tt>700*1024*1024</tt>th element...<br />
<br />
Lets modify our code a bit, to allow disk size to be tweaked:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-3.hs'<br />
dynamic_pack limit dirs = (precomputeDisksFor dirs)!!(fromInteger limit)<br />
<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack media_size ds <br />
in pack_size pack == pack_size (dynamic_pack media_size (dirs pack))<br />
<br />
prop_dynamic_pack_small_disk ds =<br />
let pack = dynamic_pack 50000 ds<br />
in pack_size pack == pack_size (dynamic_pack 50000 (dirs pack))<br />
<br />
-- rename "old" main to "moin"<br />
main = quickCheck prop_dynamic_pack_small_disk<br />
</haskell><br />
<br />
Compute a profiling version of you code with <tt>ghc -O --make -prof -auto-all -o cd-fit cd-fit.hs</tt> and run it like this: <br />
<br />
$ ./cd-fit +RTS -p<br />
OK, passed 100 tests.<br />
<br />
First thing, note that our code satisfies at least one simple property. Good. Now let's examine profile. Look into file "cd-fit.prof", which was produced in your current directory. <br />
<br />
Most probably, you'll see something like this:<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 2.18 secs (109 ticks @ 20 ms)<br />
total alloc = 721,433,008 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
precomputeDisksFor Main 88.1 99.8<br />
dynamic_pack Main 11.0 0.0<br />
<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
<br />
MAIN MAIN 1 0 0.0 0.0 100.0 100.0<br />
CAF Main 174 11 0.9 0.2 100.0 100.0<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 99.1 99.8<br />
dynamic_pack Main 182 200 11.0 0.0 99.1 99.8<br />
precomputeDisksFor Main 183 200 88.1 99.8 88.1 99.8<br />
main Main 180 1 0.0 0.0 0.0 0.0<br />
<br />
Examine column of "individual %alloc". As we thought, all memory was<br />
allocated within <tt>precomputeDisksFor</tt>. However, amount of<br />
memory allocated (more than 700 MB, according to the line "total<br />
alloc") seems to be a little too much for our simple task. We will dig<br />
deeper and find where we a wasting it.<br />
<br />
Let's examine memory consumption a little closer via so-called "heap<br />
profiles". Run <tt>./cd-fit +RTS -hb</tt>. This produces "biographical<br />
heap profile", which tells us how various parts of the memory were<br />
used during the program run time. Heap profile was saved to<br />
"cd-fit.hp". It is next to impossible to read and comprehend it as is,<br />
so use "hp2ps cd-fit.hp" to produce a nice PostScript picture which<br />
is worth a thousand words. View it with "gv" or "ghostview" or "full<br />
Adobe Acrobat (not Reader)". (This and subsequent pictures are<br />
'''not''' attached here).<br />
<br />
Notice that most of the graph is taken up by region marked as "VOID". <br />
This means that memory allocated was never used. Notice that there is<br />
'''no''' areas marked as "USE", "LAG" or "DRAG". Seems like our<br />
program hardly uses '''any''' of the allocated memory at all. Wait a<br />
minute! How could that be? Surely it must use something when it packs<br />
to the imaginary disks of 50000 bytes those random-generated<br />
directories which are 10 to 1400 Mb in size.... Oops. Severe size<br />
mismatch. We should have spotted it earlier, when we were timing<br />
<tt>precomputeDisksFor</tt>. Scroll back and observe how each run<br />
returned the very same result - empty directory set.<br />
<br />
Our random directories are too big, but nevertheless code spends time<br />
and memory trying to "pack" them. Obviously,<br />
<tt>precomputeDisksFor</tt> (which is responsible for 90% of total<br />
memory consumption and run time) is flawed in some way.<br />
<br />
Let's take a closer look at what takes up so much memory. Run<br />
<tt>./cd-fit +RTS -h -hbvoid</tt> and produce PostScript picture for<br />
this memory profile. This will give us detailed breakdown of all<br />
memory whose "biography" shows that it's been "VOID" (unused). My<br />
picture (and I presume that yours as well) shows that VOID memory<br />
comprises of "thunks" labeled "precomputeDisksFor/pre...". We could<br />
safely assume that second word would be "precomp" (You wonder why?<br />
Look again at the code and try to find function named "pre.*" which is<br />
called from inside <tt>precomputeDisksFor</tt>)<br />
<br />
This means that memory has been taken by the list generated inside<br />
"precomp". Rumor has it that memory leaks with Haskell are caused by<br />
either too little laziness or too much laziness. It seems like we have<br />
too little laziness here: we evaluate more elements of the list that<br />
we actually need and keep them from being garbage-collected. <br />
<br />
Note how we look up element from "precomp" in this piece of code:<br />
<br />
<haskell><br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
</haskell><br />
<br />
<br />
Obviously, the whole list generated by "precomp" must be kept in<br />
memory for such lookups, since we can't be sure that some element<br />
could be garbage collected and will not be needed again.<br />
<br />
Let's rewrite the code to eliminate the list (incidentally, this will also deal with the possible Int overflow while accessing the "precomp" via (!!) operator):<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-4.hs'<br />
-- Let the `bestDisk x' be the "most tightly packed" disk of total <br />
-- size no more than `x'.<br />
-- How to calculate `bestDisk'? Lets opt for a recursive definition:<br />
-- Recursion base: best packed disk of size 0 is empty and best-packed<br />
-- disk for empty list of directories on it is also empty.<br />
bestDisk 0 _ = DirPack 0 []<br />
bestDisk _ [] = DirPack 0 []<br />
-- Recursion step: for size `limit`, bigger than 0, best packed disk is<br />
-- computed as follows:<br />
bestDisk limit dirs =<br />
-- Take all non-empty dirs that could possibly fit to that disk by itself.<br />
-- Consider them one by one. Let the size of particular dir be `dir_size d'.<br />
-- Let's add it to the best-packed disk of size <= (limit - dir_size d), thus<br />
-- producing the disk of size <= limit. Lets do that for all "candidate"<br />
-- dirs that are not yet on our disk:<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) dirs <br />
, d `notElem` ds<br />
] of<br />
-- We either fail to add any dirs (probably, because all of them too big).<br />
-- Well, just report that disk must be left empty:<br />
[] -> DirPack 0 []<br />
-- Or we produce some alternative packings. Let's choose the best of them all:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
dynamic_pack limit dirs = bestDisk limit dirs<br />
</haskell><br />
<br />
<br />
Compile the profiling version of this code and obtain the overall<br />
execution profile (with "+RTS -p"). You'll get something like this:<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 0.00 secs (0 ticks @ 20 ms)<br />
total alloc = 1,129,520 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
CAF GHC.Float 0.0 4.4<br />
main Main 0.0 93.9<br />
<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
MAIN MAIN 1 0 0.0 0.0 0.0 100.0<br />
main Main 180 1 0.0 93.9 0.0 94.2<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 0.0 0.3<br />
dynamic_pack Main 182 200 0.0 0.2 0.0 0.3<br />
bestDisk Main 183 200 0.0 0.1 0.0 0.1<br />
<br />
We achieved the major improvement: memory consumption is reduced by factor<br />
of 700! Now we could test the code on the "real task" - change the<br />
code to run the test for packing the full-sized disk:<br />
<br />
<haskell><br />
main = quickCheck prop_dynamic_pack_is_fixpoint<br />
</haskell><br />
<br />
Compile with profiling and run (with "+RTS -p"). If you are not lucky<br />
and a considerably big test set would be randomly generated for your<br />
runs, you'll have to wait. And wait even more. And more.<br />
<br />
Go make some tea. Drink it. Read some Tolstoi (Do you have "War and<br />
peace" handy?). Chances are that by the time you are done with<br />
Tolstoi, program will still be running (just take my word on it, don't<br />
check).<br />
<br />
If you are lucky, your program will finish fast enough and leave you<br />
with profile. According to a profile, program spends 99% of its time<br />
inside <tt>bestDisk</tt>. Could we speed up <tt>bestDisk</tt> somehow?<br />
<br />
Note that <tt>bestDisk</tt> performs several simple calculation for<br />
which it must call itself. However, it is done rather inefficiently -<br />
each time we pass to <tt>bestDisk</tt> the exact same set of<br />
directories as it was called with, even if we have already "packed"<br />
some of them. Let's amend this:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| let small_enough = filter ( (inRange (0,limit)).dir_size ) dirs<br />
, d <- small_enough<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) (delete d small_enough)<br />
] of<br />
</haskell><br />
<br />
Recompile and run again. Runtimes could be lengthy, but bearable, and<br />
number of times <tt>bestDisk</tt> is called (according to the profile)<br />
should decrease significantly. <br />
<br />
Finally, let's compare both packing algorithms. Intuitively, we feel<br />
that greedy algorithm should produce worse results, don't we? Lets put<br />
this feeling to the test:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
prop_greedy_pack_is_no_better_than_dynamic_pack ds =<br />
pack_size (greedy_pack ds) <= pack_size (dynamic_pack media_size ds)<br />
</haskell><br />
<br />
Verify that it is indeed so by running <tt>quickCheck</tt> for this<br />
test several time. I feel that this concludes our knapsacking<br />
exercises. <br />
<br />
Adventurous readers could continue further by implementing so-called<br />
"scaling" for <tt>dynamic_pack</tt> where we divide all directory<br />
sizes and medium size by the size of the smallest directory to proceed<br />
with smaller numbers (which promises faster runtimes).<br />
<br />
== Chapter 5: (Ab)using monads and destructing constructors for fun and profit ==<br />
<br />
We already mentioned monads quite a few times. They are described in<br />
numerous articles and tutorial (See Chapter 400). It's hard to read a<br />
daily dose of any Haskell mailing list and not to come across a word<br />
"monad" a dozen times.<br />
<br />
Since we already made quite a progress with Haskell, it's time we<br />
revisit the monads once again. I will let the other sources teach you<br />
theory behind the monads, overall usefulness of the concept, etc.<br />
Instead, I will focus on providing you with examples.<br />
<br />
Let's take a part of the real world program which involves XML<br />
processing. We will work with XML tag attributes, which are<br />
essentially named values:<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
type Attribute = (Name, AttValue)<br />
</haskell><br />
<br />
'Name' is a plain string, and value could be '''either''' string or<br />
references (also strings) to another attributes which holds the actual<br />
value (now, this is not a valid XML thing, but for the sake of<br />
providing a nice example, let's accept this). Word "either" suggests<br />
that we use 'Either' datatype:<br />
<haskell><br />
type AttValue = Either Value [Reference]<br />
type Name = String<br />
type Value = String<br />
type Reference = String<br />
<br />
-- Sample list of simple attributes:<br />
simple_attrs = [ ( "xml:lang", Left "en" )<br />
, ( "xmlns", Left "jabber:client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
<br />
-- Sample list of attributes with references:<br />
complex_attrs = [ ( "xml:lang", Right ["lang"] )<br />
, ( "lang", Left "en" )<br />
, ( "xmlns", Right ["ns","subns"] )<br />
, ( "ns", Left "jabber" )<br />
, ( "subns", Left "client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
</haskell><br />
<br />
'''Our task is:''' to write a function that will look up a value of<br />
attribute by it's name from the given list of attributes. When<br />
attribute contains reference(s), we resolve them (looking for the<br />
referenced attribute in the same list) and concatenate their values,<br />
separated by semicolon. Thus, lookup of attribute "xmlns" form both<br />
sample sets of attributes should return the same value.<br />
<br />
Following the example set by the <hask>Data.List.lookup</hask> from<br />
the standard libraries, we will call our function<br />
<hask>lookupAttr</hask> and it will return <hask>Maybe Value</hask>,<br />
allowing for lookup errors:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
-- Since we dont have code for 'lookupAttr', but want<br />
-- to compile code already, we use the function 'undefined' to<br />
-- provide default, "always-fail-with-runtime-error" function body.<br />
lookupAttr = undefined<br />
</haskell><br />
<br />
Let's try to code <hask>lookupAttr</hask> using <hask>lookup</hask> in<br />
a very straightforward way:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
import Data.List<br />
<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
lookupAttr nm attrs = <br />
-- First, we lookup 'Maybe AttValue' by name and<br />
-- check whether we are successful:<br />
case (lookup nm attrs) of<br />
-- Pass the lookup error through.<br />
Nothing -> Nothing <br />
-- If given name exist, see if it is value of reference:<br />
Just attv -> case attv of<br />
-- It's a value. Return it!<br />
Left val -> Just val<br />
-- It's a list of references :(<br />
-- We have to look them up, accounting for<br />
-- possible failures.<br />
-- First, we will perform lookup of all references ...<br />
Right refs -> <br />
let vals = [ lookupAttr ref attrs | ref <- refs ]<br />
-- .. then, we will exclude lookup failures<br />
wo_failures = filter (/=Nothing) vals<br />
-- ... find a way to remove annoying 'Just' wrapper<br />
stripJust (Just v) = v<br />
-- ... use it to extract all lookup results as strings<br />
strings = map stripJust wo_failures<br />
in<br />
-- ... finally, combine them into single String. <br />
-- If all lookups failed, we should pass failure to caller.<br />
case null strings of<br />
True -> Nothing<br />
False -> Just (concat (intersperse ":" strings))<br />
</haskell><br />
<br />
Testing:<br />
<br />
*Main> lookupAttr "xmlns" complex_attrs<br />
Just "jabber:client"<br />
*Main> lookupAttr "xmlns" simple_attrs<br />
Just "jabber:client"<br />
*Main><br />
<br />
It works, but ... It seems strange that such a boatload of code<br />
required for quite simple task. If you examine the code closely,<br />
you'll see that the code bloat is caused by:<br />
<br />
* the fact that after each step we check whether the error occurred<br />
<br />
* unwrapping Strings from <hask>Maybe</hask> and <hask>Either</hask> data constructors and wrapping them back.<br />
<br />
At this point C++/Java programmers would say that since we just pass<br />
errors upstream, all those cases could be replaced by the single "try<br />
... catch ..." block, and they would be right. Does this mean that<br />
Haskell programmers are reduced to using "case"s, which were already<br />
obsolete 10 years ago?<br />
<br />
Monads to the rescue! As you can read elsewhere (see section 400),<br />
monads are used in advanced ways to construct computations from other<br />
computations. Just what we need - we want to combine several simple<br />
steps (lookup value, lookup reference, ...) into function<br />
<hask>lookupAttr</hask> in a way that would take into account possible<br />
failures.<br />
<br />
Lets start from the code and dissect in afterwards:<br />
<haskell><br />
-- Taken from 'chapter5-2.hs'<br />
import Control.Monad<br />
<br />
lookupAttr' nm attrs = do<br />
-- First, we lookup 'AttValue' by name<br />
attv <- lookup nm attrs<br />
-- See if it is value of reference:<br />
case attv of<br />
-- It's a value. Return it!<br />
Left val -> Just val<br />
-- It's a list of references :(<br />
-- We have to look them up, accounting for<br />
-- possible failures.<br />
-- First, we will perform lookup of all references ...<br />
Right refs -> do vals <- sequence $ map (flip lookupAttr' attrs) refs<br />
-- ... since all failures are already excluded by "monad magic",<br />
-- ... all all 'Just's have been removed likewise,<br />
-- ... we just combine values into single String,<br />
-- ... and return failure if it is empty. <br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
'''Exercise''': compile the code, test that <hask>lookupAttr</hask><br />
and <hask>lookupAttr'</hask> really behave in the same way. Try to<br />
write a QuickCheck test for that, defining the <br />
<hask>instance Arbitrary Name</hask> such that arbitrary names will be taken from<br />
names available in <hask>simple_attrs</hask>.<br />
<br />
Well, back to the story. Noticed the drastic reduction in code size?<br />
If you drop comments, the code will occupy mere 7 lines instead of 13<br />
- almost two-fold reduction. How we achieved this?<br />
<br />
First, notice that we never ever check whether some computation<br />
returns <hask>Nothing</hask> anymore. Yet, try to lookup some<br />
non-existing attribute name, and <hask>lookupAttr'</hask> will return<br />
<hask>Nothing</hask>. How does this happen? Secret lies in the fact<br />
that type constructor <hask>Maybe</hask> is a "monad".<br />
<br />
We use keyword <hask>do</hask> to indicate that following block of<br />
code is a sequence of '''monadic actions''', where '''monadic magic'''<br />
have to happen when we use '<-', 'return' or move from one action to<br />
another.<br />
<br />
Different monads have different '''magic'''. Library code says that<br />
type constructor <hask>Maybe</hask> is such a monad that we could use<br />
<hask><-</hask> to "extract" values from wrapper <hask>Just</hask> and<br />
use <hask>return</hask> to put them back in form of<br />
<hask>Just some_value</hask>. When we move from one action in the "do" block to<br />
another a check happens. If the action returned <hask>Nothing</hask>,<br />
all subsequent computations will be skipped and the whole "do" block<br />
will return <hask>Nothing</hask>.<br />
<br />
Try this to understand it all better:<br />
<haskell><br />
*Main> let foo x = do v <- x; return (v+1) in foo (Just 5)<br />
Just 6<br />
*Main> let foo x = do v <- x; return (v+1) in foo Nothing <br />
Nothing<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo (Just 'a')<br />
Just 97<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo Nothing <br />
Nothing<br />
*Main> <br />
</haskell><br />
<br />
Do not mind <hask>sequence</hask> and <hask>guard</hask> just for now<br />
- we will get to them in the little while.<br />
<br />
Since we already removed one reason for code bloat, it is time to deal<br />
with the other one. Notice that we have to use <hask>case</hask> to<br />
'''deconstruct''' the value of type <hask>Either Value<br />
[Reference]</hask>. Surely we are not the first to do this, and such<br />
use case have to be quite a common one. <br />
<br />
Indeed, there is a simple remedy for our case, and it is called<br />
<hask>either</hask>:<br />
<br />
*Main> :t either<br />
either :: (a -> c) -> (b -> c) -> Either a b -> c<br />
<br />
Scary type signature, but here are examples to help you grok it:<br />
<br />
*Main> :t either (+1) (length) <br />
either (+1) (length) :: Either Int [a] -> Int<br />
*Main> either (+1) (length) (Left 5)<br />
6<br />
*Main> either (+1) (length) (Right "foo")<br />
3<br />
*Main> <br />
<br />
Seems like this is exactly our case. Let's replace the<br />
<hask>case</hask> with invocation of <hask>either</hask>:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-3.hs'<br />
lookupAttr'' nm attrs = do<br />
attv <- lookup nm attrs<br />
either Just (dereference attrs) attv<br />
where<br />
dereference attrs refs = do <br />
vals <- sequence $ map (flip lookupAttr'' attrs) refs<br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
It keeps getting better and better :)<br />
<br />
Now, as semi-exercise, try to understand the meaning of "sequence",<br />
"guard" and "flip" looking at the following ghci sessions:<br />
<br />
*Main> :t sequence<br />
sequence :: (Monad m) => [m a] -> m [a]<br />
*Main> :t [Just 'a', Just 'b', Nothing, Just 'c']<br />
[Just 'a', Just 'b', Nothing, Just 'c'] :: [Maybe Char]<br />
*Main> :t sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
sequence [Just 'a', Just 'b', Nothing, Just 'c'] :: Maybe [Char]<br />
<br />
*Main> sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b', Nothing]<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b']<br />
Just "ab"<br />
<br />
*Main> :t [putStrLn "a", putStrLn "b"]<br />
[putStrLn "a", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", putStrLn "b"]<br />
sequence [putStrLn "a", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", putStrLn "b"]<br />
a<br />
b<br />
<br />
*Main> :t [putStrLn "a", fail "stop here", putStrLn "b"]<br />
[putStrLn "a", fail "stop here", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
sequence [putStrLn "a", fail "stop here", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
a<br />
*** Exception: user error (stop here)<br />
<br />
Notice that for monad <hask>Maybe</hask> sequence continues execution<br />
until the first <hask>Nothing</hask>. The same behavior could be<br />
observed for IO monad. Take into account that different behaviors are<br />
not hardcoded into the definition of <hask>sequence</hask>!<br />
<br />
Now, let's examine <hask>guard</hask>:<br />
<br />
*Main> let foo x = do v <- x; guard (v/=5); return (v+1) in map foo [Just 4, Just 5, Just 6] <br />
[Just 5,Nothing,Just 7]<br />
<br />
As you can see, it's just a simple way to "stop" execution at some<br />
condition.<br />
<br />
If you have been hooked on monads, I urge you to read "All About<br />
Monads" right now (link in Chapter 400).<br />
<br />
== Chapter 6: Where do you want to go tomorrow? ==<br />
<br />
As the name implies, the author is open for proposals - where should<br />
we go next? I had networking + xml/xmpp in mind, but it might be too<br />
heavy and too narrow for most of the readers.<br />
<br />
What do you think? Drop me a line.<br />
<br />
== Chapter 400: Monads up close ==<br />
<br />
Read [http://en.wikibooks.org/wiki/Haskell/Understanding_monads this wikibook chapter]. <br />
Then, read [http://horna.org.ua/books/All_About_Monads.pdf "All about monads"] (PDF).<br />
'Nuff said :)<br />
<br />
== Chapter 500: IO up close ==<br />
<br />
Shows that:<br />
<br />
<haskell><br />
c = do a <- someAction<br />
b <- someOtherAction<br />
print (bar b)<br />
print (foo a)<br />
print "done"<br />
</haskell><br />
<br />
really is just a syntax sugar for:<br />
<br />
<haskell><br />
c = someAction >>= \a -><br />
someOtherAction >>= \b -><br />
print (bar b) >><br />
print (foo a) >><br />
print "done"<br />
</haskell><br />
<br />
and explains about ">>=" and ">>". Oh wait. This was already explained<br />
in Chapter 400 :)<br />
<br />
== Chapter 9999: Installing Haskell Compiler/Interpreter and all necessary software ==<br />
<br />
Plenty of material on this on the web and this wiki. Just go get<br />
yourself installation of [[GHC]] (6.4 or above) or [[Hugs]] (v200311 or<br />
above) and "[[darcs]]", which we will use for version control.<br />
<br />
== Chapter 10000: Thanks! ==<br />
<br />
Thanks for comments, proofreading, good advice and kind words go to:<br />
Helge, alt, dottedmag, Paul Moore, Ben Rudiak-Gould, Jim Wilkinson,<br />
Andrew Zhdanov (avalez), Martin Percossi, SpellingNazi, Davor<br />
Cubranic, Brett Giles, Stdrange, Brian Chrisman, Nathan Collins,<br />
Anastasia Gornostaeva (ermine), Remi, Ptolomy, Zimbatm,<br />
HenkJanVanTuyl, Miguel, Mforbes, Kartik Agaram, Jake Luck, Ketil<br />
Malde, Mike Mimic, Jens Kubieziel.<br />
<br />
If I should have mentioned YOU and forgot - tell me so.<br />
<br />
Without you I would have stopped after Chapter 1 :)<br />
<br />
Languages: [[Haskellへのヒッチハイカーガイド|jp]], [[Es/Guía de Haskell para autoestopistas|es]]</div>Imzhttps://wiki.haskell.org/index.php?title=Es/Gu%C3%ADa_de_Haskell_para_autoestopistas&diff=39268Es/Guía de Haskell para autoestopistas2011-03-30T19:10:16Z<p>Imz: /* Capítulo 1: Omnipresente “¡Hola mundo!” y otras formas de hacer IO en Haskell */ The pseudocode as human-language sentences: this way it's more obvious each of the 3 lines is an item of our plan, and the plan has an imperative spirit for now</p>
<hr />
<div>{{Es/Traducción en progreso|titulo=Guía de Haskell para autoestopistas|original=Hitchhikers guide to Haskell}}<br />
<br />
== Preámbulo: ¡NO CORRER! ==<br />
<br />
Experiencias recientes de algunos compañeros programadores de C++/Java indican que leyeron varios tutoriales sobre Haskell con "velocidad exponencial" (piensa en como las sesiones de TCP/IP aumentan). Al principio son pocas y prudentes, pero cuando ven que las primeras 3-5 páginas no contienen "nada interesante" en términos de código y ejemplos, empiezan a saltarse párrafos, después capítulos, después páginas enteras, tan sólo decelerando - a menudo hasta parar completamente - alrededor de la página 50, encontrándose con el grueso de conceptos como "clases de tipos", "constructores de tipos", "IO monádica", punto en el que normalmente les entra el pánico, piensa en una escusa perfectamente racional para no seguir leyendo, y se olvida alegremente de este triste y escalofriante encuentro con Haskell (ya que los seres humanos tendemos a olvidar las cosas tristas y escalofriantes).<br />
<br />
Este texto pretende introducir al lector a los aspectos prácticos de Haskell desde el principio del todo (los planes para el primer capítulo incluyen: I/O, darcs, Parsec, QuickCheck, depurar y perfilar, por mencionar algunos). Se supone que el lector sabe (donde encontrar) por lo menos los primeros pasos de Haskell: como ejecutar "hugs” o “ghci", '''ese diseño es 2-dimensional''', etc. Aparte de eso, no esperamos avanzar radicalmente, e iremos paso por paso para no perder a los lectores por el camino. Así que NO CORRER, coge la toalla contigo y continua leyendo.<br />
<br />
'''Si te has saltado el párrafo anterior''', me gustaría destacar una vez más que Haskell es sensible a la indentación y espaciado, así que presta atención cuando hagas copias o alineación manual de código en el editor de texto con fuentes proporcionales.<br />
<br />
Ah, casi me olvido: el autor está muy interesado en CUALQUIER opinión. Escríbele algunas líneas o palabras (mira [http://www.haskell.org/haskellwiki/User:Adept Adept] para la información de contacto) o propón cambios al tutorial mediante darcs ([http://adept.linux.kiev.ua/repos/hhgtth/ el repositorio está aquí]) o directamente a este Wiki.<br />
<br />
== Capítulo 1: Omnipresente “¡Hola mundo!” y otras formas de hacer IO en Haskell ==<br />
<br />
Cada capítulo será dedicado a una pequeña tarea real que completaremos desde el principio.<br />
<br />
Así que aquí está la tarea para este capítulo: para liberar espacio en tu disco duro para todo el código de haskell que vas a escribir en un futuro cercano, vas a guardar algo de la vieja y polvorienta información en CDs y DVDs. Mientras que grabar CDs (o DVDs) es fácil hoy en día, normalmente ocupa algo (o mucho) tiempo decidir como grabar algunos GB de fotos digitales en CD-Rs, cuando los directorios con las imágenes varían desde 10 a 300 Mb de espacio, y no quieres grabar CDs medio llenos (o medio vacíos).<br />
<br />
El ejercicio consiste en escribir un programa que nos ayude a poner un conjunto de directorios en la cantidad mínima posible de discos, al mismo tiempo que aprovechamos cada disco lo máximo posible. Llamemos a este programa “cd-fit”.<br />
<br />
Oh. Espera. Hagamos el usual programa “hola mundo”, antes de que nos<br />
olvidemos, y después sigamos con cosas más interesante:<br />
<br />
<haskell><br />
-- Cogido de 'hola.hs'<br />
-- A partir de ahora, un comentario al principio del trozo de código<br />
-- especificará el archivo que contiene el programa entero del que fue cogido<br />
-- el trozo. Puedes coger el código del repositorio de darcs<br />
-- "http://adept.linux.kiev.ua/repos/hhgtth" introduciendo el comando <br />
-- "darcs get http://adept.linux.kiev.ua/repos/hhgtth"<br />
module Main where<br />
main = putStrLn "¡Hola mundo!"<br />
</haskell><br />
<br />
Ejecútalo:<br />
<br />
$ runhaskell ./hola.hs<br />
¡Hola mundo!<br />
<br />
Vale, ya lo hicimos. Sigamos ahora, no hay nada interesante aquí :)<br />
<br />
Cualquier desarrollo serio se debe hacer con un sistema de control de versiones, y no haremos una excepción. Usaremos el moderno sistema de control de versiones distribuido “darcs”. “Moderno” significa que está escrito en Haskell, “distribuido” significa que cada copia que funcione es un repositorio en si mismo.<br />
<br />
Primero, creemos un directorio vacío para nuestro todo nuestro código, y ejecuta “darcs init” en él, que creará un subdirectorio “_darcs” para guardar todo lo relacionado con el control de versiones dentro de él.<br />
<br />
Inicia tu editor favorito y crea un fichero nuevo llamado “cd-fits.hs” en nuestro directorio de trabajo. Ahora pensemos por un momento como funcionará nuestro programa y expresémoslo en pseudocódigo:<br />
<br />
<haskell><br />
main = Leer lista de directorio y sus tamaños.<br />
Decidir como ajustarlos a los CD-Rs.<br />
Imprimir la solución.<br />
</haskell><br />
<br />
¿Parece lógio? Pienso que si.<br />
<br />
Vamos a simplificar nuestra vida un poco y asumir por ahora que vamos calcular el espacio de los directorios de alguna forma fuera de nuestro programa (por ejemplo, con “du -sb *”) y leer esa información desde stdin. Convirtamos esto a Haskell:<br />
<br />
<haskell><br />
-- Cogido de 'cd-fit-1-1.hs'<br />
module Main where<br />
<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: tengo entrada" ++ input)<br />
-- calcular solución e imprimirla<br />
</haskell><br />
<br />
No funciona en realidad, pero bastante parecido al Español, ¿no? Paremos por un momento y miremos más de cerca que hemos escrito línea por línea.<br />
<br />
Empecemos desde arriba:<br />
<br />
<haskell><br />
-- Cogido de 'cd-fit-1-1.hs'<br />
input <- getContents<br />
</haskell><br />
<br />
Esto es un ejemplo de la sintaxis de Haskell para hacer IO (en este caso, entrada de datos). Esta línea es una instrucción para leer toda la información disponible desde stdin, devolverla como una única cadena, y unirla al símbolo “input”, de forma que podemos procesar esta cadena de la forma que querramos.<br />
<br />
¿Cómo lo sabía? ¿Memoricé todas las funciones? ¡Claro que no! Cada función tiene un tipo, que con su nombre, tiende a decir mucho sobre lo que hace la función.<br />
<br />
Lanza un entorno interactivo de Haskell y examinemos esta función de cerca:<br />
<br />
$ ghci<br />
___ ___ _<br />
/ _ \ /\ /\/ __(_)<br />
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.<br />
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/<br />
\____/\/ /_/\____/|_| Type :? for help.<br />
<br />
Loading package base-1.0 ... linking ... done.<br />
Prelude> :type getContents<br />
getContents :: IO String<br />
Prelude> <br />
<br />
<br />
Vemos que “getContents” es una función sin argumentos, que devuelve un “IO String”. El prefijo “IO” significa que es una acción de IO. Devolverá un String, cuando se evalue. La acción será evaluada cuando usemos “<-” para enlazar su resultado a un símbolo.<br />
<br />
Ten en cuenta que “<-” no es una forma bonita de asignar un valor a una variable. Es una forma de evaluar (ejecutar) acciones de IO, en otras palabras - para hacer alguna operación de I/O y devolver su resultado (si es que tiene).<br />
<br />
Podemos escoger no evaluar la acción que obtenemos de “getContents”, y en vez de eso dejarla por ahí y evaluarla más tarde:<br />
<br />
<haskell><br />
let x = getContents<br />
-- 300 líneas de código<br />
input <- x<br />
</haskell><br />
<br />
Como puedes ver, las acciones de IO pueden ser usadas como valores ordinarios. Supón que hemos construído una lista de acciones IO y hemos encontrado una forma de ejecutarlas una por una. Sería una forma de simular programación imperativa con su notación de “orden de ejecución”.<br />
<br />
Haskell te permite hacerlo mejor.<br />
<br />
La librería estandard del lenguaje (llamada “Prelude”) nos da acceso a muchas funcinoes que devuelven primitivas de acciones de IO muy útiles. Para combinarlas entre ellas para producir acciones más complejas, usamos “do”:<br />
<br />
<haskell><br />
c = do a <- algunaAcción<br />
b <- algunaOtraAcción<br />
print (bar b)<br />
print (foo a)<br />
putStrLn "hecho"<br />
</haskell><br />
<br />
De esta forma '''asociamos''' “c” a una acción con el siguiente “escenario”:<br />
* '''evalua''' la acción “algunaAcción” y '''asocia''' su resultado a “a”<br />
* después, '''evalua''' “algunaOtraAcción” y '''asocia''' su resultado a “b”<br />
* después, procesa “b” con la función “bar” e imprime su resultado<br />
* después, procesa “a” con la función “foo” e imprime su resultado<br />
* después, imprime la palabra “hecho”<br />
<br />
¿Cuando se ejecutará todo esto en realidad? Respuesta: tan rápido como evaluemos “c” usando “<-” (si devuelve un resultado, como hace “getContents”) o usándola como el nombre de una función (si no devuelve un resultado, como hace “print”):<br />
<br />
<haskell><br />
process = do putStrLn "Procesará algo"<br />
c<br />
putStrLn "Hecho"<br />
</haskell><br />
<br />
Date cuenta de que hemos cogido unas cuantas funciones (“algunaAcción”, “algunaOtraAcción”, “print”, “putStrLn”) y usando “do” creamos a partir de ellas una nueva función, que enlazamos al símbolo “c”. Ahora podemos usar “c” como una pieza de construcción para construir una función más compleja “proceso”, y podríamos continuar haciendo esto más y más. Finalmente, algunas de las funciones las mencionaremos en el código de la función “main”, función a la cual la última y más importante acción de IO en cualquier programa de Haskell está asociada.<br />
<br />
¿Cuándo se ejececutará/evaluará/forzará “main”? Tan rápido como ejecutemos el programa. Lee esto dos veces y trata de comprenderlo:<br />
<br />
''La ejecución de un programa de Haskell es una evaluación del símbolo “main” a la que hemos asociado una acción de IO. Mediante esta evaluación obtenemos el resultado de la acción''.<br />
<br />
Los lectores que estén familiriazados con programación en C++ o Java avanzado y ese conjunto de conocimiento arcano llamado “OOP Patrones de Diseño” se darán cuenta de que “construir acciones a partir de acciones” y “evaluar acciones para obtener resultados” es esencialmente un “Patrón de comando” y “Patrón de composición” combinados. Buenas noticias: en Haskell las tienes para todo tu IO, y lo tienes '''gratis''' :)<br />
<br />
----<br />
<br />
'''Ejercicio:''' Fíjate en el siguiente código:<br />
<br />
<haskell><br />
-- Cogido de 'exercise-1-1.hs'<br />
module Main where<br />
c = putStrLn "C!"<br />
<br />
combine before after =<br />
do before<br />
putStrLn "En el medio"<br />
after<br />
<br />
main = do combine c c<br />
let b = combine (putStrLn "¡Hola!") (putStrLn "¡Adios!")<br />
let d = combine (b) (combine c c)<br />
putStrLn "¡Tanto tiempo!"<br />
</haskell><br />
<br />
¿Te das cuenta de como indentamos las líneas con cuidado para que el código parezca limpio? En realidad, el código de Haskell tiene que estar alineado de esta forma, o sino no compilará. Si usas tabulados para indentar tus códigos<br />
fuente, ten en cuenta que los compiladores de Haskell aumen que el tabstop tiene de ancho 8 caracteres.<br />
<br />
A menudo las personas se quejan de que es una forma muy difícil de escribir en Haskell porque requiere que alinees el código. En realidad no es verdad. Si alineas tu código, el compilador adivinará cual es el principio y final de los bloques sintácticos. Sin embargo, si no indentas tu código, puedes especificarlos explícitamente en cada una de las expresiones y usar una distribución arbitraria como en este ejemplo:<br />
<br />
<haskell><br />
-- Cogido de 'exercise-1-2.hs'<br />
combine before after = <br />
do { before; <br />
putStrLn "En el medio"; <br />
after; };<br />
<br />
main = <br />
do { combine c c; let { b = combine (putStrLn "¡Hola!") (putStrLn "¡Adios!")};<br />
let {d = combine (b) (combine c c)}; <br />
putStrLn "¡Tanto tiempo!" };<br />
</haskell><br />
<br />
De vuelta al ejercicio - ¿ves como hacemos código desde la nada? Trata de imaginar que hará este código, después ejecútalo y compruébalo por ti mismo.<br />
<br />
¿Entiendas por qué “¡Hola!” y “¡Adiós!” no se imprimen?<br />
<br />
----<br />
<br />
Examinemos nuestra función “main” más de cerca:<br />
<br />
Prelude> :load cd-fit.hs<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :type main<br />
main :: IO ()<br />
*Main> <br />
<br />
Vemos que “main” es en realidad una acción IO que no devuelve nada cuando la evaluamos. Cuando combinamos acciones con “do”, el tipo del resultado será el tipo de la última acción, y “putStrLn algo” tiene tipo “IO ()”:<br />
<br />
*Main> :type putStrLn "¡Hola mundo!"<br />
putStrLn "¡Hola mundo!" :: IO ()<br />
*Main> <br />
<br />
Ah, por cierto: ¿te has dado cuenta que hemos compilado nuestro primer programa de Haskell para examinar “main”? :)<br />
<br />
celebrémoslo poniéndolo bajo control de versión: ejecuta “darcs add cd-fit.hs” y “darcs record”, responder “y” a todas las preguntas y dale un comentario al añadido “Esqueleto de cd-fit.hs”<br />
<br />
Vamos a probar a ejecutarlo:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: tengo entrada foo<br />
<br />
----<br />
<br />
'''Ejercicios''':<br />
* Trata de escribir un programa que coja tu nombre de stdin y te felicite (palabras clave: getLine, putStrLn);<br />
* Trata de escribir un programa que pregunte por tu nombre, lo lea, te felicite, pregunte por tu color favotiro, y lo devuelva (palabras clave: getLine, putStrLn).<br />
<br />
== Capítulo 2: procesando la entrada ==<br />
<br />
Bien, ahora que tenemos un entendimiento cabal de los poderes de ES en<br />
Haskell (y estamos deslumbrados por ellos, espero), nos olvidemos un<br />
poco de ES y hagamos algún trabajo útil.<br />
<br />
Como tu recordarás, nos habíamos propuesto poner datos tomados de<br />
varios directorios en tan pocos discos CD-Rs como sea<br />
posible. Asumimos que "du -sb" calculará el tamaño de los directorios<br />
de entrada y nos dará como salida algo como lo siguiente:<br />
<br />
65572 /home/adept/photos/raw-to-burn/dir1<br />
68268 /home/adept/photos/raw-to-burn/dir2<br />
53372 /home/adept/photos/raw-to-burn/dir3<br />
713124 /home/adept/photos/raw-to-burn/dir4<br />
437952 /home/adept/photos/raw-to-burn/dir5<br />
<br />
Nuestra siguiente tarea es procesar esa entrada y convertirla en<br />
alguna representación interna más cómoda.<br />
<br />
Para ello usaremos la poderosa librería de '''combinadores de<br />
parsers''' llamada "[[Parsec]]", que está presente en la mayoría de<br />
las implementaciones de Haskell.<br />
<br />
Como muchas de las facilidades para ES que hemos visto en el capítulo<br />
anterior, esta libreria provee un conjunto de parsers básicos y medios de <br />
combinarlos para obtener construcciones de parseo más complejas.<br />
<br />
A diferencia de otras herramientas en esta área (lex/yacc o JavaCC,<br />
para nombrar algunas), los parsers de [[Parsec]] no requieren una<br />
etapa de prepocesamiento previo. Dado que Haskell podeoms devolver<br />
funciones como resultado de funciones y de esta manera construir<br />
funciones a partir de "mero aire", no hay necesidad de una sintáxis<br />
separada para la descripción de parsers. Pero ya hicimos suficiente<br />
propaganda, hagamos algún parseo:<br />
<br />
<haskell><br />
-- Tomado de 'cd-fit-2-1.hs'<br />
import Text.ParserCombinators.Parsec<br />
<br />
-- parseInput parsea la entrada de "du -sb", que consiste de muchas líneas,<br />
-- cada una de ellas describe un solo directorio<br />
parseInput = <br />
do dirs <- many dirAndSize<br />
eof<br />
return dirs<br />
<br />
-- El tipo de dato Dir tiene información sobre un solo directorio:<br />
-- su tamaño y su nombre<br />
data Dir = Dir Int String deriving Show<br />
<br />
-- `dirAndSize` parsea la información de un solo directorio, que es:<br />
-- un tamaño en bytes (número), algunos espacios, y luego el nombre del<br />
-- directorio que llega hasta el fin de la línea<br />
dirAndSize = <br />
do size <- many1 digit<br />
spaces<br />
dir_name <- anyChar `manyTill` newline<br />
return (Dir (read size) dir_name)<br />
</haskell><br />
<br />
Simplemente agrega esas líneas al inicio de "cd-fit.hs". Aquí vemos muchas<br />
cosas nuevas, y muchas que ya conocíamos.<br />
<br />
Primero que nada, notemos la conocida construcción "do", que, como<br />
sabemos, se usa para combinar acciones de ES para producir nuevas<br />
acciones de ES. Aquí la usamos para combinar acciones de "parseo" en<br />
nuevas acciones de "parseo". Significa eso que "parseo" implica "hacer<br />
ES"? Absolutamente no. Es decir, tengo que admitir que te mentí - "do"<br />
no sólo se usa para combinar acciones de ES. "do" se usa para combinar<br />
cualquier tipo de las así llamadas ''acciones monádicas'' o ''valores<br />
monádicos''.<br />
<br />
Piensa en las [[monad|mónadas]] como un "[[:Category:Idioms|patrón de<br />
diseño]]" en el mundo funcional. Las [[monad|mónadas]] son una forma<br />
de ocultar al usuario (programador) toda la maquinaria necesaria para <br />
que operen funcionalidades complejas.<br />
<br />
Como habrás oido, Haskell no tiene ninguna noción de "assignación",<br />
"estado mutable" ni "variables", y es un "lenguaje funcional puro",<br />
que significa que toda función invocada con los mismos parámetros<br />
devolverá exactamente los mismos resultados. A la vez, "hacer ES"<br />
requiere acarrear descriptores de ficheros y sus estados y lidiar<br />
con errores de ES. El "parseo" requiere llevar registro de la posición<br />
en la entrada y lidiar con errores de parseo.<br />
<br />
En ambos casos Hombres Sabios que Escribieron Librerías tomaron las<br />
precauciones por nosotros y nos ocultaron toda la complejidad,<br />
exponiendo la<br />
[http://es.wikipedia.org/wiki/Application_programming_interface API]<br />
de sus librerías (ES y parseo) en la forma de "acciones monádicas",<br />
que nosotros podemos combinar libremente como nos parezca.<br />
<br />
Piensa en la programación con mónadas como hacer un remodelamiento con<br />
ayuda de un grupo de profesionales de remodelamiento. Tu describes<br />
secuencias de acciones en el papel (eso somos nosotros escribiendo con<br />
la notación "do"), y después, cuando es necesario, esa secuencia será<br />
evaluada por los profesionales ("en la mónada") lo que te dará el<br />
resultado final, ocultandote toda la complejidad subyacente (cómo<br />
preparar la pintuea, qué clavos elegir, etc).<br />
<br />
Usemos el entorno interactivo de Haskell para descifrar todas las <br />
instrucciones que hemos escritos para la librería de parseo. Como<br />
es usual, iremos de arriba hacia abajo:<br />
<br />
*Main> :reload<br />
Ok, modules loaded: Main.<br />
*Main> :t parseInput<br />
parseInput :: GenParser Char st [Dir]<br />
*Main> :t dirAndSize<br />
dirAndSize :: GenParser Char st Dir<br />
*Main> <br />
<br />
<br />
Asumiendo (bueno, confía en mi palabra) que "GenParser Char st" es<br />
nuestra mónada de parseo, podríamos ver que "parseInput", cuando sea<br />
evaluada, producirá una lista de "Dir", y que "dirAndSize", cuando sea<br />
evaluada, producirá "Dir". Asumiendo que "Dir" representa de alguna <br />
forma la iformación sobre un solo directorio, es casi lo que queríamos,<br />
o no?<br />
<br />
Veamos que significa un "Dir". Nosotros hemos definido el<br />
''[[type|tipo]] de datos'' Dir como un registro, que contiene un Int y<br />
un String:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
data Dir = Dir Int String deriving Show<br />
</haskell><br />
<br />
Para construir esos registros, debemos usar el ''[[constructor]] de<br />
datos'' Dir:<br />
<br />
*Main> :t Dir 1 "foo"<br />
Dir 1 "foo" :: Dir<br />
<br />
Para evitar la confusión para los novatos, podriamos haber escrito:<br />
<br />
<haskell><br />
data Dir = D Int String deriving Show<br />
</haskell><br />
<br />
, que define el ''[[type|tipo]] de datos'' "Dir" con el<br />
''[[constructor]] de datos'' "D". Sin embargo, tradicionalmente el<br />
nombre del [[type|tipo]] de datos y de su [[constructor]] son el mismo.<br />
<br />
La cláusula "[[deriving]] Show" le ordena al compilador hacer "tras<br />
bambalinas" todo el código necesario para que este ''tipo de datos''<br />
cumpla con la interfaz de la ''[[class|clase]] de tipo''<br />
Show. Explicaremos ''[[class|clases]] de tipo'' más adelante, por<br />
ahora digamos que esto nos permitirá "imprimir" instancias de "Dir".<br />
<br />
'''Ejercicios:'''<br />
* examina los tipos de "digit", "anyChar", "many", "many1" y "manyTill" para ver como són usados para construir parser complejos a partir de parsers simples.<br />
<br />
* compara los tipos de "manyTill", "manyTill anyChar" y "manyTill anyChar newline". Nota que "anyChar `manyTill` newline" es simplemente azucar sintácticto para el anterior. Nota que cuando no le aplicamos todos los argumentos necesarios a una función, entonces no obtenemos un valor, sino una nueva función, esto se llama ''aplicación parcial''.<br />
Bien, hasta aquí combinamos varias acciones primitivas de "parseo"<br />
para obtener nosotros un parser para la salida de "du -sb". Ahora, cómo podemos<br />
parsear algo? La librería [[Parsec]] nos brinda la función "parse":<br />
<br />
*Main> :t parse<br />
parse :: GenParser tok () a<br />
-> SourceName<br />
-> [tok]<br />
-> Either ParseError a<br />
*Main> :t parse parseInput<br />
parse parseInput :: SourceName -> [Char] -> Either ParseError [Dir]<br />
*Main> <br />
<br />
Al principio el [[type|tipo]] puede parecer un poco críptico, pero una<br />
vez que aplicamos el parser que nosotros hicimos, el compilador tiene más<br />
información y nos muestra un [[type|tipo]] más particular.<br />
<br />
Detente aquí y considera lo siguiente por un momento: el compilador se<br />
dió cuenta del tipo sin que nosotros hayamos hecho una sola anotación<br />
de tipos! Imagínate si un compilador de Java dedujera los tipos por<br />
nosotros, y no tuvieramos que especificar los tipos de los argumentos<br />
y de los valores de retorno nunca.<br />
<br />
Ahora volvamos al código. Podemos observar que "parser" es una<br />
función, que cuando recibe un parser, un nombre de un fichero o un<br />
canal (p.e. "stdin") y datos de entrada (String, que es una lista de<br />
"Char"s, que se escribe "[Char]"), producirá o bien un error de "parseo" o<br />
una lista de "Dir".<br />
<br />
El tipo de datos "Either" es un ejemplo de un tipo de datos cuyo<br />
constructor tiene un nombre diferente del nombre del tipo de datos. De<br />
hecho, "Either" tiene dos constructores:<br />
<br />
<haskell><br />
data either a b = Left a | Right b<br />
</haskell><br />
<br />
Para entender mejor qué significa, considera el siguiente ejemplo:<br />
<br />
*Main> :t Left 'a'<br />
Left 'a' :: Either Char b<br />
*Main> :t Right "aaa"<br />
Right "aaa" :: Either a [Char]<br />
*Main> <br />
<br />
Puedes ver que "Either" es una ''unión disjunta'' (bastante parecida a<br />
la "union" en C/C++), que puede tener un valor de uno de los dos tipos<br />
de datos. Sin embargo, a diferencia de la "union" en C/C++, si<br />
tuvieramos un valor de tipo "Either Int Char" podríamos decir<br />
inmediatamente si es un Int o un Char - mirando el constructor usado<br />
para producir el valor. Estos tipo de datos se llaman "uniones<br />
disjuntas" y son una [[:Category:Idioms|herramienta poderosa]] de la<br />
caja de herramientas de Haskell.<br />
<br />
¿Has notado que le hemos dado a "parse" un parser que es un valor<br />
monádico, pero no hemos recibido un nuevo valor monádico, sino un<br />
resultado de "parseo"? Esto es así porque "parse" es un evaludador<br />
para la mónada "Parser", así como el runtime de [[GHC]] o el de<br />
[[Hugs]] es un evaluador para la mónada de E/S. La función "parser"<br />
implementa toda la maquinaria monádica: tiene un registro de los errores <br />
y posiciones en la entrada, implementa backtracking y lookahead, etc.<br />
<br />
<br />
Extendamos nuestr función "main" para que use "parse", parseé realmente<br />
la entrada y nos muestra las estructuras parseadas:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: got input " ++ input)<br />
let dirs = case parse parseInput "stdin" input of<br />
Left err -> error $ "Input:\n" ++ show input ++ <br />
"\nError:\n" ++ show err<br />
Right result -> result<br />
putStrLn "DEBUG: parsed:"; print dirs<br />
</haskell><br />
<br />
'''Ejercicios:'''<br />
<br />
* Para entender mejor el siguiente pedazo de cógigo, examina (con ghci<br />
o hugs) las diferencias entre 'drop 1 ( drop 1 ( drop 1 ( drop 1 ( drop 1 "foobar" ))))' y 'drop 1 $ drop 1 $ drop 1 $ drop 1 $ drop 1 "foobar"'. Examina el tipo de ($).<br />
<br />
* Intenta hacer 'putStrLn "aaa"' y 'print "aaa"' y mira la la diferencia, examina sus tipos.<br />
<br />
* Intenta 'print (Dir 1 "foo")' y 'putStrLn (Dir 1 "foo")'. Examina los tipos de print y de putStrLn para entender el comportamiento en cada caso.<br />
<br />
Intentemos ejecutar lo que tenemos hasta aquí:<br />
<br />
$ du -sb * | runhaskell ./cd-fit.hs<br />
<br />
DEBUG: got input 22325 Article.txt<br />
18928 Article.txt~<br />
1706 cd-fit.hs<br />
964 cd-fit.hs~<br />
61609 _darcs<br />
<br />
DEBUG: parsed:<br />
[Dir 22325 "Article.txt",Dir 18928 "Article.txt~",Dir 1706 "cd-fit.hs",Dir 964 "cd-fit.hs~",Dir 61609 "_darcs"]<br />
<br />
Parece que está haciendo exactamente lo planeado. Ahora probemos con alguna<br />
entrada errónea:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: got input foo<br />
<br />
DEBUG: parsed:<br />
*** Exception: Input:<br />
"foo\n"<br />
Error:<br />
"stdin" (line 1, column 1):<br />
unexpected "f"<br />
expecting digit or end of input<br />
<br />
Parece que se comporta bien.<br />
<br />
Si tú has seguido el consejo de poner tu código bajo control de versiones,<br />
tú puedes usar "darcs whatsnew" o "darc diff -u" para examinar los<br />
cambios respecto a la versión anterior. Usando "darcs record" creas una<br />
nueva versión con los cambios. Como ejercicio, primero registra los<br />
cambios que no están dentro de la función "main" y luego<br />
registra los que están en "main". Usa "darcs changes" para examinar<br />
una lista de los cambios registrados hasta ahora.<br />
<br />
== Capítulo 3: Empacando la mochila y controlándola con clase también (¡y no te olvides tu toalla!) ==<br />
<br />
Ya tuvimos bastante preámbulo. Hagamos algunos CDs.<br />
<br />
Como debes haberte dado cuenta, nuestro problema es clásico. Se llama<br />
el "problema de la mochila"<br />
([http://www.google.com/search?hl=es&q=problema+mochila búscalo en google], si no lo conoces. Hay más de un millón de resultados.)<br />
<br />
Empecemos con la solución voraz, pero primero modifiquemos levemente<br />
nuestro tipo de datos "Dir" para facilitar la extracción de sus<br />
componentes:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
----<br />
'''Ejercicio:''' examina los tipos de "Dir", "dir_size" y "dir_name".<br />
----<br />
<br />
A partir de ahora, podríamos usar "dir_size d" para obtener un tamaño<br />
de directorio y "dir_name d" para obtener su nombre, si "d" es de tipo<br />
"Dir".<br />
<br />
El algoritmo voraz ordena los directorios de mayor a menor e intenta <br />
ponerlos en el CD uno a uno, hasta que no haya más espacio. Vamos a <br />
tener que llevar registro de los directorios que agregamos al CD, para<br />
ello agreguemos otro tipo de datos y programemos este simple algoritmo de<br />
empaque:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
import Data.List (sortBy)<br />
<br />
-- DirPack holds a set of directories which are to be stored on single CD.<br />
-- 'pack_size' could be calculated, but we will store it separately to reduce<br />
-- amount of calculation<br />
data DirPack = DirPack {pack_size::Int, dirs::[Dir]} deriving Show<br />
<br />
-- For simplicity, let's assume that we deal with standard 700 Mb CDs for now<br />
media_size = 700*1024*1024<br />
<br />
-- Greedy packer tries to add directories one by one to initially empty 'DirPack'<br />
greedy_pack dirs = foldl maybe_add_dir (DirPack 0 []) $ sortBy cmpSize dirs<br />
where<br />
cmpSize d1 d2 = compare (dir_size d1) (dir_size d2)<br />
<br />
-- Helper function, which only adds directory "d" to the pack "p" when new<br />
-- total size does not exceed media_size<br />
maybe_add_dir p d =<br />
let new_size = pack_size p + dir_size d<br />
new_dirs = d:(dirs p)<br />
in if new_size > media_size then p else DirPack new_size new_dirs<br />
</haskell><br />
<br />
----<br />
Yo resaltaré las áreas que podrías explorar vos mismo (usando otros<br />
tutoriales bonitos, especialmente te recomiento "Yet Another Haskell<br />
Tutorial" ("Otro tutorial para Haskell") por Hal Daume):<br />
* Elegimos importar una sola función "sortBy" de un módulo [[Data.List]], no el módulo entero.<br />
<br />
* En vez de programar caso por caso la definición recursiva de "greedy_pack", usamos un enfoque de alto orden, y elegimos "foldl" como una forma para recorrido de listas. Examina su tipo. Otras funciones útiles de esa categoría son "map", "foldr", "scanl" y "scanr". Búscalas!<br />
<br />
* Para ordenar una lista de "Dir" por tamaño usamos una función particular de orden con el ordenamiento parametrizable - "sortBy". Este tipo de funciones donde uno provee un modificador particular para una función de librería genérica es bastante común: busca "deleteBy", "deleteFirstBy", "groupBy", "insertBy", "intersectBy", "maximumBy", "minimumBy", "sortBy", "unionBy".<br />
<br />
* Para programar la compleja función "maybe_add_dir" hemos introducido '''definiciones locales''' con la cláusula "let"; estas definiciones pueden ser usadas nuevamente en el cuerpo de la función. Usamos una cláusula "where" en la función "greedy_pack" para lo mismo. Lee acerca de las cláusulas "let" y "where" y sobre las diferencias entre ellas.<br />
<br />
* Nota que para poder construir un nuevo valor de tipo "DirPack" (en la función "maybe_add_dir") no hemos usado las funciones auxiliares "pack_size" y "dirs".<br />
----<br />
<br />
Para poder utilizar nuestro empacador voraz debemos invocarlo desde nuestra función<br />
"main", así que agreguemos algunas líneas:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
main = do ...<br />
-- compute solution and print it<br />
putStrLn "Solution:" ; print (greedy_pack dirs)<br />
</haskell><br />
<br />
Verifica la integridad de las definiciones (re)cargando el código en ghci. ¿Compila? Claro que sí :) Ahora, haz "darcs record" y agrega algún mensaje razonable para documentar los cambios.<br />
<br />
Es el momento de probar nuestra creación. Podemos hacerlo ejecutando directamente de la siguiente forma: <br />
<br />
$ du -sb ~/DOWNLOADS/* | runhaskell ./cd-fit.hs<br />
<br />
Esto demostrará que nuestro código parece funcionar. Por lo menos esta vez. ¿Qué tal estaría<br />
establecer con algún grado de certeza que nuestro código funciona correctamente, parcial y completamente, y hacerlo de una forma re-usable? ¿En otras palabras, qué tal si escribimos<br />
algunas pruebas?<br />
<br />
Los programadores de Java, acostumbrados a JUnit, probablemente pensaron en pantallas y pantallas de plantillas e invocaciones de métodos escritas a mano. No temáis, no haremos nada tan tonto :)<br />
<br />
Presentando '''[[QuickCheck]]'''.<br />
<br />
[[QuickCheck]] es una herramienta que hace pruebas automatizadas de tus funciones utilizando datos de entrada (semi) aleatorios. Siguiendo la idea de "100b de ejemplos de código valen lo que 1k de elogios" mostremos el código para verificar la siguiente "propiedad": un intento de empacar directorios devueltos por "greedy_pack" debe regresar "DirPack" de exactamente el mismo paquete.<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
import Test.QuickCheck<br />
import Control.Monad (liftM2, replicateM)<br />
<br />
-- We must teach QuickCheck how to generate arbitrary "Dir"s<br />
instance Arbitrary Dir where<br />
-- Let's just skip "coarbitrary" for now, ok? <br />
-- I promise, we will get back to it later :)<br />
coarbitrary = undefined<br />
-- We generate arbitrary "Dir" by generating random size and random name<br />
-- and stuffing them inside "Dir"<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM (n*10+1) (elements "fubar/")<br />
<br />
-- For convenience and by tradition, all QuickCheck tests begin with prefix "prop_".<br />
-- Assume that "ds" will be a random list of "Dir"s and code your test.<br />
prop_greedy_pack_is_fixpoint ds =<br />
let pack = greedy_pack ds <br />
in pack_size pack == pack_size (greedy_pack (dirs pack))<br />
</haskell><br />
<br />
ejecutemos la prueba, tras lo cual explicaré cómo funciona:<br />
<br />
Prelude> :r<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> quickCheck prop_greedy_pack_is_fixpoint<br />
[numbers spinning]<br />
OK, passed 100 tests.<br />
*Main> <br />
<br />
Hemos visto que nuestro "greedy_pack" corre en 100 listas completamente (bueno, casi completamente) aleatorias de "Dir"s, y parece que esa propiedad efectivamente se cumple.<br />
<br />
Disequemos el código. La parte más intrigante es "instance Arbitrary Dir where", que declara que "Dir" es una instancia ('''[[instance]]''') de '''type[[class]]''') "Arbitrary". Whoa, ¡es un montón de palabras desconocidas! :) Veamos con más calma.<br />
<br />
¿Qué es una clase de tipos ('''type[[class]]''')? Una clase de tipos es la forma de Haskell de lidiar con la siguiente situación: supón que estás escribiendo una biblioteca de funciones útiles y no sabes por anticipado exactamente cómo van a ser utilizadas, así que quieres hacerlas genéricas. Por un lado no quieres restringir a tus usuarios a cierto tipo (e.g. String). Por otro lado, quieres que se cumpla que los argumentos para tu función deban satisfacer un cierto conjunto de restricciones. Aquí es donde '''typeclass''' es útil.<br />
<br />
Piensa en typeclass como en un '''contrato''' (o "interface", en términos Java) que el tipo debe cumplir para ser aceptado como argumento a ciertas funciones.<br />
<br />
Examinemos la clase de tipos "Arbitrary":<br />
<br />
*Main> :i Arbitrary<br />
class Arbitrary a where<br />
arbitrary :: Gen a<br />
coarbitrary :: a -> Gen b -> Gen b<br />
-- Imported from Test.QuickCheck<br />
instance Arbitrary Dir<br />
-- Defined at ./cd-fit.hs:61:0<br />
instance Arbitrary Bool -- Imported from Test.QuickCheck<br />
instance Arbitrary Double -- Imported from Test.QuickCheck<br />
instance Arbitrary Float -- Imported from Test.QuickCheck<br />
instance Arbitrary Int -- Imported from Test.QuickCheck<br />
instance Arbitrary Integer -- Imported from Test.QuickCheck<br />
-- rest skipped --<br />
<br />
Se puede leer así: "Cualquier [[type|tipo]] (llamémosle 'a') puede ser miembro de la [[class|clase]] Arbitrary siempre que le definamos dos funciones: "arbitrary" y "coarbitrary", con las definiciones de tipos mostradas. Para los tipos Dir, Bool, Double, Float, Int e Integer exiten tales definiciones, por lo tanto, todos esos tipos son instancia de la clase Arbitrary".<br />
<br />
¡Ahora, si escribes una función que opere en sus argumentos solamente por medio de "arbitrary" y "coarbitrary", puedes estar seguro de que esa función funcionará en cualquier tipo que sea instancia de "Arbitrary"!<br />
<br />
Vamos a decirlo otra vez. Alguien (tal vez tú mismo) escribe código (API o biblioteca) que requiere que los valores de entrada implementen ciertas "interfaces" que están descritas en términos de funciones. Una vez que muestras cómo implementa tu tipo esta "interfaz", eres libre de emplear el API o las bibliotecas.<br />
<br />
Considera la función "sort" ("ordenar") de la biblioteca estándar:<br />
<br />
*Main> :t Data.List.sort<br />
Data.List.sort :: (Ord a) => [a] -> [a]<br />
<br />
Vemos que ordena listas de valores cualesquiera que sean instancia de la clase de tipos "Ord". Examinemos esa clase:<br />
<br />
*Main> :i Ord<br />
class Eq a => Ord a where<br />
compare :: a -> a -> Ordering<br />
(<) :: a -> a -> Bool<br />
(>=) :: a -> a -> Bool<br />
(>) :: a -> a -> Bool<br />
(<=) :: a -> a -> Bool<br />
max :: a -> a -> a<br />
min :: a -> a -> a<br />
-- skip<br />
instance Ord Double -- Imported from GHC.Float<br />
instance Ord Float -- Imported from GHC.Float<br />
instance Ord Bool -- Imported from GHC.Base<br />
instance Ord Char -- Imported from GHC.Base<br />
instance Ord Integer -- Imported from GHC.Num<br />
instance Ord Int -- Imported from GHC.Base<br />
-- skip<br />
*Main> <br />
<br />
Vemos un par de cosas interesantes: primero, hay un requisito adicional: para que sea instancia de "Ord", el tipo debe primero ser una instancia de la clase de tipos "Eq". Luego, vemos que hay una gran cantidad de funciones que deben ser definidas para ser una instancia de "Ord". Un momento, ¿no es algo tonto tener que definir (<) y (>) cuando se puede expresar uno en términos del otro?<br />
<br />
¡Claro que sí! Usualmente, las clases de tipo contienen varias implementaciones por "default" para sus funciones, cuando es posible expresarlas una a través de otra (como es el caso de "Ord"). En este caso es posible proveer solamente una definición mínima (que, en el caso de "Ord", consiste en cualquier función de comparación) y las demás serán automáticamente derivadas. Si provees menos funciones de las que se requieren para una implementación mínima, el compilador/intérprete lo indicará y explicará qué funciones faltan por definir.<br />
<br />
Una vez más, vemos que muchos de los [[type|tipo]]s son ya instancia de la clase de tipos Ord, y por eso es posible ordenarlos.<br />
<br />
Veamos de nuevo la definición de "Dir":<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
¿Notas la presencia de la cláusula ''[[deriving]]''? Esto le dice al compilador que derive automáticamente código para hacer que "Dir" sea una instancia de la clase de tipos Show. El compilador conoce unas cuantas clases de tipos estándar (Eq, Ord, Show, Enum, Bound, Typeable para mencionar algunas) y sabe cómo convertir un tipo en una instancia "suficientemente buena" de cualquiera de ellas. Si quieres derivar instancias de más de una clase de tipos, dilo de esta forma: "deriving (Eq,Ord,Show)". Voila! Ahora podemos comparar, ordenar e imprimir datos de ese tipo.<br />
<br />
Un comentario para programadores Java: imaginen un compilador java que derive automáticamente código para "implements Storable"...<br />
<br />
Un comentario para programadores C++: imaginen que los constructores de copia son escritos por el compilador...<br />
<br />
----<br />
'''Exercises:'''<br />
* Examine typeclasses Eq and Show<br />
* Examine types of (==) and "print"<br />
* Try to make "Dir" instance of "Eq"<br />
----<br />
<br />
Ok, de regreso a las pruebas. Así que, ¿qué hemos tenido que hacer para que "Dir" sea instancia de "Arbitrary"? La definición mínima consiste en "arbitrary". Examinémosla de cerca:<br />
<br />
<br />
*Main> :t arbitrary<br />
arbitrary :: (Arbitrary a) => Gen a<br />
<br />
¿Notas ese "Gen a"? ¿Te recuerda algo? ¡Correcto! Piensa en "IO a" y "Parser a", que ya hemos visto. Este es otro ejemplo más de función que regresa acciones, que cuede ser utilizada dentro de la notación "do". (Puedes preguntarte, ¿no sería útil generalizar ese concepto tan conveniente de acciones y "do"? ¡Por supuesto! Ya está hecho, el concepto se llama "[[Monad]]" y lo mencionaremos en el capítulo 400 :) )<br />
<br />
Como aquí 'a' es una [[type variable|variable de tipo]] que es una instancia de "Arbitrary", podemos sustituirla con "Dir". Así que, ¿cómo creamos y regresamos una acción de tipo "Gen Dir"?<br />
<br />
Veamos el código:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM (n*10+1) (elements "fubar/")<br />
</haskell><br />
<br />
Hemos empleado las funciones de biblioteca "choose" y "elements" para construir "gen_size :: Gen Int" y "gen_name :: Gen String" (ejercicio: no me creas. Busca una forma de verificar los tipos de "gen_name" y "gen_size"). Como "Int" y "String" son los componentes de "Dir", seguramente debemos poder usar "Gen Int" y "Gen String" para construir "Gen Dir". ¿Pero donde está el bloque "do" para esto? No hay ninguno; solamente hay una sola llamada a "liftM2".<br />
<br />
Examinémoslo:<br />
<br />
*Main> :t liftM2<br />
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r<br />
<br />
¿Espanta, no? Démosle al verificador de tipos un poco de contexto:<br />
<br />
*Main> :t liftM2 Dir<br />
liftM2 Dir :: (Monad m) => m Int -> m String -> m Dir<br />
<br />
Como ya has oído que "Gen" es una "Monad", puedes sustituir "Gen" en lugar de "m" aquí, obteniendo "liftM2 Dir :: (Monad Gen) => Gen Int -> Gen String -><br />
Gen Dir". ¡Exactamente lo que queríamos!<br />
<br />
Considera que "liftM2" es un "tópico avanzado" de este capítulo (lo veremos después) y por ahora nota que:<br />
<br />
* "2" es un número de argumentos para el constructor de datos "Dir" y hemos utilizado "liftM2" para construir "Gen Dir" a partir de "Dir"<br />
* También hay "liftM", "liftM3", "liftM4", "liftM5"<br />
* "liftM2" está definido como "liftM2 f a1 a2 = do x<-a1; y<-a2; return (f x y)"<br />
<br />
Esperemos que todo esto tenga sentido tras leerlo por tercera vez ;)<br />
<br />
Ah, y de paso - ¡no olvides hacer "darcs record" para guardar tus cambios!<br />
<br />
== Capítulo 4: Empacando DE VERDAD la mochila, ahora sí == <br />
<br />
En este capítulo vamos a escribir otro método de empaque no tan trivial, comparar la eficiencia de los métodos de empaque y, de paso, aprender cosas nuevas sobre depuración y medición de desempeño de programas en Haskell.<br />
<br />
Puede no ser inmediatamente obvio si nuestro algoritmo de empaque es eficiente, y, si lo es, ¿en qué forma en particular? ¿Cuánto tarda en completar, cuanta memoria consume, el resultado obtenido es de suficiente calidad? ¿Hay otros algoritmos, y cómo se comparan uno al otro?<br />
<br />
Escribamos otra solución al problema de empacar la mochila, llamado el "método de programación dinámico", y pongamos ambas variantes a prueba.<br />
<br />
Esta vez no separaré el listado para explicarlo parte por parte. En lugar de ello he incluído comentarios en el código:<br />
<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-1.hs'<br />
----------------------------------------------------------------------------------<br />
-- Solución por programación dinámica al problema de empacar <br />
-- una mochila (o más bien un disco)<br />
--<br />
-- Sea `bestDisk x' el disco "más compactamente empacado" de <br />
-- tamaño total no mayor a `x'.<br />
precomputeDisksFor :: [Dir] -> [DirPack]<br />
precomputeDisksFor dirs = <br />
-- Calculando `bestDisk' para todos los posibles tamaños de un<br />
-- disco podemos obtener una solución para un caso en particular<br />
-- simplemente buscando en la lista de soluciones :)<br />
let precomp = map bestDisk [0..] <br />
<br />
-- ¿Cómo calcular `bestDisk'? Optemos por una definición recursiva:<br />
-- Caso base de la recursión: el disco de tamaño 0 <br />
-- mejor empacado es el vacío<br />
bestDisk 0 = DirPack 0 []<br />
-- Paso recursivo: para el tamaño `limit', mayor que 0, el disco mejor<br />
-- empacado se calcula de la siguiente forma:<br />
bestDisk limit = <br />
-- 1. Toma todos los directorios no vacíos que pudieran posiblemente caber<br />
-- en ese disco por sí mismos. Considéralos uno por uno. Que el tamaño de<br />
-- un directorio en particular sea `dir_size d'. Agreguémoslo al disco mejor <br />
-- empacado de tamaño <= (limit - dir_size d), produciendo el disco de <br />
-- tamaño <= limit. Hagamos esto para todos los directorios "candidato" que<br />
-- aún no están en nuestro disco:<br />
case [ DirPack (dir_size d + s) (d:ds) | d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(limit - dir_size d)<br />
, d `notElem` ds<br />
] of<br />
-- O no podemos agregar ningún directorio (probablemente porque todos<br />
-- son demasiado grandes); bueno, informemos que el disco se debe <br />
-- quedar vacío:<br />
[] -> DirPack 0 []<br />
-- O generemos otro empaque diferente. Seleccionemos el mejor de todos:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
in precomp<br />
<br />
-- Cuando precalculamos discos de todos los posibles tamaños para el conjunto de<br />
-- directorios dado, la solución a un problema en particular es simple: sólo toma la<br />
-- solución para el 'media_size' requerido, y eso es todo.<br />
<br />
dynamic_pack dirs = (precomputeDisksFor dirs) !! media_size<br />
</haskell><br />
<br />
Nota que se usó casi la misma cantidad de texto para describir el algoritmo y para implementarlo. ¿Bien, no?<br />
<br />
----<br />
<br />
'''Exercises:'''<br />
* Make all necessary amendments to the previously written code to make this example compile. Hints: browse modules Data.List and Data.Ix for functions that are "missing" - maybe you will find them there (use ":browse Module.Name" at ghci prompt). Have you had to define some new instances of some classes? How did you do that?<br />
* <tt>[ other_function local_binding | x <- some_list, x > 0, let local_binding = some_function x ]</tt> is called a "list comprehension". This is another example of "syntactic sugar", which could lead to nicely readable code, but, when abused, could lead to syntactic caries :) Do you understand what does this sample do: <tt>let solve x = [ y | x <- [0..], y<-[0..], y == x * x ]</tt>? Could write (with help of decent tutorial) write de-sugared version of this? (Yes, I know that finding a square root does not require list traversals, but for the sake of self-education try and do it)<br />
* Notice that in order to code quite complex implementation of <tt>precomputeDisksFor</tt> we split it up in several smaller pieces and put them as a '''local bindings''' inside '''let''' clause.<br />
* Notice that we use '''pattern matching''' to both define <tt>bestKnap</tt> on case-by-case basis and to "peer into" ('''de-construct''') <tt>DirPack</tt> in the <tt>let (DirPack s ds)=precomp!!(limit - dir_size d)</tt> line<br />
* Notice how we use function composition to compose complex condition to filter the list of dirs<br />
<br />
---- <br />
<br />
Antes de avanzar más, hagamos un pequeño cambio cosmético en nuestro código. Actualmente nuestra solución utiliza 'Int' para almacenar el tamaño del directorio. En Haskell, 'Int' es un entero dependiente de la plataforma, lo que impone ciertas limitaciones en los valores de este tipo. Intentar calcular valores de tipo 'Int' que excedan los límites resultará en un error de sobreflujo. Las bibliotecas estándar Haskell tienen la clase de tipos especial <hask>Bounded</hask>, que permite definir y examinar esos límites:<br />
<br />
Prelude> :i Bounded <br />
class Bounded a where<br />
minBound :: a<br />
maxBound :: a<br />
-- skip --<br />
instance Bounded Int -- Imported from GHC.Enum<br />
<br />
Vemos que 'Int' efectivamente tiene límites. Examinemos dichos límites:<br />
<br />
Prelude> minBound :: Int <br />
-2147483648<br />
Prelude> maxBound :: Int<br />
2147483647<br />
Prelude> <br />
<br />
Para los que entienden de C, diremos que en este caso el 'Int' es un "entero de 32 bit con signo", lo que significa que produciremos errores si intentamos operar en paquetes de directorio o directorios que sean mayores a 2 Gb.<br />
<br />
Afortunadamente para nosotros, Haskell tiene enteros de precisión arbitraria (limitados solamente por la cantidad de memoria disponible). El tipo apropiado se llama 'Integer':<br />
<br />
Prelude> (2^50) :: Int<br />
0 -- overflow<br />
Prelude> (2^50) :: Integer<br />
1125899906842624 -- no overflow<br />
Prelude><br />
<br />
Cambiemos las definiciones de 'Dir' y de 'DirPack' para permitir directorios de tamaños mayores:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
data Dir = Dir {dir_size::Integer, dir_name::String} deriving (Eq,Show)<br />
data DirPack = DirPack {pack_size::Integer, dirs::[Dir]} deriving Show<br />
</haskell><br />
<br />
Intenta compilar el código o cargarlo en ghci. Obtendrás los siguientes errores:<br />
<br />
cd-fit-4-2.hs:73:79:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the expression: limit - (dir_size d)<br />
In the second argument of `(!!)', namely `(limit - (dir_size d))'<br />
<br />
cd-fit-4-2.hs:89:47:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the second argument of `(!!)', namely `media_size'<br />
In the definition of `dynamic_pack':<br />
dynamic_pack dirs = (precomputeDisksFor dirs) !! media_size<br />
<br />
Parece que Haskell tiene algunos problemas usando 'Integer' con '(!!)'. Veamos por qué:<br />
<br />
Prelude> :t (!!)<br />
(!!) :: [a] -> Int -> a<br />
<br />
Parece que la definición de '(!!)' exige que el índice sea un 'Int', no un 'Integer'. Haskell nunca convierte un tipo en otro automáticamente - el programador debe solicitarlo de forma explícita:<br />
<br />
No voy a repetir la sección "Standard Haskell Classes" de<br />
[http://haskell.org/onlinereport/basic.html the Haskell Report] y explicar por qué los tipos de clases para varios tipos numéricos están organizados como están. Solamente diré que el tipos de clases estándar <hask>Num</hask> requiere que los tipos numéricos implementen el método <hask>fromInteger</hask>:<br />
<br />
Prelude> :i Num<br />
class (Eq a, Show a) => Num a where<br />
(+) :: a -> a -> a<br />
(*) :: a -> a -> a<br />
(-) :: a -> a -> a<br />
negate :: a -> a<br />
abs :: a -> a<br />
signum :: a -> a<br />
fromInteger :: Integer -> a<br />
-- Imported from GHC.Num<br />
instance Num Float -- Imported from GHC.Float<br />
instance Num Double -- Imported from GHC.Float<br />
instance Num Integer -- Imported from GHC.Num<br />
instance Num Int -- Imported from GHC.Num<br />
<br />
Vemos que <hask>Integer</hask> es miembro de la clase de tipos <hask>Num</hask>, y por lo tanto podemos utilizar <hask>fromInteger</hask> para hacer que desaparezcan los errores de tipo:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
-- snip<br />
case [ DirPack (dir_size d + s) (d:ds) | d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
] of<br />
-- snip<br />
dynamic_pack dirs = (precomputeDisksFor dirs)!!(fromInteger media_size)<br />
-- snip<br />
</haskell><br />
<br />
Los errores de tipo desaparecieron, pero el lector atento se dará cuenta de que cuando la expresión <hask>(limit - dir_size d)</hask> exceda los límites de <hask>Int</hask>, ocurrirá un sobreflujo, y no podremos acceder al elemento correcto en la lista. No te preocupes, resolveremos esto en un momento.<br />
<br />
Ahora, escribamos la prueba QuickCheck para esta función de la misma forma que la prueba para <tt>greedy_pack</tt>:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack ds <br />
in pack_size pack == pack_size (dynamic_pack (dirs pack))<br />
</haskell><br />
<br />
Ahora, intentemos ejecutar (¡NO ENTRAR EN PÁNICO y guarda primero lo que estés haciendo en otras aplicaciones!):<br />
<br />
*Main> quickCheck prop_dynamic_pack_is_fixpoint<br />
<br />
<br />
¿Tomaste en serio mi consejo, verdad? ¿Y tenías '''Ctrl-C''' listo, no? Lo más probable es que el intento de ejecutar la prueba haya causado que toda tu memoria haya sido saturada por el proceso <tt>ghci</tt>, que, si fuiste suficientemente rápido, pudiste interrumpir presionando '''Ctrl-C'''.<br />
<br />
¿Qué sucedió? ¿Quién se comió toda la memoria? ¿Cómo depuramos este problema? GHC puede medir el desempeño y decir donde se ocupó la memoria, pero no podemos hacerlo ahora - el reporte se produce después de que el programa finaliza, y el nuestro no parece querer finalizar sin antes consumir varios terabytes de memoria. Aún así, hay mucho terreno donde maniobrar.<br />
<br />
Veamos. Como llamamos a <tt>dynamic_pack</tt> y se comió toda la memoria, no lo hagamos de nuevo. En lugar de eso, veamos qué hace esa función y alterémosla un poco para modificar su comportamiento.<br />
<br />
Como ya sabemos que las listas aleatorias de "Dir"s generadas para nuestras pruebas QuickCheck son de tamaño mediano (después de todo, <tt>greedy_pack</tt> las mastica sin consumir demasiada memoria), el problema más probablemente no es el tamaño de la entrada. Sin embargo, <tt>dynamic_pack_is_fixpoint</tt> está construyendo internamente una lista enorme (via <tt>precomputeDisksFor</tt>). ¿Podría ser ese el problema?<br />
<br />
Activemos las estadísticas de medición de tiempo y memoria (":set +s" dentro de ghci) e intentemos espiar dentro de varios elementos de la lista devuelta por <tt>precomputeDisksFor</tt>:<br />
<br />
Prelude> :l cd-fit.hs<br />
Compiling Main ( cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :set +s<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 0<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.06 secs, 1277972 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.00 secs, 0 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.01 secs, 1519064 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 1000<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.03 secs, 1081808 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10000<br />
DirPack {pack_size = 0, dirs = []}<br />
(1.39 secs, 12714088 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100000<br />
Interrupted.<br />
<br />
¡Aha! Parece que aquí hay un problema, porque el cálculo de 100000 no finaliza en un tiempo "razonable". Y pensar que hemos tratado de calcular el elemento número <tt>700*1024*1024</tt>...<br />
<br />
Modifiquemos un poco el código, para permitir alterar el tamaño del disco:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-3.hs'<br />
dynamic_pack limit dirs = (precomputeDisksFor dirs)!!(fromInteger limit)<br />
<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack media_size ds <br />
in pack_size pack == pack_size (dynamic_pack media_size (dirs pack))<br />
<br />
prop_dynamic_pack_small_disk ds =<br />
let pack = dynamic_pack 50000 ds<br />
in pack_size pack == pack_size (dynamic_pack 50000 (dirs pack))<br />
<br />
-- rename "old" main to "moin"<br />
main = quickCheck prop_dynamic_pack_small_disk<br />
</haskell><br />
<br />
Compila una versión con soporte para medir el desempeño con <tt>ghc -O --make -prof -auto-all -o cd-fit cd-fit.hs</tt> y ejecútala así:<br />
<br />
$ ./cd-fit +RTS -p<br />
OK, passed 100 tests.<br />
<br />
Primero, notemos que nuestro código satisface al menos una propiedad simple. Bien. Ahora examinemos el reporte de desempeño. Mira en el archivo "cd-fig.prof", que ha sido generado en el directorio actual.<br />
<br />
Seguramente vas a ver algo parecido a esto:<br />
<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 2.18 secs (109 ticks @ 20 ms)<br />
total alloc = 721,433,008 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
precomputeDisksFor Main 88.1 99.8<br />
dynamic_pack Main 11.0 0.0<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
<br />
MAIN MAIN 1 0 0.0 0.0 100.0 100.0<br />
CAF Main 174 11 0.9 0.2 100.0 100.0<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 99.1 99.8<br />
dynamic_pack Main 182 200 11.0 0.0 99.1 99.8<br />
precomputeDisksFor Main 183 200 88.1 99.8 88.1 99.8<br />
main Main 180 1 0.0 0.0 0.0 0.0<br />
<br />
<br />
Examina la columna "individual %alloc". Como lo pensamos, toda la memoria ha sido ubicada dentro de <tt>precomputeDisksFor</tt>. Sin embargo, la cantidad de memoria ubicada (más de 700 Mb, de acuerdo a la línea "total alloc") parece ser demasiado para resolver nuestro problema simple. Investiguemos más profundo para averiguar en donde estamos desperdiciando.<br />
<br />
Examinemos el consumo de memoria más de cerca empleando "heap profiles". Ejecuta <tt>./cd-fit +RTS -hb</tt>. Eso produce "perfiles de memoria biográficos", que nos dicen cómo fueron utilizadas las varias partes de la memoria durante la ejecución del programa. El perfil ha sido almacenado en "cd-fit.hp". Es casi imposible de leer e interpretar tal como está; emplearemos "hp2ps cd-fit.hp" para producir una imagen en PostScript que vale más que mil palabras. Visualízala con "gv" o "ghostview" o "Adobe Acrobat" completo (no el "Reader"). (Esta y las siguientes imágenes '''no''' están incluídas aquí)<br />
<br />
Nota que la mayor parte de la gráfica está ocupada por la región marcada "VOID" (vacío). Eso significa que la memoria ubicada nunca fué usada. Nota que '''no''' hay áreas marcadas como "USE", "LAG o "DRAG". Parece que nuestro programa no usa '''casi nada''' de la memoria que ha reservado. ¡Un momento! ¿Cómo es posible? Tiene que estar usando algo cuando empaca en los discos imaginarios de 50000 bytes esos directorios generados al azar que miden de 10 a 1400 Mb... Oops. Es una enorme diferencia de tamaños. Debimos habernos dado cuenta antes, cuando estábamos midiendo <tt>precomputeDisksFor</tt>. Regresa y observa cómo es que todas las ejecuciones regresan exactamente el mismo resultado - el conjunto vacío de directorios.<br />
<br />
Nuestros directorios al azar son demasiado grandes, pero de todas formas el código consume tiempo y memoria intentando "empacarlos". Obviamente, <tt>precomputeDisksFor</tt> (que es responsable del 90% del consumo de tiempo y memoria) tiene algún error.<br />
<br />
Miremos más de cerca qué consume tanta memoria. Ejecuta <tt>./cd-fit +RTS -h -hbvoid</tt> y genera el PostScript para este perfil de memoria. Esto nos dará un informe detallado de toda la memoria cuya "biografía" muestra que ha sido "VOID" (no utilizada). Mi imagen (y me imagino que la tuya también) muestra que la memoria VOID consiste en pedazos etiquetados "precomputeDisksFor/pre...". Podemos asumir que la segunda palabra debe ser "precomp" (¿quieres saber por qué? Mira el código y trata de encontrar funciones con nombres que empiecen con "pre" que sean llamados desde dentro de <tt>precomputeDisksFor</tt>)<br />
<br />
Esto significa que la memoria ha sido ocupada por la lista generada dentro de "precomp". Los rumores dicen que las fugas de memoria en Haskell se producen por falta de flojera o por demasiada flojera. Parece que aquí tenemos muy poca flojera: estamos evaluando más elementos de la lista de los que realmente necesitamos y eso impide que sean liberados por el recolector de basura.<br />
<br />
Nota cómo buscamos elementos de "precomp" en esta porción de código:<br />
<br />
<haskell><br />
case [ DirPack (dir_size d + s) (d:ds) | d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
</haskell><br />
<br />
<br />
Está claro que la lista completa generada por "precomp" debe ser mantenida en memoria para hacer esas búsquedas, dado que no podemos estar seguros de si algún elemento ya no va a ser necesario y puede ser retirado de la memoria.<br />
<br />
Escribamos el código de nuevo para eliminar la lista:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-4.hs'<br />
-- Sea `bestDisk x' el disco "más compactamente empacado" de <br />
-- tamaño total no mayor a `x'.<br />
-- ¿Cómo calcular `bestDisk'? Optemos por una definición recursiva:<br />
-- Caso base de la recursión: el disco mejor empacado para tamaño 0 <br />
-- es vacío y el disco mejor empacado para una lista vacía de directorios <br />
-- también es el vacío<br />
bestDisk 0 _ = DirPack 0 []<br />
bestDisk _ [] = DirPack 0 []<br />
-- Paso recursivo: para el tamaño `limit' mayor que cero, el disco mejor<br />
-- empacado se calcula de la manera siguiente:<br />
<br />
bestDisk limit dirs =<br />
-- Toma todos los directorios no vacíos que quepan por sí mismos en ese disco,<br />
-- uno por uno. Sea el tamaño de un directorio d en particular `dir_size d'. <br />
-- Agreguémoslo al disco mejor empacado de tamaño <= (limit - dir_size d),<br />
-- produciendo un disco de tamaño <= limit. Hagamos esto para todos los<br />
--directorios "candidato" que no están aún en el disco:<br />
case [ DirPack (dir_size d + s) (d:ds) | d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) dirs <br />
, d `notElem` ds<br />
] of<br />
-- O no podemos agregar ningún directorio (probablemente porque todos<br />
-- son muy grandes); bueno, reportemos que ese disco se debe quedar vacío:<br />
[] -> DirPack 0 []<br />
-- O creamos otros empacamientos diferentes, y seleccionamos el mejor de todos:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
dynamic_pack limit dirs = bestDisk limit dirs<br />
</haskell><br />
<br />
Compila la versión con evaluación de desempeño de este código y obtén el perfil de ejecución general (con "+RTS -p"). Vas a conseguir algo parecido a esto:<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 0.00 secs (0 ticks @ 20 ms)<br />
total alloc = 1,129,520 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
CAF GHC.Float 0.0 4.4<br />
main Main 0.0 93.9<br />
<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
MAIN MAIN 1 0 0.0 0.0 0.0 100.0<br />
main Main 180 1 0.0 93.9 0.0 94.2<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 0.0 0.3<br />
dynamic_pack Main 182 200 0.0 0.2 0.0 0.3<br />
bestDisk Main 183 200 0.0 0.1 0.0 0.1<br />
<br />
Obtuvimos una gran mejora: ¡el consumo de memoria se reduce por un factor de 700! Ya podemos probar el código en el problema real - modifica el código para ejecutar la prueba para empacar el disco de tamaño completo:<br />
<br />
<haskell><br />
main = quickCheck prop_dynamic_pack_is_fixpoint<br />
</haskell><br />
<br />
Compila con evaluación de desempeño y ejecuta (con "+RTS -p"). Si no tienes suerte y se produce al azar un conjunto de pruebas considerablemente grande, tendrás que esperar. Y esperar aún más. Y más.<br />
<br />
Ve a preparar té. Tómate el té. Lee algo de Tolstoi (¿tienes "La Guerra y La Paz" a la mano?). Lo más probable es que para cuando termines con Tolstoi el programa siga corriendo (mejor créeme, no hagas la prueba).<br />
<br />
Si tienes suerte, tu programa finalizará suficientemente rápido y te producirá un perfil. De acuerdo con un perfil, el programa pasa el 99% del tiempo dentro de <tt>bestDisk</tt>. ¿Podemos mejorar de alguna forma el desempeño de <tt>bestDisk</tt>?<br />
<br />
Nota que <tt>bestDisk</tt> realiza varios cálculos simples para los que se debe llamar a sí mismo. Sin embargo, lo hace de forma ineficiente - cada vez le pasamos a <tt>bestDisk</tt> exactamente el mismo conjunto de directorios, aún cuando ya hemos "empacado" algunos. Arreglemos eso:<br />
<br />
Note that <tt>bestDisk</tt> performs several simple calculation for<br />
which it must call itself. However, it is done rather inefficiently -<br />
each time we pass to <tt>bestDisk</tt> the exact same set of<br />
directories as it was called with, even if we have already "packed"<br />
some of them. Let's amend this:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
case [ DirPack (dir_size d + s) (d:ds) | let small_enough = filter ( (inRange (0,limit)).dir_size ) dirs<br />
, d <- small_enough<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) (delete d small_enough)<br />
] of<br />
</haskell><br />
<br />
Recompila y ejecuta de nuevo. Los tiempos pueden ser prolongados, pero soportables, y el número de veces que llama a <tt>bestDisk</tt> (de acuerdo al perfil) debe disminuir significativamente.<br />
<br />
Finalmente, comparemos ambos algoritmos de empacado. Intuitivamente sentimos que el algoritmo voraz debe producir peores resultados, ¿o no?; hagamos pruebas para verificar:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
prop_greedy_pack_is_no_better_than_dynamic_pack ds =<br />
pack_size (greedy_pack ds) <= pack_size (dynamic_pack media_size ds)<br />
</haskell><br />
<br />
Ejecuta <tt>quickCheck</tt> con esta prueba varias veces para hacer la comparación. Yo siento que con esto concluyen nuestros ejercicios empacando la mochila.<br />
<br />
El lector con sed de aventura puede ir más lejos implementando "escalamiento" para <tt>dynamic_pack</tt>, que es cuando se dividen los directorios y los discos por tamaño y se comienza empacando los más pequeños (lo que promete que corre más rápido).<br />
<br />
== Capítulo 5: (Ab)usando mónadas y destruyendo constructores por negocio y diversión ==<br />
<br />
Ya hemos mencionado las mónadas varias veces. Están descritas en numerosos artículos y tutoriales (ver el Capítulo 400). Es difícil leer una lista de correos de Haskell y no cruzarse con la palabra "monad" una docena de veces.<br />
<br />
Como ya hemos hecho avances con Haskell, es momento de revisitar las mónadas una vez más. Dejaré que otras fuentes te enseñen la teoría detrás de las mónadas, la utilidad del concepto, etc; en lugar de eso, me enfocaré en mostrar ejemplos.<br />
<br />
Tomemos una parte de un programa de mundo real que involucra procesamiento XML. Trabajaremos con atributos de etiqueta XML, que son esencialmente valores con nombre:<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
type Attribute = (Name, AttValue)<br />
</haskell><br />
<br />
'Name' es una cadena, y AttValue puede ser una cadena '''o''' referencias (también cadenas) a otros atributos que guardan el valor real (esto no es algo válido en XML, pero, para el ejemplo, lo haremos así). Decir "o" sugiere que usemos el tipo de dato 'Either' ("uno de"):<br />
<haskell><br />
type AttValue = Either Value [Reference]<br />
type Name = String<br />
type Value = String<br />
type Reference = String<br />
<br />
-- Lista de atributos simples muestra:<br />
simple_attrs = [ ( "xml:lang", Left "en" )<br />
, ( "xmlns", Left "jabber:client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
<br />
-- Lista de atributos muestra con referencias:<br />
complex_attrs = [ ( "xml:lang", Right ["lang"] )<br />
, ( "lang", Left "en" )<br />
, ( "xmlns", Right ["ns","subns"] )<br />
, ( "ns", Left "jabber" )<br />
, ( "subns", Left "client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
</haskell><br />
<br />
'''Nuestro objetivo es:''' escribir una función que busque un valor del atributo por nombre en una lista dada de atributos. Cuando el atributo contenga referencias, las resolvemos (buscando el atributo referenciado en la misma lista) y concatenamos sus valores, separados por punto y coma. Entonces, la búsqueda del atributo "xmlns" desde ambos conjuntos muestra debe regresar el mismo valor.<br />
<br />
Siguiendo el ejemplo de <hask>Data.List.lookup</hask> de la biblioteca estándar, llamaremos a nuestra función <hask>lookupAttr</hask> que regresará <hask>Maybe Value</hask>, permitiendo manejar errores en la búsqueda:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
-- Como no tenemos código para 'lookupAttr', pero queremos<br />
-- que compile, usamos la función 'undefined' para<br />
-- indicar un cuerpo de función que siempre falla al ser ejecutado.<br />
lookupAttr = undefined<br />
</haskell><br />
<br />
Intentemos escribir <hask>lookupAttr</hask> usando <hask>lookup</hask> de forma directa:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
import Data.List<br />
<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
lookupAttr nm attrs = <br />
-- Primero, buscamos 'Maybe AttValue' por nombre y<br />
-- vemos si hemos tenido éxito:<br />
case (lookup nm attrs) of<br />
-- Simplemente propaga el error.<br />
Nothing -> Nothing <br />
-- Si el nombre existe, ver si es valor o referencia:<br />
Just attv -> case attv of<br />
-- Es un valor; regrésalo.<br />
Left val -> Just val<br />
-- Es una lista de referencias :(<br />
-- Tenemos que seguirlas, y tener cuidado con<br />
-- los posibles errores.<br />
-- Primero, hacemos búsqueda en todas las referencias...<br />
Right refs -> let vals = [ lookupAttr ref attrs | ref <- refs ]<br />
-- ...luego, excluimos los errores<br />
wo_failures = filter (/=Nothing) vals<br />
-- ...buscamos forma de sacar los datos del contenedor 'Just'<br />
stripJust (Just v) = v<br />
-- ...la usamos para extraer los resultados como cadenas<br />
strings = map stripJust wo_failures<br />
in<br />
-- ...finalmente los combinamos en una sola cadena.<br />
-- Si todas las búsquedas fallaron, debemos propagar un error.<br />
case null strings of<br />
True -> Nothing<br />
False -> Just (concat (intersperse ":" strings))<br />
</haskell><br />
<br />
Probando:<br />
<br />
*Main> lookupAttr "xmlns" complex_attrs<br />
Just "jabber:client"<br />
*Main> lookupAttr "xmlns" simple_attrs<br />
Just "jabber:client"<br />
*Main><br />
<br />
Funciona, pero... parece extraño que haga falta tanto código para hacer algo tan sencillo. Si examinas el código de cerca, verás que el exceso de código es causado por:<br />
<br />
* el hecho de que verificamos si un error ocurrió después de cada paso<br />
<br />
* sacar Strings de los constructores de datos <hask>Maybe</hask> y <hask>Either</hask> para volverlas a meter.<br />
<br />
En este punto los programadores Java/C++ dirían que, como estamos pasando los errores hacia arriba, todos esos casos se pueden reemplazar con un bloque "try ... catch ...", y tendrían razón. ¿Significa eso que los programadores Haskell están limitados a usar "case", que lleva más de 10 años siendo obsoleto?<br />
<br />
¡Mónadas al rescate! Como puedes leer en otras partes (vé en la sección 400), las mónadas se usan de formas avanzadas para construir cálculos a partir de otros cálculos. Exactamente lo que necesitamos - queremos combinar varios pasos simples (búsqueda de valores, búsqueda de referencias...) en la función <hask>lookupAttr</hask> de forma que podamos tomar en cuenta posibles errores.<br />
<br />
<br />
Comencemos con el código y lo analizaremos luego:<br />
<haskell><br />
-- Taken from 'chapter5-2.hs'<br />
import Control.Monad<br />
<br />
lookupAttr' nm attrs = do<br />
-- Buscamos 'AttValue' por nombre<br />
attv <- lookup nm attrs<br />
-- Vemos si es valor o referencia<br />
case attv of<br />
-- Es valor; lo regresamos<br />
Left val -> Just val<br />
-- Es lista de referencias<br />
-- Las buscamos, teniendo cuidado con los errores<br />
-- Buscamos todas las referencias...<br />
Right refs -> do vals <- sequence $ map (flip lookupAttr' attrs) refs<br />
-- ...como todos los errores fueron filtrados por "Magia Monádica",<br />
-- ...y todos los 'Just' fueron también retirados,<br />
-- ...sólo combinamos los valores en una sola cadena<br />
-- ...y regresamos un error si está vacía.<br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
'''Ejercicio''': compila el código, y prueba que <hask>lookupAttr</hask> y <hask>lookupAttr'</hask> de verdad funcionan igual. Trata de hacerlo escribiendo un a prueba QuickCheck, definiendo <hask>instance Arbitrary Name</hask> para que los nombres arbitrarios los tome de los nombres disponibles en <hask>simple_attrs</hask>.<br />
<br />
Bueno, de regreso a la historia. ¿Notaste la drástica reducción en tamaño de código? Sin los comentarios, el código ocupa 7 líneas en lugar de 13 - poco más de la mitad. ¿Cómo conseguimos esto?<br />
<br />
Primero, date cuenta de que nunca verificamos si algún cálculo regresa <hask>Nothing</hask>. Aún así, trata de buscar un nombre de atributo que no exista, y <hask>lookupAttr'</haskell> va a regresar Nothing. ¿Cómo puede ser? El secreto está en el hecho de que el constructor de tipo <hask>Maybe</hask> es una "mónada".<br />
<br />
Empleamos la palabra clave <hask>do</hask> para indicar que el bloque de código a continuación es una secuencia de '''acciones monádicas''', donde tiene que suceder '''magia monádica''' cuando usemos '<-', 'return' o pasemos de una acción a otra.<br />
<br />
Diferentes mónadas tienen diferente '''magia'''. El código de biblioteca dice que el constructor de tipo <hask>Maybe</hask>es una mónada en la que podemos usar <hask><-</hask> para "extraer" valores del contenedor <hask>Just</hask> y usar <hask>return</hask> para volver a meterlos en forma de <hask>Just some_value</hask>. Cuando pasamos de una acción a otra en el bloque "do" ocurre una verificación. Si la acción regresa <hask>Nothing</hask>, todos los cálculos de ahí en adelante serán omitidos y todo el bloque "do" regresará <hask>Nothing</hask>.<br />
<br />
Intenta hacer esto para entenderlo mejor:<br />
<br />
<haskell><br />
*Main> let foo x = do v <- x; return (v+1) in foo (Just 5)<br />
Just 6<br />
*Main> let foo x = do v <- x; return (v+1) in foo Nothing <br />
Nothing<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo (Just 'a')<br />
Just 97<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo Nothing <br />
Nothing<br />
*Main> <br />
</haskell><br />
<br />
Por ahora no te fijes en <hask>sequence</hask> y <hask>guard</hask>; más tarde veremos esa parte.<br />
<br />
Como ya retiramos una razón para el exceso de código, es momento de atacar la otra. Nota que henos tenido que usar <hask>case</hask> para '''deconstruir''' el valor de tipo <hask>Either Value<br />
[Reference]</hask>. Seguramente no somos los primeros que tenemos que hacer esto, y que ese caso de uso debe ser muy común.<br />
<br />
En efecto, hay un remedio simple para nuestro caso, y se llama <hask>either</hask>:<br />
<br />
*Main> :t either<br />
either :: (a -> c) -> (b -> c) -> Either a b -> c<br />
<br />
La declaración de tipo se ve complicada, pero aquí hay algunos ejemplos para ayudar a entenderla:<br />
<br />
*Main> :t either (+1) (length) <br />
either (+1) (length) :: Either Int [a] -> Int<br />
*Main> either (+1) (length) (Left 5)<br />
6<br />
*Main> either (+1) (length) (Right "foo")<br />
3<br />
*Main> <br />
<br />
Parece que este es exactamente el caso. Reemplacemos <hask>case</hask> con una invocación a <hask>either</hask>:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-3.hs'<br />
lookupAttr'' nm attrs = do<br />
attv <- lookup nm attrs<br />
either Just (dereference attrs) attv<br />
where<br />
dereference attrs refs = do <br />
vals <- sequence $ map (flip lookupAttr'' attrs) refs<br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
Se va poniendo mejor :)<br />
<br />
Ahora, como semi-ejercicio, intenta entender el significado de "sequence", "guard" and "flip" a partir de la siguiente sesión en ghci:<br />
<br />
*Main> :t sequence<br />
sequence :: (Monad m) => [m a] -> m [a]<br />
*Main> :t [Just 'a', Just 'b', Nothing, Just 'c']<br />
[Just 'a', Just 'b', Nothing, Just 'c'] :: [Maybe Char]<br />
*Main> :t sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
sequence [Just 'a', Just 'b', Nothing, Just 'c'] :: Maybe [Char]<br />
<br />
*Main> sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b', Nothing]<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b']<br />
Just "ab"<br />
<br />
*Main> :t [putStrLn "a", putStrLn "b"]<br />
[putStrLn "a", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", putStrLn "b"]<br />
sequence [putStrLn "a", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", putStrLn "b"]<br />
a<br />
b<br />
<br />
*Main> :t [putStrLn "a", fail "stop here", putStrLn "b"]<br />
[putStrLn "a", fail "stop here", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
sequence [putStrLn "a", fail "stop here", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
a<br />
*** Exception: user error (stop here)<br />
<br />
Nota que para la mónada <hask>Maybe</hask> sequence continúa la ejecución hasta el primer <hask>Nothing</hask>. Se puede observar el mismo comportamiento para la mónada IO. ¡Toma en cuenta que la definición de <hask>sequence</hask> no incluye ese comportamiento!<br />
<br />
Ahora, examinemos <hask>guard</hask>:<br />
<br />
*Main> let foo x = do v <- x; guard (v/=5); return (v+1) in map foo [Just 4, Just 5, Just 6] <br />
[Just 5,Nothing,Just 7]<br />
<br />
Como puedes ver, es solamente una forma simple de "detener" la ejecución cuando se cumple alguna condición.<br />
<br />
<br />
If you have been hooked on monads, I urge you to read "All About<br />
Monads" right now (link in Chapter 400).<br />
<br />
== Chapter 6: Where do you want to go tomorrow? ==<br />
<br />
As the name implies, the author is open for proposals - where should<br />
we go next? I had networking + xml/xmpp in mind, but it might be too<br />
heavy and too narrow for most of the readers.<br />
<br />
What do you think? Drop me a line.<br />
<br />
== Chapter 400: Monads up close ==<br />
<br />
Read [http://en.wikibooks.org/wiki/Haskell/Understanding_monads this wikibook chapter]. <br />
Then, read [http://www.nomaware.com/monads "All about monads"].<br />
'Nuff said :)<br />
<br />
== Chapter 500: IO up close ==<br />
<br />
Shows that:<br />
<br />
<haskell><br />
c = do a <- someAction<br />
b <- someOtherAction<br />
print (bar b)<br />
print (foo a)<br />
print "done"<br />
</haskell><br />
<br />
really is just a syntax sugar for:<br />
<br />
<haskell><br />
c = someAction >>= \a -><br />
someOtherAction >>= \b -><br />
print (bar b) >><br />
print (foo a) >><br />
print "done"<br />
</haskell><br />
<br />
and explains about ">>=" and ">>". Oh wait. This was already explained<br />
in Chapter 400 :)<br />
<br />
== Chapter 9999: Installing Haskell Compiler/Interpreter and all necessary software ==<br />
<br />
Plenty of material on this on the web and this wiki. Just go get<br />
yourself installation of [[GHC]] (6.4 or above) or [[Hugs]] (v200311 or<br />
above) and "[[darcs]]", which we will use for version control.<br />
<br />
== Chapter 10000: Thanks! ==<br />
<br />
Thanks for comments, proofreading, good advice and kind words go to:<br />
Helge, alt, dottedmag, Paul Moore, Ben Rudiak-Gould, Jim Wilkinson,<br />
Andrew Zhdanov (avalez), Martin Percossi, SpellingNazi, Davor<br />
Cubranic, Brett Giles, Stdrange, Brian Chrisman, Nathan Collins,<br />
Anastasia Gornostaeva (ermine), Remi, Ptolomy, Zimbatm,<br />
HenkJanVanTuyl, Miguel, Mforbes, Kartik Agaram.<br />
<br />
If I should have mentioned YOU and forgot - tell me so.<br />
<br />
Without you I would have stopped after Chapter 1 :)<br />
<br />
{{traduccion|titulo=Hitchhikers guide to Haskell}}<br />
[[Category:Es/Tutoriales|Guía de Haskell para autoestopistas]]</div>Imzhttps://wiki.haskell.org/index.php?title=Es/Haskell&diff=39267Es/Haskell2011-03-30T19:06:32Z<p>Imz: /* Tutoriales */ remove "garbage" from how the wikilink has been printed out.</p>
<hr />
<div>Bienvenido a la página en español acerca del lenguaje de programación Haskell.<br />
<br />
La idea es recopilar información en español acerca de este lenguaje puramente funcional, y de esa forma promover su uso entre hispano-hablantes.<br />
<br />
== Acerca de Haskell ==<br />
<br />
* [[Introducción]]<br />
* [[Librerías y Herramientas|Librerías y Herramientas]]<br />
* [[Haskell en 5 pasos]]<br />
* [[Es/Implementaciones | Implementaciones]]<br />
<br />
----<br />
<br />
==Boletín Semanal de Haskell (HWN)==<br />
<br />
Última entrega: [http://www.haskell.org/haskellwiki/HWN/es/2006-10-31 2006-10-31]<br />
<br />
Visita el [http://www.haskell.org/haskellwiki/HWN/es Boletín Semanal Haskell]<br />
para traducciones de la 'Haskell Weekly Newsletter'. Una publicación semanal ofreciendo todos los desarrollos y acontecimientos que se llevan a cabo en la comunidad de Haskell.<br />
<br />
----<br />
==Libros==<br />
<br />
Blas C. Ruiz, Francisco Gutiérrez, Pablo Guerrero y José E. Gallardo. [http://www.lcc.uma.es/~pepeg/pfHaskell/index.html Razonando con Haskell]: Thompson 2004. ISBN 84-9732-277-0.<br />
<blockquote><br />
<b>Descripción</b><br />
El objetivo principal de este libro es el de servir como libro de texto de las asignaturas de Programación Declarativa correspondientes a los estudios de Informática o Ciencias de la Computación, y otras ciencias en general ( Matemáticas, Física, etc.).<br />
<br />
El texto es fruto de una larga experiencia docente de los autores dentro de las distintas asignaturas que desarrollan la Programación Funcional en distintas titulaciones de la Universidad de Málaga. Aún así, su lectura no queda condicionada a un conocimiento previo sobre lenguajes de programación (de computadores), ni sobre Informática. De esta forma, el libro puede ser utilizado por todo aquel que desee tener un conocimiento amplio sobre la Programación Funcional.<br />
</blockquote><br />
<br />
----<br />
<br />
==Tutoriales==<br />
<br />
;[http://www.lcc.uma.es/~blas/pfHaskell/gentle/ Una introducción agradable a Haskell]: Traducción en español del famoso tutorial en inglés "A Gentle Introduction to Haskell".<br />
<br />
;[http://www.cs.uu.nl/people/jeroen/courses/fp-sp.pdf Programación Funcional]: Tutorial escrito por Jeroen Fokker del Departamento de Informática de la Universidad de Utrecht. Este tutorial cubre de forma muy didáctica los aspectos básicos para empezar a entender Haskell.<br />
<br />
;[[Es/Guía de Haskell para autoestopistas|Guía de Haskell para autoestopistas]]: Traducción (en progreso) en español de "[[Hitchhikers guide to Haskell]]".<br />
<br />
;[http://www.muitovar.com/glade/es-index.html Tutorial de Glade]:<br />
Este tutorial intenta proporcionar una guía paso a paso para los desarrolladores de Haskell que quieren escribir aplicaciones GTK+ usando Glade. Asumimos que estás usando Linux aunque tanto el conjunto de herramientas Gtk+, el diseñador de interfaces Glade y Gtk2Hs están disponibles en otras plataformas. Esta página tutorial es una adaptación para Haskell y Gtk2Hs de un tutorial original para C y la GTK+ C API<br />
<br />
;[http://darcs.haskell.org/gtk2hs/docs/tutorial/Tutorial_Port/es-index.xhtml Tutorial básico de Gtk2Hs]:<br />
Capítulos: Introducción, Empezando, Empaquetando Widgets, Programa de demostración de empaquetado y Empaquetado usando tablas, El Widget botón, Ajustes, Escala y Rango, Etiquetas, Flechas y Tooltips,<br />
Diálogos, elementos disponibles y barras de progreso, Entradas de texto y barras de estado, Botones de Spin, Calendario, Selección de fichero, Selección de Fuente y Color, Bloc de notas, Ventanas con desplazamiento(scroll), Cajas de evento y cajas de botones, El contenedor de layout, Ventanas con paneles y marcos de ratio constante, Menús y Barras de herramientas, Menús Popup, acciones de radio y acciones Toggle. Apéndice: Dibujando con Cairo: Empezando...<br />
<br />
----<br />
<br />
== Principiantes Haskell ==<br />
;[http://www2.ucsp.edu.pe/%7Eapaz/apuntes/ Todo Haskell en español]:<br />
Texto guia para principiantes, con pequeñas definiciones y ejemplos de programacion funcional haskell, en un sentido academico muy sencillo de entender y comprender.<br />
<br />
----<br />
<br />
==Canal de IRC==<br />
<br />
* #haskell.es : Canal oficial de la comunidad hispano-hablante de Haskell en la red irc.freenode.net.<br />
<br />
----<br />
<br />
== Paquetes recientes ==<br />
<br />
{{Main/News}}<br />
<br />
----<br />
<br />
== TODO ==<br />
<br />
* Traducir las páginas de [[Special:Popularpages]] más importantes.<br />
** [[:Category:Es/Traducción en progreso| Traducciones en progreso]]<br />
* Agregar cualquier información referente a Haskell en Español.<br />
* Agregar proyectos desarrollados por hispano-hablantes.<br />
* Corregir errores que puedan presentar las traducciones.<br />
* Colaborar con las traducciones de la HWN.<br />
<br />
[[Category:Community]]</div>Imzhttps://wiki.haskell.org/index.php?title=Es/Haskell&diff=39266Es/Haskell2011-03-30T19:04:28Z<p>Imz: /* Tutoriales */ Linked to the translation of "Hitchhikers guide to Haskell", not yet finished. But why should the work get lost without links to it?..</p>
<hr />
<div>Bienvenido a la página en español acerca del lenguaje de programación Haskell.<br />
<br />
La idea es recopilar información en español acerca de este lenguaje puramente funcional, y de esa forma promover su uso entre hispano-hablantes.<br />
<br />
== Acerca de Haskell ==<br />
<br />
* [[Introducción]]<br />
* [[Librerías y Herramientas|Librerías y Herramientas]]<br />
* [[Haskell en 5 pasos]]<br />
* [[Es/Implementaciones | Implementaciones]]<br />
<br />
----<br />
<br />
==Boletín Semanal de Haskell (HWN)==<br />
<br />
Última entrega: [http://www.haskell.org/haskellwiki/HWN/es/2006-10-31 2006-10-31]<br />
<br />
Visita el [http://www.haskell.org/haskellwiki/HWN/es Boletín Semanal Haskell]<br />
para traducciones de la 'Haskell Weekly Newsletter'. Una publicación semanal ofreciendo todos los desarrollos y acontecimientos que se llevan a cabo en la comunidad de Haskell.<br />
<br />
----<br />
==Libros==<br />
<br />
Blas C. Ruiz, Francisco Gutiérrez, Pablo Guerrero y José E. Gallardo. [http://www.lcc.uma.es/~pepeg/pfHaskell/index.html Razonando con Haskell]: Thompson 2004. ISBN 84-9732-277-0.<br />
<blockquote><br />
<b>Descripción</b><br />
El objetivo principal de este libro es el de servir como libro de texto de las asignaturas de Programación Declarativa correspondientes a los estudios de Informática o Ciencias de la Computación, y otras ciencias en general ( Matemáticas, Física, etc.).<br />
<br />
El texto es fruto de una larga experiencia docente de los autores dentro de las distintas asignaturas que desarrollan la Programación Funcional en distintas titulaciones de la Universidad de Málaga. Aún así, su lectura no queda condicionada a un conocimiento previo sobre lenguajes de programación (de computadores), ni sobre Informática. De esta forma, el libro puede ser utilizado por todo aquel que desee tener un conocimiento amplio sobre la Programación Funcional.<br />
</blockquote><br />
<br />
----<br />
<br />
==Tutoriales==<br />
<br />
;[http://www.lcc.uma.es/~blas/pfHaskell/gentle/ Una introducción agradable a Haskell]: Traducción en español del famoso tutorial en inglés "A Gentle Introduction to Haskell".<br />
<br />
;[http://www.cs.uu.nl/people/jeroen/courses/fp-sp.pdf Programación Funcional]: Tutorial escrito por Jeroen Fokker del Departamento de Informática de la Universidad de Utrecht. Este tutorial cubre de forma muy didáctica los aspectos básicos para empezar a entender Haskell.<br />
<br />
;[[Es/Guía de Haskell para autoestopistas|Es/Guía de Haskell para autoestopistas]]: Traducción (en progreso) en español de "[[Hitchhikers guide to Haskell]]".<br />
<br />
;[http://www.muitovar.com/glade/es-index.html Tutorial de Glade]:<br />
Este tutorial intenta proporcionar una guía paso a paso para los desarrolladores de Haskell que quieren escribir aplicaciones GTK+ usando Glade. Asumimos que estás usando Linux aunque tanto el conjunto de herramientas Gtk+, el diseñador de interfaces Glade y Gtk2Hs están disponibles en otras plataformas. Esta página tutorial es una adaptación para Haskell y Gtk2Hs de un tutorial original para C y la GTK+ C API<br />
<br />
;[http://darcs.haskell.org/gtk2hs/docs/tutorial/Tutorial_Port/es-index.xhtml Tutorial básico de Gtk2Hs]:<br />
Capítulos: Introducción, Empezando, Empaquetando Widgets, Programa de demostración de empaquetado y Empaquetado usando tablas, El Widget botón, Ajustes, Escala y Rango, Etiquetas, Flechas y Tooltips,<br />
Diálogos, elementos disponibles y barras de progreso, Entradas de texto y barras de estado, Botones de Spin, Calendario, Selección de fichero, Selección de Fuente y Color, Bloc de notas, Ventanas con desplazamiento(scroll), Cajas de evento y cajas de botones, El contenedor de layout, Ventanas con paneles y marcos de ratio constante, Menús y Barras de herramientas, Menús Popup, acciones de radio y acciones Toggle. Apéndice: Dibujando con Cairo: Empezando...<br />
<br />
----<br />
<br />
== Principiantes Haskell ==<br />
;[http://www2.ucsp.edu.pe/%7Eapaz/apuntes/ Todo Haskell en español]:<br />
Texto guia para principiantes, con pequeñas definiciones y ejemplos de programacion funcional haskell, en un sentido academico muy sencillo de entender y comprender.<br />
<br />
----<br />
<br />
==Canal de IRC==<br />
<br />
* #haskell.es : Canal oficial de la comunidad hispano-hablante de Haskell en la red irc.freenode.net.<br />
<br />
----<br />
<br />
== Paquetes recientes ==<br />
<br />
{{Main/News}}<br />
<br />
----<br />
<br />
== TODO ==<br />
<br />
* Traducir las páginas de [[Special:Popularpages]] más importantes.<br />
** [[:Category:Es/Traducción en progreso| Traducciones en progreso]]<br />
* Agregar cualquier información referente a Haskell en Español.<br />
* Agregar proyectos desarrollados por hispano-hablantes.<br />
* Corregir errores que puedan presentar las traducciones.<br />
* Colaborar con las traducciones de la HWN.<br />
<br />
[[Category:Community]]</div>Imzhttps://wiki.haskell.org/index.php?title=Hitchhikers_guide_to_Haskell&diff=39265Hitchhikers guide to Haskell2011-03-30T18:57:19Z<p>Imz: /* Chapter 10000: Thanks! */ Linked the Spanish translation, not fnished yet.</p>
<hr />
<div>== Preface: DON'T PANIC! ==<br />
[[Category:Tutorials]]<br />
Recent experiences from a few of my fellow C++/Java programmers<br />
indicate that they read various Haskell tutorials with "exponential<br />
speedup" (think about how TCP/IP session starts up). They start slow<br />
and cautious, but when they see that the first 3-5 pages do not<br />
contain "anything interesting" in terms of code and examples, they<br />
begin skipping paragraphs, then chapters, then whole pages, only to<br />
slow down - often to a complete halt - somewhere on page 50, finding<br />
themselves in the thick of concepts like "type classes", "type<br />
constructors", "monadic IO", at which point they usually panic, think<br />
of a perfectly rational excuse not to read further anymore, and<br />
happily forget this sad and scary encounter with Haskell (as human<br />
beings usually tend to forget sad and scary things).<br />
<br />
This text intends to introduce the reader to the practical aspects of Haskell<br />
from the very beginning (plans for the first chapters include: I/O, darcs,<br />
Parsec, QuickCheck, profiling and debugging, to mention a few). The reader<br />
is expected to know (where to find) at least the basics of Haskell: how to run<br />
"hugs" or "ghci", '''that layout is 2-dimensional''', etc. Other than that, we do<br />
not plan to take radical leaps, and will go one step at a time in order not to<br />
lose the reader along the way. So DON'T PANIC, take your towel with you and<br />
read along.<br />
<br />
'''In case you've skipped over the previous paragraph''', I would like<br />
to stress out once again that Haskell is sensitive to indentation and<br />
spacing, so pay attention to that during cut-n-pastes or manual<br />
alignment of code in the text editor with proportional fonts.<br />
<br />
Oh, almost forgot: author is very interested in ANY feedback. Drop him a line<br />
or a word (see [[User:Adept|Adept]] for contact info) or submit<br />
patches to the tutorial via darcs (<br />
[http://adept.linux.kiev.ua:8080/repos/hhgtth/ repository is here]) or directly to this<br />
Wiki. <br />
<br />
== Chapter 1: Ubiquitous "Hello world!" and other ways to do IO in Haskell ==<br />
<br />
Each chapter will be dedicated to one small real-life task which we will<br />
complete from the ground up.<br />
<br />
So here is the task for this chapter: in order to free up space on<br />
your hard drive for all the Haskell code you are going to write in the<br />
nearest future, you are going to archive some of the old and dusty<br />
information on CDs and DVDs. While CD (or DVD) burning itself is easy<br />
these days, it usually takes some (or quite a lot of) time to decide<br />
how to put several GB of digital photos on CD-Rs, when directories<br />
with images range from 10 to 300 Mb's in size, and you don't want to<br />
burn half-full (or half-empty) CD-Rs.<br />
<br />
So, the task is to write a program which will help us put a given<br />
collection of directories on the minimum possible amount of media,<br />
while packing the media as tightly as possible. Let's name this program<br />
"cd-fit".<br />
<br />
Oh. Wait. Let's do the usual "hello world" thing, before we forget about it,<br />
and then move on to more interesting things:<br />
<br />
<haskell><br />
-- Taken from 'hello.hs'<br />
-- From now on, a comment at the beginning of the code snippet<br />
-- will specify the file which contain the full program from<br />
-- which the snippet is taken. You can get the code from the darcs<br />
-- repository "http://adept.linux.kiev.ua:8080/repos/hhgtth" by issuing<br />
-- command "darcs get http://adept.linux.kiev.ua:8080/repos/hhgtth"<br />
module Main where<br />
main = putStrLn "Hello world!"<br />
</haskell><br />
<br />
Run it:<br />
<br />
$ runhaskell ./hello.hs<br />
Hello world!<br />
<br />
OK, we've done it. Move along now, nothing interesting here :)<br />
<br />
Any serious development must be done with the help of a version control<br />
system, and we will not make an exception. We will use the modern<br />
distributed version control system "darcs". "Modern" means that it is<br />
written in Haskell, "distributed" means that each working copy is<br />
a repository in itself.<br />
<br />
First, let's create an empty directory for all our code, and invoke<br />
"darcs init" there, which will create subdirectory "_darcs" to store<br />
all version-control-related stuff there.<br />
<br />
Fire up your favorite editor and create a new file called "cd-fit.hs"<br />
in our working directory. Now let's think for a moment about how our<br />
program will operate and express it in pseudocode:<br />
<br />
<haskell><br />
main = Read list of directories and their sizes.<br />
Decide how to fit them on CD-Rs.<br />
Print solution.<br />
</haskell><br />
<br />
Sounds reasonable? I thought so.<br />
<br />
Let's simplify our life a little and assume for now that we will<br />
compute directory sizes somewhere outside our program (for example,<br />
with "du -sb *") and read this information from stdin.<br />
Now let me convert all this to Haskell:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-1-1.hs'<br />
module Main where<br />
<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: got input " ++ input)<br />
-- compute solution and print it<br />
</haskell><br />
<br />
Not really working, but pretty close to plain English, eh? Let's stop<br />
for a moment and look more closely at what's written here line-by-line<br />
<br />
Let's begin from the top:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-1-1.hs'<br />
input <- getContents<br />
</haskell><br />
<br />
This is an example of the Haskell syntax for doing IO (namely, input). This<br />
line is an instruction to read all the information available from the stdin,<br />
return it as a single string, and bind it to the symbol "input", so we can<br />
process this string any way we want.<br />
<br />
How did I know that? Did I memorize all the functions by heart? Of course not!<br />
Each function has a type, which, along with function's name, usually tells a<br />
lot about what a function will do.<br />
<br />
Let's fire up an interactive Haskell environment and examine this function<br />
up close:<br />
<br />
$ ghci<br />
___ ___ _<br />
/ _ \ /\ /\/ __(_)<br />
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.<br />
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/<br />
\____/\/ /_/\____/|_| Type :? for help.<br />
<br />
Loading package base-1.0 ... linking ... done.<br />
Prelude> :type getContents<br />
getContents :: IO String<br />
Prelude> <br />
<br />
We see that "getContents" is a function without arguments, that will return<br />
"IO String". Prefix "IO" meant that this is an IO action. It will return<br />
String, when evaluated. Action will be evaluated as soon as we use "<-" to<br />
bind its result to some symbol.<br />
<br />
Note that "<-" is not a fancy way to assign value to variable. It is a way to<br />
evaluate (execute) IO actions, in other words - to actually do some I/O and<br />
return its result (if any). <br />
<br />
We can choose not to evaluate the action obtained from "getContents", but rather carry it around a bit and evaluate later:<br />
<br />
<haskell><br />
let x = getContents<br />
-- 300 lines of code here<br />
input <- x<br />
</haskell><br />
<br />
So, as you see, IO actions can act like an ordinary values. Suppose that we<br />
have built a list of IO actions and have found a way to execute them one by one.<br />
This would be a way to simulate imperative programming with its notion of<br />
"order of execution".<br />
<br />
Haskell allows you to do better than that. <br />
<br />
The standard language library (named "Prelude", by the way) provides<br />
us with lots of functions that return useful primitive IO actions. In<br />
order to combine them to produce an even more complex actions, we use a "do":<br />
<br />
<haskell><br />
c = do a <- someAction<br />
b <- someOtherAction<br />
print (bar b)<br />
print (foo a)<br />
putStrLn "done"<br />
</haskell><br />
<br />
Here we '''bind''' "c" to an action with the following "scenario":<br />
* '''evaluate''' action "someAction" and '''bind''' its result to "a"<br />
* then, '''evaluate''' "someOtherAction" and '''bind''' its result to "b"<br />
* then, process "b" with function "bar" and print result<br />
* then, process "a" with function "foo" and print result<br />
* then, print the word "done"<br />
<br />
When will all this actually be executed? Answer: as soon as we evaluate "c"<br />
using the "<-" (if it returns result, as "getContents" does) or just<br />
by using it as a function name (if it does not return a result, as "print"<br />
does):<br />
<br />
<haskell><br />
process = do putStrLn "Will do some processing"<br />
c<br />
putStrLn "Done"<br />
</haskell><br />
<br />
Notice that we took a bunch of functions ("someAction", "someOtherAction",<br />
"print", "putStrLn") and using "do" created from them a new function, which we<br />
bound to symbol "c". Now we could use "c" as a building block to produce an even<br />
more complex function, "process", and we could carry this on and on.<br />
Eventually, some of the functions will be mentioned in the code of function<br />
"main", to which the ultimate topmost IO action any Haskell program is bound.<br />
<br />
When will the "main" be executed/evaluated/forced? As soon as we run the<br />
program. Read this twice and try to comprehend: <br />
<br />
''The execution of a Haskell program is an evaluation of the symbol "main" to<br />
which we have bound an IO action. Via evaluation we obtain the result of that<br />
action''. <br />
<br />
Readers familiar with advanced C++ or Java programming and that arcane body of<br />
knowledge named "OOP Design Patterns" might note that "build actions from<br />
actions" and "evaluate actions to get result" is essentially a "Command<br />
pattern" and "Composition pattern" combined. Good news: in Haskell you get them<br />
for all your IO, and get them '''for free''' :)<br />
<br />
----<br />
'''Exercise:'''<br />
Consider the following code:<br />
<br />
<haskell><br />
-- Taken from 'exercise-1-1.hs'<br />
module Main where<br />
c = putStrLn "C!"<br />
<br />
combine before after =<br />
do before<br />
putStrLn "In the middle"<br />
after<br />
<br />
main = do combine c c<br />
let b = combine (putStrLn "Hello!") (putStrLn "Bye!")<br />
let d = combine (b) (combine c c)<br />
putStrLn "So long!"<br />
</haskell><br />
<br />
Notice how we carefully indent lines so that source looks neat?<br />
Actually, Haskell code has to be aligned this way, or it will not<br />
compile. If you use tabulation to indent your sources, take into<br />
account that Haskell compilers assume that tabstop is 8 characters<br />
wide.<br />
<br />
Often people complain that it is very difficult to write Haskell<br />
because it requires them to align code. Actually, this is not true. If<br />
you align your code, compiler will guess the beginnings and endings of<br />
syntactic blocks. However, if you don't want to indent your code, you<br />
could explicitly specify end of each and every expression and use<br />
arbitrary layout as in this example: <br />
<haskell><br />
-- Taken from 'exercise-1-2.hs'<br />
combine before after = <br />
do { before; <br />
putStrLn "In the middle"; <br />
after; };<br />
<br />
main = <br />
do { combine c c; let { b = combine (putStrLn "Hello!") (putStrLn "Bye!")};<br />
let {d = combine (b) (combine c c)}; <br />
putStrLn "So long!" };<br />
</haskell><br />
<br />
Back to the exercise - see how we construct code out of thin air? Try<br />
to imagine what this code will do, then run it and check yourself.<br />
<br />
Do you understand why "Hello!" and "Bye!" are not printed?<br />
----<br />
<br />
Let's examine our "main" function closer:<br />
<br />
Prelude> :load cd-fit.hs<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :type main<br />
main :: IO ()<br />
*Main> <br />
<br />
We see that "main" is indeed an IO action which will return nothing<br />
when evaluated. When combining actions with "do", the type of the<br />
result will be the type of the last action, and "putStrLn something" has type<br />
"IO ()": <br />
<br />
*Main> :type putStrLn "Hello world!"<br />
putStrLn "Hello world!" :: IO ()<br />
*Main> <br />
<br />
Oh, by the way: have you noticed that we actually compiled our first<br />
Haskell program in order to examine "main"? :)<br />
<br />
let's celebrate that by putting it under version control: execute<br />
"darcs add cd-fit.hs" and "darcs record", answer "y" to all questions<br />
and provide a commit comment "Skeleton of cd-fit.hs"<br />
<br />
Let's try to run it:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: got input foo<br />
<br />
----<br />
'''Exercises''':<br />
<br />
* Try to write a program that takes your name from the stdin and greets you (keywords: getLine, putStrLn);<br />
<br />
* Try to write a program that asks for you name, reads it, greets you, asks for your favorite color, and prints it back (keywords: getLine, putStrLn).<br />
<br />
== Chapter 2: Parsing the input ==<br />
<br />
OK, now that we have proper understanding of the powers of Haskell IO<br />
(and are awed by them, I hope), let's forget about IO and actually do<br />
some useful work. <br />
<br />
As you remember, we set forth to pack some CD-Rs as tightly as<br />
possible with data scattered in several input directories. We assume<br />
that "du -sb" will compute the sizes of input directories and output<br />
something like:<br />
<br />
65572 /home/adept/photos/raw-to-burn/dir1<br />
68268 /home/adept/photos/raw-to-burn/dir2<br />
53372 /home/adept/photos/raw-to-burn/dir3<br />
713124 /home/adept/photos/raw-to-burn/dir4<br />
437952 /home/adept/photos/raw-to-burn/dir5<br />
<br />
Our next task is to parse that input into some suitable internal<br />
representation.<br />
<br />
For that we will use powerful library of '''parsing combinators''' named<br />
"[[Parsec]]" which ships with most Haskell implementations.<br />
<br />
Much like the IO facilities we have seen in the first chapter, this<br />
library provides a set of basic parsers and means to combine into more<br />
complex parsing constructs.<br />
<br />
Unlike other tools in this area (lex/yacc or JavaCC to name a few),<br />
[[Parsec]] parsers do not require a separate preprocessing stage. Since in<br />
Haskell we can return function as a result of function and thus<br />
construct functions "from the thin air", there is no need for a separate<br />
syntax for parser description. But enough advertisements, let's actually<br />
do some parsing:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
import Text.ParserCombinators.Parsec<br />
<br />
-- parseInput parses output of "du -sb", which consists of many lines,<br />
-- each of which describes single directory<br />
parseInput = <br />
do dirs <- many dirAndSize<br />
eof<br />
return dirs<br />
<br />
-- Datatype Dir holds information about single directory - its size and name<br />
data Dir = Dir Int String deriving Show<br />
<br />
-- `dirAndSize` parses information about single directory, which is:<br />
-- a size in bytes (number), some spaces, then directory name, which extends till newline<br />
dirAndSize = <br />
do size <- many1 digit<br />
spaces<br />
dir_name <- anyChar `manyTill` newline<br />
return (Dir (read size) dir_name)<br />
</haskell><br />
<br />
Just add those lines to "cd-fit.hs", between the declaration of <br />
the Main module and the definition of main.<br />
<br />
Here we see quite a lot of new<br />
things, and several those that we know already. <br />
First of all, note the familiar "do" construct, which, as we know, is<br />
used to combine IO actions to produce new IO actions. Here we use it<br />
to combine "parsing" actions into new "parsing" actions. Does this<br />
mean that "parsing" implies "doing IO"? Not at all. Thing is, I must<br />
admit that I lied to you - "do" is used not only to combine IO<br />
actions. "Do" is used to combine any kind of so-called ''monadic<br />
actions'' or ''monadic values'' together.<br />
<br />
Think about [[monad]] as a "[[:Category:Idioms|design pattern]]" in the functional world.<br />
[[Monad]] is a way to hide from the user (programmer) all the machinery<br />
required for complex functionality to operate.<br />
<br />
As you might have heard, Haskell has no notion of "assignment",<br />
"mutable state", "variables", and is a "pure functional language",<br />
which means that every function called with the same input parameters<br />
will return exactly the same result. Meanwhile "doing IO" requires<br />
hauling around file handles and their states and dealing with IO<br />
errors. "Parsing" requires to track position in the input and dealing<br />
with parsing errors.<br />
<br />
In both cases Wise Men Who Wrote Libraries cared for our needs and<br />
hide all underlying complexities from us, exposing the [http://en.wikipedia.org/wiki/Application_programming_interface API] of their<br />
libraries (IO and parsing) in the form of "monadic action" which we<br />
are free to combine as we see fit. <br />
<br />
Think of programming with monads as of doing the remodelling with the<br />
help of professional remodelling crew. You describe sequence of<br />
actions on the piece of paper (that's us writing in "do" notation),<br />
and then, when required, that sequence will be evaluated by the<br />
remodelling crew ("in the monad") which will provide you with end<br />
result, hiding all the underlying complexity (how to prepare the<br />
paint, which nails to choose, etc) from you.<br />
<br />
let's use the interactive Haskell environment to decipher all the<br />
instructions we've written for the parsing library. As usually, we'll<br />
go top-down:<br />
<br />
*Main> :reload<br />
Ok, modules loaded: Main.<br />
*Main> :t parseInput<br />
parseInput :: GenParser Char st [Dir]<br />
*Main> :t dirAndSize<br />
dirAndSize :: GenParser Char st Dir<br />
*Main> <br />
<br />
Assuming (well, take my word for it) that "GenParser Char st" is our<br />
parsing monad, we could see that "parseInput", when evaluated, will<br />
produce a list of "Dir", and "dirAndSize", when evaluated, will<br />
produce "Dir". Assuming that "Dir" somehow represents information<br />
about single directory, that is pretty much what we wanted, isn't it?<br />
<br />
Let's see what a "Dir" means. We defined ''data[[type]]'' Dir as a record,<br />
which holds an Int and a String:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
data Dir = Dir Int String deriving Show<br />
</haskell><br />
<br />
In order to construct such records, we must use ''data [[constructor]]''<br />
Dir:<br />
<br />
*Main> :t Dir 1 "foo"<br />
Dir 1 "foo" :: Dir<br />
<br />
In order to reduce confusion for newbies, we could have written:<br />
<haskell><br />
data Dir = D Int String deriving Show<br />
</haskell><br />
<br />
, which would define ''data[[type]]'' "Dir" with ''data [[constructor]]'' "D".<br />
However, traditionally name of the data[[type]] and its [[constructor]] are<br />
chosen to be the same.<br />
<br />
Clause "[[deriving]] Show" instructs the compiler to make enough code "behind<br />
the curtains" to make this ''datatype'' conform to the interface of<br />
the ''type [[class]]'' Show. We will explain ''type [[class]]es'' later, for<br />
now let's just say that this will allow us to "print" instances of<br />
"Dir".<br />
<br />
'''Exercises:''' <br />
* examine types of "digit", "anyChar", "many", "many1" and "manyTill" to see how they are used to build more complex parsers from single ones.<br />
<br />
* compare types of "manyTill", "manyTill anyChar" and "manyTill anyChar newline". Note that "anyChar `manyTill` newline" is just another syntax sugar. Note that when function is supplied with less arguments that it actually needs, we get not a value, but a new function, which is called ''partial application''.<br />
<br />
<br />
OK. So, we combined a lot of primitive parsing actions to get ourselves a<br />
parser for output of "du -sb". How can we actually parse something? the [[Parsec]] library supplies us with function "parse":<br />
<br />
*Main> :t parse<br />
parse :: GenParser tok () a<br />
-> SourceName<br />
-> [tok]<br />
-> Either ParseError a<br />
*Main> :t parse parseInput<br />
parse parseInput :: SourceName -> [Char] -> Either ParseError [Dir]<br />
*Main> <br />
<br />
At first the [[type]] might be a bit cryptic, but once we supply "parse" with the parser we made, the compiler gets more information and presents us with a more concise [[type]].<br />
<br />
Stop and consider this for a moment. The compiler figured out type of the function without a single type annotation supplied by us! Imagine if a Java compiler deduced types for you, and you wouldn't have to specify types of arguments and return values of methods, ever.<br />
<br />
OK, back to the code. We can observe that the "parser" is a function, which,<br />
given a parser, a name of the source file or channel (f.e. "stdin"), and<br />
source data (String, which is a list of "Char"s, which is written "[Char]"),<br />
will either produce parse error, or parse us a list of "Dir".<br />
<br />
Datatype "Either" is an example of datatype whose constructor has name, different<br />
from the name of the datatype. In fact, "Either" has two constructors:<br />
<br />
<haskell><br />
data Either a b = Left a | Right b<br />
</haskell><br />
<br />
In order to understand better what does this mean consider the following<br />
example:<br />
<br />
*Main> :t Left 'a'<br />
Left 'a' :: Either Char b<br />
*Main> :t Right "aaa"<br />
Right "aaa" :: Either a [Char]<br />
*Main> <br />
<br />
You see that "Either" is a ''union'' (much like the C/C++ "union") which could<br />
hold value of one of the two distinct types. However, unlike C/C++ "union",<br />
when presented with value of type "Either Int Char" we could immediately see<br />
whether its an Int or a Char - by looking at the constructor which was used to<br />
produce the value. Such datatypes are called "tagged unions", and they are<br />
another [[:Category:Idioms|power tool]] in the Haskell toolset.<br />
<br />
Did you also notice that we provide "parse" with parser, which is a monadic<br />
value, but receive not a new monadic value, but a parsing result? That is<br />
because "parse" is an evaluator for "Parser" monad, much like the [[GHC]] or [[Hugs]] runtime is an evaluator for the IO monad. The function "parser" implements all monadic machinery: it tracks errors and positions in input, implements backtracking and lookahead, etc.<br />
<br />
let's extend our "main" function to use "parse" and actually parse the input<br />
and show us the parsed data structures:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: got input " ++ input)<br />
let dirs = case parse parseInput "stdin" input of<br />
Left err -> error $ "Input:\n" ++ show input ++ <br />
"\nError:\n" ++ show err<br />
Right result -> result<br />
putStrLn "DEBUG: parsed:"; print dirs<br />
</haskell><br />
<br />
'''Exercise:'''<br />
<br />
* In order to understand this snippet of code better, examine (with ghci or hugs) the difference between 'drop 1 ( drop 1 ( drop 1 ( drop 1 ( drop 1 "foobar" ))))' and 'drop 1 $ drop 1 $ drop 1 $ drop 1 $ drop 1 "foobar"'. Examine type of ($).<br />
* Try putStrLn "aaa" and print "aaa" and see the difference, examine their types.<br />
* Try print (Dir 1 "foo") and putStrLn (Dir 1 "foo"). Examine types of print and putStrLn to understand the behavior in both cases.<br />
<br />
Let's try to run what we have so far:<br />
<br />
$ du -sb * | runhaskell ./cd-fit.hs<br />
<br />
DEBUG: got input 22325 Article.txt<br />
18928 Article.txt~<br />
1706 cd-fit.hs<br />
964 cd-fit.hs~<br />
61609 _darcs<br />
<br />
DEBUG: parsed:<br />
[Dir 22325 "Article.txt",Dir 18928 "Article.txt~",<br />
Dir 1706 "cd-fit.hs",Dir 964 "cd-fit.hs~",Dir 61609 "_darcs"]<br />
<br />
Seems to be doing exactly as planned. Now let's try some erroneous<br />
input:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: got input foo<br />
<br />
DEBUG: parsed:<br />
*** Exception: Input:<br />
"foo\n"<br />
Error:<br />
"stdin" (line 1, column 1):<br />
unexpected "f"<br />
expecting digit or end of input<br />
<br />
Seems to be doing fine. <br />
<br />
If you followed advice to put your code under version control, you<br />
could now use "darcs whatsnew" or "darcs diff -u" to examine your<br />
changes to the previous version. Use "darcs record" to commit them. As<br />
an exercise, first record the changes "outside" of function "main" and<br />
then record the changes in "main". Do "darcs changes" to examine a<br />
list of changes you've recorded so far.<br />
<br />
== Chapter 3: Packing the knapsack and testing it with class, too (and don't forget your towel!) ==<br />
<br />
Enough preliminaries already. let's go pack some CDs.<br />
<br />
As you might already have recognized, our problem is a classical one. It is<br />
called a "knapsack problem" ([http://www.google.com/search?q=knapsack+problem google it up], if you don't know already what it<br />
is. There are more than 100000 links).<br />
<br />
let's start from the greedy solution, but first let's slightly modify our "Dir"<br />
datatype to allow easy extraction of its components:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
----<br />
'''Exercise:''' examine types of "Dir", "dir_size" and "dir_name"<br />
----<br />
<br />
From now on, we could use "dir_size d" to get a size of directory, and<br />
"dir_name d" to get its name, provided that "d" is of type "Dir".<br />
<br />
The Greedy algorithm sorts directories from the biggest down, and tries to put<br />
them on CD one by one, until there is no room for more. We will need to track<br />
which directories we added to CD, so let's add another datatype, and code this<br />
simple packing algorithm:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
import Data.List (sortBy)<br />
<br />
-- DirPack holds a set of directories which are to be stored on single CD.<br />
-- 'pack_size' could be calculated, but we will store it separately to reduce<br />
-- amount of calculation<br />
data DirPack = DirPack {pack_size::Int, dirs::[Dir]} deriving Show<br />
<br />
-- For simplicity, let's assume that we deal with standard 700 Mb CDs for now<br />
media_size = 700*1024*1024<br />
<br />
-- Greedy packer tries to add directories one by one to initially empty 'DirPack'<br />
greedy_pack dirs = foldl maybe_add_dir (DirPack 0 []) $ sortBy cmpSize dirs<br />
where<br />
cmpSize d1 d2 = compare (dir_size d1) (dir_size d2)<br />
<br />
-- Helper function, which only adds directory "d" to the pack "p" when new<br />
-- total size does not exceed media_size<br />
maybe_add_dir p d =<br />
let new_size = pack_size p + dir_size d<br />
new_dirs = d:(dirs p)<br />
in if new_size > media_size then p else DirPack new_size new_dirs<br />
</haskell><br />
<br />
----<br />
I'll highlight the areas which you could explore on your own (using other nice<br />
tutorials out there, of which I especially recommend "Yet Another Haskell<br />
Tutorial" by Hal Daume):<br />
* We choose to import a single function "sortBy" from a module [[Data.List]], not the whole thing.<br />
* Instead of coding case-by-case recursive definition of "greedy_pack", we go with higher-order approach, choosing "foldl" as a vehicle for list traversal. Examine its type. Other useful function from the same category are "map", "foldr", "scanl" and "scanr". Look them up!<br />
* To sort list of "Dir" by size only, we use custom sort function and parametrized sort - "sortBy". This sort of setup where the user may provide a custom "modifier" for a generic library function is quite common: look up "deleteBy", "deleteFirstsBy", "groupBy", "insertBy", "intersectBy", "maximumBy", "minimumBy", "sortBy", "unionBy".<br />
* To code the quite complex function "maybe_add_dir", we introduced several '''local definitions''' in the "let" clause, which we can reuse within the function body. We used a "where" clause in the "greedy_pack" function to achieve the same effect. Read about "let" and "where" clauses and the differences between them.<br />
* Note that in order to construct a new value of type "DirPack" (in function "maybe_add_dir") we haven't used the helper accessor functions "pack_size" and "dirs"<br />
----<br />
<br />
In order to actually use our greedy packer we must call it from our "main"<br />
function, so let's add a lines:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
main = do ...<br />
-- compute solution and print it<br />
putStrLn "Solution:" ; print (greedy_pack dirs)<br />
</haskell><br />
<br />
Verify integrity of our definitions by (re)loading our code in ghci. Compiles?<br />
Thought so :) Now, do "darcs record" and add some sensible commit message.<br />
<br />
Now it is time to test our creation. We could do it by actually running it in<br />
the wild like this:<br />
<br />
$ du -sb ~/DOWNLOADS/* | runhaskell ./cd-fit.hs<br />
<br />
This will prove that our code seems to be working. At least, this once. How<br />
about establishing with reasonable degree of certainty that our code, parts<br />
and the whole, works properly, and doing so in re-usable manner? In other<br />
words, how about writing some test?<br />
<br />
Java programmers used to JUnit probably thought about screens of boiler-plate<br />
code and hand-coded method invocations. Never fear, we will not do anything as<br />
silly :)<br />
<br />
Enter '''[[QuickCheck]]'''.<br />
<br />
[[QuickCheck]] is a tool to do automated testing of your functions using<br />
(semi)random input data. In the spirit of "100b of code examples is worth 1kb of<br />
praise" let's show the code for testing the following ''property'': An attempt to pack directories returned by "greedy_pack" should return "DirPack" of exactly the same pack:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
import Test.QuickCheck<br />
import Control.Monad (liftM2, replicateM)<br />
<br />
-- We must teach QuickCheck how to generate arbitrary "Dir"s<br />
instance Arbitrary Dir where<br />
-- Let's just skip "coarbitrary" for now, ok? <br />
-- I promise, we will get back to it later :)<br />
coarbitrary = undefined<br />
-- We generate arbitrary "Dir" by generating random size and random name<br />
-- and stuffing them inside "Dir"<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM n (elements "fubar/")<br />
<br />
-- For convenience and by tradition, all QuickCheck tests begin with prefix "prop_".<br />
-- Assume that "ds" will be a random list of "Dir"s and code your test.<br />
prop_greedy_pack_is_fixpoint ds =<br />
let pack = greedy_pack ds <br />
in pack_size pack == pack_size (greedy_pack (dirs pack))<br />
</haskell><br />
<br />
let's run the test, after which I'll explain how it all works:<br />
<br />
Prelude> :r<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> quickCheck prop_greedy_pack_is_fixpoint<br />
[numbers spinning]<br />
OK, passed 100 tests.<br />
*Main> <br />
<br />
We've just seen our "greedy_pack" run on a 100 completely (well, almost<br />
completely) random lists of "Dir"s, and it seems that property indeed holds.<br />
<br />
let's dissect the code. The most intriguing part is "instance Arbitrary Dir<br />
where", which declares that "Dir" is an '''[[instance]]''' of '''type[[class]]''' "Arbitrary". Whoa, that's a whole lot of unknown words! :) Let's slow down a<br />
bit. <br />
<br />
What is a '''type[[class]]'''? A typeclass is a Haskell way of dealing with the<br />
following situation: suppose that you are writing a library of useful<br />
functions and you don't know in advance how exactly they will be used, so you<br />
want to make them generic. Now, on one hand you don't want to restrict your<br />
users to certain type (e.g. String). On the other hand, you want to enforce<br />
the convention that arguments for your function must satisfy a certain set of<br />
constraints. That is where '''typeclass''' comes in handy. <br />
<br />
Think of typeclass as a '''contract''' (or "interface", in Java terms) that<br />
your type must fulfill in order to be admitted as an argument to certain<br />
functions. <br />
<br />
Let's examine the typeclass "Arbitrary":<br />
<br />
*Main> :i Arbitrary<br />
class Arbitrary a where<br />
arbitrary :: Gen a<br />
coarbitrary :: a -> Gen b -> Gen b<br />
-- Imported from Test.QuickCheck<br />
instance Arbitrary Dir<br />
-- Defined at ./cd-fit.hs:61:0<br />
instance Arbitrary Bool -- Imported from Test.QuickCheck<br />
instance Arbitrary Double -- Imported from Test.QuickCheck<br />
instance Arbitrary Float -- Imported from Test.QuickCheck<br />
instance Arbitrary Int -- Imported from Test.QuickCheck<br />
instance Arbitrary Integer -- Imported from Test.QuickCheck<br />
-- rest skipped --<br />
<br />
It could be read this way: "Any [[type]] (let's name it 'a') could be a member of the [[class]] Arbitrary as soon as we define two functions for it: "arbitrary" and "coarbitrary", with signatures shown. For types Dir, Bool, Double, Float, Int and Integer such definitions were provided, so all those types are instance of class Arbitrary".<br />
<br />
Now, if you write a function which operates on its arguments solely by means<br />
of "arbitrary" and "coarbitrary", you can be sure that this function will work<br />
on any type which is an instance of "Arbitrary"!<br />
<br />
let's say it again. Someone (maybe even you) writes the code (API or library),<br />
which requires that input values implement certain ''interfaces'', which is<br />
described in terms of functions. Once you show how your type implements this<br />
''interface'' you are free to use API or library.<br />
<br />
Consider the function "sort" from standard library:<br />
<br />
*Main> :t Data.List.sort<br />
Data.List.sort :: (Ord a) => [a] -> [a]<br />
<br />
We see that it sorts lists of any values which are instance of typeclass<br />
"Ord". Let's examine that class:<br />
<br />
*Main> :i Ord<br />
class Eq a => Ord a where<br />
compare :: a -> a -> Ordering<br />
(<) :: a -> a -> Bool<br />
(>=) :: a -> a -> Bool<br />
(>) :: a -> a -> Bool<br />
(<=) :: a -> a -> Bool<br />
max :: a -> a -> a<br />
min :: a -> a -> a<br />
-- skip<br />
instance Ord Double -- Imported from GHC.Float<br />
instance Ord Float -- Imported from GHC.Float<br />
instance Ord Bool -- Imported from GHC.Base<br />
instance Ord Char -- Imported from GHC.Base<br />
instance Ord Integer -- Imported from GHC.Num<br />
instance Ord Int -- Imported from GHC.Base<br />
-- skip<br />
*Main> <br />
<br />
We see a couple of interesting things: first, there is an additional<br />
requirement listed: in order to be an instance of "Ord", type must first be an<br />
instance of typeclass "Eq". Then, we see that there is an awful lot of<br />
functions to define in order to be an instance of "Ord". Wait a second, isn't<br />
it silly to define both (<) and (>) when one could be expressed via another? <br />
<br />
Right you are! Usually, typeclass contains several "default" implementation<br />
for its functions, when it is possible to express them through each other (as<br />
it is with "Ord"). In this case it is possible to supply only a minimal<br />
definition (which in case of "Ord" consists of any single function) and others<br />
will be automatically derived. If you supplied fewer functions than are required<br />
for minimal implementation, the compiler/interpreter will say so and<br />
explain which functions you still have to define.<br />
<br />
Once again, we see that a lot of [[type]]s are already instances of typeclass Ord, and thus we are able to sort them.<br />
<br />
Now, let's take a look back to the definition of "Dir":<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
See that "[[deriving]]" clause? It instructs the compiler to automatically derive code to make "Dir" an instance of typeclass Show. The compiler knows about a bunch of standard typeclasses (Eq, Ord, Show, Enum, Bound, Typeable to name a few) and knows how to make a type into a "suitably good" instance of any of them. If you want to derive instances of more than one typeclass, say it this way: "deriving (Eq,Ord,Show)". Voila! Now we can compare, sort and print data of<br />
that type!<br />
<br />
Side note for Java programmers: just imagine java compiler which derives code<br />
for "implements Storable" for you...<br />
<br />
Side note for C++ programmers: just imagine that deep copy constructors are<br />
being written for you by compiler....<br />
<br />
----<br />
'''Exercises:'''<br />
* Examine typeclasses Eq and Show<br />
* Examine types of (==) and "print"<br />
* Try to make "Dir" instance of "Eq"<br />
----<br />
<br />
OK, back to our tests. So, what we have had to do in order to make "Dir" an<br />
instance of "Arbitrary"? Minimal definition consists of "arbitrary". Let's<br />
examine it up close:<br />
<br />
*Main> :t arbitrary<br />
arbitrary :: (Arbitrary a) => Gen a<br />
<br />
See that "Gen a"? Reminds you of something? Right! Think of "IO a" and "Parser<br />
a" which we've seen already. This is yet another example of action-returning<br />
function, which could be used inside "do"-notation. (You might ask yourself,<br />
wouldn't it be useful to generalize that convenient concept of actions and<br />
"do"? Of course! It is already done, the concept is called "[[Monad]]" and we will talk about it in Chapter 400 :) )<br />
<br />
Since 'a' here is a [[type variable]] which is an instance of "Arbitrary", we could substitute "Dir" here. So, how we can make and return an action of type "Gen Dir"?<br />
<br />
Let's look at the code:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM n (elements "fubar/")<br />
</haskell><br />
<br />
We have used the library-provided functions "choose" and "elements" to build up<br />
"gen_size :: Gen Int" and "gen_name :: Gen String" (exercise: don't take my<br />
word on that. Find a way to check types of "gen_name" and "gen_size"). Since<br />
"Int" and "String" are components of "Dir", we sure must be able to use "Gen<br />
Int" and "Gen String" to build "Gen Dir". But where is the "do" block for<br />
that? There is none, and there is only single call to "liftM2". <br />
<br />
Let's examine it:<br />
<br />
*Main> :t liftM2<br />
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r<br />
<br />
Kind of scary, right? Let's provide typechecker with more context:<br />
<br />
*Main> :t liftM2 Dir<br />
liftM2 Dir :: (Monad m) => m Int -> m String -> m Dir<br />
<br />
Since you already heard that "Gen" is a "Monad", you could substitute "Gen" for "m" here, obtaining "liftM2 Dir :: (Monad Gen) => Gen Int -> Gen String -><br />
Gen Dir". Exactly what we wanted!<br />
<br />
Consider "liftM2" to be "advanced topic" of this chapter (which we will cover<br />
later) and just note for now that:<br />
* "2" is a number of arguments for data constructor "Dir" and we have used "liftM2" to construct "Gen Dir" out of "Dir"<br />
* There are also "liftM", "liftM3", "liftM4", "liftM5"<br />
* "liftM2" is defined as "liftM2 f a1 a2 = do x<-a1; y<-a2; return (f x y)"<br />
<br />
Hopefully, this will all make sense after you read it for the third<br />
time ;)<br />
<br />
Oh, by the way - don't forget to "darcs record" your changes!<br />
<br />
== Chapter 4: REALLY packing the knapsack this time == <br />
<br />
In this chapter we are going to write another not-so-trivial packing<br />
method, compare packing methods efficiency, and learn something new<br />
about debugging and profiling of the Haskell programs along the way.<br />
<br />
It might not be immediately obvious whether our packing algorithm is<br />
effective, and if yes - in which particular way? Whether it's runtime,<br />
memory consumption or result are of sufficient quality, are there any<br />
alternative algorithms, and how do they compare to each other?<br />
<br />
Let's code another solution to the knapsack packing problem, called the "dynamic programming method" and put both variants to the test.<br />
<br />
This time, I'll not dissect the listing and explain it bit by bit. Instead, comments are provided in the code:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-1.hs'<br />
----------------------------------------------------------------------------------<br />
-- Dynamic programming solution to the knapsack (or, rather, disk) packing problem<br />
--<br />
-- Let the `bestDisk x' be the "most tightly packed" disk of total <br />
-- size no more than `x'.<br />
precomputeDisksFor :: [Dir] -> [DirPack]<br />
precomputeDisksFor dirs = <br />
-- By calculating `bestDisk' for all possible disk sizes, we could<br />
-- obtain a solution for particular case by simple lookup in our list of<br />
-- solutions :)<br />
let precomp = map bestDisk [0..] <br />
<br />
-- How to calculate `bestDisk'? Lets opt for a recursive definition:<br />
-- Recursion base: best packed disk of size 0 is empty<br />
bestDisk 0 = DirPack 0 []<br />
-- Recursion step: for size `limit`, bigger than 0, best packed disk is<br />
-- computed as follows:<br />
bestDisk limit = <br />
-- 1. Take all non-empty dirs that could possibly fit to that disk by itself.<br />
-- Consider them one by one. Let the size of particular dir be `dir_size d'.<br />
-- Let's add it to the best-packed disk of size <= (limit - dir_size d), thus<br />
-- producing the disk of size <= limit. Lets do that for all "candidate"<br />
-- dirs that are not yet on our disk:<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(limit - dir_size d)<br />
, d `notElem` ds<br />
] of<br />
-- We either fail to add any dirs (probably, because all of them too big).<br />
-- Well, just report that disk must be left empty:<br />
[] -> DirPack 0 []<br />
-- Or we produce some alternative packings. Let's choose the best of them all:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
in precomp<br />
<br />
-- When we precomputed disk of all possible sizes for the given set of dirs, solution to <br />
-- particular problem is simple: just take the solution for the required 'media_size' and<br />
-- that's it!<br />
dynamic_pack dirs = (precomputeDisksFor dirs)!!media_size<br />
</haskell><br />
<br />
Notice that it took almost the same amount of text to describe algorithm and to write implementation for it. Nice, eh?<br />
<br />
----<br />
<br />
'''Exercises:'''<br />
* Make all necessary amendments to the previously written code to make this example compile. Hints: browse modules Data.List and Data.Ix for functions that are "missing" - maybe you will find them there (use ":browse Module.Name" at ghci prompt). Have you had to define some new instances of some classes? How did you do that?<br />
* <tt>[ other_function local_binding | x <- some_list, x > 0, let local_binding = some_function x ]</tt> is called a "list comprehension". This is another example of "syntactic sugar", which could lead to nicely readable code, but, when abused, could lead to syntactic caries :) Do you understand what does this sample do: <tt>let solve x = [ y | x <- [0..], y<-[0..], y == x * x ]</tt>? Could write (with help of decent tutorial) write de-sugared version of this? (Yes, I know that finding a square root does not require list traversals, but for the sake of self-education try and do it)<br />
* Notice that in order to code quite complex implementation of <tt>precomputeDisksFor</tt> we split it up in several smaller pieces and put them as a '''local bindings''' inside '''let''' clause.<br />
* Notice that we use '''pattern matching''' to both define <tt>bestKnap</tt> on case-by-case basis and to "peer into" ('''de-construct''') <tt>DirPack</tt> in the <tt>let (DirPack s ds)=precomp!!(limit - dir_size d)</tt> line<br />
* Notice how we use function composition to compose complex condition to filter the list of dirs<br />
<br />
---- <br />
<br />
Before we move any further, let's do a small cosmetic change to our<br />
code. Right now our solution uses 'Int' to store directory size. In<br />
Haskell, 'Int' is a platform-dependent integer, which imposes certain<br />
limitations on the values of this type. Attempt to compute the value<br />
of type 'Int' that exceeds the bounds will result in overflow error.<br />
Standard Haskell libraries have special typeclass<br />
<hask>Bounded</hask>, which allows to define and examine such bounds:<br />
<br />
Prelude> :i Bounded <br />
class Bounded a where<br />
minBound :: a<br />
maxBound :: a<br />
-- skip --<br />
instance Bounded Int -- Imported from GHC.Enum<br />
<br />
We see that 'Int' is indeed bounded. Let's examine the bounds:<br />
<br />
Prelude> minBound :: Int <br />
-2147483648<br />
Prelude> maxBound :: Int<br />
2147483647<br />
Prelude> <br />
<br />
Those of you who are C-literate, will spot at once that in this case<br />
the 'Int' is so-called "signed 32-bit integer", which means that we<br />
would run into errors trying to operate on directories/directory packs<br />
which are bigger than 2 GB.<br />
<br />
Luckily for us, Haskell has integers of arbitrary precision (limited<br />
only by the amount of available memory). The appropriate type is<br />
called 'Integer':<br />
<br />
Prelude> (2^50) :: Int<br />
0 -- overflow<br />
Prelude> (2^50) :: Integer<br />
1125899906842624 -- no overflow<br />
Prelude><br />
<br />
Lets change definitions of 'Dir' and 'DirPack' to allow for bigger<br />
directory sizes:<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
data Dir = Dir {dir_size::Integer, dir_name::String} deriving (Eq,Show)<br />
data DirPack = DirPack {pack_size::Integer, dirs::[Dir]} deriving Show<br />
</haskell><br />
<br />
Try to compile the code or load it into ghci. You will get the<br />
following errors:<br />
<br />
cd-fit-4-2.hs:73:79:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the expression: limit - (dir_size d)<br />
In the second argument of `(!!)', namely `(limit - (dir_size d))'<br />
<br />
cd-fit-4-2.hs:89:47:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the second argument of `(!!)', namely `media_size'<br />
In the definition of `dynamic_pack':<br />
dynamic_pack dirs = (precomputeDisksFor dirs) !! media_size<br />
<br />
<br />
It seems like Haskell have some troubles using 'Integer' with '(!!)'.<br />
Let's see why:<br />
<br />
Prelude> :t (!!)<br />
(!!) :: [a] -> Int -> a<br />
<br />
Seems like definition of '(!!)' demands that index will be 'Int', not<br />
'Integer'. Haskell never converts any type to some other type<br />
automatically - programmer have to explicitly ask for that.<br />
<br />
I will not repeat the section "Standard Haskell Classes" from<br />
[http://haskell.org/onlinereport/basic.html the Haskell Report] and<br />
explain, why typeclasses for various numbers organized the way they<br />
are organized. I will just say that standard typeclass<br />
<hask>Num</hask> demands that numeric types implement method<br />
<hask>fromInteger</hask>:<br />
<br />
Prelude> :i Num<br />
class (Eq a, Show a) => Num a where<br />
(+) :: a -> a -> a<br />
(*) :: a -> a -> a<br />
(-) :: a -> a -> a<br />
negate :: a -> a<br />
abs :: a -> a<br />
signum :: a -> a<br />
fromInteger :: Integer -> a<br />
-- Imported from GHC.Num<br />
instance Num Float -- Imported from GHC.Float<br />
instance Num Double -- Imported from GHC.Float<br />
instance Num Integer -- Imported from GHC.Num<br />
instance Num Int -- Imported from GHC.Num<br />
<br />
We see that <hask>Integer</hask> is a member of typeclass<br />
<hask>Num</hask>, thus we could use <hask>fromInteger</hask> to make<br />
the type errors go away:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
-- snip<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
] of<br />
-- snip<br />
dynamic_pack dirs = (precomputeDisksFor dirs)!!(fromInteger media_size)<br />
-- snip<br />
</haskell><br />
<br />
Type errors went away, but careful reader will spot at once that when<br />
expression <hask>(limit - dir_size d)</hask> will exceed the bounds<br />
for <hask>Int</hask>, overflow will occur, and we will not access the<br />
correct list element. Don't worry, we will deal with this in a short while.<br />
<br />
Now, lets code the QuickCheck test for this function along the lines of the test for <tt>greedy_pack</tt>:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack ds <br />
in pack_size pack == pack_size (dynamic_pack (dirs pack))<br />
</haskell><br />
<br />
Now, lets try to run (DON'T PANIC and save all you work in other applications first!):<br />
<br />
*Main> quickCheck prop_dynamic_pack_is_fixpoint<br />
<br />
Now, you took my advice seriously, don't you? And you did have your '''Ctrl-C''' handy, didn't you? Most probably, the attempt to run the test resulted in all your memory being taken by <tt>ghci</tt> process, which you hopefully interrupted soon enough by pressing '''Ctrl-C'''.<br />
<br />
What happened? Who ate all the memory? How to debug this problem? GHC comes with profiling abilities, but we could not use them - they produce report after program terminates, and our doesn't seem to do so without consuming several terabytes of memory first. Still, there is a lot of room for maneuver.<br />
<br />
Let's see. Since we called <tt>dynamic_pack</tt> and it ate all the memory, let's not do this again. Instead, let's see what this function does and tweak it a bit to explore it's behavior.<br />
<br />
Since we already know that random lists of "Dir"s generated for our QuickCheck tests are of modest size (after all, <tt>greedy_pack</tt> munches them without significant memory consumption), the size of the input most probably is not the issue. However, <tt>dynamic_pack_is_fixpoint</tt> is building quite a huge list internally (via <tt>precomputeDisksFor</tt>). Could this be a problem?<br />
<br />
Let's turn the timing/memory stats on (":set +s" on ghci prompt) and try to peek into various elements of list returned by <tt>precomputeDisksFor</tt>:<br />
<br />
Prelude> :l cd-fit.hs<br />
Compiling Main ( cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :set +s<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 0<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.06 secs, 1277972 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.00 secs, 0 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.01 secs, 1519064 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 1000<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.03 secs, 1081808 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10000<br />
DirPack {pack_size = 0, dirs = []}<br />
(1.39 secs, 12714088 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100000<br />
Interrupted.<br />
<br />
Aha! This seems to be a problem, since computation of 100000 fails to terminate in "reasonable" time, and to think that we have tried to compute <tt>700*1024*1024</tt>th element...<br />
<br />
Lets modify our code a bit, to allow disk size to be tweaked:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-3.hs'<br />
dynamic_pack limit dirs = (precomputeDisksFor dirs)!!(fromInteger limit)<br />
<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack media_size ds <br />
in pack_size pack == pack_size (dynamic_pack media_size (dirs pack))<br />
<br />
prop_dynamic_pack_small_disk ds =<br />
let pack = dynamic_pack 50000 ds<br />
in pack_size pack == pack_size (dynamic_pack 50000 (dirs pack))<br />
<br />
-- rename "old" main to "moin"<br />
main = quickCheck prop_dynamic_pack_small_disk<br />
</haskell><br />
<br />
Compute a profiling version of you code with <tt>ghc -O --make -prof -auto-all -o cd-fit cd-fit.hs</tt> and run it like this: <br />
<br />
$ ./cd-fit +RTS -p<br />
OK, passed 100 tests.<br />
<br />
First thing, note that our code satisfies at least one simple property. Good. Now let's examine profile. Look into file "cd-fit.prof", which was produced in your current directory. <br />
<br />
Most probably, you'll see something like this:<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 2.18 secs (109 ticks @ 20 ms)<br />
total alloc = 721,433,008 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
precomputeDisksFor Main 88.1 99.8<br />
dynamic_pack Main 11.0 0.0<br />
<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
<br />
MAIN MAIN 1 0 0.0 0.0 100.0 100.0<br />
CAF Main 174 11 0.9 0.2 100.0 100.0<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 99.1 99.8<br />
dynamic_pack Main 182 200 11.0 0.0 99.1 99.8<br />
precomputeDisksFor Main 183 200 88.1 99.8 88.1 99.8<br />
main Main 180 1 0.0 0.0 0.0 0.0<br />
<br />
Examine column of "individual %alloc". As we thought, all memory was<br />
allocated within <tt>precomputeDisksFor</tt>. However, amount of<br />
memory allocated (more than 700 MB, according to the line "total<br />
alloc") seems to be a little too much for our simple task. We will dig<br />
deeper and find where we a wasting it.<br />
<br />
Let's examine memory consumption a little closer via so-called "heap<br />
profiles". Run <tt>./cd-fit +RTS -hb</tt>. This produces "biographical<br />
heap profile", which tells us how various parts of the memory were<br />
used during the program run time. Heap profile was saved to<br />
"cd-fit.hp". It is next to impossible to read and comprehend it as is,<br />
so use "hp2ps cd-fit.hp" to produce a nice PostScript picture which<br />
is worth a thousand words. View it with "gv" or "ghostview" or "full<br />
Adobe Acrobat (not Reader)". (This and subsequent pictures are<br />
'''not''' attached here).<br />
<br />
Notice that most of the graph is taken up by region marked as "VOID". <br />
This means that memory allocated was never used. Notice that there is<br />
'''no''' areas marked as "USE", "LAG" or "DRAG". Seems like our<br />
program hardly uses '''any''' of the allocated memory at all. Wait a<br />
minute! How could that be? Surely it must use something when it packs<br />
to the imaginary disks of 50000 bytes those random-generated<br />
directories which are 10 to 1400 Mb in size.... Oops. Severe size<br />
mismatch. We should have spotted it earlier, when we were timing<br />
<tt>precomputeDisksFor</tt>. Scroll back and observe how each run<br />
returned the very same result - empty directory set.<br />
<br />
Our random directories are too big, but nevertheless code spends time<br />
and memory trying to "pack" them. Obviously,<br />
<tt>precomputeDisksFor</tt> (which is responsible for 90% of total<br />
memory consumption and run time) is flawed in some way.<br />
<br />
Let's take a closer look at what takes up so much memory. Run<br />
<tt>./cd-fit +RTS -h -hbvoid</tt> and produce PostScript picture for<br />
this memory profile. This will give us detailed breakdown of all<br />
memory whose "biography" shows that it's been "VOID" (unused). My<br />
picture (and I presume that yours as well) shows that VOID memory<br />
comprises of "thunks" labeled "precomputeDisksFor/pre...". We could<br />
safely assume that second word would be "precomp" (You wonder why?<br />
Look again at the code and try to find function named "pre.*" which is<br />
called from inside <tt>precomputeDisksFor</tt>)<br />
<br />
This means that memory has been taken by the list generated inside<br />
"precomp". Rumor has it that memory leaks with Haskell are caused by<br />
either too little laziness or too much laziness. It seems like we have<br />
too little laziness here: we evaluate more elements of the list that<br />
we actually need and keep them from being garbage-collected. <br />
<br />
Note how we look up element from "precomp" in this piece of code:<br />
<br />
<haskell><br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
</haskell><br />
<br />
<br />
Obviously, the whole list generated by "precomp" must be kept in<br />
memory for such lookups, since we can't be sure that some element<br />
could be garbage collected and will not be needed again.<br />
<br />
Let's rewrite the code to eliminate the list (incidentally, this will also deal with the possible Int overflow while accessing the "precomp" via (!!) operator):<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-4.hs'<br />
-- Let the `bestDisk x' be the "most tightly packed" disk of total <br />
-- size no more than `x'.<br />
-- How to calculate `bestDisk'? Lets opt for a recursive definition:<br />
-- Recursion base: best packed disk of size 0 is empty and best-packed<br />
-- disk for empty list of directories on it is also empty.<br />
bestDisk 0 _ = DirPack 0 []<br />
bestDisk _ [] = DirPack 0 []<br />
-- Recursion step: for size `limit`, bigger than 0, best packed disk is<br />
-- computed as follows:<br />
bestDisk limit dirs =<br />
-- Take all non-empty dirs that could possibly fit to that disk by itself.<br />
-- Consider them one by one. Let the size of particular dir be `dir_size d'.<br />
-- Let's add it to the best-packed disk of size <= (limit - dir_size d), thus<br />
-- producing the disk of size <= limit. Lets do that for all "candidate"<br />
-- dirs that are not yet on our disk:<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) dirs <br />
, d `notElem` ds<br />
] of<br />
-- We either fail to add any dirs (probably, because all of them too big).<br />
-- Well, just report that disk must be left empty:<br />
[] -> DirPack 0 []<br />
-- Or we produce some alternative packings. Let's choose the best of them all:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
dynamic_pack limit dirs = bestDisk limit dirs<br />
</haskell><br />
<br />
<br />
Compile the profiling version of this code and obtain the overall<br />
execution profile (with "+RTS -p"). You'll get something like this:<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 0.00 secs (0 ticks @ 20 ms)<br />
total alloc = 1,129,520 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
CAF GHC.Float 0.0 4.4<br />
main Main 0.0 93.9<br />
<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
MAIN MAIN 1 0 0.0 0.0 0.0 100.0<br />
main Main 180 1 0.0 93.9 0.0 94.2<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 0.0 0.3<br />
dynamic_pack Main 182 200 0.0 0.2 0.0 0.3<br />
bestDisk Main 183 200 0.0 0.1 0.0 0.1<br />
<br />
We achieved the major improvement: memory consumption is reduced by factor<br />
of 700! Now we could test the code on the "real task" - change the<br />
code to run the test for packing the full-sized disk:<br />
<br />
<haskell><br />
main = quickCheck prop_dynamic_pack_is_fixpoint<br />
</haskell><br />
<br />
Compile with profiling and run (with "+RTS -p"). If you are not lucky<br />
and a considerably big test set would be randomly generated for your<br />
runs, you'll have to wait. And wait even more. And more.<br />
<br />
Go make some tea. Drink it. Read some Tolstoi (Do you have "War and<br />
peace" handy?). Chances are that by the time you are done with<br />
Tolstoi, program will still be running (just take my word on it, don't<br />
check).<br />
<br />
If you are lucky, your program will finish fast enough and leave you<br />
with profile. According to a profile, program spends 99% of its time<br />
inside <tt>bestDisk</tt>. Could we speed up <tt>bestDisk</tt> somehow?<br />
<br />
Note that <tt>bestDisk</tt> performs several simple calculation for<br />
which it must call itself. However, it is done rather inefficiently -<br />
each time we pass to <tt>bestDisk</tt> the exact same set of<br />
directories as it was called with, even if we have already "packed"<br />
some of them. Let's amend this:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| let small_enough = filter ( (inRange (0,limit)).dir_size ) dirs<br />
, d <- small_enough<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) (delete d small_enough)<br />
] of<br />
</haskell><br />
<br />
Recompile and run again. Runtimes could be lengthy, but bearable, and<br />
number of times <tt>bestDisk</tt> is called (according to the profile)<br />
should decrease significantly. <br />
<br />
Finally, let's compare both packing algorithms. Intuitively, we feel<br />
that greedy algorithm should produce worse results, don't we? Lets put<br />
this feeling to the test:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
prop_greedy_pack_is_no_better_than_dynamic_pack ds =<br />
pack_size (greedy_pack ds) <= pack_size (dynamic_pack media_size ds)<br />
</haskell><br />
<br />
Verify that it is indeed so by running <tt>quickCheck</tt> for this<br />
test several time. I feel that this concludes our knapsacking<br />
exercises. <br />
<br />
Adventurous readers could continue further by implementing so-called<br />
"scaling" for <tt>dynamic_pack</tt> where we divide all directory<br />
sizes and medium size by the size of the smallest directory to proceed<br />
with smaller numbers (which promises faster runtimes).<br />
<br />
== Chapter 5: (Ab)using monads and destructing constructors for fun and profit ==<br />
<br />
We already mentioned monads quite a few times. They are described in<br />
numerous articles and tutorial (See Chapter 400). It's hard to read a<br />
daily dose of any Haskell mailing list and not to come across a word<br />
"monad" a dozen times.<br />
<br />
Since we already made quite a progress with Haskell, it's time we<br />
revisit the monads once again. I will let the other sources teach you<br />
theory behind the monads, overall usefulness of the concept, etc.<br />
Instead, I will focus on providing you with examples.<br />
<br />
Let's take a part of the real world program which involves XML<br />
processing. We will work with XML tag attributes, which are<br />
essentially named values:<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
type Attribute = (Name, AttValue)<br />
</haskell><br />
<br />
'Name' is a plain string, and value could be '''either''' string or<br />
references (also strings) to another attributes which holds the actual<br />
value (now, this is not a valid XML thing, but for the sake of<br />
providing a nice example, let's accept this). Word "either" suggests<br />
that we use 'Either' datatype:<br />
<haskell><br />
type AttValue = Either Value [Reference]<br />
type Name = String<br />
type Value = String<br />
type Reference = String<br />
<br />
-- Sample list of simple attributes:<br />
simple_attrs = [ ( "xml:lang", Left "en" )<br />
, ( "xmlns", Left "jabber:client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
<br />
-- Sample list of attributes with references:<br />
complex_attrs = [ ( "xml:lang", Right ["lang"] )<br />
, ( "lang", Left "en" )<br />
, ( "xmlns", Right ["ns","subns"] )<br />
, ( "ns", Left "jabber" )<br />
, ( "subns", Left "client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
</haskell><br />
<br />
'''Our task is:''' to write a function that will look up a value of<br />
attribute by it's name from the given list of attributes. When<br />
attribute contains reference(s), we resolve them (looking for the<br />
referenced attribute in the same list) and concatenate their values,<br />
separated by semicolon. Thus, lookup of attribute "xmlns" form both<br />
sample sets of attributes should return the same value.<br />
<br />
Following the example set by the <hask>Data.List.lookup</hask> from<br />
the standard libraries, we will call our function<br />
<hask>lookupAttr</hask> and it will return <hask>Maybe Value</hask>,<br />
allowing for lookup errors:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
-- Since we dont have code for 'lookupAttr', but want<br />
-- to compile code already, we use the function 'undefined' to<br />
-- provide default, "always-fail-with-runtime-error" function body.<br />
lookupAttr = undefined<br />
</haskell><br />
<br />
Let's try to code <hask>lookupAttr</hask> using <hask>lookup</hask> in<br />
a very straightforward way:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
import Data.List<br />
<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
lookupAttr nm attrs = <br />
-- First, we lookup 'Maybe AttValue' by name and<br />
-- check whether we are successful:<br />
case (lookup nm attrs) of<br />
-- Pass the lookup error through.<br />
Nothing -> Nothing <br />
-- If given name exist, see if it is value of reference:<br />
Just attv -> case attv of<br />
-- It's a value. Return it!<br />
Left val -> Just val<br />
-- It's a list of references :(<br />
-- We have to look them up, accounting for<br />
-- possible failures.<br />
-- First, we will perform lookup of all references ...<br />
Right refs -> <br />
let vals = [ lookupAttr ref attrs | ref <- refs ]<br />
-- .. then, we will exclude lookup failures<br />
wo_failures = filter (/=Nothing) vals<br />
-- ... find a way to remove annoying 'Just' wrapper<br />
stripJust (Just v) = v<br />
-- ... use it to extract all lookup results as strings<br />
strings = map stripJust wo_failures<br />
in<br />
-- ... finally, combine them into single String. <br />
-- If all lookups failed, we should pass failure to caller.<br />
case null strings of<br />
True -> Nothing<br />
False -> Just (concat (intersperse ":" strings))<br />
</haskell><br />
<br />
Testing:<br />
<br />
*Main> lookupAttr "xmlns" complex_attrs<br />
Just "jabber:client"<br />
*Main> lookupAttr "xmlns" simple_attrs<br />
Just "jabber:client"<br />
*Main><br />
<br />
It works, but ... It seems strange that such a boatload of code<br />
required for quite simple task. If you examine the code closely,<br />
you'll see that the code bloat is caused by:<br />
<br />
* the fact that after each step we check whether the error occurred<br />
<br />
* unwrapping Strings from <hask>Maybe</hask> and <hask>Either</hask> data constructors and wrapping them back.<br />
<br />
At this point C++/Java programmers would say that since we just pass<br />
errors upstream, all those cases could be replaced by the single "try<br />
... catch ..." block, and they would be right. Does this mean that<br />
Haskell programmers are reduced to using "case"s, which were already<br />
obsolete 10 years ago?<br />
<br />
Monads to the rescue! As you can read elsewhere (see section 400),<br />
monads are used in advanced ways to construct computations from other<br />
computations. Just what we need - we want to combine several simple<br />
steps (lookup value, lookup reference, ...) into function<br />
<hask>lookupAttr</hask> in a way that would take into account possible<br />
failures.<br />
<br />
Lets start from the code and dissect in afterwards:<br />
<haskell><br />
-- Taken from 'chapter5-2.hs'<br />
import Control.Monad<br />
<br />
lookupAttr' nm attrs = do<br />
-- First, we lookup 'AttValue' by name<br />
attv <- lookup nm attrs<br />
-- See if it is value of reference:<br />
case attv of<br />
-- It's a value. Return it!<br />
Left val -> Just val<br />
-- It's a list of references :(<br />
-- We have to look them up, accounting for<br />
-- possible failures.<br />
-- First, we will perform lookup of all references ...<br />
Right refs -> do vals <- sequence $ map (flip lookupAttr' attrs) refs<br />
-- ... since all failures are already excluded by "monad magic",<br />
-- ... all all 'Just's have been removed likewise,<br />
-- ... we just combine values into single String,<br />
-- ... and return failure if it is empty. <br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
'''Exercise''': compile the code, test that <hask>lookupAttr</hask><br />
and <hask>lookupAttr'</hask> really behave in the same way. Try to<br />
write a QuickCheck test for that, defining the <br />
<hask>instance Arbitrary Name</hask> such that arbitrary names will be taken from<br />
names available in <hask>simple_attrs</hask>.<br />
<br />
Well, back to the story. Noticed the drastic reduction in code size?<br />
If you drop comments, the code will occupy mere 7 lines instead of 13<br />
- almost two-fold reduction. How we achieved this?<br />
<br />
First, notice that we never ever check whether some computation<br />
returns <hask>Nothing</hask> anymore. Yet, try to lookup some<br />
non-existing attribute name, and <hask>lookupAttr'</hask> will return<br />
<hask>Nothing</hask>. How does this happen? Secret lies in the fact<br />
that type constructor <hask>Maybe</hask> is a "monad".<br />
<br />
We use keyword <hask>do</hask> to indicate that following block of<br />
code is a sequence of '''monadic actions''', where '''monadic magic'''<br />
have to happen when we use '<-', 'return' or move from one action to<br />
another.<br />
<br />
Different monads have different '''magic'''. Library code says that<br />
type constructor <hask>Maybe</hask> is such a monad that we could use<br />
<hask><-</hask> to "extract" values from wrapper <hask>Just</hask> and<br />
use <hask>return</hask> to put them back in form of<br />
<hask>Just some_value</hask>. When we move from one action in the "do" block to<br />
another a check happens. If the action returned <hask>Nothing</hask>,<br />
all subsequent computations will be skipped and the whole "do" block<br />
will return <hask>Nothing</hask>.<br />
<br />
Try this to understand it all better:<br />
<haskell><br />
*Main> let foo x = do v <- x; return (v+1) in foo (Just 5)<br />
Just 6<br />
*Main> let foo x = do v <- x; return (v+1) in foo Nothing <br />
Nothing<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo (Just 'a')<br />
Just 97<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo Nothing <br />
Nothing<br />
*Main> <br />
</haskell><br />
<br />
Do not mind <hask>sequence</hask> and <hask>guard</hask> just for now<br />
- we will get to them in the little while.<br />
<br />
Since we already removed one reason for code bloat, it is time to deal<br />
with the other one. Notice that we have to use <hask>case</hask> to<br />
'''deconstruct''' the value of type <hask>Either Value<br />
[Reference]</hask>. Surely we are not the first to do this, and such<br />
use case have to be quite a common one. <br />
<br />
Indeed, there is a simple remedy for our case, and it is called<br />
<hask>either</hask>:<br />
<br />
*Main> :t either<br />
either :: (a -> c) -> (b -> c) -> Either a b -> c<br />
<br />
Scary type signature, but here are examples to help you grok it:<br />
<br />
*Main> :t either (+1) (length) <br />
either (+1) (length) :: Either Int [a] -> Int<br />
*Main> either (+1) (length) (Left 5)<br />
6<br />
*Main> either (+1) (length) (Right "foo")<br />
3<br />
*Main> <br />
<br />
Seems like this is exactly our case. Let's replace the<br />
<hask>case</hask> with invocation of <hask>either</hask>:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-3.hs'<br />
lookupAttr'' nm attrs = do<br />
attv <- lookup nm attrs<br />
either Just (dereference attrs) attv<br />
where<br />
dereference attrs refs = do <br />
vals <- sequence $ map (flip lookupAttr'' attrs) refs<br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
It keeps getting better and better :)<br />
<br />
Now, as semi-exercise, try to understand the meaning of "sequence",<br />
"guard" and "flip" looking at the following ghci sessions:<br />
<br />
*Main> :t sequence<br />
sequence :: (Monad m) => [m a] -> m [a]<br />
*Main> :t [Just 'a', Just 'b', Nothing, Just 'c']<br />
[Just 'a', Just 'b', Nothing, Just 'c'] :: [Maybe Char]<br />
*Main> :t sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
sequence [Just 'a', Just 'b', Nothing, Just 'c'] :: Maybe [Char]<br />
<br />
*Main> sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b', Nothing]<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b']<br />
Just "ab"<br />
<br />
*Main> :t [putStrLn "a", putStrLn "b"]<br />
[putStrLn "a", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", putStrLn "b"]<br />
sequence [putStrLn "a", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", putStrLn "b"]<br />
a<br />
b<br />
<br />
*Main> :t [putStrLn "a", fail "stop here", putStrLn "b"]<br />
[putStrLn "a", fail "stop here", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
sequence [putStrLn "a", fail "stop here", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
a<br />
*** Exception: user error (stop here)<br />
<br />
Notice that for monad <hask>Maybe</hask> sequence continues execution<br />
until the first <hask>Nothing</hask>. The same behavior could be<br />
observed for IO monad. Take into account that different behaviors are<br />
not hardcoded into the definition of <hask>sequence</hask>!<br />
<br />
Now, let's examine <hask>guard</hask>:<br />
<br />
*Main> let foo x = do v <- x; guard (v/=5); return (v+1) in map foo [Just 4, Just 5, Just 6] <br />
[Just 5,Nothing,Just 7]<br />
<br />
As you can see, it's just a simple way to "stop" execution at some<br />
condition.<br />
<br />
If you have been hooked on monads, I urge you to read "All About<br />
Monads" right now (link in Chapter 400).<br />
<br />
== Chapter 6: Where do you want to go tomorrow? ==<br />
<br />
As the name implies, the author is open for proposals - where should<br />
we go next? I had networking + xml/xmpp in mind, but it might be too<br />
heavy and too narrow for most of the readers.<br />
<br />
What do you think? Drop me a line.<br />
<br />
== Chapter 400: Monads up close ==<br />
<br />
Read [http://en.wikibooks.org/wiki/Haskell/Understanding_monads this wikibook chapter]. <br />
Then, read [http://horna.org.ua/books/All_About_Monads.pdf "All about monads"] (PDF).<br />
'Nuff said :)<br />
<br />
== Chapter 500: IO up close ==<br />
<br />
Shows that:<br />
<br />
<haskell><br />
c = do a <- someAction<br />
b <- someOtherAction<br />
print (bar b)<br />
print (foo a)<br />
print "done"<br />
</haskell><br />
<br />
really is just a syntax sugar for:<br />
<br />
<haskell><br />
c = someAction >>= \a -><br />
someOtherAction >>= \b -><br />
print (bar b) >><br />
print (foo a) >><br />
print "done"<br />
</haskell><br />
<br />
and explains about ">>=" and ">>". Oh wait. This was already explained<br />
in Chapter 400 :)<br />
<br />
== Chapter 9999: Installing Haskell Compiler/Interpreter and all necessary software ==<br />
<br />
Plenty of material on this on the web and this wiki. Just go get<br />
yourself installation of [[GHC]] (6.4 or above) or [[Hugs]] (v200311 or<br />
above) and "[[darcs]]", which we will use for version control.<br />
<br />
== Chapter 10000: Thanks! ==<br />
<br />
Thanks for comments, proofreading, good advice and kind words go to:<br />
Helge, alt, dottedmag, Paul Moore, Ben Rudiak-Gould, Jim Wilkinson,<br />
Andrew Zhdanov (avalez), Martin Percossi, SpellingNazi, Davor<br />
Cubranic, Brett Giles, Stdrange, Brian Chrisman, Nathan Collins,<br />
Anastasia Gornostaeva (ermine), Remi, Ptolomy, Zimbatm,<br />
HenkJanVanTuyl, Miguel, Mforbes, Kartik Agaram, Jake Luck, Ketil<br />
Malde, Mike Mimic, Jens Kubieziel.<br />
<br />
If I should have mentioned YOU and forgot - tell me so.<br />
<br />
Without you I would have stopped after Chapter 1 :)<br />
<br />
Languages: [[Haskellへのヒッチハイカーガイド|jp]], [[Es/Guía de Haskell para autoestopistas|es]]</div>Imzhttps://wiki.haskell.org/index.php?title=Hitchhikers_guide_to_Haskell&diff=39264Hitchhikers guide to Haskell2011-03-30T15:56:11Z<p>Imz: /* Chapter 1: Ubiquitous "Hello world!" and other ways to do IO in Haskell */ The pseudocode as human-language sentences: this way it's more obvious each of the 3 lines is an item of our plan, and the plan has an imperative spirit for now.</p>
<hr />
<div>== Preface: DON'T PANIC! ==<br />
[[Category:Tutorials]]<br />
Recent experiences from a few of my fellow C++/Java programmers<br />
indicate that they read various Haskell tutorials with "exponential<br />
speedup" (think about how TCP/IP session starts up). They start slow<br />
and cautious, but when they see that the first 3-5 pages do not<br />
contain "anything interesting" in terms of code and examples, they<br />
begin skipping paragraphs, then chapters, then whole pages, only to<br />
slow down - often to a complete halt - somewhere on page 50, finding<br />
themselves in the thick of concepts like "type classes", "type<br />
constructors", "monadic IO", at which point they usually panic, think<br />
of a perfectly rational excuse not to read further anymore, and<br />
happily forget this sad and scary encounter with Haskell (as human<br />
beings usually tend to forget sad and scary things).<br />
<br />
This text intends to introduce the reader to the practical aspects of Haskell<br />
from the very beginning (plans for the first chapters include: I/O, darcs,<br />
Parsec, QuickCheck, profiling and debugging, to mention a few). The reader<br />
is expected to know (where to find) at least the basics of Haskell: how to run<br />
"hugs" or "ghci", '''that layout is 2-dimensional''', etc. Other than that, we do<br />
not plan to take radical leaps, and will go one step at a time in order not to<br />
lose the reader along the way. So DON'T PANIC, take your towel with you and<br />
read along.<br />
<br />
'''In case you've skipped over the previous paragraph''', I would like<br />
to stress out once again that Haskell is sensitive to indentation and<br />
spacing, so pay attention to that during cut-n-pastes or manual<br />
alignment of code in the text editor with proportional fonts.<br />
<br />
Oh, almost forgot: author is very interested in ANY feedback. Drop him a line<br />
or a word (see [[User:Adept|Adept]] for contact info) or submit<br />
patches to the tutorial via darcs (<br />
[http://adept.linux.kiev.ua:8080/repos/hhgtth/ repository is here]) or directly to this<br />
Wiki. <br />
<br />
== Chapter 1: Ubiquitous "Hello world!" and other ways to do IO in Haskell ==<br />
<br />
Each chapter will be dedicated to one small real-life task which we will<br />
complete from the ground up.<br />
<br />
So here is the task for this chapter: in order to free up space on<br />
your hard drive for all the Haskell code you are going to write in the<br />
nearest future, you are going to archive some of the old and dusty<br />
information on CDs and DVDs. While CD (or DVD) burning itself is easy<br />
these days, it usually takes some (or quite a lot of) time to decide<br />
how to put several GB of digital photos on CD-Rs, when directories<br />
with images range from 10 to 300 Mb's in size, and you don't want to<br />
burn half-full (or half-empty) CD-Rs.<br />
<br />
So, the task is to write a program which will help us put a given<br />
collection of directories on the minimum possible amount of media,<br />
while packing the media as tightly as possible. Let's name this program<br />
"cd-fit".<br />
<br />
Oh. Wait. Let's do the usual "hello world" thing, before we forget about it,<br />
and then move on to more interesting things:<br />
<br />
<haskell><br />
-- Taken from 'hello.hs'<br />
-- From now on, a comment at the beginning of the code snippet<br />
-- will specify the file which contain the full program from<br />
-- which the snippet is taken. You can get the code from the darcs<br />
-- repository "http://adept.linux.kiev.ua:8080/repos/hhgtth" by issuing<br />
-- command "darcs get http://adept.linux.kiev.ua:8080/repos/hhgtth"<br />
module Main where<br />
main = putStrLn "Hello world!"<br />
</haskell><br />
<br />
Run it:<br />
<br />
$ runhaskell ./hello.hs<br />
Hello world!<br />
<br />
OK, we've done it. Move along now, nothing interesting here :)<br />
<br />
Any serious development must be done with the help of a version control<br />
system, and we will not make an exception. We will use the modern<br />
distributed version control system "darcs". "Modern" means that it is<br />
written in Haskell, "distributed" means that each working copy is<br />
a repository in itself.<br />
<br />
First, let's create an empty directory for all our code, and invoke<br />
"darcs init" there, which will create subdirectory "_darcs" to store<br />
all version-control-related stuff there.<br />
<br />
Fire up your favorite editor and create a new file called "cd-fit.hs"<br />
in our working directory. Now let's think for a moment about how our<br />
program will operate and express it in pseudocode:<br />
<br />
<haskell><br />
main = Read list of directories and their sizes.<br />
Decide how to fit them on CD-Rs.<br />
Print solution.<br />
</haskell><br />
<br />
Sounds reasonable? I thought so.<br />
<br />
Let's simplify our life a little and assume for now that we will<br />
compute directory sizes somewhere outside our program (for example,<br />
with "du -sb *") and read this information from stdin.<br />
Now let me convert all this to Haskell:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-1-1.hs'<br />
module Main where<br />
<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: got input " ++ input)<br />
-- compute solution and print it<br />
</haskell><br />
<br />
Not really working, but pretty close to plain English, eh? Let's stop<br />
for a moment and look more closely at what's written here line-by-line<br />
<br />
Let's begin from the top:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-1-1.hs'<br />
input <- getContents<br />
</haskell><br />
<br />
This is an example of the Haskell syntax for doing IO (namely, input). This<br />
line is an instruction to read all the information available from the stdin,<br />
return it as a single string, and bind it to the symbol "input", so we can<br />
process this string any way we want.<br />
<br />
How did I know that? Did I memorize all the functions by heart? Of course not!<br />
Each function has a type, which, along with function's name, usually tells a<br />
lot about what a function will do.<br />
<br />
Let's fire up an interactive Haskell environment and examine this function<br />
up close:<br />
<br />
$ ghci<br />
___ ___ _<br />
/ _ \ /\ /\/ __(_)<br />
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.<br />
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/<br />
\____/\/ /_/\____/|_| Type :? for help.<br />
<br />
Loading package base-1.0 ... linking ... done.<br />
Prelude> :type getContents<br />
getContents :: IO String<br />
Prelude> <br />
<br />
We see that "getContents" is a function without arguments, that will return<br />
"IO String". Prefix "IO" meant that this is an IO action. It will return<br />
String, when evaluated. Action will be evaluated as soon as we use "<-" to<br />
bind its result to some symbol.<br />
<br />
Note that "<-" is not a fancy way to assign value to variable. It is a way to<br />
evaluate (execute) IO actions, in other words - to actually do some I/O and<br />
return its result (if any). <br />
<br />
We can choose not to evaluate the action obtained from "getContents", but rather carry it around a bit and evaluate later:<br />
<br />
<haskell><br />
let x = getContents<br />
-- 300 lines of code here<br />
input <- x<br />
</haskell><br />
<br />
So, as you see, IO actions can act like an ordinary values. Suppose that we<br />
have built a list of IO actions and have found a way to execute them one by one.<br />
This would be a way to simulate imperative programming with its notion of<br />
"order of execution".<br />
<br />
Haskell allows you to do better than that. <br />
<br />
The standard language library (named "Prelude", by the way) provides<br />
us with lots of functions that return useful primitive IO actions. In<br />
order to combine them to produce an even more complex actions, we use a "do":<br />
<br />
<haskell><br />
c = do a <- someAction<br />
b <- someOtherAction<br />
print (bar b)<br />
print (foo a)<br />
putStrLn "done"<br />
</haskell><br />
<br />
Here we '''bind''' "c" to an action with the following "scenario":<br />
* '''evaluate''' action "someAction" and '''bind''' its result to "a"<br />
* then, '''evaluate''' "someOtherAction" and '''bind''' its result to "b"<br />
* then, process "b" with function "bar" and print result<br />
* then, process "a" with function "foo" and print result<br />
* then, print the word "done"<br />
<br />
When will all this actually be executed? Answer: as soon as we evaluate "c"<br />
using the "<-" (if it returns result, as "getContents" does) or just<br />
by using it as a function name (if it does not return a result, as "print"<br />
does):<br />
<br />
<haskell><br />
process = do putStrLn "Will do some processing"<br />
c<br />
putStrLn "Done"<br />
</haskell><br />
<br />
Notice that we took a bunch of functions ("someAction", "someOtherAction",<br />
"print", "putStrLn") and using "do" created from them a new function, which we<br />
bound to symbol "c". Now we could use "c" as a building block to produce an even<br />
more complex function, "process", and we could carry this on and on.<br />
Eventually, some of the functions will be mentioned in the code of function<br />
"main", to which the ultimate topmost IO action any Haskell program is bound.<br />
<br />
When will the "main" be executed/evaluated/forced? As soon as we run the<br />
program. Read this twice and try to comprehend: <br />
<br />
''The execution of a Haskell program is an evaluation of the symbol "main" to<br />
which we have bound an IO action. Via evaluation we obtain the result of that<br />
action''. <br />
<br />
Readers familiar with advanced C++ or Java programming and that arcane body of<br />
knowledge named "OOP Design Patterns" might note that "build actions from<br />
actions" and "evaluate actions to get result" is essentially a "Command<br />
pattern" and "Composition pattern" combined. Good news: in Haskell you get them<br />
for all your IO, and get them '''for free''' :)<br />
<br />
----<br />
'''Exercise:'''<br />
Consider the following code:<br />
<br />
<haskell><br />
-- Taken from 'exercise-1-1.hs'<br />
module Main where<br />
c = putStrLn "C!"<br />
<br />
combine before after =<br />
do before<br />
putStrLn "In the middle"<br />
after<br />
<br />
main = do combine c c<br />
let b = combine (putStrLn "Hello!") (putStrLn "Bye!")<br />
let d = combine (b) (combine c c)<br />
putStrLn "So long!"<br />
</haskell><br />
<br />
Notice how we carefully indent lines so that source looks neat?<br />
Actually, Haskell code has to be aligned this way, or it will not<br />
compile. If you use tabulation to indent your sources, take into<br />
account that Haskell compilers assume that tabstop is 8 characters<br />
wide.<br />
<br />
Often people complain that it is very difficult to write Haskell<br />
because it requires them to align code. Actually, this is not true. If<br />
you align your code, compiler will guess the beginnings and endings of<br />
syntactic blocks. However, if you don't want to indent your code, you<br />
could explicitly specify end of each and every expression and use<br />
arbitrary layout as in this example: <br />
<haskell><br />
-- Taken from 'exercise-1-2.hs'<br />
combine before after = <br />
do { before; <br />
putStrLn "In the middle"; <br />
after; };<br />
<br />
main = <br />
do { combine c c; let { b = combine (putStrLn "Hello!") (putStrLn "Bye!")};<br />
let {d = combine (b) (combine c c)}; <br />
putStrLn "So long!" };<br />
</haskell><br />
<br />
Back to the exercise - see how we construct code out of thin air? Try<br />
to imagine what this code will do, then run it and check yourself.<br />
<br />
Do you understand why "Hello!" and "Bye!" are not printed?<br />
----<br />
<br />
Let's examine our "main" function closer:<br />
<br />
Prelude> :load cd-fit.hs<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :type main<br />
main :: IO ()<br />
*Main> <br />
<br />
We see that "main" is indeed an IO action which will return nothing<br />
when evaluated. When combining actions with "do", the type of the<br />
result will be the type of the last action, and "putStrLn something" has type<br />
"IO ()": <br />
<br />
*Main> :type putStrLn "Hello world!"<br />
putStrLn "Hello world!" :: IO ()<br />
*Main> <br />
<br />
Oh, by the way: have you noticed that we actually compiled our first<br />
Haskell program in order to examine "main"? :)<br />
<br />
let's celebrate that by putting it under version control: execute<br />
"darcs add cd-fit.hs" and "darcs record", answer "y" to all questions<br />
and provide a commit comment "Skeleton of cd-fit.hs"<br />
<br />
Let's try to run it:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: got input foo<br />
<br />
----<br />
'''Exercises''':<br />
<br />
* Try to write a program that takes your name from the stdin and greets you (keywords: getLine, putStrLn);<br />
<br />
* Try to write a program that asks for you name, reads it, greets you, asks for your favorite color, and prints it back (keywords: getLine, putStrLn).<br />
<br />
== Chapter 2: Parsing the input ==<br />
<br />
OK, now that we have proper understanding of the powers of Haskell IO<br />
(and are awed by them, I hope), let's forget about IO and actually do<br />
some useful work. <br />
<br />
As you remember, we set forth to pack some CD-Rs as tightly as<br />
possible with data scattered in several input directories. We assume<br />
that "du -sb" will compute the sizes of input directories and output<br />
something like:<br />
<br />
65572 /home/adept/photos/raw-to-burn/dir1<br />
68268 /home/adept/photos/raw-to-burn/dir2<br />
53372 /home/adept/photos/raw-to-burn/dir3<br />
713124 /home/adept/photos/raw-to-burn/dir4<br />
437952 /home/adept/photos/raw-to-burn/dir5<br />
<br />
Our next task is to parse that input into some suitable internal<br />
representation.<br />
<br />
For that we will use powerful library of '''parsing combinators''' named<br />
"[[Parsec]]" which ships with most Haskell implementations.<br />
<br />
Much like the IO facilities we have seen in the first chapter, this<br />
library provides a set of basic parsers and means to combine into more<br />
complex parsing constructs.<br />
<br />
Unlike other tools in this area (lex/yacc or JavaCC to name a few),<br />
[[Parsec]] parsers do not require a separate preprocessing stage. Since in<br />
Haskell we can return function as a result of function and thus<br />
construct functions "from the thin air", there is no need for a separate<br />
syntax for parser description. But enough advertisements, let's actually<br />
do some parsing:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
import Text.ParserCombinators.Parsec<br />
<br />
-- parseInput parses output of "du -sb", which consists of many lines,<br />
-- each of which describes single directory<br />
parseInput = <br />
do dirs <- many dirAndSize<br />
eof<br />
return dirs<br />
<br />
-- Datatype Dir holds information about single directory - its size and name<br />
data Dir = Dir Int String deriving Show<br />
<br />
-- `dirAndSize` parses information about single directory, which is:<br />
-- a size in bytes (number), some spaces, then directory name, which extends till newline<br />
dirAndSize = <br />
do size <- many1 digit<br />
spaces<br />
dir_name <- anyChar `manyTill` newline<br />
return (Dir (read size) dir_name)<br />
</haskell><br />
<br />
Just add those lines to "cd-fit.hs", between the declaration of <br />
the Main module and the definition of main.<br />
<br />
Here we see quite a lot of new<br />
things, and several those that we know already. <br />
First of all, note the familiar "do" construct, which, as we know, is<br />
used to combine IO actions to produce new IO actions. Here we use it<br />
to combine "parsing" actions into new "parsing" actions. Does this<br />
mean that "parsing" implies "doing IO"? Not at all. Thing is, I must<br />
admit that I lied to you - "do" is used not only to combine IO<br />
actions. "Do" is used to combine any kind of so-called ''monadic<br />
actions'' or ''monadic values'' together.<br />
<br />
Think about [[monad]] as a "[[:Category:Idioms|design pattern]]" in the functional world.<br />
[[Monad]] is a way to hide from the user (programmer) all the machinery<br />
required for complex functionality to operate.<br />
<br />
As you might have heard, Haskell has no notion of "assignment",<br />
"mutable state", "variables", and is a "pure functional language",<br />
which means that every function called with the same input parameters<br />
will return exactly the same result. Meanwhile "doing IO" requires<br />
hauling around file handles and their states and dealing with IO<br />
errors. "Parsing" requires to track position in the input and dealing<br />
with parsing errors.<br />
<br />
In both cases Wise Men Who Wrote Libraries cared for our needs and<br />
hide all underlying complexities from us, exposing the [http://en.wikipedia.org/wiki/Application_programming_interface API] of their<br />
libraries (IO and parsing) in the form of "monadic action" which we<br />
are free to combine as we see fit. <br />
<br />
Think of programming with monads as of doing the remodelling with the<br />
help of professional remodelling crew. You describe sequence of<br />
actions on the piece of paper (that's us writing in "do" notation),<br />
and then, when required, that sequence will be evaluated by the<br />
remodelling crew ("in the monad") which will provide you with end<br />
result, hiding all the underlying complexity (how to prepare the<br />
paint, which nails to choose, etc) from you.<br />
<br />
let's use the interactive Haskell environment to decipher all the<br />
instructions we've written for the parsing library. As usually, we'll<br />
go top-down:<br />
<br />
*Main> :reload<br />
Ok, modules loaded: Main.<br />
*Main> :t parseInput<br />
parseInput :: GenParser Char st [Dir]<br />
*Main> :t dirAndSize<br />
dirAndSize :: GenParser Char st Dir<br />
*Main> <br />
<br />
Assuming (well, take my word for it) that "GenParser Char st" is our<br />
parsing monad, we could see that "parseInput", when evaluated, will<br />
produce a list of "Dir", and "dirAndSize", when evaluated, will<br />
produce "Dir". Assuming that "Dir" somehow represents information<br />
about single directory, that is pretty much what we wanted, isn't it?<br />
<br />
Let's see what a "Dir" means. We defined ''data[[type]]'' Dir as a record,<br />
which holds an Int and a String:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
data Dir = Dir Int String deriving Show<br />
</haskell><br />
<br />
In order to construct such records, we must use ''data [[constructor]]''<br />
Dir:<br />
<br />
*Main> :t Dir 1 "foo"<br />
Dir 1 "foo" :: Dir<br />
<br />
In order to reduce confusion for newbies, we could have written:<br />
<haskell><br />
data Dir = D Int String deriving Show<br />
</haskell><br />
<br />
, which would define ''data[[type]]'' "Dir" with ''data [[constructor]]'' "D".<br />
However, traditionally name of the data[[type]] and its [[constructor]] are<br />
chosen to be the same.<br />
<br />
Clause "[[deriving]] Show" instructs the compiler to make enough code "behind<br />
the curtains" to make this ''datatype'' conform to the interface of<br />
the ''type [[class]]'' Show. We will explain ''type [[class]]es'' later, for<br />
now let's just say that this will allow us to "print" instances of<br />
"Dir".<br />
<br />
'''Exercises:''' <br />
* examine types of "digit", "anyChar", "many", "many1" and "manyTill" to see how they are used to build more complex parsers from single ones.<br />
<br />
* compare types of "manyTill", "manyTill anyChar" and "manyTill anyChar newline". Note that "anyChar `manyTill` newline" is just another syntax sugar. Note that when function is supplied with less arguments that it actually needs, we get not a value, but a new function, which is called ''partial application''.<br />
<br />
<br />
OK. So, we combined a lot of primitive parsing actions to get ourselves a<br />
parser for output of "du -sb". How can we actually parse something? the [[Parsec]] library supplies us with function "parse":<br />
<br />
*Main> :t parse<br />
parse :: GenParser tok () a<br />
-> SourceName<br />
-> [tok]<br />
-> Either ParseError a<br />
*Main> :t parse parseInput<br />
parse parseInput :: SourceName -> [Char] -> Either ParseError [Dir]<br />
*Main> <br />
<br />
At first the [[type]] might be a bit cryptic, but once we supply "parse" with the parser we made, the compiler gets more information and presents us with a more concise [[type]].<br />
<br />
Stop and consider this for a moment. The compiler figured out type of the function without a single type annotation supplied by us! Imagine if a Java compiler deduced types for you, and you wouldn't have to specify types of arguments and return values of methods, ever.<br />
<br />
OK, back to the code. We can observe that the "parser" is a function, which,<br />
given a parser, a name of the source file or channel (f.e. "stdin"), and<br />
source data (String, which is a list of "Char"s, which is written "[Char]"),<br />
will either produce parse error, or parse us a list of "Dir".<br />
<br />
Datatype "Either" is an example of datatype whose constructor has name, different<br />
from the name of the datatype. In fact, "Either" has two constructors:<br />
<br />
<haskell><br />
data Either a b = Left a | Right b<br />
</haskell><br />
<br />
In order to understand better what does this mean consider the following<br />
example:<br />
<br />
*Main> :t Left 'a'<br />
Left 'a' :: Either Char b<br />
*Main> :t Right "aaa"<br />
Right "aaa" :: Either a [Char]<br />
*Main> <br />
<br />
You see that "Either" is a ''union'' (much like the C/C++ "union") which could<br />
hold value of one of the two distinct types. However, unlike C/C++ "union",<br />
when presented with value of type "Either Int Char" we could immediately see<br />
whether its an Int or a Char - by looking at the constructor which was used to<br />
produce the value. Such datatypes are called "tagged unions", and they are<br />
another [[:Category:Idioms|power tool]] in the Haskell toolset.<br />
<br />
Did you also notice that we provide "parse" with parser, which is a monadic<br />
value, but receive not a new monadic value, but a parsing result? That is<br />
because "parse" is an evaluator for "Parser" monad, much like the [[GHC]] or [[Hugs]] runtime is an evaluator for the IO monad. The function "parser" implements all monadic machinery: it tracks errors and positions in input, implements backtracking and lookahead, etc.<br />
<br />
let's extend our "main" function to use "parse" and actually parse the input<br />
and show us the parsed data structures:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-2-1.hs'<br />
main = do input <- getContents<br />
putStrLn ("DEBUG: got input " ++ input)<br />
let dirs = case parse parseInput "stdin" input of<br />
Left err -> error $ "Input:\n" ++ show input ++ <br />
"\nError:\n" ++ show err<br />
Right result -> result<br />
putStrLn "DEBUG: parsed:"; print dirs<br />
</haskell><br />
<br />
'''Exercise:'''<br />
<br />
* In order to understand this snippet of code better, examine (with ghci or hugs) the difference between 'drop 1 ( drop 1 ( drop 1 ( drop 1 ( drop 1 "foobar" ))))' and 'drop 1 $ drop 1 $ drop 1 $ drop 1 $ drop 1 "foobar"'. Examine type of ($).<br />
* Try putStrLn "aaa" and print "aaa" and see the difference, examine their types.<br />
* Try print (Dir 1 "foo") and putStrLn (Dir 1 "foo"). Examine types of print and putStrLn to understand the behavior in both cases.<br />
<br />
Let's try to run what we have so far:<br />
<br />
$ du -sb * | runhaskell ./cd-fit.hs<br />
<br />
DEBUG: got input 22325 Article.txt<br />
18928 Article.txt~<br />
1706 cd-fit.hs<br />
964 cd-fit.hs~<br />
61609 _darcs<br />
<br />
DEBUG: parsed:<br />
[Dir 22325 "Article.txt",Dir 18928 "Article.txt~",<br />
Dir 1706 "cd-fit.hs",Dir 964 "cd-fit.hs~",Dir 61609 "_darcs"]<br />
<br />
Seems to be doing exactly as planned. Now let's try some erroneous<br />
input:<br />
<br />
$ echo "foo" | runhaskell cd-fit.hs<br />
DEBUG: got input foo<br />
<br />
DEBUG: parsed:<br />
*** Exception: Input:<br />
"foo\n"<br />
Error:<br />
"stdin" (line 1, column 1):<br />
unexpected "f"<br />
expecting digit or end of input<br />
<br />
Seems to be doing fine. <br />
<br />
If you followed advice to put your code under version control, you<br />
could now use "darcs whatsnew" or "darcs diff -u" to examine your<br />
changes to the previous version. Use "darcs record" to commit them. As<br />
an exercise, first record the changes "outside" of function "main" and<br />
then record the changes in "main". Do "darcs changes" to examine a<br />
list of changes you've recorded so far.<br />
<br />
== Chapter 3: Packing the knapsack and testing it with class, too (and don't forget your towel!) ==<br />
<br />
Enough preliminaries already. let's go pack some CDs.<br />
<br />
As you might already have recognized, our problem is a classical one. It is<br />
called a "knapsack problem" ([http://www.google.com/search?q=knapsack+problem google it up], if you don't know already what it<br />
is. There are more than 100000 links).<br />
<br />
let's start from the greedy solution, but first let's slightly modify our "Dir"<br />
datatype to allow easy extraction of its components:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
----<br />
'''Exercise:''' examine types of "Dir", "dir_size" and "dir_name"<br />
----<br />
<br />
From now on, we could use "dir_size d" to get a size of directory, and<br />
"dir_name d" to get its name, provided that "d" is of type "Dir".<br />
<br />
The Greedy algorithm sorts directories from the biggest down, and tries to put<br />
them on CD one by one, until there is no room for more. We will need to track<br />
which directories we added to CD, so let's add another datatype, and code this<br />
simple packing algorithm:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
import Data.List (sortBy)<br />
<br />
-- DirPack holds a set of directories which are to be stored on single CD.<br />
-- 'pack_size' could be calculated, but we will store it separately to reduce<br />
-- amount of calculation<br />
data DirPack = DirPack {pack_size::Int, dirs::[Dir]} deriving Show<br />
<br />
-- For simplicity, let's assume that we deal with standard 700 Mb CDs for now<br />
media_size = 700*1024*1024<br />
<br />
-- Greedy packer tries to add directories one by one to initially empty 'DirPack'<br />
greedy_pack dirs = foldl maybe_add_dir (DirPack 0 []) $ sortBy cmpSize dirs<br />
where<br />
cmpSize d1 d2 = compare (dir_size d1) (dir_size d2)<br />
<br />
-- Helper function, which only adds directory "d" to the pack "p" when new<br />
-- total size does not exceed media_size<br />
maybe_add_dir p d =<br />
let new_size = pack_size p + dir_size d<br />
new_dirs = d:(dirs p)<br />
in if new_size > media_size then p else DirPack new_size new_dirs<br />
</haskell><br />
<br />
----<br />
I'll highlight the areas which you could explore on your own (using other nice<br />
tutorials out there, of which I especially recommend "Yet Another Haskell<br />
Tutorial" by Hal Daume):<br />
* We choose to import a single function "sortBy" from a module [[Data.List]], not the whole thing.<br />
* Instead of coding case-by-case recursive definition of "greedy_pack", we go with higher-order approach, choosing "foldl" as a vehicle for list traversal. Examine its type. Other useful function from the same category are "map", "foldr", "scanl" and "scanr". Look them up!<br />
* To sort list of "Dir" by size only, we use custom sort function and parametrized sort - "sortBy". This sort of setup where the user may provide a custom "modifier" for a generic library function is quite common: look up "deleteBy", "deleteFirstsBy", "groupBy", "insertBy", "intersectBy", "maximumBy", "minimumBy", "sortBy", "unionBy".<br />
* To code the quite complex function "maybe_add_dir", we introduced several '''local definitions''' in the "let" clause, which we can reuse within the function body. We used a "where" clause in the "greedy_pack" function to achieve the same effect. Read about "let" and "where" clauses and the differences between them.<br />
* Note that in order to construct a new value of type "DirPack" (in function "maybe_add_dir") we haven't used the helper accessor functions "pack_size" and "dirs"<br />
----<br />
<br />
In order to actually use our greedy packer we must call it from our "main"<br />
function, so let's add a lines:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-1.hs'<br />
main = do ...<br />
-- compute solution and print it<br />
putStrLn "Solution:" ; print (greedy_pack dirs)<br />
</haskell><br />
<br />
Verify integrity of our definitions by (re)loading our code in ghci. Compiles?<br />
Thought so :) Now, do "darcs record" and add some sensible commit message.<br />
<br />
Now it is time to test our creation. We could do it by actually running it in<br />
the wild like this:<br />
<br />
$ du -sb ~/DOWNLOADS/* | runhaskell ./cd-fit.hs<br />
<br />
This will prove that our code seems to be working. At least, this once. How<br />
about establishing with reasonable degree of certainty that our code, parts<br />
and the whole, works properly, and doing so in re-usable manner? In other<br />
words, how about writing some test?<br />
<br />
Java programmers used to JUnit probably thought about screens of boiler-plate<br />
code and hand-coded method invocations. Never fear, we will not do anything as<br />
silly :)<br />
<br />
Enter '''[[QuickCheck]]'''.<br />
<br />
[[QuickCheck]] is a tool to do automated testing of your functions using<br />
(semi)random input data. In the spirit of "100b of code examples is worth 1kb of<br />
praise" let's show the code for testing the following ''property'': An attempt to pack directories returned by "greedy_pack" should return "DirPack" of exactly the same pack:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
import Test.QuickCheck<br />
import Control.Monad (liftM2, replicateM)<br />
<br />
-- We must teach QuickCheck how to generate arbitrary "Dir"s<br />
instance Arbitrary Dir where<br />
-- Let's just skip "coarbitrary" for now, ok? <br />
-- I promise, we will get back to it later :)<br />
coarbitrary = undefined<br />
-- We generate arbitrary "Dir" by generating random size and random name<br />
-- and stuffing them inside "Dir"<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM n (elements "fubar/")<br />
<br />
-- For convenience and by tradition, all QuickCheck tests begin with prefix "prop_".<br />
-- Assume that "ds" will be a random list of "Dir"s and code your test.<br />
prop_greedy_pack_is_fixpoint ds =<br />
let pack = greedy_pack ds <br />
in pack_size pack == pack_size (greedy_pack (dirs pack))<br />
</haskell><br />
<br />
let's run the test, after which I'll explain how it all works:<br />
<br />
Prelude> :r<br />
Compiling Main ( ./cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> quickCheck prop_greedy_pack_is_fixpoint<br />
[numbers spinning]<br />
OK, passed 100 tests.<br />
*Main> <br />
<br />
We've just seen our "greedy_pack" run on a 100 completely (well, almost<br />
completely) random lists of "Dir"s, and it seems that property indeed holds.<br />
<br />
let's dissect the code. The most intriguing part is "instance Arbitrary Dir<br />
where", which declares that "Dir" is an '''[[instance]]''' of '''type[[class]]''' "Arbitrary". Whoa, that's a whole lot of unknown words! :) Let's slow down a<br />
bit. <br />
<br />
What is a '''type[[class]]'''? A typeclass is a Haskell way of dealing with the<br />
following situation: suppose that you are writing a library of useful<br />
functions and you don't know in advance how exactly they will be used, so you<br />
want to make them generic. Now, on one hand you don't want to restrict your<br />
users to certain type (e.g. String). On the other hand, you want to enforce<br />
the convention that arguments for your function must satisfy a certain set of<br />
constraints. That is where '''typeclass''' comes in handy. <br />
<br />
Think of typeclass as a '''contract''' (or "interface", in Java terms) that<br />
your type must fulfill in order to be admitted as an argument to certain<br />
functions. <br />
<br />
Let's examine the typeclass "Arbitrary":<br />
<br />
*Main> :i Arbitrary<br />
class Arbitrary a where<br />
arbitrary :: Gen a<br />
coarbitrary :: a -> Gen b -> Gen b<br />
-- Imported from Test.QuickCheck<br />
instance Arbitrary Dir<br />
-- Defined at ./cd-fit.hs:61:0<br />
instance Arbitrary Bool -- Imported from Test.QuickCheck<br />
instance Arbitrary Double -- Imported from Test.QuickCheck<br />
instance Arbitrary Float -- Imported from Test.QuickCheck<br />
instance Arbitrary Int -- Imported from Test.QuickCheck<br />
instance Arbitrary Integer -- Imported from Test.QuickCheck<br />
-- rest skipped --<br />
<br />
It could be read this way: "Any [[type]] (let's name it 'a') could be a member of the [[class]] Arbitrary as soon as we define two functions for it: "arbitrary" and "coarbitrary", with signatures shown. For types Dir, Bool, Double, Float, Int and Integer such definitions were provided, so all those types are instance of class Arbitrary".<br />
<br />
Now, if you write a function which operates on its arguments solely by means<br />
of "arbitrary" and "coarbitrary", you can be sure that this function will work<br />
on any type which is an instance of "Arbitrary"!<br />
<br />
let's say it again. Someone (maybe even you) writes the code (API or library),<br />
which requires that input values implement certain ''interfaces'', which is<br />
described in terms of functions. Once you show how your type implements this<br />
''interface'' you are free to use API or library.<br />
<br />
Consider the function "sort" from standard library:<br />
<br />
*Main> :t Data.List.sort<br />
Data.List.sort :: (Ord a) => [a] -> [a]<br />
<br />
We see that it sorts lists of any values which are instance of typeclass<br />
"Ord". Let's examine that class:<br />
<br />
*Main> :i Ord<br />
class Eq a => Ord a where<br />
compare :: a -> a -> Ordering<br />
(<) :: a -> a -> Bool<br />
(>=) :: a -> a -> Bool<br />
(>) :: a -> a -> Bool<br />
(<=) :: a -> a -> Bool<br />
max :: a -> a -> a<br />
min :: a -> a -> a<br />
-- skip<br />
instance Ord Double -- Imported from GHC.Float<br />
instance Ord Float -- Imported from GHC.Float<br />
instance Ord Bool -- Imported from GHC.Base<br />
instance Ord Char -- Imported from GHC.Base<br />
instance Ord Integer -- Imported from GHC.Num<br />
instance Ord Int -- Imported from GHC.Base<br />
-- skip<br />
*Main> <br />
<br />
We see a couple of interesting things: first, there is an additional<br />
requirement listed: in order to be an instance of "Ord", type must first be an<br />
instance of typeclass "Eq". Then, we see that there is an awful lot of<br />
functions to define in order to be an instance of "Ord". Wait a second, isn't<br />
it silly to define both (<) and (>) when one could be expressed via another? <br />
<br />
Right you are! Usually, typeclass contains several "default" implementation<br />
for its functions, when it is possible to express them through each other (as<br />
it is with "Ord"). In this case it is possible to supply only a minimal<br />
definition (which in case of "Ord" consists of any single function) and others<br />
will be automatically derived. If you supplied fewer functions than are required<br />
for minimal implementation, the compiler/interpreter will say so and<br />
explain which functions you still have to define.<br />
<br />
Once again, we see that a lot of [[type]]s are already instances of typeclass Ord, and thus we are able to sort them.<br />
<br />
Now, let's take a look back to the definition of "Dir":<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
data Dir = Dir {dir_size::Int, dir_name::String} deriving Show<br />
</haskell><br />
<br />
See that "[[deriving]]" clause? It instructs the compiler to automatically derive code to make "Dir" an instance of typeclass Show. The compiler knows about a bunch of standard typeclasses (Eq, Ord, Show, Enum, Bound, Typeable to name a few) and knows how to make a type into a "suitably good" instance of any of them. If you want to derive instances of more than one typeclass, say it this way: "deriving (Eq,Ord,Show)". Voila! Now we can compare, sort and print data of<br />
that type!<br />
<br />
Side note for Java programmers: just imagine java compiler which derives code<br />
for "implements Storable" for you...<br />
<br />
Side note for C++ programmers: just imagine that deep copy constructors are<br />
being written for you by compiler....<br />
<br />
----<br />
'''Exercises:'''<br />
* Examine typeclasses Eq and Show<br />
* Examine types of (==) and "print"<br />
* Try to make "Dir" instance of "Eq"<br />
----<br />
<br />
OK, back to our tests. So, what we have had to do in order to make "Dir" an<br />
instance of "Arbitrary"? Minimal definition consists of "arbitrary". Let's<br />
examine it up close:<br />
<br />
*Main> :t arbitrary<br />
arbitrary :: (Arbitrary a) => Gen a<br />
<br />
See that "Gen a"? Reminds you of something? Right! Think of "IO a" and "Parser<br />
a" which we've seen already. This is yet another example of action-returning<br />
function, which could be used inside "do"-notation. (You might ask yourself,<br />
wouldn't it be useful to generalize that convenient concept of actions and<br />
"do"? Of course! It is already done, the concept is called "[[Monad]]" and we will talk about it in Chapter 400 :) )<br />
<br />
Since 'a' here is a [[type variable]] which is an instance of "Arbitrary", we could substitute "Dir" here. So, how we can make and return an action of type "Gen Dir"?<br />
<br />
Let's look at the code:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-3-2.hs'<br />
arbitrary = liftM2 Dir gen_size gen_name<br />
-- Generate random size between 10 and 1400 Mb<br />
where gen_size = do s <- choose (10,1400)<br />
return (s*1024*1024)<br />
-- Generate random name 1 to 300 chars long, consisting of symbols "fubar/" <br />
gen_name = do n <- choose (1,300)<br />
replicateM n (elements "fubar/")<br />
</haskell><br />
<br />
We have used the library-provided functions "choose" and "elements" to build up<br />
"gen_size :: Gen Int" and "gen_name :: Gen String" (exercise: don't take my<br />
word on that. Find a way to check types of "gen_name" and "gen_size"). Since<br />
"Int" and "String" are components of "Dir", we sure must be able to use "Gen<br />
Int" and "Gen String" to build "Gen Dir". But where is the "do" block for<br />
that? There is none, and there is only single call to "liftM2". <br />
<br />
Let's examine it:<br />
<br />
*Main> :t liftM2<br />
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r<br />
<br />
Kind of scary, right? Let's provide typechecker with more context:<br />
<br />
*Main> :t liftM2 Dir<br />
liftM2 Dir :: (Monad m) => m Int -> m String -> m Dir<br />
<br />
Since you already heard that "Gen" is a "Monad", you could substitute "Gen" for "m" here, obtaining "liftM2 Dir :: (Monad Gen) => Gen Int -> Gen String -><br />
Gen Dir". Exactly what we wanted!<br />
<br />
Consider "liftM2" to be "advanced topic" of this chapter (which we will cover<br />
later) and just note for now that:<br />
* "2" is a number of arguments for data constructor "Dir" and we have used "liftM2" to construct "Gen Dir" out of "Dir"<br />
* There are also "liftM", "liftM3", "liftM4", "liftM5"<br />
* "liftM2" is defined as "liftM2 f a1 a2 = do x<-a1; y<-a2; return (f x y)"<br />
<br />
Hopefully, this will all make sense after you read it for the third<br />
time ;)<br />
<br />
Oh, by the way - don't forget to "darcs record" your changes!<br />
<br />
== Chapter 4: REALLY packing the knapsack this time == <br />
<br />
In this chapter we are going to write another not-so-trivial packing<br />
method, compare packing methods efficiency, and learn something new<br />
about debugging and profiling of the Haskell programs along the way.<br />
<br />
It might not be immediately obvious whether our packing algorithm is<br />
effective, and if yes - in which particular way? Whether it's runtime,<br />
memory consumption or result are of sufficient quality, are there any<br />
alternative algorithms, and how do they compare to each other?<br />
<br />
Let's code another solution to the knapsack packing problem, called the "dynamic programming method" and put both variants to the test.<br />
<br />
This time, I'll not dissect the listing and explain it bit by bit. Instead, comments are provided in the code:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-1.hs'<br />
----------------------------------------------------------------------------------<br />
-- Dynamic programming solution to the knapsack (or, rather, disk) packing problem<br />
--<br />
-- Let the `bestDisk x' be the "most tightly packed" disk of total <br />
-- size no more than `x'.<br />
precomputeDisksFor :: [Dir] -> [DirPack]<br />
precomputeDisksFor dirs = <br />
-- By calculating `bestDisk' for all possible disk sizes, we could<br />
-- obtain a solution for particular case by simple lookup in our list of<br />
-- solutions :)<br />
let precomp = map bestDisk [0..] <br />
<br />
-- How to calculate `bestDisk'? Lets opt for a recursive definition:<br />
-- Recursion base: best packed disk of size 0 is empty<br />
bestDisk 0 = DirPack 0 []<br />
-- Recursion step: for size `limit`, bigger than 0, best packed disk is<br />
-- computed as follows:<br />
bestDisk limit = <br />
-- 1. Take all non-empty dirs that could possibly fit to that disk by itself.<br />
-- Consider them one by one. Let the size of particular dir be `dir_size d'.<br />
-- Let's add it to the best-packed disk of size <= (limit - dir_size d), thus<br />
-- producing the disk of size <= limit. Lets do that for all "candidate"<br />
-- dirs that are not yet on our disk:<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(limit - dir_size d)<br />
, d `notElem` ds<br />
] of<br />
-- We either fail to add any dirs (probably, because all of them too big).<br />
-- Well, just report that disk must be left empty:<br />
[] -> DirPack 0 []<br />
-- Or we produce some alternative packings. Let's choose the best of them all:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
in precomp<br />
<br />
-- When we precomputed disk of all possible sizes for the given set of dirs, solution to <br />
-- particular problem is simple: just take the solution for the required 'media_size' and<br />
-- that's it!<br />
dynamic_pack dirs = (precomputeDisksFor dirs)!!media_size<br />
</haskell><br />
<br />
Notice that it took almost the same amount of text to describe algorithm and to write implementation for it. Nice, eh?<br />
<br />
----<br />
<br />
'''Exercises:'''<br />
* Make all necessary amendments to the previously written code to make this example compile. Hints: browse modules Data.List and Data.Ix for functions that are "missing" - maybe you will find them there (use ":browse Module.Name" at ghci prompt). Have you had to define some new instances of some classes? How did you do that?<br />
* <tt>[ other_function local_binding | x <- some_list, x > 0, let local_binding = some_function x ]</tt> is called a "list comprehension". This is another example of "syntactic sugar", which could lead to nicely readable code, but, when abused, could lead to syntactic caries :) Do you understand what does this sample do: <tt>let solve x = [ y | x <- [0..], y<-[0..], y == x * x ]</tt>? Could write (with help of decent tutorial) write de-sugared version of this? (Yes, I know that finding a square root does not require list traversals, but for the sake of self-education try and do it)<br />
* Notice that in order to code quite complex implementation of <tt>precomputeDisksFor</tt> we split it up in several smaller pieces and put them as a '''local bindings''' inside '''let''' clause.<br />
* Notice that we use '''pattern matching''' to both define <tt>bestKnap</tt> on case-by-case basis and to "peer into" ('''de-construct''') <tt>DirPack</tt> in the <tt>let (DirPack s ds)=precomp!!(limit - dir_size d)</tt> line<br />
* Notice how we use function composition to compose complex condition to filter the list of dirs<br />
<br />
---- <br />
<br />
Before we move any further, let's do a small cosmetic change to our<br />
code. Right now our solution uses 'Int' to store directory size. In<br />
Haskell, 'Int' is a platform-dependent integer, which imposes certain<br />
limitations on the values of this type. Attempt to compute the value<br />
of type 'Int' that exceeds the bounds will result in overflow error.<br />
Standard Haskell libraries have special typeclass<br />
<hask>Bounded</hask>, which allows to define and examine such bounds:<br />
<br />
Prelude> :i Bounded <br />
class Bounded a where<br />
minBound :: a<br />
maxBound :: a<br />
-- skip --<br />
instance Bounded Int -- Imported from GHC.Enum<br />
<br />
We see that 'Int' is indeed bounded. Let's examine the bounds:<br />
<br />
Prelude> minBound :: Int <br />
-2147483648<br />
Prelude> maxBound :: Int<br />
2147483647<br />
Prelude> <br />
<br />
Those of you who are C-literate, will spot at once that in this case<br />
the 'Int' is so-called "signed 32-bit integer", which means that we<br />
would run into errors trying to operate on directories/directory packs<br />
which are bigger than 2 GB.<br />
<br />
Luckily for us, Haskell has integers of arbitrary precision (limited<br />
only by the amount of available memory). The appropriate type is<br />
called 'Integer':<br />
<br />
Prelude> (2^50) :: Int<br />
0 -- overflow<br />
Prelude> (2^50) :: Integer<br />
1125899906842624 -- no overflow<br />
Prelude><br />
<br />
Lets change definitions of 'Dir' and 'DirPack' to allow for bigger<br />
directory sizes:<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
data Dir = Dir {dir_size::Integer, dir_name::String} deriving (Eq,Show)<br />
data DirPack = DirPack {pack_size::Integer, dirs::[Dir]} deriving Show<br />
</haskell><br />
<br />
Try to compile the code or load it into ghci. You will get the<br />
following errors:<br />
<br />
cd-fit-4-2.hs:73:79:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the expression: limit - (dir_size d)<br />
In the second argument of `(!!)', namely `(limit - (dir_size d))'<br />
<br />
cd-fit-4-2.hs:89:47:<br />
Couldn't match `Int' against `Integer'<br />
Expected type: Int<br />
Inferred type: Integer<br />
In the second argument of `(!!)', namely `media_size'<br />
In the definition of `dynamic_pack':<br />
dynamic_pack dirs = (precomputeDisksFor dirs) !! media_size<br />
<br />
<br />
It seems like Haskell have some troubles using 'Integer' with '(!!)'.<br />
Let's see why:<br />
<br />
Prelude> :t (!!)<br />
(!!) :: [a] -> Int -> a<br />
<br />
Seems like definition of '(!!)' demands that index will be 'Int', not<br />
'Integer'. Haskell never converts any type to some other type<br />
automatically - programmer have to explicitly ask for that.<br />
<br />
I will not repeat the section "Standard Haskell Classes" from<br />
[http://haskell.org/onlinereport/basic.html the Haskell Report] and<br />
explain, why typeclasses for various numbers organized the way they<br />
are organized. I will just say that standard typeclass<br />
<hask>Num</hask> demands that numeric types implement method<br />
<hask>fromInteger</hask>:<br />
<br />
Prelude> :i Num<br />
class (Eq a, Show a) => Num a where<br />
(+) :: a -> a -> a<br />
(*) :: a -> a -> a<br />
(-) :: a -> a -> a<br />
negate :: a -> a<br />
abs :: a -> a<br />
signum :: a -> a<br />
fromInteger :: Integer -> a<br />
-- Imported from GHC.Num<br />
instance Num Float -- Imported from GHC.Float<br />
instance Num Double -- Imported from GHC.Float<br />
instance Num Integer -- Imported from GHC.Num<br />
instance Num Int -- Imported from GHC.Num<br />
<br />
We see that <hask>Integer</hask> is a member of typeclass<br />
<hask>Num</hask>, thus we could use <hask>fromInteger</hask> to make<br />
the type errors go away:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
-- snip<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
] of<br />
-- snip<br />
dynamic_pack dirs = (precomputeDisksFor dirs)!!(fromInteger media_size)<br />
-- snip<br />
</haskell><br />
<br />
Type errors went away, but careful reader will spot at once that when<br />
expression <hask>(limit - dir_size d)</hask> will exceed the bounds<br />
for <hask>Int</hask>, overflow will occur, and we will not access the<br />
correct list element. Don't worry, we will deal with this in a short while.<br />
<br />
Now, lets code the QuickCheck test for this function along the lines of the test for <tt>greedy_pack</tt>:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-2.hs'<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack ds <br />
in pack_size pack == pack_size (dynamic_pack (dirs pack))<br />
</haskell><br />
<br />
Now, lets try to run (DON'T PANIC and save all you work in other applications first!):<br />
<br />
*Main> quickCheck prop_dynamic_pack_is_fixpoint<br />
<br />
Now, you took my advice seriously, don't you? And you did have your '''Ctrl-C''' handy, didn't you? Most probably, the attempt to run the test resulted in all your memory being taken by <tt>ghci</tt> process, which you hopefully interrupted soon enough by pressing '''Ctrl-C'''.<br />
<br />
What happened? Who ate all the memory? How to debug this problem? GHC comes with profiling abilities, but we could not use them - they produce report after program terminates, and our doesn't seem to do so without consuming several terabytes of memory first. Still, there is a lot of room for maneuver.<br />
<br />
Let's see. Since we called <tt>dynamic_pack</tt> and it ate all the memory, let's not do this again. Instead, let's see what this function does and tweak it a bit to explore it's behavior.<br />
<br />
Since we already know that random lists of "Dir"s generated for our QuickCheck tests are of modest size (after all, <tt>greedy_pack</tt> munches them without significant memory consumption), the size of the input most probably is not the issue. However, <tt>dynamic_pack_is_fixpoint</tt> is building quite a huge list internally (via <tt>precomputeDisksFor</tt>). Could this be a problem?<br />
<br />
Let's turn the timing/memory stats on (":set +s" on ghci prompt) and try to peek into various elements of list returned by <tt>precomputeDisksFor</tt>:<br />
<br />
Prelude> :l cd-fit.hs<br />
Compiling Main ( cd-fit.hs, interpreted )<br />
Ok, modules loaded: Main.<br />
*Main> :set +s<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 0<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.06 secs, 1277972 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.00 secs, 0 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.01 secs, 1519064 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 1000<br />
DirPack {pack_size = 0, dirs = []}<br />
(0.03 secs, 1081808 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 10000<br />
DirPack {pack_size = 0, dirs = []}<br />
(1.39 secs, 12714088 bytes)<br />
*Main> (precomputeDisksFor [Dir 1 "aaa"]) !! 100000<br />
Interrupted.<br />
<br />
Aha! This seems to be a problem, since computation of 100000 fails to terminate in "reasonable" time, and to think that we have tried to compute <tt>700*1024*1024</tt>th element...<br />
<br />
Lets modify our code a bit, to allow disk size to be tweaked:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-3.hs'<br />
dynamic_pack limit dirs = (precomputeDisksFor dirs)!!(fromInteger limit)<br />
<br />
prop_dynamic_pack_is_fixpoint ds =<br />
let pack = dynamic_pack media_size ds <br />
in pack_size pack == pack_size (dynamic_pack media_size (dirs pack))<br />
<br />
prop_dynamic_pack_small_disk ds =<br />
let pack = dynamic_pack 50000 ds<br />
in pack_size pack == pack_size (dynamic_pack 50000 (dirs pack))<br />
<br />
-- rename "old" main to "moin"<br />
main = quickCheck prop_dynamic_pack_small_disk<br />
</haskell><br />
<br />
Compute a profiling version of you code with <tt>ghc -O --make -prof -auto-all -o cd-fit cd-fit.hs</tt> and run it like this: <br />
<br />
$ ./cd-fit +RTS -p<br />
OK, passed 100 tests.<br />
<br />
First thing, note that our code satisfies at least one simple property. Good. Now let's examine profile. Look into file "cd-fit.prof", which was produced in your current directory. <br />
<br />
Most probably, you'll see something like this:<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 2.18 secs (109 ticks @ 20 ms)<br />
total alloc = 721,433,008 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
precomputeDisksFor Main 88.1 99.8<br />
dynamic_pack Main 11.0 0.0<br />
<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
<br />
MAIN MAIN 1 0 0.0 0.0 100.0 100.0<br />
CAF Main 174 11 0.9 0.2 100.0 100.0<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 99.1 99.8<br />
dynamic_pack Main 182 200 11.0 0.0 99.1 99.8<br />
precomputeDisksFor Main 183 200 88.1 99.8 88.1 99.8<br />
main Main 180 1 0.0 0.0 0.0 0.0<br />
<br />
Examine column of "individual %alloc". As we thought, all memory was<br />
allocated within <tt>precomputeDisksFor</tt>. However, amount of<br />
memory allocated (more than 700 MB, according to the line "total<br />
alloc") seems to be a little too much for our simple task. We will dig<br />
deeper and find where we a wasting it.<br />
<br />
Let's examine memory consumption a little closer via so-called "heap<br />
profiles". Run <tt>./cd-fit +RTS -hb</tt>. This produces "biographical<br />
heap profile", which tells us how various parts of the memory were<br />
used during the program run time. Heap profile was saved to<br />
"cd-fit.hp". It is next to impossible to read and comprehend it as is,<br />
so use "hp2ps cd-fit.hp" to produce a nice PostScript picture which<br />
is worth a thousand words. View it with "gv" or "ghostview" or "full<br />
Adobe Acrobat (not Reader)". (This and subsequent pictures are<br />
'''not''' attached here).<br />
<br />
Notice that most of the graph is taken up by region marked as "VOID". <br />
This means that memory allocated was never used. Notice that there is<br />
'''no''' areas marked as "USE", "LAG" or "DRAG". Seems like our<br />
program hardly uses '''any''' of the allocated memory at all. Wait a<br />
minute! How could that be? Surely it must use something when it packs<br />
to the imaginary disks of 50000 bytes those random-generated<br />
directories which are 10 to 1400 Mb in size.... Oops. Severe size<br />
mismatch. We should have spotted it earlier, when we were timing<br />
<tt>precomputeDisksFor</tt>. Scroll back and observe how each run<br />
returned the very same result - empty directory set.<br />
<br />
Our random directories are too big, but nevertheless code spends time<br />
and memory trying to "pack" them. Obviously,<br />
<tt>precomputeDisksFor</tt> (which is responsible for 90% of total<br />
memory consumption and run time) is flawed in some way.<br />
<br />
Let's take a closer look at what takes up so much memory. Run<br />
<tt>./cd-fit +RTS -h -hbvoid</tt> and produce PostScript picture for<br />
this memory profile. This will give us detailed breakdown of all<br />
memory whose "biography" shows that it's been "VOID" (unused). My<br />
picture (and I presume that yours as well) shows that VOID memory<br />
comprises of "thunks" labeled "precomputeDisksFor/pre...". We could<br />
safely assume that second word would be "precomp" (You wonder why?<br />
Look again at the code and try to find function named "pre.*" which is<br />
called from inside <tt>precomputeDisksFor</tt>)<br />
<br />
This means that memory has been taken by the list generated inside<br />
"precomp". Rumor has it that memory leaks with Haskell are caused by<br />
either too little laziness or too much laziness. It seems like we have<br />
too little laziness here: we evaluate more elements of the list that<br />
we actually need and keep them from being garbage-collected. <br />
<br />
Note how we look up element from "precomp" in this piece of code:<br />
<br />
<haskell><br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)=precomp!!(fromInteger (limit - dir_size d))<br />
, d `notElem` ds<br />
</haskell><br />
<br />
<br />
Obviously, the whole list generated by "precomp" must be kept in<br />
memory for such lookups, since we can't be sure that some element<br />
could be garbage collected and will not be needed again.<br />
<br />
Let's rewrite the code to eliminate the list (incidentally, this will also deal with the possible Int overflow while accessing the "precomp" via (!!) operator):<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-4.hs'<br />
-- Let the `bestDisk x' be the "most tightly packed" disk of total <br />
-- size no more than `x'.<br />
-- How to calculate `bestDisk'? Lets opt for a recursive definition:<br />
-- Recursion base: best packed disk of size 0 is empty and best-packed<br />
-- disk for empty list of directories on it is also empty.<br />
bestDisk 0 _ = DirPack 0 []<br />
bestDisk _ [] = DirPack 0 []<br />
-- Recursion step: for size `limit`, bigger than 0, best packed disk is<br />
-- computed as follows:<br />
bestDisk limit dirs =<br />
-- Take all non-empty dirs that could possibly fit to that disk by itself.<br />
-- Consider them one by one. Let the size of particular dir be `dir_size d'.<br />
-- Let's add it to the best-packed disk of size <= (limit - dir_size d), thus<br />
-- producing the disk of size <= limit. Lets do that for all "candidate"<br />
-- dirs that are not yet on our disk:<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| d <- filter ( (inRange (1,limit)).dir_size ) dirs<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) dirs <br />
, d `notElem` ds<br />
] of<br />
-- We either fail to add any dirs (probably, because all of them too big).<br />
-- Well, just report that disk must be left empty:<br />
[] -> DirPack 0 []<br />
-- Or we produce some alternative packings. Let's choose the best of them all:<br />
packs -> maximumBy cmpSize packs<br />
<br />
cmpSize a b = compare (pack_size a) (pack_size b)<br />
<br />
dynamic_pack limit dirs = bestDisk limit dirs<br />
</haskell><br />
<br />
<br />
Compile the profiling version of this code and obtain the overall<br />
execution profile (with "+RTS -p"). You'll get something like this:<br />
<br />
cd-fit +RTS -p -RTS<br />
<br />
total time = 0.00 secs (0 ticks @ 20 ms)<br />
total alloc = 1,129,520 bytes (excludes profiling overheads)<br />
<br />
COST CENTRE MODULE %time %alloc<br />
<br />
CAF GHC.Float 0.0 4.4<br />
main Main 0.0 93.9<br />
<br />
individual inherited<br />
COST CENTRE MODULE no. entries %time %alloc %time %alloc<br />
MAIN MAIN 1 0 0.0 0.0 0.0 100.0<br />
main Main 180 1 0.0 93.9 0.0 94.2<br />
prop_dynamic_pack_small_disk Main 181 100 0.0 0.0 0.0 0.3<br />
dynamic_pack Main 182 200 0.0 0.2 0.0 0.3<br />
bestDisk Main 183 200 0.0 0.1 0.0 0.1<br />
<br />
We achieved the major improvement: memory consumption is reduced by factor<br />
of 700! Now we could test the code on the "real task" - change the<br />
code to run the test for packing the full-sized disk:<br />
<br />
<haskell><br />
main = quickCheck prop_dynamic_pack_is_fixpoint<br />
</haskell><br />
<br />
Compile with profiling and run (with "+RTS -p"). If you are not lucky<br />
and a considerably big test set would be randomly generated for your<br />
runs, you'll have to wait. And wait even more. And more.<br />
<br />
Go make some tea. Drink it. Read some Tolstoi (Do you have "War and<br />
peace" handy?). Chances are that by the time you are done with<br />
Tolstoi, program will still be running (just take my word on it, don't<br />
check).<br />
<br />
If you are lucky, your program will finish fast enough and leave you<br />
with profile. According to a profile, program spends 99% of its time<br />
inside <tt>bestDisk</tt>. Could we speed up <tt>bestDisk</tt> somehow?<br />
<br />
Note that <tt>bestDisk</tt> performs several simple calculation for<br />
which it must call itself. However, it is done rather inefficiently -<br />
each time we pass to <tt>bestDisk</tt> the exact same set of<br />
directories as it was called with, even if we have already "packed"<br />
some of them. Let's amend this:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
case [ DirPack (dir_size d + s) (d:ds) <br />
| let small_enough = filter ( (inRange (0,limit)).dir_size ) dirs<br />
, d <- small_enough<br />
, dir_size d > 0<br />
, let (DirPack s ds)= bestDisk (limit - dir_size d) (delete d small_enough)<br />
] of<br />
</haskell><br />
<br />
Recompile and run again. Runtimes could be lengthy, but bearable, and<br />
number of times <tt>bestDisk</tt> is called (according to the profile)<br />
should decrease significantly. <br />
<br />
Finally, let's compare both packing algorithms. Intuitively, we feel<br />
that greedy algorithm should produce worse results, don't we? Lets put<br />
this feeling to the test:<br />
<br />
<haskell><br />
-- Taken from 'cd-fit-4-5.hs'<br />
prop_greedy_pack_is_no_better_than_dynamic_pack ds =<br />
pack_size (greedy_pack ds) <= pack_size (dynamic_pack media_size ds)<br />
</haskell><br />
<br />
Verify that it is indeed so by running <tt>quickCheck</tt> for this<br />
test several time. I feel that this concludes our knapsacking<br />
exercises. <br />
<br />
Adventurous readers could continue further by implementing so-called<br />
"scaling" for <tt>dynamic_pack</tt> where we divide all directory<br />
sizes and medium size by the size of the smallest directory to proceed<br />
with smaller numbers (which promises faster runtimes).<br />
<br />
== Chapter 5: (Ab)using monads and destructing constructors for fun and profit ==<br />
<br />
We already mentioned monads quite a few times. They are described in<br />
numerous articles and tutorial (See Chapter 400). It's hard to read a<br />
daily dose of any Haskell mailing list and not to come across a word<br />
"monad" a dozen times.<br />
<br />
Since we already made quite a progress with Haskell, it's time we<br />
revisit the monads once again. I will let the other sources teach you<br />
theory behind the monads, overall usefulness of the concept, etc.<br />
Instead, I will focus on providing you with examples.<br />
<br />
Let's take a part of the real world program which involves XML<br />
processing. We will work with XML tag attributes, which are<br />
essentially named values:<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
type Attribute = (Name, AttValue)<br />
</haskell><br />
<br />
'Name' is a plain string, and value could be '''either''' string or<br />
references (also strings) to another attributes which holds the actual<br />
value (now, this is not a valid XML thing, but for the sake of<br />
providing a nice example, let's accept this). Word "either" suggests<br />
that we use 'Either' datatype:<br />
<haskell><br />
type AttValue = Either Value [Reference]<br />
type Name = String<br />
type Value = String<br />
type Reference = String<br />
<br />
-- Sample list of simple attributes:<br />
simple_attrs = [ ( "xml:lang", Left "en" )<br />
, ( "xmlns", Left "jabber:client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
<br />
-- Sample list of attributes with references:<br />
complex_attrs = [ ( "xml:lang", Right ["lang"] )<br />
, ( "lang", Left "en" )<br />
, ( "xmlns", Right ["ns","subns"] )<br />
, ( "ns", Left "jabber" )<br />
, ( "subns", Left "client" )<br />
, ( "xmlns:stream", Left "http://etherx.jabber.org/streams" ) ]<br />
</haskell><br />
<br />
'''Our task is:''' to write a function that will look up a value of<br />
attribute by it's name from the given list of attributes. When<br />
attribute contains reference(s), we resolve them (looking for the<br />
referenced attribute in the same list) and concatenate their values,<br />
separated by semicolon. Thus, lookup of attribute "xmlns" form both<br />
sample sets of attributes should return the same value.<br />
<br />
Following the example set by the <hask>Data.List.lookup</hask> from<br />
the standard libraries, we will call our function<br />
<hask>lookupAttr</hask> and it will return <hask>Maybe Value</hask>,<br />
allowing for lookup errors:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
-- Since we dont have code for 'lookupAttr', but want<br />
-- to compile code already, we use the function 'undefined' to<br />
-- provide default, "always-fail-with-runtime-error" function body.<br />
lookupAttr = undefined<br />
</haskell><br />
<br />
Let's try to code <hask>lookupAttr</hask> using <hask>lookup</hask> in<br />
a very straightforward way:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-1.hs'<br />
import Data.List<br />
<br />
lookupAttr :: Name -> [Attribute] -> Maybe Value<br />
lookupAttr nm attrs = <br />
-- First, we lookup 'Maybe AttValue' by name and<br />
-- check whether we are successful:<br />
case (lookup nm attrs) of<br />
-- Pass the lookup error through.<br />
Nothing -> Nothing <br />
-- If given name exist, see if it is value of reference:<br />
Just attv -> case attv of<br />
-- It's a value. Return it!<br />
Left val -> Just val<br />
-- It's a list of references :(<br />
-- We have to look them up, accounting for<br />
-- possible failures.<br />
-- First, we will perform lookup of all references ...<br />
Right refs -> <br />
let vals = [ lookupAttr ref attrs | ref <- refs ]<br />
-- .. then, we will exclude lookup failures<br />
wo_failures = filter (/=Nothing) vals<br />
-- ... find a way to remove annoying 'Just' wrapper<br />
stripJust (Just v) = v<br />
-- ... use it to extract all lookup results as strings<br />
strings = map stripJust wo_failures<br />
in<br />
-- ... finally, combine them into single String. <br />
-- If all lookups failed, we should pass failure to caller.<br />
case null strings of<br />
True -> Nothing<br />
False -> Just (concat (intersperse ":" strings))<br />
</haskell><br />
<br />
Testing:<br />
<br />
*Main> lookupAttr "xmlns" complex_attrs<br />
Just "jabber:client"<br />
*Main> lookupAttr "xmlns" simple_attrs<br />
Just "jabber:client"<br />
*Main><br />
<br />
It works, but ... It seems strange that such a boatload of code<br />
required for quite simple task. If you examine the code closely,<br />
you'll see that the code bloat is caused by:<br />
<br />
* the fact that after each step we check whether the error occurred<br />
<br />
* unwrapping Strings from <hask>Maybe</hask> and <hask>Either</hask> data constructors and wrapping them back.<br />
<br />
At this point C++/Java programmers would say that since we just pass<br />
errors upstream, all those cases could be replaced by the single "try<br />
... catch ..." block, and they would be right. Does this mean that<br />
Haskell programmers are reduced to using "case"s, which were already<br />
obsolete 10 years ago?<br />
<br />
Monads to the rescue! As you can read elsewhere (see section 400),<br />
monads are used in advanced ways to construct computations from other<br />
computations. Just what we need - we want to combine several simple<br />
steps (lookup value, lookup reference, ...) into function<br />
<hask>lookupAttr</hask> in a way that would take into account possible<br />
failures.<br />
<br />
Lets start from the code and dissect in afterwards:<br />
<haskell><br />
-- Taken from 'chapter5-2.hs'<br />
import Control.Monad<br />
<br />
lookupAttr' nm attrs = do<br />
-- First, we lookup 'AttValue' by name<br />
attv <- lookup nm attrs<br />
-- See if it is value of reference:<br />
case attv of<br />
-- It's a value. Return it!<br />
Left val -> Just val<br />
-- It's a list of references :(<br />
-- We have to look them up, accounting for<br />
-- possible failures.<br />
-- First, we will perform lookup of all references ...<br />
Right refs -> do vals <- sequence $ map (flip lookupAttr' attrs) refs<br />
-- ... since all failures are already excluded by "monad magic",<br />
-- ... all all 'Just's have been removed likewise,<br />
-- ... we just combine values into single String,<br />
-- ... and return failure if it is empty. <br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
'''Exercise''': compile the code, test that <hask>lookupAttr</hask><br />
and <hask>lookupAttr'</hask> really behave in the same way. Try to<br />
write a QuickCheck test for that, defining the <br />
<hask>instance Arbitrary Name</hask> such that arbitrary names will be taken from<br />
names available in <hask>simple_attrs</hask>.<br />
<br />
Well, back to the story. Noticed the drastic reduction in code size?<br />
If you drop comments, the code will occupy mere 7 lines instead of 13<br />
- almost two-fold reduction. How we achieved this?<br />
<br />
First, notice that we never ever check whether some computation<br />
returns <hask>Nothing</hask> anymore. Yet, try to lookup some<br />
non-existing attribute name, and <hask>lookupAttr'</hask> will return<br />
<hask>Nothing</hask>. How does this happen? Secret lies in the fact<br />
that type constructor <hask>Maybe</hask> is a "monad".<br />
<br />
We use keyword <hask>do</hask> to indicate that following block of<br />
code is a sequence of '''monadic actions''', where '''monadic magic'''<br />
have to happen when we use '<-', 'return' or move from one action to<br />
another.<br />
<br />
Different monads have different '''magic'''. Library code says that<br />
type constructor <hask>Maybe</hask> is such a monad that we could use<br />
<hask><-</hask> to "extract" values from wrapper <hask>Just</hask> and<br />
use <hask>return</hask> to put them back in form of<br />
<hask>Just some_value</hask>. When we move from one action in the "do" block to<br />
another a check happens. If the action returned <hask>Nothing</hask>,<br />
all subsequent computations will be skipped and the whole "do" block<br />
will return <hask>Nothing</hask>.<br />
<br />
Try this to understand it all better:<br />
<haskell><br />
*Main> let foo x = do v <- x; return (v+1) in foo (Just 5)<br />
Just 6<br />
*Main> let foo x = do v <- x; return (v+1) in foo Nothing <br />
Nothing<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo (Just 'a')<br />
Just 97<br />
*Main> let foo x = do v <- x; return (Data.Char.ord v) in foo Nothing <br />
Nothing<br />
*Main> <br />
</haskell><br />
<br />
Do not mind <hask>sequence</hask> and <hask>guard</hask> just for now<br />
- we will get to them in the little while.<br />
<br />
Since we already removed one reason for code bloat, it is time to deal<br />
with the other one. Notice that we have to use <hask>case</hask> to<br />
'''deconstruct''' the value of type <hask>Either Value<br />
[Reference]</hask>. Surely we are not the first to do this, and such<br />
use case have to be quite a common one. <br />
<br />
Indeed, there is a simple remedy for our case, and it is called<br />
<hask>either</hask>:<br />
<br />
*Main> :t either<br />
either :: (a -> c) -> (b -> c) -> Either a b -> c<br />
<br />
Scary type signature, but here are examples to help you grok it:<br />
<br />
*Main> :t either (+1) (length) <br />
either (+1) (length) :: Either Int [a] -> Int<br />
*Main> either (+1) (length) (Left 5)<br />
6<br />
*Main> either (+1) (length) (Right "foo")<br />
3<br />
*Main> <br />
<br />
Seems like this is exactly our case. Let's replace the<br />
<hask>case</hask> with invocation of <hask>either</hask>:<br />
<br />
<haskell><br />
-- Taken from 'chapter5-3.hs'<br />
lookupAttr'' nm attrs = do<br />
attv <- lookup nm attrs<br />
either Just (dereference attrs) attv<br />
where<br />
dereference attrs refs = do <br />
vals <- sequence $ map (flip lookupAttr'' attrs) refs<br />
guard (not (null vals))<br />
return (concat (intersperse ":" vals))<br />
</haskell><br />
<br />
It keeps getting better and better :)<br />
<br />
Now, as semi-exercise, try to understand the meaning of "sequence",<br />
"guard" and "flip" looking at the following ghci sessions:<br />
<br />
*Main> :t sequence<br />
sequence :: (Monad m) => [m a] -> m [a]<br />
*Main> :t [Just 'a', Just 'b', Nothing, Just 'c']<br />
[Just 'a', Just 'b', Nothing, Just 'c'] :: [Maybe Char]<br />
*Main> :t sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
sequence [Just 'a', Just 'b', Nothing, Just 'c'] :: Maybe [Char]<br />
<br />
*Main> sequence [Just 'a', Just 'b', Nothing, Just 'c']<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b', Nothing]<br />
Nothing<br />
*Main> sequence [Just 'a', Just 'b']<br />
Just "ab"<br />
<br />
*Main> :t [putStrLn "a", putStrLn "b"]<br />
[putStrLn "a", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", putStrLn "b"]<br />
sequence [putStrLn "a", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", putStrLn "b"]<br />
a<br />
b<br />
<br />
*Main> :t [putStrLn "a", fail "stop here", putStrLn "b"]<br />
[putStrLn "a", fail "stop here", putStrLn "b"] :: [IO ()]<br />
*Main> :t sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
sequence [putStrLn "a", fail "stop here", putStrLn "b"] :: IO [()]<br />
*Main> sequence [putStrLn "a", fail "stop here", putStrLn "b"]<br />
a<br />
*** Exception: user error (stop here)<br />
<br />
Notice that for monad <hask>Maybe</hask> sequence continues execution<br />
until the first <hask>Nothing</hask>. The same behavior could be<br />
observed for IO monad. Take into account that different behaviors are<br />
not hardcoded into the definition of <hask>sequence</hask>!<br />
<br />
Now, let's examine <hask>guard</hask>:<br />
<br />
*Main> let foo x = do v <- x; guard (v/=5); return (v+1) in map foo [Just 4, Just 5, Just 6] <br />
[Just 5,Nothing,Just 7]<br />
<br />
As you can see, it's just a simple way to "stop" execution at some<br />
condition.<br />
<br />
If you have been hooked on monads, I urge you to read "All About<br />
Monads" right now (link in Chapter 400).<br />
<br />
== Chapter 6: Where do you want to go tomorrow? ==<br />
<br />
As the name implies, the author is open for proposals - where should<br />
we go next? I had networking + xml/xmpp in mind, but it might be too<br />
heavy and too narrow for most of the readers.<br />
<br />
What do you think? Drop me a line.<br />
<br />
== Chapter 400: Monads up close ==<br />
<br />
Read [http://en.wikibooks.org/wiki/Haskell/Understanding_monads this wikibook chapter]. <br />
Then, read [http://horna.org.ua/books/All_About_Monads.pdf "All about monads"] (PDF).<br />
'Nuff said :)<br />
<br />
== Chapter 500: IO up close ==<br />
<br />
Shows that:<br />
<br />
<haskell><br />
c = do a <- someAction<br />
b <- someOtherAction<br />
print (bar b)<br />
print (foo a)<br />
print "done"<br />
</haskell><br />
<br />
really is just a syntax sugar for:<br />
<br />
<haskell><br />
c = someAction >>= \a -><br />
someOtherAction >>= \b -><br />
print (bar b) >><br />
print (foo a) >><br />
print "done"<br />
</haskell><br />
<br />
and explains about ">>=" and ">>". Oh wait. This was already explained<br />
in Chapter 400 :)<br />
<br />
== Chapter 9999: Installing Haskell Compiler/Interpreter and all necessary software ==<br />
<br />
Plenty of material on this on the web and this wiki. Just go get<br />
yourself installation of [[GHC]] (6.4 or above) or [[Hugs]] (v200311 or<br />
above) and "[[darcs]]", which we will use for version control.<br />
<br />
== Chapter 10000: Thanks! ==<br />
<br />
Thanks for comments, proofreading, good advice and kind words go to:<br />
Helge, alt, dottedmag, Paul Moore, Ben Rudiak-Gould, Jim Wilkinson,<br />
Andrew Zhdanov (avalez), Martin Percossi, SpellingNazi, Davor<br />
Cubranic, Brett Giles, Stdrange, Brian Chrisman, Nathan Collins,<br />
Anastasia Gornostaeva (ermine), Remi, Ptolomy, Zimbatm,<br />
HenkJanVanTuyl, Miguel, Mforbes, Kartik Agaram, Jake Luck, Ketil<br />
Malde, Mike Mimic, Jens Kubieziel.<br />
<br />
If I should have mentioned YOU and forgot - tell me so.<br />
<br />
Without you I would have stopped after Chapter 1 :)<br />
<br />
Languages: [[Haskellへのヒッチハイカーガイド|jp]]</div>Imzhttps://wiki.haskell.org/index.php?title=HaskellWiki_talk:Community&diff=39118HaskellWiki talk:Community2011-03-22T13:05:01Z<p>Imz: /* captcha not visible in (emacs-)w3m :( */ a solution example from emacswiki.org</p>
<hr />
<div>= Page renaming =<br />
<br />
I thought that [[HaskellWiki:Community]] is more concise than [[HaskellWiki:Community portal]]. In addition, the '''Haskell Performance Resource''' is also just called [[Performance]]. -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 23:27, 25 February 2006 (UTC)<br />
<br />
= Page position =<br />
<br />
I argue this page should be removed from its prominent position at the<br />
top of the front page. This page is getting 10,000 hits, making it one<br />
of the most popular pages, but with very little content of wide appeal. <br />
<br />
I think the name is misleading viewers thinking 'Community' will point<br />
them to something like thing like the content of the 'The Haskell<br />
community' column on the frontpage, when its just a guide to editing the<br />
wiki (which only 1% of visitors want to do). <br />
<br />
So, my proposal. [[HaskellWiki:Community_Portal]] should be removed from<br />
the top of the front page altogether. Its second place, at the bottom of<br />
the page near the editing facilities seems more appropriate.<br />
<br />
While we're here, I think 'All pages' should also disappear from the top<br />
of the front page. Site maps aren't generally the first thing you see on<br />
a web site, right? And that the remaining elements of the bar:<br />
<br />
All Pages - Categories - Community Portal<br />
Language | Packages | Standard libraries | Idioms | Tools | Proposals<br />
<br />
should appear on the left hand column of the front page. Currently we<br />
have to scroll over this stuff to get to the most popular content.<br />
<br />
Opinions? -- [[User:DonStewart]]<br />
<br />
:Makes sense. &mdash;[[User:Ashley Y|Ashley Y]] 00:57, 11 April 2006 (UTC)<br />
<br />
= Wiki dump =<br />
<br />
Is it easily possible to get a dump of the current state of all wiki pages.<br />
I mean the Wiki markup not the generated HTML.<br />
I also do not need images.<br />
For HTML I could use wget starting at Special:AllPages.<br />
<br />
= captcha not visible in (emacs-)w3m :( =<br />
<br />
I wanted to [http://www.haskell.org/haskellwiki/index.php?title=Special:Userlogin&type=signup create an account] here, and I was using [http://www.emacswiki.org/emacs/emacs-w3m emacs-w3m]-1.4.259-[http://prometheus.altlinux.org/en/5.1/srpms/emacs-w3m alt0.2.20080303] with [http://en.wikipedia.org/wiki/W3m w3m]-0.5.2-[http://prometheus.altlinux.org/en/5.1/srpms/w3m alt2.1].<br />
<br />
The captcha wasn't shown in emacs-w3m, so couldn't register without switching to another, bloated browser for a while.<br />
<br />
Perhaps, there are ways to mitigate this problem--either on the side of the wiki (by modifying the markup for the captcha so that it makes some sense in emacs-w3m) or finding what to improve in emacs-w3m for it to show such captchas, aren't there?--[[User:Imz|Imz]] 00:30, 14 March 2011 (UTC)<br />
<br />
Oh, I wasn't able to post this comment for the same reason: edits with links suppose that I solve a captcha, but me using emacs-w3m wasn't able to see it! (So, now I have pasted my comment into another, bloated browser.) :( --[[User:Imz|Imz]] 00:30, 14 March 2011 (UTC)<br />
<br />
:They came up with a solution for such a problem at the Emacs Wiki: they have a special URL to set up cookies for w3m, see the link under [http://www.emacswiki.org/emacs/emacs-w3m#toc2 ''Editing Emacs Wiki''] section. Can a solution be devised for the Haskell Wiki?--[[User:Imz|Imz]] 13:05, 22 March 2011 (UTC)</div>Imzhttps://wiki.haskell.org/index.php?title=Non-empty_list&diff=39000Non-empty list2011-03-14T00:44:35Z<p>Imz: Links for the mentioned languages.</p>
<hr />
<div>Errors such as taking <hask>head</hask> or <hask>tail</hask> of the<br />
empty list in Haskell are equivalent to the dereferencing of the zero<br />
pointer in C/C++ or <code>NullPointerException</code> in Java. These<br />
errors occur because the true domain of the function is smaller than<br />
the function's type suggests. For example, the type of<br />
<hask>head</hask> says that the function applies to any list. In<br />
reality, it can be meaningfully applied only to non-empty<br />
lists. One can eliminate such errors by giving functions<br />
<hask>head</hask> and <hask>tail</hask> more precise type, such as<br />
<hask>FullList a</hask>. Languages like [http://en.wikipedia.org/wiki/Cyclone_programming_language Cyclone] and [http://en.wikipedia.org/wiki/C%CF%89 Cw] do exactly<br />
that.<br />
<br />
It must be emphasized that we can eliminate head-of-empty-list errors<br />
'''now''', without any modification to the Haskell type system, without<br />
developing any new tool. In fact, it is possible in Haskell98! The<br />
same technique applies to OCaml and even Java and C++. The ''only''<br />
required advancement is in our thinking and programming style.<br />
<br />
Maybe, you are also interested in<br />
[http://www.haskell.org/pipermail/haskell-cafe/2006-November/019644.html advocacy] of this style.<br />
<br />
<br />
== Safe list functions ==<br />
<br />
Here's the 0th approximation of the advocated approach:<br />
<br />
<haskell><br />
{-# Haskell98! #-}<br />
-- Safe list functions<br />
<br />
module NList (FullList,<br />
fromFL,<br />
indeedFL,<br />
decon,<br />
head,<br />
tail,<br />
Listable (..)<br />
) where<br />
<br />
import Prelude hiding (head, tail)<br />
<br />
newtype FullList a = FullList [a] -- data constructor is not exported!<br />
<br />
fromFL (FullList x) = x -- Injection into general lists<br />
<br />
-- The following is an analogue of `maybe'<br />
indeedFL :: [a] -> w -> (FullList a -> w) -> w<br />
indeedFL x on_empty on_full <br />
| null x = on_empty<br />
| otherwise = on_full $ FullList x<br />
<br />
-- A possible alternative, with an extra Maybe tagging<br />
-- indeedFL :: [a] -> Maybe (FullList a)<br />
<br />
-- A more direct analogue of `maybe', for lists<br />
decon :: [a] -> w -> (a -> [a] -> w) -> w<br />
decon [] on_empty on_full = on_empty<br />
decon (h:t) on_empty on_full = on_full h t<br />
<br />
<br />
-- The following are _total_ functions<br />
-- They are guaranteed to be safe, and so we could have used<br />
-- unsafeHead# and unsafeTail# if GHC provides though...<br />
<br />
head :: FullList a -> a<br />
head (FullList (x:_)) = x<br />
<br />
tail :: FullList a -> [a]<br />
tail (FullList (_:x)) = x<br />
<br />
-- Mapping over a non-empty list gives a non-empty list<br />
instance Functor FullList where<br />
fmap f (FullList x) = FullList $ map f x<br />
<br />
<br />
-- Adding something to a general list surely gives a non-empty list<br />
infixr 5 !:<br />
<br />
class Listable l where<br />
(!:) :: a -> l a -> FullList a<br />
<br />
instance Listable [] where<br />
(!:) h t = FullList (h:t)<br />
<br />
instance Listable FullList where<br />
(!:) h (FullList t) = FullList (h:t)<br />
</haskell><br />
<br />
<br />
Now we can write<br />
<haskell><br />
import NList<br />
import Prelude hiding (head, tail)<br />
safe_reverse l = loop l [] <br />
where<br />
loop l accum = indeedFL l accum $<br />
(\l -> loop (tail l) (head l : accum))<br />
<br />
test1 = safe_reverse [1,2,3]<br />
</haskell><br />
<br />
As we can see, the null test is algorithmic. After we've done it, head<br />
and tail no longer need to check for null list. Those head and tail<br />
functions are total. Thus we achieve both safety and performance.<br />
<br />
We can also write<br />
<haskell><br />
-- Again, we are statically assured of no head [] error!<br />
test2 = head $ 1 !: 2 !: 3 !: []<br />
</haskell><br />
<br />
I should point to<br />
[http://pobox.com/~oleg/ftp/Computation/lightweight-dependent-typing.html Lightweight dependent typing] for justification and formalization, as<br />
well as for for further, more complex examples. <br />
We can also use the approach to<br />
ensure various control properties, e.g., the yield property: a thread may<br />
not invoke `yield' while holding a lock. We can assure this property<br />
both for recursive and non-recursive locks.<br />
<br />
If there is a surprise in this, it is in the triviality of<br />
approach. One can't help but wonder why don't we program in this<br />
style.<br />
<br />
== Integrating with the existing list-processing functions ==<br />
<br />
Jan-Willem Maessen wrote:<br />
<blockquote><br />
In addition, we have this rather nice assembly of functions which <br />
work on ordinary lists. Sadly, rewriting them all to also work on <br />
NonEmptyList or MySpecialInvariantList is a nontrivial task.<br />
</blockquote><br />
<br />
That's an excellent question. Indeed, let us assume we have a function<br />
<haskell><br />
foo:: [a] -> [a]<br />
</haskell><br />
(whose code, if available, we'd rather not change) and we want to<br />
write something like<br />
<haskell><br />
\l -> [head l, head (foo l)]<br />
</haskell><br />
To use the safe <hask>head</hask> from NList.hs , we should write<br />
<haskell><br />
\l -> indeedFL l onempty (\l -> [head l, head (foo l)])<br />
</haskell><br />
But that doesn't type: first of all, <hask>foo</hask> applies to <br />
<hask>[a]</hask> rather than<br />
<hask>FullList a</hask>, and second, the result of <br />
<hask>foo</hask> is not <hask>FullList a</hask>, required<br />
by our <hask>head</hask>. The first problem is easy to solve: we can always<br />
inject <hask>FullList a</hask> into the general list: <br />
<hask>fromFL</hask>. We insist on writing<br />
the latter function explicitly, which keeps the typesystem simple,<br />
free of subtyping and implicit coercions. One may regard<br />
<hask>fromFL</hask> as an<br />
analogue of <hask>fromIntegral</hask> -- which, too, we have to <br />
write explicitly, in any code with more than one sort of integral <br />
numbers (e.g., Int and Integer, or Int and CInt).<br />
<br />
If we are not sure if our function foo maps non-empty lists<br />
to non-empty lists, we really should handle the empty list case:<br />
<haskell><br />
\l -> indeedFL l onempty $<br />
\l -> [head l, indeedFL (foo $ fromFL l) onempty' head]<br />
</haskell><br />
If we have a hunch that foo maps non-empty lists to non-empty lists,<br />
but we are too busy to verify it, we can write<br />
<haskell><br />
\l -> indeedFL l onempty $<br />
\l -> [head l, indeedFL (foo $ fromFL l) <br />
(error msg)<br />
head]<br />
where msg = "I'm quite sure foo maps non-empty lists to " ++<br />
"non-empty lists. I'll be darned if it doesn't."<br />
</haskell><br />
That would get the code running. Possibly at some future date (during<br />
the code review?) I'll be called to justify my hunch, to whatever<br />
degree of formality (informal argument, formal proof) required by the<br />
policies in effect. If I fail at this justification, I'd better think<br />
what to do if the result of foo is really the empty list. If I<br />
succeed, I'd be given permission to update the module NList with the<br />
following definition<br />
<haskell><br />
nfoo (FullList x) = FullList $ foo x<br />
</haskell><br />
after which I could write<br />
<haskell><br />
\l -> indeedFL l onempty (\l -> [head l, head (nfoo l)])<br />
</haskell><br />
with no extra empty list checks.<br />
<br />
Excerpted from the discussion on Haskell-Cafe, November 2006.<br />
<br />
<br />
[[Category:Idioms]]</div>Imzhttps://wiki.haskell.org/index.php?title=HaskellWiki_talk:Community&diff=38999HaskellWiki talk:Community2011-03-14T00:32:23Z<p>Imz: /* captcha not visible in (emacs-)w3m :( */ fixing the wrong automatic section level</p>
<hr />
<div>= Page renaming =<br />
<br />
I thought that [[HaskellWiki:Community]] is more concise than [[HaskellWiki:Community portal]]. In addition, the '''Haskell Performance Resource''' is also just called [[Performance]]. -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 23:27, 25 February 2006 (UTC)<br />
<br />
= Page position =<br />
<br />
I argue this page should be removed from its prominent position at the<br />
top of the front page. This page is getting 10,000 hits, making it one<br />
of the most popular pages, but with very little content of wide appeal. <br />
<br />
I think the name is misleading viewers thinking 'Community' will point<br />
them to something like thing like the content of the 'The Haskell<br />
community' column on the frontpage, when its just a guide to editing the<br />
wiki (which only 1% of visitors want to do). <br />
<br />
So, my proposal. [[HaskellWiki:Community_Portal]] should be removed from<br />
the top of the front page altogether. Its second place, at the bottom of<br />
the page near the editing facilities seems more appropriate.<br />
<br />
While we're here, I think 'All pages' should also disappear from the top<br />
of the front page. Site maps aren't generally the first thing you see on<br />
a web site, right? And that the remaining elements of the bar:<br />
<br />
All Pages - Categories - Community Portal<br />
Language | Packages | Standard libraries | Idioms | Tools | Proposals<br />
<br />
should appear on the left hand column of the front page. Currently we<br />
have to scroll over this stuff to get to the most popular content.<br />
<br />
Opinions? -- [[User:DonStewart]]<br />
<br />
:Makes sense. &mdash;[[User:Ashley Y|Ashley Y]] 00:57, 11 April 2006 (UTC)<br />
<br />
= Wiki dump =<br />
<br />
Is it easily possible to get a dump of the current state of all wiki pages.<br />
I mean the Wiki markup not the generated HTML.<br />
I also do not need images.<br />
For HTML I could use wget starting at Special:AllPages.<br />
<br />
= captcha not visible in (emacs-)w3m :( =<br />
<br />
I wanted to [http://www.haskell.org/haskellwiki/index.php?title=Special:Userlogin&type=signup create an account] here, and I was using [http://www.emacswiki.org/emacs/emacs-w3m emacs-w3m]-1.4.259-[http://prometheus.altlinux.org/en/5.1/srpms/emacs-w3m alt0.2.20080303] with [http://en.wikipedia.org/wiki/W3m w3m]-0.5.2-[http://prometheus.altlinux.org/en/5.1/srpms/w3m alt2.1].<br />
<br />
The captcha wasn't shown in emacs-w3m, so couldn't register without switching to another, bloated browser for a while.<br />
<br />
Perhaps, there are ways to mitigate this problem--either on the side of the wiki (by modifying the markup for the captcha so that it makes some sense in emacs-w3m) or finding what to improve in emacs-w3m for it to show such captchas, aren't there?--[[User:Imz|Imz]] 00:30, 14 March 2011 (UTC)<br />
<br />
Oh, I wasn't able to post this comment for the same reason: edits with links suppose that I solve a captcha, but me using emacs-w3m wasn't able to see it! (So, now I have pasted my comment into another, bloated browser.) :( --[[User:Imz|Imz]] 00:30, 14 March 2011 (UTC)</div>Imzhttps://wiki.haskell.org/index.php?title=HaskellWiki_talk:Community&diff=38998HaskellWiki talk:Community2011-03-14T00:30:36Z<p>Imz: /* captcha not visible in (emacs-)w3m :( */ new section</p>
<hr />
<div>= Page renaming =<br />
<br />
I thought that [[HaskellWiki:Community]] is more concise than [[HaskellWiki:Community portal]]. In addition, the '''Haskell Performance Resource''' is also just called [[Performance]]. -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 23:27, 25 February 2006 (UTC)<br />
<br />
= Page position =<br />
<br />
I argue this page should be removed from its prominent position at the<br />
top of the front page. This page is getting 10,000 hits, making it one<br />
of the most popular pages, but with very little content of wide appeal. <br />
<br />
I think the name is misleading viewers thinking 'Community' will point<br />
them to something like thing like the content of the 'The Haskell<br />
community' column on the frontpage, when its just a guide to editing the<br />
wiki (which only 1% of visitors want to do). <br />
<br />
So, my proposal. [[HaskellWiki:Community_Portal]] should be removed from<br />
the top of the front page altogether. Its second place, at the bottom of<br />
the page near the editing facilities seems more appropriate.<br />
<br />
While we're here, I think 'All pages' should also disappear from the top<br />
of the front page. Site maps aren't generally the first thing you see on<br />
a web site, right? And that the remaining elements of the bar:<br />
<br />
All Pages - Categories - Community Portal<br />
Language | Packages | Standard libraries | Idioms | Tools | Proposals<br />
<br />
should appear on the left hand column of the front page. Currently we<br />
have to scroll over this stuff to get to the most popular content.<br />
<br />
Opinions? -- [[User:DonStewart]]<br />
<br />
:Makes sense. &mdash;[[User:Ashley Y|Ashley Y]] 00:57, 11 April 2006 (UTC)<br />
<br />
= Wiki dump =<br />
<br />
Is it easily possible to get a dump of the current state of all wiki pages.<br />
I mean the Wiki markup not the generated HTML.<br />
I also do not need images.<br />
For HTML I could use wget starting at Special:AllPages.<br />
<br />
== captcha not visible in (emacs-)w3m :( ==<br />
<br />
I wanted to [http://www.haskell.org/haskellwiki/index.php?title=Special:Userlogin&type=signup create an account] here, and I was using [http://www.emacswiki.org/emacs/emacs-w3m emacs-w3m]-1.4.259-[http://prometheus.altlinux.org/en/5.1/srpms/emacs-w3m alt0.2.20080303] with [http://en.wikipedia.org/wiki/W3m w3m]-0.5.2-[http://prometheus.altlinux.org/en/5.1/srpms/w3m alt2.1].<br />
<br />
The captcha wasn't shown in emacs-w3m, so couldn't register without switching to another, bloated browser for a while.<br />
<br />
Perhaps, there are ways to mitigate this problem--either on the side of the wiki (by modifying the markup for the captcha so that it makes some sense in emacs-w3m) or finding what to improve in emacs-w3m for it to show such captchas, aren't there?--[[User:Imz|Imz]] 00:30, 14 March 2011 (UTC)<br />
<br />
Oh, I wasn't able to post this comment for the same reason: edits with links suppose that I solve a captcha, but me using emacs-w3m wasn't able to see it! (So, now I have pasted my comment into another, bloated browser.) :( --[[User:Imz|Imz]] 00:30, 14 March 2011 (UTC)</div>Imz