Safe

Debugging, Documenting and Testing Haskell Programs

Introduction

Programmers put a lot of stock in productivity. Most become intimately familiar with keyboard shortcuts in the tools they use, and will spend a great deal of time configuring their workspace for maximum productivity.

Similarly, programmers seek languages and programming paradigms that improve productivity. They want a language in which they can express their ideas clearly and succinctly, and which can be easily modified, maintained, and understood.

It has already been successfully argued elsewhere¹ that functional programming languages provide substantial productivity enhancements for programmers — at least in terms of the speed at which a product is built — but what is lacking from these analyses is the less quantifiable measures that improve productivity.

Most programmers one meets are not all that enamored with Java, and yet many experienced programmers (for example, at Google) will choose Java as the language du jour for their project. I asked many such project managers why this was so, and, far and away the most common reason was “Tool Support”.

Java may not be the most fashionable language, but its development ecosystem is extremely well-rounded. Testing frameworks, refactoring editors, documentation systems, debuggers and so on are all extremely popular and well-developed in the Java world.

All too often, what is lacking from newer languages is exactly this kind of tool support. In Ruby, debugging is still done via puts, and refactoring tools are virtually nonexistent — Python suffers from a similar problem. Scala’s debugger support often falls behind Java’s. These problems plague many functional languages too: OCaml has no solid build system or library collection, and SML and Lisp have very small user-bases and are unable to provide a full set of tools.

I believe that the language Haskell, a purely functional, open-source language, is one of the best supported with regards to development ecosystem. The tools used in the Haskell world are not only fit for the Haskell community, but also for those project managers who have been choosing Java in the enterprise.

Why Haskell?

As a language, Haskell has innate productivity benefits not found in many other languages. As it is a purely functional language, many things that are considered good style are enforced by the language, reducing the amount of programmer errors that can seep into the program at runtime.

Functions cannot perform side-effects implicitly. This means that effectful functions are segregated by the type system into an impure region of the program. This is an incredible boon for writing parallelized code, as functions that perform no side-effects can always be safely executed concurrently. This separation of pure and impure makes parallelizing a function as simple as adding a small annotation.

Functions are also referentially transparent — that is, they always give the same output given the same arguments. This is a logical corollary from the lack of side-effects, as any function without side-effects can only operate on its input values in a deterministic way. This reduces the need for integration testing, as a referentially transparent function can be tested for correctness merely by a unit test, as there is no dependence on effects from other parts of the program.

There is no such thing as implicit global state in Haskell. Seeing as modifying a global state constitutes a side effect, this is not surprising. While global variables and stateful static objects in other languages have always been considered a bad code smell, it seems that a cultural distaste is not enough to prevent programmers from constantly using them. By removing this, Haskell helps to enforce good design.

Modifying a data structure is a side effect, so all data structures are immutable in Haskell. This makes Haskell’s data model far simpler than Java’s, but still equally powerful. It makes test writing incredibly easy, because one never has to check if a data structure has been correctly modified, only that the data is well formed in the output.

All of these advantages are actually restrictions. Ward Cunningham once said that what killed Smalltalk was that it was “Too easy to make a mess!”². By restricting the programmer in this way, Haskell provides a liberating straightjacket of sorts that makes it very difficult indeed to make a mess, but still keeps programmer productivity and happiness high.

Haskell’s type system is very expressive, allowing arbitrary constraints to be placed on data and checked at compile time. Haskell enjoys a closer relationship to formal specifications in its type system than something like C. As a result, things that I call “typefails” - casts (except for use in C bindings), and the null value, both do not exist in Haskell. Despite the intricate type system, types rarely need to be explicitly declared, as Haskell’s type inference helps to keep programs short and to the point.

Haskell’s features all help to reduce runtime errors and move as much checking into the static phase as possible, so that the old programmer’s pipe dream “If it compiles, it works” is more true for Haskell than most other languages.

So, Haskell as a language provides numerous productivity benefits in terms of reducing the amount of time spent debugging or testing code. Haskell does not, however, eliminate the need for debugging or testing entirely (that is more the realm of theorem proving languages). So, we need to be able to track down bugs, document design contracts, and enforce those contracts with tests. As I mentioned earlier, Haskell’s tools are very powerful in this aspect as well.

Debugging

The most commonly used Haskell debugger is called ghci, a Haskell interpreter based around the Glasgow Haskell Compiler (GHC). It provides a REPL-style feedback loop, so that any function from inside any module can be invoked and tested by the programmer with their own input data.

Quite often, that is sufficient to debug Haskell programs, as Haskell programs are simply compositions extremely simple functions, so one merely needs to narrow down the erroneous function by examining a call tree.

ghci also provides some standard debugger equipment including breakpoints and traces, as well as type lookup - an extremely useful feature to determine the order of arguments of a function, the sort of data expected by functions, or what type has been inferred for your own functions.

Testing

Most programmers these days agree that formalized, automated testing and unit testing are good things. They can be used to detect regressions, ensure your code meets the contract, and also directly reduce bugs and increase productivity.

The new Test Driven Development craze advocates never writing a line of code until you have written a failing unit test. An admirable goal, but one that I ultimately believe is impractical. So long as unit test writing seems tedious, fiddly, boring and long, your average programmers will never be disciplined enough to actually follow the Test Driven Development motto.

reverse :: [a] -> [a]
reverse (x:xs) = reverse xs ++ [x]
reverse []     = []

prop_length :: [Int] -> Bool
prop_length list = length list == length (reverse list)

prop_reverse2 :: [Int] -> Bool
prop_reverse2 list = list == reverse (reverse list)

prop_firstlast :: [Int] -> Property
prop_firstlast list = list /= [] ==> head list == last (reverse list)

-- Middle element remains the same for lists of odd length
prop_middle list = length list `mod` 2 /= 0 ==> 
                   middle list == middle (reverse list)
    where halfway  = length list `div` 2
          middle l = head (drop halfway l)

Ensuring Comprehensive Tests

Obviously it is possible to write a function that passes QuickCheck but is still incorrect. In our example, a function that swapped first and last elements would still pass. It would be possible to write a QuickCheck property that reads a list in reverse and ensures the list is reversed, but this is essentially re-implementing a reverse function - just as likely to be buggy as the original. Still, such a technique could be used if one was attempting to write a more optimized version of a function - quickCheck could be used to test against the slower version.

It is also (arguably more) possible to write specific unit tests that pass when the function is still incorrect, so it is unclear which one has the advantage in terms of correctness, but certainly QuickCheck has an advantage in terms of convenience. It is also possible to encode a specific test case as a QuickCheck property (simply do not take parameters).³

Suppose we introduced some random business logic into our reverse function, highly unlikely to be triggered by quickCheck.

reverse :: [a]->[a]
reverse (x:xs) = if (x == 42) && (length xs == 3)
                  then [1337] 
                  else (reverse xs) ++ [x]
reverse [] = []

Obviously we should add some specific properties to test this new behavior, but it becomes clearly apparent that logic-heavy functions can easily have code branches that are missed, even by generated test cases. It would be nice to have a coverage checker to find out if any code paths are missed.

Haskell includes such a tool, Haskell Program Coverage (hpc), shipped with GHC. If you compile your program with -fhpc, and run your test cases, the command hpc report gives a summary like the following:

 97% expressions used (84/86)
  0% boolean coverage (0/1)
     100% guards (0/0)
       0% 'if' conditions (0/1), 1 always False
     100% qualifiers (0/0)
 75% alternatives used (3/4)
100% local declarations used (0/0)
100% top-level declarations used (7/7)

This shows that only 75% of possible code paths have been tested by my QuickCheck tests. The command hpc markup then allows us to view in an HTML document exactly which portions of code were not executed.

HPC demonstration for our reverse function

Now presented with this information, we can go and write a test for that specific case.

Documentation

QuickCheck and HUnit tests do provide a great deal of information about the contract of a function, as does the type signature. Because of the lack of side effects, often argument and return types are the only things that matter, and therefore documentation isn’t quite as important as in something like Java.

That said, obviously documentation is ideal, so Haskell provides two main documentation methodologies.

-- | This function is very important
f :: Int    -- ^ The 'Int' argument
  -> Float  -- ^ The 'Float' argument
  -> IO ()  -- ^ The return value

You’re Going to Use Haskell

The Free Lunch is Over. As Parallel programming becomes more important, side-effected languages such as C are going to go the way of the dodo. Parallelism on merely 2 cores is difficult in traditional languages. Over thousands of cores with nested data parallelism, it’s next to impossible. Haskell provides a way for such things to become simple - for more information, please see the Data Parallel Haskell project, currently underway at UNSW.

So, Face It! You’re going to use Haskell, so make a start now!

Honourable Mention

There are lots of things I didn’t cover in this article, for example:

• The wide variety of libraries in Hackage
• The excellent build system in Cabal
• Powerful and easy distributed version control in Darcs
• Excellent benchmarking with Criterion and ThreadScope

If I get time, I may expand this article to include them, but I guess it’s already long enough already. Thanks for bearing with me to the end!

Liam O’Connor-Davis

3 April 2010