> module Questions
> where

> import Data.Array
> import Data.List
> import Random

1.) A “rotated array” is an array of integers in ascending order, after which for every element i, it has been moved to element (i + n) mod sizeOfList. Write a function that takes a rotated array and, in less-than-linear time, returns n (the amount of rotation).

First we’ll write a simple function to rotate a given array (xs) by a given amount (n).

> rotate n xs = b ++ a
>     where n'     = n `mod` (length xs)
>           (a, b) = splitAt ((length xs) - n') xs

Now we turn to the function that computes how much the array was rotated. The key to the solution is realizing that you need to find an inflection point where consecutive numbers in the rotated list decrease. To do this, we find the first, largest sub-sequence that monotonically increases. We can find that subsequence using binary search, testing the endpoints of subsequences. The running time is O(log(n)), where n is the length of the input list (ignoring the O(n) time to construct our array).

> rotateAmount xs = _ra 0 ((length xs) - 1) (listArray (0, ((length xs) - 1)) xs)
>     where _ra s e ys = if (e - s) == 1
>                        then (if ((ys ! s) &lt (ys ! e)) then s else e)  -- base case
>                        else let h  = ys ! s                  -- first item
>                                 l  = ys ! e                  -- last item
>                                 mi = s + ((e - s) `div` 2)   -- middle index
>                                 m  = ys ! mi                 -- middle item
>                             in if (h &lt l)
>                                then s                        -- return start index
>                                else if (h &gt m)
>                                     then _ra s  mi ys
>                                     else _ra mi e  ys

2.) You are given a list of Ball objects. Each Ball is either Red or Blue. Write a function that partitions these balls so that all of the balls of each color are contiguous. Return the index of the first ball of the second color (your result can be Red balls, then Blue balls, or the other way around). In haskell, you’ll probably want to return a ([Ball],Int).

This one is dead-simple in Haskell.

> data Ball = Red | Blue deriving (Eq, Ord, Show, Read)

> groupBalls bs = let gs = (group . sort) bs
>                 in (concat gs, length $ head gs)

3.) Live Search is a search engine. Suppose it was to be tied into an online store. Now you’re given two lists. One is a [(SessionId, NormalizedQuery)]. That is, when a particular user performs a query, it is turned into some consistent format, based on their apparent intent, and stored in this logfile. The second list is a [(SessionId, ProductId)]. This indicates the product bought by a particular user. Now, you want to take these two (potentially very long) lists, and return some structure that will make it easy to take a query and return a list of the most popular resulting purchases. That is, of people who have run this query in the past, what are the most common products they’ve wound up buying? The interviewer said that this is an instance of a well-known problem, but I didn’t catch the name of it.

I’m skipping this for now because its more of a rambling thought experiment. I’d love to chat about it, but I’m not going to immediately dive into writing some code.

4.) You’re given an array which contains the numbers from 1 to n, in random order, except there is one missing. Write a function to return the missing number.

Obviously sorting and walking through would work, but we can do better because the sum of the numbers 1 through n is (n * (n+1) / 2). So we can get it in one pass. This takes O(n) time. Neat.

> missingInt xs = let n = length xs
>                 in ((n + 1) * (n + 2) `div` 2) - (sum xs)

5.) Write a function to reconstruct a binary tree from its preorder traversal and inorder traversal. Take into account that the traversals could be invalid.

First define a tree data structure.

> data Tree a = Tree a (Tree a) (Tree a) | Leaf a | Empty
>               deriving (Eq, Ord, Show, Read)

For the pre-order list we need to split it up by what elements are less than or greater than the head of the list (thinking recursively here). So in the initial list, the first element is the root, and then the subsequent items that are less than the first element are in the left branch, and the other items are in the right branch. I don’t catch invalid traversals, although they would show up if ‘rest2′ in the below function was not empty.

> preorderTree xs = f xs
>     where f []          = Empty
>           f (h:[])      = Leaf h
>           f (h:tl)      = let (left,  rest1) = span (&lt h) tl
>                               (right, rest2) = span (&gt h) rest1
>                           in Tree h (f left) (f right)

> po1 = [4, 2, 1, 3, 5, 6]   -- test

Now, for the in-order traversal, every input will simply be an in-order list of numbers. So we create a balanced binary tree using that traversal by recursively splitting the list in half.

> inorderTree xs = f xs
>     where f [] = Empty
>           f (h:[]) = Leaf h
>           f (h1:h2:[]) = Tree h2 (Leaf h1) Empty
>           f ys = let (left, right) = splitAt ((length ys) `div` 2) ys
>                  in Tree (head right) (f left) (f $ tail right)

> pi1 = [1..6]

6.) You have a [(WeatherStationId, Latitude, Longitude)]. Similar to #3, write a function which will, off-line, turn this into a data structure from which you can easily determine the nearest Weather Station, given an arbitrary Latitude and Longitude.

I’m fairly stumped by this one. I can think of good ways to to solve this problem conceptualy, but I can’t think of a simple data structure to return. I’d like to return a data structure of polygons, where each polygon encapsulates what points are closest to each weather station. I don’t feel like coding that up though.

7.) Write a function for scoring a mastermind guess. That is, in a game of mastermind (http://en.wikipedia.org/wiki/Mastermind_(board_game)), given a guess, and the actual answer, determine the number correct, the number wrong,and the number out of place.

For this solution, we zip up the answer and the guess so we can examine the elements pair-wise. We then consider each pair. If they are equal, we can increment a correct counter. Otherwise, we must accumulate a list of incorrect values. As we build up the incorrect values, we check if each guess and answer has already been accumulated in the list of incorrect values. When we find it in the accumulated list, we know we’ve found a guess that was in the wrong position.

> data ColoredPeg = W | G | B | R | P | O deriving (Eq, Ord, Show, Read)

> scoreMM as gs = let (crct, wrg, _) = foldl f (0, [], []) (zip as gs)
>                     wrongPosition = (length as) - crct - (length wrg)
>                 in (crct, (length wrg), wrongPosition)
>     where f (c, oA, oG)
>                 (a, g) = case g == a of  -- update an accumulator after examining each pair
>                          True -> (c+1, oA, oG) -- match, so simply update the count of correct
>                          False -> case ((a `elem` oG), (g `elem` oA)) of
>                               (True,True)->(c, (rem g oA), (rem a oG))
>                               (False,True)->(c, a:(rem g oA), (rem a oG))
>                               (True,False)->(c, (rem g oA), g:(rem a oG))
>                               (False,False)->(c, a:(rem g oA), g:(rem a oG))
>           rem a [] = []
>           rem a (b:bs) = if (a == b) then bs else b:(rem a bs)

> testAnswer1 = [W, G, B, R]
> testGuess1 = [W, G, R, B]
> testGuess2 = [W, G, R, P]

8.) Implement a trie (http://en.wikipedia.org/wiki/Trie) data structure. Write a function add, which takes a word, and a trie, and adds the word to the trie. Write another function lookup, which takes a prefix and a trie, and returns all the words in the trie that start with that prefix.

This is a fairly straightforward problem. We create the Trie data structure and define the recursive functions. I wish that we didn’t have a special data value for the Trie root, but I couldn’t think of an alternate solution besides having a special null character as the root.

> data Trie = TrieRoot { tries :: [Trie] }
>     | Trie { char :: Char, tries :: [Trie] }
>             deriving (Eq, Ord, Show, Read)

> trieAdd t [] = t
> trieAdd (TrieRoot ts) ws = TrieRoot{tries = (_tahelp ts ws)}
> trieAdd (Trie c ts) ws   = Trie{char = c, tries = (_tahelp ts ws)}
> _tahelp ts (w:ws) = case find (\t -> (char t) == w) ts of
>                     Nothing -> let newTrie = trieAdd Trie{char=w,
>                                                           tries=[]} ws
>                                in newTrie:ts
>                     Just mtch -> let otherTries = filter (\t -> (char t) /= w) ts
>                                      newTrie    = trieAdd mtch ws
>                                  in newTrie:otherTries

> trieLookup (TrieRoot ts) ws = concatMap (\t -> trieLookup t ws) ts
> trieLookup (Trie c ts) [] = case ts of
>                             []        -> [[c]]
>                             otherwise -> recurse
>     where recurse = map (\str -> c:str) $ concatMap (\t -> trieLookup t []) ts
> trieLookup (Trie c ts) (w:ws) = if (c == w)
>                                 then case ts of -- we matched the character
>                                      []        -> [[c]]
>                                      otherwise -> recurse
>                                 else [] -- stop the search down this trie branch
>     where recurse = map (\str -> c:str) $ concatMap (\t -> trieLookup t ws) ts

> testTrie = trieAdd (trieAdd (trieAdd (TrieRoot []) "hi") "hot") "gr"
> testTrie2 = trieAdd (TrieRoot []) "h"

9.) Write an algorithm to shuffle a deck of cards. Now write a function to perform some kind of evaluation of “how shuffled” a deck of cards is.

To shuffle I swap element i with a random element at position [i, (n-1)].

> shuffle gen xs = let n = length xs
>                      a = listArray (0, (n - 1)) xs                 -- create an Array
>                      swapPairs = (zip [0..(n - 1)] (swaps gen n))  -- compute a sequence of swaps to perform
>                  in elems $ foldl f a swapPairs
>     where f a' (i1, i2) = a' // [(i1, a'!i2), (i2, a'!i1)]         -- swap element at i1 with element at i2

Here’s a function which generates a sequence of swaps. We swap element at index ‘i’ into the range [i, (n-1)].

> swaps gen n = unfoldr f (gen, 0)
>     where f (g, i) = if (i &lt n)
>                      then let (randInt, g') = next g
>                               swapIndex = (randInt `mod` (n - i)) + i  -- produce a number in [i, (n-1)]
>                           in Just (swapIndex, (g', (i+1)))         -- add 'swapIndex' to the generated list
>                      else Nothing                                  -- stop generating elements

Here are functions that generates a sequence of random numbers or random generators. Can be used to call shuffle multiple times.

> randomGems = map mkStdGen randomNums
> randomNums = unfoldr (Just . next) (mkStdGen 1)

One way we might measure how good the suffle is (although for a single shuffle, the question is a bit preposterous), is to compute the min, max, and average distance that each item moved in the list.

> shuffleQuality xs ys = let xsPos = sortBySnd $ zip [1..(length xs)] xs
>                            ysPos = sortBySnd $ zip [1..(length ys)] ys
>                            diffFun = (\ (xp, yp) -> abs ((fst xp) - (fst yp)))
>                            posDiffs = map diffFun (zip xsPos ysPos)
>                            maxDiff = maximum posDiffs
>                            minDiff = minimum posDiffs
>                            avgDiff = (sum posDiffs) `div` (length posDiffs)
>                        in (maxDiff, minDiff, avgDiff)
>     where sortBySnd ps = sortBy (\ p1 p2 -> compare (snd p1) (snd p2)) ps

I had such a hard time partly because I didn’t understand some fundamental concepts as well as I had thought. Unfortunately, it took me a while to realize this because I already had experience writing real Haskell code. It didn’t occur to me that I had to revisit basic concepts like types and functions. I also think that other tutorials don’t spend enough time breaking down the syntactic sugar that makes Haskell’s monads so terse.

This writeup focuses on the concepts that confused me. The intended audience is people who have studied Haskell, yet have struggled with monads. Although some fundemental concepts are explained, this is not a comprehensive introduction to Haskell.

Before we dive in, I want to acknowledge a few people and resources that I found most helpful during my studies. Paul Hudak’s writing is exceptionally lucid. His original A Gentle Introduction to Haskell is a tremendous resource. Cale Gibbard wrote my two favorite monadic introductions: Monads as Containers and Monads as Computation. In addition, Jeff Newbern’s All About Monads contains a well written Catalog of Standard Monads. Finally, the experts on the #haskell IRC channel are always helpful.

Back to Basics

Before we talk about the syntax or semantics of monads, and before we step through any examples, we go back to basics. When I started learning about monads, I overestimated my understanding of Haskell’s type system. This section highlights the concepts that I overlooked.

Every monad is nothing more than a paramaterized type that implements a few functions. Let’s review paramaterized types by exploring the details of (Maybe a).

> data Maybe a = Nothing
>              | Just a

It’s straightforward to see that (Maybe a) can be used to represent values that either exist or are missing. It’s also intuitive that the variable a is a place holder for the type that may or may not be there (perhaps an Int). Fair enough, but there’s more.

First let’s break down the type’s name. Although it is often called the “maybe type” in conversation, its proper name is (Maybe a). The word Maybe is a type constructor and the character a is a type variable.

The type constructor Maybe is a function that accepts the given type variable a and returns the type (Maybe a). I found this notion confusing because you cannot call the Maybe function within regular code. For example, ghci prints out:

Prelude> Maybe 4
:1:0: Not in scope: data constructor `Maybe'
Prelude> :t Maybe
:1:0: Not in scope: data constructor `Maybe'
Prelude> :kind Maybe
Maybe :: * -> *

The last statement, using :kind, gives an indication that Maybe is a unary type constructor. We won’t stop to discuss notion of a kinds (partly because I don’t understand them well enough myself). We can safely skip that topic. The error messages are printed because the Maybe function is only valid within the context of type definitions, type class definitions, and type signatures. For example, you might write:

> catMaybes :: [Maybe a] -> [a]

Within this type signature, Maybe is a function being applied to the type variable a, to produce a type of (Maybe a). (Incidentally, the type (Maybe a) is passed in turn to the type constructor [].) This is code, but it is within the scope of type signatures. We’ll return to this distinction later when we replace particular type constructors like Maybe with a variable that represents any parametric type constructor.

The right hand side of the type definition lists one or more value constructors, separated by the pipe symbol. For (Maybe a), we have Nothing and Just a. Even though these value constructors are defined within the type definition, they are valid in regular Haskell code, as we can see with ghci:

Prelude> :t Nothing
Nothing :: Maybe a
Prelude> :t Just
Just :: a -> Maybe a
Prelude> Just 5
Just 5

The ghci output says that the function named Just takes some value x of type a and returns a value of type (Maybe a), which by definition equals Just x. We introduce the value variable x here to distinguish it from a, which is a type variable. Similarly, Nothing is a nullary function of type (Maybe a).

Note that unlike the type constructor Maybe, which produces a type named (Maybe a), the value constructors Nothing and Just produce values that have the type (Maybe a). One consequence of this distinction is the tendency for value constructors to be named after its type constructor. This is not a conflict because value constructors and type constructors are in different namespaces.

Finally, be sure to review the notion of Haskell type classes and instances. Type classes allow us to define a particular interface, and then instances allow us to declare that a type implements that interface. For the purposes of monads, we will be examining the type classes Functor, and Monad.

Functors

For whatever reason, I had it in my mind that I would put off learning about functors until I understood monads. I wasn’t sure what a functor was, but I also wasn’t sure what a monad was, and I wanted to take things one at a time. In retrospect, this was a foolish mistake because the concepts are related, and functors are much simpler than monads.

A functor is simply a fancy name for a type that supports the map function, which happens to be called fmap in the Functor class. In ghci you can see:

Prelude> :t map
map :: (a -> b) -> [a] -> [b]
Prelude> :t fmap
fmap :: (Functor f) => (a -> b) -> f a -> f b

As the types show, the map function only operates over lists, whereas fmap is generalized to operate over any parametric type. The idea is that we want to apply some function to every item within a collection. The Functor class is defined as follows:

> class Functor f where
>     fmap     :: (a -> b) -> f a -> f b

This type class definition is written in the language for types. The variable f is a placeholder for any parametric type constructor. We could instantiate the variable with any parametric type constructor, including Maybe. For example:

> instance Functor Maybe where
>     fmap f Nothing  = Nothing
>     fmap f (Just x) = Just (f x)

A minor point — do not let the reuse of the variable f confuse you. In the Functor class definition, f is a placeholder for a type constructor. Within this instance defintion, f represents the function that we want to apply to whatever is within the Just x value.

Let’s see what happens in ghci:

Prelude> fmap (* 2) (Just 4)
Just 8
Prelude> fmap (* 2) Nothing
Nothing
Prelude> fmap odd (Just 4)
Just False
Prelude> fmap odd Nothing
Nothing

For the list type, we simply have:

> instance Functor [] where
>     fmap = map

To be precise, there are a two semantic rules that every proper fmap implementation must abide by:

> fmap id      = id
> fmap (f . g) = fmap f . fmap g

Together, these rules ensure that fmap doesn’t modify the shape or order of its input. Most sensible definitions of fmap abide by these rules, so don’t think about them too hard.

The important takeway from this section is the generalization of map to any parametric type using the variable f within the type signature of fmap. This allows us to make any parametric type (such as [a]) implement fmap, satisfying the common need of applying a function to every item in some collection. In the case of (Maybe a), we apply the function to zero or one values. For lists (the [a] type), we apply the function to zero or more values.

The Monad Type Class

Now we turn to the Monad class. Perhaps surprisingly, we’ll hold off discussing how monads can improve your Haskell code. Instead, we simply introduce the methods of the Monad class, just as we did for the Functor class. We also introduce Haskell’s special monadic syntactic sugar.

Here is the Monad class definition:

> infixl 1  >>, >>=
> class  Monad m  where
>     return   :: a -> m a
>     (>>=)    :: m a -> (a -> m b) -> m b
>     (>>)     :: m a -> m b -> m b
>     fail     :: String -> m a
>     m >> k   =  m >>= \_ -> k

The type class’s two important functions are return and (>>=), which is conversationally called “bind”. The function (>>) is defined in terms of bind, and exists to simplify syntax. We’ll discuss fail later, but it’s typically used to handle exceptional results.

Don’t fall in the trap of trying to think about what each of these functions “typically do.” The meaning is different for each instance of the Monad class. We will examine particular implementations shortly.

First, let’s examine return. Despite its name, it has nothing to do with the standard flow control keyword in other languages. In Haskell it is not a keyword, and it is not a flow control operator. Instead, return is a generalized value constructor, similar to how fmap was a genearlized version of map. We can show this in ghci:

Prelude> :t Just
Just :: a -> Maybe a
Prelude> :t return
return :: (Monad m) => a -> m a

Both functions take a value of some type, call it a, and return a value of a type that is parameterized over a. The Just function always returns a value of type (Maybe a), whereas the return function can generate a value of any parameterized type that is an instance of the Monad class. It is an alias for one or more of the type’s value constructors. We’ll give use cases for return later, but for now understand that if you need to create a monad, you often use return instead of explicitly using the type’s value constructors.

Next, consider bind, or (>>=). It is very similar to the fmap function, as we can see in ghci:

Prelude> :t fmap
fmap :: (Functor f) => (a -> b) -> f a -> f b
Prelude> :t (>>=)
(>>=) :: (Monad m) => m a -> (a -> m b) -> m b
Prelude> :t (flip (>>=))
(flip (>>=)) :: (Monad m) => (a -> m b) -> m a -> m b

Both functions operate over a function and a parameterized type. The first two arguments are flipped, but that’s a small matter of syntax. Also, the functions have slightly different signatures, but the intent looks familiar.

Just like with Functor, there are also some rules that any well defined instance of the Monad class must define.

> return a >>= k                 = k a
> m        >>= return            = m
> xs       >>= return . f        = fmap f xs
> m        >>= (\x -> k x >>= h) = (m >>= k) >>= h

As with the fmap rules, don’t think about these too hard. The first two rules say that return doesn’t tinker its argument. The third rule relates bind to fmap, as we hinted above. The third rule is a sort of associativity.

Haskell provides special syntactic sugar for the bind operator within its do block. Haskell performs the following two translations for us:

> do e1 ; e2         = e1 >>  e2
> do p <- e1 ; e2    = e1 >>= \p -> e2

In the second case, if p does not pattern match with e2, then fail is called. These two translations allow us to write monadic code that implicitly calls the bind operator. One effect of this notation is that the resulting code resembles typical more familiar imperative code, as we’ll see in the next section when we look at examples.

Basic Example Monads

Let’s make these monadic functions concrete by looking at two basic monads: (Maybe a) and [a]. For some time, I was confused when familiar types like these were referred to as monads. It wasn’t clear to me that any parametric type which implements the Monad class is always a monad. The monadic functionality only shines we apply a monadic operator, such as bind, on a value with the monadic type.

Monadic Maybe a

Starting with (Maybe a), we define the two key monadic operators as follows:

> instance Monad Maybe where
>     return         = Just
>     Nothing  >>= f = Nothing
>     (Just x) >>= f = f x
>     fail _         = Nothing

The return function is simply an alias for the value constructor Just. The binding operator always returns Nothing if the first argument is Nothing. Otherwise, we apply the given function f to the value x paramaterized by Just in the first argument. Due to its type, the function f must return either Just x' or Nothing.

It’s helpful to think of this instance of the bind operator passing zero or more values from one function to the next. As the type signature of (>>=) dictates, each function must produce a value of type (Maybe a). Consider the following example.

Suppose we want to define a decrement operator over the natural numbers (all integers greater than or equal to zero). To seamlessly support inputs less than or equal to zero, we define our function as follows:

> decrementNat x | x <= 0    = Nothing
>                | otherwise = Just (x-1)

Note that decrementNat has the desirable signature a -> Maybe a. Now we can use the monadic bind function to perform multiple decrements. If we load the above function from a module Foo in ghci, we can write:

*Foo> Nothing >>= decrementNat
Nothing
*Foo> Nothing >>= decrementNat >>= decrementNat
Nothing
*Foo> Just 2 >>= decrementNat
Just 1
*Foo> Just 2 >>= decrementNat >>= decrementNat
Just 0
*Foo> Just 2 >>= decrementNat >>= decrementNat >>= decrementNat
Nothing

We can also use the syntactic sugar of do, to write a function such as:

> decrementNat3 x = do x1 <- decrementNat x
>                      x2 <- decrementNat x1
>                      decrementNat x2

Then, once again, in ghci, we can write:

*Foo> decrementNat3 2
Nothing
*Foo> decrementNat3 5
Just 2

Notice that once the bind function (as defined for the (Maybe a) type) encounters a Nothing, it forever generates a Nothing. It short circuits. Otherwise, the incrementally smaller value is passed along the chain.

Monadic List

The list type is also an instance of the Monad type class, defined as follows:

> instance Monad [] where
>     return x = [x]
>     m >>= f  = concatMap f m
>     fail _   = []

Once again, return is an alias for the value constructor []. The bind operator is best conceptualized in two steps. First, a 2d list (a list of lists) is created because the function f is applied to every element in the list m. Remember that f creates a list. Then all of those lists are concatenated together.

Consider a simple expression such as:

Prelude> [1,2] >>= (\x -> return $ odd x)
[True,False]

Alternatively, you could write:

> myodd = do x <- [1,2]
>            return $ odd x

What exactly is going on here? Remember that for lists, the bind operator is concatMap, and return is the list constructor. We might also write it as:

Prelude> concatMap (return . odd) [1,2]
[True,False]

So the short monadic bind expression applies the function \x -> return $ odd x to both 1 and 2 to create [True] and [False], which are then concatenated together.

We can expand this example to produce all pairs of a list l.

> allpairs l = do x <- l
>                 y <- l
>                 return (x, y)

Note that in this case there are two chained calls to concatMap.

To be continued. . .

These are the basic ideas behind monads. We have not covered the type class MonadPlus. We have also not explored many common instances of the Monad class, most notably (IO a) and (State a). Perhaps I’ll tackle those topics in a subsequent posts.

I expected to disagree with Gustav because I have written production-quality software in many languages, including Ruby, Python, Perl, C, C++, C#, Java, and Erlang. I’m currently learning Haskell in my spare time (and I’m loving it). I think that my efforts in all of these languages has kept me nimble. I’ve met a lot of one trick ponies who I think would benefit from the change in perspective that a new language brings.

Instead, I think Gustav makes several valid points. In fact, in a subsequent prefix to his post, he writes that in the past seven years he’s added two languages to his core set, and dropped one; so he’s had fairly decent turnover. He hasn’t been a Java horse for the past 10 years.

Even so, I would like to make a few quick points:

1. The real challenge is finding an efficient and productive way to keep learning and to stay in an innovative frame of mind. If you fall into the trap of punching the clock every day without staying aware of new approaches and techniques, then you’ll quickly fall behind.
2. Just as with exercise routines or diets, motivating forces are highly personal. I happen to think that I learn new languages rather quickly, so my learning curve is relatively flat. I also get a lot of pleasure and inspiration when I work in a new language, which carries over to concurrent projects in my old languages. Those benefits are personal though — I can’t speak for others.
3. Even a developer who prefers to maintain a small proficiency set should also have a willingness to tackle new projects in a new language. I never let a language get in the way of cooperation. I’m certainly quick to object to uncommented code or poorly organized components, but I ultimately do not care what language is picked. I have seen far too many people who immediately jump to the question of “what language will we use?” when the better question is “how should we solve this problem?”

I caught the functional bug last year when I wrote a distributed computing framework in Erlang for a large investment bank. The distributed computing features of Erlang were certainly nice, but I also appreciated the code’s predictable execution. If the code compiled, it almost always worked as expected.

Sparked by that experience, I started looking around for another functional language to learn. Rumblings in the blogosphere about Haskell’s strict, succinct expressions caught my attention, so I started learning the language and hacking up some code.

Thanks to excellent documentation coupled with expert answers on the #haskell IRC channel, I feel like I’ve ramped up fairly quickly. I intend to give a little back to the Haskell community by writing posts that attempt to clarify concepts that I found confusing. I’m currently preparing a post that offers yet another introduction to monads. I also want to post some code that I’ve written to allow the expression and manipulation of recurring dates.