## Section: Scientific Foundations

### Higher-Order Functional Languages

Participants : Sylvie Boldo, Évelyne Contejean, Jean-Christophe Filliâtre, Guillaume Melquiond, Christine Paulin-Mohring.

Higher-order strongly typed programming languages such as Objective Caml help improving the quality of software development. Static typing automatically detects possible execution errors. Higher-order functions, polymorphism, modules and functors are powerful tools for the development of generic reusable libraries. Our general goal is to enrich such a software environment with a language of annotations as well as libraries for datatypes, abstract notions and associated theorems which can express logical properties of programs and ease the possibility to automatically and interactively develop proofs of correctness of the programs.

In order to reach this goal, we have explored different directions.

#### Developing correct functional programs

Dependent types provide a powerful language for building programs
that are correct by construction. In the language underlying the *Coq*
proof assistant, it is possible to introduce the type of even numbers,
or the type of sorted arrays of size n , or the type of correct
compilers.

However for the type-checking to remain decidable, the program itself needs to contain many extra informations which are only used for correctness. This leads to two problems: the first one is how to write such programs in a natural way (we want to mainly describe the algorithm and let proof strategies find most of the correctness part); the second one is how to compute efficiently with these programs.

The first problem has been addressed by M. Sozeau who proposes an
extension of the *Coq* input language for building
programs [105] . The solution is similar to the
mechanism of subset types and Type Checking Conditions in PVS but a *Coq*
proof term is built and is checked by the *Coq* kernel.
We are also working on extending the source language of *Coq* to support
common abstractions of high-level functional languages like Haskell.
M. Sozeau developed in collaboration with N. Oury a system of Type
Classes in *Coq* [104] which gives overloading in
programs and proofs and facilitates the development of generic tactics.

The second problem has been addressed in the *Coq* proof assistant by
providing an extraction mechanism from *Coq* terms to purely functional
programs (in Ocaml or Haskell) which are correct by
construction. During his PhD thesis, P. Letouzey designed and
implemented a new extraction mechanism for the *Coq*
system [93] , [94] , much more
powerful than the old version and together with J.-C.
Filliâtre used it to verify Ocaml finite sets libraries
based on balanced trees [6] .

This extraction mechanism is an original feature for the *Coq* system,
and has been used by several teams around the world in order to get
efficient certified code [91] .

#### Using Type theory to model complex programs

We are using the capability of the *Coq* system to model both
computation and deduction in order to explore different classes of
applications. These examples involve the development of large reusable
*Coq* libraries and suggest domain-specific specification and proof
strategies.

##### Randomized algorithms

C. Paulin in collaboration with Ph. Audebaud from ENS Lyon, proposed a
method for modeling probabilistic programs in *Coq* . The method is
based on a monadic interpretation of probabilistic programs as
probability measures. A large *Coq* library has been developed and made
publicly available. It contains an axiomatisation of the real interval
[0, 1] , a definition of distributions and general rules for
approximating the probability that a program satisfies a
given property.

##### Floating-point programs

Many industrial programs (weather forecasts, plane trajectories, simulations...) use floating-point computations, typically double precision floating-point numbers [106] . Even if each computation is as good as it can be (except for elementary functions like sine, or exponential), the final result may be very wrong with no warnings, or the program will produce unexpected behaviors (like division by zero). This is the reason why guarantees should be provided to the user. We mean to guarantee for example that, for all or part of the possible inputs, the result obtained is correct (or near enough) and that no exceptional behavior will occur [57] .

We now have a methodology to perform formal verification of
floating-point C programs. It extends the *Why* platform with new
annotations specific to floating-point arithmetic. This technique is
very flexible as both non-specialists and floating-point experts will
be able to express the properties they assume the program to fulfil,
directly on the source code. The generated VCs are for
example “there is no overflow” or “the final error is less
than...” [1] .

##### Certification of tools

Certifying the result of tools for analysing programs is a good
challenge in the domain of proofs of higher-order functional programs.
We obtained several results concerning formal proofs in *Coq*
corresponding to automated deduction. These results are described in
Section
3.3 .

We have also started a project for the modeling and proof of the correctness of a compiler for the Lustre synchronous language. Our goal is to show the feasability of the certification using formal proofs of the compiler used in the new version of Scade developed by Esterel Technologies.