Project and Dependency Management

Cabal and Stack are the tools for managing projects in the Haskell world. As you have seen throughout the book, they share a declarative way to specify which kind of software artifacts should be built, the dependencies you need, and options for compilation. Each artifact is defined in a so-called stanza .

Most of the power of Haskell comes from the great repository of libraries called Hackage . This repository is managed by the Haskell community, which uploads its latest work to make it available to the outer world. Using the cabal install command, you can automatically get a copy of a package and compile it. For those cases in which stability is preferred over novelty, Stackage provides a curated subset of Hackage which is known to compile together.

Code Style

You need to write code that satisfies the constraints of the compiler to produce some library or executable. However, code that is accepted may not necessarily be easily maintainable, or it may follow a pattern whose behavior is usually confusing for later readers.

One piece of advice I strongly suggest you follow is to always enable the -Wall flag of the compiler. Setting this flag causes the compiler not only to look for errors but also to issue warnings for your code. The HLint tool is also useful in generating warnings, helping you find poorly written sections of code that may prove troublesome later.

In many cases, you also want your code to follow some style guidelines, that is, a set of recommendations on indentation, newlines, whether to use anonymous functions or define them in let blocks, and so on. Stylish Haskell is a tool that can help you with guidelines. It reads your code and produces a new version following some configurable options. Furthermore, it’s possible to integrate it into Visual Studio Code, Emacs, vi, and many other editors, so you can make it part of your daily development experience.

Documentation

In the previous chapter I discussed the importance of good and up-to-date documentation. As you now know, Haddock is the recommended tool for maintaining that documentation. The main benefit of using Haddock is that the information about an element appears near the element itself. Haddock is also the tool used to produce the massive amount of help documents in Hackage. Finally, Haddock’s output shows the documentation coverage, so you can quickly see whether you’ve forgotten to document any of the functions within your code.

Searching a large number of packages for functions and data types can be a time-consuming task. Hoogle was introduced earlier in the book as a way to search Haskell declarations not only by name or description but also by taking into account the types that are involved in a function’s signature.

Test and Verification

One big part of Chapter 15 has been devoted to testing using HUnit , QuickCheck , and SmallCheck. I can’t stress enough how important testing is for a successful development project. The great benefit of property-based testing tools, such as QuickCheck or SmallCheck, is that you indicate how your program should behave at a higher level. Then, it generates small unit tests for a variety of scenarios. In that way, the coverage is much higher than using traditional tools.

Type-level programming in Haskell opens the door to formally verifying some properties of your data types and algorithms directly inside the language. If this is not enough, you can complement strong types with refinement types as targeted by LiquidHaskell. While formal verification consumes more time than basic testing, it’s the only technique that can guarantee a complete absence of bugs.

Benchmarking

Functional correctness is an important consideration for a piece of code. In many cases, though, an application should run with a certain performance. The Criterion tool helps you define test cases and get statistics on the time of execution. The tool runs the test enough times to make the computed time statistically significant and evaluates the result completely (in other cases, some part of the computation wouldn’t be measured because of laziness).

Profiling

Chapter 5 introduced the GHC profiler, which allows you to gather information about the time and memory consumption of your applications. Because of the lazy nature of Haskell, memory profiling becomes much more important than in other languages. Used wisely, it can shorten the investigation process for performance problems and guide you toward those places you should spend more time optimizing.

The main disadvantage of the profiler is that it’s not designed for applications with several threads, such as those you can write with the libraries presented in Chapter 8. For those cases it’s interesting to consider ThreadScope , a graphic tool for reading GHC event logs. These event logs include information about when different threads are created and terminated, along with the activity of each of them.

Coverage

When you design tests, it’s important to ensure that every possible path of execution is covered. That is, make sure that you’ve covered all possible branches of conditionals, all possible patterns for a data type and match, and so on. The hpc tool, included with GHC, gathers important statistics about the code used in a certain execution. This information can be used to produce a report with the different kinds of coverage and the achieved percentage.

Remote Monitoring

In many cases, applications are not processes with a limited life but are server-like in nature. One example of this kind is web applications. The ekg package enables you to get statistics of the performance and behavior of an application while executing. In addition, it does so via a web interface, so its management is quite simple. When using ekg, you’re not restricted to the information it gives by default; you can include your own counters. For example, for a web application you might be interested in knowing how many pages are served by the minute or how many database connections are kept open through time.

Use Higher-Order Combinators

Using functions such as map, filter, and fold will make the purpose of your code more apparent to a future reader of it. You saw in Chapters 3 and 14 how recursion over a data type can usually be turned into a series of calls to these functions, so you should keep its use to a minimum.

Refactor

In the previous section I discussed how Haskell goes quite well with agile programming methodologies. The ability to pass functions as parameters can help you to build functions that encapsulate the common parts of many algorithms. Many classes of problems can be divided in a general skeleton and then instantiated to each case by introducing the small parts that are missing.

The benefits of higher-order refactoring are twofold. First, you reduce the amount of code you have to maintain, and thus you have fewer possibilities of introducing new bugs because your code will have been much better tested. Furthermore, when you abstract a common pattern in your code, the correctness or the corner cases of your approach become more obvious.

Use Type Classes Wisely

Type classes are a powerful tool for abstracting the common idioms of several data types. The Haskell libraries are full of type classes, and almost every important programming concept is implemented as a type class. Try to follow the steps of those libraries and implement your concepts as type classes.

Enforce Invariants via the Type System

Chapter 13 discussed many ways in which you can enforce invariants in your values via strong types. Using those techniques in your code will benefit you in the short term because more errors will be caught by the compiler; you will also benefit in the long term because modifications that would break your invariants will be denied.

The type system can help you catch many errors even if you don’t follow all these techniques. One good example is newtype. You can separate different concepts (such as money, a record identifier, or distance) even if they have the same computer representation (which in that case would be an integer).

Stay (As) Pure and Polymorphic (As Possible)

If you write your functions by separating side effects from the rest of your computation, you’ll have a much easier time testing your code. One useful pattern is to create a core of pure functions that work on your core data types, apply a lot of QuickCheck tests and even formal verification, and build from there.

In case you need to work with monadic contexts, try to use monad classes (such as MonadState, MonadError, etc.) to specify exactly what functionality you need from a monad stack. The solution of specifying the complete monad stack you’re using from the beginning is not maintainable because usually you need to add layers for extra functionality. Furthermore, keeping your code polymorphic will enable you to use it in different ways. For example, you may be interested in testing your Persistent code against a list instead of a database, something that would be possible if instead of SqlPersistT (the actual transformer) you specify PersistQuery (the monad class) in your signature.

The essence of this advice is that polymorphism opens the door to reusability. If instead of a function using a list of integers you write a function that works on any Traversable whose elements are Nums, you will be able to change both the representation of the container (tree instead of lists) and the type of number (Integers instead of Ints) without any further change.

Summary of Monads

Restrictive Monad Classes

Looking at the previous table you may notice that some monads provide a very restricted set of operations – for example, ReaderT just offers the ability to obtain a single value – while others open the door to many different effects – think of IO or the monads from the persistent package. The latter case goes at odds with Haskell’s philosophy of making types describe your functions: if your signature mentions IO, nothing really could be said about its behavior. Here I describe a small pattern to restrict the operations while keeping a good performance.

To understand this pattern, we need to look back at the monad classes introduced in Chapter 7. At that point the problem was different: we had just introduced monad transformers, and we wanted to have a common interface for any stack which contained a given layer, regardless of where that layer was found. That is, we wanted to keep using the ask function for any stack which contained a ReaderT transformer.

Imagine now that we want to use file operations in a function. If we throw an IO monad in the signature, we could also do network operations or create threads. Or even worse, if we want to write a combinator – a function which takes another as parameter – and we allow IO there, we can never be sure about what that function will do. This is the perfect scenario to restrict the set of operations allowed by IO to the file system subset.

The consequence is that now you can use copyFile anywhere a function which operates on IO is expected. Furthermore, the cost of this abstraction is almost negligible, since GHC specializes functions like copyFile when they are used with a single type class.

Roll Your Own Monad

Monads appear everywhere in Haskell code. The special do notation provides a convenient syntax for sequencing and composing actions, and there are many libraries and functions operating on monadic code. Thus, writing a monad appears as an obvious choice for developing a domain-specific language for your actions.

Notice that the SaveClient operation doesn’t return any value, so the next operation doesn’t take any parameter. Thus, you only need to specify r in the data constructor.

The free package provides many more features for rolling your own monads. For example, you may decide to create a monad transformer instead of a plain monad, just by using FreeT instead of Free. If your application will revolve around a custom monad, it’s useful to read the documentation of the Control.Monad.Free.Church module, which can enhance the performance in the long term. Finally, free provides not only free monads but also free Applicatives, Alternatives, and MonadPlus.