Thomas Letan's Blog - coq

Implementing an Echo Server in Coq with coqffi.1.0.0

December 10, 2020

Implementing an Echo Server in Coq with `coqffi.1.0.0`

In this article, we will demonstrate how coqffi can be used to implement an echo server, i.e., a TCP server which sends back any input it receives from its clients. In addition to coqffi, you will need to install coq-simple-io. The latter is available in the released repository of the Opam Coq Archive .

opam install coq-coqffi coq-simple-io

Besides, you can download the source tree presented in this article if you want to try to read the source directly, or modify it to your taste.

Project Layout

Before diving too much into the implementation of our echo server, we first give an overview of the resulting project’s layout. Since we aim at implementing a program, we draw our inspiration from the idiomatic way of organizing a OCaml project.

We have three directories at the root of the project.

ffi/ contains the low-level OCaml code: It provides an OCaml library (ffi), and a Coq theory (FFI) which gathers the FFI modules generated by coqffi.
src/ contains the Coq implementation of our echo server: It provides a Coq theory (Echo) which depends on the FFI theory the SimpleIO theory of coq-simple~io. This theory provides the implementation of our echo server in Coq.
bin/ contains the pieces of code to get an executable program: It contains a Coq module (echo.v) which configures and uses the extraction mechanism to generate an OCaml module (echo.ml). This OCaml module can be compiled to get an executable program.

Note that we could have decided to only have one Coq theory. We could also have added a fourth directory (theories/) for formal verification specific code, but this is out of the scope of this tutorial.

Overall, we use dune to compile and compose the different parts of the echo server. dune has a native —yet unstable at the time of writing— support for building Coq projects, with very convenient stanzas like coq.theory and coq.extraction.

The following graph summarizes the dependencies between each component (plain arrows symbolize software dependencies).

The echo server dependency graph. Dashed boxes are generated.

We enable Coq-related stanza with (using coq 0.2) in the dune-project. file.

(lang dune 2.7)
(using coq 0.2)

The rest of this tutorial proceeds by diving into each directory.

FFI Bindings

Our objective is to implement an echo server, i.e., a server which (1) accepts incoming connections, and (2) sends back any incoming messages. We will consider two classes of effects. One is related to creating and manipulating TCP sockets. The other is dedicated to process management, more precisely to be able to fork when receiving incoming connections.

Therefore, the ffi library will provide two modules. Likewise, the FFI theory will provide two analogous modules generated by coqffi.

In the ffi/ directory, we add the following stanza to the dune file.

(library
  (name ffi)
  (libraries unix))

dune will look for any .ml and .mli files within the directory and will consider they belong to the ffi library. We use the unix library to implement the features we are looking for.

Then, we add the following stanza to the dune file of the ffi/ directory.

(coq.theory
  (name FFI))

This tells dune to look for .v file within the ffi/ directory, in order to build them with Coq. A nice feature of dune is that if we automatically generate Coq files, they will be automatically “attached” to this theory.

Sockets

Sockets are boring. The following OCaml module interface provides the necessary type and functions to manipulate them.

type socket_descr

val open_socket : string -> int -> socket_descr
val listen : socket_descr -> unit
val recv : socket_descr -> string
val send : socket_descr -> string -> int
val accept_connection : socket_descr -> socket_descr
val close_socket : socket_descr -> unit

Our focus is how to write the interface modules for coqffi. Since the object of this tutorial is not the implementation of an echo server in itself, the implementation details of the ffi library will not be discussed, but is provided at the end of this article.

dune generates .cmi files for the .mli files of our library, and provides the necessary bits to easily locate them. Besides, the action stanza can be used here to tell to dune how to generate the module Socket.v from file.cmi. We add the following entry to ffi/dune.

(rule
  (target Socket.v)
  (action (run coqffi %{cmi:socket} -o %{target})))

We call coqffi without any feature-related command-line argument, which means only the simple-io feature is enabled. As a consequence, the socket_descr type is axiomatized in Coq, and in addition to a MonadSocket monad, coqffi will generate an instance for this monad for the IO monad of coq-simple-io.

The stanza generates the following Coq module.

(* This file has been generated by coqffi. *)

Set Implicit Arguments.
Unset Strict Implicit.
Set Contextual Implicit.
Generalizable All Variables.
Close Scope nat_scope.

From CoqFFI Require Export Extraction.
From SimpleIO Require Import IO_Monad.

Axiom socket_descr : Type.

Extract Constant socket_descr => "Ffi.Socket.socket_descr".

(** * Impure Primitives *)

(** ** Monad Definition *)

Class MonadSocket (m : Type -> Type) : Type :=
  { open_socket : string -> i63 -> m socket_descr
  ; listen : socket_descr -> m unit
  ; recv : socket_descr -> m string
  ; send : socket_descr -> string -> m i63
  ; accept_connection : socket_descr -> m socket_descr
  ; close_socket : socket_descr -> m unit
  }.

(** ** [IO] Instance *)

Axiom io_open_socket : string -> i63 -> IO socket_descr.
Axiom io_listen : socket_descr -> IO unit.
Axiom io_recv : socket_descr -> IO string.
Axiom io_send : socket_descr -> string -> IO i63.
Axiom io_accept_connection : socket_descr -> IO socket_descr.
Axiom io_close_socket : socket_descr -> IO unit.

Extract Constant io_open_socket
  => "(fun x1 x2 k__ -> k__ ((Ffi.Socket.open_socket x1 x2)))".
Extract Constant io_listen => "(fun x1 k__ -> k__ ((Ffi.Socket.listen x1)))".
Extract Constant io_recv => "(fun x1 k__ -> k__ ((Ffi.Socket.recv x1)))".
Extract Constant io_send
  => "(fun x1 x2 k__ -> k__ ((Ffi.Socket.send x1 x2)))".
Extract Constant io_accept_connection
  => "(fun x1 k__ -> k__ ((Ffi.Socket.accept_connection x1)))".
Extract Constant io_close_socket
  => "(fun x1 k__ -> k__ ((Ffi.Socket.close_socket x1)))".

Instance IO_MonadSocket : MonadSocket IO :=
  { open_socket := io_open_socket
  ; listen := io_listen
  ; recv := io_recv
  ; send := io_send
  ; accept_connection := io_accept_connection
  ; close_socket := io_close_socket
  }.

(* The generated file ends here. *)

Process Management

In order to avoid a client to block the server by connecting to it without sending anything, we can fork a new process for each client.

type identity = Parent of int | Child

val fork : unit -> identity

This time, the proc.mli module interface introduces a transparent type, /i.e./, it also provides its definition. This is a good use case for the transparent-types feature of coqffi. In the stanza for generating Proc.v, we enable it with the -ftransparent-types command-line argument, like this.

(rule
  (target Proc.v)
  (action (run coqffi -ftransparent-types %{cmi:proc} -o %{target})))

which generates the following Coq module.

(* This file has been generated by coqffi. *)

Set Implicit Arguments.
Unset Strict Implicit.
Set Contextual Implicit.
Generalizable All Variables.
Close Scope nat_scope.

From CoqFFI Require Export Extraction.
From SimpleIO Require Import IO_Monad.

Inductive identity : Type :=
| Parent (x0 : i63) : identity
| Child : identity.

Extract Inductive identity => "Ffi.Proc.identity"
  [ "Ffi.Proc.Parent" "Ffi.Proc.Child" ].

(** * Impure Primitives *)

(** ** Monad Definition *)

Class MonadProc (m : Type -> Type) : Type := { fork : unit -> m identity
                                             }.

(** ** [IO] Instance *)

Axiom io_fork : unit -> IO identity.

Extract Constant io_fork => "(fun x1 k__ -> k__ ((Ffi.Proc.fork x1)))".

Instance IO_MonadProc : MonadProc IO := { fork := io_fork
                                        }.

(* The generated file ends here. *)

We now have everything we need to implement an echo server in Coq.

Implementing an Echo Server

Our implementation will be part of a dedicated Coq theory, called Echo. This is done easily a dune file in the src/ directory, with the following content.

(coq.theory
  (name Echo)
  (theories FFI))

In the rest of this section, we will discuss the content of the unique module of this theory. Hopefully, readers familiar with programming impurity by means of monads will not find anything particularly surprising here.

Let us start with the inevitable sequence of import commands. We use the Monad and MonadFix typeclasses of ExtLib, and our FFI modules from the FFI theory we have previously defined.

From ExtLib Require Import Monad MonadFix.
From FFI Require Import Proc Socket.

Letting Coq guess the type of unintroduced variables using the ` annotation (e.g., in presence of `{Monad m}, Coq understands m is of type Type -> Type) is always nice, so we enable it.

Generalizable All Variables.

We enable the monad notation provided by ExtLib. In this article, we prefer the let* notation (as recently introduced by OCaml) over the <- notation of Haskell, but both are available.

Import MonadLetNotation.
Open Scope monad_scope.

Then, we define a notation to be able to define local, monadic recursive functions using the mfix combinator of the MonadFix typeclass.

Notation "'let_rec*' f x ':`' p 'in' q" :`
  (let f :` mfix (fun f x `> p) in q)
    (at level 61, x pattern, f name, q at next level, right associativity).

Note that mfix does /not/ check whether or not the defined function will terminate (contrary to the fix keyword of Coq). This is fortunate because in our case, we do not want our echo server to converge, but rather to accept an infinite number of connections.

We can demonstrate how this notation can be leveraged by defining a generic TCP server, parameterized by a handler to deal with incoming connections.

Definition tcp_srv `{Monad m, MonadFix m, MonadProc m, MonadSocket m}
    (handler : socket_descr -> m unit)
  : m unit :=
  let* srv := open_socket "127.0.0.1" 8888 in
  listen srv;;

  let_rec* tcp_aux _ :=
    let* client := accept_connection srv in
    let* res := fork tt in
    match res with
    | Parent _ => close_socket client >>= tcp_aux
    | Child =>  handler client
    end
  in

  tcp_aux tt.

The handler for the echo server is straightforward: it just reads incoming bytes from the socket, sends it back, and closes the socket.

Definition echo_handler `{Monad m, MonadSocket m} (sock : socket_descr)
  : m unit :=
  let* msg := recv sock in
  send sock msg;;
  close_socket sock.

Composing our generic TCP server with our echo handler gives us an echo server.

Definition echo_server `{Monad m, MonadFix m, MonadProc m, MonadSocket m}
  : m unit :=
  tcp_srv echo_handler.

Because coqffi has generated typeclasses for the impure primitives of proc.mli and socket.mli, echo_server is polymorphic, and can be instantiated for different monads. When it comes to extracting our program, we will generally prefer the IO monad of coq-simple-io. But we could also imagine verifying the client handler with FreeSpec, or the generic TCP server with Interaction Trees (which support diverging computations). Overall, we can have different verification strategies for different parts of our program, by leveraging the most relevant framework for each part, yet being able to extract it in an efficient form.

The next section shows how this last part is achieved using, once again, a convenient stanza of dune.

Extracting and Building an Executable

The 0.2 version of the Coq-related stanzas of dune provides the coq.extraction stanza, which can be used to build a Coq module expected to generate ml files.

In our case, we will write bin/echo.v to extract the echo_server in a echo.ml module, and uses the executable stanza of dune to get an executable from this file. To achieve this, the bin/dune file simply requires these two stanzas.

(coq.extraction
  (prelude echo)
  (theories Echo)
  (extracted_modules echo))

(executable
  (name echo)
  (libraries ffi))

We are almost done. We now need to write the echo.v module, which mostly consists of (1) providing a MonadFix instance for the IO monad, (2) using the IO.unsafe_run function to escape the IO monad, (3) calling the Extraction command to wrap it up.

From Coq Require Extraction.
From ExtLib Require Import MonadFix.
From SimpleIO Require Import SimpleIO.
From Echo Require Import Server.

Instance MonadFix_IO : MonadFix IO :=
  { mfix := @IO.fix_io }.

Definition main : io_unit :=
  IO.unsafe_run echo_server.

Extraction "echo.ml" main.

Since we are using the i63 type (signed 63bits integers) of the CoqFFI theory, and since i63 is implemented under the hood with Coq primitive integers, we also need to provide a Uint63 module with a of_int function. Fortunately, this module is straightforward to write.

let of_int x = x

And voilà. A call to dune at the root of the repository will build everything (Coq and OCaml alike). Starting the echo server is as simple as

dune exec bin/echo.exe

And connecting to it can be achieved with a program like telnet.

$ telnet 127.0.0.1 8888
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
hello, echo server!
hello, echo server!
Connection closed by foreign host.

Appendix

The `Socket` OCaml Module

There is not much to say, except that (as already stated) we use the Unix module to manipulate sockets, and we attach to each socket a buffer to store incoming bytes.

let buffer_size = 1024

type socket_descr = {
  fd : Unix.file_descr;
  recv_buffer : bytes;
}

let from_fd fd =
  let rbuff = Bytes.create buffer_size in
  { fd ` fd; recv_buffer ` rbuff }

let open_socket hostname port =
  let open Unix in
  let addr = inet_addr_of_string hostname in
  let fd = socket PF_INET SOCK_STREAM 0 in
  setsockopt fd SO_REUSEADDR true;
  bind fd (ADDR_INET (addr, port));
  from_fd fd

let listen sock = Unix.listen sock.fd 1

let recv sock =
  let s = Unix.read sock.fd sock.recv_buffer 0 buffer_size in
  Bytes.sub_string sock.recv_buffer 0 s

let send sock msg =
  Unix.write_substring sock.fd msg 0 (String.length msg)

let accept_connection sock =
  Unix.accept sock.fd |> fst |> from_fd

let close_socket sock = Unix.close sock.fd

The `Proc` OCaml Module

Thanks to the Unix module, the implementation is pretty straightforward.

type identity = Parent of int | Child

let fork x =
  match Unix.fork x with
  | 0 -> Child
  | x -> Parent x

coqffi.1.0.0 In A Nutshell

December 10, 2020

`coqffi.1.0.0` In A Nutshell

coq ocaml coqffi

For each entry of a cmi file (a compiled mli file), coqffi tries to generate an equivalent (from the extraction mechanism perspective) Coq definition. In this article, we walk through how coqffi works.

Note that we do not dive into the vernacular commands coqffi generates. They are of no concern for users of coqffi.

Getting Started

Requirements

The latest version of coqffi (1.0.0~beta8) is compatible with OCaml 4.08 up to 4.14, and Coq 8.12 up top 8.13. If you want to use coqffi, but have incompatible requirements of your own, feel free to submit an issue .

Installing `coqffi`

The recommended way to install coqffi is through the Opam Coq Archive , in the released repository. If you haven’t activated this repository yet, you can use the following bash command.

opam repo add coq-released https://coq.inria.fr/opam/released

Then, installing coqffi is as simple as

opam install coq-coqffi

You can also get the source from the upstream git repository . The README provides the necessary pieces of information to build it from source.

Additional Dependencies

One major difference between Coq and OCaml is that the former is pure, while the latter is not. Impurity can be modeled in pure languages, and Coq does not lack of frameworks in this respect. coqffi currently supports two of them: coq-simple-io and FreeSpec . It is also possible to use it with Interaction Trees , albeit in a less direct manner.

Primitive Types

coqffi supports a set of primitive types, i.e., a set of OCaml types for which it knows an equivalent type in Coq. The list is the following (the Coq types are fully qualified in the table, but not in the generated Coq module as the necessary Import statements are generated too).

OCaml type	Coq type
`bool`	`Coq.Init.Datatypes.bool`
`char`	`Coq.Strings.Ascii.ascii`
`int`	`CoqFFI.Data.Int.i63`
`'a list`	`Coq.Init.Datatypes.list a`
`'a Seq.t`	`CoqFFI.Data.Seq.t`
`'a option`	`Coq.Init.Datatypes.option a`
`('a, 'e) result`	`Coq.Init.Datatypes.sum`
`string`	`Coq.Strings.String.string`
`unit`	`Coq.Init.Datatypes.unit`
`exn`	`CoqFFI.Exn`

The i63 type is introduced by the CoqFFI theory to provide signed primitive integers to Coq users. They are implemented on top of the (unsigned) Coq native integers introduced in Coq 8.13. The i63 type will be deprecated once the support for signed primitive integers is implementedThis is actually one of the sources of incompatibility of coqffi with most recent versions of Coq. .

When processing the entries of a given interface model, coqffi will check that they only use these types, or types introduced by the interface module itself.

Sometimes, you may encounter a situation where you have two interface modules b.mli and b.mli, such that b.mli uses a type introduced in a.mli. To deal with this scenario, you can use the --witness flag to generate A.v. This will tell coqffi to also generate A.ffi; this file can then be used when generating B.v thanks to the -I option. Furthermore, for B.v to compile the --require option needs to be used to ensure the A Coq library (A.v) is required.

To give a more concrete example, given ~a.mli~

type t

and b.mli

type a = A.t

To generate A.v, we can use the following commands:

ocamlc a.mli
coqffi --witness -o A.v a.cmi

Which would generate the following axiom for t.

Axiom t : Type.

Then, generating B.v can be achieved as follows:

ocamlc b.mli
coqffi -I A.ffi -ftransparent-types -r A -o B.v b.cmi

which results in the following output for v:

Require A.

Definition u : Type := A.t.

Code Generation

coqffi distinguishes five types of entries: types, pure values, impure primitives, asynchronous primitives, exceptions, and modules. We now discuss how each one of them is handled.

Types

By default, coqffi generates axiomatized definitions for each type defined in a .cmi file. This means that type t becomes Axiom t : Type. Polymorphism is supported, i.e., type 'a t becomes Axiom t : forall (a : Type), Type.

It is possible to provide a “model” for a type using the coq_model annotation, for instance, for reasoning purposes. That is, we can specify that a type is equivalent to a list.

type 'a t [@@coq_model "list"]

This generates the following Coq definition.

Definition t : forall (a : Type), Type := list.

It is important to be careful when using the =coq_model= annotation. More precisely, the fact that t is a list in the “Coq universe” shall not be used while the implementation phase, only the verification phase.

Unnamed polymorphic type parameters are also supported. In presence of such parameters, coqffi will find it a name that is not already used. For instance,

type (_, 'a) ast

becomes

Axiom ast : forall (b : Type) (a : Type), Type.

Finally, coqffi has got an experimental feature called transparent-types (enabled by using the -ftransparent-types command-line argument). If the type definition is given in the module interface, then coqffi tries to generate an equivalent definition in Coq. For instance,

type 'a llist =
  | LCons of 'a * (unit -> 'a llist)
  | LNil

becomes

Inductive llist (a : Type) : Type :=
| LCons (x0 : a) (x1 : unit -> llist a) : llist a
| LNil : llist a.

Mutually recursive types are supported, so

type even = Zero | ESucc of odd
and odd = OSucc of even

becomes

Inductive odd : Type :=
| OSucc (x0 : even) : odd
with even : Type :=
| Zero : even
| ESucc (x0 : odd) : even.

Besides, coqffi supports alias types, as suggested in this write-up when we discuss witness files.

The transparent-types feature is experimental, and is currently limited to variant types. It notably does not support records. Besides, it may generate incorrect Coq types, because it does not check whether or not the positivity condition is satisfied.

Pure values

coqffi decides whether or not a given OCaml value is pure or impure with the following heuristics:

Constants are pure
Functions are impure by default
Functions with a coq_model annotation are pure
Functions marked with the pure annotation are pure
If the pure-module feature is enabled (-fpure-module), then synchronous functions (which do not live inside the ~Lwt~ monad) are pure

Similarly to types, coqffi generates axioms (or definitions if the coq_model annotation is used) for pure values. Then,

val unpack : string -> (char * string) option [@@pure]

becomes

Axiom unpack : string -> option (ascii * string).

Polymorphic values are supported.

val map : ('a -> 'b) -> 'a list -> 'b list [@@pure]

becomes

Axiom map : forall (a : Type) (b : Type), (a -> b) -> list a -> list b.

Again, unnamed polymorphic typse are supported, so

val ast_to_string : _ ast -> string [@@pure]

becomes

Axiom ast_to_string : forall (a : Type), string.

Impure Primitives

coqffi reserves a special treatment for /impure/ OCaml functions. Impurity is usually handled in pure programming languages by means of monads, and coqffi is no exception to the rule.

Given the set of impure primitives declared in an interface module, coqffi will (1) generate a typeclass which gathers these primitives, and (2) generate instances of this typeclass for supported backends.

We illustrate the rest of this section with the following impure primitives.

val echo : string -> unit
val scan : unit -> string

where echo allows writing something the standard output, and scan to read the standard input.

Assuming the processed module interface is named console.mli, the following Coq typeclass is generated.

Class MonadConsole (m : Type -> Type) := { echo : string -> m unit
                                         ; scan : unit -> m string
                                         }.

Using this typeclass and with the additional support of an additional Monad typeclass, we can specify impure computations which interacts with the console. For instance, with the support of ExtLib, one can write.

Definition pipe `{Monad m, MonadConsole m} : m unit :=
  let* msg := scan () in
  echo msg.

There is no canonical way to model impurity in Coq, but over the years several frameworks have been released to tackle this challenge.

coqffi provides three features related to impure primitives.

`simple-io`

When this feature is enabled, coqffi generates an instance of the typeclass for the =IO= monad introduced in the coq-simple-io package

Axiom io_echo : string -> IO unit.
Axiom io_scan : unit -> IO string.

Instance IO_MonadConsole : MonadConsole IO := { echo := io_echo
                                              ; scan := io_scan
                                              }.

It is enabled by default, but can be disabled using the -fno-simple-io command-line argument.

`interface`

When this feature is enabled, coqffi generates an inductive type which describes the set of primitives available, to be used with frameworks like FreeSpec or Interactions Trees .

Inductive CONSOLE : Type -> Type :=
| Echo : string -> CONSOLE unit
| Scan : unit -> CONSOLE string.

Definition inj_echo `{Inject CONSOLE m} (x0 : string) : m unit :=
  inject (Echo x0).

Definition inj_scan `{Inject CONSOLE m} (x0 : unit) : m string :=
  inject (Scan x0).

Instance Inject_MonadConsole `{Inject CONSOLE m} : MonadConsole m :=
  { echo := inj_echo
  ; scan := inj_scan
  }.

Providing an instance of the form forall i, Inject i M is enough for your monad M to be compatible with this featureSee for instance how FreeSpec implements it ). .

`freespec`

When this feature in enabled, coqffi generates a semantics for the inductive type generated by the interface feature.

Axiom unsafe_echo : string -> unit.
Axiom unsafe_scan : uint -> string.

Definition console_unsafe_semantics : semantics CONSOLE :=
  bootstrap (fun a e =>
    local match e in CONSOLE a return a with
          | Echo x0 => unsafe_echo x0
          | Scan x0 => unsafe_scan x0
          end).

Asynchronous Primitives

coqffi also reserves a special treatment for asynchronous primitives —i.e., functions which live inside the Lwt monad— when the lwt feature is enabled.

The treatment is very analogous to the one for impure primitives: (1) a typeclass is generated (with the _Async suffix), and (2) an instance for the Lwt monad is generated. Besides, an instance for the “synchronous” primitives is also generated for Lwt. If the interface feature is enabled, an interface datatype is generated, which means you can potentially use Coq to reason about your asynchronous programs (using FreeSpec and alike, although the interleaving of asynchronous programs in not yet supported in FreeSpec).

By default, the type of the Lwt monad is Lwt.t. You can override this setting using the --lwt-alias option. This can be useful when you are using an alias type in place of Lwt.t.

Exceptions

OCaml features an exception mechanism. Developers can define their own exceptions using the exception keyword, whose syntax is similar to the constructors’ definition. For instance,

exception Foo of int * bool

introduces a new exception Foo which takes two parameters of type int and bool. Foo (x, y) constructs of value of type exn.

For each new exception introduced in an OCaml module, coqffi generates (1) a so-called “proxy type,” and (2) conversion functions to and from this type.

Coming back to our example, the “proxy type” generates by coqffi is

Inductive FooExn : Type :=
| MakeFooExn (x0 : i63) (x1 : bool) : FooExn.

Then, coqffi generates conversion functions.

Axiom exn_of_foo : FooExn -> exn.
Axiom foo_of_exn : exn -> option FooExn.

Besides, coqffi also generates an instance for the Exn typeclass provided by the CoqFFI theory:

Instance FooExn_Exn : Exn FooExn :=
  { to_exn := exn_of_foo
  ; of_exn := foo_of_exn
  }.

Under the hood, exn is an extensible datatype , and how coqffi supports it will probably be generalized in future releases.

Finally, coqffi has a minimal support for functions which may raise exceptions. Since OCaml type system does not allow to identify such functions, they need to be annotated explicitly, using the =may_raise= annotation. In such a case, coqffi will change the return type of the function to use the =sum= Coq inductive type.

For instance,

val from_option : 'a option -> 'a [@@may_raise] [@@pure]

becomes

Axiom from_option : forall (a : Type), option a -> sum a exn.

Modules

Lastly, coqffi supports OCaml modules described within mli files, when they are specified as module T : sig ... end. For instance,

module T : sig
  type t

  val to_string : t -> string [@@pure]
end

becomes

Module T.
  Axiom t : Type.

  Axiom to_string : t -> string.
End T.

As of now, the following construction is unfortunately not supported, and will be ignored by coqffi:

module S = sig
  type t

  val to_string : t -> string [@@pure]
end

module T : S

Moving Forward

coqffi comes with a comprehensive man page. In addition, the interested reader can proceed to the next article of this series, which explains how coqffi can be used to easily implement an echo server in Coq.

Pattern Matching on Types and Contexts

August 28, 2020

Pattern Matching on Types and Contexts

coq

In the a previous article of our series on Ltac, we have shown how tactics allow for constructing Coq terms incrementally. Ltac programs (“proof scripts”) generate terms, and the shape of said terms can be very different regarding the initial context. For instance, induction x will refine the current goal by using an inductive principle dedicated to the type of x.

This is possible because Ltac allows for pattern matching on types and contexts. In this article, we give a short introduction on this feature of key importance.

To `lazymatch` or to `match`

Gallina provides one pattern matching construction, whose semantics is always the same: for a given term, the first pattern to match will always be selected. On the contrary, Ltac provides several pattern matching constructions with different semantics. This key difference has probably been motivated because Ltac is not a total language: a tactic may not always succeed.

Ltac programmers can use match or lazymatch. One the one hand, with match, if one pattern matches, but the branch body fails, Coq will backtrack and try the next branch. On the other hand, lazymatch will stop with an error.

So, for instance, the two following tactics will print two different messages:

Ltac match_failure :=
  match goal with
  | _
    => fail "fail in first branch"
  | _
    => fail "fail in second branch"
  end.

Ltac lazymatch_failure :=
  lazymatch goal with
  | _
    => fail "fail in first branch"
  | _
    => fail "fail in second branch"
  end.

We can try that quite easily by starting a dumb goal (eg. Goal (True).) and call our tactic. For match_failure, we get:

Ltac call to "match_failure" failed.
Error: Tactic failure: fail in second branch.

On the other hand, for lazymatch_failure, we get:

Ltac call to "match_failure'" failed.
Error: Tactic failure: fail in first branch.

Moreover, pattern matching allows for matching over patterns, not just constants. Here, Ltac syntax differs from Gallina’s. In Gallina, if a variable name is used in a pattern, Gallina creates a new variable in the scope of the related branch. If a variable with the same name already existed, it is shadowed. On the contrary, in Ltac, using a variable name as-is in a pattern implies an equality check.

To illustrate this difference, we can take the example of the following tactic.

Ltac successive x y :=
  lazymatch y with
  | S x => idtac
  | _ => fail
  end.

successive x y will fail if y is not the successor of x. On the contrary, the “syntactically equivalent” function in Gallina will exhibit a totally different behavior.

Definition successor (x y : nat) : bool :=
  match y with
  | S x => true
  | _ => false
  end.

Here, the first branch of the pattern match is systematically selected when y is not O, and in this branch, the argument x is shadowed by the predecessor of y.

For Ltac to adopt a behavior similar to Gallina, the ? prefix shall be used. For instance, the following tactic will check whether its argument has a known successor, prints it if it does, or fail otherwise.

Ltac print_pred_or_zero x :=
  match x with
  | S ?x => idtac x
  | _ => fail
  end.

On the one hand, print_pred_or_zero 3 will print 2. On the other hand, if there exists a variable x : nat in the context, calling print_pred_or_zero x will fail, since the exact value of x is not known.

Pattern Matching on Types with `type of`

The type of operator can be used in conjunction to pattern matching to generate different terms according to the type of a variable. We could leverage this to reimplement induction for instance.

As an example, we propose the following not_nat tactic which, given an argument x, fails if x is of type nat.

Ltac not_nat x :=
  lazymatch type of x with
  | nat => fail "argument is of type nat"
  | _ => idtac
  end.

With this definition, not_nat true succeeds since true is of type bool, and not_nat O since O encodes $0$ in nat.

We can also use the ? prefix to write true pattern. For instance, the following tactic will fail if the type of its supplied argument has at least one parameter.

Ltac not_param_type x :=
  lazymatch type of x with
  | ?f ?a => fail "argument is of type with parameter"
  | _ => idtac
  end.

Both not_param_type (@nil nat) of type list nat and @eq_refl nat 0 of type 0 = 0 fail, but not_param_type 0 of type nat succeeds. *)

Pattern Matching on the Context with `goal`

Lastly, we discuss how Ltac allows for inspecting the context (i.e., the hypotheses and the goal) using the goal keyword.

For instance, we propose a naive implementation of the subst tactic as follows.

Ltac subst' :=
  repeat
    match goal with
    | H :  ?x = _ |- context[?x]
      => repeat rewrite H; clear H
    end.

With goal, patterns are of the form H : (pattern), ... |- (pattern).

At the left side of |-, we match on hypotheses. Beware that contrary to variable names in pattern, hypothesis names behaves as in Gallina (i.e., fresh binding, shadowing, etc.). In the branch, we are looking for equations, i.e., a hypothesis of the form ?x = _.
At the right side of |-, we match on the goal.

In both cases, Ltac makes available an interesting operator, context[(pattern)], which is satisfied if (pattern) appears somewhere in the object we are pattern matching against. So, the branch of the match reads as follows: we are looking for an equation H which specifies the value of an object x which appears in the goal. If such an equation exists, subst' tries to rewrite x as many times as possible.

This implementation of subst' is very fragile, and will not work if the equation is of the form _ = ?x, and it may behave poorly if we have “transitive equations”, such as there exists hypotheses ?x = ?y and ?y = _. Motivated readers may be interested in proposing a more robust implementation of subst'.

Ltac is an Imperative Metaprogramming Language

August 28, 2020

Ltac is an Imperative Metaprogramming Language

coq

Coq is often depicted as an interactive proof assistant, thanks to its proof environment. Inside the proof environment, Coq presents the user a goal, and said user solves said goal by means of tactics which describes a logical reasoning. For instance, to reason by induction, one can use the induction tactic, while a simple case analysis can rely on the destruct or case_eq tactics, etc. It is not uncommon for new Coq users to be introduced to Ltac, the Coq default tactic language, using this proof-centric approach. This is not surprising, since writing proofs remains the main use case for Ltac. In practice, though, this discourse remains an abstraction which hides away what actually happens under the hood when Coq executes a proof script.

To really understand what Ltac is about, we need to recall ourselves that Coq kernel is mostly a type checker. A theorem statement is expressed as a “type” (which lives in a dedicated sort called Prop), and a proof of this theorem is a term of this type, just like the term S (S O) ( $2$ ) is of type nat. Proving a theorem in Coq requires to construct a term of the type encoding said theorem, and Ltac allows for incrementally constructing this term, one step at a time.

Ltac generates terms, therefore it is a metaprogramming language. It does it incrementally, by using primitives to modifying an implicit state, therefore it is an imperative language. Henceforth, it is an imperative metaprogramming language.

To summarize, a goal presented by Coq inside the environment proof is a hole within the term being constructed. It is presented to users as:

A list of “hypotheses,” which are nothing more than the variables in the scope of the hole
A type, which is the type of the term to construct to fill the hole

We illustrate what happens under the hood of Coq executes a simple proof script. One can use the Show Proof vernacular command to exhibit this.

We illustrate how Ltac works with the following example.

Theorem add_n_O : forall (n : nat), n + O = n.
Proof.

The Proof vernacular command starts the proof environment. Since no tactic has been used, the term we are trying to construct consists solely in a hole, while Coq presents us a goal with no hypothesis, and with the exact type of our theorem, that is forall (n : nat), n + O = n.

A typical Coq course will explain to students the intro tactic allows for turning the premise of an implication into an hypothesis within the context.

C \vdash P \rightarrow Q

becomes

C,\ P \vdash Q

This is a fundamental rule of deductive reasoning, and intro encodes it. It achieves this by refining the current hole into an anonymous function. When we use

  intro n.

it refines the term

  ?Goal1

into

  fun (n : nat) => ?Goal2

The next step of this proof is to reason about induction on n. For nat, it means that to be able to prove

\forall n, \mathrm{P}\ n

we need to prove that

$\mathrm{P}\ 0$
$\forall n, \mathrm{P}\ n \rightarrow \mathrm{P}\ (S n)$

The induction tactic effectively turns our goal into two subgoals. But why is that? Because, under the hood, Ltac is refining the current goal using the nat_ind function automatically generated by Coq when nat was defined. The type of nat_ind is

  forall (P : nat -> Prop),
    P 0
    -> (forall n : nat, P n -> P (S n))
    -> forall n : nat, P n

Interestingly enough, nat_ind is not an axiom. It is a regular Coq function, whose definition is

  fun (P : nat -> Prop) (f : P 0)
      (f0 : forall n : nat, P n -> P (S n)) =>
  fix F (n : nat) : P n :=
    match n as n0 return (P n0) with
    | 0 => f
    | S n0 => f0 n0 (F n0)
    end

So, after executing

  induction n.

The hidden term we are constructing becomes

  (fun n : nat =>
     nat_ind
       (fun n0 : nat => n0 + 0 = n0)
       ?Goal3
       (fun (n0 : nat) (IHn : n0 + 0 = n0) => ?Goal4)
       n)

And Coq presents us two goals.

First, we need to prove $\mathrm{P}\ 0$ , i.e., $0 + 0 = 0$ . Similarly to Coq presenting a goal when what we are actually doing is constructing a term, the use of $=$ and $+$ (i.e., the Coq notations mechanism) hides much here. We can ask Coq to be more explicit by using the vernacular command Set Printing All to learn that when Coq presents us a goal of the form 0 + 0 = 0, it is actually looking for a term of type @eq nat (Nat.add O O) O.

Nat.add is a regular Coq (recursive) function.

  fix add (n m : nat) {struct n} : nat :=
    match n with
    | 0 => m
    | S p => S (add p m)
    end

Similarly, eq is not an axiom. It is a regular inductive type, defined as follows.

Inductive eq (A : Type) (x : A) : A -> Prop :=
| eq_refl : eq A x x

Coming back to our current goal, proving @eq nat (Nat.add 0 0) 0That is, 0 + 0 = 0 requires to construct a term of a type whose only constructor is eq_refl. eq_refl accepts one argument, and encodes the proof that said argument is equal to itself. In practice, Coq type checker will accept the term @eq_refl _ x when it expects a term of type @eq _ x y if it can reduce x and y to the same term.

Is it the case for @eq nat (Nat.add 0 0) 0? It is, since by definition of Nat.add, Nat.add 0 x is reduced to x. We can use the reflexivity tactic to tell Coq to fill the current hole with eq_refl.

  + reflexivity.

Suspicious readers may rely on Show Proof to verify this assertion.

  (fun n : nat =>
     nat_ind
       (fun n0 : nat => n0 + 0 = n0)
       eq_refl
       (fun (n0 : nat) (IHn : n0 + 0 = n0) => ?Goal4)
       n)

?Goal3 has indeed be replaced by eq_refl.

One goal remains, as we need to prove that if n + 0 = n, then S n + 0 = S n. Coq can reduce S n + 0 to S (n + 0) by definition of Nat.add, but it cannot reduce S n more than it already is.

  + cbn.

We cannot just use reflexivity here (i.e., fill the hole with eq_refl), since S (n + 0) and S n cannot be reduced to the same term.

However, at this point of the proof, we have the IHn hypothesis (i.e., the IHn argument of the anonymous function whose body we are trying to construct). The rewrite tactic allows for substituting in a type an occurrence of x by y as long as we have a proof of x = y. *)

    rewrite IHn.

Similarly to induction using a dedicated function, rewrite refines the current hole with the eq_ind_r functionAgain, not an axiom. . Replacing n + 0 with n transforms the goal into S n = S n. Here, we can use reflexivity (i.e., eq_refl) to conclude. *)

    reflexivity.

After this last tactic, the work is done. There is no more goal to fill inside the proof term that we have carefully constructed.

  (fun n : nat =>
     nat_ind
       (fun n0 : nat => n0 + 0 = n0)
       eq_refl
       (fun (n0 : nat) (IHn : n0 + 0 = n0) =>
          eq_ind_r (fun n1 : nat => S n1 = S n0) eq_refl IHn)
       n)

We can finally use Qed or Defined to tell Coq to type check this term. That is, Coq does not trust Ltac, but rather type check the term to verify it is correct. This way, in case Ltac has a bug which makes it construct an ill-formed type, at the very least Coq can reject it.

Qed.

In conclusion, tactics are used to incrementally refine hole inside a term until the latter is complete. They do it in a very specific manner, to encode certain reasoning rules.

On the other hand, the refine tactic provides a generic, low-level way to do the same thing. Knowing how a given tactic works allows for mimicking its behavior using the refine tactic.

If we take the previous theorem as an example, we can prove it using this alternative proof script.

Theorem add_n_O' : forall (n : nat), n + O = n.
Proof.
  refine (fun n => _).
  refine (nat_ind (fun n => n + 0 = n) _ _ n).
  + refine eq_refl.
  + refine (fun m IHm => _).
    refine (eq_ind_r (fun n => S n = S m) _ IHm).
    refine eq_refl.
Qed.

Mixing Ltac and Gallina for Fun and Profit

July 26, 2020

Mixing Ltac and Gallina for Fun and Profit

coq

One of the most misleading introductions to Coq is to say that “Gallina is for programs, while tactics are for proofs.” Indeed, in Coq we construct terms of given types, always. Terms encodes both programs and proofs about these programs. Gallina is the preferred way to construct programs, and tactics are the preferred way to construct proofs.

The key word here is “preferred.” We do not always need to use tactics to construct a proof term. Conversely, there are some occasions where constructing a program with tactics become handy. Furthermore, Coq actually allows for mixing together Ltac and Gallina.

In the previous article of this series, we discuss how Ltac provides two very interesting features:

With match goal with it can inspect its context
With match type of _ with it can pattern matches on types

It turns out these features are more than handy when it comes to metaprogramming (that is, the generation of programs by programs).

A Tale of Two Worlds, and Some Bridges

Constructing terms proofs directly in Gallina often happens when one is writing dependently typed definition. For instance, we can write a type-safe from_option function (inspired by this very nice write-up ) such that the option to unwrap shall be accompanied by a proof that said option contains something. This extra argument is used in the None case to derive a proof of False, from which we can derive anything.

Definition is_some {α} (x : option α) : bool :=
  match x with Some _ => true | None => false end.

Lemma is_some_None {α} (x : option α)
  : x = None -> is_some x <> true.
Proof. intros H. rewrite H. discriminate. Qed.

Definition from_option {α}
    (x : option α) (some : is_some x = true)
  : α :=
  match x as y return x = y -> α with
  | Some x => fun _ => x
  | None => fun equ => False_rect α (is_some_None x equ some)
  end eq_refl.

In from_option, we construct two proofs without using tactics:

False_rect α (is_some_None x equ some) to exclude the absurd case
eq_refl in conjunction with a dependent pattern matching (if you are not familiar with this trick: the main idea is to allow Coq to “remember” that x = None in the second branch)

We can use another approach. We can decide to implement from_option with a proof script.

Definition from_option' {α}
    (x : option α) (some : is_some x = true)
  : α.
Proof.
  case_eq x.
  + intros y _.
    exact y.
  + intros equ.
    rewrite equ in some.
    now apply is_some_None in some.
Defined.

There is a third approach we can consider: mixing Gallina terms and tactics. This is possible thanks to the ltac:() feature.

Definition from_option'' {α}
    (x : option α) (some : is_some x = true)
  : α :=
  match x as y return x = y -> α with
  | Some x => fun _ => x
  | None => fun equ => ltac:(rewrite equ in some;
                             now apply is_some_None in some)
  end eq_refl.

When Coq encounters ltac:(), it treats it as a hole. It sets up a corresponding goal, and tries to solve it with the supplied tactic.

Conversely, there exists ways to construct terms in Gallina when writing a proof script. Certain tactics take such terms as arguments. Besides, Ltac provides constr:() and uconstr:() which work similarly to ltac:(). The difference between constr:() and uconstr:() is that Coq will try to assign a type to the argument of constr:(), but will leave the argument of uconstr:() untyped.

For instance, consider the following tactic definition.

Tactic Notation "wrap_id" uconstr(x) :=
  let f := uconstr:(fun x => x) in
  exact (f x).

Both x the argument of wrap_id and f the anonymous identity function are not typed. It is only when they are composed together as an argument of exact (which expects a typed argument, more precisely of the type of the goal) that Coq actually tries to type check it.

As a consequence, wrap_id generates a specialized identity function for each specific context.

Definition zero : nat := ltac:(wrap_id 0).

The generated anonymous identity function is fun x : nat => x.

Definition empty_list α : list α := ltac:(wrap_id nil).

The generated anonymous identity function is fun x : list α => x. Besides, we do not need to give more type information about nil. If wrap_id were to be expecting a typed term, we would have to replace nil by [(@nil α)].

Beware the Automation Elephant in the Room

Proofs and computational programs are encoded in Coq as terms, but there is a fundamental difference between them, and it is highlighted by one of the axioms provided by the Coq standard library: proof irrelevance.

Proof irrelevance states that two proofs of the same theorem (i.e., two proof terms which share the same type) are essentially equivalent, and can be substituted without threatening the trustworthiness of the system. From a formal methods point of view, it makes sense. Even if we value “beautiful proofs,” we mostly want correct proofs.

The same reasoning does not apply to computational programs. Two functions of type nat -> nat -> nat are unlikely to be equivalent. For instance, add, mul or sub share the same type, but computes totally different results.

Using tactics such as auto to generate terms which do not live inside Prop is risky, to say the least. For instance,

Definition add (x y : nat) : nat := ltac:(auto).

This works, but it is certainly not what you would expect:

add = fun _ y : nat => y
     : nat -> nat -> nat

That being said, if we keep that in mind, and assert the correctness of the generated programs (either by providing a proof, or by extensively testing it), there is no particular reason not to use Ltac to generate terms when it makes sense.

Dependently typed programming can help you here. If we decorate the return type of a function with the expected properties of the result wrt. the function’s arguments, we can ensure the function is correct, and conversely prevent tactics such as auto to generate “incorrect” terms. Interested readers may refer to the dedicated series on this very website.

Proving Algebraic Datatypes are “Algebraic”

July 12, 2020

Proving Algebraic Datatypes are “Algebraic”

coq

Several programming languages allow programmers to define (potentially recursive) custom types, by composing together existing ones. For instance, in OCaml, one can define lists as follows:

type 'a list =
| Cons of 'a * 'a list
| Nil

This translates in Haskell as

data List a =
  Cons a (List a)
| Nil

In Rust as

enum List<A> {
  Cons(A, Box<List<a>>),
  Nil,
}

Or in Coq as

Inductive list a :=
| cons : a -> list a -> list a
| nil

And so forth.

Each language will have its own specific constructions, and the type systems of OCaml, Haskell, Rust and Coq —to only cite them— are far from being equivalent. That being said, they often share a common “base formalism,” usually (and sometimes abusively) referred to as algebraic datatypes. This expression is used because under the hood any datatype can be encoded as a composition of types using two operators: sum ( $+$ ) and product ( $*$ ) for types.

$a + b$ is the disjoint union of types $a$ and $b$ . Any term of $a$ can be injected into $a + b$ , and the same goes for $b$ . Conversely, a term of $a + b$ can be projected into either $a$ or $b$ .
$a * b$ is the Cartesian product of types $a$ and $b$ . Any term of $a * b$ is made of one term of $a$ and one term of $b$ (think tuples).

For an algebraic datatype, one constructor allows for defining “named tuples,” that is ad hoc product types. Besides, constructors are mutually exclusive: you cannot define the same term using two different constructors. Therefore, a datatype with several constructors is reminiscent of a disjoint union. Coming back to the $\mathrm{list}$ type, under the syntactic sugar of algebraic datatypes, we can define it as

\mathrm{list}_\alpha \equiv \mathrm{unit} + \alpha * \mathrm{list}_\alpha

where $\mathrm{unit}$ models the nil case, and $α * \mathrm{list}_\alpha$ models the cons case.

The set of types which can be defined in a language together with $+$ and $*$ form an “algebraic structure” in the mathematical sense, hence the name. It means the definitions of $+$ and $*$ have to satisfy properties such as commutativity or the existence of neutral elements. In this article, we will prove some of them in Coq. More precisely,

$+$ is commutative, that is $\forall (x, y),\ x + y = y + x$
$+$ is associative, that is $\forall (x, y, z),\ (x + y) + z = x + (y + z)$
$+$ has a neutral element, that is $\exists e_s,\ \forall x,\ x + e_s = x$
$*$ is commutative, that is $\forall (x, y),\ x * y = y * x$
$*$ is associative, that is $\forall (x, y, z),\ (x * y) * z = x * (y * z)$
$*$ has a neutral element, that is $\exists e_p,\ \forall x,\ x * e_p = x$
The distributivity of $+$ and $*$ , that is $\forall (x, y, z),\ x * (y + z) = x * y + x * z$
$*$ has an absorbing element, that is $\exists e_a,\ \forall x, \ x * e_a = e_a$

For the record, the sum ( $+$ ) and prod ( $*$ ) types are defined in Coq as follows:

Inductive sum (A B : Type) : Type :=
| inl : A -> sum A B
| inr : B -> sum A B

Inductive prod (A B : Type) : Type :=
| pair : A -> B -> prod A B

An Equivalence for `Type`

Algebraic structures come with equations expected to be true. This means there is an implicit dependency which is —to my opinion— too easily overlooked: the definition of $=$ . In Coq, = is a built-in relation that states that two terms are “equal” if they can be reduced to the same “hierarchy” of constructors. This is too strong in the general case, and in particular for our study of algebraic structures of Type. It is clear that, to Coq’s opinion, $\alpha + \beta$ is not structurally equal to $\beta + \alpha$ , yet we will have to prove they are “equivalent.”

Introducing `type_equiv`

Since = for Type is not suitable for reasoning about algebraic datatypes, we introduce our own equivalence relation, denoted ==. We say two types $\alpha$ and $\beta$ are equivalent up to an isomorphism when for any term of type $\alpha$ , there exists a counterpart term of type $\beta$ and vice versa. In other words, $\alpha$ and $\beta$ are equivalent if we can exhibit two functions $f$ and $g$ such that:

\forall (x : α),\ x = g(f(x))

\forall (y : β),\ y = f(g(y))

This translates into the following inductive type.

Reserved Notation "x == y" (at level 72).

Inductive type_equiv (α β : Type) : Prop :=
| mk_type_equiv (f : α -> β) (g : β -> α)
                (equ1 : forall (x : α), x = g (f x))
                (equ2 : forall (y : β), y = f (g y))
  : α == β
where "x == y" := (type_equiv x y).

As mentioned earlier, we prove two types are equivalent by exhibiting two functions, and proving these functions satisfy two properties. We introduce a Ltac notation to that end.

Tactic Notation "equiv" "with" uconstr(f) "and" uconstr(g)
  := apply (mk_type_equiv f g).

The tactic equiv with f and g will turn a goal of the form α == β into two subgoals to prove f and g form an isomorphism.

`type_equiv` is an Equivalence

We can prove it by demonstrating it is

Reflexive,
Symmetric, and
Transitive.

`type_equiv` is reflexive

This proof is straightforward. A type $\alpha$ is equivalent to itself because:

\forall (x : α),\ x = id(id(x))

Lemma type_equiv_refl (α : Type) : α == α.
Proof.
  now equiv with (@id α) and (@id α).
Qed.

`type_equiv` is symmetric

If $\alpha = \beta$ , then we know there exists two functions $f$ and $g$ which satisfy the expected properties. We can “swap” them to prove that $\beta == \alpha$ .

Lemma type_equiv_sym {α β} (equ : α == β) : β == α.
Proof.
  destruct equ as [f g equ1 equ2].
  now equiv with g and f.
Qed.

`type_equiv` is transitive

If $\alpha = \beta$ , we know there exists two functions $f_\alpha$ and $g_\beta$ which satisfy the expected properties of type_equiv. Similarly, because $\beta = \gamma$ , we know there exists two additional functions $f_\beta$ and $g_\gamma$ . We can compose these functions together to prove $\alpha = \gamma$ .

As a reminder, composing two functions $f$ and $g$ (denoted by f >>> g thereafter) consists in using the result of $f$ as the input of $g$ .

Infix ">>>" := (fun f g x => g (f x)) (at level 70).

Lemma type_equiv_trans {α β γ} (equ1 : α == β) (equ2 : β == γ)
  : α == γ.
Proof.
  destruct equ1 as [fα gβ equαβ equβα],
           equ2 as [fβ gγ equβγ equγβ].
  equiv with (fα >>> fβ) and (gγ >>> gβ).
  + intros x.
    rewrite <- equβγ.
    now rewrite <- equαβ.
  + intros x.
    rewrite <- equβα.
    now rewrite <- equγβ.
Qed.

Conclusion

The Coq standard library introduces the Equivalence type class. We can provide an instance of this type class for type_equiv, using the three lemmas we have proven in this section.

#[refine]
Instance type_equiv_Equivalence : Equivalence type_equiv :=
  {}.

Proof.
  + intros x.
    apply type_equiv_refl.
  + intros x y.
    apply type_equiv_sym.
  + intros x y z.
    apply type_equiv_trans.
Qed.

Examples

`list`’s canonical form

We now come back to our initial example, given in the introduction of this write-up. We can prove our assertion, that is list α == unit + α * list α.

Lemma list_equiv (α : Type)
  : list α == unit + α * list α.

Proof.
  equiv with (fun x => match x with
                       | [] => inl tt
                       | x :: rst => inr (x, rst)
                       end)
         and (fun x => match x with
                       | inl _ => []
                       | inr (x, rst) => x :: rst
                       end).
  + now intros [| x rst].
  + now intros [[] | [x rst]].
Qed.

`list` is a morphism

This means that if α == β, then list α == list β. We prove this by defining an instance of the Proper type class.

Instance list_Proper
  : Proper (type_equiv ==> type_equiv) list.

Proof.
  add_morphism_tactic.
  intros α β [f g equαβ equβα].
  equiv with (map f) and (map g).
  all: setoid_rewrite map_map; intros l.
  + replace (fun x : α => g (f x))
       with (@id α).
    ++ symmetry; apply map_id.
    ++ apply functional_extensionality.
       apply equαβ.
  + replace (fun x : β => f (g x))
       with (@id β).
    ++ symmetry; apply map_id.
    ++ apply functional_extensionality.
       apply equβα.
Qed.

The use of the Proper type class allows for leveraging hypotheses of the form α == β with the rewrite tactic. I personally consider providing instances of Proper whenever it is possible to be a good practice, and would encourage any Coq programmers to do so.

`nat` is a special purpose `list`

Did you notice? Now, using type_equiv, we can prove it!

Lemma nat_and_list : nat == list unit.
Proof.
  equiv with (fix to_list n :=
                match n with
                | S m => tt :: to_list m
                | _ => []
                end)
         and (fix of_list l :=
                match l with
                | _ :: rst => S (of_list rst)
                | _ => 0
                end).
  + induction x; auto.
  + induction y; auto.
    rewrite <- IHy.
    now destruct a.
Qed.

Non-empty lists

We can introduce a variant of list which contains at least one element by modifying the nil constructor so that it takes one argument instead of none.

Inductive non_empty_list (α : Type) :=
| ne_cons : α -> non_empty_list α -> non_empty_list α
| ne_singleton : α -> non_empty_list α.

We can demonstrate the relation between list and non_empty_list, which reveals an alternative implementation of non_empty_list. More precisely, we can prove that forall (α : Type), non_empty_list α == α * list α. It is a bit more cumbersome, but not that much. We first define the conversion functions, then prove they satisfy the properties expected by type_equiv.

Fixpoint non_empty_list_of_list {α} (x : α) (l : list α)
  : non_empty_list α :=
  match l with
  | y :: rst => ne_cons x (non_empty_list_of_list y rst)
  | [] => ne_singleton x
  end.

#[local]
Fixpoint list_of_non_empty_list {α} (l : non_empty_list α)
  : list α :=
  match l with
  | ne_cons x rst => x :: list_of_non_empty_list rst
  | ne_singleton x => [x]
  end.

Definition list_of_non_empty_list {α} (l : non_empty_list α)
  : α * list α :=
  match l with
  | ne_singleton x => (x, [])
  | ne_cons x rst => (x, list_of_non_empty_list rst)
  end.

Lemma ne_list_list_equiv (α : Type)
  : non_empty_list α == α * list α.

Proof.
  equiv with list_of_non_empty_list
         and (prod_curry non_empty_list_of_list).
  + intros [x rst|x]; auto.
    cbn.
    revert x.
    induction rst; intros x; auto.
    cbn; now rewrite IHrst.
  + intros [x rst].
    cbn.
    destruct rst; auto.
    change (non_empty_list_of_list x (α0 :: rst))
      with (ne_cons x (non_empty_list_of_list α0 rst)).
    replace (α0 :: rst)
      with (list_of_non_empty_list
              (non_empty_list_of_list α0 rst)); auto.
    revert α0.
    induction rst; intros y; [ reflexivity | cbn ].
    now rewrite IHrst.
Qed.

The `sum` Operator

`sum` Is a Morphism

To prove this, we compose together the functions whose existence is implied by $\alpha = \alpha'$ and $\beta = \beta'$ . To that end, we introduce the auxiliary function lr_map.

Definition lr_map_sum {α β α' β'} (f : α -> α') (g : β -> β')
    (x : α + β)
  : α' + β' :=
  match x with
  | inl x => inl (f x)
  | inr y => inr (g y)
  end.

Then, we prove sum is a morphism by defining a Proper instance.

Instance sum_Proper
  : Proper (type_equiv ==> type_equiv ==> type_equiv) sum.
Proof.
  add_morphism_tactic.
  intros α α' [fα gα' equαα' equα'α]
         β β' [fβ gβ' equββ' equβ'β].
  equiv with (lr_map_sum fα fβ)
         and (lr_map_sum gα' gβ').
  + intros [x|y]; cbn.
    ++ now rewrite <- equαα'.
    ++ now rewrite <- equββ'.
  + intros [x|y]; cbn.
    ++ now rewrite <- equα'α.
    ++ now rewrite <- equβ'β.
Qed.

`sum` Is Commutative

Definition sum_invert {α β} (x : α + β) : β + α :=
  match x with
  | inl x => inr x
  | inr x => inl x
  end.

Lemma sum_com {α β} : α + β == β + α.
Proof.
  equiv with sum_invert and sum_invert;
    now intros [x|x].
Qed.

`sum` Is Associative

The associativity of sum is straightforward to prove, and should not pose a particular challenge to prospective readersIf we assume that this article is well written, that is. .

Lemma sum_assoc {α β γ} : α + β + γ == α + (β + γ).
Proof.
  equiv with (fun x =>
                match x with
                | inl (inl x) => inl x
                | inl (inr x) => inr (inl x)
                | inr x => inr (inr x)
                end)
         and (fun x =>
                match x with
                | inl x => inl (inl x)
                | inr (inl x) => inl (inr x)
                | inr (inr x) => inr x
                end).
  + now intros [[x|x]|x].
  + now intros [x|[x|x]].
Qed.

`sum` Has A Neutral Element

We need to find a type $e$ such that $\alpha + e = \alpha$ for any type $\alpha$ (similarly to $x + 0 = x$ for any natural number $x$ ).

Any empty type (that is, a type with no term such as False) can act as the natural element of Type. As a reminder, empty types in Coq are defined with the following syntaxNote that Inductive empty. is erroneous. When the := is omitted, Coq defines an inductive type with one constructor, making such a type equivalent to unit, not False. :

Inductive empty := .

From a high-level perspective, empty being the neutral element of sum makes sense. Because we cannot construct a term of type empty, then α + empty contains exactly the same numbers of terms as α. This is the intuition. Now, how can we convince Coq that our intuition is correct? Just like before, by providing two functions of types:

α -> α + empty
α + empty -> α

The first function is inl, that is one of the constructors of sum.

The second function is trickier to write in Coq, because it comes down to writing a function of type is empty -> α.

Definition from_empty {α} : empty -> α :=
  fun x => match x with end.

It is the exact same trick that allows Coq to encode proofs by contradiction.

If we combine from_empty with the generic function

Definition unwrap_left_or {α β}
    (f : β -> α) (x : α + β)
  : α :=
  match x with
  | inl x => x
  | inr x => f x
  end.

Then, we have everything to prove that α == α + empty.

Lemma sum_neutral (α : Type) : α == α + empty.
Proof.
  equiv with inl and (unwrap_left_or from_empty);
    auto.
  now intros [x|x].
Qed.

The `prod` Operator

This is very similar to what we have just proven for sum, so expect less text for this section.

`prod` Is A Morphism

Definition lr_map_prod {α α' β β'}
    (f : α -> α') (g : β -> β')
  : α * β -> α' * β' :=
  fun x => match x with (x, y) => (f x, g y) end.

Instance prod_Proper
  : Proper (type_equiv ==> type_equiv ==> type_equiv) prod.

Proof.
  add_morphism_tactic.
  intros α α' [fα gα' equαα' equα'α]
         β β' [fβ gβ' equββ' equβ'β].
  equiv with (lr_map_prod fα fβ)
         and (lr_map_prod gα' gβ').
  + intros [x y]; cbn.
    rewrite <- equαα'.
    now rewrite <- equββ'.
  + intros [x y]; cbn.
    rewrite <- equα'α.
    now rewrite <- equβ'β.
Qed.

`prod` Is Commutative

Definition prod_invert {α β} (x : α * β) : β * α :=
  (snd x, fst x).

Lemma prod_com {α β} : α * β == β * α.

Proof.
  equiv with prod_invert and prod_invert;
    now intros [x y].
Qed.

`prod` Is Associative

Lemma prod_assoc {α β γ}
  : α * β * γ == α * (β * γ).

Proof.
  equiv with (fun x =>
                match x with
                | ((x, y), z) => (x, (y, z))
                end)
         and (fun x =>
                match x with
                | (x, (y, z)) => ((x, y), z)
                end).
  + now intros [[x y] z].
  + now intros [x [y z]].
Qed.

`prod` Has A Neutral Element

Lemma prod_neutral (α : Type) : α * unit == α.

Proof.
  equiv with fst and ((flip pair) tt).
  + now intros [x []].
  + now intros.
Qed.

`prod` Has An Absorbing Element *)

And this absorbing element is empty, just like the absorbing element of the multiplication of natural numbers is $0$ (that is, the neutral element of the addition).

Lemma prod_absord (α : Type) : α * empty == empty.
Proof.
  equiv with (snd >>> from_empty)
         and (from_empty).
  + intros [_ []].
  + intros [].
Qed.

`prod` And `sum` Distributivity

Finally, we can prove the distributivity property of prod and sum using a similar approach to prove the associativity of prod and sum.

Lemma prod_sum_distr (α β γ : Type)
  : α * (β + γ) == α * β + α * γ.
Proof.
  equiv with (fun x => match x with
                       | (x, inr y) => inr (x, y)
                       | (x, inl y) => inl (x, y)
                       end)
         and (fun x => match x with
                       | inr (x, y) => (x, inr y)
                       | inl (x, y) => (x, inl y)
                       end).
  + now intros [x [y | y]].
  + now intros [[x y] | [x y]].
Qed.

Bonus: Algebraic Datatypes and Metaprogramming

Algebraic datatypes are very suitable for generating functions, as demonstrated by the automatic deriving of typeclass in Haskell or trait in Rust. Because a datatype can be expressed in terms of sum and prod, you just have to know how to deal with these two constructions to start metaprogramming.

We can take the example of the fold functions. A fold function is a function which takes a container as its argument, and iterates over the values of that container in order to compute a result.

We introduce fold_type INPUT CANON_FORM OUTPUT, a tactic to compute the type of the fold function of the type INPUT, whose “canonical form” (in terms of prod and sum) is CANON_FORM and whose result type is OUTPUT. Interested readers have to be familiar with Ltac.

Ltac fold_args b a r :=
  lazymatch a with
  | unit =>
    exact r
  | b =>
    exact (r -> r)
  | (?c + ?d)%type =>
    exact (ltac:(fold_args b c r) * ltac:(fold_args b d r))%type
  | (b * ?c)%type =>
    exact (r -> ltac:(fold_args b c r))
  | (?c * ?d)%type =>
    exact (c -> ltac:(fold_args b d r))
  | ?a =>
    exact (a -> r)
  end.

Ltac currying a :=
  match a with
  | ?a * ?b -> ?c => exact (a -> ltac:(currying (b -> c)))
  | ?a => exact a
  end.

Ltac fold_type b a r :=
  exact (ltac:(currying (ltac:(fold_args b a r) -> b -> r))).

We use it to compute the type of a fold function for list.

Definition fold_list_type (α β : Type) : Type :=
  ltac:(fold_type (list α) (unit + α * list α)%type β).

fold_list_type =
  fun α β : Type => β -> (α -> β -> β) -> list α -> β
     : Type -> Type -> Type

It is exactly what you could have expected (as match the type of fold_right).

Generating the body of the function is possible in theory, but probably not in Ltac without modifying a bit type_equiv. This could be a nice use case for MetaCoq though.

A Study of Clight and its Semantics

March 20, 2020

A Study of Clight and its Semantics

coq

CompCert is a certified C compiler which comes with a proof of semantics preservation. What this means is the following: the semantics of the C code you write is preserved by CompCert compilation passes up to the generated machine code.

I had been interested in CompCert for quite some times, and ultimately challenged myself to study Clight and its semantics. This write-up is the result of this challenge, written as I was progressing.

Installing CompCert

CompCert has been added to opam, and as a consequence can be very easily used as a library for other Coq developments. A typical use case is for a project to produce Clight (the high-level AST of CompCert), and to benefit from CompCert proofs after that.

Installing CompCert is as easy as

opam install coq-compcert

More precisely, this article uses coq-compcert.3.8.

Once opam terminates, the compcert namespace becomes available. In addition, several binaries are now available if you have correctly set your $PATH environment variable. For instance, clightgen takes a C file as an argument, and generates a Coq file which contains the Clight generated by CompCert.

Problem Statement

Our goal for this first write-up is to prove that the C function

int add (int x, int y) {
    return x + y;
}

returns the expected result, that is x + y. The clightgen tool generates (among other things) the following ASTIt has been modified in order to improve its readability. .

From compcert Require Import Clight Ctypes Clightdefs AST
                             Coqlib Cop.

Definition _x : ident := 1%positive.
Definition _y : ident := 2%positive.

Definition f_add : function :=
  {| fn_return := tint
   ; fn_callconv := cc_default
   ; fn_params := [(_x, tint); (_y, tint)]
   ; fn_vars := []
   ; fn_temps := []
   ; fn_body := Sreturn
                  (Some (Ebinop Oadd
                                (Etempvar _x tint)
                                (Etempvar _y tint)
                                tint))
  |}.

The fields of the function type are pretty self-explanatory (as it is often the case in CompCert’s ASTs as far as I can tell for now).

Identifiers in Clight are (positive) indices. The fn_body field is of type statement, with the particular constructor Sreturn whose argument is of type option expr, and statement and expr look like the two main types to study. The predicates step1 and step2 allow for reasoning about the execution of a function, step-by-step (hence the name). It appears that clightgen generates Clight terms using the function call convention encoded by step2. To reason about a complete execution, it appears that we can use star (from the Smallstep module) which is basically a trace of step. These semantics are defined as predicates (that is, they live in Prop). They allow for reasoning about state transformation, where a state is either

A function call, with a given list of arguments and a continuation
A function return, with a result and a continuation
A statement execution within a function

We import several CompCert modules to manipulate values (in our case, bounded integers).

From compcert Require Import Values Integers.
Import Int.

Putting everything together, the lemma we want to prove about f_add is the following.

Lemma f_add_spec (env : genv)
    (t : Events.trace)
    (m m' : Memory.Mem.mem)
    (v : val) (x y z : int)
    (trace : Smallstep.star step2 env
               (Callstate (Ctypes.Internal f_add)
                          [Vint x; Vint y]
                          Kstop
                          m)
               t
               (Returnstate (Vint z) Kstop m'))
  : z = add x y.

Proof Walkthrough

We introduce a custom inversion tactic which does some clean-up in addition to just perform the inversion.

Ltac smart_inv H :=
  inversion H; subst; cbn in *; clear H.

We can now try to prove our lemma.

Proof.

We first destruct trace, and we rename the generated hypothesis in order to improve the readability of these notes.

  smart_inv trace.
  rename H into Hstep.
  rename H0 into Hstar.

This generates two hypotheses.

Hstep : step1
          env
          (Callstate (Ctypes.Internal f_add)
                     [Vint x; Vint y]
                     Kstop
                     m)
          t1
          s2
Hstar : Smallstep.star
          step2
          env
          s2
          t2
          (Returnstate (Vint z) Kstop m')

In other words, to “go” from a Callstate of f_add to a Returnstate, there is a first step from a Callstate to a state s2, then a succession of steps to go from s2 to a Returnstate.

We consider the single step, in order to determine the actual value of s2 (among other things). To do that, we use smart_inv on Hstep, and again perform some renaming.

  smart_inv Hstep.
  rename le into tmp_env.
  rename e into c_env.
  rename H5 into f_entry.

This produces two effects. First, a new hypothesis is added to the context.

f_entry : function_entry1
            env
            f_add
            [Vint x; Vint y]
            m
            c_env
            tmp_env
            m1

Then, the Hstar hypothesis has been updated, because we now have a more precise value of s2. More precisely, s2 has become

State
  f_add
  (Sreturn
    (Some (Ebinop Oadd
                  (Etempvar _x tint)
                  (Etempvar _y tint)
                  tint)))
  Kstop
  c_env
  tmp_env
  m1

Using the same approach as before, we can uncover the next step.

  smart_inv Hstar.
  rename H into Hstep.
  rename H0 into Hstar.

The resulting hypotheses are

Hstep : step2 env
          (State
             f_add
             (Sreturn
               (Some
                 (Ebinop Oadd
                 (Etempvar _x tint)
                 (Etempvar _y tint)
                 tint)))
             Kstop c_env tmp_env m1) t1 s2
Hstar : Smallstep.star
          step2
          env
          s2
          t0
          (Returnstate (Vint z) Kstop m')

An inversion of Hstep can be used to learn more about its resulting state… So let’s do just that.

  smart_inv Hstep.
  rename H7 into ev.
  rename v0 into res.
  rename H8 into res_equ.
  rename H9 into mem_equ.

The generated hypotheses have become

res : val
ev : eval_expr env c_env tmp_env m1
       (Ebinop Oadd
               (Etempvar _x tint)
               (Etempvar _y tint)
               tint)
       res
res_equ : sem_cast res tint tint m1 = Some v'
mem_equ : Memory.Mem.free_list m1
                               (blocks_of_env env c_env)
            = Some m'0

Our understanding of these hypotheses is the following

The expression _x + _y is evaluated using the c_env environment (and we know thanks to binding the value of _x and _y), and its result is stored in res
res is cast into a tint value, and acts as the result of f_add

The Hstar hypothesis is now interesting

Hstar : Smallstep.star
          step2 env
          (Returnstate v' Kstop m'0) t0
          (Returnstate (Vint z) Kstop m')

It is clear that we are at the end of the execution of f_add (even if Coq generates two subgoals, the second one is not relevant and easy to discard).

  smart_inv Hstar; [| smart_inv H ].

We are making good progress here, and we can focus our attention on the ev hypothesis, which concerns the evaluation of the _x + _y expression. We can simplify it a bit further.

  smart_inv ev; [| smart_inv H].
  rename H4 into fetch_x.
  rename H5 into fetch_y.
  rename H6 into add_op.

In a short-term, the hypotheses fetch_x and fetch_y are the most important.

fetch_x : eval_expr env c_env tmp_env m1 (Etempvar _x tint) v1
fetch_y : eval_expr env c_env tmp_env m1 (Etempvar _y tint) v2

The current challenge we face is to prove that we know their value. At this point, we can have a look at f_entry. This is starting to look familiar: smart_inv, then renaming, etc.

  smart_inv f_entry.
  clear H.
  clear H0.
  clear H1.
  smart_inv H3; subst.
  rename H2 into allocs.

We are almost done. Let’s simplify as much as possible fetch_x and fetch_y. Each time, the smart_inv tactic generates two subgoals, but only the first one is relevant. The second one is not, and can be discarded.

  smart_inv fetch_x; [| inversion H].
  smart_inv H2.
  smart_inv fetch_y; [| inversion H].
  smart_inv H2.

We now know the values of the operands of add. The two relevant hypotheses that we need to consider next are add_op and res_equ. They are easy to read.

add_op : sem_binarith
           (fun (_ : signedness) (n1 n2 : Integers.int)
              => Some (Vint (add n1 n2)))
           (fun (_ : signedness) (n1 n2 : int64)
              => Some (Vlong (Int64.add n1 n2)))
           (fun n1 n2 : Floats.float
              => Some (Vfloat (Floats.Float.add n1 n2)))
           (fun n1 n2 : Floats.float32
              => Some (Vsingle (Floats.Float32.add n1 n2)))
           v1 tint v2 tint m1 = Some res

add_op is the addition of Vint x and Vint y, and its result is res.
```
res_equ : sem_cast res tint tint m1 = Some (Vint z)
```
res_equ is the equation which says that the result of f_add is res, after it has been cast as a tint value.

We can simplify add_op and res_equ, and this allows us to conclude.

  smart_inv add_op.
  smart_inv res_equ.
  reflexivity.
Qed.

Conclusion

The definitions of Clight are straightforward, and the CompCert documentation is very pleasant to read. Understanding Clight and its semantics can be very interesting if you are working on a language that you want to translate into machine code. However, proving some functional properties of a given C snippet using only CompCert can quickly become cumbersome. From this perspective, the VST project is very interesting, as its main purpose is to provide tools to reason about Clight programs more easily.

Rewriting in Coq

May 13, 2017

Rewriting in Coq

coq

I have to confess something. In the codebase of SpecCert lies a shameful secret, which takes the form of a set of unnecessary axioms.

I thought I couldn’t avoid them at first, but it was before I heard about “generalized rewriting,” setoids and morphisms. Now, I know the truth, and I will have to update SpecCert eventually. But, in the meantime, let me try to explain how it is possible to rewrite a term in a proof using an ad hoc equivalence relation and, when necessary, a proper morphism.

Case Study: Gate System

Now, why would anyone want such a thing as “generalized rewriting” when the rewrite tactic works just fine.

The thing is: it does not in some cases. To illustrate my statement, we will consider the following definition of a gate in Coq:

Record Gate :=
  { open:           bool
  ; lock:           bool
  ; lock_is_close:  lock = true -> open = false
  }.

According to this definition, a gate can be either open or closed. It can also be locked, but if it is, it cannot be open at the same time. To express this constraint, we embed the appropriate proposition inside the Record. By doing so, we know for sure that we will never meet an ill-formed Gate instance. The Coq engine will prevent it, because to construct a gate, one will have to prove the lock_is_close predicate holds.

The program attribute makes it easy to work with embedded proofs. For instance, defining the ”open gate” is as easy as:

Require Import Coq.Program.Tactics.

#[program]
Definition open_gate :=
  {| open := true
   ; lock := false
   |}.

Under the hood, program proves what needs to be proven, that is the lock_is_close proposition. Just have a look at its output:

open_gate has type-checked, generating 1 obligation(s)
Solving obligations automatically...
open_gate_obligation_1 is defined
No more obligations remaining
open_gate is defined

In this case, using Program is a bit like cracking a nut with a sledgehammer. We can easily do it ourselves using the refine tactic.

Definition open_gate': Gate.
  refine ({| open := true
           ; lock := false
          |}).
  intro Hfalse.
  discriminate Hfalse.
Defined.

`Gate` Equality

What does it mean for two gates to be equal? Intuitively, we know they have to share the same states (open and lock is our case).

Leibniz Equality Is Too Strong

When you write something like a = b in Coq, the = refers to the eq function and this function relies on what is called the Leibniz Equality: x and y are equal iff every property on A which is true of x is also true of y.

As for myself, when I first started to write some Coq code, the Leibniz Equality was not really something I cared about and I tried to prove something like this:

Lemma open_gates_are_equal (g g': Gate)
    (equ : open g = true) (equ' : open g' = true)
  : g = g'.

Basically, it means that if two doors are open, then they are equal. That made sense to me, because by definition of Gate, a locked door is closed, meaning an open door cannot be locked.

Here is an attempt to prove the open_gates_are_equal lemma.

Proof.
  assert (forall g, open g = true -> lock g = false). {
    intros [o l h] equo.
    cbn in *.
    case_eq l; auto.
    intros equl.
    now rewrite (h equl) in equo.
  }
  assert (lock g = false) by apply (H _ equ).
  assert (lock g' = false) by apply (H _ equ').
  destruct g; destruct g'; cbn in *; subst.

The term to prove is now:

{| open := true; lock := false; lock_is_close := lock_is_close0 |} =
{| open := true; lock := false; lock_is_close := lock_is_close1 |}

The next tactic I wanted to use reflexivity, because I'd basically proven open g = open g' and lock g = lock g', which meets my definition of equality at that time.

Except Coq wouldn’t agree. See how it reacts:

Unable to unify "{| open := true; lock := false; lock_is_close := lock_is_close1 |}"
  with "{| open := true; lock := false; lock_is_close := lock_is_close0 |}".

It cannot unify the two records. More precisely, it cannot unify lock_is_close1 and lock_is_close0. So we abort and try something else.

Abort.

Ah-Hoc Equivalence Relation

This is a familiar pattern. Coq cannot guess what we have in mind. Giving a formal definition of “our equality” is fortunately straightforward.

Definition gate_eq
           (g g': Gate)
  : Prop :=
  open g = open g' /\ lock g = lock g'.

Because “equality” means something very specific in Coq, we won't say “two gates are equal” anymore, but “two gates are equivalent.” That is, gate_eq is an equivalence relation. But “equivalence relation” is also something very specific. For instance, such relation needs to be symmetric (R x y -> R y x), reflexive (R x x) and transitive (R x y -> R y z -> R x z).

Require Import Coq.Classes.Equivalence.

#[program]
Instance Gate_Equivalence
  : Equivalence gate_eq.

Next Obligation.
  split; reflexivity.
Defined.

Next Obligation.
  intros g g' [Hop Hlo].
  symmetry in Hop; symmetry in Hlo.
  split; assumption.
Defined.

Next Obligation.
  intros g g' g'' [Hop Hlo] [Hop' Hlo'].
  split.
  + transitivity (open g'); [exact Hop|exact Hop'].
  + transitivity (lock g'); [exact Hlo|exact Hlo'].
Defined.

Afterwards, the symmetry, reflexivity and transitivity tactics also works with gate_eq, in addition to eq. We can try again to prove the open_gate_are_the_same lemma and it will workI know I should have proven an intermediate lemma to avoid code duplication. Sorry about that, it hurts my eyes too. .

Lemma open_gates_are_the_same:
  forall (g g': Gate),
    open g = true
    -> open g' = true
    -> gate_eq g g'.
Proof.
  induction g; induction g'.
  cbn.
  intros H0 H2.
  assert (lock0 = false).
  + case_eq lock0; [ intro H; apply lock_is_close0 in H;
                     rewrite H0 in H;
                     discriminate H
                   | reflexivity
                   ].
  + assert (lock1 = false).
    * case_eq lock1; [ intro H'; apply lock_is_close1 in H';
                       rewrite H2 in H';
                       discriminate H'
                     | reflexivity
                     ].
    * subst.
      split; reflexivity.
Qed.

Equivalence Relations and Rewriting

So here we are, with our ad hoc definition of gate equivalence. We can use symmetry, reflexivity and transitivity along with gate_eq and it works fine because we have told Coq gate_eq is indeed an equivalence relation for Gate.

Can we do better? Can we actually use rewrite to replace an occurrence of g by an occurrence of g’ as long as we can prove that gate_eq g g’? The answer is “yes”, but it will not come for free.

Before moving forward, just consider the following function:

Require Import Coq.Bool.Bool.

Program Definition try_open
        (g: Gate)
  : Gate :=
  if eqb (lock g) false
  then {| lock := false
        ; open := true
       |}
  else g.

It takes a gate as an argument and returns a new gate. If the former is not locked, the latter is open. Otherwise the argument is returned as is.

Lemma gate_eq_try_open_eq
  : forall (g g': Gate),
    gate_eq g g'
    -> gate_eq (try_open g) (try_open g').
Proof.
  intros g g' Heq.
Abort.

What we could have wanted to do is: rewrite Heq. Indeed, g and g’ “are the same” (gate_eq g g’), so, of course, the results of try_open g and try_open g’ have to be the same. Except...

Error: Tactic failure: setoid rewrite failed: Unable to satisfy the following constraints:
UNDEFINED EVARS:
 ?X49==[g g' Heq |- relation Gate] (internal placeholder) {?r}
 ?X50==[g g' Heq (do_subrelation:=Morphisms.do_subrelation)
         |- Morphisms.Proper (gate_eq ==> ?X49@{__:=g; __:=g'; __:=Heq}) try_open] (internal placeholder) {?p}
 ?X52==[g g' Heq |- relation Gate] (internal placeholder) {?r0}
 ?X53==[g g' Heq (do_subrelation:=Morphisms.do_subrelation)
         |- Morphisms.Proper (?X49@{__:=g; __:=g'; __:=Heq} ==> ?X52@{__:=g; __:=g'; __:=Heq} ==> Basics.flip Basics.impl) eq]
         (internal placeholder) {?p0}
 ?X54==[g g' Heq |- Morphisms.ProperProxy ?X52@{__:=g; __:=g'; __:=Heq} (try_open g')] (internal placeholder) {?p1}

What Coq is trying to tell us here —in a very poor manner, I’d say— is actually pretty simple. It cannot replace g by g’ because it does not know if two equivalent gates actually give the same result when passed as the argument of try_open. This is actually what we want to prove, so we cannot use rewrite just yet, because it needs this result so it can do its magic. Chicken and egg problem.

In other words, we are making the same mistake as before: not telling Coq what it cannot guess by itself.

The rewrite tactic works out of the box with the Coq equality (eq, or most likely =) because of the Leibniz Equality: x and y are equal iff every property on A which is true of x is also true of y

This is a pretty strong property, and one that a lot of equivalence relations do not have. Want an example? Consider the relation R over A such that forall x and y, R x y holds true. Such a relation is reflexive, symmetric and reflexive. Yet, there is very little chance that given a function f : A -> B and R’ an equivalence relation over B, R x y -> R' (f x) (f y). Only if we have this property, we would know that we could rewrite f x by f y, e.g., in R' z (f x). Indeed, by transitivity of R’, we can deduce R' z (f y) from R' z (f x) and R (f x) (f y).

If R x y -> R' (f x) (f y), then f is a morphism because it preserves an equivalence relation. In our previous case, A is Gate, R is gate_eq, f is try_open and therefore B is Gate and R’ is gate_eq. To make Coq aware that try_open is a morphism, we can use the following syntax: *)

#[local]
Open Scope signature_scope.

Require Import Coq.Classes.Morphisms.

#[program]
Instance try_open_Proper
  : Proper (gate_eq ==> gate_eq) try_open.

This notation is actually more generic because you can deal with functions that take more than one argument. Hence, given g : A -> B -> C -> D, R (respectively R’, R’’ and R’’’) an equivalent relation of A (respectively B, C and D), we can prove f is a morphism as follows:

Add Parametric Morphism: (g)
    with signature (R) ==> (R') ==> (R'') ==> (R''')
      as <name>.

Back to our try_open morphism. Coq needs you to prove the following goal:

1 subgoal, subgoal 1 (ID 50)

  ============================
  forall x y : Gate, gate_eq x y -> gate_eq (try_open x) (try_open y)

Here is a way to prove that:

Next Obligation.
  intros g g' Heq.
  assert (gate_eq g g') as [Hop Hlo] by (exact Heq).
  unfold try_open.
  rewrite <- Hlo.
  destruct (bool_dec (lock g) false) as [Hlock|Hnlock]; subst.
  + rewrite Hlock.
    split; cbn; reflexivity.
  + apply not_false_is_true in Hnlock.
    rewrite Hnlock.
    cbn.
    exact Heq.
Defined.

Now, back to our gate_eq_try_open_eq, we now can use rewrite and reflexivity.

Require Import Coq.Setoids.Setoid.

Lemma gate_eq_try_open_eq
  : forall (g g': Gate),
    gate_eq g g'
    -> gate_eq (try_open g) (try_open g').
Proof.
  intros g g' Heq.
  rewrite Heq.
  reflexivity.
Qed.

We did it! We actually rewrite g as g’, even if we weren’t able to prove g = g’.

Implementing Strongly-Specified Functions with the Program Framework

January 1, 2017

Implementing Strongly-Specified Functions with the `Program` Framework

coq

The Theory

If I had to explain Program, I would say Program is the heir of the refine tactic. It gives you a convenient way to embed proofs within functional programs that are supposed to fade away during code extraction. But what do I mean when I say "embed proofs" within functional programs? I found two ways to do it.

Invariants

First, we can define a record with one or more fields of type Prop. By doing so, we can constrain the values of other fields. Put another way, we can specify invariant for our type. For instance, in SpecCert , I have defined the memory controller's SMRAMC register as follows:

Record SmramcRegister := {
  d_open: bool;
  d_lock: bool;
  lock_is_close: d_lock = true -> d_open = false;
}.

So lock_is_closed is an invariant I know each instance of SmramcRegister will have to comply with, because every time I will construct a new instance, I will have to prove lock_is_closed holds true. For instance:

Definition lock (reg: SmramcRegister)
  : SmramcRegister.
  refine ({| d_open := false; d_lock := true |}).

Coq leaves us this goal to prove.

reg : SmramcRegister
============================
true = true -> false = false

This sound reasonable enough.

Proof.
  trivial.
Defined.

We have seen in my previous article about strongly specified functions that mixing proofs and regular terms may lead to cumbersome code.

From that perspective, Program helps. Indeed, the lock function can also be defined as follows:

From Coq Require Import Program.

#[program]
Definition lock' (reg: SmramcRegister)
  : SmramcRegister :=
  {| d_open := false
   ; d_lock := true
   |}.

Pre and Post Conditions

Another way to "embed proofs in a program" is by specifying pre- and post-conditions for its component. In Coq, this is done using sigma types.

On the one hand, a precondition is a proposition a function input has to satisfy in order for the function to be applied. For instance, a precondition for head : forall {a}, list a -> a the function that returns the first element of a list l requires l to contain at least one element. We can write that using a sigma-type. The type of head then becomes forall {a} (l: list a | l <> []) : a.

On the other hand, a post condition is a proposition a function output has to satisfy in order for the function to be correctly implemented. In this way, head should in fact return the first element of l and not something else.

Program makes writing this specification straightforward.

#[program]
Definition head {a} (l : list a | l <> [])
  : { x : a | exists l', x :: l' = l }.

We recall that because { l: list a | l <> [] } is not the same as list a, in theory we cannot just compare l with x :: l' (we need to use proj1_sig). One advantage of Program is to deal with it using an implicit coercion.

Note that for the type inference to work as expected, the unwrapped value (here, x :: l') needs to be the left operand of =.

Now that head have been specified, we have to implement it.

#[program]
Definition head {a} (l: list a | l <> [])
  : { x : a | exists l', cons x l' = l } :=
  match l with
  | x :: l' => x
  | [] => !
  end.

Next Obligation.
  exists l'.
  reflexivity.
Qed.

I want to highlight several things here:

We return x (of type a) rather than a sigma-type, then Program is smart enough to wrap it. To do so, it tries to prove the post condition and because it fails, we have to do it ourselves (this is the Obligation we solve after the function definition.)
The [] case is absurd regarding the precondition, we tell Coq that using the bang (!) symbol.

We can have a look at the extracted code:

(** val head : 'a1 list -> 'a1 **)
let head = function
| Nil -> assert false (* absurd case *)
| Cons (a, _) -> a

The implementation is pretty straightforward, but the pre- and post conditions have faded away. Also, the absurd case is discarded using an assertion. This means one thing: [head] should not be used directly from the Ocaml world. "Interface" functions have to be total. *)

The Practice

From Coq Require Import Lia.

I have challenged myself to build a strongly specified library. My goal was to define a type vector : nat -> Type -> Type such as vector a n is a list of n instance of a.

Inductive vector (a : Type) : nat -> Type :=
| vcons {n} : a -> vector a n -> vector a (S n)
| vnil : vector a O.

Arguments vcons [a n] _ _.
Arguments vnil {a}.

I had three functions in mind: take, drop and extract. I learned a few lessons. My main takeaway remains: do not use sigma types, Program and dependent types together. From my point of view, Coq is not yet ready for this. Maybe it is possible to make those three work together, but I have to admit I did not find out how. As a consequence, my preconditions are defined as extra arguments.

To be able to specify the post conditions of my three functions and some others, I first defined nth to get the nth element of a vector.

My first attempt to write nth was a failure.

#[program]
Fixpoint nth {a n}
    (v : vector a n) (i : nat) {struct v}
  : option a :=
  match v, i with
  | vcons x _, O => Some x
  | vcons x r, S i => nth r i
  | vnil, _ => None
  end.

raised an anomaly.

#[program]
Fixpoint nth {a n}
    (v : vector a n) (i : nat) {struct v}
  : option a :=
  match v with
  | vcons x r =>
    match i with
    | O => Some x
    | S i => nth r i
    end
  | vnil => None
  end.

With nth, it is possible to give a very precise definition of take:

#[program]
Fixpoint take {a n}
    (v : vector a n) (e : nat | e <= n)
  : { u : vector a e | forall i : nat,
        i < e -> nth u i = nth v i } :=
  match e with
  | S e' => match v with
            | vcons x r => vcons x (take r e')
            | vnil => !
            end
  | O => vnil
  end.

Next Obligation.
  now apply le_S_n.
Defined.

Next Obligation.
  induction i.
  + reflexivity.
  + apply e0.
    now apply Lt.lt_S_n.
Defined.

Next Obligation.
  now apply PeanoNat.Nat.nle_succ_0 in H.
Defined.

Next Obligation.
  now apply PeanoNat.Nat.nlt_0_r in H.
Defined.

As a side note, I wanted to define the post condition as follows: { v': vector A e | forall (i : nat | i < e), nth v' i = nth v i }. However, this made the goals and hypotheses become very hard to read and to use. Sigma types in sigma types: not a good idea.

(** val take : 'a1 vector -> nat -> 'a1 vector **)

let rec take v = function
| O -> Vnil
| S e' ->
  (match v with
   | Vcons (_, x, r) -> Vcons (e', x, (take r e'))
   | Vnil -> assert false (* absurd case *))

Then I could tackle drop in a very similar manner:

#[program]
Fixpoint drop {a n}
    (v : vector a n) (b : nat | b <= n)
  : { v': vector a (n - b) | forall i,
        i < n - b -> nth v' i = nth v (b + i) } :=
  match b with
  | 0 => v
  | S n => (match v with
           | vcons _ r => (drop r n)
           | vnil => !
           end)
  end.

Next Obligation.
  now rewrite <- Minus.minus_n_O.
Defined.

Next Obligation.
  induction n;
    rewrite <- eq_rect_eq;
    reflexivity.
Defined.

Next Obligation.
  now apply le_S_n.
Defined.

Next Obligation.
  now apply PeanoNat.Nat.nle_succ_0 in H.
Defined.

The proofs are easy to write, and the extracted code is exactly what one might want it to be:

(** val drop : 'a1 vector -> nat -> 'a1 vector **)
let rec drop v = function
| O -> v
| S n ->
  (match v with
   | Vcons (_, _, r) -> drop r n
   | Vnil -> assert false (* absurd case *))

But Program really shone when it comes to implementing extract. I just had to combine take and drop. *)

#[program]
Definition extract {a n} (v : vector a n)
    (e : nat | e <= n) (b : nat | b <= e)
  : { v': vector a (e - b) | forall i,
        i < (e - b) -> nth v' i = nth v (b + i) } :=
  take (drop v b) (e - b).


Next Obligation.
  transitivity e; auto.
Defined.

Next Obligation.
  now apply PeanoNat.Nat.sub_le_mono_r.
Defined.

Next Obligation.
  destruct drop; cbn in *.
  destruct take; cbn in *.
  rewrite e1; auto.
  rewrite <- e0; auto.
  lia.
Defined.

The proofs are straightforward because the specifications of drop and take are precise enough, and we do not need to have a look at their implementations. The extracted version of extract is as clean as we can anticipate.

(** val extract : 'a1 vector -> nat -> nat -> 'a1 vector **)
let extract v e b =
  take (drop v b) (sub e b)

I was pretty happy, so I tried some more. Each time, using nth, I managed to write a precise post condition and to prove it holds true. For instance, given map to apply a function f to each element of a vector v:

#[program]
Fixpoint map {a b n} (v : vector a n) (f : a -> b)
  : { v': vector b n | forall i,
        nth v' i = option_map f (nth v i) } :=
  match v with
  | vnil => vnil
  | vcons a v => vcons (f a) (map v f)
  end.

Next Obligation.
  induction i.
  + reflexivity.
  + apply e.
Defined.

I also managed to specify and write append:

#[program]
Fixpoint append {a n m}
    (v : vector a n) (u : vector a m)
  : { w : vector a (n + m) | forall i,
        (i < n -> nth w i = nth v i) /\
        (n <= i -> nth w i = nth u (i - n))
    } :=
  match v with
  | vnil => u
  | vcons a v => vcons a (append v u)
  end.

Next Obligation.
  split.
  + now intro.
  + intros _.
    now rewrite PeanoNat.Nat.sub_0_r.
Defined.

Next Obligation.
  rename wildcard' into n.
  destruct (Compare_dec.lt_dec i (S n)); split.
  + intros _.
    destruct i.
    ++ reflexivity.
    ++ cbn.
       specialize (a1 i).
       destruct a1 as [a1 _].
       apply a1.
       auto with arith.
  + intros false.
    lia.
  + now intros.
  + intros ord.
    destruct i.
    ++ lia.
    ++ cbn.
       specialize (a1 i).
       destruct a1 as [_ a1].
       apply a1.
       auto with arith.
Defined.

Finally, I tried to implement map2 that takes a vector of a, a vector of b (both of the same size) and a function f : a -> b -> c and returns a vector of c.

First, we need to provide a precise specification for map2. To do that, we introduce option_app, a function that Haskellers know all to well as being part of the Applicative type class.

Definition option_app {a b}
    (opf: option (a -> b))
    (opx: option a)
  : option b :=
  match opf, opx with
  | Some f, Some x => Some (f x)
  | _, _ => None
end.

We thereafter use <$> as an infix operator for option_map and <*> as an infix operator for option_app. *)

Infix "<$>" := option_map (at level 50).
Infix "<*>" := option_app (at level 55).

Given two vectors v and u of the same size and a function f, and given w the result computed by map2, then we can propose the following specification for map2:

forall (i : nat), nth w i = f <$> nth v i <*> nth u i

This reads as follows: the ith element of w is the result of applying the ith elements of v and u to f.

It turns out implementing map2 with the Program framework has proven to be harder than I originally expected. My initial attempt was the following:

#[program]
Fixpoint map2 {a b c n}
    (v : vector a n) (u : vector b n)
    (f : a -> b -> c) {struct v}
  : { w: vector c n | forall i,
        nth w i = f <$> nth v i <*> nth u i
    } :=
  match v, u with
  | vcons x rst, vcons x' rst' =>
      vcons (f x x') (map2 rst rst' f)
  | vnil, vnil => vnil
  | _, _ => !
  end.

Illegal application:
The term "@eq" of type "forall A : Type, A -> A -> Prop"
cannot be applied to the terms
 "nat" : "Set"
 "S wildcard'" : "nat"
 "b" : "Type"
The 3rd term has type "Type" which should be coercible
to "nat".

So I had to fallback to defining the function in pure Ltac.

#[program]
Fixpoint map2 {a b c n}
    (v : vector a n) (u : vector b n)
    (f : a -> b -> c) {struct v}
  : { w: vector c n | forall i,
        nth w i = f <$> nth v i <*> nth u i
    } := _.

Next Obligation.
  dependent induction v; dependent induction u.
  + remember (IHv u f) as u'.
    inversion u'.
    refine (exist _ (vcons (f a0 a1) x) _).
    intros i.
    induction i.
    * reflexivity.
    * apply (H i).
  + refine (exist _ vnil _).
    reflexivity.
Qed.

Is It Usable?

This post mostly gives the "happy ends" for each function. I think I tried too hard for what I got in return and therefore I am convinced Program is not ready (at least for a dependent type, I cannot tell for the rest). For instance, I found at least one bug in Program logic (I still have to report it). Have a look at the following code:

#[program]
Fixpoint map2 {a b c n}
     (u : vector a n) (v : vector b n)
     (f : a -> b -> c) {struct v}
  : vector c n :=
  match u with
  | _ => vnil
  end.

It gives the following error:

Error: Illegal application:
The term "@eq" of type "forall A : Type, A -> A -> Prop"
cannot be applied to the terms
 "nat" : "Set"
 "0" : "nat"
 "wildcard'" : "vector A n'"
The 3rd term has type "vector A n'" which should be
coercible to "nat".

Implementing Strongly-Specified Functions with the refine Tactic

January 11, 2015

Implementing Strongly-Specified Functions with the `refine` Tactic

coq

I started to play with Coq, the interactive theorem prover developed by Inria, a few weeks ago. It is a very powerful tool, yet hard to master. Fortunately, there are some very good readings if you want to learn (I recommend the Coq'Art). This article is not one of them.

In this article, we will see how to implement strongly specified list manipulation functions in Coq. Strong specifications are used to ensure some properties on functions' arguments and return value. It makes Coq type system very expressive. Thus, it is possible to specify in the type of the function pop that the return value is the list passed as an argument in which the first element has been removed, for example.

Is This List Empty?

It's the first question to deal with when manipulating lists. There are some functions that require their arguments not to be empty. It's the case for the pop function, for instance it is not possible to remove the first element of a list that does not have any elements in the first place.

When one wants to answer such a question as “Is this list empty?”, he has to keep in mind that there are two ways to do it: by a predicate or by a boolean function. Indeed, Prop and bool are two different worlds that do not mix easily. One solution is to write two definitions and to prove their equivalence. That is forall args, predicate args <-> bool_function args = true.

Another solution is to use the sumbool type as middlemen. The scheme is the following:

Defining predicate : args → Prop
Defining predicate_dec : args -> { predicate args } + { ~predicate args }
Defining predicate_b:

Definition predicate_b (args) :=
  if predicate_dec args then true else false.

Defining the `empty` Predicate

A list is empty if it is [] (nil). It's as simple as that!

Definition empty {a} (l : list a) : Prop := l = [].

Defining a decidable version of `empty`

A decidable version of empty is a function which takes a list l as its argument and returns either a proof that l is empty, or a proof that l is not empty. This is encoded in the Coq standard library with the sumbool type, and is written as follows: { empty l } + { ~ empty l }.

Definition empty_dec {a} (l : list a)
  : { empty l } + { ~ empty l }.
Proof.
  refine (match l with
          | [] => left _ _
          | _ => right _ _
          end);
    unfold empty; trivial.
  unfold not; intro H; discriminate H.
Defined.

In this example, I decided to use the refine tactic which is convenient when we manipulate the Set and Prop sorts at the same time.

Defining `empty_b`

With empty_dec, we can define empty_b.

Definition empty_b {a} (l : list a) : bool :=
  if empty_dec l then true else false.

Let's try to extract empty_b:

type bool =
| True
| False

type sumbool =
| Left
| Right

type 'a list =
| Nil
| Cons of 'a * 'a list

(** val empty_dec : 'a1 list -> sumbool **)

let empty_dec = function
| Nil -> Left
| Cons (a, l0) -> Right

(** val empty_b : 'a1 list -> bool **)

let empty_b l =
  match empty_dec l with
  | Left -> True
  | Right -> False

In addition to 'a list, Coq has created the sumbool and bool types and empty_b is basically a translation from the former to the latter. We could have stopped with empty_dec, but Left and Right are less readable that True and False. Note that it is possible to configure the Extraction mechanism to use primitive OCaml types instead, but this is out of the scope of this article.

Defining Some Utility Functions

Defining `pop`

There are several ways to write a function that removes the first element of a list. One is to return nil if the given list was already empty:

Definition pop {a} ( l :list a) :=
  match l with
  | _ :: l => l
  | [] => []
  end.

But it's not really satisfying. A pop call over an empty list should not be possible. It can be done by adding an argument to pop: the proof that the list is not empty.

Definition pop {a} (l : list a) (h : ~ empty l)
  : list a.

There are, as usual when it comes to lists, two cases to consider.

l = x :: rst, and therefore pop (x :: rst) h is rst
l = [], which is not possible since we know l is not empty.

The challenge is to convince Coq that our reasoning is correct. There are, again, several approaches to achieve that. We can, for instance, use the refine tactic again, but this time we need to know a small trick to succeed as using a “regular” match will not work.

From the following goal:

  a : Type
  l : list a
  h : ~ empty l
  ============================
  list a

Using the refine tactic naively, for instance, this way:

  refine (match l with
          | _ :: rst => rst
          | [] => _
          end).

leaves us the following goal to prove:

  a : Type
  l : list a
  h : ~ empty l
  ============================
  list a

Nothing has changed! Well, not exactly. See, refine has taken our incomplete Gallina term, found a hole, done some type-checking, found that the type of the missing piece of our implementation is list a and therefore has generated a new goal of this type. What refine has not done, however, is remembering that we are in the case where l = [].

We need to generate a goal from a hole wherein this information is available. It is possible to use a long form of match. The general approach is this: rather than returning a value of type list a, our match will return a function of type l = ?l' -> list a, where ?l is a value of l for a given case (that is, either x :: rst or []). Of course and as a consequence, the type of the match in now a function which awaits a proof to return the expected result. Fortunately, this proof is trivial: it is eq_refl.

  refine (match l as l'
                return l = l' -> list a
          with
          | _ :: rst => fun _ => rst
          | [] => fun equ => _
          end eq_refl).

For us to conclude the proof, this is way better.

  a : Type
  l : list a
  h : ~ empty l
  equ : l = []
  ============================
  list a

We conclude the proof, and therefore the definition of pop.

  rewrite equ in h.
  exfalso.
  now apply h.
Defined.

It's better and yet it can still be improved. Indeed, according to its type, pop returns “some list.” As a matter of fact, pop returns “the same list without its first argument.” It is possible to write such precise definition thanks to sigma types, defined as:

Inductive sig (A : Type) (P : A -> Prop) : Type :=
  exist : forall (x : A), P x -> sig P.

Rather than sig A p, sigma-types can be written using the notation { a | P }. They express subsets, and can be used to constraint arguments and results of functions.

We finally propose a strongly specified definition of pop.

Definition pop {a} (l : list a | ~ empty l)
  : { l' | exists a, proj1_sig l = cons a l' }.

If you think the previous use of match term was ugly, brace yourselves.

  refine (match proj1_sig l as l'
                return proj1_sig l = l'
                       -> { l' | exists a, proj1_sig l = cons a l' }
          with
          | [] => fun equ => _
          | (_ :: rst) => fun equ => exist _ rst _
          end eq_refl).

This leaves us two goals to tackle.

First, we need to discard the case where l is the empty list.

  a : Type
  l : {l : list a | ~ empty l}
  equ : proj1_sig l = []
  ============================
  {l' : list a | exists a0 : a, proj1_sig l = a0 :: l'}

  + destruct l as [l nempty]; cbn in *.
    rewrite equ in nempty.
    exfalso.
    now apply nempty.

Then, we need to prove that the result we provide (rst) when the list is not empty is correct with respect to the specification of pop.

  a : Type
  l : {l : list a | ~ empty l}
  a0 : a
  rst : list a
  equ : proj1_sig l = a0 :: rst
  ============================
  exists a1 : a, proj1_sig l = a1 :: rst

  + destruct l as [l nempty]; cbn in *.
    rewrite equ.
    now exists a0.
Defined.

Let's have a look at the extracted code:

(** val pop : 'a1 list -> 'a1 list **)

let pop = function
| Nil -> assert false (* absurd case *)
| Cons (a, l0) -> l0

If one tries to call pop nil, the assert ensures the call fails. Extra information given by the sigma type has been stripped away. It can be confusing, and in practice it means that, we you rely on the extraction mechanism to provide a certified OCaml module, you cannot expose strongly specified functions in its public interface because nothing in the OCaml type system will prevent a misuse which will in practice leads to an assert false. *)

Defining `push`

It is possible to specify push the same way pop has been. The only difference is push accepts lists with no restriction at all. Thus, its definition is a simpler, and we can write it without refine.

Definition push {a} (l : list a) (x : a)
  : { l' | l' = x :: l } :=
  exist _ (x :: l) eq_refl.

And the extracted code is just as straightforward.

let push l a =
  Cons (a, l)

Defining `head`

Same as pop and push, it is possible to add extra information in the type of head, namely the returned value of head is indeed the first value of l.

Definition head {a} (l : list a | ~ empty l)
  : { x | exists r, proj1_sig l = x :: r }.

It's not a surprise its definition is very close to pop.

  refine (match proj1_sig l as l'
                return proj1_sig l = l' -> _
          with
          | [] => fun equ => _
          | x :: _ => fun equ => exist _ x _
          end eq_refl).

The proof is also very similar, and are left to read as an exercise for passionate readers.

  + destruct l as [l falso]; cbn in *.
    rewrite equ in falso.
    exfalso.
    now apply falso.
  + exists l0.
    now rewrite equ.
Defined.

Finally, the extracted code is as straightforward as it can get.

let head = function
| Nil -> assert false (* absurd case *)
| Cons (a, l0) -> a

Conclusion

Writing strongly specified functions allows for reasoning about the result correctness while computing it. This can help in practice. However, writing these functions with the refine tactic does not enable a very idiomatic Coq code.

To improve the situation, the Program framework distributed with the Coq standard library helps, but it is better to understand what Program achieves under its hood, which is basically what we have done in this article.

Thomas Letan's Blog - coq

Implementing an Echo Server in Coq with coqffi.1.0.0

Implementing an Echo Server in Coq with coqffi.1.0.0

Project Layout

FFI Bindings

Sockets

Process Management

Implementing an Echo Server

Extracting and Building an Executable

Appendix

The Socket OCaml Module

The Proc OCaml Module

coqffi.1.0.0 In A Nutshell

coqffi.1.0.0 In A Nutshell

Getting Started

Requirements

Installing coqffi

Additional Dependencies

Primitive Types

Code Generation

Types

Pure values

Impure Primitives

simple-io

interface

freespec

Asynchronous Primitives

Exceptions

Modules

Moving Forward

Pattern Matching on Types and Contexts

Pattern Matching on Types and Contexts

To lazymatch or to match

Pattern Matching on Types with type of

Pattern Matching on the Context with goal

Ltac is an Imperative Metaprogramming Language

Ltac is an Imperative Metaprogramming Language

Mixing Ltac and Gallina for Fun and Profit

Mixing Ltac and Gallina for Fun and Profit

A Tale of Two Worlds, and Some Bridges

Beware the Automation Elephant in the Room

Proving Algebraic Datatypes are “Algebraic”

Proving Algebraic Datatypes are “Algebraic”

An Equivalence for Type

Introducing type_equiv

type_equiv is an Equivalence

type_equiv is reflexive

type_equiv is symmetric

type_equiv is transitive

Conclusion

Examples

list’s canonical form

list is a morphism

nat is a special purpose list

Non-empty lists

The sum Operator

sum Is a Morphism

sum Is Commutative

sum Is Associative

sum Has A Neutral Element

The prod Operator

prod Is A Morphism

prod Is Commutative

prod Is Associative

prod Has A Neutral Element

prod Has An Absorbing Element *)

prod And sum Distributivity

Bonus: Algebraic Datatypes and Metaprogramming

A Study of Clight and its Semantics

A Study of Clight and its Semantics

Installing CompCert

Problem Statement

Proof Walkthrough

Conclusion

Rewriting in Coq

Rewriting in Coq

Case Study: Gate System

Gate Equality

Leibniz Equality Is Too Strong

Ah-Hoc Equivalence Relation

Implementing an Echo Server in Coq with `coqffi.1.0.0`

The `Socket` OCaml Module

The `Proc` OCaml Module

`coqffi.1.0.0` In A Nutshell

Installing `coqffi`

`simple-io`

`interface`

`freespec`

To `lazymatch` or to `match`

Pattern Matching on Types with `type of`

Pattern Matching on the Context with `goal`

An Equivalence for `Type`

Introducing `type_equiv`

`type_equiv` is an Equivalence

`type_equiv` is reflexive

`type_equiv` is symmetric

`type_equiv` is transitive

`list`’s canonical form

`list` is a morphism

`nat` is a special purpose `list`

The `sum` Operator

`sum` Is a Morphism

`sum` Is Commutative

`sum` Is Associative

`sum` Has A Neutral Element

The `prod` Operator

`prod` Is A Morphism

`prod` Is Commutative

`prod` Is Associative

`prod` Has A Neutral Element

`prod` Has An Absorbing Element *)

`prod` And `sum` Distributivity

`Gate` Equality

Implementing Strongly-Specified Functions with the `Program` Framework

Implementing Strongly-Specified Functions with the `refine` Tactic

Defining the `empty` Predicate

Defining a decidable version of `empty`

Defining `empty_b`

Defining `pop`

Defining `push`

Defining `head`