Glasgow Haskell Compiler

The Glasgow Haskell Compiler (GHC) is the flagship open-source compiler and interactive environment for the Haskell programming language. Originally developed by Simon Peyton Jones and his colleagues at the University of Glasgow in 1989, GHC has evolved from a research prototype into one of the most sophisticated optimizing compilers in existence — a system that compiles a language of mathematical purity into machine code competitive with hand-written C. It is not merely a tool but a decades-long experiment in whether theoretical coherence and industrial performance are compatible goals.

GHC's architecture reflects a commitment to transformation over generation. Rather than compiling Haskell directly to assembly, GHC progressively simplifies the source program through a series of intermediate languages, each stripping away syntactic sugar and exposing deeper structure. This pipeline — source → desugared core → typed lambda calculus → STG-machine → C-- or LLVM → native code — enables optimizations that would be impossible if the compiler tried to bridge the gap between Haskell's high-level semantics and hardware in a single leap.

The Core Language: Where Theory Meets Implementation

At the heart of GHC lies an explicitly typed lambda calculus called Core. After desugaring Haskell's rich surface syntax — type classes, do-notation, list comprehensions — the compiler translates everything into Core, a small, rigorous language with only a handful of constructs: variables, lambda abstractions, applications, let-bindings, and case expressions. Core is not an implementation detail; it is the compiler's shared vocabulary, the common currency in which all optimizations are expressed.

The design of Core embodies the Curry-Howard Correspondence in concrete form. Every Core program is a proof in a constructive logic, and the type system ensures that transformations preserve meaning. This is not metaphor. GHC's optimizer performs equational reasoning on Core programs, replacing subexpressions with provably equivalent alternatives using rewrite rules supplied by programmers themselves. The result is a compiler that treats code as mathematics — not as a sequence of instructions to be shuffled, but as expressions to be simplified according to algebraic laws.

GHC also converts programs to a variant of Continuation-Passing Style during optimization, enabling control-flow analysis that is impossible in direct style. Combined with Defunctionalization, this transformation pipeline can turn a high-level functional interpreter into an efficient abstract machine — a technique the compiler uses internally when optimizing higher-order functions.

Type Classes and the Dictionary Transformation

Haskell's type classes — its mechanism for ad-hoc polymorphism — present a particular challenge for compilation. A function polymorphic over the 'Eq' class must work for integers, strings, and user-defined types alike. GHC solves this through dictionary passing: at compile time, the compiler selects the appropriate implementation for each type and passes it as an explicit argument. The type class constraint disappears; what remains is ordinary function application.

This transformation is deceptively powerful. It means that type classes impose no runtime cost beyond the cost of a function call. The compiler inlines aggressively, and dictionary selection happens entirely at compile time. What looks like object-oriented dispatch becomes static monomorphization under the hood. This is why Haskell programs can be both polymorphic and fast — a combination that object-oriented languages typically achieve only through virtual tables and dynamic dispatch, with their attendant cache misses and optimization barriers.

Lazy Evaluation and the STG Machine

The Spineless Tagless G-machine (STG) is GHC's execution model for lazy evaluation. It resolves the tension between Haskell's call-by-need semantics and the realities of modern hardware, which expects eager evaluation and predictable memory access. The STG machine represents unevaluated expressions as heap-allocated closures — self-describing objects that know how to compute their own value when forced. When a value is needed, the closure is entered; when the computation completes, the closure is overwritten with its result, so subsequent accesses retrieve the value directly.

This update-in-place strategy is the essence of call-by-need: evaluate once, share everywhere. The STG machine also uses a uniform representation for all values — pointers on the stack, tagged integers in registers — which simplifies the garbage collector and enables efficient generational collection. The result is a runtime system that makes laziness practical, not merely theoretically elegant.

Beyond Haskell: GHC as Research Platform

GHC has never been only a Haskell compiler. It is a vehicle for programming language research, a platform on which new ideas are implemented and tested before they migrate into mainstream languages. Software Transactional Memory (STM) was first made practical in GHC, providing a composable alternative to locks for concurrent programming. Generalized algebraic data types (GADTs), type families, and higher-kinded polymorphism all debuted in GHC before appearing elsewhere.

The compiler's plugin architecture allows researchers to add new transformations, new intermediate representations, and even new type systems without modifying the core compiler. This extensibility has made GHC the de facto reference implementation for advanced type system features — a role analogous to that of GCC in the C ecosystem, but for a language whose specification is itself a moving target.

The common criticism that Haskell is 'too slow for production' reveals a misunderstanding of what GHC actually achieves. The compiler routinely generates code within a small constant factor of C for numerically intensive workloads, and its runtime system outperforms many garbage-collected languages on latency-sensitive tasks. The perception of slowness stems not from the compiler but from the language's laziness — a semantics that enables expressive power at the cost of predictable space usage. To blame GHC for this is to blame the telescope for revealing how distant the stars are. The industry does not avoid Haskell because the compiler is slow; it avoids Haskell because it has not yet developed the organizational patience to learn a language whose rewards accrue over years, not sprints.