Compositional explanation of types and algorithmic debugging of type errors

Abstract

The type systems of most typed functional programming languages are based on the Hindley-Milner type system. A practical problem with these type systems is that it is often hard to understand why a program is not type correct or a function does not have the intended type. We suggest that at the core of this problem is the difficulty of explaining why a given expression has a certain type. The type system is not defined compositionally. We propose to explain types using a variant of the Hindley-Milner type system that defines a compositional type explanation graph of principal typings. We describe how the programmer understands types by interactive navigation through the explanation graph. Furthermore, the explanation graph can be the foundation for algorithmic debugging of type errors, that is, semi-automatic localisation of the source of a type error without even having to understand the type inference steps. We implemented a prototype of a tool to explore the usefulness of the proposed methods.

Improving Type Error Messages in OCaml

“…Bernstein and Stark [3] describe this idea of interactive debugging, although they suggested the user performing the change by hand in the code. Chitil [5] describes a type-checker that features debugging sessions, during which the user is asked a sequence of questions of the form: "Is the intended type of expression foo an instance of the type bla? ", to which the programmer answers by either "yes" or "no".…”

“…Interactive type-debugging sessions have been proposed as a solution to verbosity (e.g. [5]), however they can be very time consuming for the programmer. Another proposed approach is the extraction of minimal error slices [7].…”