figure a
figure b

1 Introduction

Formalizing mathematics provides every object and statement of the mathematical literature with an explicit data structure, in a certain choice of foundational formalism. As one would expect, several such explicit representations are most often needed for a same mathematical concept. Sometimes, these different choices are already made explicit on paper: multivariate polynomials can for instance be represented as lists of coefficient-monomial pairs, e.g., when computing Gröbner bases, but also as univariate polynomials with polynomial coefficients, e.g., for the purpose of projecting algebraic varieties. The conversion between these equivalent data structures however remains implicit on paper, as they code in fact for the same free commutative algebra. In some other cases, implementation details are just ignored on paper, e.g., when a proof involves both reasoning with Peano arithmetic and computing with large integers.

Example 1 (Proof-oriented vs. computation-oriented data structures)

[Proof-oriented vs. computation-oriented data structures] The standard library of the Coq interactive theorem prover [32] has two data structures for representing natural numbers. Type \(\mathbb {N}\) is the base-1 number system and the associated elimination principle is the usual recurrence scheme:

figure d

On the other hand, type provides a binary representation of non-negative integers, as sequences of bits with a head 1, and is thus better suited for coding efficient arithmetic operations. The successor function is no longer a constructor of the type, but can be implemented as a program, via an auxiliary successor function for type .

figure j

This successor function is useful to implement conversions \(\uparrow _{\mathbb {N}}\ :\ \texttt {N}\ \rightarrow \ \mathbb {N}\) and \(\downarrow _{\mathbb {N}}\ :\ \mathbb {N}\ \rightarrow \ \texttt {N}\) between the unary and binary representations. These conversion functions are in fact inverses of each other. The natural recurrence scheme on natural numbers thus transfers to type :

figure l

Incidentally, can be proved from by using only the fact that \(\downarrow _{\mathbb {N}}\) is a left inverse of \(\uparrow _{\mathbb {N}}\), and the following compatibility lemmas:

$$\begin{aligned} \downarrow _{\mathbb {N}}\texttt {O}_{\mathbb {N}} = \texttt {O}_{\texttt {N}} \quad \text {and} \quad \forall n : \mathbb {N},\quad \downarrow _{\mathbb {N}}(\texttt {S}_{\mathbb {N}}\ n) = \texttt {S}_\texttt {N}\ (\downarrow _{\mathbb {N}}\,n) \end{aligned}$$

Proof transfer issues are not tied to program verification. For instance, the formal study of summation and integration, in basic real analysis, provides a classic example of frustrating bureaucracy.

Example 2 (Extended domains)

[Extended domains] Given a sequence \((u_n)_{n\in \mathbb {N}}\) of non-negative real numbers, i.e., a function \(u\ : \ \mathbb {N} \rightarrow [0,+\infty [\), u is said to be summable when the sequence \((\sum _{k=0}^nu_k)_{n\in \mathbb {N}}\) has a finite limit, denoted \(\sum u\). Now for two summable sequences u and v, it is easy to see that \(u + v\), the sequence obtained by point-wise addition of u and v, is also a summable sequence, and that:

$$\begin{aligned} \sum (u + v) = \sum u + \sum v \end{aligned}$$

As expression \(\sum u\) only makes sense when u is a summable sequence, any algebraic operation “under the sum”, e.g., rewriting \(\sum (u + (v + w))\) into \(\sum ((w + u) + v)\), a priori requires a proof of summability for every rewriting step. In a classical setting, the standard approach rather assigns a default value to the case of an infinite sum, and introduces an extended domain \([0,+\infty ]\). Algebraic operations on real numbers, like addition, are extended to the extra \(+\infty \) case. Now for a sequence \(u\ : \ \mathbb {N} \rightarrow [0,+\infty ]\), the limit \(\sum u\) is always defined, as increasing partial sums either converge to a finite limit, or diverge to \(+\infty \). The road map is then to first prove that Equation 1 holds for any two sequences of extended non-negative numbers. The result is then transferred to the special case of summable sequences of non-negative numbers. Major libraries of formalized mathematics including Lean’s mathlib [1], Isabelle/HOL’s Archive of Formal Proofs, coq-interval [20] or Coq’s mathcomp-analysis [2], resort to such extended domains and transfer steps, notably for defining measure theory. Yet, as reported by expert users [18], the associated transfer bureaucracy is essentially done manually and thus significantly clutters formal developments in real and complex analysis, probabilities, etc.

Users of interactive theorem provers should be allowed to elude mundane arguments pertaining to proof transfer, as they would on paper, and spare themselves the related bureaucracy. Yet, they still need to convince the proof checker and thus have to provide explicit transfer proofs, albeit ideally automatically generated ones. The present work aims at providing a general method for implementing this nature of automation, for a diverse range of proof transfer problems.

In this paper, we focus on interactive theorem provers based on dependent type theory, such as Coq, Agda [24] or Lean [22]. These proof management systems are genuine functional programming languages, with full-spectrum dependent types, a context in which representation independence meta-theorems can be turned into concrete instruments for achieving program and proof transfer.

Seminal results on the contextual equivalence of distinct implementations of a same abstract interface were obtained for System F, using logical relations [21] and parametricity meta-theorems [26, 35]. In the context of type theory, such meta-theorems can be turned into syntactic translations of the type theory of interest into itself, automating this way the generation of the statement and proof of parametricity properties for type families and for programs. Such syntactic relational models can accommodate dependent types [10], inductive types [9] and scale to the Calculus of Inductive Constructions, with an impredicative sort [19].

In particular, the univalent parametricity translation [30] leverages the univalence axiom [33] so as to transfer statements using established equivalences of types. This approach crucially removes the need for devising an explicit common interface for the types in relation. In presence of an internalized univalence axiom and of higher-inductive types, the structure identity principle provides internal representations of independence results, for more general relations between types than equivalences [5]. This last approach is thus particularly relevant in cubical type theory [12, 34]. Indeed, a computational interpretation of the univalence axiom brings computational adequacy to otherwise possibly stuck terms, those resulting from a transfer involving an axiomatized univalence principle.

Yet taming the bureaucracy of proof transfer remains hard in practice for users of Coq, Lean or Agda. Examples 1 and 2 actually illustrate fundamental limitations of the existing approaches:

Univalence is overkill Both univalent parametricity and the structure identity principle can be used to derive the statement and the proof of the induction principle of Example 1, from the elimination scheme of type \(\mathbb {N}\). But up to our knowledge, all the existing methods for automating this implication pull in the univalence principle in the proof, although it can be obtained by hand by very elementary means. This limitation is especially unsatisfactory for developers of libraries formalizing classical mathematics, and notably Lean’s mathlib. These libraries indeed typically assume a strong form of proof irrelevance, which is incompatible with univalence, and thus with univalent parametricity.

Equivalences are not enough, neither are quotients Univalent parametricity cannot help with Example 2, as type \([0,+\infty [\) is not equivalent to its extended version \([0,+\infty ]\). In fact, we are not aware of any tool able to automate this proof transfer. In particular, the structure identity principle [5] would not apply as such.

Contributions In short, existing techniques for transferring results from one type to another, e.g., from to or from extended real numbers to real numbers, are either not suitable for dependent types, or too coarse to track the exact amount of data needed in a given proof, and not more. This paper presents three contributions improving this unfortunate state of affairs:

  • A parametricity framework à la carte, that generalizes the univalent parametricity translation [30], as well as refinements à la CoqEAL [14] and generalized rewriting [28]. Its pivotal ingredient is a variant of Altenkirch and Kaposi’s symmetrical presentation of type equivalence [3].

  • A conservative subtyping extension of \(CC_{\omega }\) [15], used to formulate an inference algorithm for the synthesis of parametricity proofs.

  • The implementation of a new parametricity plugin for the Coq interactive theorem prover, using the Coq-Elpi [31] meta-language. This plugin rests on original formal proofs, conducted on top of the HoTT library [8], and is distributed with a collection of application examples.

Outline The rest of this paper is organized as follows. Section 2 introduces proof transfer and recalls the principle, strengths and weaknesses of the univalent parametricity translation. In Section 3, we present a new definition of type equivalence, motivating a hierarchy of structures for relations preserved by parametricity. Section 4 then presents variants of parametricity translations. In Section 5, we discuss a few examples of applications and we conclude in Section 6.

2 Strengths and limits of univalent parametricity

We first clarify the essence of proof transfer in dependent type theory (§ 2.1) and briefly recall a few concepts related to type equivalence and univalence (§ 2.2). We then review and discuss the limits of univalent parametricity (§ 2.3).

2.1 Proof transfer in type theory

We recall the syntax of the Calculus of Constructions, \(CC_{\omega }\), a \(\lambda \)-calculus with dependent function types and a predicative hierarchy of universes, denoted \(\square _{i}\):

$$A, B, M, N :\,\!:= \square _{i}\ |\ x\ |\ M\ N \ |\ \lambda x : A.\,M \ |\ \varPi x : A.\,B$$

We omit the typing rules of the calculus, and refer the reader to standard references (e.g.,  [23, 25]). We also use the standard equality type, called propositional equality, as well as dependent pairs, denoted \(\varSigma x : A.\,B\). We write \(t \equiv u\) the definitional equality between two terms t and u. Interactive theorem provers like Coq, Agda and Lean are based on various extensions of this core, notably with inductive types or with an impredicative sort. When the universe level does not matter, we casually remove the annotation and use notation \(\square _{}\).

In this context, proof transfer from type \(T_1\) to type \(T_2\) roughly amounts to synthesizing a new type former \(W : T_2 \rightarrow \square _{}\), i.e., a type parametric in some type \(T_2\), from an initial type former \(V : T_1 \rightarrow \square _{}\), i.e., a type parametric in some type \(T_1\), so as to ensure that for some given relations \(R_{T} : T_1 \rightarrow T_2 \rightarrow \square _{}\) and \(R_{\square _{}} : \square _{} \rightarrow \square _{} \rightarrow \square _{}\), there is a proof w that:

$$\ \varGamma \vdash w : \forall (t_1 : T_1) (t_2 : T_2), R_{T}\ t_1\ t_2 \rightarrow R_{\square _{}}(V\ t_1) (W\ t_2)$$

for a suitable context \(\varGamma \). This setting generalizes as expected to k-ary type formers, and to more pairs of related types. In practice, relation \(R_{\square _{}}\) is often a right-to-left arrow, i.e., \(R_{\square _{}}\ A\ B \triangleq B \rightarrow A\), as in this case the proof w substantiates a proof step turning a goal clause \(\varGamma \vdash V\ t_1\) into \(\varGamma \vdash W\ t_2\).

Phrased as such, this synthesis problem is arguably quite loosely specified. Consider for instance the transfer problem discussed in Example 1. A first possible formalization involves the design of an appropriate common interface structure for types \(\mathbb {N}\) and \(\texttt {N}\), for instance by setting both \(T_1\) and \(T_2\) as \(\varSigma N : \square _{}. N \times (N \rightarrow N)\), and both V and W as: \(\lambda X : T_1.\, \varPi P : X.1 \rightarrow \Box .\, P\ X.2 \rightarrow (\varPi n : X.1.\, P\ n \rightarrow P\ (X.3\ n)) \rightarrow \varPi n : X.1.\, P\ n\), where X.i denotes the i-th item in the dependent tuple X. In this case, relation \(R_T\) may characterize isomorphic instances of the structure. Such instances of proof transfer are elegantly addressed in cubical type theories via internal representation independence results [5]. In the context of \(CC_{\omega }\), the hassle of devising explicit structures by hand has been termed the anticipation problem [30].

Another option is to consider two different types \(T_1 \triangleq \mathbb {N} \times (\mathbb {N} \rightarrow \mathbb {N})\) and \(T_2 \triangleq \textrm{N} \times (\textrm{N} \rightarrow \textrm{N})\) and

$$\begin{aligned} V' \triangleq \ {} & \lambda X : T_1.\ \forall P : \mathbb {N} \rightarrow \Box .\ P\ X.1 \rightarrow (\forall n : \mathbb {N}, P\ n \rightarrow P (X.2\ n)) \rightarrow \forall n : \mathbb {N}, P\ n\\ W' \triangleq \ {} & \lambda X : T_2.\ \forall P : \textrm{N} \rightarrow \Box .\ P\ X.1 \rightarrow (\forall n : \textrm{N}, P\ n \rightarrow P (X.2\ n)) \rightarrow \forall n : \textrm{N}, P\ n \end{aligned}$$

where one would typically expect \(R_T\) to be a type equivalence between \(T_1\) and \(T_2\), so as to transport \((V'\ t_1)\) to \((W'\ t_2)\), along this equivalence.

Note that some solutions of given instances of proof transfer problems are in fact too trivial to be of interest. Consider for example the case of a functional relation between \(T_2\) and \(T_1\), with \(R_T \ t_1\ t_2\) defined as \(t_1 = \phi \ t_2\), for some \(\phi : T_2 \rightarrow T_1\). In this case, the composition \(V \circ \phi \) is an obvious candidate for W, but is often uninformative. Indeed, this composition can only propagate structural arguments, blind to the additional mathematical proofs of program equivalences potentially available in the context. For instance, here is a useless variant of \(W'\):

$$\begin{aligned} W'' \triangleq \lambda X : T_2. \quad & \forall P : \mathbb {N} \rightarrow \Box .\ P\ (\uparrow _{\mathbb {N}} X.1) \rightarrow \\ & \left( \forall n : \mathbb {N}, P\ n \rightarrow P \left( \uparrow _{\mathbb {N}} (X.2\ (\downarrow _{\mathbb {N}} n))\right) \right) \rightarrow \forall n : \mathbb {N}, P\ n. \end{aligned}$$

Automation devices dedicated to proof transfer thus typically consist of a meta-program which attempts to compute type former W and proof w by induction on the structure of V, by composing registered canonical pairs of related terms, and the corresponding proofs. These tools differ by the nature of relations they can accommodate, and by the class of type formers they are able to synthesize. For instance, generalized rewriting [28], which provides essential support to formalizations based on setoids [7], addresses the case of homogeneous (and reflexive) relations, i.e., when \(T_1\) and \(T_2\) coincide. The CoqEAL library [14] provides another example of such transfer automation tool, geared towards refinements, typically from a proof-oriented data-structure to a computation-oriented one. It is thus specialized to heterogeneous, functional relations but restricted to closed, quantifier-free type formers. We now discuss the few transfer methods which can accommodate dependent types and heterogeneous relations.

2.2 Type equivalences, univalence

Let us first focus on the special case of types related by an equivalence, and start with a few standard definitions, notations and lemmas. Omitted details can be found in the usual references, like the Homotopy Type Theory book [33]. Two functions \(f,g : A \rightarrow B\) are point-wise equal, denoted \(f \doteqdot g\) when their values coincide on all arguments, that is \(f \doteqdot g \triangleq \varPi a : A.\,f\ a = g\ a\). For any type A, \(id_A\) denotes \(\lambda a : A.\,a\), the identity function on A, and we write id when the implicit type A is not ambiguous.

Definition 1 (Type isomorphism, type equivalence)

[Type isomorphism, type equivalence] A function \(f : A \rightarrow B\) is an isomorphism, denoted \(\textsf {IsIso}(f)\), if there exists a function \(g : B \rightarrow A\) which satisfies the section and retraction properties, i.e., g is respectively a point-wise left and right inverse of f. A function f is an equivalence, denoted \(\textsf {IsEquiv}(f)\), when it moreover enjoys a coherence property, relating the proofs of the section and retraction properties and ensuring that \(\textsf {IsEquiv}(f)\) is proof-irrelevant.

Types A and B are equivalent, denoted \(A \simeq B\), when there is an equivalence \(f : A \rightarrow B\):

$$\begin{aligned} A \simeq B \triangleq \varSigma f : A \rightarrow B.\,\textsf {IsEquiv}(f) \end{aligned}$$

Lemma 1

Any isomorphism \(f : A \rightarrow B\) is also an equivalence.

The data of an equivalence \(e : A \simeq B\) thus include two transport functions, denoted respectively \(\uparrow _e\ : A \rightarrow B\) and \(\downarrow _e\ : B \rightarrow A\). They can be used for proof transfer from A to B, using \(\uparrow _e\) at covariant occurrences, and \(\downarrow _e\) at contravariant ones. The univalence principle asserts that equivalent types are interchangeable, in the sense that all universes are univalent.

Definition 2 (Univalent universe)

[Univalent universe] A universe \(\mathcal {U}\) is univalent if for any two types A and B in \(\mathcal {U}\), the canonical map \(A = B \rightarrow A \simeq B\) is an equivalence.

In variants of \(CC_{\omega }\), the univalence axiom has no explicit computational content: it just postulates that all universes \(\Box _i\) are univalent, as for instance in the HoTT library for the Coq interactive theorem prover [8]. Some more recent variants of dependent type theory [4, 12] feature a built-in computational univalence principle. They are used to implement experimental interactive theorem provers, such as Cubical Agda [34]. In both cases, the univalence principle provides a powerful proof transfer principle from \(\square _{}\) to \(\square _{}\), as for any two types A and B such that \(A \simeq B\), and any \(P : \square _{} \rightarrow \square _{}\), we can obtain that \(P\ A \simeq P\ B\) as a direct corollary of univalence. Concretely, \(P\ B\) is obtained from \(P\ A\) by appropriately allocating the transfer functions provided by the equivalence data, a transfer process typically useful in the context of proof engineering [27].

Going back to our example from § 2.1, transferring along an equivalence \(\mathbb {N} \simeq \texttt {N}\) thus produces \(W''\) from \(V'\). Assuming univalence, one may achieve the more informative transport from \(V'\) to \(W'\), using a method called univalent parametricity [30], which we discuss in the next section.

2.3 Parametricity translations

Univalent parametricity strengthens the transfer principle provided by the univalence axiom by combining it with parametricity. In \(CC_{\omega }\), the essence of parametricity, which is to devise a relational interpretation of types, can be turned into an actual syntactic translation, as relations can themselves be modeled as \(\lambda \)-terms in \(CC_{\omega }\). The seminal work of Bernardy, Lasson et al. [9, 10, 19] combine in what we refer to as the raw parametricity translation, which essentially defines inductively a logical relation \(\llbracket \,T\,\rrbracket \) for any type T, as described on Figure 1. This presentation uses the standard convention that \(t'\) is the term obtained from a term t by replacing every variable x in t with a fresh variable \(x'\). A variable x is translated into a variable \(x_R\), where \(x_R\) is a fresh name. Parametricity follows from the associated fundamental theorem, also called abstraction theorem [26]:

Fig. 2.
figure 1

Raw parametricity translation for \(CC_{\omega }\).

Theorem 1

If \(\ \varGamma \vdash t : T\) then the following hold: \(\ \llbracket \,\varGamma \,\rrbracket \vdash t : T\), \(\ \llbracket \,\varGamma \,\rrbracket \vdash t' : T'\) and \(\ \llbracket \,\varGamma \,\rrbracket \vdash \llbracket \,t\,\rrbracket : \llbracket \,T\,\rrbracket \ t\ t'\).


By structural induction on the typing judgment, see for instance [19].

A key, albeit mundane ingredient of Theorem 1 is the fact that the rules of Figure 1 ensure that:

$$\begin{aligned} \vdash \llbracket \,\square _{i}\,\rrbracket \ :\ \llbracket \,\square _{i+1}\,\rrbracket \ \square _{i}\ \square _{i} \end{aligned}$$

This translation precisely generates the statements expected from a parametric type family or program. For instance, the translation of a \(\varPi \)-type, given by Equation 8, is a type of relations on functions that relate those producing related outputs from related inputs. Concrete implementations of this translation are available [19, 31]; they generate and prove parametricity properties for type families or for constants, improved induction schemes, etc.

Univalent parametricity follows from the observation that the abstraction theorem still holds when restricting to relations that are in fact (heterogeneous) equivalences. This however requires some care in the translation of universes:

$$\begin{aligned} \llbracket \,\square _{i}\,\rrbracket \ A\ B {} & {} \triangleq \varSigma (R : A \rightarrow B \rightarrow \square _{i}) (e : A \simeq B). \nonumber \\ {} & {} \qquad \qquad \qquad \qquad \qquad \varPi (a : A) (b : B).\,R\ a\ b \simeq (a =\,\downarrow _e b) \end{aligned}$$

where \(\llbracket \,\cdot \,\rrbracket \) now refers to the univalent parametricity translation, replacing the notation introduced for the raw variant. For any two types A and B, \(\llbracket \,\square _{i}\,\rrbracket \ A\ B\) packages a relation R and an equivalence e such that R is equivalent to the functional relation associated with \(\downarrow _e\). Crucially, assuming univalence, \(\llbracket \,\square _{i}\,\rrbracket \) is equivalent to type equivalence, that is, for any two types A and B:

$$\begin{aligned} \llbracket \,\square _{i}\,\rrbracket \ A\ B \simeq (A \simeq B). \end{aligned}$$

This observation is actually an instance of a more general technique available for constructing syntactic models of type theory [11], based on attaching extra intensional specifications to negative type constructors. In these models, a standard way to recover the abstraction theorem consists of refining the translation into two variants, for any term \(T : \square _{i}\), that is also a type. The translation of such a T as a term, denoted \([\,T\,]\), is a dependent pair, which equips a relation with the additional data prescribed by the interpretation \(\llbracket \,\square _{i}\,\rrbracket \) of the universe. The translation \(\llbracket \,T\,\rrbracket \) of T as a type is the relation itself, that is, the projection of the dependent pair \([\,T\,]\) onto its first component, denoted \(\textsf {rel}([\,T\,])\). We refer to the original article [30, Figure 4] for a complete description of the translation.

We now state the abstraction theorem of the univalent parametricity translation [30], where \(\vdash _u\) denotes a typing judgment of \(CC_{\omega }\) assuming univalence:

Theorem 2

If \(\ \varGamma \vdash t : T\) then \(\llbracket \,\varGamma \,\rrbracket \vdash _u [\,t\,]\ :\ \llbracket \,T\,\rrbracket \ t\ t'\).

Note that proving the abstraction theorem 2 involves in particular proving that:

$$\begin{aligned} \vdash _u [\,\square _{i}\,]\ :\ \llbracket \,\square _{i+1}\,\rrbracket \ \square _{i}\ \square _{i} \quad \text {and} \quad \textsf {rel}([\,\square _{i}\,]) \equiv \llbracket \,\square _{i}\,\rrbracket . \end{aligned}$$

The definition of relation \([\,\square _{i}\,]\) relies on the univalence principle in a crucial way, in order to prove that the relation in the universe is equivalent to equality on the universe, i.e., to prove that:

$$\begin{aligned} \vdash _u \varPi A\,B : \square _{i}.\,\llbracket \,\square _{i}\,\rrbracket \ A\ B\simeq (A = B). \end{aligned}$$

Importantly, this univalent parametricity translation can be seamlessly extended so as to also make use of a global context of user-defined equivalences.

Yet because of the interpretation of universes given by Equation 10, univalent parametricity can only automate proof transfer based on type equivalences. This is too strong a requirement in many cases, e.g., to deduce properties of natural numbers from that of integers, or more generally for refinement relations. Even in the case of equivalent types, this restriction may be problematic, as Equation 11 may incur unnecessary dependencies on the univalence axiom, as in Example 1.

3 Type equivalence in kit

In this section, we propose (§ 3.1) an equivalent, modular presentation of type equivalence, phrased as a nested sigma type. Then (§ 3.2), we carve a hierarchy of structures on relations out of this dependent tuple, selectively picking pieces. Last, we revisit (§ 3.3) parametricity translations through the lens of this finer grained analysis of the relational interpretations of types.

3.1 Disassembling type equivalence

Let us first observe that the Definition 1, of type equivalence, is quite asymmetrical, although this fact is somehow swept under the rug by the infix \(A \simeq B\) notation. First, the data of an equivalence \(e : A \simeq B\) privileges the left-to-right direction, as \(\uparrow _e\) is directly accessible from e as its first projection, while accessing the right-to-left transport requires an additional projection. Second, the statement of the coherence property, which we eluded in Definition 1, is actually:

$$ \varPi a : A.\,\textsf {ap}_{\uparrow _e} (s\ a) = r\ \circ \,\downarrow _e $$

where \(\textsf {ap}_f (t)\) is the term \(f\ u = f\ v\), for any identity proof \(t : u = v\). This statement uses proofs s and r, respectively of the section and retraction properties of e, but not in a symmetrical way, although swapping them leads to an equivalent definition. This entanglement prevents tracing the respective roles of each direction of transport, left-to-right or right-to-left, during the course of a given univalent parametricity translation. Exercise 4.2 in the HoTT book [33] however suggests a symmetrical definition of type equivalence, via functional relations.

Definition 3

A relation \(R : A \rightarrow B \rightarrow \square _{i}\), is functional when:

$$\begin{aligned} \varPi a : A.\,\textsf {IsContr}(\varSigma b : B.\,R\ a\ b) \end{aligned}$$

where for any type T, \(\textsf {IsContr}(T)\) is the standard contractibility predicate \(\varSigma t : T.\,\varPi t' : T.\,t = t'\). This property is denoted \(\textsf {IsFun}(R)\).

We can now obtain an equivalent but symmetrical characterization of type equivalence, as a functional relation whose symmetrization is also functional.

Lemma 2

For any types \(A, B : \square _{}\), type \(A \simeq B\) is equivalent to:

$$\begin{aligned} \varSigma R : A \rightarrow B \rightarrow \square _{}.\,\textsf {IsFun}(R) \times \textsf {IsFun}({R}^{-1}) \end{aligned}$$

where \({R}^{-1} : B \rightarrow A \rightarrow \square _{}\) just swaps the arguments of relation \(R : A \rightarrow B \rightarrow \square _{}\).

We sketch below a proof of this result, left as an exercise in [33]. The essential argument is the following characterization of functional relations:

Lemma 3

The type of functions is equivalent to the type of functional relations; i.e., for any types \(A, B\ :\ \square _{}\), we have \((A \rightarrow B) \, \simeq \, \varSigma R : A \rightarrow B \rightarrow \square _{}.\,\textsf {IsFun}(R)\).


The proof goes by chaining the following equivalences:

$$\begin{aligned} \left( \varSigma R : A \rightarrow B \rightarrow \square _{}.\,\textsf {IsFun}(R)\right) & \simeq \left( A \rightarrow \varSigma P : B \rightarrow \square _{}.\,\textsf {IsContr}(\varSigma b : B.\,P\ b)\right) \\ & \simeq (A \rightarrow B) \end{aligned}$$


(of Lemma 2). The proof goes by chaining the following equivalences, where the type of f is always \(A \rightarrow B\) and the type of R is \(A \rightarrow B \rightarrow \square _{}\):

$$\begin{aligned} (A \simeq B) & \simeq \varSigma f : A \rightarrow B.\,\textsf {IsEquiv}(f) &\,& \text {by definition of }(A \simeq B) \\ & \simeq \varSigma f.\,\varPi b : B.\,\textsf {IsContr}(\varSigma a. f\ a = b) &\,& \text {standard result in HoTT} \\ & \simeq \varSigma f.\,\textsf {IsFun}(\lambda (b : B) (a : A).\,f\ a = b) &\,& \text {by definition of } \textsf {IsFun}(\cdot ) \\ & \simeq \varSigma \left( \varphi : \varSigma R.\,\textsf {IsFun}(R)\right) .\,\textsf {IsFun}( \pi _1(\varphi )^{-1}) &\,& \text {by Lemma 3} \\ & \simeq \varSigma R.\,\textsf {IsFun}(R) \times \textsf {IsFun}(R^{-1}) &\,& \text {by associativity of } \varSigma . \end{aligned}$$

However, the definition of type equivalence provided by Lemma 2 does not expose explicitly the two transfer functions in its data, although this computational content can be extracted via first projections of contractibility proofs. In fact, it is possible to devise a definition of type equivalence which directly provides the two transport functions in its data, while remaining symmetrical. This variant follows from an alternative characterization of functional relations.

Definition 4

For any types \(A, B : \square _{}\), a relation \(R : A \rightarrow B \rightarrow \square _{}\), is a univalent map, denoted \(\textsf {IsUmap}(R)\) when there exists a function \(m : A \rightarrow B\) together with:

$$\begin{aligned} & g_1 : \varPi (a : A) (b : B).\,m\ a = b \rightarrow R\ a\ b \\ \text {and} & g_2 : \varPi (a : A) (b : B).\,R\ a\ b \rightarrow m\ a = b \\ \text {such that} & \varPi (a : A) (b : B).\,(g_1\ a\ b) \circ (g_2 \ a\ b) \doteqdot id. \end{aligned}$$

Now comes the crux lemma of this section.

Lemma 4

For any types \(A, B : \square _{}\) and any relation \(R : A \rightarrow B \rightarrow \square _{}\)

$$\begin{aligned} \textsf {IsFun}(R) \simeq \textsf {IsUmap}(R). \end{aligned}$$


The proof goes by rewording the left hand side, in the following way:

$$\begin{aligned} \varPi x. & \,\textsf {IsContr}(R\ x) \\ & \simeq \varPi x.\,\varSigma (r : \varSigma y.\,R\ x\ y).\,\varPi (p : \varSigma y.\,R\ x\ y).\,r = p \\ & \simeq \varPi x.\,\varSigma y.\,\varSigma (r : R\ x\ y).\,\varPi (p : \varSigma y.\,R\ x\ y).\,(y, r) = p \\ {} & \simeq \varSigma f.\,\varPi x.\,\varSigma (r : R\ x\ (f\ x)).\,\varPi (p : \varSigma y.\,R\ x\ y).\,(f\ x, r) = p \\ & \simeq \varSigma f.\,\varSigma (r : \varPi x.\,R\ x\ (f\ x)).\,\varPi x.\,\varPi (p : \varSigma y.\, R\ x\ y).\,(f\ x, r\ x) = p \\ & \simeq \varSigma f.\,\varSigma r.\,\varPi x.\,\varPi y.\,\varPi (p : R\ x\ y).\,(f\ x, r\ x) = (y, p) \\ & \simeq \varSigma f.\,\varSigma r.\,\varPi x.\,\varPi y.\,\varPi (p : R\ x\ y).\,\varSigma (e : f\ x = y).\,r\ x =_e p \\ & \simeq \varSigma f.\,\varSigma r.\, \varSigma (e : \varPi x.\,\varPi y.\,R\ x\ y \rightarrow f\ x = y).\, \varPi x.\,\varPi y.\,\varPi p.\,(r\ x) =_{e\,x\,y\,p} p \end{aligned}$$

After a suitable reorganization of the sigma types we are left to show that

$$\begin{aligned} &\varSigma (r : \varPi x.\,\varPi y.\,f\ x = y \rightarrow R\ x\ y).\,(e\,x\,y) \circ (r\,x\,y) \doteqdot id \\ \simeq & \varSigma (r : \varPi x.\,R\ x\ (f\ x)).\,\varPi x.\,\varPi y.\,\varPi p.\,r\ x =_{e\,x\,y\,p} p \end{aligned}$$

which proof we do not detail, referring the reader to the supplementary material.

As a direct corollary, we obtain a novel characterization of type equivalence:

Theorem 3

For any types \(A, B : \square _{i}\), we have:

figure r

where the relation is defined as:

$$\begin{aligned} \varSigma R : A \rightarrow B \rightarrow \square _{i}.\,\textsf {IsUmap}(R) \times \textsf {IsUmap}({R}^{-1}) \end{aligned}$$

The collection of data packed in a term of type is now symmetrical, as the right-to-left direction of the equivalence based on univalent maps can be obtained from the left-to-right by flipping the relation and swapping the two functionality proofs. If the \(\eta \)-rule for records is verified, symmetry is even definitionally involutive.

3.2 Reassembling type equivalence

Definition 4 of univalent maps and the resulting rephrasing of type equivalence suggest introducing a hierarchy of structures for heterogeneous relations, which explains how close a given relation is to type equivalence. In turn, this distance is described in terms of structure available respectively on the left-to-right and right-to-left transport functions.

Definition 5

For \(n, k \in \{0, 1, 2_{\text {a}}, 2_{\text {b}}, 3, 4\}\), and \(\alpha =(n,k)\), relation , is defined as:

figure v

where the map class \(\textsf {Class}_{\alpha }\ R\) itself unfolds to a pair type \((\textsf {M}_{n}\ R) \times (\textsf {M}_{k}\ {R}^{-1})\), with \(\textsf {M}_{i}\) defined as:Footnote 1

$$\begin{aligned} \textsf {M}_{0}\ R \triangleq &\ .\\ \textsf {M}_{1}\ R \triangleq &\ (A \rightarrow B)\\ \textsf {M}_{2_{\text {a}}}\ R \triangleq &\ \varSigma m : A \rightarrow B.\, G_{2_{\text {a}}}\ m\ R\quad \text { with } G_{2_{\text {a}}}\ m\ R\ \triangleq \varPi a\,b.\,m\ a = b \rightarrow R\ a\ b \\ \textsf {M}_{2_{\text {b}}}\ R \triangleq &\ \varSigma m : A \rightarrow B.\,G_{2_{\text {b}}}\ m\ R\quad \text { with } G_{2_{\text {b}}}\ m\ R\ \triangleq \varPi a\,b.\,R\ a\ b \rightarrow m\ a = b\\ \textsf {M}_{3}\ R \triangleq &\ \varSigma m : A \rightarrow B.\,(G_{2_{\text {a}}}\ m\ R)\times (G_{2_{\text {b}}}\ m\ R)\\ \textsf {M}_{4}\ R \triangleq &\ \varSigma m : A \rightarrow B.\,\varSigma (g_1 : G_{2_{\text {a}}}\ m\ R).\,\varSigma (g_2 : G_{2_{\text {b}}}\ m\ R).\,\varPi a\,b.\\ &\ (g_1\ a\ b) \circ (g_2\ a\ b) \doteqdot id \end{aligned}$$

For any types A and B, and any we use notations \(\textsf {rel}(r)\), \(\textsf {map}(r)\) and \(\textsf {comap}(r)\) to refer respectively to the relation, map of type \(A \rightarrow B\), map of type \(B \rightarrow A\), included in the data of r, for a suitable \(\alpha \).

Definition 6

We denote \(\mathcal {A}\) the set \(\{0, 1, 2_{\text {a}}, 2_{\text {b}}, 3, 4\}^2\), used to index map classes in Definition 5. This set is partially ordered for the product order defined from the partial order \(0 < 1 < 2_{*} < 3 < 4\) for \(2_{*}\) either \(2_\text {a}\) or \(2_\text {b}\), and with \(2_\text {a}\) and \(2_\text {b}\) being incomparable.

Remark 1

Relation of Definition 5 coincides with the relation introduced in Theorem 3. Similarly, we denote the relation .

Remark 2

Definition 5 is associated with the following dictionary. For r of type:

  • , \(\textsf {map}(r)\) is an arbitrary function \(f : A \rightarrow B\);

  • , \(\textsf {rel}(r)\) is a univalent map, in the sense of Definition 4;

  • , \(\textsf {rel}(r)\) is the graph of a retraction (i.e., a subjective univalent map with an explicit partial left inverse) of type \(A \rightarrow B\);

  • , \(\textsf {rel}(r)\) is the graph of a section (i.e., an injective univalent map with explicit partial right inverse) of type \(A \rightarrow B\);

  • , r is an equivalence between A and B;

  • , r is an isomorphism between A and B.

Observe that coincides, up to equivalence, with . Other classes, while not corresponding to a meaningful mathematical definition, may arise in concrete runs of proof transfer: see also Section 4 for explicit examples.

The corresponding lattice to the collection of \(\textsf {M}_{n}\) is implemented as a hierarchy of dependent tuples, more precisely, of record types.

3.3 Populating the hierarchy of relations

We shall now revisit the parametricity translations of Section 2.3. In particular, combining Theorem 3 with Equation 11, crux of the abstraction theorem for univalent parametricity, ensures the existence of a term \(p_{\square _{i}}\) such that:

figure aj

Otherwise said, relation can be endowed with a structure, assuming univalence. Similarly, Equation 9, for the raw parametricity translation, can be read as the fact that relation on universes can be endowed with a structure.

Now the hierarchy of structures introduced by Definition 5 enables a finer grained analysis of the possible relational interpretations of universes. Not only would this put the raw and univalent parametricity translations under the same hood, but it would also allow for generalizing parametricity to a larger class of relations. For this purpose, we generalize the previous observation, on the key ingredient for translating universes: for each \(\alpha \in \mathcal {A}\), relation may be endowed with several structures from the lattice, and we need to study which ones, depending on \(\alpha \). Otherwise said, we need to identify the pairs \((\alpha , \beta )\in \mathcal {A}^2\) for which it is possible to construct a term \(p_\Box ^{\alpha , \beta }\) such that:


Note that we aim here at a definitional equality between \(\textsf {rel}(p_\Box ^{\alpha , \beta })\) and , rather than at an equivalence. It is easy to see that a term \(p_\Box ^{\alpha , \bot }\) exists for any \(\alpha \in \mathcal {A}\), as requires no structure on the relation. On the other hand, it is not possible to construct a term \(p_\Box ^{\bot , \top }\), i.e., to turn an arbitrary relation into a type equivalence.

Definition 7

We denote \(\mathcal {D}_\Box \) the following subset of \(\mathcal {A}^2\):

$$\begin{aligned} \mathcal {D}_{\Box } = \{(\alpha , \beta )\in \mathcal {A}^2\ |\ \alpha = \top \vee \beta \in \{0, 1, 2_{\text {a}}\}^2\} \end{aligned}$$

The supplementary material constructs terms \(p_\Box ^{\alpha , \beta }\) for every pair \((\alpha ,\beta )\in \mathcal {D}_\Box \), using a meta-program to generate them from a minimal collection of manual definitions. In particular, assuming univalence, it is possible to construct a term \(p_{\square _{}}^{\top ,\top }\), which can be seen as an analogue of the translation [ \(\square _{}\) ] of univalent parametricity. More generally, the provided terms \(p_\Box ^{\alpha , \beta }\) depend on univalence if and only if \(\beta \notin \{0, 1, 2_{\text {a}}\}^2\).

The next natural question concerns the possible structures endowing the relational interpretation of a product type \(\varPi x : A.\, B\), given relational interpretation for types A and B respectively equipped with structures and .

Otherwise said, we need to identify the triples \((\alpha ,\beta ,\gamma )\in \mathcal {A}^3\) for which it is possible to construct a term \(p_{\varPi }^{\gamma }\) such that the following statements both hold:

figure au

The corresponding collection of triples can actually be described as a function \(\mathcal {D}_\varPi : \mathcal {A}\rightarrow \mathcal {A}^2\), such that \(\mathcal {D}_\varPi (\gamma ) = (\alpha , \beta )\) provides the minimal requirements on the structures associated with A and B, with respect to the partial order on \(\mathcal {A}^2\). The supplementary material provides a corresponding collection of terms \(p_\varPi ^{\gamma }\) for each \(\gamma \in \mathcal {A}\), as well as all the associated weakenings. Once again, these definitions are generated by a meta-program. Observe in particular that by symmetry, \(p_\varPi ^{(m, n)}\) can be obtained from \(p_\varPi ^{(m, 0)}\) and \(p_\varPi ^{(n, 0)}\) by swapping the latter and glueing it to the former. Therefore, the values of \(p_\varPi ^\gamma \) and \(\mathcal {D}_\varPi (\gamma )\) are completely determined by those of \(p_\varPi ^{(m, 0)}\) and \(\mathcal {D}_\varPi (m, 0)\). In particular, for any \((m, n)\in \mathcal {A}\):

$$\begin{aligned} \mathcal {D}_\varPi (m, n) = \left( (m_A, n_A), (m_B, n_B)\right) \end{aligned}$$

where \(m_A, n_A, m_B, n_B\in \mathcal {A}\) are such that \(\mathcal {D}_\varPi (m, 0) = \left( (0, n_A), (m_B, 0)\right) \) and \(\mathcal {D}_\varPi (n, 0) = \left( (0, m_A), (n_B, 0)\right) \). We sum up in Figure 2 the values of \(\mathcal {D}_\varPi (m, 0)\).

Fig. 3.
figure 2

Minimal dependencies for product and arrow types

Note that in the case of a non-dependent product, constructing \(p_\rightarrow ^\gamma \) requires less structure on the domain A of an arrow type \(A \rightarrow B\), which motivates the introduction of function \(\mathcal {D}_\rightarrow (\gamma )\). Using the combinator for dependent products to interpret an arrow type, albeit correct, potentially pulls in unnecessary structure (and axiom) requirements. The supplementary material includes a construction of terms \(p_\rightarrow ^\gamma \) for any \(\gamma \in \mathcal {A}\).

The two tables in Figure 2 show how requirements on levels stay the same on the right hand side of both \(\varPi \) and \(\rightarrow \), stay the same up to symmetries (exchange of variance and of \(2_\text {a}\) and \(2_\text {b}\)) on the left hand side of a \(\rightarrow \) and increase on the left hand side of a \(\varPi \). This elegant arithmetic justifies our hierarchy of relations.

4 A calculus for proof transfer

This section introduces Trocq, a framework for proof transfer designed as a generalization of parametricity translations, so as to allow for interpreting types as instances of the structures introduced in Section 3.2. We adopt a sequent style presentation, which fits closely the type system of \(CC_{\omega }\), while explaining in a consistent way the transformations of terms and contexts. This choice of presentation departs from the standard literature about parametricity in pure type systems. Yet, it brings the presentation closer to actual implementations, whose necessary management of parametricity contexts is swept under the rug by notational conventions (e.g., the primes of Section 2.3).

For this purpose, we successively introduce four calculi, of increasing sophistication. We start (§ 4.1) with introducing this sequent style presentation by rephrasing the raw parametricity translation, and the univalent parametricity one (§ 4.2). We then introduce \(CC_{\omega }^+\) (§ 4.3), a Calculus of Constructions with annotations on sorts and subtyping, before defining (§ 4.4) the Trocq calculus.

4.1 Raw parametricity sequents

We introduce parametricity contexts, under the form of a list of triples packaging two variables x and \(x'\) together with a third one \(x_R\). The latter \(x_R\) is a witness (a proof) that x and \(x'\) are related:

$$\begin{aligned} \varXi :\,\!:= \varepsilon \ |\ \varXi ,\; x\,\sim \,x'\ \because \ x_R \end{aligned}$$

We write \((x, x', x_R) \in \varXi \) when \(\varXi = \varXi ',\; x\,\sim \,x'\ \because \ x_R,\; \varXi ''\) for some \(\varXi '\) and \(\varXi ''\).

We denote \(\textrm{Var}(\varXi )\) the sequence of variables related in a parametricity context \(\varXi \), with multiplicities:

$$\textrm{Var}(\varepsilon )= \varepsilon \quad \quad \textrm{Var}(\varXi ,\; x\,\sim \,x'\ \because \ x_R) = \textrm{Var}(\varXi ), x, x', x_R$$

A parametricity context \(\varXi \) is well-formed, written \(\varXi \vdash \), if the sequence \(\textrm{Var}(\varXi )\) is duplicate-free. In this case, we use the notation \(\varXi (x)=(x', x_R)\) as a synonym of \((x, x', x_R) \in \varXi \).

A parametricity judgment relates a parametricity context \(\varXi \) and three terms \(M, M', M_R\) of \(CC_{\omega }\). Parametricity judgments, denoted as:

$$\begin{aligned} \varXi \vdash M\,\sim \,M'\ \because \ M_R, \end{aligned}$$

are defined by rules of Figure 3 and read in context \(\varXi \), term M translates to the term \(M'\), because \(M_R\).

Fig. 4.
figure 3

Param: sequent-style binary parametricity translation

Lemma 5

The relation associating a term M with pairs \((M', M_R)\) such that \(\varXi \vdash M\,\sim \,M'\ \because \ M_R\) holds, with \(\varXi \) a well-formed parametricity context, is functional. More precisely, for any well-formed parametricity context \(\varXi \):

$$\begin{aligned} \forall M, M', N', M_R, N_R, \quad & \varXi \vdash M\,\sim \,M'\ \because \ M_R\quad \wedge \quad \varXi \vdash M\,\sim \,N'\ \because \ N_R\\ {} & \implies \ (M', M_R) = (N', N_R) \end{aligned}$$


Immediate by induction on the syntax of M.

This presentation of parametricity thus provides an alternative definition of translation \(\llbracket \,\cdot \,\rrbracket \) from Figure 1, and accounts for the prime-based notational convention used in the latter.

Definition 8

A parametricity context \(\varXi \) is admissible for a well-formed typing context \(\varGamma \), denoted \({\varGamma }\rhd {\varXi }\), when \(\varXi \) and \(\varGamma \) are well-formed as a parametricity context and \(\varGamma \) provides coherent type annotations for all terms in \(\varXi \), that is, for any variables \(x, x', x_R\) such that \( \varXi (x) = (x', x_R)\), and for any terms \(A'\) and \(A_R\):

$$ \varXi \vdash \varGamma (x)\,\sim \,A'\ \because \ A_R\quad \implies \quad \varGamma (x') = A' \; \wedge \; \varGamma (x_R) \equiv A_R\ x\ x'$$

We can now state and prove an abstraction theorem:

Theorem 4 (Abstraction theorem)

[Abstraction theorem]

figure av


By induction on the derivation of \(\varXi \vdash M\,\sim \,M'\ \because \ M_R\).

4.2 Univalent parametricity sequents

We now propose in Figure 4 a rephrased version of the univalent parametricity translation [30], using the same sequent style and replacing the translation of universes with the equivalent relation . Parametricity judgments are denoted:

$$ \varXi \vdash _{u} M\,\sim \,M'\ \because \ M_R $$

where \(\varXi \) is a parametricity context and M, \(M'\), and \(M_R\) are terms of \(CC_{\omega }\). The u index is a reminder that typing judgments \(\varGamma \vdash _u M : A\) involved in the associated abstraction theorem assume the univalence axiom Fig. 4.

Fig. 5.
figure 4

UParam: univalent parametricity rules

We can now rephrase the abstraction theorem for univalent parametricity.

Theorem 5 (Univalent abstraction theorem)

[Univalent abstraction theorem]

figure ax


By induction on the derivation of \(\varXi \vdash _{u} M\,\sim \,M'\ \because \ M_R\).

Remark 3

In Theorem 5, \(\textsf {rel}(A_R)\) is a term of type \(A \rightarrow A' \rightarrow \Box \). Indeed:

figure ay

entails \(A_R\) has type

figure az

4.3 Annotated type theory

We are now ready to generalize the relational interpretation of types provided by the univalent parametricity translation, so as to allow for interpreting sorts with instances of weaker structures than equivalence. For this purpose, we introduce a variant \(CC_{\omega }^+\) of \(CC_{\omega }\) where each universe is annotated with a label indicating the structure available on its relational interpretation. Recall from Section 3.2 that we have used annotations \(\alpha \in \mathcal {A}\) to identify the different structures of the lattice disassembling type equivalence: these are the labels annotating sorts of \(CC_{\omega }^+\) , so that if A has type \(\Box ^\alpha \), then the associated relation \(A_R\) has type . The syntax of \(CC_{\omega }^+\) is thus:

$$\begin{aligned}\begin{gathered} M, N, A, B \in \mathcal {T}_{CC_{\omega }^+ } :\,\!:= \Box _i^\alpha \ |\ x\ |\ M\ N \ |\ \lambda x : A.\,M\ |\ \varPi x : A.\,B\\ \alpha \in \mathcal {A}= \{0, 1, 2_{\text {a}}, 2_{\text {b}}, 3, 4\}^2 \qquad i \in \mathbb {N} \end{gathered}\end{aligned}$$

Before completing the actual formal definition of the Trocq proof transfer framework, let us informally illustrate how these annotations shall drive the interpretation of terms, and in particular, of a dependent product \(\varPi x : A.\,B\). In this case, before translating B, three terms representing the bound variable x, its translation \(x'\), and the parametricity witness \(x_R\) are added to the context. The type of \(x_R\) is \(\textsf {rel}(A_R)\ x\ x'\) where \(A_R\) is the parametricity witness relating A to its translation \(A'\). The role of annotation \(\alpha \) on the sort typing type A is thus to to govern the amount of information available in witness \(x_R\), by determining the type of \(A_R\). This intent is reflected in the typing rules of \(CC_{\omega }^+\) , which rely on the definition of the loci \(\mathcal {D}_{\Box }\), \(\mathcal {D}_{\rightarrow }\) and \(\mathcal {D}_{\varPi }\), introduced in §3.3.

Contexts are defined as usual, but typing terms in \(CC_{\omega }^+\) requires defining a subtyping relation \(\preccurlyeq \), defined by the rules of Figure 5. The typing rules of \(CC_{\omega }^+\) are available in Figure 6 and follow standard presentations [6]. The \(\equiv \) relation in the (SubConv) rule is the conversion relation, defined as the closure of \(\alpha \)-equivalence and \(\beta \)-reduction. The two types of judgment in \(CC_{\omega }^+\) are thus:

$$ \varGamma \vdash _{+} A \preccurlyeq B \quad \text {and} \quad \varGamma \vdash _{+} M : A $$

where MA and B are terms in \(CC_{\omega }^+ \) and \(\varGamma \) is a context in \(CC_{\omega }^+ \).

Fig. 6.
figure 5

Subtyping rules for \(CC_{\omega }^+\)

Fig. 7.
figure 6

Typing rules for \(CC_{\omega }^+\)

Due to space constraints, we omit the direct proof that \(CC_{\omega }^+\) is a conservative extension over \(CC_{\omega }\). It goes by defining an erasure function for terms \(\left| \,\,\cdot \,\,\right| ^- : \mathcal {T}_{CC_{\omega }^+ } \rightarrow \mathcal {T}_{CC_{\omega }}\) and the associated erasure function for contexts.

4.4 The Trocq calculus

The final stage of the announced generalization consists in building an analogue to the parametricity translations available in pure type systems, but for the annotated type theory of § 4.3. This analogue is geared towards proof transfer, as discussed in § 2.1, and therefore designed to synthesize the output of the translation from its input, rather than to check that certain pairs of terms are in relation. However, splitting up the interpretation of universes into a lattice of possible relation structures means that the source term of the translation is not enough to characterize the desired output: the translation needs to be informed with some extra information about the expected outcome of the translation. In the Trocq calculus, this extra information is a type of \(CC_{\omega }^+ \).

We thus define Trocq contexts as lists of quadruples:

$$ \varDelta :\,\!:= \varepsilon \ |\ \varDelta ,\; x\ @\ A\,\sim \,x'\ \because \ x_R \quad \text {where}\; A \in \mathcal {T}_{CC_{\omega }^+ }, $$

and introduce a conversion function \(\gamma \) from Trocq contexts to \(CC_{\omega }^+\) contexts:

$$\begin{aligned} \gamma (\varepsilon ) \quad = \quad & \varepsilon \\ \gamma (\varDelta , \; x\ @\ A\,\sim \,x'\ \because \ x_R) \quad = \quad & \gamma (\varDelta ),\; x : A \end{aligned}$$

Now, a Trocq judgment is a 4-ary relation of the form \(\varDelta \vdash _t M\ @\ A\,\sim \,M'\ \because \ M_R\), which is read in context \(\varDelta \), term M of annotated type A translates to term \(M'\), because \(M_R\) and \(M_R\) is called a parametricity witness. Trocq judgments are defined by the rules of Figure 7. This definition involves a weakening function for parametricity witnesses, defined as follows.

Definition 9

For all \(p, q \in \{0, 1, 2_{\text {a}}, 2_{\text {b}}, 3, 4\}\), such that \(p \ge q\), we define map \(\downarrow ^p_q : \textsf {M}_{p} \rightarrow \textsf {M}_{q}\), which forgets the fields from class \(\textsf {M}_{p}\) that are not in \(\textsf {M}_{q}\).

For all \(\alpha , \beta \in \mathcal {A}\), such that \(\alpha \ge \beta \), function is defined by:

$$ \downdownarrows ^{(m,n)}_{(p,q)}\ \langle R, M^\rightarrow , M^\leftarrow \rangle := \langle R, \downarrow ^m_p M^\rightarrow , \downarrow ^n_q M^\leftarrow \rangle . $$

The weakening function on parametricity witnesses is defined on Figure 8 by extending function \(\downdownarrows ^\alpha _\beta \) to all relevant pairs of types of \(CC_{\omega }^+\) , i.e., \(\Downarrow ^T_U\) is defined for \(T, U \in \mathcal {T}_{CC_{\omega }^+ }\) as soon as \(T \preccurlyeq U\).

Fig. 8.
figure 7

Trocq rules

Fig. 9.
figure 8

Weakening of parametricity witnesses

An abstraction theorem relates Trocq judgments and typing in \(CC_{\omega }^+\) .

Theorem 6

(Trocq abstraction theorem).

figure bc


By induction on derivation \(\varDelta \vdash _t M\ @\ A\,\sim \,M'\ \because \ M_R\).

Note that type A in the typing hypothesis \(\gamma (\varDelta ) \vdash _{+} M : A\) of the abstraction theorem is exactly the extra information passed to the translation. The latter can thus also be seen as an inference algorithm, which infers annotations for the output of the translation from that of the input.

Remark 4

Since by definition of \(p_\Box ^{\alpha ,\beta }\) (Equation 12), we have \(\vdash _t \Box ^\alpha \ @\ \Box ^\beta \,\sim \,\Box ^\alpha \ \because \ p_\Box ^{\alpha ,\beta }\), by applying Theorem 6 with \(\gamma (\varDelta ) \vdash _{+} A : \Box ^\alpha \), we get:

figure bd

Now by the same definition, for any \(\beta \in \mathcal {A}\), , hence , as expected by the type annotation \(A : \Box ^\alpha \) in the premise of the rule.

Remark 5

By applying the Remark 4 with \(\vdash _{+} \Box ^\alpha : \Box ^\beta \), we indeed obtain that  as expected, provided that \((\alpha , \beta ) \in \mathcal {D}_\Box \).

4.5 Constants

Concrete applications require extending Trocq with constants. Constants are similar to variables, except that they are stored in a global context instead of a typing context. A crucial difference though is that a constant may be assigned several different annotated types in \(CC_{\omega }^+\) .

Consider for example, a constant \(\texttt {list}\), standing for the type of polymorphic lists. As \(\texttt {list}\ A\) is the type of lists with elements of type A, it can be annotated with type \(\Box ^\alpha \rightarrow \Box ^\alpha \) for any \(\alpha \in \mathcal {A}\).

Every constant declared in the global environment has an associated collection of possible annotated types \( T_{c} \subset \mathcal {T}_{CC_{\omega }^+ }\). We require that all the annotated types of a same constant share the same erasure in \(CC_{\omega }\), i.e., \(\forall c, \forall A, \forall B,\ A, B \in T_{c} \Rightarrow \left| \,A\,\right| ^- = \left| \,B\,\right| ^-\). For example, \(T_{\texttt {list}} = \left\{ \Box ^\alpha \rightarrow \Box ^\alpha \ \left| \ \alpha \in \mathcal {A}\right. \right\} .\)

In addition, we provide translations \(\mathcal {D}_c(A)\) for each possible annotated type A of each constant c in the global context. For example, \(\mathcal {D}_{\texttt {list}}(\Box ^{(1,0)} \rightarrow \Box ^{(1,0)})\) is equal to \(\left( \texttt {list},\ \lambda A\,A'\,A_R.\,\left( \texttt {List.All2}\ A_R,\; \texttt {}\ \left( \texttt {map}\ A_R\right) \right) \right) \), where relation List.All2 \(A_R\) relates lists of the same length, whose elements are pair-wise related via \(A_R\), \(\texttt {}\) is the usual map function on lists and \(\texttt {map}\ A_R : A \rightarrow A'\) extracts the map projection of the record \(A_R\) of type . Part of these translations can be generated automatically by weakening.

We describe in Figure 9 the additional rules for constants in \(CC_{\omega }^+\) and Trocq. Note that for an input term featuring constants, an unfortunate choice of annotation may lead to a stuck translation.

Fig. 10.
figure 9

Additional constant rules for \(CC_{\omega }^+\) and Trocq

We describe in Figure 9 the additional rules for constants in \(CC_{\omega }^+\) and Trocq. Note that for an input term featuring constants, an unfortunate choice of annotation may lead to a stuck translation.

5 Implementation and applications

The Trocq plugin [13] turns the material presented in Section 4 into an actual tactic, called , for automating proof transfer in Coq. This tactic synthesizes a new goal from the current one, as well as a proof that the former implies the latter. User-defined relations between constants, registered via specific vernacular commands, inform this synthesis. The core of the plugin implements each rule of the Trocq calculus in the Elpi meta-programming language [17, 31], on top of Coq libraries formalizing the contents of Section 3. In the logic programming paradigm of Elpi, each rule of Figure 7 translates gracefully into a corresponding \(\lambda \) Prolog predicate, making the corresponding source code very close to the presentation of §4.4. However, the Trocq plugin also implements a much less straightforward annotation inference algorithm, so as to hide the management of sort annotations to Coq users completely. This section illustrates the usage of the tactic on various concrete examples.

5.1 Isomorphisms

Bitvectors (code). Here are two possible encodings of bitvectors in Coq:

figure bk

We can prove that these representations are equivalent by combining two proofs by transitivity: the proof that is related to for a given , and the proof that is related to itself. We also make use of the equivalence relations and , which respectively relate type and with themselves:

figure bt

Now, suppose we would like to transfer the following result from the bounded natural numbers to the vector-based encoding:

figure bu

As this goal involves and operations on bitvectors, and the order and equality relations on type , we inform Trocq with the associated operations and on the vector encoding. E.g., for and , we prove:

figure cc

We can now use proof transfer from bitvectors to bounded natural numbers:

figure cd

Induction principle on integers. (code). Recall that the problem from Example 1 is to obtain the following elimination scheme, from that available on type \(\mathbb {N}\):

figure ce

We first inform Trocq that and are isomorphic, by providing proofs that the two conversions \(\uparrow _{\mathbb {N}}\ :\ \texttt {N}\ \rightarrow \ \mathbb {N}\) and \(\downarrow _{\mathbb {N}}\ :\ \mathbb {N}\ \rightarrow \ \texttt {N}\) are mutual inverses. Using lemma , we can deduce an equivalence , i.e., . We also prove and register that zeros and successors are related:

figure ck

Trocq is now able to generate, prove and apply the desired implication:

figure cl

Inspecting this proof confirms that only information up to level \((2_\text {a}, 3)\) has been extracted from the equivalence proof . It is thus possible to run the exact proof transfer, but with a weaker relation, as illustrated in the code for an abstract type I with a zero and a successor constants, and a retraction \(\mathbb {N} \rightarrow I\).

5.2 Sections, retractions

Modular arithmetic (code).

A typical application of modular arithmetic is to show that some statement on \(\mathbb {Z}\) can be reduced to statements on \(\mathbb {Z}/p\mathbb {Z}\) Let us show how Trocq can synthesize and prove the following implication:

figure cn

where scope is for the usual product and zero on type , for \(\mathbb {Z}/p\mathbb {Z}\), scope for those on type , for \(\mathbb {Z}\), and is an equality test modulo p on type . Observe that the implication deduces a lemma on \(\mathbb {Z}\) from its modular analogues. Type and are obviously not equivalent, but a retraction is actually enough for this proof transfer. We have:

figure cw

where , (a proof that ), is obtained from via lemma . Proving lemma by now just requires relating the respective zeroes, multiplications, and equalities of the two types:

figure dd

where ( is the Coq name for ) is . Note that by definition of the relation given by , lemma amounts to:

figure dk

Summable sequences. (code). Example 2 involves two instances of subtypes: type \({\overline{\mathbb {R}}_{\ge 0}}\) extends a type \({{\mathbb {R}}_{\ge 0}}\) of positive real numbers with an abstract element and type is for provably convergent sequences of positive real numbers:

figure dm

Type \({\overline{\mathbb {R}}_{\ge 0}}\) and \({{\mathbb {R}}_{\ge 0}}\) are related at level \((4,2_\text {b})\): e.g., provides a partial inverse to the injection by sending the extra to zero. Types and are also related at level \((4,2_\text {b})\), via the relation:

figure ds

where transforms a summable sequence into a sequence of extended positive reals in the obvious way. Now is the sum of a sequence of extended positive reals, and we also define the sum of a sequence of positive reals, as a positive real, again by defaulting infinite sums to zero. For the purpose of the example, we only do so for summable sequences:

figure dw

These two notions of sums are related via , and so are the respective additions of positive (resp. extended positive) reals and the respective pointwise additions of sequences. Once Trocq is informed of these relations, the tactic is able to transfer the statement from the much easier variant on extended reals:

figure dy

5.3 Polymorphic, dependent types

Polymorphic parameters (code). Suppose we want to transfer a goal involving lists along an equivalence between the types of the values contained in the lists. We first prove that the type former is equivalent to itself, and register this fact:

figure ea

We also need to relate with themselves all operations on type involved in the goal, including constructors, and to register these facts, before Trocq is able to transfer any goal, e.g., about to its analogue on .

Note that lemma requires an equivalence between its parameters. If this does not hold, as in the case of type and from Section 5.1, the translation is stuck: weakening does not apply here. In order to avoid stuck translation, we need several versions of to cover all cases. For instance, the following lemma is required for proof transfers from to .

figure ek

Dependent and polymorphic types (code). Fixed-size vectors can be represented by iterated tuples, an alternative to the inductive type , from Coq’s standard library, as follows.

figure em

On the following mockup example, Trocq transfers a lemma on to its analogue on , about a function , and a function creating a constant vector, and simultaneously refines integers into the integers modulo p from Section 5.1:

figure er

This automated proof only requires proving (and registering) that and are related to their analogue and , from Coq’s standard library. Note that the proof uses the equivalence between and but only requires a retraction between parameter types.

6 Conclusion

The Trocq framework can be seen as a generalization of the univalent parametricity translation [30]. It allows for weaker relations than equivalence, thanks to a fine-grained control of the data propagated by the translation. This analysis is enabled by skolemizing the usual symmetrical presentation of equivalence, so as to expose the data, and by introducing a hierarchy of algebraic structures for relations. This scrutiny allows in particular to get rid of the univalence axiom for a larger class of equivalence proofs [29], and to deal with refinement relations for arbitrary terms, unlike the CoqEAL library [14]. Altenkirch and Kaposi already proposed a symmetrical, skolemized phrasing of type equivalence [3], but for different purposes. In particular, they did not study the resulting hierarchy of structures. Definition 4 however slightly differs from theirs: by reducing the amount of transport involved, it eases formal proofs significantly in practice, both in the internal library of Trocq and for end-users of the tactic.

The concrete output of this work is a plugin [13] that consists of about 3000 l. of original Coq proofs and 1200 l. of meta-programming, in the Elpi meta-language, excluding white lines and comments. This plugin goes beyond the state of the art in two ways. First, it demonstrates that a single implementation of this parametricity framework covers the core features of several existing other tactics, for refinements [14, 16], generalized rewriting [28], and proof transfer [30]. Second, it addresses use cases, such as Example 2, that are beyond the skills of any existing tool in any proof assistant based on type theory. The prototype plugin arguably needs an improved user interface so as to reach the maturity of some of the aforementioned existing tactics. It would also benefit from an automated generation of equivalence proofs, such as Pumpkin Pi [27].