Haskell type error messages can be difficult to understand for many reasons.

For beginners, small typos or common reasoning errors may lead to very complex messages with unfamiliar jargon. Even otherwise simple error messages are terse. Requests to make messages more friendly introduce a difficult community problem of gathering consensus on how these new and improved messages should look, how they might interfere with the workflow of more advanced users, as well as justifying their additional maintenance burden within the compiler.

For advanced users, large libraries and eDSLs with complex internal type machinery often expose these inner details in the form of complex errors when the programmer makes a mistake using surface-level functions. Very polymorphic functions, which would normally be good for code reuse, introduce a separate issue of under-constrained types, with little automated guidance as to how to constrain them properly.

We propose the introduction of a custom-error plugin interface for GHC - using this interface, plugin writers can detect errors of interest and annotate them with custom messages. Our hope is that this plugin interface will allow library writers to explain complex, library-specific errors by detecting constraints of interest. Such an interface will also enable us to avoid issues of community consensus for improving simpler errors - users and plugin writers are free to design and use the custom errors they prefer best.

We go over prior work in this area, including GHC’s existing custom type error functionality, and detail an existing in-production custom type error interface that we have designed into Damlc, a fork of GHC.

Dylan is a software engineer working on the Daml compiler team at Digital Asset. Before that, he was using Clash to build machine learning accelerators at Myrtle.AI.