## 4.5 Inductive Definitions

A (possibly mutual) inductive definition is specified by giving the names and the type of the inductive sets or families to be defined and the names and types of the constructors of the inductive predicates. An inductive declaration in the environment can consequently be represented with two contexts (one for inductive definitions, one for constructors).
Stating the rules for inductive definitions in their general form needs quite tedious definitions. We shall try to give a concrete understanding of the rules by precising them on running examples. We take as examples the type of natural numbers, the type of parameterized lists over a type A, the relation which state that a list has some given length and the mutual inductive definition of trees and forests.

### 4.5.1 Representing an inductive definition

#### Inductive definitions without parameters

As for constants, inductive definitions can be defined in a non-empty context.
We write Ind(G)(GI:=GC ) an inductive definition valid in a context G, a context of definitions GI and a context of constructors GC.

##### Examples.

The inductive declaration for the type of natural numbers will be:
Ind()(nat:Set:=O:nat,S:nat®nat )
In a context with a variable A:Set, the lists of elements in A is represented by:
Ind(A:Set)(List:Set:=nil:List,cons : A ® List ® List )
Assuming GI is [I1:A1;...;Ik:Ak], and GC is [c1:C1;...;cn:Cn], the general typing rules are:

Ind(G)(GI:=GC ) Î E j=1... k
(Ij:Aj) Î E

Ind(G)(GI:=GC ) Î E i=1.. n
(ci:Ci{Ij/Ij} |
j=1... k
| )Î E

#### Inductive definitions with parameters

We have to slightly complicate the representation above in order to handle the delicate problem of parameters. Let us explain that on the example of List. As they were defined above, the type List can only be used in an environment where we have a variable A:Set. Generally one want to consider lists of elements in different types. For constants this is easily done by abstracting the value over the parameter. In the case of inductive definitions we have to handle the abstraction over several objects.
One possible way to do that would be to define the type List inductively as being an inductive family of type Set®Set:
Ind()(List:Set®Set:=nil:(A:Set)(List A),cons : (A:Set)A ® (List A) ® (List A) )
There are drawbacks to this point of view. The information which says that (List nat) is an inductively defined Set has been lost.
In the system, we keep track in the syntax of the context of parameters. The idea of these parameters is that they can be instantiated and still we have an inductive definition for which we know the specification.
Formally the representation of an inductive declaration will be Ind(G)[GP](GI:=GC ) for an inductive definition valid in a context G with parameters GP, a context of definitions GI and a context of constructors GC. The occurrences of the variables of GP in the contexts GI and GC are bound.
The definition Ind(G)[GP](GI:=GC ) will be well-formed exactly when Ind(G,GP)(GI:=GC ) is. If GP is [p1:P1;...;pr:Pr], an object in Ind(G)[GP](GI:=GC ) applied to q1,...,qr will behave as the corresponding object of Ind(G)(GI{(pi/qi)i=1..r}:=GC{(pi/qi)i=1..r} ).

##### Examples

The declaration for parameterized lists is:
Ind()[A:Set](List:Set:=nil:List,cons : A ® List ® List )
The declaration for the length of lists is:
Ind()[A:Set](Length:(List A)® nat®Prop:=Lnil:(Length (nil A) O),
Lcons :(a:A)(l:(List A))(n:nat)(Length l n)® (Length (cons A a l) (S n)) )
The declaration for a mutual inductive definition of forests and trees is:
Ind([])(tree:Set,forest:Set:=node:forest ® tree, emptyf:forest,consf:tree ® forest ® forest )
These representations are the ones obtained as the result of the Coq declaration:
`Coq` `<``Inductive Set nat := O : nat | S : nat -``>``nat.`
`Coq` `<``Inductive list [A : Set] : Set :=`
`Coq` `<``nil : (list A) | cons : A -``>``(list A) -``>``(list A).`
`Coq` `<``Inductive Length [A:Set] : (list A) -``>``nat -``>``Prop :=`
`Coq` `<``Lnil : (Length A (nil A) O)`
`Coq` `<``| Lcons : (a:A)(l:(list A))(n:nat)`
`Coq` `<``(Length A l n)-``>``(Length A (cons A a l) (S n)).`
`Coq` `<``Mutual Inductive tree : Set := node : forest -``>``tree`
`Coq` `<``with forest : Set := emptyf : forest | consf : tree -``>``forest -``>``forest.`
The inductive declaration in Coq is slightly different from the one we described theoretically. The difference is that in the type of constructors the inductive definition is explicitly applied to the parameters variables. The Coq type-checker verifies that all parameters are applied in the correct manner in each recursive call. In particular, the following definition will not be accepted because there is an occurrence of List which is not applied to the parameter variable:
`Coq` `<``Inductive list' [A : Set] : Set :=`
`Coq` `<``nil' : (list' A) | cons' : A -``>``(list' A-``>``A) -``>``(list' A).`
`Error: The 1st argument of list' must be A in`
`A-``>``(list' A-``>``A)-``>``(list' A)`

### 4.5.2 Types of inductive objects

We have to give the type of constants in an environment E which contains an inductive declaration.

Ind-Const
  Assuming GP is [p1:P1;...;pr:Pr], GI is [I1:A1;...;Ik:Ak], and GC is [c1:C1;...;cn:Cn],

  Ind(G)[GP](GI:=GC ) Î E j=1... k
  (Ij:(p1:P1)...(pr:Pr)Aj) Î E

  Ind(G)[GP](GI:=GC ) Î E i=1.. n
  (ci:(p1:P1)...(pr:Pr)Ci{Ij/(Ij p1... pr)} |
  j=1... k
  | )Î E

##### Example.

We have (List:Set ® Set), (cons:(A:Set)A®(List A)® (List A)),
(Length:(A:Set)(List A)®nat®Prop), tree:Set and forest:Set.
From now on, we write List_A instead of (List A) and Length_A for (Length A).

### 4.5.3 Well-formed inductive definitions

We cannot accept any inductive declaration because some of them lead to inconsistent systems. We restrict ourselves to definitions which satisfy a syntactic criterion of positivity. Before giving the formal rules, we need a few definitions:

##### Definitions

A type T is an arity of sort s if it converts to the sort s or to a product (x:T)U with U an arity of sort s. (For instance A® Set or (A:Prop)A® Prop are arities of sort respectively Set and Prop). A type of constructor of I is either a term (I t1... tn) or (x:T)C with C a type of constructor of I.
The type of constructor T will be said to satisfy the positivity condition for a constant X in the following cases:

- T=(X t1... tn) and X does not occur free in any ti
- T=(x:T)U and X occurs only strictly positively in T and the type U satisfies the positivity condition for X

The constant X occurs strictly positively in T in the following cases:

- X does not occur in T
- T converts to (X t1 ... tn) and X does not occur in any of ti
- T converts to (x:U)V and X does not occur in type U but occurs strictly positively in type V
- T converts to (I a1 ... am t1 ... tp) where I is the name of an inductive declaration of the form Ind(G)[[p1:P1;...;pm:Pm]]([I:A]:=[c1:C1;...;cn:Cn] ) (in particular, it is not mutually defined and it has m parameters) and X does not occur in any of the ti, and the types of constructor Ci{pj/aj}j=1... m of I satisfy the imbricated positivity condition for X

The type constructor T of I satisfies the imbricated positivity condition for a constant X in the following cases:

- T=(I t1... tn) and X does not occur in any ti
- T=(x:T)U and X occurs only strictly positively in T and the type U satisfies the imbricated positivity condition for X

##### Example

X occurs strictly positively in A® X or X*A or (`list` X) but not in X ® A or (X ® A)® A assuming the notion of product and lists were already defined. Assuming X has arity `nat ® Prop` and `ex` is inductively defined existential quantifier, the occurrence of X in `(ex nat [n:nat](X n))` is also strictly positive.

##### Correctness rules.

We shall now describe the rules allowing the introduction of a new inductive definition.

W-Ind
  Let E be an environment and G,GP,GI,GC are contexts such that GI is [I1:A1;...;Ik:Ak] and GC is [c1:C1;...;cn:Cn].

  (E[G;GP] |- Aj : s'j | ) |
  j=1... k
  | (E[G;GP;GI] |- Ci : spi | ) |
  i=1... n
  WF(E;Ind(G)[GP](GI:=GC ))[G]

  providing the following side conditions hold:
  - k>0, Ij, ci are different names for j=1... k and i=1... n,
  - for j=1... k we have Aj is an arity of sort sj and Ij Ï G È E,
  - for i=1... n we have Ci is a type of constructor of Ipi which satisfies the positivity condition for I1 ... Ik and ci Ï G È E.

One can remark that there is a constraint between the sort of the arity of the inductive type and the sort of the type of its constructors which will always be satisfied for impredicative sorts (Prop or Set) but may generate constraints between universes.

### 4.5.4 Destructors

The specification of inductive definitions with arities and constructors is quite natural. But we still have to say how to use an object in an inductive type.
This problem is rather delicate. There are actually several different ways to do that. Some of them are logically equivalent but not always equivalent from the computational point of view or from the user point of view.
From the computational point of view, we want to be able to define a function whose domain is an inductively defined type by using a combination of case analysis over the possible constructors of the object and recursion.
Because we need to keep a consistent theory and also we prefer to keep a strongly normalising reduction, we cannot accept any sort of recursion (even terminating). So the basic idea is to restrict ourselves to primitive recursive functions and functionals.
For instance, assuming a parameter A:Set exists in the context, we want to build a function length of type List_A® nat which computes the length of the list, so such that (length nil) = O and (length (cons A a l)) = (S (length l)). We want these equalities to be recognized implicitly and taken into account in the conversion rule.
From the logical point of view, we have built a type family by giving a set of constructors. We want to capture the fact that we do not have any other way to build an object in this type. So when trying to prove a property (P m) for m in an inductive definition it is enough to enumerate all the cases where m starts with a different constructor.
In case the inductive definition is effectively a recursive one, we want to capture the extra property that we have built the smallest fixed point of this recursive equation. This says that we are only manipulating finite objects. This analysis provides induction principles.
For instance, in order to prove (l:List_A)(Length_A l (length l)) it is enough to prove:
(Length_A nil (length nil)) and
(a:A)(l:List_A)(Length_A l (length l)) ® (Length_A (cons A a l) (length (cons A a l))).
which given the conversion equalities satisfied by length is the same as proving: (Length_A nil O) and (a:A)(l:List_A)(Length_A l (length l)) ® (Length_A (cons A a l) (S (length l))).
One conceptually simple way to do that, following the basic scheme proposed by Martin-Löf in his Intuitionistic Type Theory, is to introduce for each inductive definition an elimination operator. At the logical level it is a proof of the usual induction principle and at the computational level it implements a generic operator for doing primitive recursion over the structure.
But this operator is rather tedious to implement and use. We choose in this version of Coq to factorize the operator for primitive recursion into two more primitive operations as was first suggested by Th. Coquand in [Coq92]. One is the definition by case analysis. The second one is a definition by guarded fixpoints.

#### The `Cases...of ...end` construction.

The basic idea of this destructor operation is that we have an object m in an inductive type I and we want to prove a property (P m) which in general depends on m. For this, it is enough to prove the property for m = (ci u1... upi) for each constructor of I.
This proof will be denoted by a generic term:
<P>`Cases` m `of` (c1 x11 ... x1p1) `=>` f1 | ... | (cn xn1...xnpn) `=>` fn `end`
In this expression, if m is a term built from a constructor (ci u1... upi) then the expression will behave as it is specified with i-th branch and will reduce to fi where the xi1...xipi are replaced by the u1... up according to the i-reduction.
This is the basic idea which is generalized to the case where I is an inductively defined n-ary relation (in which case the property P to be proved will be a n+1-ary relation).

##### Non-dependent elimination.

When defining a function by case analysis, we build an object of type I ® C and the minimality principle on an inductively defined logical predicate of type A ® Prop is often used to prove a property (x:A)(I x)® (C x). This is a particular case of the dependent principle that we stated before with a predicate which does not depend explicitly on the object in the inductive definition.
For instance, a function testing whether a list is empty can be defined as:
[l:List_A]<[H:List_A]bool>`Cases` l `of` nil `=>` true | (cons a m) `=>` false `end`
Remark. In the system Coq the expression above, can be written without mentioning the dummy abstraction: <bool>`Cases` l `of` nil `=>` true | (cons a m) `=>` false `end`

##### Allowed elimination sorts.

An important question for building the typing rule for `Case` is what can be the type of P with respect to the type of the inductive definitions.
Remembering that the elimination builds an object in (P m) from an object in m in type I it is clear that we cannot allow any combination.
For instance we cannot in general have I has type Prop and P has type I® Set, because it will mean to build an informative proof of type (P m) doing a case analysis over a non-computational object that will disappear in the extracted program. But the other way is safe with respect to our interpretation we can have I a computational object and P a non-computational one, it just corresponds to proving a logical property of a computational object.
Also if I is in one of the sorts {Prop, Set}, one cannot in general allow an elimination over a bigger sort such as Type. But this operation is safe whenever I is a small inductive type, which means that all the types of constructors of I are small with the following definition:
(I t1... ts) is a small type of constructor and (x:T)C is a small type of constructor if C is and if T has type Prop or Set.
We call this particular elimination which gives the possibility to compute a type by induction on the structure of a term, a strong elimination.
We define now a relation [I:A|B] between an inductive definition I of type A, an arity B which says that an object in the inductive definition I can be eliminated for proving a property P of type B.
The [I:A|B] is defined as the smallest relation satisfying the following rules:

Prod

  [(I x):A'|B']
  [I:(x:A)A'|(x:A)B']

Prop
  [I:Prop|I®Prop]

  I is an empty or singleton definition
  [I:Prop|I® Set]
  I is an empty or small singleton definition
  [I:Prop|I® Type(i)]

Set

  s Î {Prop, Set}
  [I:Set|I® s]
  I is a small inductive definition s Î {Type(i)}
  [I:Set|I® s]

Type

  s Î {Prop,Set,Type(j)}
  [I:Type(i)|I® s]

##### Notations.

We write [I|B] for [I:A|B] where A is the type of I.

##### Empty and singleton elimination

A singleton definition has always an informative content, even if it is a proposition.
A singleton definition has only one constructor and all the argument of this constructor are non informative. In that case, there is a canonical way to interpret the informative extraction on an object in that type, such that the elimination on any sort s is legal. Typical examples are the conjunction of non-informative propositions and the equality. In that case, the term `eq_rec` which was defined as an axiom, is now a term of the calculus.
`Coq` `<``Print eq_rec.`
`eq_rec =`
`[A:Set; x:A; P:(A-``>``Set)](eq_rect A x P)`
`: (A:Set; x:A; P:(A-``>``Set))(P x)-``>``(y:A)x=y-``>``(P y)`
`Coq` `<``Extraction eq_rec.`
`let eq_rec x x0 x1 =`
`x0`
An empty definition has no constructors, in that case also, elimination on any sort is allowed.

##### Type of branches.

Let c be a term of type C, we assume C is a type of constructor for an inductive definition I. Let P be a term that represents the property to be proved. We assume r is the number of parameters.
We define a new type {c:C}P which represents the type of the branch corresponding to the c:C constructor.

{c:(Ii p1... pr t1 ... tp)}P | º (P t1... tp c)
{c:(x: T)C}P | º (x:T){(c x):C}P

We write {c}P for {c:C}P with C the type of c.

##### Examples.

For List_A the type of P will be List_A® s for s Î {Prop,Set,Type(i)}.
{(cons A)}P º (a:A)(l:List_A)(P (cons A a l)).
For Length_A, the type of P will be (l:List_A)(n:nat)(Length_A l n)® Prop and the expression {(Lcons A)}P is defined as:
(a:A)(l:List_A)(n:nat)(h:(Length_A l n))(P (cons A a l) (S n) (Lcons A a l n l)).
If P does not depend on its third argument, we find the more natural expression:
(a:A)(l:List_A)(n:nat)(Length_A l n)®(P (cons A a l) (S n)).

##### Typing rule.

Our very general destructor for inductive definition enjoys the following typing rule (we write <P>`Cases` c `of` [x11:T11]...[x1p1:T1p1]g1... [xn1:Tn1]...[xnpn:Tnpn]gn `end` for <P>`Cases` c `of` (c1 x11 ... x1p1) `=>` g1 | ... | (cn xn1...xnpn) `=>` gn `end`):

Cases

  E[G] |- c : (I q1... qr t1... ts) E[G] |- P : B [(I q1... qr)|B] (E[G] |- fi : {(cpi q1... qr)}P | ) |
  i=1... l
  E[G] |- <P>`Cases` c `of` f1... fl `end` : (P t1... ts c)

  provided I is an inductive type in a declaration Ind(D)[GP](GI:=GC ) with |GP| = r, GC = [c1:C1;...;cn:Cn] and cp1... cpl are the only constructors of I.

##### Example.

For List and Length the typing rules for the `Case` expression are (writing just t:M instead of E[G] |- t : M, the environment and context being the same in all the judgments).

l:List_A P:List_A® s f1:(P (nil A)) f2:(a:A)(l:List_A)(P (cons A a l))
<P>`Cases` l `of` f1 f2 `end`:(P l)

H:(Length_A L N)
P:(l:List_A)(n:nat)(Length_A l n)® Prop
f1:(P (nil A) O Lnil)
f2:(a:A)(l:List_A)(n:nat)(h:(Length_A l n))(P (cons A a n) (S n) (Lcons A a l n h))
<P>`Cases` H `of` f1 f2 `end`:(P L N H)

##### Definition of i-reduction.

We still have to define the i-reduction in the general case.
A i-redex is a term of the following form:
<P>`Cases` (cpi q1... qr a1... am) `of` f1... fl `end`
with cpi the i-th constructor of the inductive type I with r parameters.
The i-contraction of this term is (fi a1... am) leading to the general reduction rule:

<P>`Cases` (cpi q1... qr a1... am) `of` f1... fn `end` | |> |
i
| (fi a1... am)

### 4.5.5 Fixpoint definitions

The second operator for elimination is fixpoint definition. This fixpoint may involve several mutually recursive definitions. The basic syntax for a recursive set of declarations is
`Fix` {f1:A1:=t1 ... fn:An:=tn}
The terms are obtained by projections from this set of declarations and are written `Fix` fi{f1:A1:=t1 ... fn:An:=tn}

#### Typing rule

The typing rule is the expected one for a fixpoint.

Fix

  (E[G] |- Ai : si | ) |
  i=1... n
  | (E[G,f1:A1,...,fn:An] |- ti : Ai | ) |
  i=1... n
  E[G] |- `Fix` fi{f1:A1:=t1 ... fn:An:=tn} : Ai

Any fixpoint definition cannot be accepted because non-normalizing terms will lead to proofs of absurdity.
The basic scheme of recursion that should be allowed is the one needed for defining primitive recursive functionals. In that case the fixpoint enjoys special syntactic restriction, namely one of the arguments belongs to an inductive type, the function starts with a case analysis and recursive calls are done on variables coming from patterns and representing subterms.
For instance in the case of natural numbers, a proof of the induction principle of type
(P:nat®Prop)(P O)®((n:nat)(P n)®(P (S n)))®(n:nat)(P n)
can be represented by the term:

[P:nat®Prop][f:(P O)][g:(n:nat)(P n)®(P (S n))]
`Fix` h{h:(n:nat)(P n):=[n:nat]<P>`Cases` n `of` f [p:nat](g p (h p)) `end`}

Before accepting a fixpoint definition as being correctly typed, we check that the definition is ``guarded''. A precise analysis of this notion can be found in [Gim94].
The first stage is to precise on which argument the fixpoint will be decreasing. The type of this argument should be an inductive definition.
For doing this the syntax of fixpoints is extended and becomes
`Fix` fi{f1/k1:A1:=t1 ... fn/kn:An:=tn}
where ki are positive integers. Each Ai should be a type (reducible to a term) starting with at least ki products (y1:B1)... (yki:Bki) A'i and Bki being an instance of an inductive definition.
Now in the definition ti, if fj occurs then it should be applied to at least kj arguments and the kj-th argument should be syntactically recognized as structurally smaller than yki
The definition of being structurally smaller is a bit technical. One needs first to define the notion of recursive arguments of a constructor. For an inductive definition Ind(G)[GP](GI:=GC ), the type of a constructor c have the form (p1:P1)...(pr:Pr)(x1:T1)... (xr:Tr)(Ij p1... pr t1... ts) the recursive arguments will correspond to Ti in which one of the Il occurs.
The main rules for being structurally smaller are the following:
Given a variable y of type an inductive definition in a declaration Ind(G)[GP](GI:=GC ) where GI is [I1:A1;...;Ik:Ak], and GC is [c1:C1;...;cn:Cn]. The terms structurally smaller than y are:

- (t u), [x:u]t when t is structurally smaller than y .
- <P>`Cases` c `of` f1... fn `end` when each fi is structurally smaller than y.
  If c is y or is structurally smaller than y, its type is an inductive definition Ip part of the inductive declaration corresponding to y. Each fi corresponds to a type of constructor Cq º (y1:B1)... (yk:Bk)(I a1... ak) and can consequently be written [y1:B'1]... [yk:B'k]gi. (B'i is obtained from Bi by substituting parameters variables) the variables yj occurring in gi corresponding to recursive arguments Bi (the ones in which one of the Il occurs) are structurally smaller than y.

The following definitions are correct, we enter them using the `Fixpoint` command as described in section 1.3.4 and show the internal representation.
`Coq` `<``Fixpoint plus [n:nat] : nat -``>``nat :=`
`Coq` `<``[m:nat]Case n of m [p:nat](S (plus p m)) end.`
`plus is recursively defined`
`Coq` `<``Print plus.`
`plus =`
`Fix plus`
`{plus [n:nat] : nat-``>``nat :=`
`[m:nat]Cases n of`
`O =``>``m`
`| (S p) =``>``(S (plus p m))`
`end}`
`: nat-``>``nat-``>``nat`
`Coq` `<``Fixpoint lgth [A:Set;l:(list A)] : nat :=`
`Coq` `<``Case l of O [a:A][l':(list A)](S (lgth A l')) end.`
`lgth is recursively defined`
`Coq` `<``Print lgth.`
`lgth =`
`Fix lgth`
`{lgth [A:Set; l:(list A)] : nat :=`
`Cases l of`
`nil =``>``O`
`| (cons _ l') =``>``(S (lgth A l'))`
`end}`
`: (A:Set)(list A)-``>``nat`
`Coq` `<``Fixpoint sizet [t:tree] : nat`
`Coq` `<``:= Case t of [f:forest](S (sizef f)) end`
`Coq` `<``with sizef [f:forest] : nat`
`Coq` `<``:= Case f of O [t:tree][f:forest](plus (sizet t) (sizef f)) end.`
`sizet, sizef are recursively defined`
`Coq` `<``Print sizet.`
`sizet =`
`Fix sizet`
`{sizet [t:tree] : nat := Cases t of (node f) =``>``(S (sizef f)) end`
`with sizef [f:forest] : nat :=`
`Cases f of`
`emptyf =``>``O`
`| (consf t f0) =``>``(plus (sizet t) (sizef f0))`
`end}`
`: tree-``>``nat`

#### Reduction rule

Let F be the set of declarations: f1/k1:A1:=t1 ... fn/kn:An:=tn. The reduction for fixpoints is:

(`Fix` | fi{F} a1... a |
ki
| ) |> |
i
| ti{(fk/`Fix` | fk{F}) |
k=1... n
| }

when aki starts with a constructor. This last restriction is needed in order to keep strong normalization and corresponds to the reduction for primitive recursive operators.
We can illustrate this behavior on examples.
`Coq` `<``Goal (n,m:nat)(plus (S n) m)=(S (plus n m)).`
`1 subgoal`
``
`============================`
`(n,m:nat)(plus (S n) m)=(S (plus n m))`
`Coq` `<``Reflexivity.`
`Subtree proved!`
`Coq` `<``Abort.`
`Current goal aborted`
`Coq` `<``Goal (f:forest)(sizet (node f))=(S (sizef f)).`
`1 subgoal`
``
`============================`
`(f:forest)(sizet (node f))=(S (sizef f))`
`Coq` `<``Reflexivity.`
`Subtree proved!`
`Coq` `<``Abort.`
`Current goal aborted`
But assuming the definition of a son function from tree to forest:
`Coq` `<``Definition sont : tree -``>``forest := [t]Case t of [f]f end.`
`sont is defined`
The following is not a conversion but can be proved after a case analysis.
`Coq` `<``Goal (t:tree)(sizet t)=(S (sizef (sont t))).`
`1 subgoal`
``
`============================`
`(t:tree)(sizet t)=(S (sizef (sont t)))`
`Coq` `<``(** this one fails **)`
`Coq` `<``Reflexivity.`
`Error: Impossible to unify (S (sizef (sont t))) with (sizet t)`
`Coq` `<``Destruct t.`
`1 subgoal`
``
`t : tree`
`============================`
`(f:forest)(sizet (node f))=(S (sizef (sont (node f))))`
`Coq` `<``Reflexivity.`
`Subtree proved!`

#### Mutual induction

The principles of mutual induction can be automatically generated using the `Scheme` command described in section 7.14.