Towards Certified Meta-Programming with Typed Template-Coq

Meta-programming is the art of writing programs (in a meta-language) that produce or manipulate programs (written in an object language). In the setting of dependent type theory, the expressivity of the language permits to consider the case were the meta and object languages are actually the same, accounting for well-typedness. This idea has been pursued in the work on inductive-recursive (IR) and quotient inductive-inductive types (QIIT) in Agda to reflect a syntactic model of a dependently-typed language within another one [2, 9]. These term encodings include type-correctness internally by considering only well-typed terms of the syntax, i.e. derivations. However, the use of IR or QIITs complicates considerably the meta-theory of the meta-language which makes it difficult to coincide with the object language represented by an inductive type. More problematically in practice, the concision and encapsulation of the syntactic encoding has the drawback that it is very difficult to use because any function from the syntax can be built only at the price of a proof that it respects typing, conversion or any other features described by the intrinsically typed syntax right away.

Other works have taken advantage of the power of dependent types to do meta-programming in a more progressive manner, by first defining the syntax of terms and types; and then defining out of it the notions of reduction, conversion and typing derivation [11, 26] (the introduction of [11] provides a comprehensive review of related work in this area). This can be seen as a type-theoretic version of the functional programming language designs such as Template Haskell [22] or MetaML [24]. This is also the approach taken by Malecha in his thesis [18], where he defined Template-Coq, a plugin which defines a correspondence—using quoting and unquoting functions—between Coq kernel terms and inhabitants of an inductive type representing internally the syntax of the calculus of inductive constructions (CIC), as implemented in Coq. It becomes thus possible to define programs in Coq that manipulate the representation of Coq terms and reify them as functions on Coq terms. Recently, its use was extended for the needs of the CertiCoq certified compiler project [4], which uses it as its front-end language. It was also used by Anand and Morissett [3] to formalize a modified parametricity translation, and to extract Coq terms to a CBV \(\lambda \)-calculus [13]. All of these translations however lacked any means to talk about the semantics of the reified programs, only syntax was provided by Template-Coq. This is an issue for CertiCoq for example where both a non-deterministic small step semantics and a deterministic call-by-value big step semantics for CIC terms had to be defined and preserved by the compiler, without an “official” specification to refer to.

This paper proposes to remedy this situation and provides a formal semantics of Coq’s implemented type theory, that can independently be refined and studied. The advantage of having a very concrete untyped description of Coq terms (as opposed to IR or QIITs definitions) together with an explicit type checker is that the extracted type-checking algorithm gives rise to an OCaml program that can directly be used to type-check Coq kernel terms. This opens a way to a concrete solution to bootstrap Coq by implementing the Coq kernel in Coq. However, a complete reification of CIC terms and a definition of the checker are not enough to provide a meta-programming framework in which Coq plugins could be implemented. One needs to get access to Coq logical environments. This is achieved using a monad that reifies Coq general commands, such as lookups and declarations of constants and inductive types.

As far as we know this is the only reflection framework in a dependently-typed language allowing such manipulations of terms and datatypes, thanks to the relatively concise representation of terms and inductive families in CIC. Compared to the MetaCoq project [27], Lean ’s tactic monad [12], or Agda ’s reflection framework [26], our ultimate goal is not to interface with Coq’s unification and type-checking algorithms, but to provide a self-hosted, bootstrappable and verifiable implementation of these algorithms. On one hand, this opens the possibility to verify the kernel’s implementation, a problem tackled by Barras [6] using set-theoretic models. On the other hand we also advocate for the use of Template-Coq as a foundation on which higher-level tools can be built: meta-programs implementing translations, boilerplate-generating tools, domain-specific proof languages, or even general purpose tactic languages.

Plan of the Paper. In Sect. 2, we present the complete reification of Coq terms, covering the entire CIC and define in Sect. 3 the type-checking algorithm of Coq reified terms in Coq. In Sect. 4, we show the definition of a monad for general manipulation of Coq’s logical environment and use it to define plugins for various translations from Coq to Coq (Sect. 5). Finally, we discuss related and future work in Sect. 6.

Reification of Syntax. The central piece of Template-Coq is the inductive type which represents the syntax of Coq terms, as defined in Fig. 1. This inductive follows directly the datatype of Coq terms in the OCaml code of Coq, except for the use of OCaml ’s native arrays and strings; an upcoming extension of Coq [5] with such features should solve this mismatch.

Constructor represents variables bound by abstractions (introduced by ), dependent products (introduced by ) and local definitions (introduced by ), the natural number is a De Bruijn index. The is a printing annotation.

Sorts are represented with , which takes a as argument. A universe is the supremum of a (non-empty) list of level expressions, and a level is either , , a global level or a De Bruijn polymorphic level variable.

The application (introduced by ) is n-ary. The , and constructors represent references to constants (definitions or axioms), inductives, or constructors of an inductive type. The are non-empty only for polymorphic constants. Finally, represents pattern-matchings, primitive projections, fixpoints and cofixpoints.

Quoting and Unquoting of Terms. Template-Coq provides a lifting from concrete syntax to reified syntax (quoting) and the converse (unquoting). It can reify and reflect all kernel Coq terms.

The command reifies the syntax of a term. For instance,

generates the term defined as

On the converse, the command constructs a term from its syntax. This example below defines to be of type \(\mathbb {N}\).

where is the inductive of the mutual block of the name .

Reification of Environment. In Coq, the meaning of a term is relative to an environment, which must be reified as well. Environments consist of three parts: (i) a graph of universes (ii) declarations of definitions, axioms and inductives (iii) a local context registering types of De Bruijn indexes.

As we have seen in the syntax of terms, universe levels are not given explicitly in Coq. Instead, level variables are introduced and constraints between them are registered in a graph of universes. This is the way typical ambiguity is implemented in Coq. A constraint is given by two levels and a

Then the graph is given by a set of level variables and one of constraints. Sets, coming from the Coq standard library, are implemented using lists without duplicates. means the type of the module .

Functions to query the graph are provided, for the moment they rely on a naive implementation of the Bellman-Ford algorithm. checks if the graph enforces and checks that the graph has no negative cycle.

Constant and inductive declarations are grouped together, properly ordered according to dependencies, in a global context ( ), which is a list of global declarations ( ).

Definitions and axioms just associate a name to a universe context, and two terms for the optional body and type. Inductives are more involved:

In Coq internals, there are in fact two ways of representing a declaration: either as a “declaration” or as an “entry”. The kernel takes entries as input, type-check them and elaborate them to declarations. In Template-Coq, we provide both, and provide an erasing function from declarations to entries for inductive types.

Finally, local contexts are just list of local declarations: a type for lambda bindings and a type and a body for let bindings.

Quoting and Unquoting the Environment. Template-Coq provides the command to quote an environment. This command crawls the environment and quote all declarations needed to typecheck a given term.

The other way, the commands allows declaring an inductive type from its entry. For instance the following redefines a copy of \(\mathbb {N}\):

More examples of use of quoting/unquoting commands can be found in the file .

In Fig. 2, we present (an excerpt of) the specification of the typing judgment of the kernel of Coq using the inductive type . It represents all the typing rules of Coq¹. This includes the basic dependent lambda calculus with lets, global references to inductives and constants, the construct and primitive projections. Universe polymorphic definitions and the well-formedness judgment for global declarations are dealt with as well.

The only ingredients missing are the guard check for fixpoint and productivity of cofixpoints and the positivity condition of mutual (co-) inductive types. They are work-in-progress.

The typing judgment is mutually defined with to account for n-ary applications. Untyped reduction and cumulativity can be defined separately.

Implementation. To test this specification, we have implemented the basic algorithms for type-checking in Coq, that is, we implement type inference: given a context and a term, output its type or produce a type error. All the rules of type inference are straightforward except for cumulativity. The cumulativity test is implemented by comparing head normal forms for a fast-path failure and potentially calling itself recursively, unfolding definitions at the head in Coq’s kernel in case the heads are equal. We implemented weak-head reduction by mimicking Coq’s kernel implementation, which is based on an abstract machine inspired by the KAM. Coq’s machine optionally implements a variant of lazy, memoizing evaluation (which can have mixed results, see Coq’s PR #555 for example), that feature has not been implemented yet.

The main difference with the OCaml implementation is that all of the functions are required to be shown terminating in Coq. One possibility could be to prove the termination of type-checking separately but this amounts to prove in particular the normalization of CIC which is a complex task. Instead, we simply add a fuel parameter to make them syntactically recursive and make a type error, i.e., we are working in a variant of the option monad.

Bootstrapping It. We can extract this checker to OCaml and reuse the setup described in Sect. 2 to connect it with the reifier and easily derive a (partialy verified) alternative checker for Coq’s object files. Our plugin provides a new command for typechecking definitions using the alternative checker, that can be used as follows:

Our initial tests indicate that its running time is comparable to the coqchk checker of Coq, as expected.

Coq plugins need to interact with the environment, for example by repeatedly looking up definitions by name, declaring new constants using fresh names, or performing computations. It is desirable to allow such programs to be written in Coq (Gallina) because of the two following advantages. Plugin-writers no longer need to understand the OCaml implementation of Coq and plugins are no longer sensitive to changes made in the OCaml implementation. Also, when plugins implementing syntactic models are proven correct in Coq, they provide a mechanism to add axioms to Coq without compromising consistency (Sect. 5.3).

In general, interactions with the environment have side effects, e.g. the declaration of new constants, which must be described in Coq’s pure setting. To overcome this difficulty, we use the standard “free” monadic setting to represent the operations involved in interacting with the environment, as done for instance in Mtac [27].

is an inductive family (Fig. 3) such that represents a program which will finally output a term of type . There are special constructor and to provide (freely) the basic monadic operations. We use the monadic syntactic sugar for .

The other operations of the monad can be classified in two categories: the traditional Coq operations ( to declare a new definition, ...) and the quoting and unquoting operations to move between Coq term and their syntax or to work directly on the syntax ( to declare a new inductive from its syntax for instance). An overview is given in Table 1.

A program of type can be executed with the command . This command is thus an interpreter for , implemented in OCaml as a traditional Coq plugin. The term produced by the program is discarded but, and it is the point, a program can have many side effects like declaring a new definition or a new inductive type, printing something, ....

Let’s look at some examples. The following program adds the definitions and to the current context.

The program below asks the user to provide an inhabitant of \(\mathbb {N}\) (here we provide ) and records it in the lemma ; prints its normal form ; and records the syntax of its normal form in (hence of type ). We use Program ’s obligation mechanism² to ask for missing proofs, running the rest of the program when the user finishes providing it. This enables the implementation of interactive plugins.

The reification of syntax, typing and commands of Coq allow writing a Coq plugin directly inside Coq, without requiring another language like OCaml and an external compilation phase.

In this section, we describe three examples of such plugins: (i) a plugin that adds a constructor to an inductive type, (ii) a re-implementation of Lasson ’s parametricity plugin³, and (iii) an implementation of a plugin that provides an extension of CIC—using a syntactic translation—in which it is possible to prove the negation of functional extensionality [8].

Meta-Programming is a whole field of research in the programming languages community, we will not attempt to give a detailed review of related work here. In contrast to most work on meta-programming, we provide a very rough interface to the object language: one can easily build ill-scoped and ill-typed terms in our framework, and staging is basic. However, with typing derivations we provide a way to verify meta-programs and ensure that they do make sense.

The closest cousin of our work is the Typed Syntactic Meta-Programming [11] proposal in Agda, which provides a well-scoped and well-typed interface to a denotation function, that can be used to implement tactics by reflection. We could also implement such an interface, asking for a proof of well-typedness on top of the primitive of our monad.

Intrinsically typed representations of terms in dependent type-theory is an area of active research. Most solutions are based on extensions of Martin-Löf Intensional Type Theory with inductive-recursive or quotient inductive-inductive types [2, 9], therefore extending the meta-theory. Recent work on verifying soundness and completeness of the conversion algorithm of a dependent type theory (with natural numbers, dependent products and a universe) in a type theory with IR types [1] gives us hope that this path can nonetheless be taken to provide the strongest guarantees on our conversion algorithm. The intrinsically-typed syntax used there is quite close to our typing derivations.

Another direction is taken by the Œuf certified compiler [19], which restricts itself to a fragment of Coq for which a total denotation function can be defined, in the tradition of definitional interpreters advocated by Chlipala [10]. This setup should be readily accommodated by Template-Coq.

The translation + plugin technique paves the way for certified translations and the last piece will be to prove correctness of such translations. By correctness we mean computational soundness and typing soundness (see [8]), and both can be stated in Template-Coq. Anand has made substantial attempts in this direction to prove the computational soundness, in Template-Coq, of a variant of parametricity providing stronger theorems for free on propositions [3]. This included as a first step a move to named syntax that could be reused in other translations.

Our long term goal is to leverage this technique to extend the logical and computational power of Coq using, for instance, the forcing translation [14] or the weaning translation [20].

When performance matters, we can extract the translation to OCaml and use it like any ordinary Coq plugin. This relies on the correctness of extraction, but in the untyped syntax + typing judgment setting, extraction of translations is almost an identity pretty-printing phase, so we do not lose much confidence. We can also implement a template monad runner in OCaml to run the plugins outside Coq. Our first experiments show that we could gain a factor 10 for the time needed to compute the translation of a term. Another solution would be to use the certified CertiCoq compiler, once it supports a kind of foreign function interface, to implement the evaluation.

The last direction of extension is to build higher-level tools on top of the syntax: the unification algorithm described in [28] is our first candidate. Once unification is implemented, we can look at even higher-level tools: elaboration from concrete syntax trees, unification hints like canonical structures and type class resolution, domain-specific and general purpose tactic languages. A key inspiration in this regard is the work of Malecha and Bengston [17] which implemented this idea on a restricted fragment of CIC.