I developed this project together with my colleagues Liewe Thomas van Binsbergen and the portuguese guy with the longest name I’ve ever seen: João Miguel Queiroz de Ataíde Agorreta de Alpuim. As a final project for the course, each “team” of students had to submit an entry to a competition that involved the simulation of ants searching for food in an environment. This “task” was also the one selected for the programming contest of the International Conference on Functional Programming in 2004…

The official task description defines an assembly language for the ants, and that the ant colonies of the two teams will fight in “rounds” in a championship (with random maps chosen for each round); in each round the goal is to collect the most food possible at your anthill after a certain amount of time. The championship was run in a simulator, and the following animated gif shows how a small part of a simulation might look like:

In this example, our team is the “red” team, and we are competing agains the all-time winner (in blue). Even though in this particular example we are losing by a long shot (there is little food in our hill), we weren’t so bad when competing with our classmates…

Anyways, the project (uploaded to GitHub) is not about ant assembly, but about Advanced Functional Programming, so you might ask “What the hell does this all have to do with Haskell?”. The answer is simple: our real task was to implement an Embedded Domain-Specific Language (EDSL) in Haskell, allowing to express with a high level of abstraction the strategies we wanted our ants to follow. The “deliverables” of the project, thus, were twofold:

• Ant EDSL library: A high-level API, made of fundamental strategies and of combinators allowing the user to build more complex strategies from simpler ones.
• The strategies themselves: Using the developed API, we needed to hand in two strategies (ant assembly files), that would take part in the championship against the rest of the class.

Our EDSL was developed with a layered architecture, where the the evaluation of user-accessible functions in the API resulted in a value of type AntImperative, that was then converted (compiled) to proper ant assembly. This paradigm of EDSL is called “deep-embedded”. In the following figure, you can have an idea of how the project is structured:

Also, here it goes one of the basic strategies we submitted for the contest, so that you can have an idea of how it “feels” to write strategies in our EDSL:

This particular strategy was based in the fact that ants born in the hill’s corners (each anthill had 6 corners) would draw “highways” with pheromones, that would mark a quick way for other ants to go back home whenever needed. Besides this, ants that found food would also leave a “trail” of pheromones leading to the highways, and these trails would consist a kind of “local roads”.

Finally, as a prize for your pacience in reading this post until here :), you can take a look at the slides that we prepared for the presentation of the project (click on the image to start the download):
presentation-ants-edsl-afp2012

That’s it! As soon as I have another cool project to show you guys, I will tell more about it here… See you soon! :)

Just the smart people will get it:

Just because “ones = 1 : ones” was too much of a boring example…

In that Coding Dojo we wanted to solve the “Game Of Life” problem. The goal was mainly to – given an initial configuration – evolve the world in one generation and print back this evolved state. For those of you who never heard about Conway’s Game of Life, its article on Wikipedia can be very clarifying.

So we did it, and we solved the problem, but – as always – I wanted very badly to try to solve the same problem using Haskell (instead of Python). At home, I coded it up in Haskell in around 30min, and the code was concise and elegant… In fact, this was so easy that I decided I needed some bigger challenge, something graphical, why not? Then I gave the awesome Gloss graphics library another chance, and I was AGAIN impressed with the results.

So let’s start our Haskell Kata routine, by first describing the problem itself and then the beautiful Haskell solution…

Problem Description

(This problem description is blatantly copied from the correspondent Coding Dojo Wiki entry, as of 2012-01-19)

This Kata is about calculating the next generation of Conway’s Game of Life, given any starting position. Take a look at Wikipedia for background.

You start with a two-dimensional grid of cells, where each cell is either alive or dead. In this version of the problem, the grid is finite, and no life can exist off the edges. When calculating the next generation of the grid, follow these rules:

• Any live cell with fewer than two live neighbours dies, as if caused by underpopulation.
• Any live cell with more than three live neighbours dies, as if by overcrowding.
• Any live cell with two or three live neighbours lives on to the next generation.
• Any dead cell with exactly three live neighbours becomes a live cell.

You should write a program that can accept an arbitrary grid of cells, and will output a similar grid showing the next generation.

Input and Output

The input starting position is given through a text file that looks like this:

........
....*...
...**...
........

And the output could look like:

........
...**...
...**...
........

This format was chosen because it is very easily parsed in most languages. OBS: It is VERY, VERY easily parsed in Haskell :)

Proposed “solution” in Haskell

SPOILER ALERT: DO NOT KEEP READING if you want to try solving this problem for yourself.

As I said in the beginning of the post, my code isn’t really a solution to the given problem, but rather an improvement over it. It improves a simple solution in two ways:

1. It handles more than one generation. It is actually a live simulation
2. It has a graphical interface to display the simulation

Even though the code is bigger (because of these enhancements) it is still very concise and readable, totaling some 150 lines of code (with lots of whitespace). And to keep it simple, we are going to start our tour of the solution by the module that deals with the “original” problem: we are going to look first at the functions to read and evolve the board for one generation. First of all, the parser for a starting position (imports omitted for brevity):

Our parser was written using the easy-to-use, efficient and popular Parsec library for Haskell, that allows us to describe a format to be recognized (a grammar) in Haskell itself, in a very readable and concise way. Parsec is a parser combinator library, which means that we build our “big” parser by combining smaller parsers, which are built by combining even smaller ones, and so on… until we reach the primitive parsers that come with Parsec like, for example, “char”, used to define the parser for a dead cell in the first line of the code above.

Indeed, the parsers “dead” (for a dead cell) and “alive” (for a live cell) are the most fundamental, and what they do is pretty simple: they map a dot or an upper-case ‘O’ to False or True, respectively. We can take a look at the type signatures of “char” and “fmap” if we want to know more precisely what they do:

fmap ∷ (a → b) → f a → f b
char ∷ Char → Parser Char
...
map ∷ (a → b) → [a] → [b]

First of all, let’s talk about “char”. The exact type of “char” (as in the Parsec documentation) is more general and uses type classes. The type shown above, however, is a valid specialization of the general type, suiting our usage. You can see that “char” takes a character and gives us a Parser that recognizes that character. However, we want “dead” to be of type Parser Bool, that is, a parser that returns a boolean; so we need a function that converts Parser Char to Parser Bool… And that’s the point where “fmap” comes to help us!

You can see that not only the name, but also the type of “fmap” is very similar to that of “map”. In fact, “fmap” is a generalization of “map”: while “map” works only over lists, “fmap” works over any container. Well, then “fmap” is applicable to our situation, that’s because anything of type Parser a is a monad, and any monad is a container (the fancy word for container is “Functor”). The last interesting detail is the function that we map over (char ‘.’) and (char ‘O’): The usage of “const” means that we don’t care about what the Parser returns, as long as it succeeds, we return either a True or a False.

The remaining parser code is even simpler; the top-level function in the parser module (“parseBoardFromFile”) is the only one that still deserves some commentary:

This function takes a file name as input (FilePath is just a synonym for String) and performs some IO actions (reading the file and parsing its contents). As a result of these actions, it returns a matrix of booleans (that is, our Board \o/). The function “parseFromFile” comes from Parsec, and it does exactly what its name says, with a return type of Either ParseError [[Bool]]. Because “result” has this type, we use the “either” function in the next line. The “either” function is used whenever you need to decide what to do based on a value of type Either. In our case, if the result is a correctly parsed matrix, we return it as-is (that’s what “id” does for us). But if it’s an erroneous parse, then we convert the ParseError to a string and terminate the program showing the error message (that’s what “(error ∘ show)” does for us).

Enough for parsing now, and on to what really matters: evolving a board one generation. We take care of this task in the Evolution module. The most important functions of this module are “evolve” and “eval”. “eval” is given a position on the board and returns whether the cell in that position should be dead or alive, based on its surroundings. “evolve” is given a board and just applies “eval” all over it to create the next-generation board. With one important consideration: it only looks at the inner cells in the board, i.e, all border cells are considered always dead. Here’s the code for “eval” and “evolve”:

The function “aliveNeighbours” takes a board and a pair of coordinates, returning how many of the 8 surrounding cells are alive. Its definition is pretty boring and straightforward, so I won’t explain it – you’ll have to believe that it works :)

So, the code that we saw so far almost solves the original Kata problem – we only needed to add some pretty-printing of the board… BUT! But we are going to do something much nicer, much cooler: we are going to display our simulation in a graphical interface, like this:

The "Gosper glider gun" o/o/o/

Before getting too excited, I have to warn you: the module dealing with drawing the graphics is the largest one (It has around 50 lines of code). However, if you run the program for yourself and watch the AWESOME resulting simulation, you’ll realize that 50 lines is a very good mark :)

Anyways, 50 lines is still too much to be embedded in a blog post, so I’ll only give you the highlights – namely, the functions “drawModel”, “layout” and “activate”. Here’s their code:


Let’s begin with the easiest one: “activate” takes a matrix of pictures (all of them are squares) and assigns a color to each one, with the color depending on whether that position of the matrix is active or not in the underlying Game of Life board. The way in which we implemented “activate” is VERY typical in functional programming, and benefits largely from lazy evaluation. First, we apply “paintersFromBoard”, which has type:

paintersFromBoard ∷ [[Bool]] → [[Picture → Picture]]

It takes the board and transforms it into a matrix of functions. More specifically, each function in this matrix is a painter, transforming a picture into a new one by changing its color. Now we have two things to combine:

1. A matrix of default-colored squares (by default they are all black)
2. A matrix of “painter functions”, one for each square

To combine these, we use “applyFunctionMatrix” (not shown above). Its definition is very straightforward, but also very typical of functional programming languages. We define “applyFunctionMatrix” by “lifting” the usage of “applyFunctionList” to the outer list of the matrix (the list of lines). “applyFunctionList” is beautifully defined as follows:

Continuing in the Drawing module, we reach “layout”. The purpose of this function is to – given a list of “unplaced” pictures (all overlapping each other) – spread them with some padding between each other so that they fill a horizontal or vertical line. We want the resulting “array” of pictures to be centered around the point where all overlapping pictures currently are – that’s why we calculate the “middle” index as being half of the list’s length. We then use “move” to displace each picture by “i” steps in direction “dir”. The “move” function knows the size of the cells, so we only need to pass it how many “steps” we want to displace a cell, and a pixel-exact translation will be done for us.

At last, the most important function in the drawing module – the core of the simulation: “drawModel”. Its type, Board → Picture, already tells us how much important it is. At each simulation step, the model is transformed by a call to “evolve”; then, our function “drawModel” is called by the Gloss Simulation Engine to render to model into a Picture. The definition is a simple pipeline with the following steps:

1. Create a l × c matrix of same-sized squares – by default they are all black and placed at (0,0)
2. Paint the squares according to the model
3. Place them – equally spaced – in a nice grid

Ladies and gentlemen, having understood how to do a simulation step (“evolve”) and how to display the model (“drawModel”), we are almost DONE. I am only going to show you how the “simulate” function from Gloss connects these pieces together. Our main function is basically just a call to “simulate”, like this:

The “simulate” function takes 6 parameters, and while it might seem too much, they all actually make sense:

1. display: defines how gloss is going to show the simulation – the size and position of the window, etc.
2. bg: background color for the drawing area
3. fps: how many simulation steps happen in one second of real time
4. initial: the initial model (that we read from the file)
5. drawModel: a function that transforms the model into a Picture
6. step function: a function to advance the model one iteration. We use the lambda to ignore some parameters that are irrelevant for us

THAT’S IT! TADA! Now we are done. As always, you can download the cabalized package with the source code from my GitHub repository (https://github.com/joaopizani/katas/tree/blog-05-2012GlossGameOfLife), build and run it as follows:

$ cd GlossGameOfLife
$ cabal-dev install

Have fun!

But then we decided to have more fun and feed some more “organized” bytes to the sound card – we would generate our audio samples programmatically. And what better tool to do some data generation than Haskel!? So I started writing my first audio synthesizer, and after some hours it was ready and working awesomely… I was really excited with the results, so I just NEEDED to share this nice piece of code with the world :)

My Haskell tone synthesizer takes a “score file” as input, that describes the tune you want the synthesizer to generate. This input file has a syntax very similar to the old Nokia Ringtone Composer syntax… The program reads the score from the file and outputs a lot of bytes to standard output. If you redirect the standard output to your sound card, you will hear your favorite tunes! So let me guide you through a tour of this program’s source code:

This tour will be in top-bottom style: we will start by looking at the Main module and its major processing steps, and then dwell a bit deeper into some of the most important functions of each module. So, to start, here is the entire Main module:

As you can see in the second line of “main”, we need 2 command-line parameters: “file” and “bpmStr” (which will be read into an Int called “bpm”). “file” is the name of the file containing our score, and “bpm_” is the tempo in which the song will be played (in beats per minute – BPM). We then proceed to parse the score from the file, using the “parseFromFile” function (from Parsec). This function takes a parser to apply and a filename from which to read an input stream. Our conveniently-named “score” parser is defined in a separate file (Melody.hs) and will not be further discussed… You can see it if you download the full source code at the end of the post.

The “parseFromFile” function has type Parser a → String → Either ParseError a, which means its result is Either our desired outcome (Right [Note]) or an error (Left ParseError). We then apply the “either” function over “parsedScore” to do case analysis: in case a perfect parse ocurred, the “id” function is applied and the result is kept as-is; in case a parse error has been found, we apply (error ∘ show) – which just displays the error message on standard output and terminates the program. The next “big step” in the program is to turn the music into concrete form.

The parsed score is a sequence of musical notes with relative durations (1, 1/2, 1/4, etc.) and abstract pitch names (C, D, E, etc.), so the the task of “concrete bpm” is to take each abstract note and make both pitch and duration “concrete”. Its type is:

It takes a Tempo and a Note and produces a pair representing a concrete sound, where the first element is the frequency of this sound (in Hz) and the second element is its duration (in seconds).

After we have our list of sound pairs to play (“concreteMusic”), we reach the last and most important step, which is to actually generate the samples and output them, using “concreteMusic” to guide the generation process. This is done by “produceStream”. For each pair of frequency and duration “(f,t)”, the following is done:

1. Samples for a (infinite) square wave of frequency f are generated by a call to “signal f”.
2. This signal is then “sliced” to obtain a piece of length t, by a call to “slice t”

Finally, this whole sequence of “signal slices” is concatenated together into a ByteString which goes to standard output… Now going deeper, we will dive to file “Signal.hs” and take a look at the definitions of “signal” and “slice”, along with some helper functions:

Let’s start explaining this module (“Signal.hs”) from the ground up: our signal is an infinite sound wave. The most characteristic feature of a wave is that it’s periodic, which means it’s just an infinite repetition of a pattern. Therefore we have the “period” function here, which, given the number of samples to generate and the desired waveform, generates a list of samples that follows this waveform. So that’s how “signal” uses “period” in order to make a wave: it takes the requested frequency and then calculates (according to the sample rate) how many samples are there in one period. It uses the “period” function to generate a “singlePeriod”, which it then cycles and packs into an infinite and repetitive ByteString. The “silence” function is only there to produce a “dummy” period when we need a pause. It doesn’t need to have more than one sample, however, because it’s going to be transformed into an infinite ByteString of 0′s anyway…

The “cycleAndPack” function takes one period ([Int]) and transforms it into a (lazy) infinite ByteString. Its type should be very self-evident, after all. The “(map fromIntegral)” part transforms our [Int] into [Word8], which then serves as input for “B.pack”, which actually creates the ByteString, then made infinite (repeated indefinitely) by “B.cycle”.

Now to the slicing! :) The task of the “slice” function is to transform an infinite wave (infinite ByteString) of a certain frequency into a finite wave (finite ByteString), with the requested duration in seconds. The type of slice is:

Which makes evident its role as a “ByteString-transforming” function. The definition of “slice” – in point-free style – also helps explaining what it does: to slice an infinite ByteString is just to take n of its first elements, where n is the product of the desired time in seconds by the sampling rate in Hz.

Before continuing to show you the code, allow me to take a slight detour and say how Haskell’s purely-functional features help us express this program in such an elegant (and still efficient) way:

1. Lazyness: Due to the possibility of using lazy evaluation, we were able to represent sound waves as infinite streams of samples, separating stream generation from stream usage.
2. Referential transparency: Haskell’s purity means that every function is transparent. Thus, the value of any expression needs only to be computed once, and can be substituted for all occurrences of that expression. This is important because – in a single song – several notes will have the same frequency (and therefore will result in identical signals). Thanks to referential transparency, it is guaranteed that we only need to compute “signal f” once for each f, and thus we will only have one stream for each frequency in our song.

Well, having understood how “signal” and “slice” work, the puzzle is now almost entirely solved. The only remaining mystery should be how the actual input file (in Nokia-Composer-style) is parsed, but – as I said before – the parser is mostly straightforward and uses just basic Parsec. The input parser is the largest single piece of code in the whole synthesizer (only relatively big, but still small), so I’ll only show you a summarized version here and won’t even explain it. You can grab the full code at the end of the post and take a more careful look… So here it goes, the core of our input parser:

And now, a bit of fun: to finish up the post nicely, I have included some sample song files in the synthesizer’s tarball; then I ran the synthesizer over them and encoded the output as MP3. Now you can listen to two catchy tunes generated by Haskell!

• Europe – The Final Countdown:
  • Song score:

    p4, p8, b16, a16, b4, e4, p4, p8, c'16, b16, c'8, b8, a4, p4, p8, c'16, b16, c'4, e4, p4, p8, a16, g16, a8, g8, f#8, a8, g4, p8, f#16, g16, a4, p8, g16, a16, b8, a8, g8, f#8, e4, c'4, b2, p4, b16, c'16, b16, a16, b1

  • MP3: Download audio file (finalcountdown.mp3)

• Zelda Main Theme:
  • Song score:

    a#4, f4, f8, f16, a#16, a#16, c'16, d'16, d#'16, f'2, p8, f'8, f'8, f#'16, g#'16, a#'2, p8, a#'8, a#'8, a#'8, g#'16, f#'16, g#'8, g#'16,  f#'16, f'2

  • MP3: Download audio file (zelda.mp3)

Finally, as always, there comes what REALLY matters: The Source Code. The code of this synthesizer, along with several of my other “toy programs”, lives in the “Katas” repository on GitHub. You can check it out here: https://github.com/joaopizani/katas . Download the code as a .zip file or even clone the repository and then play freely!… I strongly recommend that you use cabal-dev to build all your Haskell projects, so in case you want to follow my recommendation, the steps to build and run (in Unix) the synthesizer are something like this:

cd ToneSynthesizer
cabal-dev install
./cabal-dev/bin/tonesynthesizer songs/  | aplay -t raw -f U8 -r 16000

I wish you all a whole lot of excitement and fun while coding in Haskell, and would certainly appreciate suggestions and critique regarding the code I just shared with you. That’s all, folks! :)

Our Dojos were pretty exciting, indeed, to the point that sometimes we would each rush home after the Dojo to try and solve the problem in our favorite language/framework. I solved some of these short programming challenges in Haskell, and I now want to post them here in the blog so that more people can enjoy the – supposed :) – beauty of the code and give suggestions. In the first of this hopefully long series of posts, we are going to play with BankOCR.

Problem description

The acronym “OCR” in the problem description gives the hint: we want to recognize characters. But our task is much easier than building a full-fledged optical recognizer…

Our program’s input is going to be a text file containing digits from 0 to 9 in a “LED-display-like” format. Like this:

    _  _     _  _  _  _  _
  | _| _||_||_ |_   ||_||_|
  ||_  _|  | _||_|  ||_| _|

Our input text file has only one line of “7-segment” digits, where each digit has a height of 3 “segments” (lines) and a width also of 3 “segments” (columns). Our program must read the contents of this file and print the corresponding number on the standard output, which for the above example would be “123456789″.

In the official problem description, there are several additional usage scenarios for this challenge: recognizing several lines of digits, validating the numbers and using error-correcting codes to return good numbers even with “dirty” input. We are going, however, to tackle only the basic challenge, which is to recognize a single line of well-formed digits.

Haskell solution

SPOILER ALERT: DO NOT KEEP READING if you want to try solving this problem for yourself.

I believe that a Haskell solution for this problem turned out very idiomatic and relatively easy to understand. Besides, it is also very short: ignoring the lookup table, we have only some 10 lines of code! There it goes, the relevant part of the solution:

Our solution is a typical Unix filter, and this very much justifies our usage of the function “interact” to define main… The “interact” function has the following type:

interact ∷ (String → String) → IO ()

“interact” takes a function from String to String as parameter and does Input/Output with the help of this function. One way to express what “interact” does is by saying that it connects standard input to standard output, but allowing the information to be transformed by the user function as it flows down the pipeline :)

Now for some commentary on the core of our recognizer, the “parse” function:

1. The “transpose” function is in the standard library (the “Prelude”), and works over lists of lists (matrices). It turns lines into columns and vice-versa (pretty obvious :P)
2. “lines” is also in the Prelude, and has type String → [String]. It takes a big String and breaks it down to a list of smaller Strings, one per line
3. The “lookup” function returns a value from an associative table. In Haskell, an associative table is just a list of pairs: [ (key, value) ]
4. “lookup” gives us a value of type Maybe Char. That because, generally speaking, the key might not be in the table (it maybe is there). So, to transform a Maybe Char in the Char that we want, we use “fromJust”. Of course that if we pass “Nothing” (a nonexistent value) to “fromJust”, the program will crash. We are only using “fromJust” here because WE ARE SURE that all digits are in the table…
5. The “chunk” function is in the “Data.List.Split” module, and does what its name (and parameter) suggests: returns same-sized groups of elements from its input list
6. About “dummy”: The problem description states that there’s a blank column between any two digits (as a separator). So, effectively, we could treat each digit as having 4 columns – EXCEPT FOR THE FIRST ONE. So, to avoid handling corner cases, I forced the first digit to also have 4 columns by adding a “dummy” column to it. This “strategy” of transforming a corner case into a normal one and THEN treating all cases equally is VERY often found in functional programs

Well, after understanding how it works, we can now run the program, like this:

joaopizani@rabbithole:~$ cat twohundredfiftysix
 _   _   _ 
 _| |_  |_ 
|_   _| |_|

joaopizani@rabbithole:~$ cat twohundredfiftysix | ./OCR
256

Of course you don’t have to believe me, and you can check that the program work by yourself. Copy the code from my “katas” repository on GitHub (https://github.com/joaopizani/katas/blob/blog-05-2012/BankOCR/OCR.hs), compile it and run it! There’s a small dependency on the “Data.List.Split” module, so the commands for compiling your source file and running the program are as follows:

cabal install split
ghc --make OCR.hs
cat <input-file> | ./OCR

That’s all, folks! Thanks for reading and have FUN coding in Haskell… In case you have any suggestion or you want to criticize the solution in any way, please do so in the comments :)

At that time I discovered that there are A LOT of monads in Haskell, and that A LOT of them are useful and popular – even though you might not know that they are monads… There is the State Monad, Parser monads, Reader and Writer monads, the Error monads, the Either Monad, the Maybe Monad and even the List Monad!!! YES! (Maybe a) and [a] are monads! :D Well, “all of these things are monads, that’s very nice, but why should I care?”, you might ask. I hope to give you just a bit of an answer with the example in this post.

In this post, I will assume that you have at least some experience with Haskell, and that you have messed around with at least IO (maybe with Maybe too, hun? :P)…

So, every year we have a tradition in Brazil, which is a big lottery run on December 31, with a huge prize. This year my family bought 180 tickets, and I wrote a program to check if any of them had the 6 winner numbers shown on TV. I wrote this program in Haskell – of course – and this time I was, again, forced to deepen my understanding of monads AND monad transformers to get it done.

The program should work as follows: A file containing all 180 tickets (each with 6 numbers) must be read. Then 6 rounds of user input must happen: in each round, the user types a number and the program matches the current collection of user-typed numbers with all tickets. Then, the 5 tickets with the most “lucky” numbers are printed on the screen. Again, six of these “rounds” must happen.

I started modelling my program from the bottom-up, by defining a datatype to represent a lottery ticket, a “Combination” of lottery numbers:

Notice that a Combination has two sets of ints, a “lucky” and an “unlucky” one. The lucky one contains the numbers belonging to this combination that “showed up” on TV, while the unlucky ones are the rest… Also, the Ord instance for Combination is interesting: a combination is “larger” than another if the size of it’s lucky set is bigger. I use “(flip compare)” there just to make clearer that we are defining the notion of “larger” instead of “lesser or equal” (more common).

I then proceeded to implement the reading of the file into a list of Combination. This part is a bit out-of-context in this post, but I tried to make nice use of monadic features even here:

Comparing the types of “makeCombination” and “makeCombinations”, for example, you see that they have a lot in common. I think that most people would implement makeCombinations as “makeCombinations = map makeCombination”. I just used “liftM” to make very clear that List is a Monad. Thus, we are lifting the “makeCombination” function into the List Monad. Then, at the definition of “readCombinations”, we have to use “liftM” again, but this time we lift into the IO Monad. So we use “liftM makeCombinations”. The expression “liftM makeCombinations” has type IO [[Int]] → IO [Combination], and “readMatrix” has type FilePath → IO [[Int]], so the types match nicely and allow an elegant composition, like this :)

(FilePath → IO [[Int]]) ∘ (IO [[Int]] → IO [Combination]) ⇒ (FilePath → IO [Combination])

Going further down the code, we reach the “core” function of our lottery checker: a function called “matchWithCombination”, which takes a “probe” (a number that showed up on TV) and one combination, returning a new combination with its lucky and unlucky components updated in case of a “match” with the probe:

We use IntSet.intersection to “match” the probe with the unlucky numbers, and then we update the current lucky set, by uniting it with the possible new lucky guy. The definition of “matchWithCombination” also shows a nice syntactical feature of Haskell: allowing us to both define AND use functions in infix form, by just putting backticks around the function name. Well.. we now define matchWithCombinations, very obviously: it’s ALMOST just a map (a lift to the List Monad), but we need to keep the probe argument as it is (unlifted), so that’s why the partial application:

Our program is now quite full-featured. Using matchWithCombinations. we can already take a number and see where it appears on all tickets. Two of the requirements we defined earlier are lacking, though:

1. We need input (the user needs to type in the numbers in the terminal) and output (print the top 5 tickets on the terminal)
2. We need to perform 6 (input → process → output) “rounds”

Our “matchWithCombinations” function can only do ONE “update” step, so we need to keep “threading” the results of calls to it in a chain, like this (sort of):

(matchWithCombinations <user-input> (matchWithCombinations <user-input> (matchWithCombinations <user-input> originalCombs)))

Usually, to accomplish this sort of “threading of a state” between function calls, we use the (obviously named) State Monad. And, as you might have already guessed, to perform input and output, we use the almighty IO Monad. It’s nice to see how each “layer of functionality” in your program corresponds to a layer in the “Monad onion” that your program becomes. So here we need to combine State and IO, two monads… Keep this in mind.

In a slight detour of our monad-combining craze, let me introduce you to the simple and humble “askForNewNumber” monad (a function in the IO Monad). Its task is to read a line of input from the terminal and (do its best) to convert it to an Int:

Now we want to use “askForNewNumber” in a more sophisticated monad, called “includeNewNumber”. The “includeNewNumber” monad will keep a state consisting of our combination list, and will (each time it’s called) read a number from the terminal and update the state with the newly matched combinations. The type of “includeNewNumber” has to be a combination of IO (because it uses “askForNewNumber”) and State. But how can we combine two monads??

Well, the good news is that we can usually combine two monads into another monad, by using this nifty thing called “monad transformers” :P In our case, we want to “transform” mere IO into a “State IO”. Look at the beautiful definition of “includeNewNumber” by yourself:

Literally, the type of “includeNewNumber” is StateT [Combination] IO (), which means that we applied the “State Transformer” to the IO Monad, the type of our state being [Combination] and the type returned by IO being () (the unit type). StateT “wraps” IO with a layer of State, so now our program “onion” has officially two layers of functionality! Nice, hun!? :D Before going on, just one little explanation: IO must always be the innermost layer, mainly because when running the program all other layers are “peeled off”, and IO () is what we need to give to “main”. The task of “peeling off” IO itself lays with the Haskell runtime system, and is out of our control :)

In the body of “includeNewNumber”, we need again to lift “askForNewNumber”, so that it resides on the outer StateT layer. After getting the probe we modify the state held by the monad using “matchWithCombinations probe”. Now we are VERY close to getting this program DONE®. In fact, we are so close that we could now run “includeNewNumber” six times… the numbers would be read and the combination list would be updated correctly; the only problem is that nothing would show up on the screen :(

Of course we are going to implement the last requirement (print the top 5 combinations after each round), but this optionality shows that monads (and monad transformers) allow you to write software in a very composable way, in which independent features are implemented in independent code. A very high Separation of Concerns indeed. Let’s go on then with the implementation of our “feature full” function: “includeAndPrintTop5″

We first include a new number and get the (already updated) combinations state into “combs”. Then we pass “combs” through a pipeline which will print the top 5 combs on the screen. At the end of the pipeline, we need “lift” again, to transform the IO () returned by putStrLn into the desired StateT [Combination] IO ().

Dear reader, behold! Now comes the end of this post: I will show you the implementation of “main” for the lottery program…. With 2 lines of code! :)

First things first: we read the file into the suggestively-named “initial” value. We also need to perform 6 rounds of “includeAndPrintTop5″. That’s what “replicateM_ 6″ is doing for us. If you want, you can do this repetition manually, like this:

execStateT (includeAndPrintTop5 » includeAndPrintTop5 » includeAndPrintTop5 »
            includeAndPrintTop5 » includeAndPrintTop5 » includeAndPrintTop5 » return ()) initial

Finally, we use execStateT to “peel off” the State Transformer and leave the rest of the job to our friend, IO (). The arguments to execStateT are the state monad it needs to “exec” and an initial state. It then runs the monad and doesn’t care about what is returned (in case you want the returned value, “evalStateT” is for you).

DONE! TA-DA! :D Please, do not believe my black magic. Grab the code on my “katas” GitHub repository https://github.com/joaopizani/katas and run for yourself, then change it and play with it… Have fun :)
PS:

1. If you played with lists before (you should have), you will know the “replicate” function from Data.List… Indeed, “replicateM_” and “replicate” work VERY similarly. Take a look (≡ means “is equivalent to”):

   replicate 6 1   ≡ 1 : 1 : 1 : 1 : 1 : 1 : []
   replicateM_ 6 m ≡ m » m » m » m » m » m » (return ())

   Now you can already start to imagine how List is a monad, can’t you? ;)

2. If you want to really know how “1 : 1 : 1 : []” and “m » m » m » (return ())” are related, take a look at the source code. Seriously, it’s HERE.

On December 31, 2011, I spent my morning and afternoon writing a program that would help me check if I had won the national New Year’s lottery. Of course, being such an important program, it HAD to have a nice, beautiful graphical interface. And of course the language I was going to use was Haskell; after all, I wanted to have some FUN writing it :)

I remembered that some months ago I came across the fantastic gloss library for Haskell, but didn’t have much time to play with it… so I decided to give “gloss” a try this time. Gloss is a Haskell library that allows the user to create and run 2D static images, animations and GAMES! It runs on top of OpenGL, so – if you have a reasonable graphics card – your game can even be fast :)

What I needed to draw in my lottery program was actually too simple and boring (just some colorful numbers), so in this post we’ll create a nicer animation with gloss: we will design a clock! Yes, a classic analog clock with three dials, sort of…

First of all, a huge part of the stuff that gloss manipulates has the type “Picture“. And there are several convenient functions for creating fundamental pictures and transforming one picture into another. In fact, there is a “rectangleSolid” function, which is exactly what we need to create the dials of our clock. Here’s a black 50px by 200px rectangle:

rectangleSolid 50 200

We need three of these rectangles for our “clock”, one for each dial (seconds, minutes, hours). And each of them has a differente length. So this is how we defined our dials:

baseLength w = 0.75 * w
secondsDialLength x = baseLength x
minutesDialLength x = secondsDialLength x * 0.75
hoursDialLength x = minutesDialLength x * 0.70

baseDial = rectangleSolid 15
secondsDial x = baseDial (secondsDialLength x)
minutesDial x = baseDial (minutesDialLength x)
hoursDial = baseDial . hoursDialLength

I made the length of our dials variable, and it all depends on the parameter of “baseLength”, which is “w”. This is going to be the width of our clockface. You can see that we have three FUNCTIONS defining the dials, so the dial lengths are variable, but the proportion between the dials is fixed by us… Besides, all dials have the same width, so that’s why we defined “baseDial = rectangleSolid 15″. We are able to “fixate” or “bind” one parameter of rectangleSolid to 15, thus “baseDial” needs only one more parameter, which is the dial’s length. This ability to “bind” functions partially is a very nice feature of Haskell called “currying”. Chech it out here if you want to know more: Currying

hoursDial = baseDial . hoursDialLength

The definition of “hoursDial” in the last line of the block seems to be very different from the others, doesn’t it? hoursDial is still a function, but where is it’s length (“x”) parameter?? Well, we don’t need it, because hoursDial is defined as a composition of the functions hoursDialLength and baseDial. Remember high school?

(f ∘ g)(x) = f(g(x))

So now compare the two definition of hoursDial below, substituting “baseDial” for “f” and “hoursDialLength” for “g”. Nice, hun?

hoursDial x = baseDial (hoursDialLength x)
hoursDial = baseDial ∘ hoursDialLength

Very often in Haskell we can use function composition to make code look less verbose (with less “dirt”) and easier to read.

Now, going on with our clock! Until now, we have got 3 nice static dials. We now need to make them move :) In gloss, we can make our pictures move by adding an extra parameter to the picture definition: the time. Take a look at this:

movingSquare t = rotate (90 * t) (rectangleSolid 100 100)

Our “movingSquare” is now an animation. Animations have type (Float → Picture), i.e, they are functions that give us a picture (a frame) for each instant of time! Cool idea, don’t you think? The time parameter (“t”) is the number of seconds elapsed since the beginning of the animation. Thus, in the example above, we are rotating our little square 90 degrees per second…

But the seconds dial of our clock needs to turn 6 degrees per second (in order to turn 360 degrees in one minute). And the minutes dial needs to be 60 times slower than the seconds dial, and so on… Thus, that’s how we define the speeds of our dials:

secondsRotationSpeed t = 6 * t
minutesRotationSpeed t = secondsRotationSpeed t / 60
hoursRotationSpeed t = minutesRotationSpeed t / 60

Our speed functions define how much a dial is turned (degrees), according to the time (seconds) elapsed. And now, with the speeds defined, we can very easily define our “moving objects” – our animated clock
dials:

seconds x t = rotate (secondsRotationSpeed t) (secondsDial x)
minutes x t = rotate (minutesRotationSpeed t) (minutesDial x)
hours x t = rotate (hoursRotationSpeed t) (hoursDial x)

They still take that length parameter (“x”), but now they also take the time parameter (“t”). And the “core of the movement” here is the function “rotate”. The amount to rotate depends on the time, and the picture to be rotated is parameterized by the length we give (“x”).

Well, well, well… We can have now our clock. It will be very minimalistic (Apple style :P), so it will ONLY contain three dials and nothing more. If you have some Pictures, and want to build one single Picture
out of them all, the appropriately named “pictures” function from gloss can help you:

clock x t = pictures [dial x t | dial <- [seconds, minutes, hours]]

Our clock is an animation, so it has that trailing time (“t”) parameter, plus it has a variable size, which we pass throught the x parameter. We take each of our animated dials, and apply the SAME parameters to all of them. What it means, of course, is that “global time” “runs” at the same speed for all dials. This is not the case when the clock travels close to the speed of light, but nevertheless… :P

As a final touch of elegance, however, I wanted to add the possibility of accelerating time :) With the function “variableSpeedClock” below, we can make a second in our animation take less (or more) than a second in the real world. Take a look:

variableSpeedClock speed x t = clock x (t * speed)

We multiply t by the speed parameter, so (quite obviously) the larger the value of speed, the quicker one “second” will be.

That’s it, that’s our FULL funky minimalistic analog clock. We can now RUN the animation by calling the (also appropriately called) “animate” function from gloss:

animate (InWindow "GlossClock" (size, size) (200,200)) white (variableSpeedClock speed' size')

In case you want to run the code and see the beauty for yourself, there are two possibilities:

1. Install the Haskell Platform in your computer (for Ubuntu: “sudo apt-get install haskell-platform”), and afterwards install gloss (typing “cabal install gloss”). You can them grab the full code here, compile
   it with “ghc –make Clock.hs” and RUN!
2. Using this BEAUTIFUL GLOSS WEB INTERFACE: Copy the code from HERE, paste it into the text field on the page and click “run”!

And never forget, fiddle with the code, change it and have fun! The code is licensed under Creative Commons sharealike bla bla bla… :D

Thanks to Ben Lippmeier for creating gloss, and thanks a lot to Chris Smith for creating the gloss web interface. Chris has also taught an awesome “Haskell for kids” course, which was very inspiring to me… That’s how I WANT to teach my kids about computers :)

One of the most common processing steps performed to identify objects in an image is edge detection. Our first course assignment is to implement the Roberts Cross edge detection algorithm. Because of my wish to get up-to-speed and review my Haskell knowledge, and also because this sort of algorithm is perfect for the functional paradigm, I decided to give Haskell a try! I’ll then show you the code, the pretty images and report my (almost painless) experience implementing it :P

One of the strongest selling points of functional programming is that code that is written according to the paradigm can be automatically parallelized. Roberts edge detection consists, for example, of nothing more than scanning an image, pixel by pixel, and applying a small matrix of coefficients that calculates the weighted average with its neighbours (it’s called Convolution by the guys at Wikipedia). Well, this “pixel by pixel” sort of algorithm is INHERENTLY parallel, and we can divide the task among as many thread as we want, without changing the semantics of the code. This is exactly what the Repa library does: it allows you to easily express several algorithms over multidimensional arrays and have them parallelized automatically.

Without any more explanation, here comes an example of executing the “Roberts” program with 1 thread, for an image of 1024×768 pixels:

Original image:

Edges:

Execution time (some of it is IO-bound):

real	0m7.112s
user	0m7.044s
sys	0m0.020s

Now to execute it with 2 and 4 threads, the only difference is that you need to run the program with some extra arguments on the command line:

./Roberts wow.png wow_bordas.bmp +RTS -N{2,4}

(2 threads)
real	0m4.000s
user	0m7.176s
sys	0m0.076s

(4 threads)
real	0m3.096s
user	0m8.509s
sys	0m0.456s

Disconsidering some synchronization overhead, the speedup in execution time is almost linear \o/\o/. I admit that processing time is still a bit high, but taking into account that I’m a complete n00b with this library the results are pretty promising!

I’m gonna even show you the code, because it’s really beautiful and reasonably small:

A TOTAL of 45 lines of code, including reading and writing from/to files. Amazing, isn’t it? :)

The Haskell compiler (GHC – The Glorious Haskell Compilation system) generates faster code release after release, the community of people using the language is booming, including big enterprises like Facebook :D There are Haskell libraries to accomplish every imaginable and unimaginable task, and these libraries are centralized and organized in the Hackage repository. Are you using a library and need to search its documentation? Use Hoogle, the central Haskell documentation search engine… BUT, in this huge pool of good news I want to pick two special ones:

1) Learning Haskell is easier than ever. In my old post I mentioned already the nice tutorial (for beginners) “Learn You a Haskell for Great Good!” and the book “Real World Haskell“. Now, great guys have created an even more awesome tool to learn Haskell: if you want to follow a good Haskell tutorial, practicing as you read, and even though install NOTHING onto your PC, go to the “Try Haskell!” website. It’s an interactive Haskell tutorial, you code as you learn, in the comfort of your favorite browser :)

2) If you enjoyed the test-drive and wanna install Haskell in your PC it’s also easier than ever. Now all the essential tools and libraries for a Haskell programmer are bundled in the Haskell Platform. Everything tested, stable and working nicely together. You just need to go to the platform’s website, choose your operating system, and install. Surely in Ubuntu the install process is the simplest of all: you add the repository and then type into a terminal: “sudo aptitude install haskell-platform” :D

And to prove that installation is really EASY, I’ve recorded a videocast of me installing the Haskell Platform on Ubuntu and put it on YouTube. Here it goes:

I’ve talked about what is functional programming and what are its greatest features. I’ve also shown the unique characteristics of Haskell that make it not just another programming language. The current state of the Haskell development toolchain and libraries was shown, and I also gave some directions about downloads, books and good tutorials for those interested in learning Haskell.

It’s always nice talking about something you like :) I already posted here in the blog another [intlink id="155" type="post"]article[/intlink] with some reasons to learn Haskell. The slides from the presentation are available here: Seminar – Prog. Funcional e Haskell (in portuguese)