Theory Logic

(*<*)
theory Logic
imports LaTeXsugar
begin
(*>*)
text‹
\vspace{-5ex}
\section{Formulas}

The core syntax of formulas (\textit{form} below)
provides the standard logical constructs, in decreasing order of precedence:
\[
\begin{array}{rcl}

\mathit{form} & ::= &
  (form)› ~\mid~
  constTrue ~\mid~
  constFalse ~\mid~
  propterm = term\\
 &\mid& prop¬ form\index{$HOL4@\isasymnot} ~\mid~
  propform  form\index{$HOL0@\isasymand} ~\mid~
  propform  form\index{$HOL1@\isasymor} ~\mid~
  propform  form\index{$HOL2@\isasymlongrightarrow}\\
 &\mid& propx. form\index{$HOL6@\isasymforall} ~\mid~  propx. form\index{$HOL7@\isasymexists}
\end{array}
\]
Terms are the ones we have seen all along, built from constants, variables,
function application and λ›-abstraction, including all the syntactic
sugar like infix symbols, if›, case›, etc.
\begin{warn}
Remember that formulas are simply terms of type bool›. Hence
=› also works for formulas. Beware that =› has a higher
precedence than the other logical operators. Hence props = t  A means
(s = t) ∧ A›, and propAB = BA means A ∧ (B = B) ∧ A›.
Logical equivalence can also be written with
⟷› instead of =›, where ⟷› has the same low
precedence as ⟶›. Hence A ∧ B ⟷ B ∧ A› really means
(A ∧ B) ⟷ (B ∧ A)›.
\end{warn}
\begin{warn}
Quantifiers need to be enclosed in parentheses if they are nested within
other constructs (just like if›, case› and let›).
\end{warn}
The most frequent logical symbols and their ASCII representations are shown
in Fig.~\ref{fig:log-symbols}.
\begin{figure}
\begin{center}
\begin{tabular}{l@ {\qquad}l@ {\qquad}l}
∀› & \xsymbol{forall} & \texttt{ALL}\\
∃› & \xsymbol{exists} & \texttt{EX}\\
λ› & \xsymbol{lambda} & \texttt{\%}\\
⟶› & \texttt{-{\kern0pt}->}\\
⟷› & \texttt{<->}\\
∧› & \texttt{/\char`\\} & \texttt{\&}\\
∨› & \texttt{\char`\\/} & \texttt{|}\\
¬› & \xsymbol{not} & \texttt{\char`~}\\
≠› & \xsymbol{noteq} & \texttt{\char`~=}
\end{tabular}
\end{center}
\caption{Logical symbols and their ASCII forms}
\label{fig:log-symbols}
\end{figure}
The first column shows the symbols, the other columns ASCII representations.
The \texttt{\char`\\}\texttt{<...>} form is always converted into the symbolic form
by the Isabelle interfaces, the treatment of the other ASCII forms
depends on the interface. The ASCII forms \texttt{/\char`\\} and
\texttt{\char`\\/}
are special in that they are merely keyboard shortcuts for the interface and
not logical symbols by themselves.
\begin{warn}
The implication ⟹› is part of the Isabelle framework. It structures
theorems and proof states, separating assumptions from conclusions.
The implication ⟶› is part of the logic HOL and can occur inside the
formulas that make up the assumptions and conclusion.
Theorems should be of the form ⟦ A1; …; An ⟧ ⟹ A›,
not A1 ∧ … ∧ An ⟶ A›. Both are logically equivalent
but the first one works better when using the theorem in further proofs.

The ASCII representation of ⟦› and ⟧› is \texttt{[|} and \texttt{|]}.
\end{warn}

\section{Sets}
\label{sec:Sets}

Sets of elements of type typ'a have type typ'a set\index{set@set›}.
They can be finite or infinite. Sets come with the usual notation:
\begin{itemize}
\item \indexed{term{}}{$IMP042},\quad {e1,…,en}›
\item prope  A\index{$HOLSet0@\isasymin},\quad propA  B\index{$HOLSet2@\isasymsubseteq}
\item termA  B\index{$HOLSet4@\isasymunion},\quad termA  B\index{$HOLSet5@\isasyminter},\quad termA - B,\quad term-A
\end{itemize}
(where termA-B and -A› are set difference and complement)
and much more. constUNIV is the set of all elements of some type.
Set comprehension\index{set comprehension} is written
term{x. P}\index{$IMP042@term{x. P}} rather than {x | P}›.
\begin{warn}
In term{x. P} the x› must be a variable. Set comprehension
involving a proper term t› must be written
\noquotes{@{term[source] "{t | x y. P}"}}\index{$IMP042@{t |x. P}›},
where x y› are those free variables in t›
that occur in P›.
This is just a shorthand for term{v. x y. v = t  P}, where
v› is a new variable. For example, term{x+y|x. x  A}
is short for \noquotes{@{term[source]"{v. x. v = x+y  x  A}"}}.
\end{warn}

Here are the ASCII representations of the mathematical symbols:
\begin{center}
\begin{tabular}{l@ {\quad}l@ {\quad}l}
∈› & \texttt{\char`\\\char`∈} & \texttt{:}\\
⊆› & \texttt{\char`\\\char`⊆} & \texttt{<=}\\
∪› & \texttt{\char`\\\char`∪} & \texttt{Un}\\
∩› & \texttt{\char`\\\char`∩} & \texttt{Int}
\end{tabular}
\end{center}
Sets also allow bounded quantifications propx  A. P and
propx  A. P.

For the more ambitious, there are also ⋃›\index{$HOLSet6@\isasymUnion}
and ⋂›\index{$HOLSet7@\isasymInter}:
\begin{center}
@{thm Union_eq} \qquad @{thm Inter_eq}
\end{center}
The ASCII forms of ⋃› are \texttt{\char`\\\char`⋃} and \texttt{Union},
those of ⋂› are \texttt{\char`\\\char`⋂} and \texttt{Inter}.
There are also indexed unions and intersections:
\begin{center}
@{thm[eta_contract=false] UNION_eq} \\ @{thm[eta_contract=false] INTER_eq}
\end{center}
The ASCII forms are \ \texttt{UN x:A.~B} \ and \ \texttt{INT x:A. B} \
where \texttt{x} may occur in \texttt{B}.
If \texttt{A} is \texttt{UNIV} you can write \ \texttt{UN x.~B} \ and \ \texttt{INT x. B}.

Some other frequently useful functions on sets are the following:
\begin{center}
\begin{tabular}{l@ {\quad}l}
@{const_typ set}\index{set@constset} & converts a list to the set of its elements\\
@{const_typ finite}\index{finite@constfinite} & is true iff its argument is finite\\
\noquotes{@{term[source] "card :: 'a set  nat"}}\index{card@constcard} & is the cardinality of a finite set\\
 & and is 0› for all infinite sets\\
@{thm image_def}\index{$IMP042@termf ` A} & is the image of a function over a set
\end{tabular}
\end{center}
See cite"Nipkow-Main" for the wealth of further predefined functions in theory
theoryMain.


\subsection*{Exercises}

\exercise
Start from the data type of binary trees defined earlier:
›

datatype 'a tree = Tip | Node "'a tree" 'a "'a tree"

text‹
Define a function set ::› typ'a tree  'a set
that returns the elements in a tree and a function
ord ::› typint tree  bool
that tests if an typint tree is ordered.

Define a function ins› that inserts an element into an ordered typint tree
while maintaining the order of the tree. If the element is already in the tree, the
same tree should be returned. Prove correctness of ins›:
propset(ins x t) = {x}  set t and propord t  ord(ins i t).
\endexercise


\section{Proof Automation}

So far we have only seen simp› and \indexed{auto›}{auto}: Both perform
rewriting, both can also prove linear arithmetic facts (no multiplication),
and auto› is also able to prove simple logical or set-theoretic goals:
›

lemma "x. y. x = y"
by auto

lemma "A  B  C  A  B  C"
by auto

text‹where
\begin{quote}
\isacom{by} \textit{proof-method}
\end{quote}
is short for
\begin{quote}
\isacom{apply} \textit{proof-method}\\
\isacom{done}
\end{quote}
The key characteristics of both simp› and auto› are
\begin{itemize}
\item They show you where they got stuck, giving you an idea how to continue.
\item They perform the obvious steps but are highly incomplete.
\end{itemize}
A proof method is \conceptnoidx{complete} if it can prove all true formulas.
There is no complete proof method for HOL, not even in theory.
Hence all our proof methods only differ in how incomplete they are.

A proof method that is still incomplete but tries harder than auto› is
\indexed{fastforce›}{fastforce}.  It either succeeds or fails, it acts on the first
subgoal only, and it can be modified like auto›, e.g.,
with simp add›. Here is a typical example of what fastforce›
can do:
›

lemma " xs  A. ys. xs = ys @ ys;  us  A 
    n. length us = n+n"
by fastforce

text‹This lemma is out of reach for auto› because of the
quantifiers.  Even fastforce› fails when the quantifier structure
becomes more complicated. In a few cases, its slow version force›
succeeds where fastforce› fails.

The method of choice for complex logical goals is \indexed{blast›}{blast}. In the
following example, T› and A› are two binary predicates. It
is shown that if T› is total, A› is antisymmetric and T› is
a subset of A›, then A› is a subset of T›:
›

lemma
  " x y. T x y  T y x;
     x y. A x y  A y x  x = y;
     x y. T x y  A x y 
    x y. A x y  T x y"
by blast

text‹
We leave it to the reader to figure out why this lemma is true.
Method blast›
\begin{itemize}
\item is (in principle) a complete proof procedure for first-order formulas,
  a fragment of HOL. In practice there is a search bound.
\item does no rewriting and knows very little about equality.
\item covers logic, sets and relations.
\item either succeeds or fails.
\end{itemize}
Because of its strength in logic and sets and its weakness in equality reasoning, it complements the earlier proof methods.


\subsection{\concept{Sledgehammer}}

Command \isacom{sledgehammer} calls a number of external automatic
theorem provers (ATPs) that run for up to 30 seconds searching for a
proof. Some of these ATPs are part of the Isabelle installation, others are
queried over the internet. If successful, a proof command is generated and can
be inserted into your proof.  The biggest win of \isacom{sledgehammer} is
that it will take into account the whole lemma library and you do not need to
feed in any lemma explicitly. For example,›

lemma " xs @ ys = ys @ xs;  length xs = length ys   xs = ys"

txt‹cannot be solved by any of the standard proof methods, but
\isacom{sledgehammer} finds the following proof:›

by (metis append_eq_conv_conj)

text‹We do not explain how the proof was found but what this command
means. For a start, Isabelle does not trust external tools (and in particular
not the translations from Isabelle's logic to those tools!)
and insists on a proof that it can check. This is what \indexed{metis›}{metis} does.
It is given a list of lemmas and tries to find a proof using just those lemmas
(and pure logic). In contrast to using simp› and friends who know a lot of
lemmas already, using metis› manually is tedious because one has
to find all the relevant lemmas first. But that is precisely what
\isacom{sledgehammer} does for us.
In this case lemma @{thm[source]append_eq_conv_conj} alone suffices:
@{thm[display] append_eq_conv_conj}
We leave it to the reader to figure out why this lemma suffices to prove
the above lemma, even without any knowledge of what the functions consttake
and constdrop do. Keep in mind that the variables in the two lemmas
are independent of each other, despite the same names, and that you can
substitute arbitrary values for the free variables in a lemma.

Just as for the other proof methods we have seen, there is no guarantee that
\isacom{sledgehammer} will find a proof if it exists. Nor is
\isacom{sledgehammer} superior to the other proof methods.  They are
incomparable. Therefore it is recommended to apply simp› or auto› before invoking \isacom{sledgehammer} on what is left.

\subsection{Arithmetic}

By arithmetic formulas we mean formulas involving variables, numbers, +›, -›, =›, <›, ≤› and the usual logical
connectives ¬›, ∧›, ∨›, ⟶›,
⟷›. Strictly speaking, this is known as \concept{linear arithmetic}
because it does not involve multiplication, although multiplication with
numbers, e.g., 2*n›, is allowed. Such formulas can be proved by
\indexed{arith›}{arith}:
›

lemma " (a::nat)  x + b; 2*x < c   2*a + 1  2*b + c"
by arith

text‹In fact, auto› and simp› can prove many linear
arithmetic formulas already, like the one above, by calling a weak but fast
version of arith›. Hence it is usually not necessary to invoke
arith› explicitly.

The above example involves natural numbers, but integers (type typint)
and real numbers (type real›) are supported as well. As are a number
of further operators like constmin and constmax. On typnat and
typint, arith› can even prove theorems with quantifiers in them,
but we will not enlarge on that here.


\subsection{Trying Them All}

If you want to try all of the above automatic proof methods you simply type
\begin{isabelle}
\isacom{try}
\end{isabelle}
There is also a lightweight variant \isacom{try0} that does not call
sledgehammer. If desired, specific simplification and introduction rules
can be added:
\begin{isabelle}
\isacom{try0} simp: … intro: …›
\end{isabelle}

\section{Single Step Proofs}

Although automation is nice, it often fails, at least initially, and you need
to find out why. When fastforce› or blast› simply fail, you have
no clue why. At this point, the stepwise
application of proof rules may be necessary. For example, if blast›
fails on propA  B, you want to attack the two
conjuncts A› and B› separately. This can
be achieved by applying \emph{conjunction introduction}
\[ @{thm[mode=Rule,show_question_marks]conjI}\ conjI›
\]
to the proof state. We will now examine the details of this process.

\subsection{Instantiating Unknowns}

We had briefly mentioned earlier that after proving some theorem,
Isabelle replaces all free variables x› by so called \conceptidx{unknowns}{unknown}
?x›. We can see this clearly in rule @{thm[source] conjI}.
These unknowns can later be instantiated explicitly or implicitly:
\begin{itemize}
\item By hand, using \indexed{of›}{of}.
The expression conjI[of "a=b" "False"]›
instantiates the unknowns in @{thm[source] conjI} from left to right with the
two formulas a=b› and False›, yielding the rule
@{thm[display,mode=Rule,margin=100]conjI[of "a=b" False]}

In general, th[of string1 … stringn]› instantiates
the unknowns in the theorem th› from left to right with the terms
string1 to stringn.

\item By unification. \conceptidx{Unification}{unification} is the process of making two
terms syntactically equal by suitable instantiations of unknowns. For example,
unifying ?P ∧ ?Q› with \mbox{propa=b  False} instantiates
?P› with propa=b and ?Q› with propFalse.
\end{itemize}
We need not instantiate all unknowns. If we want to skip a particular one we
can write _› instead, for example conjI[of _ "False"]›.
Unknowns can also be instantiated by name using \indexed{where›}{where}, for example
conjI[where ?P = "a=b"› \isacom{and} ?Q = "False"]›.


\subsection{Rule Application}

\conceptidx{Rule application}{rule application} means applying a rule backwards to a proof state.
For example, applying rule @{thm[source]conjI} to a proof state
\begin{quote}
1.  …  ⟹ A ∧ B›
\end{quote}
results in two subgoals, one for each premise of @{thm[source]conjI}:
\begin{quote}
1.  …  ⟹ A›\\
2.  …  ⟹ B›
\end{quote}
In general, the application of a rule ⟦ A1; …; An ⟧ ⟹ A›
to a subgoal \mbox{… ⟹ C›} proceeds in two steps:
\begin{enumerate}
\item
Unify A› and C›, thus instantiating the unknowns in the rule.
\item
Replace the subgoal C› with n› new subgoals A1 to An.
\end{enumerate}
This is the command to apply rule xyz›:
\begin{quote}
\isacom{apply}(rule xyz)›\index{rule@rule›}
\end{quote}
This is also called \concept{backchaining} with rule xyz›.

\subsection{Introduction Rules}

Conjunction introduction (@{thm[source] conjI}) is one example of a whole
class of rules known as \conceptidx{introduction rules}{introduction rule}. They explain under which
premises some logical construct can be introduced. Here are some further
useful introduction rules:
\[
\inferrule*[right=\mbox{impI›}]{\mbox{?P ⟹ ?Q›}}{\mbox{?P ⟶ ?Q›}}
\qquad
\inferrule*[right=\mbox{allI›}]{\mbox{⋀x. ?P x›}}{\mbox{∀x. ?P x›}}
\]
\[
\inferrule*[right=\mbox{iffI›}]{\mbox{?P ⟹ ?Q›} \\ \mbox{?Q ⟹ ?P›}}
  {\mbox{?P = ?Q›}}
\]
These rules are part of the logical system of \concept{natural deduction}
(e.g., citeHuthRyan). Although we intentionally de-emphasize the basic rules
of logic in favour of automatic proof methods that allow you to take bigger
steps, these rules are helpful in locating where and why automation fails.
When applied backwards, these rules decompose the goal:
\begin{itemize}
\item @{thm[source] conjI} and @{thm[source]iffI} split the goal into two subgoals,
\item @{thm[source] impI} moves the left-hand side of a HOL implication into the list of assumptions,
\item and @{thm[source] allI} removes a ∀› by turning the quantified variable into a fixed local variable of the subgoal.
\end{itemize}
Isabelle knows about these and a number of other introduction rules.
The command
\begin{quote}
\isacom{apply} rule›\index{rule@rule›}
\end{quote}
automatically selects the appropriate rule for the current subgoal.

You can also turn your own theorems into introduction rules by giving them
the \indexed{intro›}{intro} attribute, analogous to the simp› attribute.  In
that case blast›, fastforce› and (to a limited extent) auto› will automatically backchain with those theorems. The intro›
attribute should be used with care because it increases the search space and
can lead to nontermination.  Sometimes it is better to use it only in
specific calls of blast› and friends. For example,
@{thm[source] le_trans}, transitivity of ≤› on type typnat,
is not an introduction rule by default because of the disastrous effect
on the search space, but can be useful in specific situations:
›

lemma " (a::nat)  b; b  c; c  d; d  e   a  e"
by(blast intro: le_trans)

text‹
Of course this is just an example and could be proved by arith›, too.

\subsection{Forward Proof}
\label{sec:forward-proof}

Forward proof means deriving new theorems from old theorems. We have already
seen a very simple form of forward proof: the of› operator for
instantiating unknowns in a theorem. The big brother of of› is
\indexed{OF›}{OF} for applying one theorem to others. Given a theorem propA  B called
r› and a theorem A'› called r'›, the theorem r[OF r']› is the result of applying r› to r'›, where r› should be viewed as a function taking a theorem A› and returning
B›.  More precisely, A› and A'› are unified, thus
instantiating the unknowns in B›, and the result is the instantiated
B›. Of course, unification may also fail.
\begin{warn}
Application of rules to other rules operates in the forward direction: from
the premises to the conclusion of the rule; application of rules to proof
states operates in the backward direction, from the conclusion to the
premises.
\end{warn}

In general r› can be of the form ⟦ A1; …; An ⟧ ⟹ A›
and there can be multiple argument theorems r1 to rm
(with m ≤ n›), in which case r[OF r1 … rm]› is obtained
by unifying and thus proving Ai with ri, i = 1…m›.
Here is an example, where @{thm[source]refl} is the theorem
@{thm[show_question_marks] refl}:
›

thm conjI[OF refl[of "a"] refl[of "b"]]

text‹yields the theorem @{thm conjI[OF refl[of "a"] refl[of "b"]]}.
The command \isacom{thm} merely displays the result.

Forward reasoning also makes sense in connection with proof states.
Therefore blast›, fastforce› and auto› support a modifier
dest› which instructs the proof method to use certain rules in a
forward fashion. If r› is of the form \mbox{A ⟹ B›}, the modifier
\mbox{dest: r›}\index{dest@dest:›}
allows proof search to reason forward with r›, i.e.,
to replace an assumption A'›, where A'› unifies with A›,
with the correspondingly instantiated B›. For example, @{thm[source,show_question_marks] Suc_leD} is the theorem \mbox{@{thm Suc_leD}}, which works well for forward reasoning:
›

lemma "Suc(Suc(Suc a))  b  a  b"
by(blast dest: Suc_leD)

text‹In this particular example we could have backchained with
@{thm[source] Suc_leD}, too, but because the premise is more complicated than the conclusion this can easily lead to nontermination.

%\subsection{Finding Theorems}
%
%Command \isacom{find{\isacharunderscorekeyword}theorems} searches for specific theorems in the current
%theory. Search criteria include pattern matching on terms and on names.
%For details see the Isabelle/Isar Reference Manual~citeIsarRef.
%\bigskip

\begin{warn}
To ease readability we will drop the question marks
in front of unknowns from now on.
\end{warn}


\section{Inductive Definitions}
\label{sec:inductive-defs}\index{inductive definition|(}

Inductive definitions are the third important definition facility, after
datatypes and recursive function.
\ifsem
In fact, they are the key construct in the
definition of operational semantics in the second part of the book.
\fi

\subsection{An Example: Even Numbers}
\label{sec:Logic:even}

Here is a simple example of an inductively defined predicate:
\begin{itemize}
\item 0 is even
\item If $n$ is even, so is $n+2$.
\end{itemize}
The operative word ``inductive'' means that these are the only even numbers.
In Isabelle we give the two rules the names ev0› and evSS›
and write
›

inductive ev :: "nat  bool" where
ev0:    "ev 0" |
evSS:  (*<*)"ev n  ev (Suc(Suc n))"(*>*)
text_raw@{prop[source]"ev n  ev (n + 2)"}

text‹To get used to inductive definitions, we will first prove a few
properties of constev informally before we descend to the Isabelle level.

How do we prove that some number is even, e.g., propev 4? Simply by combining the defining rules for constev:
\begin{quote}
ev 0 ⟹ ev (0 + 2) ⟹ ev((0 + 2) + 2) = ev 4›
\end{quote}

\subsubsection{Rule Induction}\index{rule induction|(}

Showing that all even numbers have some property is more complicated.  For
example, let us prove that the inductive definition of even numbers agrees
with the following recursive one:›

fun evn :: "nat  bool" where
"evn 0 = True" |
"evn (Suc 0) = False" |
"evn (Suc(Suc n)) = evn n"

text‹We prove propev m  evn m.  That is, we
assume propev m and by induction on the form of its derivation
prove propevn m. There are two cases corresponding to the two rules
for constev:
\begin{description}
\item[Case @{thm[source]ev0}:]
 propev m was derived by rule propev 0: \\
 ⟹› propm=(0::nat) ⟹› evn m = evn 0 = True›
\item[Case @{thm[source]evSS}:]
 propev m was derived by rule propev n  ev(n+2): \\
⟹› propm=n+(2::nat) and by induction hypothesis propevn n\\
⟹› evn m = evn(n + 2) = evn n = True›
\end{description}

What we have just seen is a special case of \concept{rule induction}.
Rule induction applies to propositions of this form
\begin{quote}
propev n  P n
\end{quote}
That is, we want to prove a property propP n
for all even n›. But if we assume propev n, then there must be
some derivation of this assumption using the two defining rules for
constev. That is, we must prove
\begin{description}
\item[Case @{thm[source]ev0}:] propP(0::nat)
\item[Case @{thm[source]evSS}:] prop ev n; P n   P(n + 2::nat)
\end{description}
The corresponding rule is called @{thm[source] ev.induct} and looks like this:
\[
\inferrule{
\mbox{@{thm (prem 1) ev.induct[of "n"]}}\\
\mbox{@{thm (prem 2) ev.induct}}\\
\mbox{prop!!n.  ev n; P n   P(n+2)}}
{\mbox{@{thm (concl) ev.induct[of "n"]}}}
\]
The first premise propev n enforces that this rule can only be applied
in situations where we know that n› is even.

Note that in the induction step we may not just assume propP n but also
\mbox{propev n}, which is simply the premise of rule @{thm[source]
evSS}.  Here is an example where the local assumption propev n comes in
handy: we prove propev m  ev(m - 2) by induction on propev m.
Case @{thm[source]ev0} requires us to prove propev(0 - 2), which follows
from propev 0 because prop0 - 2 = (0::nat) on type typnat. In
case @{thm[source]evSS} we have \mbox{propm = n+(2::nat)} and may assume
propev n, which implies propev (m - 2) because m - 2 = (n +
2) - 2 = n›. We did not need the induction hypothesis at all for this proof (it
is just a case analysis of which rule was used) but having propev n
at our disposal in case @{thm[source]evSS} was essential.
This case analysis of rules is also called ``rule inversion''
and is discussed in more detail in \autoref{ch:Isar}.

\subsubsection{In Isabelle}

Let us now recast the above informal proofs in Isabelle. For a start,
we use constSuc terms instead of numerals in rule @{thm[source]evSS}:
@{thm[display] evSS}
This avoids the difficulty of unifying n+2› with some numeral,
which is not automatic.

The simplest way to prove propev(Suc(Suc(Suc(Suc 0)))) is in a forward
direction: evSS[OF evSS[OF ev0]]› yields the theorem @{thm evSS[OF
evSS[OF ev0]]}. Alternatively, you can also prove it as a lemma in backwards
fashion. Although this is more verbose, it allows us to demonstrate how each
rule application changes the proof state:›

lemma "ev(Suc(Suc(Suc(Suc 0))))"
txt@{subgoals[display,indent=0,goals_limit=1]}
apply(rule evSS)
txt@{subgoals[display,indent=0,goals_limit=1]}
apply(rule evSS)
txt@{subgoals[display,indent=0,goals_limit=1]}
apply(rule ev0)
done

text‹\indent
Rule induction is applied by giving the induction rule explicitly via the
rule:› modifier:\index{inductionrule@induction ... rule:›}›

lemma "ev m  evn m"
apply(induction rule: ev.induct)
by(simp_all)

text‹Both cases are automatic. Note that if there are multiple assumptions
of the form propev t, method induction› will induct on the leftmost
one.

As a bonus, we also prove the remaining direction of the equivalence of
constev and constevn:
›

lemma "evn n  ev n"
apply(induction n rule: evn.induct)

txt‹This is a proof by computation induction on n› (see
\autoref{sec:recursive-funs}) that sets up three subgoals corresponding to
the three equations for constevn:
@{subgoals[display,indent=0]}
The first and third subgoals follow with @{thm[source]ev0} and @{thm[source]evSS}, and the second subgoal is trivially true because propevn(Suc 0) is constFalse:
›

by (simp_all add: ev0 evSS)

text‹The rules for constev make perfect simplification and introduction
rules because their premises are always smaller than the conclusion. It
makes sense to turn them into simplification and introduction rules
permanently, to enhance proof automation. They are named @{thm[source] ev.intros}
\index{intros@.intros›} by Isabelle:›

declare ev.intros[simp,intro]

text‹The rules of an inductive definition are not simplification rules by
default because, in contrast to recursive functions, there is no termination
requirement for inductive definitions.

\subsubsection{Inductive Versus Recursive}

We have seen two definitions of the notion of evenness, an inductive and a
recursive one. Which one is better? Much of the time, the recursive one is
more convenient: it allows us to do rewriting in the middle of terms, and it
expresses both the positive information (which numbers are even) and the
negative information (which numbers are not even) directly. An inductive
definition only expresses the positive information directly. The negative
information, for example, that 1› is not even, has to be proved from
it (by induction or rule inversion). On the other hand, rule induction is
tailor-made for proving \mbox{propev n  P n} because it only asks you
to prove the positive cases. In the proof of propevn n  P n by
computation induction via @{thm[source]evn.induct}, we are also presented
with the trivial negative cases. If you want the convenience of both
rewriting and rule induction, you can make two definitions and show their
equivalence (as above) or make one definition and prove additional properties
from it, for example rule induction from computation induction.

But many concepts do not admit a recursive definition at all because there is
no datatype for the recursion (for example, the transitive closure of a
relation), or the recursion would not terminate (for example,
an interpreter for a programming language). Even if there is a recursive
definition, if we are only interested in the positive information, the
inductive definition may be much simpler.

\subsection{The Reflexive Transitive Closure}
\label{sec:star}

Evenness is really more conveniently expressed recursively than inductively.
As a second and very typical example of an inductive definition we define the
reflexive transitive closure.
\ifsem
It will also be an important building block for
some of the semantics considered in the second part of the book.
\fi

The reflexive transitive closure, called star› below, is a function
that maps a binary predicate to another binary predicate: if r› is of
type τ ⇒ τ ⇒ bool› then termstar r is again of type τ ⇒
τ ⇒ bool›, and propstar r x y means that x› and y› are in
the relation termstar r. Think termr* when you see termstar
r, because star r› is meant to be the reflexive transitive closure.
That is, propstar r x y is meant to be true if from x› we can
reach y› in finitely many r› steps. This concept is naturally
defined inductively:›

inductive star :: "('a  'a  bool)  'a  'a  bool"  for r where
refl:  "star r x x" |
step:  "r x y  star r y z  star r x z"

text‹The base case @{thm[source] refl} is reflexivity: termx=y. The
step case @{thm[source]step} combines an r› step (from x› to
y›) and a termstar r step (from y› to z›) into a
termstar r step (from x› to z›).
The ``\isacom{for}~r›'' in the header is merely a hint to Isabelle
that r› is a fixed parameter of conststar, in contrast to the
further parameters of conststar, which change. As a result, Isabelle
generates a simpler induction rule.

By definition termstar r is reflexive. It is also transitive, but we
need rule induction to prove that:›

lemma star_trans: "star r x y  star r y z  star r x z"
apply(induction rule: star.induct)
(*<*)
defer
apply(rename_tac u x y)
defer
(*>*)
txt‹The induction is over propstar r x y (the first matching assumption)
and we try to prove \mbox{propstar r y z  star r x z},
which we abbreviate by propP x y. These are our two subgoals:
@{subgoals[display,indent=0]}
The first one is propP x x, the result of case @{thm[source]refl},
and it is trivial:\index{assumption@assumption›}
›
apply(assumption)
txt‹Let us examine subgoal 2›, case @{thm[source] step}.
Assumptions propr u x and \mbox{propstar r x y}
are the premises of rule @{thm[source]step}.
Assumption propstar r y z  star r x z is \mbox{propP x y},
the IH coming from propstar r x y. We have to prove propP u y,
which we do by assuming propstar r y z and proving propstar r u z.
The proof itself is straightforward: from \mbox{propstar r y z} the IH
leads to propstar r x z which, together with propr u x,
leads to \mbox{propstar r u z} via rule @{thm[source]step}:
›
apply(metis step)
done

text‹\index{rule induction|)}

\subsection{The General Case}

Inductive definitions have approximately the following general form:
\begin{quote}
\isacom{inductive} I :: "τ ⇒ bool"› \isacom{where}
\end{quote}
followed by a sequence of (possibly named) rules of the form
\begin{quote}
⟦ I a1; …; I an ⟧ ⟹ I a›
\end{quote}
separated by |›. As usual, n› can be 0.
The corresponding rule induction principle
I.induct› applies to propositions of the form
\begin{quote}
propI x  P x
\end{quote}
where P› may itself be a chain of implications.
\begin{warn}
Rule induction is always on the leftmost premise of the goal.
Hence I x› must be the first premise.
\end{warn}
Proving propI x  P x by rule induction means proving
for every rule of I› that P› is invariant:
\begin{quote}
⟦ I a1; P a1; …; I an; P an ⟧ ⟹ P a›
\end{quote}

The above format for inductive definitions is simplified in a number of
respects. I› can have any number of arguments and each rule can have
additional premises not involving I›, so-called \conceptidx{side
conditions}{side condition}. In rule inductions, these side conditions appear as additional
assumptions. The \isacom{for} clause seen in the definition of the reflexive
transitive closure simplifies the induction rule.
\index{inductive definition|)}

\subsection*{Exercises}

\begin{exercise}
Formalize the following definition of palindromes
\begin{itemize}
\item The empty list and a singleton list are palindromes.
\item If xs› is a palindrome, so is terma # xs @ [a].
\end{itemize}
as an inductive predicate palindrome ::› typ'a list  bool
and prove that proprev xs = xs if xs› is a palindrome.
\end{exercise}

\exercise
We could also have defined conststar as follows:
›

inductive star' :: "('a  'a  bool)  'a  'a  bool" for r where
refl': "star' r x x" |
step': "star' r x y  r y z  star' r x z"

text‹
The single r› step is performed after rather than before the star'›
steps. Prove propstar' r x y  star r x y and
propstar r x y  star' r x y. You may need lemmas.
Note that rule induction fails
if the assumption about the inductive predicate is not the first assumption.
\endexercise

\begin{exercise}\label{exe:iter}
Analogous to conststar, give an inductive definition of the n›-fold iteration
of a relation r›: termiter r n x y should hold if there are x0, \dots, xn
such that propx = x0, propxn = y and r xi xi+1 for
all propi < n. Correct and prove the following claim:
propstar r x y  iter r n x y.
\end{exercise}

\begin{exercise}\label{exe:cfg}
A context-free grammar can be seen as an inductive definition where each
nonterminal $A$ is an inductively defined predicate on lists of terminal
symbols: $A(w)$ means that $w$ is in the language generated by $A$.
For example, the production $S \to a S b$ can be viewed as the implication
propS w  S (a # w @ [b]) where a› and b› are terminal symbols,
i.e., elements of some alphabet. The alphabet can be defined like this:
\isacom{datatype} alpha = a | b | …›

Define the two grammars (where $\varepsilon$ is the empty word)
\[
\begin{array}{r@ {\quad}c@ {\quad}l}
S &\to& \varepsilon \quad\mid\quad aSb \quad\mid\quad SS \\
T &\to& \varepsilon \quad\mid\quad TaTb
\end{array}
\]
as two inductive predicates.
If you think of a› and b› as ``(›'' and  ``)›'',
the grammars define balanced strings of parentheses.
Prove propT w  S w and \mbox{propS w  T w} separately and conclude
propS w = T w.
\end{exercise}

\ifsem
\begin{exercise}
In \autoref{sec:AExp} we defined a recursive evaluation function
aval :: aexp ⇒ state ⇒ val›.
Define an inductive evaluation predicate
aval_rel :: aexp ⇒ state ⇒ val ⇒ bool›
and prove that it agrees with the recursive function:
propaval_rel a s v  aval a s = v, 
propaval a s = v  aval_rel a s v and thus
\noquotes{@{prop [source] "aval_rel a s v  aval a s = v"}}.
\end{exercise}

\begin{exercise}
Consider the stack machine from Chapter~3
and recall the concept of \concept{stack underflow}
from Exercise~\ref{exe:stack-underflow}.
Define an inductive predicate
ok :: nat ⇒ instr list ⇒ nat ⇒ bool›
such that ok n is n'› means that with any initial stack of length
n› the instructions is› can be executed
without stack underflow and that the final stack has length n'›.
Prove that ok› correctly computes the final stack size
@{prop[display] "ok n is n'; length stk = n  length (exec is s stk) = n'"}
and that instruction sequences generated by comp›
cannot cause stack underflow: \ ok n (comp a) ?› \ for
some suitable value of ?›.
\end{exercise}
\fi
›
(*<*)
end
(*>*)