I recently started a post-doc in the Gallium team, and it is past due-time for my first blog post. I will not start with a research oriented blog right now (but stay tuned!); and I will rather talk about one of my hobbies: writing Coq plugins in OCaml to build new tactics. I reckon that this deviates a bit from standard practice, so I will try to make things clear.

First, a Coq proof script is usually a program written in LTac. Executing a proof script builds incrementally a proof-term. The tactics themselves are not trusted: at Qed time, Coq checks that the proof term that was built is well-typed and that its type is the same as the statement of the theorem. One must remember that LTac tactics can always be understood in terms of manipulations of partial proof terms; and it is often instructive to get an idea of the proof term that is being built, using the Show Proof vernacular command.

Usually, one build new tactics in LTac. LTac is a powerful domain-specific language with some interesting programming constructs, and it is possible to build powerful new tactics using a few combinators and leveraging the existing automation (builtin tactics, decision procedures and so on). I have read that LTac is vindicated as one of the strong points of Coq, and part of me agree with that statement: there is a lot of use cases in which LTac is a good tool. Yet, writing a LTac tactic is often tedious, the code that needs to be written is hard to debug, and it may be quite inefficient.

The alternative is to write custom tactics in OCaml, the meta-language that is used to implement Coq (and all the primitive tactics). In the following, I will demonstrate how to write such a tactic, and give you a handful of the necessary entry points into Coq’s code.

The tactic that we are going to code is the following one, shamefully stolen from Compcert’s code.

Lemma modusponens: forall (P Q: Prop), P -> (P -> Q) -> Q.
Proof. auto. Qed.

Ltac exploit x :=
   refine (modusponens _ _ (x _ _ _ _ _ _ _ _ _ _ _) _)
|| refine (modusponens _ _ (x _ _ _ _ _ _ _ _ _ _) _)
(* Lots of lines elided.  The actual code handle cases upto 
  35 arguments *)
|| refine (modusponens _ _ (x _ _ _) _)
|| refine (modusponens _ _ (x _ _) _)
|| refine (modusponens _ _ (x _) _).

What does exploit do ? Well, the best thing is to give an example. In the following context,

A, B, C, D, G : Prop
H : A -> B -> C -> D
============================
G

exploit H will produce four sub-goals in which the user needs to prove A, B, C, and D -> G. That is, the exploit tactic is a generalized version of the modus-ponens.

This tactic has two drawbacks. First, it is a bit inefficient: it tries to apply the modusponens theorem to x applied to a decreasing number of arguments (obviously we do not want to get two subgoals A and (B -> C -> D) -> G). Yet, this is a pity, because most of the time, the right application has a low number of arguments, and the execution of exploit must go through twenty-something failures before reaching a successful of refine. The second drawback is that one has to repeat by hand the same pattern (x followed by a given number of holes), to handle all reasonable use-cases of the tactic.

Now, we probably could imagine other (LTac) implementations of exploit, but it is not the point of this article, and you should definitely not try to do that at home! What we will do is implement this tactic as 9 lines long tactic in an OCaml plugin, way shorter than the LTac implementation.

Here we go.

 
let exploit (c: Termconstr) = fun gl ->  
(* the type of [c] is [ty] *)
let ty = Tacmachpf_type_of gl c in 

(* In the general case, [ty] can be written as [forall (x1:t1)
... (xn:tn), t]. We decompose this arity in two parts: [ctx] which
is [(xn, tn); ...; (x1,t1)] and the conclusion [t] *)
let ctx, t = Termdecompose_prod_assum ty in

(* We will also need the type of the conclusion of the goal *)
let concl = Tacmachpf_concl gl in

We encounter functions from two modules here:

  • coq-v8.4/kernel/term.ml contains the definition of Coq terms, the constr data-type, and various operations on it. For instance, decompose_prod_assum takes as arguments a constr and decomposes it into two parts: a telescope of products (that is, a context cxt), and the final type t. At this point, it is crucial to note that this manipulation of terms is very syntactic: the term t may contain de Bruijn indices that refers to variables bound in the context. Therefore, we shall manipulate t with some care and not forget to, e.g., lift it when needed.

  • coq-v8.4/proofs/tacmach.ml contains the API that I use most often to interact with the proof machinery. For instance, pf_type_of takes as argument the current proof environment (that is, the goal, the typing context, and so on) and a constr, and returns its coq type. The function pf_concl returns the conclusion of the current goal.

All in all, the above snippet is quite straightforward: get the type of the argument of the tactic, and the conclusion of the current goal. Nothing fancy, but here comes the meaty stuff.

Recall that a tactic builds a partial proof-term, which is a regular Coq term. Here, the proof-term that we want to generate is

(fun (x1:t1) ... (xn:tn) (m : t -> concl) => m (c x1 ... xn))

(intuitively, if we were to apply this term in Coq, we would get a sub-goal for each of the arguments of the function)

let pf_body =
  TermmkApp (TermmkRel 1,
              [| TermmkApp (c, Termopsextended_rel_vect 1 ctx) |])

The term pf_body corresponds to the internal representation of the above m (c x1 ... xn). As should be obvious with their names, the function Term.mkApp builds an application, and Term.mkRel builds a term that is a de Bruijn index that points to the nearest binder. The function Termops.extended_rel_vect is slightly more complicated: it builds a vector of de Bruijn indices, lifted by 1.

Now, we need to build the fun part. We build exactly one lambda for each product that occurred in the type of the term c, plus one for the parameter of type t -> concl. To do so, we simply extend the former context with a new definition. (Note here that the type t may depend on the context ctx. Yet, there is no need to lift t, because it is used in the exact same context as before; and concl should be a closed term.)

let ctx = (NamesAnonymous,None, TermmkArrow t concl ) :: ctx in 
let pf_term = Termit_mkLambda_or_LetIn pf_body ctx in

The function Term.it_mkLambda_or_LetIn iterates the function that creates a lambda, for each of the elements of the context ctx. Finally, we can call the built-in apply tactics to finish the job.

Tacticsapply pf_term gl

There is one wrinkle here: with my version of Coq, the sub-goals that are generated are not in the same order as with the LTac version (which is a problem if we have to deal with backward compatibility of proof-scripts). More precisely, the proof obligation that corresponds to t -> concl comes first. In order to avoid this problem, we will rely on a slightly more arcane piece of code.

Tacticsapply_term
  pf_term (Listmap (fun _ -> Evarutilmk_new_meta ()) ctx) gl

The function apply_term seems to be a variant of apply to which we give a term, and a list of arguments to which the term is applied. Here, we provide as arguments a bunch of _ (in the same fashion as we would have done for refine). For a reason that I do not fully grasp, this gives us exactly the same sub-goals as the above LTac exploit.

The last line of our OCaml plugin enrichs Coq’s tactic environments with our new tactic. This declaration is made of three parts: a unique identifier foobar (that is used internally by Coq), the syntax extension, and the actual OCaml code of the tactic (here, we simply wrap a call to exploit):

TACTIC EXTEND foobar
  | ["exploit" constr(c)] -> [exploit c]
END;;

And that’s it: mission accomplished.

There is one extra benefit to our brand new implementation of exploit: the former version was not working properly if it was given a theorem of type, e.g., A -> B -> ~C. Let D be the goal, the sub-goals that were generated were A, B, C and False -> D. This short-coming is solved with our new implementation.

In the end, our new tactic is 9 lines long, compared to 20 something repetitions of the same pattern in the LTac implementation. (To be honest, we omit on this 9 lines count a few lines of boilerplate that must be written for each new OCaml tactic, like the makefile that is needed to compile the plugin.)

Moving to OCaml, we lost the safety-belt that is provided by LTac: for instance, it is possible to get the de Bruijn indices wrong by one when we build a proof-term. But it gives us the full power of the best programming language ever ;) to build our new tactics.

The plugin that was build in this tutorial is available from the public GitHub repository here. From the root of the repository

make
make -f Makefile.coq install

should install the plugin in your Coq plugins directory. Then, it suffices to use the vernacular Require Exploit. to be able to use the exploit tactic, from any coq development.