GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness

Abstract

For ML and Haskell, accurate warnings when a function definition has redundant or missing patterns are mission critical. But today's compilers generate bogus warnings when the programmer uses guards (even simple ones), GADTs, pattern guards, or view patterns. We give the first algorithm that handles all these cases in a single, uniform framework, together with an implementation in GHC, and evidence of its utility in practice.

GADTs and Exhaustiveness: Looking for the Impossible

“…As a result, one only has to check the remaining cases when a constructor is actually matched on, as this forces evaluation, but not for wild cards. This explains why Karachalias et al [7] did not discuss this problem. Note however that, since GHC has strictness annotations, one can actually create situations where inhabitation by constructor terms becomes relevant, and the exhaustiveness check becomes undecidable.…”

“…This is to contrast with what used to happen in GHC before version 8.0, as the exhaustiveness checker could tell you that some case was missing, but adding it would cause a type error, leaving the programmer with the only option of adding a catch all case. Thanks to recent work [7], GHC 8.0 has the same property, by using the same typechecking-based pruning; note that since Haskell does not allow the same kind of type abstraction as ML, they do not need our compatibility relation.…”

Verification of Program Transformations with Inductive Refinement Types

“…The theory is useful since it supports inferring simple recursive shapes of programs, but it has its limitations: inference is syntactic and exact, and it is unclear how to generalize it to work with the rich pattern matching constructs and heterogeneous visitors. Haskell supports analysing coverage of its pattern matching language, that includes generalized algebraic data types (GADTs) and Boolean constraints [33]. While general Haskell function calls can occur in the Boolean constraints, the analysis treats them shallowly as function symbols; some covering pattern matches that depend on particular semantics of called functions, will be marked falsely as non-exhaustive.…”

Verification of high-level transformations with inductive refinement types

“…The theory is useful since it supports inferring simple recursive shapes of programs, but it has its limitations: inference is syntactic and exact, and it is unclear how to generalize it to work with the rich pattern matching constructs and heterogeneous visitors. Haskell supports analysing coverage of its pattern matching language, that includes generalized algebraic data types (GADTs) and Boolean constraints [30]. While general Haskell function calls can occur in the Boolean constraints, the analysis treats them shallowly as function symbols; some covering pattern matches that depend on particular semantics of called functions, will be marked falsely as non-exhaustive.…”