Coinductive Natural Semantics for Compiler Verification in Coq ^†

Abstract

(Coinductive) natural semantics is presented as a unifying framework for the verification of total correctness of compilers in Coq (with the feature that a verified compiler can be obtained). In this way, we have a simple, easy, and intuitive framework; to carry out the verification of a compiler, using a proof assistant in which both cases are considered: terminating and non-terminating computations (total correctness).

1. Introduction

This paper tackles the problem of compiler verification in proof assistants. At present, a number of long-term projects deals with several aspects of this issue, for instance, CompCert C [1,2,3,4,5], CertiCoq [6], and IRIS [7]. In this work, we address specifically the verification of total correctness of compilers of functional languages in Coq. Here, we refer to total correctness in the sense of Leroy [8] and Gregoire and Leroy [9], that is total correctness means: correctness of terminating and non-terminating computations.

In the literature, ad-hoc verifications are traditionally used; meaning, verifications that employ more than one distinct formalism.

This situation calls for a solution that abstracts away everything needed in a single unifying framework that simplifies (and perhaps, it could even make possible to automate) this task. By  unifying framework we mean a single formalism able to define each of the components of a compiler, namely: source language semantics, intermediate language semantics, abstract machine semantics, and  translations. In fact, in this work we offer (coinductive) natural semantics as a simple, easy and intuitive unifying framework to carry out (total correctness) compiler verification in Coq. Whenever we use ‘framework’, and we are referring to the (coinductive) natural semantics unifying framework as presented in this work (and only to it), we mean ‘unifying framework’. In this manner, we remark that only one formalism, (coinductive) natural semantics, is sufficient to conduct this task as opposed to usual verifications in the literature where more than one distinct formalism are needed in order to accomplish the same goal (see Section 1.1 for a discussion of the related work). In our preliminary work [10] we only address correctness for termination. In this extended and improved version, as the main novelty, we also tackle correctness for non-termination (which is the most challenging one).

Natural semantics, as introduced by Kahn [11], was initially a unifying framework. Indeed, since its inception [11], natural semantics has been able to express: source language semantics, intermediate languages semantics, abstract machine semantics and translations. Despeyroux [12] also showed how natural semantics allows proof of the correctness of the translations. Based on the work of Kahn and Despeyroux, Boutin [13] formalized a compiler from Mini-ML to the CAM in Coq (although it is not possible to obtain a verified compiler from his formalization).

It is folklore that natural semantics, as originally introduced by Kahn [11], is unqualified to express non-terminating computations (the articles of Kahn, Despeyroux, and Boutin, only address the case of terminating computations.) More precisely, Despeyroux made a preliminary attempt to cover infinite computations but it is based on denotational semantics instead of natural semantics per se. However, since the introduction of coinductive natural semantics by Leroy [14] and Leroy and Grall [15] it is a well-known practice to use a coinductively defined natural semantics to deal with non-terminating program behavior. Leroy [14] and Leroy and Grall [15] advance coinductive natural semantics as a formalism to express non-terminating computations; however, they do not use coinductive natural semantics as a unifying framework in the original sense of Kahn, but they use it only to specify the source language (a high-level language). Specifically, they make an ad-hoc formalization in which, in addition, they use small-step semantics in (what was later called) the Modern SECD (MSECD) machine [8] and a function to define the compilation.

The main idea of this work is to extend natural semantics so that it becomes a simple, easy, and intuitive unifying framework for verifying total correctness of compilers in Coq (with the ability that you can get a verified compiler that can be used in real life).

The strategy for carrying out this extension is as follows: until now, taking as reference the work of Boutin, natural semantics can be used for formalizing the correctness of a compiler in Coq (only for the termination case and a verified compiler cannot be obtained). The first thing we will do is to show how, from a natural semantics specification, one can obtain, either an interpreter (Section 2.1) or a compiler (Section 2.3.1) sound and complete regarding the natural semantics specification. Then, for natural semantics to be able to express non-terminating computations, we will use Leroy’s coinductive natural semantics. However, this semantics has only been used in the source language, in addition, we will show how to use coinductive natural semantics to specify non-terminating computations in an abstract machine (Section 3.3). We will also show that an interpreter, which was previously obtained from natural semantics, is sound and complete regarding its corresponding coinductive natural semantics specification (Section 3.1), that is, for the non-termination criteria (and not only for the termination case). In this way, we are ready to formulate and prove the correctness (semantic preservation) of a compiler, both for the termination case (Section 2.3.2), and, for the non-termination case (Section 3.3.2), completely in terms of (coinductive) natural semantics.

To illustrate the use of (coinductive) natural semantics as a framework, we mechanized a compiler from Mini-ML to a big-step version of the Modern SECD machine. We were interested in showing that in particular, (coinductive) natural semantics can express translations among high-level languages, as well as translations from a high-level language to machine code (a low-level language). Therefore, our compiler is composed of two phases (see Figure 1): translation of Mini-ML with named variables ($\mathtt{MiniML}$) to Mini-ML in de Bruijn notation (${\mathtt{MiniML}}^{\mathtt{dB}}$), as an instance of the first one, and generation of code of the (big-step version of the) Modern SECD machine from Mini-ML in de Bruijn notation (Section 2.3 and Section 3.3), as an instance of the second one. In this work, we will concentrate on the code generation phase which is the most interesting one.

Traditionally, in the literature small-step semantics is used in the machine. That is why, as an alternative target machine, we offer the original small-step semantics Modern SECD machine (Section 2.2 and Section 3.2) extended to support all Mini-ML features, in particular, with native recursion support, mainly to compare it with our solution, in which a big-step machine is used, i.e., our Modern SECD machine big-step version.

1.1. Related Work

Since CompCert C [1,2,3,4,5] project’s inception led by Leroy, there has been great progress in the literature dedicated to compiler verification using proof assistants, Coq in particular. In this work, we address specifically functional programming languages verification. In principle, verification of functional programming languages to abstract machines.

An unusual technique exposed by Hardin et al. [16] to carry out the verification of a functional language to an abstract machine is to use small-step semantics, both in the source language and in the abstract machine, together with a decompilation function and a measure to establish correctness. The idea of this technique is to perform a bottom-up simulation in which every machine transition corresponds to zero or one source level reductions. The machine states are mapped back to source level expressions using a decompilation function. More precisely, if from a machine state s a state $s^{\prime }$ is reached via a machine transition $s\to s^{\prime }$, and e is the source language expression corresponding to the state s via decompilation, then there exists an expression $e^{\prime }$ corresponding to $s^{\prime }$ via decompilation, such that $e=e^{\prime }$ or e reduces to $e^{\prime }$ via source language small-step semantics $e\to e^{\prime }$. When a machine performs a transition from a state to another and the decompilation of both states corresponds to the same expression in the source language, the machine performs a silent transition. To guarantee that there are not infinitely many silent machine transitions, a measure defined on the machine states is used. i.e., if $s\to s^{\prime }$ and the decompilation of s and $s^{\prime }$ corresponds to the same expression e, then s measure is greater than that of $s^{\prime }$.

Gregoire and Leroy [9] and Gregoire [17] use this technique to verify a compiler from a strong reduction lambda calculus to an abstract machine in Coq; more precisely, to verify the correctness of a compiler from the Calculus of Inductive Constructions (CIC) to a variant of the ZAM machine [18] (adapted to support weak symbolic reduction), obtaining a compiler-based verified implementation to evaluate Coq terms. In addition, they show that this compiler-based implementation is more efficient than the original Coq interpreter as expected. More recently, Kunze et al. [19] employ a very similar technique to verify the correctness of a compiler from a call-by-value lambda calculus to an abstract machine in Coq.

However, Leroy [8,14] and Leroy and Grall [15] point out that a correctness proof using this technique is difficult, and also that the definition of a decompilation is complicated, hard to reason about, and hard to extend (especially for optimizing compilation phases). In consequence, they propose a solution based on big-step semantics. In fact, they state that proving semantic preservation for compilers both for terminating and diverging programs using big-step semantics is the original motivation of their work.

The Leroy [14] and Leroy and Grall [15] technique consists of using (coinductive) big-step semantics in the source language but small-step semantics in the machine. In this way, for the termination case, if a source language expression e evaluates to v via big-step semantics $e\Rightarrow v$, then reducing the machine code c via transitive closure of small-step semantics $\stackrel{+}{\to }$, takes the machine to a state with $v_m$ at the top of the stack, where c corresponds to e compilation and $v_m$ is the machine value corresponding to v. For the non-termination case, if e diverges using coinductive big-step semantics, then c also diverges in the machine. Leroy and Grall mention that their technique provides a simpler way to prove semantics preservation, in particular for the non-termination case.

Currently, it is well known [14,15,20,21] that big-step semantics are easier and more convenient for compiler correctness proofs, and also for efficient interpreters [21]. Thus, we have on one hand that Leroy and Grall main motivation is to use big-step semantics for compiler correctness proofs, and on the other that big-step semantics has proved to be easier and more convenient for compiler correctness proofs. Our aim is to take big-step semantics to its deepest consequences exploiting it where it has proved to be useful. This is why we propose (coinductive) natural semantics as framework for compiler verification.

(Coinductive) natural semantics as framework for compiler verification in Coq as proposed in this paper is a technique very similar in spirit to that of Leroy and Grall, but going further since not only (coinductive) big-step semantics is used in the source language but also in the target machine (let us recall that Leroy and Grall employ small-step semantics in the machine). Furthermore, to the best of the author’s knowledge, it is the first time that coinductive natural semantics is proposed and used to define computations that do not terminate in an abstract machine. In this way, we obtain a fully-based (coinductive) natural semantics technique for a functional language to an abstract machine compiler correctness verification in Coq.

Establishing correctness is even easier, intuitive and simple since natural semantics are also used in the machine. If a source language expression e is evaluated to a value v via source language natural semantics $e\Rightarrow v$, then c is evaluated to a final machine state with $v_m$ at the top of the stack via machine natural semantics $s⊢c\Rightarrow v_m·s$; where c is the compilation of e via natural semantics $e\Downarrow c$, and $v_m$ is the compilation of v via natural semantics $v\Downarrow v_m$, and s is any machine stack. If e diverges via coinductive natural semantics $e\stackrel{\infty }{\Rightarrow }$, then c also diverges via machine coinductive natural semantics $s⊢c\stackrel{\infty }{\Rightarrow }$. We can note here, how only (coinductive) natural semantics is sufficient to establish correctness; we do not need to use any other distinct formalism.

A potential use of this framework is to take it as basis to verify a conventional compiler to abstract machine implementation of (the core of) a realistic functional language such as OCaml. The official INRIA OCaml implementation comes with two compilers [22], the first one generates code of the ZAM machine, and the second one generates C-- code. We speculate that this framework can also be used as basis to verify the compiler that generates C-- since Dargaye [23] already uses big-step semantics (although not as unifying framework and only tackling terminating computations) to verify a compiler from Mini-ML to Cminor (an early intermediate language of the CompCert C compiler). The idea of generating Cminor (or some other Compcert C intermediate language) code instead of C-- is immediate since, in this way, we can connect the compiler’s back-end to CompCert C and obtain as final result verified assembly code. This use takes more relevance if we take into account that Coq itself is an OCaml program (even though some portions of Coq are verified in Coq [24,25,26], the extracted verified OCaml code will eventually run on an OCaml implementation).

Another line of work is dedicated to systematically derive an abstract machine from a lambda calculus [27,28,29,30,31,32,33]. The general idea in these works is from a lambda calculus to carry out a series of transformations until the desired abstract machine is obtained. One of the most exploited transformations in some of these works is refocusing [34], although a great variety of transformations are used. The compilation correctness is a direct consequence of the correctness of the transformations. Some of them, in addition, address Coq formalization [29,30,31,32,33]. The closest works to ours are those which starting from a natural semantics of a lambda calculus derive an abstract machine [27,30]. Specifically, the most similar work in nature to ours is [30]. In [30], the STG machine is derived from natural semantics of a lazy lambda calculus and the derivation is formalized in Coq. However, in  [30] only the case for terminating computations is tackled.

In all these works, the emphasis is on the corresponding machine derivation. In contrast, in a functional language implementation the target abstract machine is usually designed by hand and only then (if any) proved correct w.r.t source lambda calculus semantics (see, for example, [18]). Hence, (coinductive) natural semantics as framework as presented in this paper is best suited to verify functional languages implementations (which targets abstract machines), since it assumes that the target machine (and intermediate languages) are given (not to be derived).

Moreover, if for some reason (for example, semantic justification of the target abstract machine) it is considered relevant to systematically derive the target abstract machine from the source calculus, we conjecture that the corresponding derivation can also be carried out in our (coinductive) natural semantics framework. This is because each transformation which leads to the derived machine could be seen as an (intermediate) translation and be defined in natural semantics. Also, the input and output language of each transformation could be seen as an (intermediate) language and its corresponding semantics be defined in natural semantics. Certainly, the derived abstract machine would be a big-step machine.

Other works tackle the verification of a small functional language in Coq, but to the authors’ knowledge none of them use (coinductive) natural semantics as unifying framework; instead, they use ad-hoc verifications. For instance, Chlipala [35] offers a compiler from a small impure functional language to an idealized assembly language. He starts from de Bruijn notation and employs natural semantics for the source and target languages, but not to specify the compilation, his effort only cover terminating computations. Benton and Hur [36] deal with the compilation of a small typed functional language to the SECD machine, but they use denotational semantics for the source language and small-step semantics for the target machine. In addition, Benton and Hur employ a biorthogonality step-indexed logical relation to establish correctness. As mentioned before, Dargaye [23] develops a compiler from Mini-ML to C minor, but it is not designed to be a standalone general-purpose Mini-ML implementation. Instead, it was conceived to work only on the code generated by the Coq extraction mechanism. The Coq extraction mechanism generates code of a real-life functional language, by default OCaml, but it is also able to generate Scheme and Haskell code. This is why in Dargaye’s work, it only makes sense to cover terminating computations since the Coq’s calculus, the Calculus of Inductive Constructions, is strongly normalizing [37], meaning in Coq all computations must terminate. For this reason, all extracted code from Coq should be terminating, while in Coq this property is ensured by Coq’s type checker [26]; the code generation translation performed by the Coq extraction mechanism is not verified, although some efforts are conducted in this direction [6,24,25,38,39,40].

The CertiCoq project [6,40,41] aims to provide a verified extraction pipeline from the core language of Coq, Gallina, to machine language. Therefore, in CertiCoq it also only makes sense to cover terminating computations. This fact is explicitly stated in [6]: ‘… we can restrict our reasoning to terminating programs since Coq is strongly normalizing. This way we avoid backward simulations (forward simulations proofs are much simpler) and avoid proving preservation of divergence’. Similarly, Savary Bélanger [40] indicates: ‘In CertiCoq, we are only concerned with terminating programs: Gallina is strongly normalizing, and our proof of correctness ensures that programs do not acquire non-terminating behaviors along the way’.

Instead of producing machine code directly, CertiCoq generates C light (a CompCert C intermediate language) code. Hence, it uses CompCert C as verified compiler back-end to produce machine language. This way, CertiCoq compiler performs a series of phases from Galllina to Cligth. In CertiCoq, (intermediate) languages semantics and proofs of correctness are based on big-step semantics (for terminating computations). However, big-step semantics is refined with other notions such as step-indexed logical relations and context-based semantics [40,42] to account for additional properties, for instance, compositionality. In addition, the idea of adapting this technique to be useful for general-purpose programming languages is barely mentioned in [40]. Albeit, for this purpose, Savary Bélanger [40] suggests to employ small-step semantics. For their part, Paraskevopoulou and Appel [42], in order to prove closure conversion correctness, they already extend this technique to cover non-termination computations under certain conditions. Closure conversion is a phase performed by CertiCoq.

Our (coinductive) natural semantics framework is best suited to verify usual functional language to abstract machine implementations since it accounts for both terminating and non-terminating computations (total correctness). In addition, it can express terminating and non-terminating computations in an abstract machine. In contrast, by design [6] CertiCoq only covers terminating evaluations on one hand, and on the other it targets C light which is why no abstract machine is used. This situation reflects the fact that our (coinductive) natural semantics framework and CertiCoq pursuit different goals. Although our (coinductive) natural semantics framework is a framework to conduct total correctness compiler verification in Coq, CertiCoq is a verified compiler (from Coq’s core calculus to Clight). Hence, it is not an explicit CertiCoq main objective to offer an infrastructure to perform compiler verification [6], even although, the infrastructure and techniques developed to verify the CertiCoq compiler could be adapted to be used to verify other compilers as well.

Step-indexed logical relations as shown by Ahmed [43] serve to establish contextual equivalence between programs. We remark that step-indexed logical relations provide a way to deal with two compiler problems in particular; specifically, compositionality and secure compilation.

In [44], Ahmed and Blume show how to use step-indexed logical relations together with small-step semantics to deal with a notion of secure compilation. Ahmed and Blume demonstrate their method, applying it to a typed closure conversion transformation. Patrignani et al. [45] offer a recent survey of the formal approaches and techniques used in secure compilation. Certainly, this survey includes in particular works that employ step-indexed logical relations. Abate et al. [46] study generalizations of trace-based compiler correctness criteria including some which accounts for secure compilation.

In order to account for compositionality, Perconti and Ahmed [47] propose the use of a language in which all languages involved in a compilation pipeline can be embedded. Then, using a step-indexed logical relation and small-step semantics compositional compiler correctness is established in terms of the combined language. For their part, Neis et al. [48] introduce parametric inter-language simulations (PILS) as a technique particularly suited to compositional compiler verification for higher-order imperative languages. In particular, they demonstrate their technique with Pilsner, a verified compositional compiler from a ML-like language to an assembly-like language. Patterson and Ahmed [49] provide a framework for expressing different notions of compiler correctness, especially those which consider compiler compositionality.

Dreyer et al. [50], in order to avoid tedious, error-prone and obscuring step-indexed arithmetic, instead of using explicit indices, they propose to ‘hide’ indices, internalizing them into a logic. The idea is to replace indices with a modal operator, this way obtaining a modal logic which they name LSLR. In particular, this idea is reused in IRIS. IRIS [7,51,52,53] is a concurrent separation logic framework implemented and verified in Coq. In this regard, Krebbers et al. [53] comment: ‘We also show that the step-indexed “later” modality of Iris is an essential source of complexity, in that removing it leads to a logical inconsistency’. Recently, Linn Georges et al. [54] formalize a capability machine in IRIS. As Linn Georges et al. [54] point out, capability machines are promising targets for secure compilers. Hence, the idea to extend IRIS to be used as secure compiler framework is imminent; in particular, to verify secure compilers from high-level concurrent languages to capability machines. However, to the authors’ knowledge, IRIS has never been used in this manner. A very similar goal is pursued by Cuellar et al. [55] and Cuellar [56] but extending CompCert C. To this end, they introduce the Concurrent Permission Machine (CPM). Certainly, C (with concurrency) is the source language in these works.

In retrospective, on one hand step-indexed logical relations have proved to be useful, in particular in secure compilation, compiler compositionality and concurrency; on the other hand, natural semantics has proved to be easier and more convenient than other formalisms (for instance, small-step semantics) for compiler correctness proofs. Hence, we speculate that both natural semantics and step-indexed logical relations can be combined in a single formalism that has the best properties of each one of them. In other words, we envisage the ambitious goal of reaching a single formalism that features secure compilation, compositional compilation, concurrency and be simple, easy and intuitive as possible.

Currently, our (coinductive) natural semantics framework does not account for secure compilation, compositionality nor concurrency. However, we conjecture that step-indexed logical relations can be adopted in it to address some or even all these features. The price paid for this effort would be to deal with the known complexity of step-indexed logical relations (although it could be ameliorated, for instance, by internalizing the indices in a natural semantics modal logic). At present, our (coinductive) natural semantics framework is simple, easy and intuitive.

The following are related semantics: coinductive big-step operational semantics [14,15], trace-based coinductive operational semantics [57], pretty-big-step semantics [20] and flag-based big-step semantics [21].

The only one of these works that presents the verification of the correctness of a compiler is Leroy’s (an ad-hoc verification). This means that (coinductive) natural semantics is not used in any of them as a unifying framework for the verification of compiler correctness. Specifically, it is not used in the definition of the semantics of the machine (nor in that of its interpreter), it is not used to define the translations, and it is not used (both in the source language and in the target language) to establish, nor to prove the correctness of the translations. What it does, in each of them, is to present a natural semantics with coinduction of a high-level language (which would usually correspond to the source language in a compiler) and it is this aspect that we review next.

Leroy [14] first expresses finite computations with natural semantics ‘evaluation’ and infinite computations ‘divergence’ with coinductive natural semantics, separately; this solution is clear and clean. After, he offers an alternative solution in which one finite and infinite computations are expressed in a single coinductive natural semantics ‘coevaluation’; however, this semantics does not behave well in the sense that on one hand, there are infinite computations that it is not able to express, and on the other, there are infinite computations that are evaluated to any value v. Nakata and Uustalu [57] remark that this behavior appears accidental and undesired.

Nakata and Uustalu [57] define a coinductive natural semantics of the While language that expresses finite and infinite computations; the careful and ad-hoc design of semantics follows, and within it that of small-step semantics. Additionally, Nakata and Uustalu define an interpreter using the trace monad and they show that it is correct regarding such semantics. Nakata and Uustalu’s work [57] is the only one of the related works presented here in which an interpreter is presented.

Charguéraud [20] introduces pretty-big-step semantics, a semantics based on ‘coevaluation’ of Leroy. Unfortunately, pretty-big-step semantics inherits the not well behavior of ‘coevaluation’. In turn, Bach Poulsen and Mosses [21] define flag-based big-step semantics based on pretty-big-step semantics. Unfortunately, flag-based big-step semantics, through pretty-big-step semantics, also inherits the not well behavior of ‘coevaluation’.

In this work, we present (coinductive) natural semantics as a framework for the verification of total correctness of compilers in Coq. Once we have a simple, easy, clear, and intuitive solution for this task, we can seek to improve it in the future. In particular, we use a natural parameter in the interpreters to bound the recursion. Recently, Leroy [58] has defined an interpreter of While using the partiality monad in Coq; we plan to adopt the partiality monad in our Mini-ML compiler and in the framework in general to avoid the use of this parameter.

On the other hand, we can seek to reach a single coinductive natural semantics ‘$\stackrel{co}{\Rightarrow }$’ able to express terminating computations, as well as non-terminating computations. Charguéraud [20] mentions that in principle, this semantics can be used directly to prove total correctness of the translations; however, he points out that the conclusion in the correctness theoremis usually of the form $\exists v^{\prime }.(v\approx v^{\prime })\wedge (c\stackrel{co}{\Rightarrow }{v}^{\prime })$, and that the current support of coinduction in Coq only allows using coinductive predicates in the conclusion. In particular, it does not allow using the existential quantifier ‘∃’ or the connective ‘∧’ when a proof is done by coinduction. Bach Poulsen and Mosses [21] run a similar criticism to the current coinduction support in Coq. Fortunately, our (coinductive) natural semantics is ideal here since, when using (inductive) natural semantics ‘⇒’ to express finite computations and coinductive natural semantics ‘$\stackrel{\infty }{\Rightarrow }$’ to express infinite computations (separately), the proof of the termination case where the conclusion requires an ∃ and an ∧ can be done by induction, whereas, in this way, in the case of non-termination, in the conclusion neither the ∃ nor the ∧ is required, only the coinductive predicate $\stackrel{\infty }{\Rightarrow }$ is used, so it can be proved by coinduction (with the current support of Coq).

Even then, it would be possible to aim at having a single semantics in order to have a more concise definition. If so, the framework could automate the translation from it to the two separated semantics (⇒ and $\stackrel{\infty }{\Rightarrow }$); also, the framework could establish and prove the equivalence between the first one and the union of the last two semantics. Having arrived at these two semantics, the current results of the framework can be used.

The central problem is that (to the authors’ knowledge) to date, there is not a single coinductive natural semantics in the literature that expresses finite and infinite computations, and that it does behave well. The first author, based on Leroy’s ‘coevaluation’, has succeeded in defining a single coinductive natural semantics (of the pure lambda calculus extended with constants) that expresses terminating and non-terminating computations, and that it does behave well in Coq. Also, he has proved the equivalence of this semantics with the union of the two semantics (⇒ and $\stackrel{\infty }{\Rightarrow }$) that express, respectively, finite and infinite computations separately. Apparently, this result is sound [59] and we plan to present it in future works.

To continue, it would be possible to deal with the problem of decreasing the number of rules necessary in a coinductive natural semantics definition. This is the main goal of pretty-big-step semantics and flag-based big-step semantics. To this end and going further, we envisage that the results in this work and those of pretty-big-step semantics and flag-based big-step semantics (future work and perhaps other works as well) can be integrated in a coinductive natural semantics framework having all the desired properties of each of them. In other words, it is our intention that the resulting coinductive natural semantics framework synthesizes all the major advances in natural semantics.

1.2. Contributions

Our main general and specific contributions are:

• The (coinductive) natural semantics as a framework for the verification of total correctness of compilers in Coq. Such that a working standalone verified compiler, meaning, a compiler sound and complete regarding (coinductive) natural semantics specification and correct regarding semantic preservation of the specified translation can be obtained as a final product
• A systematic method to obtain either a sound or complete interpreter (Section 2.1 and  Section 3.1) or compiler (Section 2.3.1), as applicable, from a (coinductive) natural semantics specification
• The use of coinductive natural semantics to specify non-terminating computations in an abstract machine (Section 3.3)
• A compiler from Mini-ML to a big-step version of the Modern SECD machine including its total correctness verification in Coq (Section 2.1, Section 2.3, Section 3.1 and Section 3.3)
• An extended version of the original small-step semantics Modern SECD machine which includes native recursion support (Section 2.2 and Section 3.2)
• A big-step version of the Modern SECD machine including its formalization in Coq (Section 2.3 and Section 3.3)
• A coinductive natural semantics specification of non-terminating computations of Mini-ML (extended version of Leroy’s specification of the pure lambda calculus with constants, Section 3.1)
• A coinductive natural semantics specification of non-terminating computations of the big-step Modern SECD machine (Section 3.3)
• An algorithm to translate from (an abstract representation of) the (coinductive) natural semantics specification of a total correct compiler to its corresponding formalization in Coq (Section 4)

The strategy for the presentation is, first, to tackle the termination case using natural semantics (Section 2), and then the non-termination case using coinductive natural semantics (Section 3). During this work, the method that we use is to present each of the compiler’s components together with their corresponding Coq formalization; in this way, it is intended that when our compiler is finished, we will have the necessary intuition behind the algorithm to go from a total correct compiler in abstract to Coq (Section 4). Finally, (Section 5), we present our conclusions.

2. Natural Semantics

We will first tackle, in this section, the case in which the computations are finite (terminating) using natural semantics.

2.1. ${\mathtt{MiniML}}^{\mathtt{dB}}$

To begin with, we introduce the source language, Mini-ML, in de Bruijn notation, which is essentially the pure lambda calculus extended with naturals, Booleans, arithmetic and comparison operators, local definitions, conditionals and native recursion by means of a fixed point operator. Its abstract syntax is the following:

d	$\hspace{1em}::=\hspace{1em}$	n	Naturals
	∣	b	Booleans
	∣	$d\star d$   with $\star \in$ {+,−,∗,=}	Primitive operators
	∣	$\underline{i}$	Nameless variables (de Bruijn index)
	∣	ifdthendelsed	Conditionals
	∣	letdind	Local definition
	∣	$\lambda .d$	Abstraction
	∣	$\mu .\lambda .d$	Fixed point
	∣	$dd$	Application

Before carrying out the coding of our definitions in Coq, it is important to highlight some of its features. Coq is based on the Calculus of Inductive Constructions, i.e., a lambda calculus with a sophisticated and expressive type system. Since it is a lambda calculus, it can be used as a logic, but also as a programming language, i.e., we can prove propositions, but also write programs. This distinction is made explicit by using the types Prop and Set respectively. Roughly, it can be said that when a term in Coq has type Prop, it is used as logic, and if a term has type Set, then it is used as programming language. In fact, this explicit syntactic distinction between Prop and Set was introduced by the Coq extraction mechanism [60] to distinguish between those terms with computational content and those without it (Paulin-Mohring [60] calls ‘Spec’ what would later be called ‘Set’). In this way, if a term in Coq has a Set type, the extraction mechanism can generate a program written in a general-purpose programming language, such as OCaml, related to this term, in contrast to a term with a Prop type from which is not possible to extract any program at all.

The abstract syntax of ${\mathtt{MiniML}}^{\mathtt{dB}}$ can be coded in Coq as first order abstract syntax using an Inductive definition with type Set as follows:

• Inductive MML_dB_exp: Set :=
• | Const_dB : nat → MML_dB_exp
• | …
• | Letm_dB: MML_dB_exp → MML_dB_exp → MML_dB_exp
• | …
• | Lam_dB: MML_dB_exp → MML_dB_exp
• | Mu_dB: MML_dB_exp → MML_dB_exp
• | App_dB: MML_dB_exp → MML_dB_exp → MML_dB_exp.

For conciseness, throughout this article, we will show only the essentials parts of the formalization. The full formalization can be consulted in [61].

Hence, the Coq extraction mechanism can be used with the following command:

• Extraction MML_dB_exp.

which gives as a result:

• type mML_dB_exp =
• | Const_dB of nat
• | …
• | Letm_dB of mML_dB_exp ∗ mML_dB_exp
• | …
• | Lam_dB of mML_dB_exp
• | Mu_dB of mML_dB_exp
• | App_dB of mML_dB_exp ∗ mML_dB_exp

This way, we can notice how an Inductive definition with type Set in Coq corresponds to an ADT in OCaml, in this case to the abstract syntax of ${\mathtt{MiniML}}^{\mathtt{dB}}$ written in OCaml.

To define the natural semantics of ${\mathtt{MiniML}}^{\mathtt{dB}}$, we first need to define its values by means of environments and closures.

v	$\hspace{1em}::=\hspace{1em}$	n	Numbers	$\Omega$	$\hspace{1em}::=\hspace{1em}$	$[ ]$	Empty environment
	∣	b	Booleans	$$	∣	$v·\Omega$
	∣	$(\lambda .d)[\Omega ]$	Closures
	∣	$(\mu .\lambda .d)[\Omega ]$	Recursive closures

The environments serve as (implicit) associations from variables (represented by de Bruijn indices) to values. In this manner, as expressed by the predicate $\Omega ⊢\underline{i}⟼v$, the value of a variable represented by the index $\underline{i}$ is at the $i^{th}$ position in the environment (a sequence of values).

$\frac{}{v·\Omega ⊢\underline{0}⟼v}$

$\frac{\Omega ⊢\underline{i}⟼v}{w·\Omega ⊢\underline{Si}⟼v}$

The natural semantics of ${\mathtt{MiniML}}^{\mathtt{dB}}$ is inductively defined by the predicate:

$$\Omega ⊢d\Rightarrow v$$

which can be read as follows: in the environment $\Omega$, the expression d is evaluated to the value v.

The $\Omega$ environment is supposed to contain the value of the free variables in d. The natural semantics of ${\mathtt{MiniML}}^{\mathtt{dB}}$ is defined as follows:

$\frac{}{\Omega ⊢n\Rightarrow n}\frac{}{\Omega ⊢b\Rightarrow b}\frac{\Omega ⊢d_1\Rightarrow n_1\hspace{1em}\hspace{1em}\Omega ⊢d_2\Rightarrow n_2}{\Omega ⊢d_1\star d_2\Rightarrow n_1\star n_2}$

$\frac{\Omega ⊢\underline{i}⟼v}{\Omega ⊢\underline{i}\Rightarrow v}\frac{\Omega ⊢d_1\Rightarrow v_1\hspace{1em}\hspace{1em}{v}_1·\Omega ⊢d_2\Rightarrow v}{\Omega ⊢\mathrm{let}{d}_1\mathrm{in}{d}_2\Rightarrow v}$

$\frac{\Omega ⊢d_1\Rightarrow true\hspace{1em}\hspace{1em}\Omega ⊢d_2\Rightarrow v}{\Omega ⊢\mathrm{if}{d}_1\mathrm{then}{d}_2\mathrm{else}{d}_3\Rightarrow v}\frac{\Omega ⊢d_1\Rightarrow false\hspace{1em}\hspace{1em}\Omega ⊢d_3\Rightarrow v}{\Omega ⊢\mathrm{if}{d}_1\mathrm{then}{d}_2\mathrm{else}{d}_3\Rightarrow v}$

$\frac{}{\Omega ⊢\lambda .d\Rightarrow (\lambda .d)[\Omega ]}\frac{}{\Omega ⊢\mu .\lambda .d\Rightarrow (\mu .\lambda .d)[\Omega ]}$

$\frac{\Omega ⊢d_1\Rightarrow (\lambda .d)[{\Omega }_1]\hspace{1em}\hspace{1em}\Omega ⊢d_2\Rightarrow v_2\hspace{1em}\hspace{1em}{v}_2·{\Omega }_1⊢d\Rightarrow v}{\Omega ⊢d_1{d}_2\Rightarrow v}$

$\frac{\Omega ⊢d_1\Rightarrow (\mu .\lambda .d)[{\Omega }_1]\hspace{1em}\hspace{1em}\Omega ⊢d_2\Rightarrow v_2\hspace{1em}\hspace{1em}{v}_2·(\mu .\lambda .d)[{\Omega }_1]·{\Omega }_1⊢d\Rightarrow v}{\Omega ⊢d_1{d}_2\Rightarrow v}$

A natural semantics definition can be seen as an inductive logical proposition; hence, it can be encoded in Coq as an Inductive definition with type Prop. This way the ${\mathtt{MiniML}}^{\mathtt{dB}}$ semantics can be written as follows:

• Inductive MML_dB_NS : MML_dB_env → MML_dB_exp → MML_dB_val → Prop :=
• | MML_dB_NS_Const: ∀ O:MML_dB_env, ∀ n:nat,
•     MML_dB_NS O (Const_dB n) (Num_dB n)
• | …
• | MML_dB_NS_Let: ∀ O:MML_dB_env, ∀ d1 d2:MML_dB_exp, ∀ v1 v2: MML_dB_val,
•     MML_dB_NS O d1 v1 →
•     MML_dB_NS (v1::O) d2 v2 →
•     MML_dB_NS O (Letm_dB d1 d2) v2
• | …
• | MML_dB_NS_Lam: ∀ O:MML_dB_env, ∀ d:MML_dB_exp,
•     MML_dB_NS O (Lam_dB d) (Clos_dB d O)
•  
• | MML_dB_NS_Mu: ∀ O:MML_dB_env, ∀ d:MML_dB_exp,
•     MML_dB_NS O (Mu_dB d) (Closr_dB d O)
•  
• | MML_dB_NS_App: ∀ O O1: MML_dB_env, ∀ d1 d2 d:MML_dB_exp, ∀ v v2:MML_dB_val,
•     MML_dB_NS O d1 (Clos_dB d O1) →
•     MML_dB_NS O d2 v2 →
•     MML_dB_NS (v2::O1) d v →
•     MML_dB_NS O (App_dB d1 d2) v
•  
• | MML_dB_NS_Appr: ∀ O O1:MML_dB_env, ∀ d1 d2 d:MML_dB_exp, ∀ v v2:MML_dB_val,
•     MML_dB_NS O d1 (Closr_dB d O1) →
•     MML_dB_NS O d2 v2 →
•     MML_dB_NS (v2::(Closr_dB d O1)::O1) d v →
•     MML_dB_NS O (App_dB d1 d2) v.

A natural semantics definition, in general, is a relation; therefore, no determinism is the general case. Then, in case a definition of this kind is deterministic, a lemma that expresses this property must be formally established in the same way we do it for the ${\mathtt{MiniML}}^{\mathtt{dB}}$ semantics:

• Lemma MML_dB_NS_deterministic:
• ∀ O, ∀ d, ∀ v1, MML_dB_NS O d v1 →
•             ∀ v2, MML_dB_NS O d v2 →
•                        v1 = v2.

If a relation is deterministic, then it can be stated as a function. Consequently, it can be encoded as function in a programming language. In particular, in Coq, we can write a recursive function employing Fixpoint. For instance, the function corresponding to ${\mathtt{MiniML}}^{\mathtt{dB}}$ natural semantics is written as follows:

• Fixpoint MML_dB_NS_interpreter (depthR:nat )(O:MML_dB_env) (d:MML_dB_exp)
• : option MML_dB_val :=
• match depthR with
• | 0 ⇒ None
• | S m ⇒ match d with
•            | Const_dB n ⇒ Some (Num_dB n)
•            | …
•            | Letm_dB d1 d2 ⇒
•              match (MML_dB_NS_interpreter m O d1) with
•                | Some v1 ⇒ MML_dB_NS_interpreter m (v1::O) d2
•                | _ ⇒ None
•              end
•            | …
•            | Lam_dB d ⇒ Some (Clos_dB d O)
•            | Mu_dB d ⇒ Some (Closr_dB d O)
•            | App_dB d1 d2 ⇒
•              match (MML_dB_NS_interpreter m O d1) with
•                | Some (Clos_dB d O1) ⇒
•                  match MML_dB_NS_interpreter m O d2 with
•                    | Some v2 ⇒ MML_dB_NS_interpreter m (v2::O1) d
•                    | _ ⇒ None
•                  end
•                | Some (Closr_dB d O1) ⇒
•                  match MML_dB_NS_interpreter m O d2 with
•                    | Some v2 ⇒ MML_dB_NS_interpreter m (v2::(Closr_dB d O1)::O1) d
•                    | _ ⇒ None
•                  end
•                | _ ⇒ None
•              end
•          end
• end.

Please note that this function is actually an interpreter. To guarantee termination, we added the natural parameter depthR which indicates the recursion depth (depthR is also called ‘fuel’ by some authors, see, for example [24,25,62,63]). This is because the CIC is strongly normalizing [37], which means, from a programming-language perspective, that all the calculations must terminate. In Coq, this means that all functions must be total and terminating.

From a verification perspective, a logical proposition serves as a formal specification that a program must comply. In this case, the logical proposition is the Inductive definition in Prop whereas the program is the interpreter in Set. Then, to verify that our interpreter is sound with respect to the ${\mathtt{MiniML}}^{\mathtt{dB}}$ natural semantics, we must prove the following lemma:

• Lemma MML_dB_NS_interpreter_soundness:
• ∀ O, ∀ d, ∀ v, MML_dB_NS O d v →
•             ∃ n, MML_dB_NS_interpreter n O d = Some v.

Conversely, i.e., to verify that our interpreter is complete with respect to ${\mathtt{MiniML}}^{\mathtt{dB}}$ natural semantics, we must prove this lemma:

• Lemma MML_dB_NS_interpreter_completeness: ∀ n, ∀ O, ∀ d, ∀ v,
• MML_dB_NS_interpreter n O d = Some v →
• MML_dB_NS O d v.

Now we write factorial of 5 in ${\mathtt{MiniML}}^{\mathtt{dB}}$ as a program example:

• Definition example :=
• (App_dB (Mu_dB (If_dB (Eq_dB (Var_dB 0) (Const_dB 0))
•            (Const_dB 1)
•            (Times_dB (Var_dB 0)
•                (App_dB (Var_dB 1)
•                          (Minus_dB (Var_dB 0) (Const_dB 1)))))) (Const_dB 5)).

then, we can evaluate it in our ${\mathtt{MiniML}}^{\mathtt{dB}}$ interpreter, inside Coq, as follows:

• Compute (MML_dB_NS_interpreter 19 nil example).

obtaining just the expected result:

• = Some (Num_dB 120) : option MML_dB_val

Next, we can use the extraction mechanism as follows:

• Extraction MML_dB_NS_interpreter.

so, in this way, we obtain a verified interpreter, sound and complete with respect to ${\mathtt{MiniML}}^{\mathtt{dB}}$ natural semantics in OCaml, ready to be used in real life.

• let rec mML_dB_NS_interpreter depthR o d =
•   match depthR with
•   | O → None
•   | S m →
•     (match d with
•      | Const_dB n → Some (Num_dB n)
•      | …
•      | Letm_dB (d1, d2) →
•        (match mML_dB_NS_interpreter m o d1 with
•         | Some v1 → mML_dB_NS_interpreter m (Cons (v1, o)) d2
•         | None → None)
•      | …
•      | Lam_dB d0 → Some (Clos_dB (d0, o))
•      | Mu_dB d0 → Some (Closr_dB (d0, o))
•      | App_dB (d1, d2) →
•        (match mML_dB_NS_interpreter m o d1 with
•         | Some m0 →
•           (match m0 with
•            | Clos_dB (d0, o1) →
•              (match mML_dB_NS_interpreter m o d2 with
•               | Some v2 → mML_dB_NS_interpreter m (Cons (v2, o1)) d0
•               | None → None)
•            | Closr_dB (d0, o1) →
•              (match mML_dB_NS_interpreter m o d2 with
•               | Some v2 →
•                 mML_dB_NS_interpreter m (Cons (v2, (Cons ((Closr_dB (d0, o1)),
•                   o1)))) d0
•               | None → None)
•            | _ → None)
•         | None → None))

The reader may question the ‘double’ task of maintaining both definitions, Prop and Set. On one hand, if we stay in the logical part, in Prop, a verified compiler cannot be obtained to be used in real life, while on the other hand, definitions using the Set type forces us to work with total terminating functions.

Let us recall that natural semantics is, in general, inherently relational and, non-deterministic; therefore, to write a natural semantics definition as a function we must ensure that it is total and deterministic. Although for some particular cases this is true, we think that if a natural semantics definition is written directly as a function, the essence of natural semantics vanishes.

Also, Coq automatically generates inductive principles from inductive definitions, which is not the case for functions. These induction principles are useful as they can be used through the induction tactic while doing a proof. In some scenarios, this is an advantage, especially, of course, when a proof is done by induction.

Regarding the remarks above, we give definitions in Prop to retain the essence of natural semantics and to take advantage of the inductive principles generated by Coq. Also, we give the corresponding definitions in Set, mainly to obtain verified implementations.

2.2. Modern SECD Machine

Leroy [8,14] introduces the Modern SECD, a machine based on Landin’s SECD [64] with two main differences: the first one is that it does not use a Dump; instead, it makes use of frames in the stack to support function calls; the second one is that it uses de Bruijn indices to access the environment.

The original Modern SECD only offers natural constants, local definitions, abstraction and application support. Due to this, we offer an extended version of the MSECD to support Booleans, arithmetic and comparison operators, conditionals, and native recursion by means of recursive closures. It is worth mentioning that we made the conditionals support based on Henderson’s SECD presentation [65].

The instructions of the extended MSECD are the following:

i	$\hspace{1em}::=\hspace{1em}$	IConst n	Push the natural n
	∣	IConstb b	Push the Boolean b
	∣	IAdd	Perform an addition
	∣	ISub	Perform a subtraction
	∣	IMul	Perform a multiplication
	∣	IEq	Perform an equality comparison
	∣	IAcc $\underline{i}$	Push the value of the variable number (de Bruijn index) $\underline{i}$
	∣	ISel c c	Select a conditional branch
	∣	IJoin	Rejoin the main control (return from conditional)
	∣	ILet	Add the value of a local defintion variable to the environment
	∣	IEndLet	Remove the value of a local definition variable from the environment
	∣	IClos c	Push a closure with code c
	∣	IClos${}_{rec}$ c	Push a recursive closure with code c
	∣	IApp	Perform a function application
	∣	IRet	Return from function

Notice the distinction between ‘i’ and ‘$\underline{i}$’, the former denotes a machine instruction, whereas the latter denotes a de Bruijn index.

The code is defined as an instruction sequence:

c	$\hspace{1em}::=\hspace{1em}$	$[ ]$	Empty code
	∣	$i·c$

The values of the machine and its environment are defined as follows:

$v_m$	$\hspace{1em}::=\hspace{1em}$	n	Naturals	$\Delta$	$\hspace{1em}::=\hspace{1em}$	$[ ]$	Empty environment
	∣	b	Booleans	$$	∣	$v_m·\Delta$
	∣	$c[\Delta ]$	Closures
	∣	$c{[\Delta ]}_{rec}$	Recursive closures

Besides these values, the frames should be able to be stored in the stack. Therefore, the stack values and the stack of the machine are defined as follows:

$v_s$	$\hspace{1em}::=\hspace{1em}$	$v_m$	Machine values	$s$	$\hspace{1em}::=\hspace{1em}$	$[ ]$	Empty stack
	∣	$(c,\Delta )$	Stack Frames	$$	∣	$v_s·\Delta$

A MSECD machine configuration is a triplet $(c,\Delta ,s)$ where c is a code, $\Delta$ is a machine environment, and s is a stack.

The MSECD small-step semantics is a transition relation from a configuration $(c_i,{\Delta }_i,s_i)$ to the next $(c_{i+1},{\Delta }_{i+1},s_{i+1})$ denoted by: $(c_i,{\Delta }_i,s_i)\to (c_{i+1},{\Delta }_{i+1},s_{i+1})$.

Next, We present the MSECD small-step semantics, shown in

Table 1. MSECD small-step semantics.

Current			Next
Code	Environment	Stack	Code	Environment	Stack
$(\mathtt{IConst}n)·c$	$\Delta$	s	c	$\Delta$	$n·s$
$(\mathtt{IConstb}b)·c$	$\Delta$	s	c	$\Delta$	$b·s$
$\mathtt{IAdd}·c$	$\Delta$	$n_2·n_1·s$	c	$\Delta$	$n_1+n_2·s$
$\mathtt{ISub}·c$	$\Delta$	$n_2·n_1·s$	c	$\Delta$	$n_1-n_2·s$
$\mathtt{IMul}·c$	$\Delta$	$n_2·n_1·s$	c	$\Delta$	$n_1\ast n_2·s$
$\mathtt{IEq}·c$	$\Delta$	$n_2·n_1·s$	c	$\Delta$	$n_1=n_2·s$
$(\mathtt{IAcc}\underline{i})·c$	$[v_0,\dots ,v_i,\dots ,v_n]=\Delta$	s	c	$\Delta$	$v_i·s$
$\mathtt{ILet}·c$	$\Delta$	$v·s$	c	$v·\Delta$	s
$\mathtt{IEndLet}·c$	$v·\Delta$	s	c	$\Delta$	s
$(\mathtt{ISel}{c}_1{c}_2)·c$	$\Delta$	$true·s$	$c_1$	$\Delta$	$(c,[])·s$
$(\mathtt{ISel}{c}_1{c}_2)·c$	$\Delta$	$false·s$	$c_2$	$\Delta$	$(c,[])·s$
$\mathtt{IJoin}·c$	$\Delta$	$v·(c_b,[])·s$	$c_b$	$\Delta$	$v·s$
$(\mathtt{IClos}{c}_1)·c$	$\Delta$	s	c	$\Delta$	$c_1[\Delta ]·s$
$({\mathtt{IClos}}_{rec}{c}_1)·c$	$\Delta$	s	c	$\Delta$	$c_1{[\Delta ]}_{rec}·s$
$\mathtt{IApp}·c$	$\Delta$	$v·c_1[{\Delta }_1]·s$	$c_1$	$v·{\Delta }_1$	$(c,\Delta )·s$
$\mathtt{IApp}·c$	$\Delta$	$v·c_1{[{\Delta }_1]}_{rec}·s$	$c_1$	$v·c_1{[{\Delta }_1]}_{rec}·{\Delta }_1$	$(c,\Delta )·s$
$\mathtt{IRet}·c$	$\Delta$	$v·(c_1,{\Delta }_1)·s$	$c_1$	${\Delta }_1$	$v·s$

:

To codify this semantics in Coq, we write:

• Inductive MSECD_SS: conf → conf → Prop :=
•  MSECD_SS_IConst: ∀ n:nat, ∀ c:code, ∀ D:env, ∀ s:stack,
•     MSECD_SS (IConst n::c, D, s) (c, D, Val (MInt n)::s)
• | …
•  
• | MSECD_SS_ILet: ∀ c:code, ∀ D:env, ∀ v:val, ∀ s:stack,
•     MSECD_SS (ILet::c, D, Val v::s) (c, v::D, s)
•  
• | MSECD_SS_IEndLet: ∀ c:code, ∀ D:env, ∀ v:val, ∀ s:stack,
•     MSECD_SS (IEndLet::c, v::D, s) (c, D, s)
• | …
•  
• | MSECD_SS_IClos: ∀ cc c:code, ∀ D:env, ∀ s:stack,
•     MSECD_SS (IClos cc::c, D, s) (c, D, Val (MClos cc D)::s)
•  
• | MSECD_SS_IClosr: ∀ cc c:code, ∀ D:env, ∀ s:stack,
•     MSECD_SS (IClosr cc::c, D, s) (c, D, Val (MClosr cc D)::s)
•  
• | MSECD_SS_IApp: ∀ c c1:code, ∀ D D1:env, ∀ s:stack, ∀ v:val,
•     MSECD_SS (IApp::c, D, Val v:: Val (MClos c1 D1)::s) (c1, v::D1, SFrame c D::s)
•  
• | MSECD_SS_IAppr:∀ c c1:code, ∀ D D1:env, ∀ s:stack, ∀ v:val,
•     MSECD_SS (IApp::c, D,Val v::Val (MClosr c1 D1)::s) (c1, v::(MClosr c1 D1)::D1,SFrame c D::s)
•  
• | MSECD_SS_IReturn: ∀ c c1:code, ∀ D D1:env, ∀ v:val, ∀ s:stack,
•     MSECD_SS (IRet::c, D, Val v:: SFrame c1 D1 ::s) (c1, D1, Val v::s).

Let $m_1$, $m_2$ and $m_3$ be MSECD machine configurations, the transitive closure of the small-step semantics is defined inductively as follows:

$\frac{m_1\to m_2}{m_1\stackrel{+}{\to }{m}_2}\frac{m_1\to m_2\hspace{1em}\hspace{1em}{m}_2\stackrel{+}{\to }{m}_3}{m_1\stackrel{+}{\to }{m}_3}$

In Coq, this transitive closure is written as follows:

• Inductive TC_MSECD_SS: conf → conf → Prop :=
• | TC_MSECD_SS_SS:
•      ∀ m1 m2, MSECD_SS m1 m2 →
•                  TC_MSECD_SS m1~m2
•  
• | TC_MSECD_SS_Transitivity:
•      ∀ m1 m2, MSECD_SS m1 m2 →
•          ∀ m3, TC_MSECD_SS m2 m3 →
•                  TC_MSECD_SS m1 m3.

2.2.1. Compilation

Leroy [14] defines the compilation from the pure lambda calculus extended with constants to MSECD machine code as a function. Here, we extend his work to all the ${\mathtt{MiniML}}^{\mathtt{dB}}$ language constructs:

$$\begin{array}{ccc}\hfill 〚n〛& =& \mathtt{IConst}n\hfill \\ \hfill 〚b〛& =& \mathtt{IConstb}b\hfill \\ \hfill 〚d_1\star d_2〛& =& 〚d_1〛·〚d_2〛·\mathtt{IOp}\hfill \\ \hfill 〚\underline{i}〛& =& \mathtt{IAcc}\underline{i}\hfill \\ \hfill 〚\mathtt{let}{d}_1\mathtt{in}{d}_2〛& =& 〚d_1〛·\mathtt{ILet}·〚d_2〛·\mathtt{IEndLet}\hfill \\ \hfill 〚\mathtt{if}{d}_1\mathtt{then}{d}_2\mathtt{else}{d}_3〛& =& 〚d_1〛·\mathtt{ISel}(〚d_2〛·\mathtt{IJoin})(〚d_3〛·\mathtt{IJoin})\hfill \\ \hfill 〚\lambda .d〛& =& \mathtt{IClos}(〚d〛·\mathtt{IRet})\hfill \\ \hfill 〚\mu .\lambda .d〛& =& {\mathtt{IClos}}_{rec}(〚d〛·\mathtt{IRet})\hfill \\ \hfill 〚d_1{d}_2〛& =& 〚d_1〛·〚d_2〛·\mathtt{IApp}\hfill \end{array}$$

2.2.2. Correctness

The correctness of this compilation can be established by semantic preservation for which it is necessary to extend the compilation to values and environments of the machine, as shown below:

$$\begin{array}{c}〚n〛=n〚b〛=b〚(\lambda .d)[\Omega ]〛=(〚d〛·\mathtt{IRet})[〚\Omega 〛]\\ 〚(\mu .\lambda .d)[\Omega ]〛=(〚d〛·\mathtt{IRet}){[〚\Omega 〛]}_{rec}〚v_1\dots v_n〛=〚v_1〛\dots 〚v_n〛\end{array}$$

In this way, if an expression d is evaluated to a value v in an $\Omega$ environment, it is expected that its compilation $〚d〛$ is evaluated to $〚v〛$ in the $〚\Omega 〛$ environment. However, to prove this result, it is necessary to strengthen the hypothesis (we will see, in Section 2.3.2, that this is not necessary when natural semantics is used). Here, to strengthen the hypothesis is to concatenate any code c at the end of compilation $〚d〛$, so when the evaluation of $〚d〛$ finishes, it is expected that $〚v〛$ is at the top of the stack, and the code c remains to evaluate. This is formally expressed in the following theorem formulated by Leroy [14]:

Theorem 1.

If $\Omega ⊢d\Rightarrow v$, then $(〚d〛·c,〚\Omega 〛,s)\stackrel{+}{\to }(c,〚\Omega 〛,〚v〛·s)$ for all codes c and stacks s.

Proof outline.

The proof is conducted by induction on the derivation of $\Omega ⊢d\Rightarrow v$. The base cases where d is a natural, a Boolean, a nameless variable, an abstraction, or a fixed point (recursive abstraction) are straightforward since the corresponding $〚d〛$ compilation is a single machine instruction whose evaluation is performed by a single machine step → that mimics the ${\mathtt{MiniML}}^{\mathtt{dB}}$ d evaluation.

For the inductive cases where d is an arithmetic or comparison expression, a conditional, a local definition, or an application the proof follows the structure of the derivation $\Omega ⊢d\Rightarrow v$. The key idea is to use the $\stackrel{+}{\to }$ transitivity together with the induction hypothesis, while evaluating the intermingled single instructions which appear in $〚d〛$ by performing the corresponding → machine step. □

The complete proof can be consulted in Appendix A. This theorem is written in Coq as follows:

• Theorem compile_eval:
• ∀ O, ∀ d, ∀ v, MML_dB_NS O d v →
•     ∀ c, ∀ s, TC_MSECD_SS ((compile d)++c, compile_env O,s)
•                                   (c,compile_env O, (Val (compile_value v)::s)).

2.3. Big-Step MSECD Machine

This section introduces our big-step version of the Modern SECD machine. This machine is strongly based on our extended version of the original small-step semantics MSECD. Unlike the small-step MSECD, due to the high-level of abstraction of natural semantics, it is not necessary to use stack frames at all, and therefore the return instructions are also unnecessary (IRet which works for returning from a function call, nor IJoin that works for returning from a conditional). Having said this, we can affirm that the use of natural semantics directly impacts the machine design, specifically the machine’s components.

The instructions of the big-step MSECD machine, as well as its code, are the following:

i	$\hspace{1em}::=\hspace{1em}$	IConst n	Naturals	$c$	$\hspace{1em}::=\hspace{1em}$	$[ ]$	Empty code
	∣	IConstb b	Booleans		∣	$i·c$
	∣	IAdd	Addition
	∣	ISub	Subtraction
	∣	IMul	Multiplication
	∣	IEq	Equality comparison
	∣	IAcc $\underline{i}$	Variable value access (de Bruijn index)
	∣	ISel c c	Conditionals
	∣	ILet	Local definitions
	∣	IEndLet
	∣	IClos c	Abstraction
	∣	IClos${}_{rec}$ c	Recursion abstraction
	∣	IApp	Application

The values and environments of the machine are defined as follows:

$v_m$	$\hspace{1em}::=\hspace{1em}$	n	Naturals	$\Delta$	$\hspace{1em}::=\hspace{1em}$	$[ ]$	Empty environment
	∣	b	Booleans		∣	$v_m·\Delta$
	∣	$c[\Delta ]$	Closures
	∣	$c{[\Delta ]}_{rec}$	Recursive closures

Given the fact that the frames disappear, it is not necessary to define stack values. Due to this, the stack directly becomes a sequence of machine values:

s	$\hspace{1em}::=\hspace{1em}$	$[ ]$	Empty stack
	∣	$v_m·s$

The predicate $\Delta ⊢\underline{i}⟼v$ expresses that v is the value of the variable represented by the de Bruijn index $\underline{i}$ in the machine environment $\Delta$.

$\frac{}{v·\Delta ⊢\underline{0}⟼v}\frac{\Delta ⊢\underline{i}⟼v}{w·\Delta ⊢\underline{Si}⟼v}$

A state is a pair $(\Delta ,s)$ where $\Delta$ is a machine environment and s a stack.

The machine natural semantics is defined by the following two mutually dependent predicates:

$$\Delta ,s⊢c\Rightarrow ({\Delta }_f,s_f){\Delta }_1,s_1⊢i\Rightarrow ({\Delta }_2,s_2)$$

the first one for machine code, which can be read as follows: if the machine is in a state $(\Delta ,s)$, and a code c is given, evaluating c takes it to the state $({\Delta }_f,s_f)$. The second one for instructions, which can be read as follows: if the machine is in a state $({\Delta }_1,s_1)$ and an instruction i is given, evaluating i takes it to the state $({\Delta }_2,s_2)$. However, the entry point for the semantics should be the predicate for code.

The environment $\Delta$ is supposed to contain the value of the free variables (represented by IAcc $\underline{i}$ instructions) in c, whereas the environment ${\Delta }_1$ are supposed to contain the value of the free variable in i (if i is an instruction IAcc $\underline{i}$). The natural semantics of the machine is the following:

$\frac{}{\Delta ,s⊢[]\Rightarrow (\Delta ,s)}\frac{\Delta ,s⊢i\Rightarrow ({\Delta }_1,s_1)\hspace{1em}\hspace{1em}{\Delta }_1,s_1⊢c\Rightarrow ({\Delta }_2,s_2)}{\Delta ,s⊢i·c\Rightarrow ({\Delta }_2,s_2)}$

$\frac{}{\Delta ,s⊢\mathtt{IConst}n\Rightarrow (\Delta ,n·s)}\frac{}{\Delta ,s⊢\mathtt{IConstb}b\Rightarrow (\Delta ,b·s)}$

${\frac{}{\Delta ,n_2·n_1·s⊢\mathtt{IOp}\Rightarrow (\Delta ,n_1\star n_2·s)}}^{\mathtt{IOp}\in \{\mathtt{IAdd},\mathtt{ISub},\mathtt{IMul},\mathtt{IEq}\},\star \in \{+,-,\ast ,=\}\mathtt{resp}.}$

$\frac{\Delta ⊢\underline{i}⟼v}{\Delta ,s⊢\mathtt{IAcc}\underline{i}\Rightarrow (\Delta ,v·s)}$

$\frac{\Delta ,s⊢c_1\Rightarrow ({\Delta }_1,s_1)}{\Delta ,true·s⊢\mathtt{ISel}{c}_1{c}_2\Rightarrow ({\Delta }_1,s_1)}\frac{\Delta ,s⊢c_2\Rightarrow ({\Delta }_1,s_1)}{\Delta ,false·s⊢\mathtt{ISel}{c}_1{c}_2\Rightarrow ({\Delta }_1,s_1)}$

$\frac{}{\Delta ,v·s⊢\mathtt{ILet}\Rightarrow (v·\Delta ,s)}\frac{}{v·\Delta ,s⊢\mathtt{IEndLet}\Rightarrow (\Delta ,s)}$

$\frac{}{\Delta ,s⊢\mathtt{IClos}c\Rightarrow (\Delta ,c[\Delta ]·s)}\frac{}{\Delta ,s⊢{\mathtt{IClos}}_{rec}c\Rightarrow (\Delta ,c{[\Delta ]}_{rec}·s)}$

$\frac{v·{\Delta }_1,s⊢c\Rightarrow ({\Delta }_2,v_1·s_1)}{\Delta ,v·c[{\Delta }_1]·s⊢\mathtt{IApp}\Rightarrow (\Delta ,v_1·s_1)}\frac{v·c{[{\Delta }_1]}_{rec}·{\Delta }_1,s⊢c\Rightarrow ({\Delta }_2,v_1·s_1)}{\Delta ,v·c{[{\Delta }_1]}_{rec}·s⊢\mathtt{IApp}\Rightarrow (\Delta ,v_1·s_1)}$

The coding of the natural semantics of the machine is similar to that of the natural semantics of ${\mathtt{MiniML}}^{\mathtt{dB}}$ (only, it is necessary to use a mutually dependent definition in Coq, in correspondence with the mutually dependent predicates of the machine natural semantics). The same applies for the interpreter and its respective lemmas of soundness and completeness regarding the machine natural semantics. The formalization details can be consulted at [61].

We highlight that the machine natural semantics has the property enunciated in the following lemma:

Lemma 1.

Let Δ, ${\Delta }_1$, ${\Delta }_2$ be machine environments; s, $s_1$, $s_2$ stacks; $c_1$, $c_2$ machine codes. If

$$\Delta ,s⊢c_1\Rightarrow ({\Delta }_1,s_1),\hspace{1em}\hspace{1em}{\Delta }_1,s_1⊢c_2\Rightarrow ({\Delta }_2,s_2)$$

then

$$\Delta ,s⊢c_1·c_2\Rightarrow ({\Delta }_2,s_2)$$

Proof outline.

By induction on the derivation $\Delta ,s⊢c_1\Rightarrow (\Delta ,s_1)$. The base case is when $c_1$ is the empty code $c_1=[]$ which follows simply by hypothesis. The inductive case is when $c_1$ is not empty $c_1\ne []$ which is proved by applying the induction hypothesis and by ⇒ definition. □

This lemma is useful to prove compilation correctness (Section 2.3.2). A detailed proof can be seen in Appendix A.

2.3.1. Compilation

Using natural semantics, the compilation from ${\mathtt{MiniML}}^{\mathtt{dB}}$ to code of the big-step Modern SECD machine is defined by the following predicate:

$$d\Downarrow c$$

meaning, the ${\mathtt{MiniML}}^{\mathtt{dB}}$ expression d is compiled into the machine code c.

$\underset{n\Downarrow \mathtt{IConst}n}{-}\underset{b\Downarrow \mathtt{IConstb}b}{-}\underset{d_1\star d_2\Downarrow c_1·c_2·\mathtt{IOp}}{\overset{d_1\Downarrow c_1\hspace{1em}\hspace{1em}{d}_2\Downarrow c_2}{-}}\star \in \{+,-,\ast ,=\},\mathtt{IOp}\in \{\mathtt{IAdd},\mathtt{ISub},\mathtt{IMul},\mathtt{IEq}\}\mathrm{resp}.$

$\underset{\underline{i}\Downarrow \mathtt{IAcc}\underline{i}}{-}\underset{\mathtt{let}{d}_1\mathtt{in}{d}_2\Downarrow c_1·\mathtt{ILet}·c_2·\mathtt{IEndLet}}{\overset{d_1\Downarrow c_1\hspace{1em}\hspace{1em}{d}_2\Downarrow c_2}{-}}\underset{\mathtt{if}{d}_1\mathtt{then}{d}_2\mathtt{else}{d}_3\Downarrow c_1·\mathtt{ISel}{c}_2{c}_3}{\overset{d_1\Downarrow c_1\hspace{1em}\hspace{1em}{d}_2\Downarrow c_2\hspace{1em}\hspace{1em}{d}_3\Downarrow c_3}{-}}$

$\underset{\lambda .d\Downarrow \mathtt{IClos}c}{\overset{d\Downarrow c}{-}}\underset{\mu .\lambda .d\Downarrow {\mathtt{IClos}}_{rec}c}{\overset{d\Downarrow c}{-}}\underset{d_1{d}_2\Downarrow c_1·c_2·\mathtt{IApp}}{\overset{d_1\Downarrow c_1\hspace{1em}\hspace{1em}{d}_2\Downarrow c_2}{-}}$

Regarding the Coq encoding of this compilation, it is analogous to the ${\mathtt{MiniML}}^{\mathtt{dB}}$ semantics, meaning, it is done with an Inductive definition with Prop type:

• Inductive Compilation_NS: MML_dB_exp → code → Prop :=
• | Compilation_NS_Const: ∀ n:nat,
•                     Compilation_NS (Const_dB n) (IConst n::nil)
• | …
•  
• | Compilation_NS_Let:
•       ∀ d1, ∀ c1, Compilation_NS d1 c1 →
•       ∀ d2, ∀ c2, Compilation_NS d2 c2 →
•                     Compilation_NS (Letm_dB d1 d2) (c1 ++ ILet::c2  ++ IEndLet::nil)
• | …
•  
• | Compilation_NS_Lam:
•          ∀ d, ∀ c, Compilation_NS d c →
•                      Compilation_NS (Lam_dB d) (IClos c::nil)
•  
• | Compilation_NS_Mu:
•          ∀ d, ∀ c, Compilation_NS d c →
•                     Compilation_NS (Mu_dB d) (IClosr c::nil)
•  
• | Compilation_NS_App:
•       ∀ d1, ∀ c1, Compilation_NS d1 c1 →
•       ∀ d2, ∀ c2, Compilation_NS d2 c2 →
•                     Compilation_NS (App_dB d1 d2) (c1 ++ c2 ++ IApp::nil).

and the corresponding function is written as follows:

• Fixpoint Compilation_NS_compiler (d:MML_dB_exp) : code :=
• match d with
• | Const_dB n ⇒ IConst n::nil
• | …
• | Letm_dB d1 d2 ⇒ Compilation_NS_compiler d1 ++ ILet::Compilation_NS_compiler d2 ++ IEndLet::nil
• | …
• | Lam_dB d ⇒ IClos (Compilation_NS_compiler d)::nil
• | Mu_dB d ⇒ IClosr (Compilation_NS_compiler d)::nil
• | App_dB d1 d2 ⇒ Compilation_NS_compiler d1 ++ Compilation_NS_compiler d2 ++ IApp::nil
• end.

It is noteworthy how this time, instead of the function being an interpreter, it is a compiler, since it translates an expression instead of evaluating it. Also, it is not necessary to add a natural parameter to bound the recursion, given that the translation is decidable. This fact is guaranteed in Coq by using structural recursion (based on syntax) on the expression d.

The following lemma expresses that the compiler is sound regarding the natural semantics definition of the compilation:

• Lemma Compilation_NS_compiler_soundness:
• ∀ d:MML_dB_exp, ∀ c:code,
• Compilation_NS d c →
• Compilation_NS_compiler d = c.

Conversely, the next lemma expresses that the compiler is complete regarding the natural semantics definition of the compilation:

• Lemma Compilation_NS_compiler_completeness:
• ∀ d:MML_dB_exp, ∀ c:code,
• Compilation_NS_compiler d = c →
• Compilation_NS d c.

2.3.2. Correctness

To establish the correctness, we extend the compilation to values and environments once more, so after that we can formulate semantic preservation.

To formulate correctness, we expect that if a nameless expression d is evaluated to a value v in an environment $\Omega$, besides, if c is the code resulting of the d compilation, and $\Delta$ is the resulting compilation of $\Omega$; then, it must exist a machine value $v_m$ that corresponds to the compilation of v and, when c is evaluated starting with the machine in a state $(\Delta ,s)$, for any stack s, the evaluation takes the machine to the state $(\Delta ,v_m·s)$. Now, the correctness theorem is enunciated.

Theorem 2 (Correctness for termination).

Let Ω be a nameless environment, Δ a machine environment, d a nameless expression, c a machine code, v a nameless value. If

then, there exists a machine value $v_m$ such that v v_m and for all stack s,

$$\Delta ,s⊢c\Rightarrow (\Delta ,v_m·s)$$

Proof outline.

We proceed by induction on the derivation of $\Omega ⊢d\Rightarrow v$. The base cases where d is a natural, a Boolean, a nameless variable, an abstraction, or a fixed point (recursive abstraction) are straightforward. In these cases, we exhibit a $v_m$ such that v v_m, since c is the result of d compilation, c is a single machine instruction hence $\Delta ,s⊢c\Rightarrow (\Delta ,v_m·s)$ follows simply by definition.

For the inductive cases where d is an arithmetic or comparison expression, a conditional, a local definition, or an application, the  main idea is to use the induction hypothesis in tandem with Lemma 1. In such way the machine evaluation follows the structure of the $\Omega ⊢d\Rightarrow v$ derivation and the proof is simple and intuitive. □

The complete proof can be consulted in Appendix A. This theorem is written as follows in Coq:

• Theorem Compilation_NS_correctness:
• ∀ O, ∀ d, ∀ v, MML_dB_NS O d v →
•              ∀ c, Compilation_NS d c →
•              ∀ D, Compilation_NS_env O D →
•             ∃ mv, Compilation_NS_val v mv  ∧
•              ∀ s, BSMSECD_NSC (D,s) c  (D, mv::s).

We can immediately notice that due to the unifying use of natural semantics to define each of the compiler’s components: source language, compilation and machine; the source language is mapped down, in a transparent way, to the target language (in this case, machine code) by means of the compilation. In this manner, to establish the correctness turns out to be easier, clearer, simpler and more intuitive than using an ad-hoc solution. For instance, in this case, it was unnecessary to previously define a closure of a relation, and it was also unnecessary to strengthen the hypothesis to prove the correctness theorem compared to the use of a function to define the compilation and small-step semantics in the machine.

3. Coinductive Natural Semantics

In this section, we will address the case in which the computations do not terminate, for which we will use coinductive natural semantics.

3.1. ${\mathtt{MiniML}}^{\mathtt{dB}}$

In general, coinduction allows us to reason on infinite structures. In this way, taking into account the natural semantics design, we can employ a coinductive definition to express infinite evaluations of a language, in this case of ${\mathtt{MiniML}}^{\mathtt{dB}}$. Following Leroy [14], we define the coinductive natural semantics for divergence (infinite evaluations) by the following predicate:

$$\Omega ⊢d\stackrel{\infty }{\Rightarrow }$$

which can be read: in the $\Omega$ environment, the evaluation of the expression d diverges, is infinite, or, non-terminate.

That is, the infinite evaluations of ${\mathtt{MiniML}}^{\mathtt{dB}}$ are defined by the coinductive interpretation of the following rules:

$\underset{\Omega ⊢d_1\star d_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\stackrel{\infty }{\Rightarrow }}}}\underset{\Omega ⊢d_1\star d_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow n_1\hspace{1em}\hspace{1em}\Omega ⊢d_2\stackrel{\infty }{\Rightarrow }}}}$

$\underset{\Omega ⊢\mathtt{let}{d}_1\mathtt{in}{d}_2\stackrel{\infty }{\Rightarrow }}{\overset{\Omega ⊢d_1\stackrel{\infty }{\Rightarrow }}{=}}\underset{\Omega ⊢\mathtt{let}{d}_1\mathtt{in}{d}_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow v_1\hspace{1em}\hspace{1em}{v}_1·\Omega ⊢d_2\stackrel{\infty }{\Rightarrow }}}}$

$\underset{\Omega ⊢\mathtt{if}{d}_1\mathtt{then}{d}_2\mathtt{else}{d}_3\stackrel{\infty }{\Rightarrow }}{\overset{\Omega ⊢d_1\stackrel{\infty }{\Rightarrow }}{=}}\hspace{1em}\hspace{1em}\underset{\Omega ⊢\mathtt{if}{d}_1\mathtt{then}{d}_2\mathtt{else}{d}_3\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow true\hspace{1em}\hspace{1em}\Omega ⊢d_2\stackrel{\infty }{\Rightarrow }}}}\hspace{1em}\hspace{1em}\underset{\Omega ⊢\mathtt{if}{d}_1\mathtt{then}{d}_2\mathtt{else}{d}_3\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow false\hspace{1em}\hspace{1em}\Omega ⊢d_3\stackrel{\infty }{\Rightarrow }}}}$

$\underset{\Omega ⊢d_1{d}_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\stackrel{\infty }{\Rightarrow }}}}\hspace{1em}\hspace{1em}\underset{\Omega ⊢d_1{d}_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow (\lambda .d)[{\Omega }_1]\hspace{1em}\hspace{1em}\Omega ⊢d_2\stackrel{\infty }{\Rightarrow }}}}\hspace{1em}\hspace{1em}\underset{\Omega ⊢d_1{d}_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow (\mu .\lambda .d)[{\Omega }_1]\hspace{1em}\hspace{1em}\Omega ⊢d_2\stackrel{\infty }{\Rightarrow }}}}$

$\underset{\Omega ⊢d_1{d}_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow (\lambda .d)[{\Omega }_1]\hspace{1em}\hspace{1em}\Omega ⊢d_2\Rightarrow v_2\hspace{1em}\hspace{1em}{v}_2·{\Omega }_1⊢d\stackrel{\infty }{\Rightarrow }}}}$

$\underset{\Omega ⊢d_1{d}_2\stackrel{\infty }{\Rightarrow }}{\underset{¯}{\underset{¯}{\Omega ⊢d_1\Rightarrow (\mu .\lambda .d)[{\Omega }_1]\hspace{1em}\hspace{1em}\Omega ⊢d_2\Rightarrow v_2\hspace{1em}\hspace{1em}{v}_2·(\mu .\lambda .d)[{\Omega }_1]·{\Omega }_1⊢d\stackrel{\infty }{\Rightarrow }}}}$

Adopting the Leroy [14] convention, double horizontal lines denote coinductive interpretation, whereas single horizontal lines denote inductive interpretation.

The coinduction support in Coq is based on the work of Giménez [66]. In particular, Coq has native support of coinductive definitions. Likewise, a natural semantics definition can be encoded in Coq as an Inductive definition with type Prop, a coinductive natural semantics definition can be encoded in Coq as a CoInductive definition with type Prop. Hence, the ${\mathtt{MiniML}}^{\mathtt{dB}}$ semantics for divergence can be written in Coq as follows:

• CoInductive MML_dB_CNS: MML_dB_env → MML_dB_exp → Prop :=
• | …
•  
• | MML_dB_CNS_LetL:
•         ∀ O, ∀ d1, MML_dB_CNS O d1 →
•               ∀ d2, MML_dB_CNS O (Letm_dB d1 d2)
•  
• | MML_dB_CNS_LetR:
• ∀ O, ∀ d1, ∀ v1, MML_dB_NS O d1 v1 →
•               ∀ d2, MML_dB_CNS (v1::O) d2 →
•                      MML_dB_CNS O (Letm_dB d1 d2)
• | …
•  
• | MML_dB_CNS_AppL:
•          ∀ O, ∀ d1, MML_dB_CNS O d1 →
•                ∀ d2, MML_dB_CNS O (App_dB d1 d2)
•  
• | MML_dB_CNS_AppR:
•  ∀ O O1, ∀ d1 d, MML_dB_NS O d1 (Clos_dB d O1) →
•               ∀ d2, MML_dB_CNS O d2 →
•                      MML_dB_CNS O (App_dB d1 d2)
•  
• | MML_dB_CNS_AppRr:
•  ∀ O O1, ∀ d1 d, MML_dB_NS O d1 (Closr_dB d O1) →
•               ∀ d2, MML_dB_CNS O d2 →
•                      MML_dB_CNS O (App_dB d1 d2)
•  
• | MML_dB_CNS_AppF:
•  ∀ O O1, ∀ d1 d, MML_dB_NS O d1 (Clos_dB d O1) →
•        ∀ d2, ∀ v2, MML_dB_NS O d2 v2 →
•                      MML_dB_CNS (v2::O1) d →
•                      MML_dB_CNS O (App_dB d1 d2)
•  
• | MML_dB_CNS_AppFr:
•  ∀ O O1, ∀ d1 d, MML_dB_NS O d1 (Closr_dB d O1) →
•        ∀ d2, ∀ v2, MML_dB_NS O d2 v2 →
•                      MML_dB_CNS (v2:: (Closr_dB d O1)::O1) d →
•                      MML_dB_CNS O (App_dB d1 d2).

In the same manner as shown earlier in Section 2.1, where we verified that our interpreter MML_dB_NS_interpreter is sound regarding ${\mathtt{MiniML}}^{\mathtt{dB}}$ natural semantics; here, we must verify that it is sound regarding ${\mathtt{MiniML}}^{\mathtt{dB}}$ coinductive natural semantics for non-termination, meaning, we must prove the next lemma:

• Lemma MML_NS_interpreter_soundness_non_termination:
• ∀ O, ∀ d, MML_dB_CNS O d →
•       ∀ n, MML_dB_NS_interpreter n O d = None.

This lemma states that, if the evaluation of d does not terminate, whatever the n value of the fuel is, the interpreter will necessarily, eventually, run out of fuel (None means that the interpreter runs out of fuel).

Conversely, to verify that our interpreter is complete regarding ${\mathtt{MiniML}}^{\mathtt{dB}}$ coinductive natural semantics, we must prove this lemma:

• Lemma MML_NS_interpreter_completeness_non_termination: ∀ n, ∀ O, ∀ d,
• MML_dB_NS_interpreter n O d = None →
• not (∃ v, MML_dB_NS O d v) ∨
• (∃ m, m > n ∧ ∃ v, MML_dB_NS_interpreter m O d = Some v).

This lemma says that if the interpreter runs out of fuel, then, there is not a finite evaluation of or d or, in fact, it exists a finite evaluation of d, but more fuel is needed for the interpreter to be able to compute it. The proof of this lemma in Coq requires classic reasoning.

3.2. Modern SECD Machine

Let us now see how to express non-terminating computations in a machine. Leroy [14] uses small-step semantics to express infinitely many transitions in the MSECD. He defines the transition relation ‘$\stackrel{\infty }{\to }$’ coinductively as follows:

$$\underset{m_1\stackrel{\infty }{\to }}{\underset{¯}{\underset{¯}{m_1\to m_2\hspace{1em}\hspace{1em}{m}_2\stackrel{\infty }{\to }}}}$$

This relation can be written in Coq in the following manner:

• CoInductive transinf: conf → Prop :=
• | transinf_intro: ∀ m1 m2,
•      MSECD_SS m1 m2 →
•      transinf m2 →
•      transinf m1.

However, by using this definition directly, it is not possible to prove the correctness of the compilation in the case of non-termination. The reason is that the Coq coinduction mechanism imposes the guard condition. The guard condition requires (at least) one rule (a constructor) of a coinductive definition to be used before the coinduction hypothesis is employed during a proof by coinduction. The solution offered by Leroy [14] is to define an auxiliary relation with which the proof can be carried out, and which is equivalent to the previous definition.

$$\underset{m\stackrel{\infty }{\underset{n+1}{\to }}}{\overset{m\stackrel{\infty }{\underset{n}{\to }}}{=}}(\stackrel{\infty }{\underset{n}{\to }}\text{-}\mathrm{sleep})\underset{m_1\stackrel{\infty }{\underset{n}{\to }}}{\overset{m_1\stackrel{+}{\to }{m}_2\hspace{1em}\hspace{1em}{m}_2\stackrel{\infty }{\underset{n^{\prime }}{\to }}}{=}}(\underset{n}{\overset{\infty }{\to }}\text{-}\mathrm{perform})$$

The most important property of the $\stackrel{\infty }{\underset{n}{\to }}$ relation, for our purposes, is that it allows the machine to remain in the same configuration, at most, a finite number n times ($\stackrel{\infty }{\underset{n}{\to }}$-sleep rule). This rule is crucial, as it is used for being able to comply with the guard condition when carrying out the correctness proof. At some point before n reaches 0, or necessarily when n arrives at 0, at least one transition ($\stackrel{\infty }{\underset{n}{\to }}$-perform rule) must be performed, in exchange for making a transition, the value of n is reset to any natural $n^{\prime }$, i.e., the possibility is given (again) to remain in the same configuration (this time, $n^{\prime }$ times at most). The relation $\stackrel{\infty }{\to }$ and the relation $\stackrel{\infty }{\underset{n}{\to }}$ are equivalent as stated in the following lemma:

Lemma 2.

Let m be a machine configuration, n any natural number,

$$m\stackrel{\infty }{\to }\hspace{1em}if and only if\hspace{1em}m\stackrel{\infty }{\underset{n}{\to }}$$

Proof outline.

The if part is by coinduction. By $\stackrel{\infty }{\to }$ definition, necessarily $m\to m_1$ and $m_1\stackrel{\infty }{\to }$, the result is obtained by applying the induction hypothesis on $m_1\stackrel{\infty }{\to }$ and then by using the $\stackrel{\infty }{\underset{n}{\to }}$-perform rule. The only if part is also by coinduction. Assuming that if $m\stackrel{\infty }{\underset{n}{\to }}$ then $m\to m_1$ and $m_1\stackrel{\infty }{\underset{n_1}{\to }}$, we apply the coinduction hypothesis on $m_1\stackrel{\infty }{\underset{n_1}{\to }}$ and then the result follows by $\stackrel{\infty }{\to }$ definition. □

A more detailed proof can be consulted in Appendix A.

Compilation Correctness

To carry out the correctness proof, it is necessary to define a measure that indicates how many times the machine can remain in the same configuration based on the constructs of a language. The measure offered by Leroy (extended to cover all ${\mathtt{MiniML}}^{\mathtt{dB}}$) is the following:

$$\begin{array}{ccc}\hfill \parallel n\parallel =\parallel b\parallel =\parallel x\parallel =\parallel \lambda .d\parallel =\parallel \mu .\lambda .d\parallel & =& 0\hfill \\ \hfill \parallel d_1\star d_2\parallel & =& \parallel d_1\parallel +1\hfill \\ \hfill \parallel \mathtt{let}{d}_1\mathtt{in}{d}_2\parallel & =& \parallel d_1\parallel +1\hfill \\ \hfill \parallel \mathtt{if}{d}_1\mathtt{then}{d}_2\mathtt{else}{d}_3\parallel & =& \parallel d_1\parallel +1\hfill \\ \hfill \parallel d_1{d}_2\parallel & =& \parallel d_1\parallel +1\hfill \end{array}$$

This is because it is possible that an evaluation step of a ${\mathtt{MiniML}}^{\mathtt{dB}}$ expression d does not correspond, one to one in the same order, to a transition while evaluating $〚d〛$ in the machine, causing the machine to stay at the same configuration, $\parallel d\parallel$ times, before performing a transition.

In this way, we are ready to state the correctness for the non-termination case, using the auxiliary relation $\stackrel{\infty }{\underset{n}{\to }}$ and strengthening the hypothesis, by the following lemma:

Lemma 3.

If $\Omega ⊢d\stackrel{\infty }{\Rightarrow }$, then $(〚d〛·c,〚\Omega 〛,s)\stackrel{\infty }{\underset{\parallel d\parallel }{\to }}$ for all codes c and stacks s.

Proof outline.

By coinduction. The main idea of the proof is to use Theorem 1 to evaluate the finite parts of d, to apply the coinduction hypothesis on the infinite parts of d, and to employ $\stackrel{\infty }{\underset{n}{\to }}$-sleep and $\stackrel{\infty }{\underset{n}{\to }}$-perform rules as convenient. □

A complete proof of this lemma can be consulted in Appendix A. This gives the possibility for formulating the correctness theorem directly with the $m\stackrel{\infty }{\to }$ relation, as Leroy [14] does, as follows:

Theorem 3.

If $\Omega ⊢d\stackrel{\infty }{\Rightarrow }$, then $(〚d〛·c,〚\Omega 〛,s)\stackrel{\infty }{\to }$ for all codes c and stacks s.

Proof outline.

The result is an immediate deduction from Lemma 3 followed by an application of Lemma 2. □

A step-by-step proof can be seen in Appendix A. This theorem is written in Coq as follows:

• Theorem compile_evalinf:
• ∀ O, ∀ d, MML_dB_CNS O d →
• ∀ c, ∀ s, transinf ((compile d)++c, (compile_env O), s).

3.3. Big-Step MSECD Machine

This section introduces coinductive natural semantics to express non-terminating computations (infinite evaluations) in a machine. We illustrate its use with our big-step Modern SECD machine.

3.3.1. Rules of Non-terminating Computations

As with natural semantics (for finite evaluations, Section 2.3), coinductive natural semantics for divergence (infinite evaluations) is defined by the following two mutually dependent predicates:

$$\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }\Delta ,s⊢c\stackrel{\infty }{\Rightarrow }$$

The first one reads: in the state $(\Delta ,s)$ the instruction i diverges, whereas the second one reads: in the state $(\Delta ,s)$ the code c diverges.

Thus, the infinite evaluations of the machine are defined by the coinductive interpretation of the following rules:

$1)\underset{\Delta ,s⊢i·c\stackrel{\infty }{\Rightarrow }}{\overset{\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }}{=}}2)\underset{\Delta ,s⊢i·c\stackrel{\infty }{\Rightarrow }}{\overset{\Delta ,s⊢i\Rightarrow ({\Delta }_1,s_1)\hspace{1em}\hspace{1em}{\Delta }_1,s_1⊢c\stackrel{\infty }{\Rightarrow }}{=}}$

$3)\underset{\Delta ,true·s⊢\mathtt{ISel}{c}_1{c}_2\stackrel{\infty }{\Rightarrow }}{\overset{\Delta ,s⊢c_1\stackrel{\infty }{\Rightarrow }}{=}}4)\underset{\Delta ,false·s⊢\mathtt{ISel}{c}_1{c}_2\stackrel{\infty }{\Rightarrow }}{\overset{\Delta ,s⊢c_2\stackrel{\infty }{\Rightarrow }}{=}}$

$5)\underset{\Delta ,v·c[{\Delta }_1]·s⊢\mathtt{IApp}\stackrel{\infty }{\Rightarrow }}{\overset{v·{\Delta }_1,s⊢c\stackrel{\infty }{\Rightarrow }}{=}}6)\underset{\Delta ,v·c{[{\Delta }_1]}_{rec}·s⊢\mathtt{IApp}\stackrel{\infty }{\Rightarrow }}{\overset{v·c{[{\Delta }_1]}_{rec}·{\Delta }_1,s⊢c\stackrel{\infty }{\Rightarrow }}{=}}$

The coinductive natural semantics of the machine is encoded in Coq in an analogous manner to the coinductive natural semantics of ${\mathtt{MiniML}}^{\mathtt{dB}}$ (it is just necessary to use a coinductive mutually dependent definition in Coq that parallels the mutually dependent predicates of the machine coinductive natural semantics). Likewise, the respective lemmas that express that the machine interpreter is sound and complete regarding the machine coinductive natural semantics are analogous to those of the ${\mathtt{MiniML}}^{\mathtt{dB}}$ interpreter. These formalizations can be seen in detail in [61].

We will give a brief explanation of the rules. When evaluating a code, it must begin by evaluating the first instruction i. The evaluation of i can be finite (rule 2) or infinite (rule 1). In the rule 1 case, if the first instruction diverges, then the complete code diverges. How can an instruction diverge? Let us recall (Section 2.3) that due to the high level of abstraction of the big-step MSECD, in the case of termination, the ISel and IApp instructions are fully evaluated in a single big step, which includes the evaluation of their sub-codes and is why for these instructions it is necessary to define rules that allow expressing the possibility that their corresponding sub-codes diverge (rules 3–6). In the case of rule 2, if the evaluation of the first instruction terminates but the remaining code diverges, then, the complete code (including the first instruction) diverges.

We can note here that in principle only rule 2 is necessary to express divergence in the machine since, intuitively, an instruction performs only a single basic operation and this rule is the analogous of the small-step semantics transition relation $\stackrel{\infty }{\to }$. However, as already mentioned, our big-step machine has two instructions, namely ISel and IApp, which are high-level (and therefore they evaluate different from their small-step semantics counterparts, performing not only single basic operations but a big-step sub-code evaluation). This is why these instructions require specific rules, while the remaining instructions, perform in fact only a single basic operation; for instance, $\mathtt{IConst}n$ push n on the stack. This is why these remaining instructions do not need specific rules.

In this way, the machine computations that do not terminate are completely defined. However, as in the case of the MSECD small-step semantics, we are facing, once more, the problem with Coq’s guard condition. This means that similarly, we cannot prove correctness directly by using this relation. To solve this problem, we will present a variant of Leroy’s solution adapted to coinductive natural semantics. This means that we must define an auxiliary relation equivalent to the previous relation, and which allows proving correctness. Below, we present the auxiliary relation:

$1)\underset{\Delta ,s⊢i·c\stackrel{\infty }{\underset{n}{⤇}}}{\overset{\Delta ,s⊢i\stackrel{\infty }{⤇}}{=}}$

$3)\underset{\Delta ,true·s⊢\mathtt{ISel}{c}_1{c}_2\stackrel{\infty }{⤇}}{\overset{\Delta ,s⊢c_1\stackrel{\infty }{\underset{n}{⤇}}}{=}}4)\underset{\Delta ,false·s⊢\mathtt{ISel}{c}_1{c}_2\stackrel{\infty }{⤇}}{\overset{\Delta ,s⊢c_2\stackrel{\infty }{\underset{n}{⤇}}}{=}}$

$5)\underset{\Delta ,v·c[{\Delta }_1]·s⊢\mathtt{IApp}\stackrel{\infty }{⤇}}{\overset{v·{\Delta }_1,s⊢c\stackrel{\infty }{\underset{n}{⤇}}}{=}}6)\underset{\Delta ,v·c{[{\Delta }_1]}_{rec}·s⊢\mathtt{IApp}\stackrel{\infty }{⤇}}{\overset{v·c{[{\Delta }_1]}_{rec}·{\Delta }_1,s⊢c\stackrel{\infty }{\underset{n}{⤇}}}{=}}$

$\underset{\Delta ,s⊢c_1·c_2\stackrel{\infty }{\underset{n+1}{⤇}}}{\overset{\Delta ,s⊢c_1\stackrel{\infty }{\underset{n}{⤇}}}{=}}(\stackrel{\infty }{\underset{n}{⤇}}\text{-}\mathrm{sleep})\underset{c_1\ne []\hspace{1em}\Delta ,s⊢c_1\Rightarrow ({\Delta }_1,s_1)\hspace{1em}{\Delta }_1,s_1⊢c_2\stackrel{\infty }{\underset{n^{\prime }}{⤇}}}{\overset{\Delta ,s⊢c_1·c_2\stackrel{\infty }{\underset{n}{⤇}}}{=}}(\stackrel{\infty }{\underset{n}{⤇}}\text{-}\mathrm{perform})$

The rule ($\stackrel{\infty }{\underset{n}{⤇}}$-sleep) is the improved analogous version of Leroy’s rule ($\stackrel{\infty }{\underset{n}{\to }}$-sleep), since, in addition, it expresses that if in a code, the initial code $c_1$ diverges, then, no matter what the remaining code $c_2$ is, the code will diverge. The importance of this improvement is that it allows proving correctness without the need to strengthen the hypothesis. The rule ($\stackrel{\infty }{\underset{n}{⤇}}$-perform) is analogous to the rule ($\stackrel{\infty }{\underset{n}{\to }}$-perform) of Leroy. We can note that rule 2 disappears (is no longer necessary) because it is subsumed by the ($\stackrel{\infty }{\underset{n}{⤇}}$-perform) rule. For its part, the remaining rules (1 and 3–6) remain unchanged, i.e., they are analogous, but instead of the relation for code $\stackrel{\infty }{\Rightarrow }$ they use the relation $\stackrel{\infty }{\underset{n}{⤇}}$ with any natural n.

It is worth remarking that the $\stackrel{\infty }{\Rightarrow }$ relation defines the machine computations that do not terminate in the expected way and it would be ideal working directly with it in Coq; however, because of the Coq guard condition it is not possible. This is why we have defined the $\stackrel{\infty }{⤇}$ relation just to beat the Coq guard condition. Since we have defined the $\stackrel{\infty }{⤇}$ relation (more precisely $\stackrel{\infty }{\underset{n}{⤇}}$ relation for code and $\stackrel{\infty }{⤇}$ relation for instructions) in a very similar way to the $\stackrel{\infty }{\Rightarrow }$ relation, we have used a very similar notation; nonetheless, we should be careful and notice the distinction between $\stackrel{\infty }{\Rightarrow }$ and $\stackrel{\infty }{⤇}$.

The following lemma states that the two original mutually dependent relations are equivalent to the two auxiliary mutually dependent relations.

Lemma 4.

Let Δ be a machine environment, s a stack, i a machine instruction,

$$\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }\hspace{1em}\mathit{if}\mathit{and}\mathit{only}\mathit{if}\hspace{1em}\Delta ,s⊢i\stackrel{\infty }{⤇}$$

and, let c be a machine code, n any natural,

$$\Delta ,s⊢c\stackrel{\infty }{\Rightarrow }\hspace{1em}\mathit{if}\mathit{and}\mathit{only}\mathit{if}\hspace{1em}\Delta ,s⊢c\stackrel{\infty }{\underset{n}{⤇}}$$

Proof outline.

The if part consist of: if $\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }$ then $\Delta ,s⊢i\stackrel{\infty }{⤇}$, and  if $\Delta ,s⊢c\stackrel{\infty }{\Rightarrow }$ then $\Delta ,s⊢c\stackrel{\infty }{\underset{n}{⤇}}$, i.e., of the following two cases:

• If $\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }$ then $\Delta ,s⊢i\stackrel{\infty }{⤇}$. Assuming 2, since the instructions’ definition of $\stackrel{\infty }{\Rightarrow }$ and $\stackrel{\infty }{⤇}$ are analogous, the proof proceeds simply by case analysis which are proved directly by $\stackrel{\infty }{⤇}$ definition using 2 to obtain the required $\Delta ,s⊢c\stackrel{\infty }{\underset{n}{⤇}}$ code premises.
• If $\Delta ,s⊢c\stackrel{\infty }{\Rightarrow }$ then $\Delta ,s⊢c\stackrel{\infty }{\underset{n}{⤇}}$. By coinduction. The main idea is to use the coinduction hypothesis together with the $\stackrel{\infty }{\underset{n}{⤇}}$-perform rule, and to apply 1 to obtain $\Delta ,s⊢i\stackrel{\infty }{⤇}$ premises when necessary.

The only if part consists of: If $\Delta ,s⊢i\stackrel{\infty }{⤇}$ then $\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }$, and if $\Delta ,s⊢c\stackrel{\infty }{\underset{n}{⤇}}$ then $\Delta ,s⊢c\stackrel{\infty }{\Rightarrow }$. That is, of the following two cases:

3.

If $\Delta ,s⊢i\stackrel{\infty }{⤇}$ then $\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }$. Assuming 4, the proof is analogue to that of 1 going in the opposite direction (and using 4 instead of 2).

4.

If $\Delta ,s⊢c\stackrel{\infty }{\underset{n}{⤇}}$ then $\Delta ,s⊢c\stackrel{\infty }{\Rightarrow }$. Assuming that, if  $\Delta ,s⊢i·c\stackrel{\infty }{\underset{n}{⤇}}$ then $\Delta ,s⊢i\stackrel{\infty }{⤇}$ or there exists $n_1$, ${\Delta }_1$, $s_1$, such that $\Delta ,s⊢i\Rightarrow ({\Delta }_1,s_1)$ and ${\Delta }_1,s_1⊢c\stackrel{\infty }{\underset{n_1}{⤇}}$; The proof proceeds by coinduction. The key idea is to use the coinduction hypothesis together with $\stackrel{\infty }{\underset{n}{⤇}}$ definition, in particular with the $\stackrel{\infty }{\underset{n}{⤇}}$-perform rule, employing the assumption in the step which is required, and  applying 3 to obtain $\Delta ,s⊢i\stackrel{\infty }{\Rightarrow }$ premises when necessary.

 □

The details of this proof can be consulted in Appendix A.

3.3.2. Compilation Correctness

To prove correctness, we must use the auxiliary relation $\stackrel{\infty }{\underset{n}{⤇}}$ along with a measure. Following an analogous argument to the case of the small-step MSECD, the measure $\parallel d\parallel$ also works here. In this way, the correctness for the non-termination case can be formulated by the following lemma:

Lemma 5 (Correctness for non-termination (auxiliary)).

Let Ω be a nameless environment, Δ a machine environment, d a nameless expression, c a machine code. If

then, for all stack s,

$$\Delta ,s⊢c\stackrel{\infty }{\underset{\parallel d\parallel }{⤇}}$$

Proof outline.

We proceed by coinduction. The main idea is to mimic the ${\mathtt{MiniML}}^{\mathtt{dB}}$ d evaluation in the machine while evaluating c. To carry out this idea, for the finite parts of d (if any), we employ Theorem 2, whereas for the infinite parts of d, we apply the coinduction hypothesis. In addition, we use the $\stackrel{\infty }{\underset{n}{⤇}}$ definition, including the $\stackrel{\infty }{\underset{n}{⤇}}$-sleep and $\stackrel{\infty }{\underset{n}{⤇}}$-perform rules, as necessary. □

A complete proof of this lemma appears in Appendix A. Finally, we enunciate the correctness theorem for the non-termination case of the machine, using the $\stackrel{\infty }{\Rightarrow }$ relation directly in the following manner:

Theorem 4 (Correctness for non-termination).

Let Ω be a nameless environment, Δ a machine environment, d a nameless expression, c a machine code. If

then, for all stack s,

$$\Delta ,s⊢c\stackrel{\infty }{\Rightarrow }$$

Proof outline.

The result is a direct consequence of Lemma 5 followed by Lemma 4. □

A detailed step-by-step proof can be found in Appendix A. This theorem is written in Coq as follows:

• Theorem Compilation_CNS_correctness:
• ∀ O, ∀ d, MML_dB_CNS O d →
•        ∀ c, Compilation_NS d c →
•        ∀ D, Compilation_NS_env O D →
•        ∀ s, BSMSECD_CNSC (D,s) c.

4. Abstract to Coq Translation Algorithm

At this point, by means of our Mini-ML compiler, we have shown how from the (coinductive) natural semantics definition of each compiler component the corresponding formalization in Coq can be realized. It is our intention here to generalize this method and write it formally as an algorithm.

Algorithm 1 expresses how to translate a (coinductive) natural semantics definition of a compiler to its corresponding formalization in Coq.

We observe that the steps of the algorithm possess a high-level of abstraction. This is favorable in the sense that it provides freedom on how to actually implement them. We can even take advantage of this freedom by applying previous work. For instance, applying the results in [67], step 14 could be performed by generating a function from the Inductive definition $I_N$, corresponding to the natural semantics N.

Analyzing the algorithm, as we can note in step 35, the case in which the target language R of a translation T is a postfix representation requires a special treatment that merits explanation. Let V be the source language of T, d a construct of V, if c is the translation of d into R, then if R is a prefix representation when reasoning about the evaluation of c in Coq, necessarily a constructor s associated with the construct, must be used (at front) when starting the evaluation; in this way, the guard condition is fulfilled. Instead, if R is a postfix representation, then necessarily a constructor s associated with the construct, must be used but (behind), at the end of the evaluation; in this way, the Coq’s guard condition is not fulfilled since it requires that it must be used at the start (at front). For instance, let Plus e1 e2 be a construct in $\mathtt{MiniML}$ and let Plus_dB d1 d2 be its translation in ${\mathtt{MiniML}}^{\mathtt{dB}}$, then the evaluation of Plus_dB d1 d2 will start using a Plus_dB constructor associated with the addition, at the start, and the Coq’s guard condition will be satisfied. Instead, let Plus_dB d1 d2 be a construct in ${\mathtt{MiniML}}^{\mathtt{dB}}$ and c1++c2++IAdd its translation into code of the big-step MSECD, then the evaluation of c1++c2++IAdd will not start using an IAdd constructor associated with the addition, even when potentially, eventually, it will be used at the end in fact. Therefore, in this latter case, we must find a way to express and convince Coq’s guard condition that the constructor will be in fact used, but at the end of the evaluation of c. This is exactly what the solution presented in Section 3.3 does, if the auxiliary relation is used, then initially the sleep rule constructor can be used, which allows the starting of the evaluation of c without using a constructor s associated with the construct, ensuring that potentially, eventually, such a s constructor will be in fact used (what is expressed in the constructor corresponding to the perform rule); the measure function $\parallel d\parallel$ indicates the number of constructors that will be used at the end of the evaluation of c. This is certainly a weakness of Coq’s guard condition that turns out to be too inflexible in this case, and that is why we have had to resort to an indirect solution.

In fact, in our compiler, in the $\mathtt{MiniML}$ to ${\mathtt{MiniML}}^{\mathtt{dB}}$ translation it was not necessary to use this indirect solution at all because ${\mathtt{MiniML}}^{\mathtt{dB}}$ is a prefix representation. Instead, it was in fact necessary to use it in the ${\mathtt{MiniML}}^{\mathtt{dB}}$ to big-step MSECD machine code generation because machine code is a postfix representation.

Algorithm 1: Translation of a Compiler Definition to Coq (first part)

Algorithm 1: Translation of a Compiler Definition to Coq (second part)

5. Conclusions

Natural semantics is a simple, easy, and intuitive formalism widely known and used in the literature to define the semantics of programming languages.

In this work, we extended (coinductive) natural semantics to present it as a unifying framework for the verification of total correctness of compilers in Coq. This way, we present a solution to the problem of having a simple, easy, clear, and intuitive framework to perform this task in this proof assistant. By means of this framework, one can obtain standalone executable verified compiler.

Although we have not illustrated it here, natural semantics can also be used to express and verify the static semantics of a language. For instance, in [68] the Mini-ML static semantics is verified (although it is not possible to obtain a verified semantic analyzer). In future work, we plan to extend this use of natural semantics to make it possible to obtain a verified semantic analyzer.

To have a full compiler framework, we must address lexing and parsing too. So, we envisioned that natural ‘semantics’ can also be used to perform these tasks. This inspiration comes from the observation that, as stated by Kahn [11], natural deduction is at the heart of natural semantics, so we are looking for a natural deduction-based parsing strategy, fortunately, it already exists a parsing technique with these features since long time ago. In the logic programming community, parsing as deduction [69,70] is a well-known and established natural deduction-based parsing framework. Therefore, since both: natural semantics and parsing as deduction are based on natural deduction, we believe that we can abstract both in a single formalism able to express both: syntax and semantics. In this way, it would achieve natural ‘semantics’ as full compiler verification framework in Coq.