Section: Scientific Foundations
Formal proofs
Coq is one of the most popular proof assistant, in the academia and in the industry. Based on the Calculus of Inductive Constructions, Coq has three kinds of basic entities: objects are used for computations (data, programs, proofs are objects); types express properties of objects; kinds categorize types by their logical structure. Coq's type checker can decide whether a given object satisfies a given type, and if a given type has a logical structure expressed by a given kind. Because it is possible to (uniformly) define inductive types such as lists, dependent types such as lists-of-length-n, parametric types such as lists-of-something, inductive properties such as (evenn) for some natural number n , etc, writing small specifications in Coq is an easy task. Writing proofs is a harder (non-automatable) task that must be done by the user with the help of tactics. Automating proofs when possible is a necessary step for dissemination of these techniques, as is scaling up. These are the problems we are interested in.
Modeling in Coq is not always as easy as argued: Coq identifies expressions up to computation. Identifying two lists of identical content but respective lengths m + n and n + m is no problem if m and n are given integers, but does not work if m and n are unknowns, since n + m = m + n is a valid theorem of arithmetic which cannot be proved by mere computation. It follows that the statement reverse(l::l') = reverse(l')::reverse(l) is not typable, :: standing for appending two lists. This problem that seemingly innocent statements cannot be written in Coq because they do not type-check has been considered a major open problem for years. Blanqui, Jouannaud and Strub have recently developed Coq modulo Theories , in which computations do not operate only on closed terms (as are 1 + 2 and 2 + 1 ) but on open expressions of a decidable theory (as is n + m = m + n in Presburger arithmetic). This preliminary work addresses three problems at once: decidable goals become solved automatically by a program taken from the shelves; writing specifications and proofs becomes easier and closer to the mathematical practice; assuming that calls to a decision procedure return a proof certificate in case of success, the correctness of a Coq proof now results from type checking the proof as well as the various certificates generated along the proof. Trusting Coq becomes incremental, resulting from trusting each certificate checker when added in turn to Coq's kernel. The development of this new paradigm is our first research challenge here.
Scaling up is yet another challenge. Modeling a large, complex software is a hard task which has been addressed within the Coq community in two different ways. By developing a module system for Coq in the OCaML style, which makes it possible to modularize proof developments and hence to develop modular libraries. By developing a methodology for modeling real programs and proving their properties with Coq. This methodology allows to translate a JavaCard (tool Caduceus) or C (tool FRAMA-C) program into an ML-like program. The correctness of this first step is ensured by proving in Coq verification conditions generated along the translation. The correctness of the ML-like program annotated by the user is then done by Coq via another tool called Why. This methodology and the associated tools are developed by the INRIA project PROVAL in association with CEA. Part of our second challenge is to reuse these tools to prove properties at the source code level of programs used in an embedded application. As part of this effort, we are interested in the development of termination tools and automatic provers, in particular an SMT prover which is indeed complementary of our first challenge. The second part of the challenge is to ensure that these properties are still satisfied by the machine code executed on the embedded cpu. Here, we are going to rely on a different technology, certified compilers, and reuse the certified compilers from CLight to ARM or PowerPC developped in the COMPCERT INRIA project. We will be left with the development of certified compilers from source languages which are frequently used for developping embedded applications into CLight. These languages are either variants of C, or languages for the description of automata with timers in the case of Program Logic Controllers.
Our last challenge is to rely on certified tools only. In particular, we decided to certify in Coq all extensions of Coq developped in the project: the core logic of CoqMT has been certified with Coq. The most critical parts of the simulator will also be certified. As for compilers, there are two ways to certify tools: either, the code is proved correct, or it outputs a certificate that can be checked. The second approach demands less man-power, and has the other advantage to be compatible with the use of tools taken from the shelves, provided these tools are open-source since they must be equipped with a mechanism for generating certificates. This is the approach we will favour for the theories to be used in CoqMT, as well as for the SMT prover to be developped. For the simulator SimSoC itself, we shall probably combine both approaches.
