Like its built-in programming language, Coq's built-in logic is extremely small: Inductive definitions, universal quantification (∀), and implication (→) are primitive, but all the other familiar logical connectives — conjunction, disjunction, negation, existential quantification, even equality — can be defined using just these.

Quantification and Implication

In fact, → and ∀ are the same primitive! Coq's → notation is actually just a shorthand for ∀. The ∀ notation is more general, because it allows us to name the hypothesis. For example, consider this proposition:

If we had a proof term inhabiting this proposition, it would be a function with two arguments: a number n and some evidence that n is even. But the name E for this evidence is not used in the rest of the statement of funny_prop1, so it's a bit silly to bother making up a name. We could write it like this instead:

Or we can write it in more familiar notation:

This illustrates that "P → Q" is just syntactic sugar for "∀ (_:P), Q".

Conjunction

The logical conjunction of propositions P and Q is represented using an Inductive definition with one constructor.

Note that, like the definition of ev in the previous chapter, this definition is parameterized; however, in this case, the parameters are themselves propositions, rather than numbers. The intuition behind this definition is simple: to construct evidence for and P Q, we must provide evidence for P and evidence for Q. More precisely:

• conj p q can be taken as evidence for and P Q if p is evidence for P and q is evidence for Q; and
• this is the only way to give evidence for and P Q — that is, if someone gives us evidence for and P Q, we know it must have the form conj p q, where p is evidence for P and q is evidence for Q.

Since we'll be using conjunction a lot, let's introduce a more familiar-looking infix notation for it.

(The type_scope annotation tells Coq that this notation will be appearing in propositions, not values.) Consider the "type" of the constructor conj:

Notice that it takes 4 inputs — namely the propositions P and Q and evidence for P and Q — and returns as output the evidence of P ∧ Q. Besides the elegance of building everything up from a tiny foundation, what's nice about defining conjunction this way is that we can prove statements involving conjunction using the tactics that we already know. For example, if the goal statement is a conjuction, we can prove it by applying the single constructor conj, which (as can be seen from the type of conj) solves the current goal and leaves the two parts of the conjunction as subgoals to be proved separately.

Let's take a look at the proof object for the above theorem.

Note that the proof is of the form which is what you'd expect, given the type of conj. Just for convenience, we can use the tactic split as a shorthand for apply conj.

Conversely, the inversion tactic can be used to take a conjunction hypothesis in the context, calculate what evidence must have been used to build it, and put this evidence into the proof context.

Exercise: 1 star, optional (proj2)

☐

Once again, we have commented out the Case tactics to make the proof object for this theorem easy to understand. Examining it shows that all that is really happening is taking apart a record containing evidence for P and Q and rebuilding it in the opposite order:

Exercise: 2 stars (and_assoc)

In the following proof, notice how the nested pattern in the inversion breaks H : P ∧ (Q ∧ R) down into HP: P, HQ : Q, and HR : R. Finish the proof from there:

☐

Exercise: 2 stars, recommended (even_ev)

Now we can prove the other direction of the equivalence of even and ev, which we left hanging in the last chapter. Notice that the left-hand conjunct here is the statement we are actually interested in; the right-hand conjunct is needed in order to make the induction hypothesis strong enough that we can carry out the reasoning in the inductive step. (To see why this is needed, try proving the left conjunct by itself and observe where things get stuck.)

☐

Exercise: 2 stars

Construct a proof object demonstrating the following proposition.

☐

Iff

The familiar logical "if and only if" is just the conjunction of two implications.

Exercise: 1 star (iff_properties)

Using the above proof that ↔ is symmetric (iff_sym) as a guide, prove that it is also reflexive and transitive.

Hint: If you have an iff hypothesis in the context, you can use inversion to break it into two separate implications. (Think about why this works.) ☐

Exercise: 2 stars (MyProp_iff_ev)

We have seen that the families of propositions MyProp and ev actually characterize the same set of numbers (the even ones). Prove that MyProp n ↔ ev n for all n. Just for fun, write your proof as an explicit proof object, rather than using tactics. (Hint: if you make use of previously defined thoerems, you should only need a single line!)

☐ Some of Coq's tactics treat iff statements specially, thus avoiding the need for some low-level manipulation when reasoning with them. In particular, rewrite can be used with iff statements, not just equalities.

Disjunction

Disjunction ("logical or") can also be defined as an inductive proposition.

Consider the "type" of the constructor or_introl:

It takes 3 inputs, namely the propositions P,Q and evidence of P, and returns as output, the evidence of P ∧ Q. Next, look at the type of or_intror:

It is like or_introl but it requires evidence of Q instead of evidence of P. Intuitively, there are two ways of giving evidence for P ∨ Q:

• give evidence for P (and say that it is P you are giving evidence for! — this is the function of the or_introl constructor), or
• give evidence for Q, tagged with the or_intror constructor.

Since P ∨ Q has two constructors, doing inversion on a hypothesis of type P ∨ Q yields two subgoals.

From here on, we'll use the shorthand tactics left and right in place of apply or_introl and apply or_intror.

Exercise: 2 stars, optional (or_commut'')

Try to write down an explicit proof object for or_commut (without using Print to peek at the ones we already defined!).

☐

Exercise: 2 stars, recommended (or_distributes_over_and_2)

☐

Exercise: 1 star (or_distributes_over_and)

☐

Relating ∧ and ∨ with andb and orb

We've already seen several places where analogous structures can be found in Coq's computational (Type) and logical (Prop) worlds. Here is one more: the boolean operators andb and orb are obviously analogs, in some sense, of the logical connectives ∧ and ∨. This analogy can be made more precise by the following theorems, which show how to translate knowledge about andb and orb's behaviors on certain inputs into propositional facts about those inputs.

Exercise: 1 star (bool_prop)

☐

Falsehood

Logical falsehood can be represented in Coq as an inductively defined proposition with no constructors.

Intuition: False is a proposition for which there is no way to give evidence.

Exercise: 1 star (False_ind_principle)

Can you predict the induction principle for falsehood?

☐ Since False has no constructors, inverting an assumption of type False always yields zero subgoals, allowing us to immediately prove any goal.

How does this work? The inversion tactic breaks contra into each of its possible cases, and yields a subgoal for each case. As contra is evidence for False, it has no possible cases, hence, there are no possible subgoals and the proof is done. Conversely, the only way to prove False is if there is already something nonsensical or contradictory in the context:

Actually, since the proof of False_implies_nonsense doesn't actually have anything to do with the specific nonsensical thing being proved; it can easily be generalized to work for an arbitrary P:

The Latin ex falso quodlibet means, literally, "from falsehood follows whatever you please." This theorem is also known as the principle of explosion.

Truth

Since we have defined falsehood in Coq, we might wonder whether it is possible to define truth in the same way. Naturally, the answer is yes.

Exercise: 2 stars (True_induction)

Define True as another inductively defined proposition. What induction principle will Coq generate for your definition? (The intution is that True should be a proposition for which it is trivial to give evidence. Alternatively, you may find it easiest to start with the induction principle and work backwards to the inductive definition.)

☐ However, unlike False, which we'll use extensively, True is just a theoretical curiosity: it is trivial (and therefore uninteresting) to prove as a goal, and it carries no useful information as a hypothesis.

Negation

The logical complement of a proposition P is written not P or, for shorthand, ~P:

The intuition is that, if P is not true, then anything at all (even False) follows from assuming P.

It takes a little practice to get used to working with negation in Coq. Even though you can see perfectly well why something is true, it can be a little hard at first to get things into the right configuration so that Coq can see it! Here are proofs of a few familiar facts about negation to get you warmed up.

Exercise: 2 stars, recommended (double_neg_inf)

Write an informal proof of double_neg: Theorem: P implies ~~P, for any proposition P. Proof: (* FILL IN HERE *)
☐

Exercise: 2 stars, recommended (contrapositive)

☐

Exercise: 1 star (not_both_true_and_false)

☐

Exercise: 1 star ev_not_ev_S

Theorem five_not_even confirms the unsurprising fact that five is not an even number. Prove this more interesting fact:

☐

Exercise: 1 star (informal_not_PNP)

Write an informal proof (in English) of the proposition ∀ P : Prop, ~(P ∧ ~P).

☐ Note that some theorems that are true in classical logic are not provable in Coq's "built in" constructive logic...

Exercise: 5 stars, optional (classical_axioms)

For those who like a challenge, here is an exercise taken from the Coq'Art book (p. 123). The following five statements are often considered as characterizations of classical logic (as opposed to constructive logic, which is what is "built in" to Coq). We can't prove them in Coq, but we can consistently add any one of them as an unproven axiom if we wish to work in classical logic. Prove that these five propositions are equivalent.

☐

Inequality

Saying x <> y is just the same as saying ~(x = y).

Since inequality involves a negation, it again requires a little practice to be able to work with it fluently. Here is one very useful trick. If you are trying to prove a goal that is nonsensical (e.g., the goal state is false = true), apply the lemma ex_falso_quodlibet to change the goal to False. This makes it easier to use assumptions of the form ~P that are available in the context — in particular, assumptions of the form x<>y.

Exercise: 2 stars, recommended (not_eq_beq_false)

☐

Exercise: 2 stars, optional (beq_false_not_eq)

☐

Existential Quantification

Another critical logical connective is existential quantification. We can capture what this means with the following definition:

That is, ex is a family of propositions indexed by a type X and a property P over X. In order to give evidence for the assertion "there exists an x for which the property P holds" we must actually name a witness — a specific value x — and then give evidence for P x, i.e., evidence that x has the property P. For example, consider this existentially quantified proposition:

To prove this proposition, we need to choose a particular number as witness — say, 4 — and give some evidence that that number is even.

Coq's notation definition facility can be used to introduce more familiar notation for writing existentially quantified propositions, exactly parallel to the built-in syntax for universally quantified propositions. Instead of writing ex nat ev to express the proposition that there exists some number that is even, for example, we can write ∃ x:nat, ev x. (It is not necessary to understand exactly how the Notation definition works.)

We can use the same set of tactics as always for manipulating existentials. For example, if to prove an existential, we apply the constructor ex_intro. Since the premise of ex_intro involves a variable (witness) that does not appear in its conclusion, we need to explicitly give its value when we use apply.

Note, again, that we have to explicitly give the witness. Or, instead of writing apply ex_intro with (witness:=e) all the time, we can use the convenient shorthand ∃ e, which means the same thing.

Conversely, if we have an existential hypothesis in the context, we can eliminate it with inversion. Note the use of the as... pattern to name the variable that Coq introduces to name the witness value and get evidence that the hypothesis holds for the witness. (If we don't explicitly choose one, Coq will just call it witness, which makes proofs confusing.)

Exercise: 1 star (english_exists)

In English, what does the proposition mean?

Complete the definition of the following proof object:

☐

Exercise: 1 star (dist_not_exists)

Prove that "P holds for all x" and "there is no x for which P does not hold" are equivalent assertions.

☐

Exercise: 3 stars, optional (not_exists_dist)

The other direction requires the classical "law of the excluded middle":

☐

Exercise: 2 stars (dist_exists_or)

Prove that existential quantification distributes over disjunction.

☐

Equality

Even Coq's equality relation is not built in. It has the following inductive definition. (We enclose the definition in a module to avoid confusion with the standard library equality, which we have used extensively already.)

Standard infix notation (using Coq's type argument synthesis):

This is a bit subtle. The way to think about it is that, given a set X, it defines a family of propositions "x is equal to y," indexed by pairs of values (x and y) from X. There is just one way of constructing evidence for members of this family: applying the constructor refl_equal to a type X and a value x : X yields evidence that x is equal to x. Here is a slightly different definition — the one that actually appears in the Coq standard library.

Exercise: 3 stars, optional (two_defs_of_eq_coincide)

Verify that the two definitions of equality are equivalent.

☐ The advantage of the second definition is that the induction principle that Coq derives for it is precisely the familiar principle of Leibniz equality: what we mean when we say "x and y are equal" is that every property on P that is true of x is also true of y.

One important consideration remains. Clearly, we can use refl_equal to construct evidence that, for example, 2 = 2. Can we also use it to construct evidence that 1 + 1 = 2? Yes. Indeed, it is the very same piece of evidence! The reason is that Coq treats as "the same" any two terms that are convertible according to a simple set of computation rules. These rules, which are similar to those used by Eval simpl, include evaluation of function application, inlining of definitions, and simplification of matches. In tactic-based proofs of equality, the conversion rules are normally hidden in uses of simpl (either explicit or implicit in other tactics such as reflexivity). But you can see them directly at work in the following explicit proof objects:

Inversion, Again

We've seen inversion used with both equality hypotheses and hypotheses about inductively defined propositions. Now that we've seen that these are actually the same thing, we're in a position to take a closer look at how inversion behaves... In general, the inversion tactic

• takes a hypothesis H whose type is some inductively defined proposition P, and
• for each constructor C in P's definition,
  • generates a new subgoal in which we assume H was built with C,
  • adds the arguments (premises) of C to the context of the subgoal as extra hypotheses,
  • matches the conclusion (result type) of C against the current goal and calculates a set of equalities that must hold in order for C to be applicable,
  • adds these equalities to the context of the subgoal, and
  • if the equalities are not satisfiable (e.g., they involve things like S n = O), immediately solves the subgoal.

Example: If we invert a hypothesis built with or, there are two constructors, so two subgoals get generated. The conclusion (result type) of the constructor (P ∨ Q) doesn't place any restrictions on the form of P or Q, so we don't get any extra equalities in the context of the subgoal. Example: If we invert a hypothesis built with and, there is only one constructor, so only one subgoal gets generated. Again, the conclusion (result type) of the constructor (P ∧ Q) doesn't place any restrictions on the form of P or Q, so we don't get any extra equalities in the context of the subgoal. The constructor does have two arguments, though, and these can be seen in the context in the subgoal. Example: If we invert a hypothesis built with eq, there is again only one constructor, so only one subgoal gets generated. Now, though, the form of the refl_equal constructor does give us some extra information: it tells us that the two arguments to eq must be the same! The inversion tactic adds this fact to the context.

Relations as Propositions

A proposition parameterized numbers (such as ev) can be thought of as a property — i.e., it defines a subset of nat, namely those numbers for which the proposition is provable. In the same way, a two-argument proposition can be thought of as a relation — i.e., it defines a set of pairs for which the proposition is provable.

We've already seen an inductive definition of one fundamental relation: equality. Another useful one is the "less than or equal to" relation on numbers: This definition should be fairly intuitive. It says that there are two ways to give evidence that one number is less than or equal to another: either observe that they are the same number, or give evidence that the first is less than or equal to the predecessor of the second.

This is a reasonable definition of the <= relation, but we can streamline it a little by observing that the left-hand argument n is the same everywhere in the definition, so we can actually make it a "general parameter" to the whole definition, rather than an argument to each constructor. This is similar to what we did in our second definition of the eq relation, above.

The second one is better, even though it looks less symmetric. Why? Because it gives us a simpler induction principle. (The same was true of our second version of eq.)

By contrast, the induction principle that Coq calculates for the first definition has a lot of extra quantifiers, which makes it messier to work with when proving things by induction. Here is the induction principle for the first le:

Proofs of facts about <= using the constructors le_n and le_S follow the same patterns as proofs about properties, like ev in the previous chapter. We can apply the constructors to prove <= goals (e.g., to show that 3<=3 or 3<=6), and we can use tactics like inversion to extract information from <= hypotheses in the context (e.g., to prove that ~(2 <= 1).) Here are some sanity checks on the definition. (Notice that, although these are the same kind of simple "unit tests" as we gave for the testing functions we wrote in the first few lectures, we must construct their proofs explicitly — simpl and reflexivity don't do the job, because the proofs aren't just a matter of simplifying computations.

The "strictly less than" relation n < m can now be defined in terms of le.

Here are a few more simple relations on numbers:

Exercise: 2 stars, recommended (total_relation)

Define an inductive relation total_relation that holds between every pair of natural numbers.

☐

Exercise: 2 stars (empty_relation)

Define an inductive relation empty_relation (on numbers) that never holds.

☐

Exercise: 3 stars, recommended (R_provability)

We can define three-place relations, four-place relations, etc., in just the same way as binary relations. For example, consider the following three-place relation on numbers:

• Which of the following propositions are provable?
  • R 1 1 2
  • R 2 2 6
• If we dropped constructor c5 from the definition of R, would the set of provable propositions change? Briefly (1 sentence) explain your answer.
• If we dropped constructor c4 from the definition of R, would the set of provable propositions change? Briefly (1 sentence) explain your answer.

(* FILL IN HERE *)
☐

Exercise: 3 stars, optional (R_fact)

State and prove an equivalent characterization of the relation R. That is, if R m n o is true, what can we say about m, n, and o, and vice versa?

☐

Exercise: 3 stars, recommended (all_forallb)

Inductively define a property all of lists, parameterized by a type X and a property P : X → Prop, such that all X P l asserts that P is true for every element of the list l.

Recall the function forallb, from the exercise forall_exists_challenge in Poly.v:

Using the property all, write down a specification for forallb, and prove that it satisfies the specification. Try to make your specification as precise as possible. Are there any important properties of the function forallb which are not captured by your specification?

☐

Exercise: 4 stars, optional (filter_challenge)

One of the main purposes of Coq is to prove that programs match their specifications. To this end, let's prove that our definition of filter matches a specification. Here is the specification, written out informally in English. Suppose we have a set X, a function test: X→bool, and a list l of type list X. Suppose further that l is an "in-order merge" of two lists, l1 and l2, such that every item in l1 satisfies test and no item in l2 satisfies test. Then filter test l = l1. A list l is an "in-order merge" of l1 and l2 if it contains all the same elements as l1 and l2, in the same order as l1 and l2, but possibly interleaved. For example, is an in-order merge of and Your job is to translate this specification into a Coq theorem and prove it. (Hint: You'll need to begin by defining what it means for one list to be a merge of two others. Do this with an inductive relation, not a Fixpoint.)

☐

Exercise: 5 stars, optional (filter_challenge_2)

A different way to formally characterize the behavior of filter goes like this: Among all subsequences of l with the property that test evaluates to true on all their members, filter test l is the longest. Express this claim formally and prove it.

☐

Exercise: 4 stars, optional (no_repeats)

The following inductively defined proposition...

...gives us a precise way of saying that a value a appears at least once as a member of a list l. Here's a pair of warm-ups about appears_in.

Now use appears_in to define a proposition disjoint X l1 l2, which should be provable exactly when l1 and l2 are lists (with elements of type X) that have no elements in common.

Next, use appears_in to define an inductive proposition no_repeats X l, which should be provable exactly when l is a list (with elements of type X) where every member is different from every other. For example, no_repeats nat [1,2,3,4] and no_repeats bool [] should be provable, while no_repeats nat [1,2,1] and no_repeats bool [true,true] should not be.

Finally, state and prove one or more interesting theorems relating disjoint, no_repeats and ++ (list append).

☐

Digression: More Facts about <= and <

Let's pause briefly to record several facts about the <= and < relations that we are going to need later in the course. The proofs make good practice exercises.

Exercise: 2 stars, optional (le_exercises)

☐

Exercise: 3 stars, recommended (nostutter)

Formulating inductive definitions of predicates is an important skill you'll need in this course. Try to solve this exercise without any help at all. If you do receive assistance from anyone, please say so specifically in a comment. We say that a list of numbers "stutters" if it repeats the same number consecutively. The predicate "nostutter mylist" means that mylist does not stutter. Formulate an inductive definition for nostutter. (This is different from the no_repeats predicate in the exercise above; the sequence 1,4,1 repeats but does not stutter.)

Make sure each of these tests succeeds, but you are free to change the proof if the given one doesn't work for you. Your definition might be different from mine and still correct, in which case the examples might need a different proof. The suggested proofs for the examples (in comments) use a number of tactics we haven't talked about, to try to make them robust with respect to different possible ways of defining nostutter. You should be able to just uncomment and use them as-is, but if you prefer you can also prove each example with more basic tactics.

☐

Exercise: 4 stars, optional (pigeonhole principle)

The "pigeonhole principle" states a basic fact about counting: if you distribute more than n items into n pigeonholes, some pigeonhole must contain at least two items. As is often the case, this apparently trivial fact about numbers requires non-trivial machinery to prove, but we now have enough... First a pair of useful lemmas... (we already proved this for lists of naturals, but not for arbitrary lists.)

Now define a predicate repeats (analogous to no_repeats in the exercise above), such that repeats X l asserts that l contains at least one repeated element (of type X).

Now here's a way to formalize the pigeonhole principle. List l2 represents a list of pigeonhole labels, and list l1 represents an assignment of items to labels: if there are more items than labels, at least two items must have the same label. You will almost certainly need to use the excluded_middle hypothesis.

☐

Optional Material

Induction Principles for ∧ and ∨

The induction principles for conjunction and disjunction are a good illustration of Coq's way of generating simplified induction principles for Inductively defined propositions, which we discussed in the last chapter. You try first:

Exercise: 1 star (and_ind_principle)

See if you can predict the induction principle for conjunction.

☐

Exercise: 1 star (or_ind_principle)

See if you can predict the induction principle for disjunction.

☐

From the inductive definition of the proposition and P Q we might expect Coq to generate this induction principle but actually it generates this simpler and more useful one: In the same way, when given the inductive definition of or P Q instead of the "maximal induction principle" what Coq actually generates is this:

Explicit Proof Objects for Induction

Although tactic-based proofs are normally much easier to work with, the ability to write a proof term directly is sometimes very handy, particularly when we want Coq to do something slightly non-standard. Recall the induction principle on naturals that Coq generates for us automatically from the Inductive declation for nat.

There's nothing magic about this induction lemma: it's just another Coq lemma that requires a proof. Coq generates the proof automatically too...

We can read this as follows: Suppose we have evidence f that P holds on 0, and evidence f0 that ∀ n:nat, P n → P (S n). Then we can prove that P holds of an arbitrary nat n via a recursive function F (here defined using the expression form Fix rather than by a top-level Fixpoint declaration). F pattern matches on n:

• If it finds 0, F uses f to show that P n holds.
• If it finds S n0, F applies itself recursively on n0 to obtain evidence that P n0 holds; then it applies f0 on that evidence to show that P (S n) holds.

F is just an ordinary recursive function that happens to operate on evidence in Prop rather than on terms in Set. Aside to those interested in functional programming: You may notice that the match in F requires an annotation as n0 return (P n0) to help Coq's typechecker realize that the two arms of the match actually return the same type (namely P n). This is essentially like matching over a GADT in Haskell. In fact, F has a dependent type: its result type depends on its argument; GADT's can be used to describe simple dependent types like this. We can adapt this approach to proving nat_ind to help prove non-standard induction principles too. Recall our desire to prove that ∀ n : nat, even n → ev n. Attempts to do this by standard induction on n fail, because the induction principle only lets us proceed when we can prove that even n → even (S n) — which is of course never provable. What we did earlier in this chapter was a bit of a hack: Theorem even_ev : ∀ n : nat, (even n → ev n) ∧ (even (S n) → ev (S n)). We can make a much better proof by defining and proving a non-standard induction principle that goes "by twos":

Once you get the hang of it, it is entirely straightforward to give an explicit proof term for induction principles like this. Proving this as a lemma using tactics is much less intuitive (try it!). The induction ... using tactic gives a convenient way to specify a non-standard induction principle like this.

The Coq Trusted Computing Base

One issue that arises with any automated proof assistant is "why trust it?": what if there is a bug in the implementation that renders all its reasoning suspect? While it is impossible to allay such concerns completely, the fact that Coq is based on the Curry-Howard Correspondence gives it a strong foundation. Because propositions are just types and proofs are just terms, checking that an alleged proof of a proposition is valid just amounts to type-checking the term. Type checkers are relatively small and straightforward programs, so the "trusted computing base" for Coq — the part of the code that we have to believe is operating correctly — is small too. What must a typechecker do? Its primary job is to make sure that in each function application the expected and actual argument types match, that the arms of a match expression are constructor patterns belonging to the inductive type being matched over and all arms of the match return the same type, and so on. There are a few additional wrinkles:

• Since Coq types can themselves be expressions, the checker must normalize these (by using the conversion rules) before comparing them.
• The checker must make sure that match expressions are exhaustive. That is, there must be an arm for every possible constructor. To see why, consider the following alleged proof object:
  Definition or_bogus : ∀ P Q, P ∨ Q → P :=
    fun (P Q : Prop) (A : P ∨ Q) =>
       match A with
       | or_introl H => H
       end.
  All the types here match correctly, but the match only considers one of the possible constructors for or. Coq's exhaustiveness check will reject this definition.
• The checker must make sure that each fix expression terminates. It does this using a syntactic check to make sure that each recursive call is on a subexpression of the original argument. To see why this is essential, consider this alleged proof:
      Definition nat_false : ∀ (n:nat), False :=
         fix f (n:nat) : False := f n.
  Again, this is perfectly well-typed, but (fortunately) Coq will reject it.

Note that the soundness of Coq depends only on the correctness of this typechecking engine, not on the tactic machinery. If there is a bug in a tactic implementation (and this certainly does happen!), that tactic might construct an invalid proof term. But when you type Qed, Coq checks the term for validity from scratch. Only lemmas whose proofs pass the type-checker can be used in further proof developments.