Practical tips to prevent correctness space leaks in lazy Haskell programs

The article introduces a taxonomy of space leaks that distinguishes strictness leaks, liveness leaks, and excessive sharing leaks. It focuses on those leaks that can affect program correctness rather than only performance. Each class is illustrated with a short Haskell example and its STG representation.

To avoid strictness leaks, the author recommends forcing accumulator thunks before the recursive call, which can be done with bang patterns or seq. For liveness leaks, cost-centre annotations and runtime profiling are used to detect dead references that survive garbage collection. These techniques require adding a few annotations and recompiling with profiling enabled.

Excessive sharing leaks are addressed by merging multiple passes over a data structure into a single pass, moving the generator inside the consuming function, or, as a last resort, using linear types to enforce single-use. Each strategy may involve refactoring existing code and, for linear types, enabling GHC extensions.

The advice assumes the GHC compilation pipeline and its STG intermediate language; the same reasoning may not hold for other Haskell implementations. Moreover, linear types and aggressive strictness can increase code complexity and may not be suitable for all domains. One must weigh the benefits of leak reduction against the added maintenance cost.