English for Haskell Developers

Haskell’s strong type system and lazy evaluation model produce a vocabulary that’s precise but easy to misuse in conversation — “type class,” “monad,” and “strictness” all mean something specific. This guide covers the English used when discussing Haskell code with a team.

Key Vocabulary

Type class — an interface describing a set of operations a type must support (Eq, Functor, Monad), letting polymorphic code be written against the interface rather than a concrete type. “Instead of writing three near-identical functions for these types, define a type class capturing the shared behavior and write one function against it.”

Monad — a type class capturing a pattern for sequencing computations that carry some context (failure, state, I/O), letting that context be threaded automatically instead of manually. “Wrapping this in the Maybe monad means we don’t need explicit null checks at every step — the short-circuiting on Nothing happens for us.”

Laziness — Haskell’s default evaluation strategy where expressions aren’t computed until their result is actually needed, enabling infinite structures but also causing space leaks if misused. “That accumulator is building up a huge chain of unevaluated thunks — force strict evaluation with foldl' instead of the lazy foldl, or we’ll blow the heap on large inputs.”

Type inference — the compiler’s ability to deduce a value’s type from context without an explicit annotation, while still enforcing full static type safety. “You don’t need to annotate every intermediate binding — let type inference handle it, and only add explicit signatures at the top-level functions for documentation.”

Pure function / side effect boundary — the strict separation Haskell enforces between pure computation and effectful code, with effects tracked explicitly in the type signature (typically via IO). “If this function’s type doesn’t mention IO, the compiler guarantees it has no side effects — that’s a much stronger guarantee than a comment promising the same thing.”

Algebraic data type (ADT) — a type built by combining other types with sum (either/or) and product (and) composition, commonly defined with data and pattern-matched exhaustively. “Model this as an ADT with one constructor per state instead of a struct with several optional fields — then the compiler can force us to handle every case.”

Common Phrases

• “Does this type class actually need to be this general, or would a concrete function be clearer?”
• “Is this thunk chain going to force all at once and blow the stack, or is it being consumed incrementally?”
• “Should we add an explicit type signature here for documentation, even though inference would work?”
• “Does the type signature reflect that this function is pure, or is there an effect hiding somewhere?”
• “Would an ADT with explicit constructors make these invalid states unrepresentable?”

Example Sentences

Reviewing a pull request: “This function’s signature says it’s pure, but it’s calling unsafePerformIO internally — that undermines the whole guarantee the type system is supposed to give us.”

Explaining a design decision: “We modeled the request state as an ADT with one constructor per stage instead of a record with several Maybe fields, so invalid combinations simply can’t be constructed.”

Describing an incident: “The memory blow-up came from a lazy foldl building a massive unevaluated thunk chain instead of reducing the list as it went — switching to foldl' fixed it.”

Professional Tips

• Say “unrepresentable” when advocating for a stronger ADT — it’s precise shorthand Haskell developers use for designs that make invalid states impossible to construct.
• Distinguish “strict” from “lazy” explicitly when discussing performance — vague language like “it’s slow” hides which evaluation strategy is actually at fault.
• Use “the type signature guarantees…” rather than “I think this is pure” — it reflects how strongly Haskell developers lean on the type system as documentation.
• Flag unsafePerformIO by name in review — it’s a well-known escape hatch that deserves explicit scrutiny, not a passing comment.

Practice Exercise

1. Explain in two sentences why laziness can cause a space leak in a naive fold.
2. Write a one-sentence code review comment questioning a function’s claimed purity.
3. Describe, in your own words, what an algebraic data type buys you over a record with several optional fields.