The Toolbox

Base Camp introduced GHCup and ghci just enough to get the rest of this book running hands-on. This closing chapter fills in the rest of the map.

GHC and GHCi, properly

GHC (the Glasgow Haskell Compiler) is the thing that actually turns .hs files into running programs — every other tool in this chapter either wraps it, feeds it, or queries it. ghci, its interactive REPL, is worth knowing beyond the handful of commands Base Camp introduced:

ghci> :type map            -- ask for a value's type
map :: (a -> b) -> [a] -> [b]

ghci> :kind Maybe           -- ask for a type's kind
Maybe :: * -> *

ghci> :info Functor         -- full details: methods, laws, instances in scope
ghci> :load MyModule.hs     -- load a file (:l for short)
ghci> :reload               -- reload after editing (:r for short)
ghci> :set -XLambdaCase     -- turn on an extension for this session only

:type and :kind are the two commands worth building a habit around — reaching for :type someExpression the instant a type signature is unclear is faster and more reliable than working it out on paper, and it’s the single most common way experienced Haskell programmers actually explore unfamiliar code.

Cabal and Stack: two answers to “manage my dependencies”

Both Cabal and Stack solve the same core problem — pin down exactly which package versions a project depends on, fetch them, and build against them reproducibly — with different philosophies:

• Cabal is the more fundamental, lower-level tool (and the one GHCup installs by default): you declare dependencies and version bounds in a .cabal file, and Cabal resolves a compatible set from Hackage directly.
• Stack builds on top of the same underlying tools but resolves dependencies against curated snapshots (Stackage) — large, pre-tested sets of package versions known to build together — trading some flexibility for a stronger “if it builds for me, it builds for you” guarantee.

cabal init                # start a new project
cabal build                # build it
cabal run                  # build and run
cabal repl                 # ghci, with the project's dependencies loaded

stack new my-project       # start a new project (from a template)
stack build
stack run
stack ghci

Where Cabal’s per-project pinning lives in a .cabal file’s version bounds, Stack’s lives in a stack.yaml file that every stack new-created project gets automatically:

# stack.yaml
resolver: lts-22.28   # one Stackage snapshot: a specific, tested GHC + package-version set

packages:
  - .                 # this project's own package

extra-deps:
  - some-package-1.2.3   # a dependency not in the chosen snapshot, pinned by hand

The resolver line is the whole idea in one place: lts-22.28 names one specific, dated, already-tested combination of a GHC version and thousands of package versions known to build together. Every developer on a project pointed at the same resolver gets the exact same dependency versions, with no solver run needed at all for anything already in the snapshot — Stack only has to resolve versions itself for the rare package listed under extra-deps, ones the curators haven’t included.

Neither is objectively correct; both are genuinely popular, and most Haskell developers develop a preference within their first few projects and mostly stick with it.

Hoogle: search by type, not just by name

Hoogle is the tool that most distinguishes searching for Haskell code from searching for code in most other languages: because every function’s type signature is precise and meaningful (the whole premise of Chapter 4’s Types chapter), Hoogle lets you search by type signature directly, not just by name.

Search: (a -> b) -> [a] -> [b]

That exact query returns map as the very first result — and more usefully, searching String -> [String] when you don’t yet know the function you want turns up lines and words immediately, without needing to know their names in advance. Hoogle is genuinely one of the most-used everyday Haskell tools precisely because “I know the shape of the function I need, but not its name” is an extremely common situation once type signatures are second nature.

HLS, hlint, and the rest of the everyday loop

HLS (the Haskell Language Server) is what gives editors — VS Code, Neovim, Emacs — live type-on-hover, inline error squiggles, and jump-to-definition, by running GHC’s own type checker continuously in the background as code is edited, rather than only at explicit compile time. hlint is a separate, complementary tool: a linter that suggests more idiomatic rewrites (foldr (:) [] → id, nested if/then/else → guards) based on a large, community-curated set of known-good simplifications.

Bringing it together

None of these tools do anything Chapter 1’s ghc/ghci couldn’t do directly, in principle — they exist entirely to make the feedback loop between writing code and finding out whether it’s right faster and more informative. That loop — write a type signature, let the compiler hold you to it, ask a tool when you’re unsure rather than guessing — has been this book’s real throughline since the very first chapter, and the tools in this one are simply what that same loop looks like at the speed real, everyday Haskell development actually runs at.

The climb that started with ghci> 1 + 1 reaches its summit here: not just knowing what Haskell code means, but having the actual tools to write, search for, check, and ship it. One last, shorter stop remains after this — a look outward at the wider range this particular peak belongs to — but the climb itself, the thing this book set out to teach, is complete.