A Series on Ltac

Mixing Ltac and Gallina for Fun and Profit

July 26, 2020

Mixing Ltac and Gallina for Fun and Profit

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.

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.

A Series on Ltac

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

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

To `lazymatch` or to `match`

Pattern Matching on Types with `type of`

Pattern Matching on the Context with `goal`