Abstract
There is a large gap between the specification of type systems and the implementation of their type checkers, which impedes reasoning about the soundness of the type checker with respect to the specification. A vision to close this gap is to automatically obtain type checkers from declarative programming language specifications. This moves the burden of proving correctness from a case-by-case basis for concrete languages to a single correctness proof for the specification language. This vision is obstructed by an aspect common to all programming languages: name resolution. Naming and scoping are pervasive and complex aspects of the static semantics of programming languages. Implementations of type checkers for languages with name binding features such as modules, imports, classes, and inheritance interleave collection of binding information (i.e., declarations, scoping structure, and imports) and querying that information. This requires scheduling those two aspects in such a way that query answers are stable—i.e., they are computed only after all relevant binding structure has been collected. Type checkers for concrete languages accomplish stability using language-specific knowledge about the type system. In this paper we give a language-independent characterization of necessary and sufficient conditions to guarantee stability of name and type queries during type checking in terms of critical edges in an incomplete scope graph . We use critical edges to give a formal small-step operational semantics to a declarative specification language for type systems, that achieves soundness by delaying queries that may depend on missing information. This yields type checkers for the specified languages that are sound by construction—i.e., they schedule queries so that the answers are stable, and only accept programs that are name- and type-correct according to the declarative language specification. We implement this approach, and evaluate it against specifications of a small module and record language, as well as subsets of Java and Scala.
Highlights
In an ideal world, programming language designers should not have to deal with accidental complexity when defining and implementing languages
Implementing type checkers for languages with such features is complicated because the use of names in programs causes dependencies between type-checking tasks, and requires that the construction of symbol tables and type environments is interleaved with querying those data structures
We envision closing the gap between language specification and language implementation by using specification languages that can address the complexity of actual programming languages and systematically deriving implementations from specifications
Summary
In an ideal world, programming language designers should not have to deal with accidental complexity when defining and implementing languages. The general approach to deriving type checkers from Statix specifications is already sketched by van Antwerpen et al [2018], who provide a Java implementation They explain the problem with unsound name resolution when queries answers are unstable, and they claim that their implementation implements a sound strategy. In order to formalize the soundness and confluence results, we develop a theory around the novel concept of critical edges in scope graphs We believe that this concept is a useful device in both the design of languages, and the implementation of their type checkers. It explains when a given object-language program, together with a type assignment and a scope graph model of its binding, satisfies the specified static semantics of an object language We equip this refined core of Statix with a novel small-step operational semantics.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
