Large-scale design in Haskell? [closed]

by

I talk a bit about this in Engineering Large Projects in Haskell and in the Design and Implementation of XMonad. Engineering in the large is about managing complexity. The primary code structuring mechanisms in Haskell for managing complexity are:

The type system

  • Use the type system to enforce abstractions, simplifying interactions.
  • Enforce key invariants via types
    • (e.g. that certain values cannot escape some scope)
    • That certain code does no IO, does not touch the disk
  • Enforce safety: checked exceptions (Maybe/Either), avoid mixing concepts (Word, Int, Address)
  • Good data structures (like zippers) can make some classes of testing needless, as they rule out e.g. out of bounds errors statically.

The profiler

  • Provide objective evidence of your program’s heap and time profiles.
  • Heap profiling, in particular, is the best way to ensure no unnecessary memory use.

Purity

  • Reduce complexity dramatically by removing state. Purely functional code scales, because it is compositional. All you need is the type to determine how to use some code — it won’t mysteriously break when you change some other part of the program.
  • Use lots of “model/view/controller” style programming: parse external data as soon as possible into purely functional data structures, operate on those structures, then once all work is done, render/flush/serialize out. Keeps most of your code pure

Testing

  • QuickCheck + Haskell Code Coverage, to ensure you are testing the things you can’t check with types.
  • GHC + RTS is great for seeing if you’re spending too much time doing GC.
  • QuickCheck can also help you identify clean, orthogonal APIs for your modules. If the properties of your code are difficult to state, they’re probably too complex. Keep refactoring until you have a clean set of properties that can test your code, that compose well. Then the code is probably well designed too.

Monads for Structuring

  • Monads capture key architectural designs in types (this code accesses hardware, this code is a single-user session, etc.)
  • E.g. the X monad in xmonad, captures precisely the design for what state is visible to what components of the system.

Type classes and existential types

  • Use type classes to provide abstraction: hide implementations behind polymorphic interfaces.

Concurrency and parallelism

  • Sneak par into your program to beat the competition with easy, composable parallelism.

Refactor

  • You can refactor in Haskell a lot. The types ensure your large scale changes will be safe, if you’re using types wisely. This will help your codebase scale. Make sure that your refactorings will cause type errors until complete.

Use the FFI wisely

  • The FFI makes it easier to play with foreign code, but that foreign code can be dangerous.
  • Be very careful in assumptions about the shape of data returned.

Meta programming

  • A bit of Template Haskell or generics can remove boilerplate.

Packaging and distribution

  • Use Cabal. Don’t roll your own build system. (EDIT: Actually you probably want to use Stack now for getting started.).
  • Use Haddock for good API docs
  • Tools like graphmod can show your module structures.
  • Rely on the Haskell Platform versions of libraries and tools, if at all possible. It is a stable base. (EDIT: Again, these days you likely want to use Stack for getting a stable base up and running.)

Warnings

  • Use -Wall to keep your code clean of smells. You might also look at Agda, Isabelle or Catch for more assurance. For lint-like checking, see the great hlint, which will suggest improvements.

With all these tools you can keep a handle on complexity, removing as many interactions between components as possible. Ideally, you have a very large base of pure code, which is really easy to maintain, since it is compositional. That’s not always possible, but it is worth aiming for.

In general: decompose the logical units of your system into the smallest referentially transparent components possible, then implement them in modules. Global or local environments for sets of components (or inside components) might be mapped to monads. Use algebraic data types to describe core data structures. Share those definitions widely.

More Related Contents:

  1. What is a monad?
  2. Applicatives compose, monads don’t
  3. Is monad bind (>>=) operator closer to function composition (chaining) or function application?
  4. Is Haskell truly pure (is any language that deals with input and output outside the system)?
  5. Should do-notation be avoided in Haskell?
  6. What is a monad?
  7. How to use (->) instances of Monad and confusion about (->)
  8. Why are side-effects modeled as monads in Haskell?
  9. How to interpret bind/>>= of the function instance?
  10. How to enumerate a recursive datatype in Haskell?
  11. How Monads are considered pure?
  12. Monads with Join() instead of Bind()
  13. How do you represent a graph in Haskell?
  14. How do functors work in haskell?
  15. What are “n+k patterns” and why are they banned from Haskell 2010?
  16. Applicative functor evaluation is not clear to me
  17. Expressing do block using only monadic bind syntax
  18. Why do we need monads?
  19. What constitutes a fold for types other than list?
  20. Defining a new monad in haskell raises no instance for Applicative
  21. Pattern matching identical values
  22. Abusing the algebra of algebraic data types – why does this work?
  23. Converting IO Int to Int
  24. Why should Applicative be a superclass of Monad?
  25. Haskell – depth for each node in binary tree using Reader monad
  26. How to return a pure value from a impure method
  27. In what sense is the IO Monad pure?
  28. Why does OCaml sometimes require eta expansion?
  29. Explanation of “tying the knot”
  30. Is Haskell’s mapM not lazy?

Leave a Comment