isabelle’s logics

λ→

∀=Is

abelle

β

α

Isabelle’s Logics

Lawrence C. PaulsonComputer Laboratory

University of [email protected]

With Contributions by Tobias Nipkow and Markus Wenzel1

20 February 2021

1Markus Wenzel made numerous improvements. Sara Kalvala contributedChap. 4. Philippe de Groote wrote the first version of the logic LK. Tobias Nip-kow developed LCF and Cube. Martin Coen developed Modal with assistance fromRajeev Gore. The research has been funded by the EPSRC (grants GR/G53279,GR/H40570, GR/K57381, GR/K77051, GR/M75440) and by ESPRIT (projects3245: Logical Frameworks, and 6453: Types), and by the DFG Schwerpunktpro-gramm Deduktion.

Contents

1 Syntax definitions 3

2 Higher-Order Logic 52.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Types and overloading . . . . . . . . . . . . . . . . . . 52.1.2 Binders . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 The let and case constructions . . . . . . . . . . . . . . 9

2.2 Rules of inference . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 A formulation of set theory . . . . . . . . . . . . . . . . . . . 14

2.3.1 Syntax of set theory . . . . . . . . . . . . . . . . . . . 142.3.2 Axioms and rules of set theory . . . . . . . . . . . . . . 172.3.3 Properties of functions . . . . . . . . . . . . . . . . . . 20

2.4 Simplification and substitution . . . . . . . . . . . . . . . . . . 222.4.1 Case splitting . . . . . . . . . . . . . . . . . . . . . . . 23

2.5 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.1 Product and sum types . . . . . . . . . . . . . . . . . . 242.5.2 The type of natural numbers, nat . . . . . . . . . . . . 262.5.3 Numerical types and numerical reasoning . . . . . . . . 282.5.4 The type constructor for lists, list . . . . . . . . . . . . 29

2.6 Datatype definitions . . . . . . . . . . . . . . . . . . . . . . . 292.6.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.6.2 Defining datatypes . . . . . . . . . . . . . . . . . . . . 37

2.7 Old-style recursive function definitions . . . . . . . . . . . . . 382.8 Example: Cantor’s Theorem . . . . . . . . . . . . . . . . . . . 41

3 First-Order Sequent Calculus 443.1 Syntax and rules of inference . . . . . . . . . . . . . . . . . . . 443.2 Automatic Proof . . . . . . . . . . . . . . . . . . . . . . . . . 503.3 Tactics for the cut rule . . . . . . . . . . . . . . . . . . . . . . 503.4 Tactics for sequents . . . . . . . . . . . . . . . . . . . . . . . . 513.5 A simple example of classical reasoning . . . . . . . . . . . . . 523.6 A more complex proof . . . . . . . . . . . . . . . . . . . . . . 533.7 *Unification for lists . . . . . . . . . . . . . . . . . . . . . . . 553.8 *Packaging sequent rules . . . . . . . . . . . . . . . . . . . . . 56

i

CONTENTS ii

3.9 *Proof procedures . . . . . . . . . . . . . . . . . . . . . . . . . 573.9.1 Method A . . . . . . . . . . . . . . . . . . . . . . . . . 573.9.2 Method B . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 Defining A Sequent-Based Logic 594.1 Concrete syntax of sequences . . . . . . . . . . . . . . . . . . 594.2 Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3 Object logics . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.4 What’s in Sequents.thy . . . . . . . . . . . . . . . . . . . . . 61

5 Constructive Type Theory 635.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Rules of inference . . . . . . . . . . . . . . . . . . . . . . . . . 695.3 Rule lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.4 Tactics for subgoal reordering . . . . . . . . . . . . . . . . . . 735.5 Rewriting tactics . . . . . . . . . . . . . . . . . . . . . . . . . 735.6 Tactics for logical reasoning . . . . . . . . . . . . . . . . . . . 745.7 A theory of arithmetic . . . . . . . . . . . . . . . . . . . . . . 755.8 The examples directory . . . . . . . . . . . . . . . . . . . . . . 755.9 Example: type inference . . . . . . . . . . . . . . . . . . . . . 775.10 An example of logical reasoning . . . . . . . . . . . . . . . . . 785.11 Example: deriving a currying functional . . . . . . . . . . . . 815.12 Example: proving the Axiom of Choice . . . . . . . . . . . . . 83

Preface

Several logics come with Isabelle. Many of them are sufficiently developedto serve as comfortable reasoning environments. They are also good startingpoints for defining new logics. Each logic is distributed with sample proofs,some of which are described in this document.

HOL is currently the best developed Isabelle object-logic, including an ex-tensive library of (concrete) mathematics, and various packages for advanceddefinitional concepts (like (co-)inductive sets and types, well-founded recur-sion etc.). The distribution also includes some large applications.

ZF provides another starting point for applications, with a slightly lessdeveloped library than HOL. ZF’s definitional packages are similar to thoseof HOL. Untyped ZF set theory provides more advanced constructions forsets than simply-typed HOL. ZF is built on FOL (first-order logic), both aredescribed in a separate manual Isabelle’s Logics: FOL and ZF [12].

There are some further logics distributed with Isabelle:

CCL is Martin Coen’s Classical Computational Logic, which is the basis of apreliminary method for deriving programs from proofs [2]. It is builtupon classical FOL.

LCF is a version of Scott’s Logic for Computable Functions, which is alsoimplemented by the lcf system [13]. It is built upon classical FOL.

HOLCF is a version of lcf, defined as an extension of HOL. See [10] for moredetails on HOLCF.

CTT is a version of Martin-Lof’s Constructive Type Theory [11], with exten-sional equality. Universes are not included.

Cube is Barendregt’s λ-cube.

The directory Sequents contains several logics based upon the sequentcalculus. Sequents have the form A1, . . . ,Am ` B1, . . . ,Bn ; rules are appliedusing associative matching.

LK is classical first-order logic as a sequent calculus.

Modal implements the modal logics T , S4, and S43.

1

CONTENTS 2

ILL implements intuitionistic linear logic.

The logics CCL, LCF, Modal, ILL and Cube are undocumented. All object-logics’ sources are distributed with Isabelle (see the directory src). They arealso available for browsing on the WWW at

http://www.cl.cam.ac.uk/Research/HVG/Isabelle/library/https://isabelle.in.tum.de/library/

Note that this is not necessarily consistent with your local sources!

Do not read the Isabelle’s Logics manuals before reading Isabelle/HOL —The Tutorial or Introduction to Isabelle, and performing some Isabelle proofs.Consult the Reference Manual for more information on tactics, packages, etc.

http://www.cl.cam.ac.uk/Research/HVG/Isabelle/library/

https://isabelle.in.tum.de/library/

Chapter 1

Syntax definitions

The syntax of each logic is presented using a context-free grammar. Thesegrammars obey the following conventions:

• identifiers denote nonterminal symbols

• typewriter font denotes terminal symbols

• parentheses (. . .) express grouping

• constructs followed by a Kleene star, such as id∗ and (. . .)∗ can berepeated 0 or more times

• alternatives are separated by a vertical bar, |

• the symbol for alphanumeric identifiers is id

• the symbol for scheme variables is var

To reduce the number of nonterminals and grammar rules required, Isabelle’ssyntax module employs priorities, or precedences. Each grammar rule isgiven by a mixfix declaration, which has a priority, and each argument placehas a priority. This general approach handles infix operators that associateeither to the left or to the right, as well as prefix and binding operators.

In a syntactically valid expression, an operator’s arguments never involvean operator of lower priority unless brackets are used. Consider first-orderlogic, where ∃ has lower priority than ∨, which has lower priority than ∧.There, P ∧ Q ∨ R abbreviates (P ∧ Q) ∨ R rather than P ∧ (Q ∨ R). Also,∃x .P ∨Q abbreviates ∃x . (P ∨Q) rather than (∃x .P)∨Q . Note especiallythat P ∨ (∃x .Q) becomes syntactically invalid if the brackets are removed.

A binder is a symbol associated with a constant of type (σ ⇒ τ) ⇒ τ ′.For instance, we may declare ∀ as a binder for the constant All , which hastype (α ⇒ o) ⇒ o. This defines the syntax ∀x . t to mean All(λx . t). We canalso write ∀x1 . . . xm . t to abbreviate ∀x1 . . . . ∀xm . t ; this is possible for anyconstant provided that τ and τ ′ are the same type. The Hilbert descriptionoperator εx . P x has type (α ⇒ bool) ⇒ α and normally binds only one

3

CHAPTER 1. SYNTAX DEFINITIONS 4

variable. ZF’s bounded quantifier ∀x ∈ A . P(x ) cannot be declared as abinder because it has type [i , i ⇒ o] ⇒ o. The syntax for binders allowstype constraints on bound variables, as in

∀(x ::α) (y ::β) z ::γ .Q(x , y , z )

To avoid excess detail, the logic descriptions adopt a semi-formal style.Infix operators and binding operators are listed in separate tables, whichinclude their priorities. Grammar descriptions do not include numeric pri-orities; instead, the rules appear in order of decreasing priority. This shouldsuffice for most purposes; for full details, please consult the actual syntaxdefinitions in the .thy files.

Each nonterminal symbol is associated with some Isabelle type. For ex-ample, the formulae of first-order logic have type o. Every Isabelle expressionof type o is therefore a formula. These include atomic formulae such as P ,where P is a variable of type o, and more generally expressions such asP(t , u), where P , t and u have suitable types. Therefore, ‘expression oftype o’ is listed as a separate possibility in the grammar for formulae.

Chapter 2

Higher-Order Logic

This chapter describes Isabelle’s formalization of Higher-Order Logic, a poly-morphic version of Church’s Simple Theory of Types. HOL can be best un-derstood as a simply-typed version of classical set theory. The monographIsabelle/HOL — A Proof Assistant for Higher-Order Logic provides a gentleintroduction on using Isabelle/HOL in practice. All of this material is mainlyof historical interest!

2.1 Syntax

Figure 2.1 lists the constants (including infixes and binders), while Fig. 2.2presents the grammar of higher-order logic. Note that a~=b is translated to¬(a = b).

! HOL has no if-and-only-if connective; logical equivalence is expressed usingequality. But equality has a high priority, as befitting a relation, while if-and-

only-if typically has the lowest priority. Thus, ¬¬P = P abbreviates ¬¬(P = P)and not (¬¬P) = P . When using = to mean logical equivalence, enclose bothoperands in parentheses.

2.1.1 Types and overloading

The universal type class of higher-order terms is called term. By default,explicit type variables have class term. In particular the equality symboland quantifiers are polymorphic over class term.

The type of formulae, bool , belongs to class term; thus, formulae areterms. The built-in type fun, which constructs function types, is overloadedwith arity (term, term) term. Thus, σ ⇒ τ belongs to class term if σ and τdo, allowing quantification over functions.

HOL allows new types to be declared as subsets of existing types, eitherusing the primitive typedef or the more convenient datatype (see §2.6).

Several syntactic type classes — plus, minus, times and power— permitoverloading of the operators +, -, *. and ^. They are overloaded to denote

5

CHAPTER 2. HIGHER-ORDER LOGIC 6

name meta-type descriptionTrueprop bool ⇒ prop coercion to prop

Not bool ⇒ bool negation (¬)True bool tautology (>)False bool absurdity (⊥)

If [bool , α, α] ⇒ α conditionalLet [α, α ⇒ β] ⇒ β let binder

Constants

symbol name meta-type descriptionSOME or @ Eps (α ⇒ bool) ⇒ α Hilbert description (ε)ALL or ! All (α ⇒ bool) ⇒ bool universal quantifier (∀)EX or ? Ex (α ⇒ bool) ⇒ bool existential quantifier (∃)EX! or ?! Ex1 (α ⇒ bool) ⇒ bool unique existence (∃!)

LEAST Least (α :: ord ⇒ bool) ⇒ α least element

Binders

symbol meta-type priority descriptiono [β ⇒ γ, α ⇒ β] ⇒ (α ⇒ γ) Left 55 composition (◦)= [α, α] ⇒ bool Left 50 equality (=)< [α :: ord , α] ⇒ bool Left 50 less than (<)

<= [α :: ord , α] ⇒ bool Left 50 less than or equals (≤)& [bool , bool ] ⇒ bool Right 35 conjunction (∧)| [bool , bool ] ⇒ bool Right 30 disjunction (∨)

--> [bool , bool ] ⇒ bool Right 25 implication (→)

Infixes

Figure 2.1: Syntax of HOL


the obvious arithmetic operations on types nat, int and real. (With the ^operator, the exponent always has type nat.) Non-arithmetic overloadingsare also done: the operator - can denote set difference, while ^ can denoteexponentiation of relations (iterated composition). Unary minus is also writ-ten as - and is overloaded like its 2-place counterpart; it even can stand forset complement.

The constant 0 is also overloaded. It serves as the zero element of severaltypes, of which the most important is nat (the natural numbers). The typeclass plus_ac0 comprises all types for which 0 and + satisfy the laws x+y =y+x , (x+y)+z = x+(y+z ) and 0+x = x . These types include the numericones nat, int and real and also multisets. The summation operator sum isavailable for all types in this class.

Theory Ord defines the syntactic class ord of order signatures. The rela-tions < and ≤ are polymorphic over this class, as are the functions mono, minand max, and the LEAST operator. Ord also defines a subclass order of ordwhich axiomatizes the types that are partially ordered with respect to ≤. Afurther subclass linorder of order axiomatizes linear orderings. For details,see the file Ord.thy.

If you state a goal containing overloaded functions, you may need toinclude type constraints. Type inference may otherwise make the goal morepolymorphic than you intended, with confusing results. For example, thevariables i , j and k in the goal i ≤ j =⇒ i ≤ j +k have type α :: {ord , plus},although you may have expected them to have some numeric type, e.g. nat .Instead you should have stated the goal as (i :: nat) ≤ j =⇒ i ≤ j +k , whichcauses all three variables to have type nat .

! If resolution fails for no obvious reason, try setting show_types to true, caus-ing Isabelle to display types of terms. Possibly set show_sorts to true as well,

causing Isabelle to display type classes and sorts.Where function types are involved, Isabelle’s unification code does not guar-

antee to find instantiations for type variables automatically. Be prepared to useres_inst_tac instead of resolve_tac, possibly instantiating type variables. Set-ting Unify.trace_types to true causes Isabelle to report omitted search pathsduring unification.

2.1.2 Binders

Hilbert’s description operator εx . P [x ] stands for some x satisfying P , ifsuch exists. Since all terms in HOL denote something, a description is alwaysmeaningful, but we do not know its value unless P defines it uniquely. Wemay write descriptions as Eps(λx . P [x ]) or use the syntax SOME x. P [x ].


Existential quantification is defined by

∃x . P x ≡ P(εx . P x ).

The unique existence quantifier, ∃!x . P , is defined in terms of ∃ and ∀. AnIsabelle binder, it admits nested quantifications. For instance, ∃!x y . P x yabbreviates ∃!x . ∃!y .P x y ; note that this does not mean that there exists aunique pair (x , y) satisfying P x y .

The basic Isabelle/HOL binders have two notations. Apart from the usualALL and EX for ∀ and ∃, Isabelle/HOL also supports the original notation ofGordon’s hol system: ! and ?. In the latter case, the existential quantifiermust be followed by a space; thus ?x is an unknown, while ? x. f x=y is aquantification. Both notations are accepted for input. The print mode “HOL”governs the output notation. If enabled (e.g. by passing option -m HOL tothe isabelle executable), then ! and ? are displayed.

If τ is a type of class ord, P a formula and x a variable of type τ , thenthe term LEAST x . P [x ] is defined to be the least (w.r.t. ≤) x such that P xholds (see Fig. 2.4). The definition uses Hilbert’s ε choice operator, so Least

is always meaningful, but may yield nothing useful in case there is not aunique least element satisfying P .1

All these binders have priority 10.

! The low priority of binders means that they need to be enclosed in parenthesiswhen they occur in the context of other operations. For example, instead of

P ∧ ∀x .Q you need to write P ∧ (∀x .Q).

2.1.3 The let and case constructions

Local abbreviations can be introduced by a let construct whose syntax ap-pears in Fig. 2.2. Internally it is translated into the constant Let. It can beexpanded by rewriting with its definition, Let_def.

HOL also defines the basic syntax

case e of c1 => e1 | . . . | cn => en

as a uniform means of expressing case constructs. Therefore case and of

are reserved words. Initially, this is mere syntax and has no logical meaning.By declaring translations, you can cause instances of the case constructto denote applications of particular case operators. This is what happensautomatically for each datatype definition (see §2.6).

1Class ord does not require much of its instances, so ≤ need not be a well-ordering,not even an order at all!


refl t = (t::’a)

subst [| s = t; P s |] ==> P (t::’a)

ext (!!x::’a. (f x :: ’b) = g x) ==> (%x. f x) = (%x. g x)

impI (P ==> Q) ==> P-->Q

mp [| P-->Q; P |] ==> Q

iff (P-->Q) --> (Q-->P) --> (P=Q)

someI P(x::’a) ==> P(@x. P x)

True_or_False (P=True) | (P=False)

Figure 2.3: The HOL rules

! Both if and case constructs have as low a priority as quantifiers, which re-quires additional enclosing parentheses in the context of most other opera-

tions. For example, instead of f x = if . . . then . . . else . . . you need to writef x = (if . . . then . . . else . . .).

2.2 Rules of inference

Figure 2.3 shows the primitive inference rules of HOL, with their ml names.Some of the rules deserve additional comments:

ext expresses extensionality of functions.

iff asserts that logically equivalent formulae are equal.

someI gives the defining property of the Hilbert ε-operator. It is a form ofthe Axiom of Choice. The derived rule some_equality (see below) isoften easier to use.

True_or_False makes the logic classical.2

HOL follows standard practice in higher-order logic: only a few connec-tives are taken as primitive, with the remainder defined obscurely (Fig. 2.4).Gordon’s hol system expresses the corresponding definitions [6, page 270]using object-equality (=), which is possible because equality in higher-orderlogic may equate formulae and even functions over formulae. But the-ory HOL, like all other Isabelle theories, uses meta-equality (==) for defi-nitions.

2In fact, the ε-operator already makes the logic classical, as shown by Diaconescu; seePaulson [14] for details.


True_def True == ((%x::bool. x)=(%x. x))

All_def All == (%P. P = (%x. True))

Ex_def Ex == (%P. P(@x. P x))

False_def False == (!P. P)

not_def not == (%P. P-->False)

and_def op & == (%P Q. !R. (P-->Q-->R) --> R)

or_def op | == (%P Q. !R. (P-->R) --> (Q-->R) --> R)

Ex1_def Ex1 == (%P. ? x. P x & (! y. P y --> y=x))

o_def op o == (%(f::’b=>’c) g x::’a. f(g x))

if_def If P x y ==

(%P x y. @z::’a.(P=True --> z=x) & (P=False --> z=y))

Let_def Let s f == f s

Least_def Least P == @x. P(x) & (ALL y. P(y) --> x <= y)"

Figure 2.4: The HOL definitions

! The definitions above should never be expanded and are shown for complete-ness only. Instead users should reason in terms of the derived rules shown

below or, better still, using high-level tactics.

Some of the rules mention type variables; for example, refl mentions thetype variable ’a. This allows you to instantiate type variables explicitly bycalling res_inst_tac.

Some derived rules are shown in Figures 2.5 and 2.6, with their ml names.These include natural rules for the logical connectives, as well as sequent-styleelimination rules for conjunctions, implications, and universal quantifiers.

Note the equality rules: ssubst performs substitution in backward proofs,while box_equals supports reasoning by simplifying both sides of an equa-tion.

The following simple tactics are occasionally useful:

strip_tac i applies allI and impI repeatedly to remove all outermost uni-versal quantifiers and implications from subgoal i .

case_tac "P" i performs case distinction on P for subgoal i : the latter isreplaced by two identical subgoals with the added assumptions P and¬P , respectively.

smp_tac j i applies j times spec and then mp in subgoal i , which is typi-cally useful when forward-chaining from an induction hypothesis. As ageneralization of mp_tac, if there are assumptions ∀~x . P~x → Q~x andP~a, (~x being a vector of j variables) then it replaces the universallyquantified implication by Q~a. It may instantiate unknowns. It fails ifit can do nothing.


2.3 A formulation of set theory

Historically, higher-order logic gives a foundation for Russell andWhitehead’stheory of classes. Let us use modern terminology and call them sets, butnote that these sets are distinct from those of ZF set theory, and behavemore like ZF classes.

• Sets are given by predicates over some type σ. Types serve to defineuniverses for sets, but type-checking is still significant.

• There is a universal set (for each type). Thus, sets have complements,and may be defined by absolute comprehension.

• Although sets may contain other sets as elements, the containing setmust have a more complex type.

Finite unions and intersections have the same behaviour in HOL as they doin ZF. In HOL the intersection of the empty set is well-defined, denoting theuniversal set for the given type.

2.3.1 Syntax of set theory

HOL’s set theory is called Set. The type α set is essentially the same asα ⇒ bool . The new type is defined for clarity and to avoid complicationsinvolving function types in unification. The isomorphisms between the twotypes are declared explicitly. They are very natural: Collect maps α ⇒ boolto α set , while op : maps in the other direction (ignoring argument order).

Figure 2.7 lists the constants, infixes, and syntax translations. Figure 2.8presents the grammar of the new constructs. Infix operators include unionand intersection (A ∪ B and A ∩ B), the subset and membership relations,and the image operator ‘‘. Note that a~:b is translated to ¬(a ∈ b).

The {a1, . . .} notation abbreviates finite sets constructed in the obviousmanner using insert and {}:

{a, b, c} ≡ insert a (insert b (insert c {}))

The set {x. P [x ]} consists of all x (of suitable type) that satisfy P [x ],where P [x ] is a formula that may contain free occurrences of x . This syntaxexpands to Collect(λx . P [x ]). It defines sets by absolute comprehension,which is impossible in ZF; the type of x implicitly restricts the comprehen-sion.


name meta-type description{} α set the empty set

insert [α, α set ] ⇒ α set insertion of elementCollect (α ⇒ bool) ⇒ α set comprehension

INTER [α set , α ⇒ β set ] ⇒ β set intersection over a setUNION [α set , α ⇒ β set ] ⇒ β set union over a setInter (α set)set ⇒ α set set of sets intersectionUnion (α set)set ⇒ α set set of sets union

Pow α set ⇒ (α set)set powerset

range (α ⇒ β) ⇒ β set range of a function

Ball Bex [α set , α ⇒ bool ] ⇒ bool bounded quantifiers

Constants

symbol name meta-type priority descriptionINT INTER1 (α ⇒ β set) ⇒ β set 10 intersectionUN UNION1 (α ⇒ β set) ⇒ β set 10 union

Binders

symbol meta-type priority description‘‘ [α ⇒ β, α set ] ⇒ β set Left 90 image

Int [α set , α set ] ⇒ α set Left 70 intersection (∩)Un [α set , α set ] ⇒ α set Left 65 union (∪): [α, α set ] ⇒ bool Left 50 membership (∈)

<= [α set , α set ] ⇒ bool Left 50 subset (⊆)

Infixes

Figure 2.7: Syntax of the theory Set


external internal descriptiona ~: b ~(a : b) not in

{a1, . . .} insert a1 . . . {} finite set{x. P [x ]} Collect(λx . P [x ]) comprehension

INT x:A. B [x ] INTER A λx . B [x ] intersectionUN x:A. B [x ] UNION A λx . B [x ] union

ALL x:A. P [x ] or ! x:A. P [x ] Ball A λx . P [x ] bounded ∀EX x:A. P [x ] or ? x:A. P [x ] Bex A λx . P [x ] bounded ∃

Translations

term = other terms. . .| {}

| { term (,term)∗ }

| { id . formula }

| term ‘‘ term| term Int term| term Un term| INT id:term . term| UN id:term . term| INT id id∗ . term| UN id id∗ . term

formula = other formulae. . .| term : term| term ~: term| term <= term| ALL id:term . formula | ! id:term . formula| EX id:term . formula | ? id:term . formula

Full Grammar

Figure 2.8: Syntax of the theory Set (continued)


mem_Collect_eq (a : {x. P x}) = P a

Collect_mem_eq {x. x:A} = A

empty_def {} == {x. False}

insert_def insert a B == {x. x=a} Un B

Ball_def Ball A P == ! x. x:A --> P x

Bex_def Bex A P == ? x. x:A & P x

subset_def A <= B == ! x:A. x:B

Un_def A Un B == {x. x:A | x:B}

Int_def A Int B == {x. x:A & x:B}

set_diff_def A - B == {x. x:A & x~:B}

Compl_def -A == {x. ~ x:A}

INTER_def INTER A B == {y. ! x:A. y: B x}

UNION_def UNION A B == {y. ? x:A. y: B x}

INTER1_def INTER1 B == INTER {x. True} B

UNION1_def UNION1 B == UNION {x. True} B

Inter_def Inter S == (INT x:S. x)

Union_def Union S == (UN x:S. x)

Pow_def Pow A == {B. B <= A}

image_def f‘‘A == {y. ? x:A. y=f x}

range_def range f == {y. ? x. y=f x}

Figure 2.9: Rules of the theory Set

The set theory defines two bounded quantifiers:

∀x ∈ A . P [x ] abbreviates ∀x . x ∈ A → P [x ]

∃x ∈ A . P [x ] abbreviates ∃x . x ∈ A ∧ P [x ]

The constants Ball and Bex are defined accordingly. Instead of Ball AP and Bex A P we may write ALL x:A. P [x ] and EX x:A. P [x ]. Theoriginal notation of Gordon’s hol system is supported as well: ! and ?.

Unions and intersections over sets, namely⋃

x∈A B [x ] and⋂

x∈A B [x ], arewritten UN x:A. B [x ] and INT x:A. B [x ].

Unions and intersections over types, namely⋃

x B [x ] and⋂

x B [x ], arewritten UN x. B [x ] and INT x. B [x ]. They are equivalent to the previousunion and intersection operators when A is the universal set.

The operators⋃A and

⋂A act upon sets of sets. They are not binders,

but are equal to⋃

x∈A x and⋂

x∈A x , respectively.

2.3.2 Axioms and rules of set theory

Figure 2.9 presents the rules of theory Set. The axioms mem_Collect_eq

and Collect_mem_eq assert that the functions Collect and op : are iso-morphisms. Of course, op : also serves as the membership relation.


CollectI [| P a |] ==> a : {x. P x}

CollectD [| a : {x. P x} |] ==> P a

CollectE [| a : {x. P x}; P a ==> W |] ==> W

ballI [| !!x. x:A ==> P x |] ==> ! x:A. P x

bspec [| ! x:A. P x; x:A |] ==> P x

ballE [| ! x:A. P x; P x ==> Q; ~ x:A ==> Q |] ==> Q

bexI [| P x; x:A |] ==> ? x:A. P x

bexCI [| ! x:A. ~ P x ==> P a; a:A |] ==> ? x:A. P x

bexE [| ? x:A. P x; !!x. [| x:A; P x |] ==> Q |] ==> Q

Comprehension and Bounded quantifiers

subsetI (!!x. x:A ==> x:B) ==> A <= B

subsetD [| A <= B; c:A |] ==> c:B

subsetCE [| A <= B; ~ (c:A) ==> P; c:B ==> P |] ==> P

subset_refl A <= A

subset_trans [| A<=B; B<=C |] ==> A<=C

equalityI [| A <= B; B <= A |] ==> A = B

equalityD1 A = B ==> A<=B

equalityD2 A = B ==> B<=A

equalityE [| A = B; [| A<=B; B<=A |] ==> P |] ==> P

equalityCE [| A = B; [| c:A; c:B |] ==> P;

[| ~ c:A; ~ c:B |] ==> P

|] ==> P

The subset and equality relations

Figure 2.10: Derived rules for set theory


emptyE a : {} ==> P

insertI1 a : insert a B

insertI2 a : B ==> a : insert b B

insertE [| a : insert b A; a=b ==> P; a:A ==> P |] ==> P

ComplI [| c:A ==> False |] ==> c : -A

ComplD [| c : -A |] ==> ~ c:A

UnI1 c:A ==> c : A Un B

UnI2 c:B ==> c : A Un B

UnCI (~c:B ==> c:A) ==> c : A Un B

UnE [| c : A Un B; c:A ==> P; c:B ==> P |] ==> P

IntI [| c:A; c:B |] ==> c : A Int B

IntD1 c : A Int B ==> c:A

IntD2 c : A Int B ==> c:B

IntE [| c : A Int B; [| c:A; c:B |] ==> P |] ==> P

UN_I [| a:A; b: B a |] ==> b: (UN x:A. B x)

UN_E [| b: (UN x:A. B x); !!x.[| x:A; b:B x |] ==> R |] ==> R

INT_I (!!x. x:A ==> b: B x) ==> b : (INT x:A. B x)

INT_D [| b: (INT x:A. B x); a:A |] ==> b: B a

INT_E [| b: (INT x:A. B x); b: B a ==> R; ~ a:A ==> R |] ==> R

UnionI [| X:C; A:X |] ==> A : Union C

UnionE [| A : Union C; !!X.[| A:X; X:C |] ==> R |] ==> R

InterI [| !!X. X:C ==> A:X |] ==> A : Inter C

InterD [| A : Inter C; X:C |] ==> A:X

InterE [| A : Inter C; A:X ==> R; ~ X:C ==> R |] ==> R

PowI A<=B ==> A: Pow B

PowD A: Pow B ==> A<=B

imageI [| x:A |] ==> f x : f‘‘A

imageE [| b : f‘‘A; !!x.[| b=f x; x:A |] ==> P |] ==> P

rangeI f x : range f

rangeE [| b : range f; !!x.[| b=f x |] ==> P |] ==> P

Figure 2.11: Further derived rules for set theory


Union_upper B:A ==> B <= Union A

Union_least [| !!X. X:A ==> X<=C |] ==> Union A <= C

Inter_lower B:A ==> Inter A <= B

Inter_greatest [| !!X. X:A ==> C<=X |] ==> C <= Inter A

Un_upper1 A <= A Un B

Un_upper2 B <= A Un B

Un_least [| A<=C; B<=C |] ==> A Un B <= C

Int_lower1 A Int B <= A

Int_lower2 A Int B <= B

Int_greatest [| C<=A; C<=B |] ==> C <= A Int B

Figure 2.12: Derived rules involving subsets

All the other axioms are definitions. They include the empty set, boundedquantifiers, unions, intersections, complements and the subset relation. Theyalso include straightforward constructions on functions: image (‘‘) andrange.

Figures 2.10 and 2.11 present derived rules. Most are obvious and resem-ble rules of Isabelle’s ZF set theory. Certain rules, such as subsetCE, bexCIand UnCI, are designed for classical reasoning; the rules subsetD, bexI, Un1and Un2 are not strictly necessary but yield more natural proofs. Similarly,equalityCE supports classical reasoning about extensionality, after the fash-ion of iffCE. See the file HOL/Set.ML for proofs pertaining to set theory.

Figure 2.12 presents lattice properties of the subset relation. Unions formleast upper bounds; non-empty intersections form greatest lower bounds.Reasoning directly about subsets often yields clearer proofs than reasoningabout the membership relation. See the file HOL/subset.ML.

Figure 2.13 presents many common set equalities. They include commu-tative, associative and distributive laws involving unions, intersections andcomplements. For a complete listing see the file HOL/equalities.ML.

! Blast_tac proves many set-theoretic theorems automatically. Hence you sel-dom need to refer to the theorems above.

2.3.3 Properties of functions

Figure 2.14 presents a theory of simple properties of functions. Note thatinv f uses Hilbert’s ε to yield an inverse of f . See the file HOL/Fun.ML for acomplete listing of the derived rules. Reasoning about function composition


Int_absorb A Int A = A

Int_commute A Int B = B Int A

Int_assoc (A Int B) Int C = A Int (B Int C)

Int_Un_distrib (A Un B) Int C = (A Int C) Un (B Int C)

Un_absorb A Un A = A

Un_commute A Un B = B Un A

Un_assoc (A Un B) Un C = A Un (B Un C)

Un_Int_distrib (A Int B) Un C = (A Un C) Int (B Un C)

Compl_disjoint A Int (-A) = {x. False}

Compl_partition A Un (-A) = {x. True}

double_complement -(-A) = A

Compl_Un -(A Un B) = (-A) Int (-B)

Compl_Int -(A Int B) = (-A) Un (-B)

Union_Un_distrib Union(A Un B) = (Union A) Un (Union B)

Int_Union A Int (Union B) = (UN C:B. A Int C)

Inter_Un_distrib Inter(A Un B) = (Inter A) Int (Inter B)

Un_Inter A Un (Inter B) = (INT C:B. A Un C)

Figure 2.13: Set equalities

name meta-type descriptioninj surj (α ⇒ β) ⇒ bool injective/surjective

inj_on [α ⇒ β, α set ] ⇒ bool injective over subsetinv (α ⇒ β) ⇒ (β ⇒ α) inverse function

inj_def inj f == ! x y. f x=f y --> x=y

surj_def surj f == ! y. ? x. y=f x

inj_on_def inj_on f A == !x:A. !y:A. f x=f y --> x=y

inv_def inv f == (%y. @x. f(x)=y)

Figure 2.14: Theory Fun


(the operator o) and the predicate surj is done simply by expanding thedefinitions.

There is also a large collection of monotonicity theorems for constructionson sets in the file HOL/mono.ML.

2.4 Simplification and substitution

Simplification tactics tactics such as Asm_simp_tac and Full_simp_tac usethe default simpset (simpset()), which works for most purposes. A quiteminimal simplification set for higher-order logic is HOL_ss; even more frugalis HOL_basic_ss. Equality (=), which also expresses logical equivalence, maybe used for rewriting. See the file HOL/simpdata.ML for a complete listing ofthe basic simplification rules.

See the Reference Manual for details of substitution and simplification.

! Reducing a = b ∧ P(a) to a = b ∧ P(b) is sometimes advantageous. The leftpart of a conjunction helps in simplifying the right part. This effect is not

available by default: it can be slow. It can be obtained by including conj_cong

in a simpset, addcongs [conj_cong].

! By default only the condition of an if is simplified but not the then and else

parts. Of course the latter are simplified once the condition simplifies to True

or False. To ensure full simplification of all parts of a conditional you must removeif_weak_cong from the simpset, delcongs [if_weak_cong].

If the simplifier cannot use a certain rewrite rule — either because ofnontermination or because its left-hand side is too flexible — then you mighttry stac:

stac thm i , where thm is of the form lhs = rhs , replaces in subgoal i in-stances of lhs by corresponding instances of rhs . In case of multipleinstances of lhs in subgoal i , backtracking may be necessary to selectthe desired ones.

If thm is a conditional equality, the instantiated condition becomes anadditional (first) subgoal.

HOL provides the tactic hyp_subst_tac, which substitutes for an equal-ity throughout a subgoal and its hypotheses. This tactic uses HOL’s generalsubstitution rule.


2.4.1 Case splitting

HOL also provides convenient means for case splitting during rewriting.Goals containing a subterm of the form if b then...else... often requirea case distinction on b. This is expressed by the theorem split_if:

?P(if ?b then ?x else ?y) = ((?b → ?P(?x )) ∧ (¬?b → ?P(?y))) (∗)

For example, a simple instance of (∗) is

x ∈ (if x ∈ A then A else {x}) = ((x ∈ A → x ∈ A)∧(x /∈ A → x ∈ {x}))

Because (∗) is too general as a rewrite rule for the simplifier (the left-handside is not a higher-order pattern in the sense of the Reference Manual),there is a special infix function addsplits of type simpset * thm list ->

simpset (analogous to addsimps) that adds rules such as (∗) to a simpset,as in

by(simp_tac (simpset() addsplits [split_if]) 1);

The effect is that after each round of simplification, one occurrence of if issplit acording to split_if, until all occurrences of if have been eliminated.

It turns out that using split_if is almost always the right thing to do.Hence split_if is already included in the default simpset. If you want todelete it from a simpset, use delsplits, which is the inverse of addsplits:

by(simp_tac (simpset() delsplits [split_if]) 1);

In general, addsplits accepts rules of the form

?P(c ?x1 . . . ?xn) = rhs

where c is a constant and rhs is arbitrary. Note that (∗) is of the right formbecause internally the left-hand side is ?P(If ?b ?x ?y). Important furtherexamples are splitting rules for case expressions (see §2.5.4 and §2.6.1).

Analogous to Addsimps and Delsimps, there are also imperative versionsof addsplits and delsplits

Addsplits: thm list -> unit

Delsplits: thm list -> unit

for adding splitting rules to, and deleting them from the current simpset.

2.5 Types

This section describes HOL’s basic predefined types (α × β, α + β, nat andα list) and ways for introducing new types in general. The most importanttype construction, the datatype, is treated separately in §2.6.


2.5.1 Product and sum types

symbol meta-type descriptionPair [α, β] ⇒ α× β ordered pairs (a, b)fst α× β ⇒ α first projectionsnd α× β ⇒ β second projection

split [[α, β] ⇒ γ, α× β] ⇒ γ generalized projectionSigma [α set , α ⇒ β set ] ⇒ (α× β)set general sum of sets

Sigma_def Sigma A B == UN x:A. UN y:B x. {(x,y)}

prod.inject ((a,b) = (a’,b’)) = (a=a’ & b=b’)

Pair_inject [| (a, b) = (a’,b’); [| a=a’; b=b’ |] ==> R |] ==> R

prod.exhaust [| !!x y. p = (x,y) ==> Q |] ==> Q

fst_conv fst (a,b) = a

snd_conv snd (a,b) = b

surjective_pairing p = (fst p,snd p)

split case_prod c (a,b) = c a b

prod.split R(case_prod c p) = (! x y. p = (x,y) --> R(c x y))

SigmaI [| a:A; b:B a |] ==> (a,b) : Sigma A B

SigmaE [| c:Sigma A B; !!x y.[| x:A; y:B x; c=(x,y) |] ==> P

|] ==> P

Figure 2.15: Type α× β

Theory Prod (Fig. 2.15) defines the product type α× β, with the orderedpair syntax (a, b). General tuples are simulated by pairs nested to the right:

external internalτ1 × . . .× τn τ1 × (. . . (τn−1 × τn) . . .)(t1, . . . , tn) (t1, (. . . , (tn−1, tn) . . .)

In addition, it is possible to use tuples as patterns in abstractions:

%(x,y). t stands for split(%x y. t)

Nested patterns are also supported. They are translated stepwise:

%(x,y,z). t ; %(x,(y,z)). t

; case_prod(%x.%(y,z). t)

; case_prod(%x. case_prod(%y z. t))

The reverse translation is performed upon printing.


! The translation between patterns and split is performed automatically by theparser and printer. Thus the internal and external form of a term may differ,

which can affects proofs. For example the term (%(x,y).(y,x))(a,b) requiresthe theorem split (which is in the default simpset) to rewrite to (b,a).

In addition to explicit λ-abstractions, patterns can be used in any variablebinding construct which is internally described by a λ-abstraction. Someimportant examples are

Let: let pattern = t in u

Quantifiers: ALL pattern:A. P

Choice: SOME pattern. P

Set operations: UN pattern:A. B

Sets: {pattern. P}

There is a simple tactic which supports reasoning about patterns:

split_all_tac i replaces in subgoal i all !!-quantified variables of producttype by individual variables for each component. A simple example:

1. !!p. (%(x,y,z). (x, y, z)) p = p

by(split_all_tac 1);

1. !!x xa ya. (%(x,y,z). (x, y, z)) (x, xa, ya) = (x, xa, ya)

Theory Prod also introduces the degenerate product type unit whichcontains only a single element named () with the property

unit_eq u = ()

Theory Sum (Fig. 2.16) defines the sum type α+β which associates to theright and has a lower priority than ∗: τ1+τ2+τ3∗τ4 means τ1+(τ2+(τ3∗τ4)).

The definition of products and sums in terms of existing types is notshown. The constructions are fairly standard and can be found in the re-spective theory files. Although the sum and product types are constructedmanually for foundational reasons, they are represented as actual datatypeslater.


symbol meta-type descriptionInl α ⇒ α+ β first injectionInr β ⇒ α+ β second injection

case_sum [α ⇒ γ, β ⇒ γ, α+ β] ⇒ γ conditional

Inl_not_Inr Inl a ~= Inr b

inj_Inl inj Inl

inj_Inr inj Inr

sumE [| !!x. P(Inl x); !!y. P(Inr y) |] ==> P s

case_sum_Inl case_sum f g (Inl x) = f x

case_sum_Inr case_sum f g (Inr x) = g x

surjective_sum case_sum (%x. f(Inl x)) (%y. f(Inr y)) s = f s

sum.split_case R(case_sum f g s) = ((! x. s = Inl(x) --> R(f(x))) &

(! y. s = Inr(y) --> R(g(y))))

Figure 2.16: Type α + β

2.5.2 The type of natural numbers, nat

The theory Nat defines the natural numbers in a roundabout but traditionalway. The axiom of infinity postulates a type ind of individuals, which isnon-empty and closed under an injective operation. The natural numbers areinductively generated by choosing an arbitrary individual for 0 and using theinjective operation to take successors. This is a least fixedpoint construction.

Type nat is an instance of class ord, which makes the overloaded functionsof this class (especially < and <=, but also min, max and LEAST) available onnat . Theory Nat also shows that <= is a linear order, so nat is also an instanceof class linorder.

Theory NatArith develops arithmetic on the natural numbers. It definesaddition, multiplication and subtraction. Theory Divides defines division,remainder and the “divides” relation. The numerous theorems proved includecommutative, associative, distributive, identity and cancellation laws. SeeFigs. 2.17 and 2.18. The recursion equations for the operators +, - and * onnat are part of the default simpset.

Functions on nat can be defined by primitive or well-founded recursion;see §2.7. A simple example is addition. Here, op + is the name of the infixoperator +, following the standard convention.


symbol meta-type priority description0 α zero

Suc nat ⇒ nat successor function* [α, α] ⇒ α Left 70 multiplication

div [α, α] ⇒ α Left 70 divisionmod [α, α] ⇒ α Left 70 modulusdvd [α, α] ⇒ bool Left 70 “divides” relation+ [α, α] ⇒ α Left 65 addition- [α, α] ⇒ α Left 65 subtraction

Constants and infixes

nat_induct [| P 0; !!n. P n ==> P(Suc n) |] ==> P n

Suc_not_Zero Suc m ~= 0

inj_Suc inj Suc

n_not_Suc_n n~=Suc n

Basic properties

Figure 2.17: The type of natural numbers, nat

0+n = n

(Suc m)+n = Suc(m+n)

m-0 = m

0-n = n

Suc(m)-Suc(n) = m-n

0*n = 0

Suc(m)*n = n + m*n

mod_less m<n ==> m mod n = m

mod_geq [| 0<n; ~m<n |] ==> m mod n = (m-n) mod n

div_less m<n ==> m div n = 0

div_geq [| 0<n; ~m<n |] ==> m div n = Suc((m-n) div n)

Figure 2.18: Recursion equations for the arithmetic operators


primrec

"0 + n = n"

"Suc m + n = Suc (m + n)"

There is also a case-construct of the form

case e of 0 => a | Suc m => b

Note that Isabelle insists on precisely this format; you may not even changethe order of the two cases. Both primrec and case are realized by a recursionoperator rec_nat, which is available because nat is represented as a datatype.

Tactic induct_tac "n" i performs induction on variable n in subgoal iusing theorem nat_induct. There is also the derived theorem less_induct:

[| !!n. [| ! m. m<n --> P m |] ==> P n |] ==> P n

2.5.3 Numerical types and numerical reasoning

The integers (type int) are also available in HOL, and the reals (type real)are available in the logic image HOL-Complex. They support the expectedoperations of addition (+), subtraction (-) and multiplication (*), and muchelse. Type int provides the div and mod operators, while type real providesreal division and other operations. Both types belong to class linorder, sothey inherit the relational operators and all the usual properties of linearorderings. For full details, please survey the theories in subdirectories Integ,Real, and Complex.

All three numeric types admit numerals of the form sd . . . d , where s is anoptional minus sign and d . . . d is a string of digits. Numerals are representedinternally by a datatype for binary notation, which allows numerical calcu-lations to be performed by rewriting. For example, the integer division of54342339 by 3452 takes about five seconds. By default, the simplifier cancelslike terms on the opposite sites of relational operators (reducing z+x<x+y toz<y, for instance. The simplifier also collects like terms, replacing x+y+x*3

by 4*x+y.Sometimes numerals are not wanted, because for example n+3 does not

match a pattern of the form Suc k . You can re-arrange the form of an arith-metic expression by proving (via subgoal_tac) a lemma such as n+3 = Suc

(Suc (Suc n)). As an alternative, you can disable the fancier simplifica-tions by using a basic simpset such as HOL_ss rather than the default one,simpset().

Reasoning about arithmetic inequalities can be tedious. Fortunately,HOL provides a decision procedure for linear arithmetic: formulae involv-ing addition and subtraction. The simplifier invokes a weak version of this


decision procedure automatically. If this is not sufficent, you can invoke thefull procedure Lin_Arith.tac explicitly. It copes with arbitrary formulaeinvolving =, <, <=, +, -, Suc, min, max and numerical constants. Other sub-terms are treated as atomic, while subformulae not involving numerical typesare ignored. Quantified subformulae are ignored unless they are positive uni-versal or negative existential. The running time is exponential in the numberof occurrences of min, max, and - because they require case distinctions. Ifk is a numeral, then div k, mod k and k dvd are also supported. The for-mer two are eliminated by case distinctions, again blowing up the runningtime. If the formula involves explicit quantifiers, Lin_Arith.tac may takesuper-exponential time and space.

If Lin_Arith.tac fails, try to find relevant arithmetic results in the li-brary. The theories Nat and NatArith contain theorems about <, <=, +, -and *. Theory Divides contains theorems about div and mod. Use ProofGeneral’s find button (or other search facilities) to locate them.

2.5.4 The type constructor for lists, list

Figure 2.19 presents the theory List: the basic list operations with theirtypes and syntax. Type α list is defined as a datatype with the constructors[] and #. As a result the generic structural induction and case analysistactics induct tac and cases tac also become available for lists. A case

construct of the form

case e of [] => a | x#xs => b

is defined by translation. For details see §2.6. There is also a case splittingrule list.split

P(case e of [] => a | x#xs => f x xs) =((e = [] → P(a)) ∧ (∀x xs . e = x#xs → P(f x xs)))

which can be fed to addsplits just like split_if (see §2.4.1).List provides a basic library of list processing functions defined by prim-

itive recursion. The recursion equations are shown in Figs. 2.20 and 2.21.

2.6 Datatype definitions

Inductive datatypes, similar to those of ml, frequently appear in applica-tions of Isabelle/HOL. In principle, such types could be defined by handvia typedef, but this would be far too tedious. The datatype definition


symbol meta-type priority description[] α list empty list# [α, α list ] ⇒ α list Right 65 list constructor

null α list ⇒ bool emptiness testhd α list ⇒ α headtl α list ⇒ α list tail

last α list ⇒ α last elementbutlast α list ⇒ α list drop last element

@ [α list , α list ] ⇒ α list Left 65 appendmap (α ⇒ β) ⇒ (α list ⇒ β list) apply to all

filter (α ⇒ bool) ⇒ (α list ⇒ α list) filter functionalset α list ⇒ α set elementsmem α ⇒ α list ⇒ bool Left 55 membership

foldl (β ⇒ α ⇒ β) ⇒ β ⇒ α list ⇒ β iterationconcat (α list)list ⇒ α list concatenation

rev α list ⇒ α list reverselength α list ⇒ nat length

! α list ⇒ nat ⇒ α Left 100 indexingtake, drop nat ⇒ α list ⇒ α list take/drop a prefixtakeWhile,dropWhile (α ⇒ bool) ⇒ α list ⇒ α list take/drop a prefix

Constants and infixes

external internal description[x1, . . ., xn] x1 # · · · # xn # [] finite list

[x:l. P] filter (λx .P) l list comprehension

Translations

Figure 2.19: The theory List


null [] = True

null (x#xs) = False

hd (x#xs) = x

tl (x#xs) = xs

tl [] = []

[] @ ys = ys

(x#xs) @ ys = x # xs @ ys

set [] = {}

set (x#xs) = insert x (set xs)

x mem [] = False

x mem (y#ys) = (if y=x then True else x mem ys)

concat([]) = []

concat(x#xs) = x @ concat(xs)

rev([]) = []

rev(x#xs) = rev(xs) @ [x]

length([]) = 0

length(x#xs) = Suc(length(xs))

xs!0 = hd xs

xs!(Suc n) = (tl xs)!n

Figure 2.20: Simple list processing functions


map f [] = []

map f (x#xs) = f x # map f xs

filter P [] = []

filter P (x#xs) = (if P x then x#filter P xs else filter P xs)

foldl f a [] = a

foldl f a (x#xs) = foldl f (f a x) xs

take n [] = []

take n (x#xs) = (case n of 0 => [] | Suc(m) => x # take m xs)

drop n [] = []

drop n (x#xs) = (case n of 0 => x#xs | Suc(m) => drop m xs)

takeWhile P [] = []

takeWhile P (x#xs) = (if P x then x#takeWhile P xs else [])

dropWhile P [] = []

dropWhile P (x#xs) = (if P x then dropWhile P xs else xs)

Figure 2.21: Further list processing functions

package of Isabelle/HOL (cf. [1]) automates such chores. It generates anappropriate typedef based on a least fixed-point construction, and provesfreeness theorems and induction rules, as well as theorems for recursion andcase combinators. The user just has to give a simple specification of newinductive types using a notation similar to ml or Haskell.

The current datatype package can handle both mutual and indirect re-cursion. It also offers to represent existing types as datatypes giving theadvantage of a more uniform view on standard theories.

2.6.1 Basics

A general datatype definition is of the following form:

datatype (~α)t1 = C 11 τ 11,1 . . . τ 11,m1

1| . . . | C 1

k1τ 1k1,1 . . . τ 1k1,m1

k1...

and (~α)tn = C n1 τn1,1 . . . τn1,mn

1| . . . | C n

kn τnkn ,1 . . . τnkn ,mnkn

where ~α = (α1, . . . , αh) is a list of type variables, C ji are distinct constructor

names and τ ji ,i ′ are admissible types containing at most the type variablesα1, . . . , αh . A type τ occurring in a datatype definition is admissible if andonly if


• τ is non-recursive, i.e. τ does not contain any of the newly defined typeconstructors t1, . . . , tn , or

• τ = (~α)tj ′ where 1 ≤ j ′ ≤ n, or

• τ = (τ ′1, . . . , τ′h ′)t ′, where t ′ is the type constructor of an already existing

datatype and τ ′1, . . . , τ′h ′ are admissible types.

• τ = σ → τ ′, where τ ′ is an admissible type and σ is non-recursive (i.e.the occurrences of the newly defined types are strictly positive)

If some (~α)tj ′ occurs in a type τ ji ,i ′ of the form

(. . . , . . . (~α)tj ′ . . . , . . .)t ′

this is called a nested (or indirect) occurrence. A very simple example of adatatype is the type list, which can be defined by

datatype ’a list = Nil

| Cons ’a (’a list)

Arithmetic expressions aexp and boolean expressions bexp can be modelledby the mutually recursive datatype definition

datatype ’a aexp = If_then_else (’a bexp) (’a aexp) (’a aexp)

| Sum (’a aexp) (’a aexp)

| Diff (’a aexp) (’a aexp)

| Var ’a

| Num nat

and ’a bexp = Less (’a aexp) (’a aexp)

| And (’a bexp) (’a bexp)

| Or (’a bexp) (’a bexp)

The datatype term, which is defined by

datatype (’a, ’b) term = Var ’a

| App ’b (((’a, ’b) term) list)

is an example for a datatype with nested recursion. Using nested recursioninvolving function spaces, we may also define infinitely branching datatypes,e.g.

datatype ’a tree = Atom ’a | Branch "nat => ’a tree"

Types in HOL must be non-empty. Each of the new datatypes (~α)tjwith 1 ≤ j ≤ n is non-empty if and only if it has a constructor C j

i with thefollowing property: for all argument types τ ji ,i ′ of the form (~α)tj ′ the datatype(~α)tj ′ is non-empty.


If there are no nested occurrences of the newly defined datatypes, ob-viously at least one of the newly defined datatypes (~α)tj must have a con-structor C j

i without recursive arguments, a base case, to ensure that the newtypes are non-empty. If there are nested occurrences, a datatype can evenbe non-empty without having a base case itself. Since list is a non-emptydatatype, datatype t = C (t list) is non-empty as well.

Freeness of the constructors

The datatype constructors are automatically defined as functions of theirrespective type:

C ji :: [τ ji ,1, . . . , τ

j

i ,mji

] ⇒ (α1, . . . , αh)tj

These functions have certain freeness properties. They construct distinctvalues:

C ji x1 . . . xmj

i6= C j

i ′ y1 . . . ymj

i′for all i 6= i ′.

The constructor functions are injective:

(C ji x1 . . . xmj

i= C j

i y1 . . . ymji) = (x1 = y1 ∧ . . . ∧ xmj

i= ymj

i)

Since the number of distinctness inequalities is quadratic in the number ofconstructors, the datatype package avoids proving them separately if thereare too many constructors. Instead, specific inequalities are proved by asuitable simplification procedure on demand.3

3This procedure, which is already part of the default simpset, may be referred to bythe ML identifier DatatypePackage.distinct_simproc.


Structural induction

The datatype package also provides structural induction rules. For datatypeswithout nested recursion, this is of the following form:∧

x1 . . . xm11. [[Ps11,1

xr11,1 ; . . . ;Ps11,l1

1

xr11,l1

1

]] =⇒ P1

(C 1

1 x1 . . . xm11

)...∧

x1 . . . xm1k1. [[Ps1

k1,1xr1

k1,1; . . . ;Ps1

k1,l1k1

xr1k1,l

1k1

]] =⇒ P1

(C 1

k1x1 . . . xm1

k1

)...∧

x1 . . . xmn1. [[Psn1,1

xrn1,1 ; . . . ;Psn1,ln

1

xrn1,ln

1

]] =⇒ Pn

(C n

1 x1 . . . xmn1

)...∧

x1 . . . xmnkn. [[Psn

kn ,1xrn

kn ,1; . . .Psn

kn ,lnkn

xrnkn ,ln

kn

]] =⇒ Pn

(C n

kn x1 . . . xmnkn

)P1 x1 ∧ . . . ∧ Pn xn

where

Recji :={(

r ji ,1, sji ,1

), . . . ,

(r ji ,l ji

, s ji ,l ji

)}={

(i ′, i ′′)∣∣∣ 1 ≤ i ′ ≤ m j

i ∧ 1 ≤ i ′′ ≤ n ∧ τ ji ,i ′ = (α1, . . . , αh)ti ′′}

i.e. the properties Pj can be assumed for all recursive arguments.For datatypes with nested recursion, such as the term example from

above, things are a bit more complicated. Conceptually, Isabelle/HOL un-folds a definition like

datatype (’a,’b) term = Var ’a

| App ’b (((’a, ’b) term) list)

to an equivalent definition without nesting:

datatype (’a,’b) term = Var

| App ’b ((’a, ’b) term_list)

and (’a,’b) term_list = Nil’

| Cons’ ((’a,’b) term) ((’a,’b) term_list)

Note however, that the type (’a,’b) term_list and the constructors Nil’and Cons’ are not really introduced. One can directly work with the original(isomorphic) type ((’a, ’b) term) list and its existing constructors Niland Cons. Thus, the structural induction rule for term gets the form∧

x . P1 (Var x )∧x1 x2 . P2 x2 =⇒ P1 (App x1 x2)

P2 Nil∧x1 x2 . [[P1 x1;P2 x2]] =⇒ P2 (Cons x1 x2)

P1 x1 ∧ P2 x2


Note that there are two predicates P1 and P2, one for the type (’a,’b) term

and one for the type ((’a, ’b) term) list.For a datatype with function types such as ’a tree, the induction rule

is of the form∧a . P (Atom a)

∧ts . (∀x . P (ts x )) =⇒ P (Branch ts)

P t

In principle, inductive types are already fully determined by freeness andstructural induction. For convenience in applications, the following derivedconstructions are automatically provided for any datatype.

The case construct

The type comes with an ml-like case-construct:

case e of C j1 x1,1 . . . x1,mj

1⇒ e1

...

| C jkjxkj ,1 . . . xkj ,mj

kj

⇒ ekj

where the xi ,j are either identifiers or nested tuple patterns as in §2.5.1.

! All constructors must be present, their order is fixed, and nested patterns arenot supported (with the exception of tuples). Violating this restriction results

in strange error messages.

To perform case distinction on a goal containing a case-construct, thetheorem tj .split is provided:

P(tj case f1 . . . fkj e) = ((∀x1 . . . xmj1. e = C j

1 x1 . . . xmj1→ P(f1 x1 . . . xmj

1))

∧ . . . ∧(∀x1 . . . xmj

kj

. e = C jkjx1 . . . xmj

kj

→ P(fkj x1 . . . xmjkj

)))

where tj_case is the internal name of the case-construct. This theorem canbe added to a simpset via addsplits (see §2.4.1).

Case splitting on assumption works as well, by using the rule tj .split_asmin the same manner. Both rules are available under tj .splits (this name isnot bound in ML, though).

! By default only the selector expression (e above) in a case-construct is simpli-fied, in analogy with if (see page 22). Only if that reduces to a constructor is

one of the arms of the case-construct exposed and simplified. To ensure full simpli-fication of all parts of a case-construct for datatype t , remove t.case_weak_congfrom the simpset, for example by delcongs [thm "t.case_cong_weak"].


The function size

Theory NatArith declares a generic function size of type α ⇒ nat . Eachdatatype defines a particular instance of size by overloading according tothe following scheme:

size(C ji x1 . . . xmj

i) =

0 if Recji = ∅

1 +l ji∑

h=1size xr j

i,hif Recji =

{(r ji ,1, s

ji ,1

), . . . ,

(r ji ,l ji

, s ji ,l ji

)}where Recji is defined above. Viewing datatypes as generalised trees, the sizeof a leaf is 0 and the size of a node is the sum of the sizes of its subtrees +1.

2.6.2 Defining datatypes

The theory syntax for datatype definitions is given in the Isabelle/Isar refer-ence manual. In order to be well-formed, a datatype definition has to obeythe rules stated in the previous section. As a result the theory is extendedwith the new types, the constructors, and the theorems listed in the previoussection.

Most of the theorems about datatypes become part of the default simpsetand you never need to see them again because the simplifier applies themautomatically. Only induction or case distinction are usually invoked byhand.

induct_tac "x" i applies structural induction on variable x to subgoal i ,provided the type of x is a datatype.

induct_tac "x1 . . . xn" i applies simultaneous structural induction on thevariables x1, . . . , xn to subgoal i . This is the canonical way to proveproperties of mutually recursive datatypes such as aexp and bexp, ordatatypes with nested recursion such as term.

In some cases, induction is overkill and a case distinction over all constructorsof the datatype suffices.

case_tac "u" i performs a case analysis for the term u whose type must bea datatype. If the datatype has kj constructors C

j1 , . . .C

jkj, subgoal i is

replaced by kj new subgoals which contain the additional assumptionu = C j

i ′ x1 . . . xmj

i′for i ′ = 1, . . ., kj .

Note that induction is only allowed on free variables that should not occuramong the premises of the subgoal. Case distinction applies to arbitraryterms.


For the technically minded, we exhibit some more details. Processingthe theory file produces an ml structure which, in addition to the usualcomponents, contains a structure named t for each datatype t defined in thefile. Each structure t contains the following elements:

val distinct : thm list

val inject : thm list

val induct : thm

val exhaust : thm

val cases : thm list

val split : thm

val split_asm : thm

val recs : thm list

val size : thm list

val simps : thm list

distinct, inject, induct, size and split contain the theorems describedabove. For user convenience, distinct contains inequalities in both direc-tions. The reduction rules of the case-construct are in cases. All theoremsfrom distinct, inject and cases are combined in simps. In case of mut-ually recursive datatypes, recs, size, induct and simps are contained in aseparate structure named t1 . . . tn .

2.7 Old-style recursive function definitions

Old-style recursive definitions via recdef requires that you supply a well-founded relation that governs the recursion. Recursive calls are only allowedif they make the argument decrease under the relation. Complicated recur-sion forms, such as nested recursion, can be dealt with. Termination caneven be proved at a later time, though having unsolved termination condi-tions around can make work difficult.4

Using recdef, you can declare functions involving nested recursion andpattern-matching. Recursion need not involve datatypes and there are fewsyntactic restrictions. Termination is proved by showing that each recursivecall makes the argument smaller in a suitable sense, which you specify bysupplying a well-founded relation.

Here is a simple example, the Fibonacci function. The first line declaresfib to be a constant. The well-founded relation is simply < (on the naturalnumbers). Pattern-matching is used here: 1 is a macro for Suc 0.

4This facility is based on Konrad Slind’s TFL package [16]. Thanks are due to Konradfor implementing TFL and assisting with its installation.


consts fib :: "nat => nat"

recdef fib "less_than"

"fib 0 = 0"

"fib 1 = 1"

"fib (Suc(Suc x)) = (fib x + fib (Suc x))"

With recdef, function definitions may be incomplete, and patterns mayoverlap, as in functional programming. The recdef package disambiguatesoverlapping patterns by taking the order of rules into account. For missingpatterns, the function is defined to return a default value.

The well-founded relation defines a notion of “smaller” for the function’sargument type. The relation ≺ is well-founded provided it admits no in-finitely decreasing chains

· · · ≺ xn ≺ · · · ≺ x1.

If the function’s argument has type τ , then ≺ has to be a relation over τ : itmust have type (τ × τ)set .

Proving well-foundedness can be tricky, so Isabelle/HOL provides a col-lection of operators for building well-founded relations. The package recog-nises these operators and automatically proves that the constructed relationis well-founded. Here are those operators, in order of importance:

• less_than is “less than” on the natural numbers. (It has type (nat ×nat)set , while < has type [nat , nat ] ⇒ bool .

• measure f , where f has type τ ⇒ nat , is the relation ≺ on type τ suchthat x ≺ y if and only if f (x ) < f (y). Typically, f takes the recursivefunction’s arguments (as a tuple) and returns a result expressed interms of the function size. It is called a measure function. Recallthat size is overloaded and is defined on all datatypes (see §2.6.1).

• inv imageR f is a generalisation of measure. It specifies a relationsuch that x ≺ y if and only if f (x ) is less than f (y) according to R,which must itself be a well-founded relation.

• R1<*lex*>R2 is the lexicographic product of two relations. It is arelation on pairs and satisfies (x1, x2) ≺ (y1, y2) if and only if x1 is lessthan y1 according to R1 or x1 = y1 and x2 is less than y2 accordingto R2.

• finite_psubset is the proper subset relation on finite sets.

We can use measure to declare Euclid’s algorithm for the greatest com-mon divisor. The measure function, λ(m, n) . n, specifies that the recursionterminates because argument n decreases.


recdef gcd "measure ((%(m,n). n) ::nat*nat=>nat)"

"gcd (m, n) = (if n=0 then m else gcd(n, m mod n))"

The general form of a well-founded recursive definition is

recdef function relcongs congruence rules (optional)simpset simplification set (optional)reduction rules

where

• function is the name of the function, either as an id or a string.

• rel is a HOL expression for the well-founded termination relation.

• congruence rules are required only in highly exceptional circumstances.

• The simplification set is used to prove that the supplied relation iswell-founded. It is also used to prove the termination conditions:assertions that arguments of recursive calls decrease under rel. Bydefault, simplification uses simpset(), which is sufficient to prove well-foundedness for the built-in relations listed above.

• reduction rules specify one or more recursion equations. Each left-handside must have the form f t , where f is the function and t is a tuple ofdistinct variables. If more than one equation is present then f is definedby pattern-matching on components of its argument whose type is adatatype.

The ml identifier f .simps contains the reduction rules as a list oftheorems.

With the definition of gcd shown above, Isabelle/HOL is unable to proveone termination condition. It remains as a precondition of the recursiontheorems:

gcd.simps;

["! m n. n ~= 0 --> m mod n < n

==> gcd (?m,?n) = (if ?n=0 then ?m else gcd (?n, ?m mod ?n))"]

: thm list

The theory HOL/ex/Primes illustrates how to prove termination conditionsafterwards. The function Tfl.tgoalw is like the standard function goalw,which sets up a goal to prove, but its argument should be the identifierf .simps and its effect is to set up a proof of the termination conditions:


Tfl.tgoalw thy [] gcd.simps;

Level 0

! m n. n ~= 0 --> m mod n < n

1. ! m n. n ~= 0 --> m mod n < n

This subgoal has a one-step proof using simp_tac. Once the theorem isproved, it can be used to eliminate the termination conditions from elementsof gcd.simps. Theory HOL/Subst/Unify is a much more complicated exam-ple of this process, where the termination conditions can only be proved bycomplicated reasoning involving the recursive function itself.

Isabelle/HOL can prove the gcd function’s termination condition auto-matically if supplied with the right simpset.

recdef gcd "measure ((%(m,n). n) ::nat*nat=>nat)"

simpset "simpset() addsimps [mod_less_divisor, zero_less_eq]"

"gcd (m, n) = (if n=0 then m else gcd(n, m mod n))"

If all termination conditions were proved automatically, f .simps is addedto the simpset automatically, just as in primrec. The simplification rulescorresponding to clause i (where counting starts at 0) are called f .i and canbe accessed as thms "f .i", which returns a list of theorems. Thus you can,for example, remove specific clauses from the simpset. Note that a singleclause may give rise to a set of simplification rules in order to capture thefact that if clauses overlap, their order disambiguates them.

A recdef definition also returns an induction rule specialised for therecursive function. For the gcd function above, the induction rule is

gcd.induct;

"(!!m n. n ~= 0 --> ?P n (m mod n) ==> ?P m n) ==> ?P ?u ?v" : thm

This rule should be used to reason inductively about the gcd function. Itusually makes the induction hypothesis available at all recursive calls, leadingto very direct proofs. If any termination conditions remain unproved, theywill become additional premises of this rule.

2.8 Example: Cantor’s Theorem

Cantor’s Theorem states that every set has more subsets than it has elements.It has become a favourite example in higher-order logic since it is so easilyexpressed:

∀f :: α ⇒ α ⇒ bool . ∃S :: α ⇒ bool . ∀x :: α . f x 6= S


Viewing types as sets, α ⇒ bool represents the powerset of α. This versionstates that for every function from α to its powerset, some subset is outsideits range.

The Isabelle proof uses HOL’s set theory, with the type α set and theoperator range.

context Set.thy;

The set S is given as an unknown instead of a quantified variable so that wemay inspect the subset found by the proof.

Goal "?S ~: range (f :: ’a=>’a set)";

Level 0

?S ~: range f

1. ?S ~: range f

The first two steps are routine. The rule rangeE replaces ?S ∈ range f by?S = f x for some x .

by (resolve_tac [notI] 1);

Level 1

?S ~: range f

1. ?S : range f ==> False

by (eresolve_tac [rangeE] 1);

Level 2

?S ~: range f

1. !!x. ?S = f x ==> False

Next, we apply equalityCE, reasoning that since ?S = f x , we have ?c ∈ ?Sif and only if ?c ∈ f x for any ?c.

by (eresolve_tac [equalityCE] 1);

Level 3

?S ~: range f

1. !!x. [| ?c3 x : ?S; ?c3 x : f x |] ==> False

2. !!x. [| ?c3 x ~: ?S; ?c3 x ~: f x |] ==> False

Now we use a bit of creativity. Suppose that ?S has the form of a comprehen-sion. Then ?c ∈ {x .?P x} implies ?P ?c. Destruct-resolution using CollectD

instantiates ?S and creates the new assumption.

by (dresolve_tac [CollectD] 1);

Level 4

{x. ?P7 x} ~: range f

1. !!x. [| ?c3 x : f x; ?P7(?c3 x) |] ==> False

2. !!x. [| ?c3 x ~: {x. ?P7 x}; ?c3 x ~: f x |] ==> False

Forcing a contradiction between the two assumptions of subgoal 1 completesthe instantiation of S . It is now the set {x . x 6∈ f x}, which is the standarddiagonal construction.


by (contr_tac 1);

Level 5

{x. x ~: f x} ~: range f

1. !!x. [| x ~: {x. x ~: f x}; x ~: f x |] ==> False

The rest should be easy. To apply CollectI to the negated assumption, weemploy swap_res_tac:

by (swap_res_tac [CollectI] 1);

Level 6


1. !!x. [| x ~: f x; ~ False |] ==> x ~: f x

by (assume_tac 1);

Level 7


No subgoals!

How much creativity is required? As it happens, Isabelle can prove this theo-rem automatically. The default classical set claset() contains rules for mostof the constructs of HOL’s set theory. We must augment it with equalityCE

to break up set equalities, and then apply best-first search. Depth-first searchwould diverge, but best-first search successfully navigates through the largesearch space.

choplev 0;

Level 0

?S ~: range f

1. ?S ~: range f

by (best_tac (claset() addSEs [equalityCE]) 1);

Level 1


No subgoals!

If you run this example interactively, make sure your current theory con-tains theory Set, for example by executing context Set.thy. Otherwise thedefault claset may not contain the rules for set theory.

Chapter 3

First-Order Sequent Calculus

The theory LK implements classical first-order logic through Gentzen’s se-quent calculus (see Gallier [5] or Takeuti [17]). Resembling the method ofsemantic tableaux, the calculus is well suited for backwards proof. Asser-tions have the form Γ ` ∆, where Γ and ∆ are lists of formulae. Associativeunification, simulated by higher-order unification, handles lists (§3.7 presentsdetails, if you are interested).

The logic is many-sorted, using Isabelle’s type classes. The class of first-order terms is called term. No types of individuals are provided, but ex-tensions can define types such as nat::term and type constructors such aslist::(term)term. Below, the type variable α ranges over class term; theequality symbol and quantifiers are polymorphic (many-sorted). The type offormulae is o, which belongs to class logic.

LK implements a classical logic theorem prover that is nearly as powerfulas the generic classical reasoner. The simplifier is now available too.

To work in LK, start up Isabelle specifying Sequents as the object-logic.Once in Isabelle, change the context to theory LK.thy:

isabelle Sequents

context LK.thy;

Modal logic and linear logic are also available, but unfortunately they arenot documented.

3.1 Syntax and rules of inference

Figure 3.1 gives the syntax for LK, which is complicated by the representationof sequents. Type sobj ⇒ sobj represents a list of formulae.

The definite description operator ιx . P [x ] stands for some a satisfy-ing P [a], if one exists and is unique. Since all terms in LK denote something,a description is always meaningful, but we do not know its value unless P [x ]defines it uniquely. The Isabelle notation is THE x. P [x ]. The correspond-ing rule (Fig. 3.4) does not entail the Axiom of Choice because it requiresuniqueness.

44

CHAPTER 3. FIRST-ORDER SEQUENT CALCULUS 45

name meta-type descriptionTrueprop [sobj ⇒ sobj , sobj ⇒ sobj ] ⇒ prop coercion to prop

Seqof [o, sobj ] ⇒ sobj singleton sequenceNot o ⇒ o negation (¬)

True o tautology (>)False o absurdity (⊥)

Constants

symbol name meta-type priority descriptionALL All (α ⇒ o) ⇒ o 10 universal quantifier (∀)EX Ex (α ⇒ o) ⇒ o 10 existential quantifier (∃)THE The (α ⇒ o) ⇒ α 10 definite description (ι)

Binders

symbol meta-type priority description= [α, α] ⇒ o Left 50 equality (=)& [o, o] ⇒ o Right 35 conjunction (∧)| [o, o] ⇒ o Right 30 disjunction (∨)

--> [o, o] ⇒ o Right 25 implication (→)<-> [o, o] ⇒ o Right 25 biconditional (↔)

Infixes

external internal descriptionΓ |- ∆ Trueprop(Γ, ∆) sequent Γ ` ∆

Translations

Figure 3.1: Syntax of LK


basic $H, P, $G |- $E, P, $F

contRS $H |- $E, $S, $S, $F ==> $H |- $E, $S, $F

contLS $H, $S, $S, $G |- $E ==> $H, $S, $G |- $E

thinRS $H |- $E, $F ==> $H |- $E, $S, $F

thinLS $H, $G |- $E ==> $H, $S, $G |- $E

cut [| $H |- $E, P; $H, P |- $E |] ==> $H |- $E

Structural rules

refl $H |- $E, a=a, $F

subst $H(a), $G(a) |- $E(a) ==> $H(b), a=b, $G(b) |- $E(b)

Equality rules

Figure 3.3: Basic Rules of LK

Conditional expressions are available with the notation

if formula then term else term.

Figure 3.2 presents the grammar of LK. Traditionally, Γ and ∆ are meta-variables for sequences. In Isabelle’s notation, the prefix $ on a term makesit range over sequences. In a sequent, anything not prefixed by $ is taken asa formula.

The notation <<sequence>> stands for a sequence of formulæ. For exam-ple, you can declare the constant imps to consist of two implications:

consts P,Q,R :: o

constdefs imps :: seq’=>seq’

"imps == <<P --> Q, Q --> R>>"

Then you can use it in axioms and goals, for example


proof procedure, they guarantee termination, but are incomplete. Multipleuse of a quantifier can be obtained by a contraction rule, which in backwardproof duplicates a formula. The tactic res_inst_tac can instantiate thevariable ?P in these rules, specifying the formula to duplicate. See theorySequents/LK0 in the sources for complete listings of the rules and derivedrules.

To support the simplifier, hundreds of equivalences are proved forthe logical connectives and for if-then-else expressions. See the fileSequents/simpdata.ML.

3.2 Automatic Proof

LK instantiates Isabelle’s simplifier. Both equality (=) and the biconditional(↔) may be used for rewriting. The tactic Simp_tac refers to the defaultsimpset (simpset()). With sequents, the full_ and asm_ forms of the sim-plifier are not required; all the formulae in the sequent will be simplified.The left-hand formulae are taken as rewrite rules. (Thus, the behaviour iswhat you would normally expect from calling Asm_full_simp_tac.)

For classical reasoning, several tactics are available:

Safe_tac : int -> tactic

Step_tac : int -> tactic

Fast_tac : int -> tactic

Best_tac : int -> tactic

Pc_tac : int -> tactic

These refer not to the standard classical reasoner but to a separate oneprovided for the sequent calculus. Two commands are available for addingnew sequent calculus rules, safe or unsafe, to the default “theorem pack”:

Add_safes : thm list -> unit

Add_unsafes : thm list -> unit

To control the set of rules for individual invocations, lower-case versions ofall these primitives are available. Sections 3.8 and 3.9 give full details.

3.3 Tactics for the cut rule

According to the cut-elimination theorem, the cut rule can be eliminatedfrom proofs of sequents. But the rule is still essential. It can be used tostructure a proof into lemmas, avoiding repeated proofs of the same formula.More importantly, the cut rule cannot be eliminated from derivations of rules.


For example, there is a trivial cut-free proof of the sequent P ∧ Q ` Q ∧ P .Noting this, we might want to derive a rule for swapping the conjuncts in aright-hand formula:

Γ ` ∆,P ∧Q

Γ ` ∆,Q ∧ P

The cut rule must be used, for P ∧Q is not a subformula of Q∧P . Most cutsdirectly involve a premise of the rule being derived (a meta-assumption). Ina few cases, the cut formula is not part of any premise, but serves as a bridgebetween the premises and the conclusion. In such proofs, the cut formula isspecified by calling an appropriate tactic.

cutR_tac : string -> int -> tactic

cutL_tac : string -> int -> tactic

These tactics refine a subgoal into two by applying the cut rule. The cutformula is given as a string, and replaces some other formula in the sequent.

cutR_tac P i reads an LK formula P , and applies the cut rule to subgoal i .It then deletes some formula from the right side of subgoal i , replacingthat formula by P .

cutL_tac P i reads an LK formula P , and applies the cut rule to subgoal i .It then deletes some formula from the left side of the new subgoal i+1,replacing that formula by P .

All the structural rules — cut, contraction, and thinning — can be appliedto particular formulae using res_inst_tac.

3.4 Tactics for sequents

forms_of_seq : term -> term list

could_res : term * term -> bool

could_resolve_seq : term * term -> bool

filseq_resolve_tac : thm list -> int -> int -> tactic

Associative unification is not as efficient as it might be, in part because therepresentation of lists defeats some of Isabelle’s internal optimisations. Thefollowing operations implement faster rule application, and may have otheruses.

forms_of_seq t returns the list of all formulae in the sequent t , removingsequence variables.


could_res (t,u) tests whether two formula lists could be resolved. Listt is from a premise or subgoal, while u is from the conclusion of anobject-rule. Assuming that each formula in u is surrounded by sequencevariables, it checks that each conclusion formula is unifiable (usingcould_unify) with some subgoal formula.

could_resolve_seq (t,u) tests whether two sequents could be resolved.Sequent t is a premise or subgoal, while u is the conclusion of anobject-rule. It simply calls could_res twice to check that both the leftand the right sides of the sequents are compatible.

filseq_resolve_tac thms maxr i uses filter_thms could_resolve toextract the thms that are applicable to subgoal i . If more thanmaxr theorems are applicable then the tactic fails. Otherwise itcalls resolve_tac. Thus, it is the sequent calculus analogue offilt_resolve_tac.

3.5 A simple example of classical reasoning

The theorem ` ∃y . ∀x . P(y) → P(x ) is a standard example of the classicaltreatment of the existential quantifier. Classical reasoning is easy using LK,as you can see by comparing this proof with the one given in the FOL man-ual [12]. From a logical point of view, the proofs are essentially the same;the key step here is to use exR rather than the weaker exR_thin.

Goal "|- EX y. ALL x. P(y)-->P(x)";

Level 0

|- EX y. ALL x. P(y) --> P(x)

1. |- EX y. ALL x. P(y) --> P(x)

by (resolve_tac [exR] 1);

Level 1

|- EX y. ALL x. P(y) --> P(x)

1. |- ALL x. P(?x) --> P(x), EX x. ALL xa. P(x) --> P(xa)

There are now two formulae on the right side. Keeping the existential one inreserve, we break down the universal one.

by (resolve_tac [allR] 1);

Level 2

|- EX y. ALL x. P(y) --> P(x)

1. !!x. |- P(?x) --> P(x), EX x. ALL xa. P(x) --> P(xa)

by (resolve_tac [impR] 1);

Level 3

|- EX y. ALL x. P(y) --> P(x)

1. !!x. P(?x) |- P(x), EX x. ALL xa. P(x) --> P(xa)

Because LK is a sequent calculus, the formula P(?x ) does not become an


assumption; instead, it moves to the left side. The resulting subgoal cannotbe instantiated to a basic sequent: the bound variable x is not unifiable withthe unknown ?x .

by (resolve_tac [basic] 1);

by: tactic failed

We reuse the existential formula using exR_thin, which discards it; we shallnot need it a third time. We again break down the resulting formula.

by (resolve_tac [exR_thin] 1);

Level 4

|- EX y. ALL x. P(y) --> P(x)

1. !!x. P(?x) |- P(x), ALL xa. P(?x7(x)) --> P(xa)

by (resolve_tac [allR] 1);

Level 5

|- EX y. ALL x. P(y) --> P(x)

1. !!x xa. P(?x) |- P(x), P(?x7(x)) --> P(xa)

by (resolve_tac [impR] 1);

Level 6

|- EX y. ALL x. P(y) --> P(x)

1. !!x xa. P(?x), P(?x7(x)) |- P(x), P(xa)

Subgoal 1 seems to offer lots of possibilities. Actually the only useful step isinstantiating ?x7 to λx . x , transforming ?x7(x ) into x .


Level 7

|- EX y. ALL x. P(y) --> P(x)

No subgoals!

This theorem can be proved automatically. Because it involves quantifierduplication, we employ best-first search:

Goal "|- EX y. ALL x. P(y)-->P(x)";

Level 0

|- EX y. ALL x. P(y) --> P(x)

1. |- EX y. ALL x. P(y) --> P(x)

by (best_tac LK_dup_pack 1);

Level 1

|- EX y. ALL x. P(y) --> P(x)

No subgoals!

3.6 A more complex proof

Many of Pelletier’s test problems for theorem provers [15] can be solved auto-matically. Problem 39 concerns set theory, asserting that there is no Russell


set — a set consisting of those sets that are not members of themselves:

` ¬(∃x . ∀y . y ∈ x ↔ y 6∈ y)

This does not require special properties of membership; we may generalizex ∈ y to an arbitrary predicate F (x , y). The theorem, which is trivial forFast_tac, has a short manual proof. See the directory Sequents/LK formany more examples.

We set the main goal and move the negated formula to the left.

Goal "|- ~ (EX x. ALL y. F(y,x) <-> ~F(y,y))";

Level 0

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. |- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

by (resolve_tac [notR] 1);

Level 1

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. EX x. ALL y. F(y,x) <-> ~ F(y,y) |-

The right side is empty; we strip both quantifiers from the formula on theleft.

by (resolve_tac [exL] 1);

Level 2

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. !!x. ALL y. F(y,x) <-> ~ F(y,y) |-

by (resolve_tac [allL_thin] 1);

Level 3

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. !!x. F(?x2(x),x) <-> ~ F(?x2(x),?x2(x)) |-

The rule iffL says, if P ↔ Q then P and Q are either both true or bothfalse. It yields two subgoals.

by (resolve_tac [iffL] 1);

Level 4

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. !!x. |- F(?x2(x),x), ~ F(?x2(x),?x2(x))

2. !!x. ~ F(?x2(x),?x2(x)), F(?x2(x),x) |-

We must instantiate ?x2, the shared unknown, to satisfy both subgoals. Be-ginning with subgoal 2, we move a negated formula to the left and create abasic sequent.


by (resolve_tac [notL] 2);

Level 5

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. !!x. |- F(?x2(x),x), ~ F(?x2(x),?x2(x))

2. !!x. F(?x2(x),x) |- F(?x2(x),?x2(x))


Level 6

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. !!x. |- F(x,x), ~ F(x,x)

Thanks to the instantiation of ?x2, subgoal 1 is obviously true.

by (resolve_tac [notR] 1);

Level 7

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

1. !!x. F(x,x) |- F(x,x)


Level 8

|- ~ (EX x. ALL y. F(y,x) <-> ~ F(y,y))

No subgoals!

3.7 *Unification for lists

Higher-order unification includes associative unification as a special case, byan encoding that involves function composition [7, page 37]. To representlists, let C be a new constant. The empty list is λx . x , while [t1, t2, . . . , tn ]is represented by

λx . C (t1,C (t2, . . . ,C (tn , x ))).

The unifiers of this with λx . ?f (?g(x )) give all the ways of expressing[t1, t2, . . . , tn ] as the concatenation of two lists.

Unlike orthodox associative unification, this technique can represent cer-tain infinite sets of unifiers by flex-flex equations. But note that the termλx .C (t , ?a) does not represent any list. Flex-flex constraints containing suchgarbage terms may accumulate during a proof.

This technique lets Isabelle formalize sequent calculus rules, where thecomma is the associative operator:

Γ,P ,Q ,∆ ` Θ

Γ,P ∧Q ,∆ ` Θ(∧-left)

Multiple unifiers occur whenever this is resolved against a goal containingmore than one conjunction on the left.

LK exploits this representation of lists. As an alternative, the sequentcalculus can be formalized using an ordinary representation of lists, with a


logic program for removing a formula from a list. Amy Felty has applied thistechnique using the language λProlog [4].

Explicit formalization of sequents can be tiresome. But it gives precisecontrol over contraction and weakening, and is essential to handle relevantand linear logics.

3.8 *Packaging sequent rules

The sequent calculi come with simple proof procedures. These are incompletebut are reasonably powerful for interactive use. They expect rules to beclassified as safe or unsafe. A rule is safe if applying it to a provable goalalways yields provable subgoals. If a rule is safe then it can be appliedautomatically to a goal without destroying our chances of finding a proof.For instance, all the standard rules of the classical sequent calculus lk aresafe. An unsafe rule may render the goal unprovable; typical examples arethe weakened quantifier rules allL_thin and exR_thin.

Proof procedures use safe rules whenever possible, using an unsafe rule asa last resort. Those safe rules are preferred that generate the fewest subgoals.Safe rules are (by definition) deterministic, while the unsafe rules require asearch strategy, such as backtracking.

A pack is a pair whose first component is a list of safe rules and whosesecond is a list of unsafe rules. Packs can be extended in an obvious wayto allow reasoning with various collections of rules. For clarity, LK declarespack as an ml datatype, although is essentially a type synonym:

datatype pack = Pack of thm list * thm list;

Pattern-matching using constructor Pack can inspect a pack’s contents.Packs support the following operations:

pack : unit -> pack

pack_of : theory -> pack

empty_pack : pack

prop_pack : pack

LK_pack : pack

LK_dup_pack : pack

add_safes : pack * thm list -> pack infix 4

add_unsafes : pack * thm list -> pack infix 4

pack returns the pack attached to the current theory.

pack_of thy returns the pack attached to theory thy .

empty_pack is the empty pack.


prop_pack contains the propositional rules, namely those for ∧, ∨, ¬, →and ↔, along with the rules basic and refl. These are all safe.

LK_pack extends prop_pack with the safe rules allR and exL and the unsaferules allL_thin and exR_thin. Search using this is incomplete sincequantified formulae are used at most once.

LK_dup_pack extends prop_pack with the safe rules allR and exL and theunsafe rules allL and exR. Search using this is complete, since quan-tified formulae may be reused, but frequently fails to terminate. It isgenerally unsuitable for depth-first search.

pack add_safes rules adds some safe rules to the pack pack .

pack add_unsafes rules adds some unsafe rules to the pack pack .

3.9 *Proof procedures

The LK proof procedure is similar to the classical reasoner described in theReference Manual . In fact it is simpler, since it works directly with sequentsrather than simulating them. There is no need to distinguish introductionrules from elimination rules, and of course there is no swap rule. As always,Isabelle’s classical proof procedures are less powerful than resolution theoremprovers. But they are more natural and flexible, working with an open-endedset of rules.

Backtracking over the choice of a safe rule accomplishes nothing: applyingthem in any order leads to essentially the same result. Backtracking may benecessary over basic sequents when they perform unification. Suppose that 0,1, 2, 3 are constants in the subgoals

P(0),P(1),P(2) ` P(?a)P(0),P(2),P(3) ` P(?a)P(1),P(3),P(2) ` P(?a)

The only assignment that satisfies all three subgoals is ?a 7→ 2, and this canonly be discovered by search. The tactics given below permit backtrackingonly over axioms, such as basic and refl; otherwise they are deterministic.

3.9.1 Method A

reresolve_tac : thm list -> int -> tactic

repeat_goal_tac : pack -> int -> tactic

pc_tac : pack -> int -> tactic

These tactics use a method developed by Philippe de Groote. A subgoal


is refined and the resulting subgoals are attempted in reverse order. Forsome reason, this is much faster than attempting the subgoals in order. Themethod is inherently depth-first.

At present, these tactics only work for rules that have no more than twopremises. They fail — return no next state — if they can do nothing.

reresolve_tac thms i repeatedly applies the thms to subgoal i and theresulting subgoals.

repeat_goal_tac pack i applies the safe rules in the pack to a goal andthe resulting subgoals. If no safe rule is applicable then it applies anunsafe rule and continues.

pc_tac pack i applies repeat_goal_tac using depth-first search to solvesubgoal i .

3.9.2 Method B

safe_tac : pack -> int -> tactic

step_tac : pack -> int -> tactic

fast_tac : pack -> int -> tactic

best_tac : pack -> int -> tactic

These tactics are analogous to those of the generic classical reasoner. Theyuse ‘Method A’ only on safe rules. They fail if they can do nothing.

safe_goal_tac pack i applies the safe rules in the pack to a goal and theresulting subgoals. It ignores the unsafe rules.

step_tac pack i either applies safe rules (using safe_goal_tac) or appliesone unsafe rule.

fast_tac pack i applies step_tac using depth-first search to solve sub-goal i . Despite its name, it is frequently slower than pc_tac.

best_tac pack i applies step_tac using best-first search to solve subgoal i .It is particularly useful for quantifier duplication (using LK_dup_pack).

Chapter 4

Defining A Sequent-BasedLogic

The Isabelle theory Sequents.thy provides facilities for using sequent nota-tion in users’ object logics. This theory allows users to easily interface thesurface syntax of sequences with an underlying representation suitable forhigher-order unification.

4.1 Concrete syntax of sequences

Mathematicians and logicians have used sequences in an informal way muchbefore proof systems such as Isabelle were created. It seems sensible to allowpeople using Isabelle to express sequents and perform proofs in this sameinformal way, and without requiring the theory developer to spend a lot oftime in ml programming.

By using Sequents.thy appropriately, a logic developer can allow usersto refer to sequences in several ways:

• A sequence variable is any alphanumeric string with the first characterbeing a $ sign. So, consider the sequent $A |- B, where $A is intendedto match a sequence of zero or more items.

• A sequence with unspecified sub-sequences and unspecified or individ-ual items is written as a comma-separated list of regular variables (rep-resenting items), particular items, and sequence variables, as in

$A, B, C, $D(x) |- E

Here both $A and $D(x) are allowed to match any subsequences ofitems on either side of the two items that match B and C . Moreover,the sequence matching $D(x) may contain occurrences of x .

• An empty sequence can be represented by a blank space, as in|- true.

59

CHAPTER 4. DEFINING A SEQUENT-BASED LOGIC 60

These syntactic constructs need to be assimilated into the object theorybeing developed. The type that we use for these visible objects is given thename seq. A seq is created either by the empty space, a seqobj or a seqobjfollowed by a seq, with a comma between them. A seqobj is either an itemor a variable representing a sequence. Thus, a theory designer can specifya function that takes two sequences and returns a meta-level proposition bygiving it the Isabelle type [seq, seq] => prop.

This is all part of the concrete syntax, but one may wish to exploit Isa-belle’s higher-order abstract syntax by actually having a different, more pow-erful internal syntax.

4.2 Basis

One could opt to represent sequences as first-order objects (such as simplelists), but this would not allow us to use many facilities Isabelle providesfor matching. By using a slightly more complex representation, users of thelogic can reap many benefits in facilities for proofs and ease of reading logicalterms.

A sequence can be represented as a function — a constructor for fur-ther sequences — by defining a binary abstract function Seq0’ with type[o,seq’]=>seq’, and translating a sequence such as A, B, C into

%s. Seq0’(A, SeqO’(B, SeqO’(C, s)))

This sequence can therefore be seen as a constructor for further sequences.The constructor Seq0’ is never given a value, and therefore it is not possibleto evaluate this expression into a basic value.

Furthermore, if we want to represent the sequence A, $B, C, we notethat $B already represents a sequence, so we can use B itself to refer to thefunction, and therefore the sequence can be mapped to the internal form:%s. SeqO’(A, B(SeqO’(C, s))).

So, while we wish to continue with the standard, well-liked external rep-resentation of sequences, we can represent them internally as functions oftype seq’=>seq’.

4.3 Object logics

Recall that object logics are defined by mapping elements of particular typesto the Isabelle type prop, usually with a function called Trueprop. So, an ob-ject logic proposition P is matched to the Isabelle proposition Trueprop(P).


The name of the function is often hidden, so the user just sees P. Isabelleis eager to make types match, so it inserts Trueprop automatically when anobject of type prop is expected. This mechanism can be observed in most ofthe object logics which are direct descendants of Pure.

In order to provide the desired syntactic facilities for sequent calculi,rather than use just one function that maps object-level propositions tometa-level propositions, we use two functions, and separate internal fromthe external representation.

These functions need to be given a type that is appropriate for the partic-ular form of sequents required: single or multiple conclusions. So multiple-conclusion sequents (used in the LK logic) can be specified by the followingtwo definitions, which are lifted from the inbuilt Sequents/LK.thy:

Trueprop :: two_seqi

"@Trueprop" :: two_seqe ("((_)/ |- (_))" [6,6] 5)

where the types used are defined in Sequents.thy as abbreviations:

two_seqi = [seq’=>seq’, seq’=>seq’] => prop

two_seqe = [seq, seq] => prop

The next step is to actually create links into the low-level parsing andpretty-printing mechanisms, which map external and internal representa-tions. These functions go below the user level and capture the underlyingstructure of Isabelle terms in ml. Fortunately the theory developer need notdelve in this level; Sequents.thy provides the necessary facilities. All thetheory developer needs to add in the ml section is a specification of the twotranslation functions:

ML

val parse_translation = [("@Trueprop",Sequents.two_seq_tr "Trueprop")];

val print_translation = [("Trueprop",Sequents.two_seq_tr’ "@Trueprop")];

In summary: in the logic theory being developed, the developer needs tospecify the types for the internal and external representation of the sequences,and use the appropriate parsing and pretty-printing functions.

4.4 What’s in Sequents.thy

Theory Sequents.thy makes many declarations that you need to knowabout:

1. The Isabelle types given below, which can be used for the constantsthat map object-level sequents and meta-level propositions:


single_seqe = [seq,seqobj] => prop

single_seqi = [seq’=>seq’,seq’=>seq’] => prop

two_seqi = [seq’=>seq’, seq’=>seq’] => prop

two_seqe = [seq, seq] => prop

three_seqi = [seq’=>seq’, seq’=>seq’, seq’=>seq’] => prop

three_seqe = [seq, seq, seq] => prop

four_seqi = [seq’=>seq’, seq’=>seq’, seq’=>seq’, seq’=>seq’] => prop

four_seqe = [seq, seq, seq, seq] => prop

The single_ and two_ sets of mappings for internal and external rep-resentations are the ones used for, say single and multiple conclusionsequents. The other functions are provided to allow rules that manip-ulate more than two functions, as can be seen in the inbuilt objectlogics.

2. An auxiliary syntactic constant has been defined that directly maps asequence to its internal representation:

"@Side" :: seq=>(seq’=>seq’) ("<<(_)>>")

Whenever a sequence (such as << A, $B, $C>>) is entered using thissyntax, it is translated into the appropriate internal representation.This form can be used only where a sequence is expected.

3. The ml functions single tr, two seq tr, three seq tr, four seq

tr for parsing, that is, the translation from external to internalform. Analogously there are single tr’, two seq tr’, three seq

tr’, four seq tr’ for pretty-printing, that is, the translation from in-ternal to external form. These functions can be used in the ml sectionof a theory file to specify the translations to be used. As an exampleof use, note that in LK.thy we declare two identifiers:

val parse_translation =

[("@Trueprop",Sequents.two_seq_tr "Trueprop")];

val print_translation =

[("Trueprop",Sequents.two_seq_tr’ "@Trueprop")];

The given parse translation will be applied whenever a @Trueprop con-stant is found, translating using two_seq_tr and inserting the constantTrueprop. The pretty-printing translation is applied analogously; aterm that contains Trueprop is printed as a @Trueprop.

Chapter 5

Constructive Type Theory

Martin-Lof’s Constructive Type Theory [9, 11] can be viewed at many differ-ent levels. It is a formal system that embodies the principles of intuitionisticmathematics; it embodies the interpretation of propositions as types; it is avehicle for deriving programs from proofs.

Thompson’s book [18] gives a readable and thorough account of TypeTheory. Nuprl is an elaborate implementation [3]. alf is a more recent toolthat allows proof terms to be edited directly [8].

Isabelle’s original formulation of Type Theory was a kind of sequent cal-culus, following Martin-Lof [9]. It included rules for building the context,namely variable bindings with their types. A typical judgement was

a(x1, . . . , xn) ∈ A(x1, . . . , xn) [x1 ∈ A1, x2 ∈ A2(x1), . . . , xn ∈ An(x1, . . . , xn−1)]

This sequent calculus was not satisfactory because assumptions like ‘supposeA is a type’ or ‘suppose B(x ) is a type for all x in A’ could not be formalized.

The theory CTT implements Constructive Type Theory, using naturaldeduction. The judgement above is expressed using

∧and =⇒:∧

x1 . . . xn .[[x1 ∈ A1; x2 ∈ A2(x1); · · · xn ∈ An(x1, . . . , xn−1)]] =⇒a(x1, . . . , xn) ∈ A(x1, . . . , xn)

Assumptions can use all the judgement forms, for instance to express that Bis a family of types over A:∧

x . x ∈ A =⇒ B(x ) type

To justify the CTT formulation it is probably best to appeal directly to thesemantic explanations of the rules [9], rather than to the rules themselves.The order of assumptions no longer matters, unlike in standard Type Theory.Contexts, which are typical of many modern type theories, are difficult torepresent in Isabelle. In particular, it is difficult to enforce that all thevariables in a context are distinct.

The theory does not use polymorphism. Terms in CTT have type i , thetype of individuals. Types in CTT have type t .

63

CHAPTER 5. CONSTRUCTIVE TYPE THEORY 64

name meta-type descriptionType t → prop judgement form

Eqtype [t , t ] → prop judgement formElem [i , t ] → prop judgement form

Eqelem [i , i , t ] → prop judgement formReduce [i , i ] → prop extra judgement form

N t natural numbers type0 i constructor

succ i → i constructorrec [i , i , [i , i ] → i ] → i eliminator

Prod [t , i → t ] → t general product typelambda (i → i) → i constructor

Sum [t , i → t ] → t general sum typepair [i , i ] → i constructor

split [i , [i , i ] → i ] → i eliminatorfst snd i → i projections

inl inr i → i constructors for +when [i , i → i , i → i ] → i eliminator for +

Eq [t , i , i ] → t equality typeeq i constructor

F t empty typecontr i → i eliminator

T t singleton typett i constructor

Figure 5.1: The constants of CTT


CTT supports all of Type Theory apart from list types, well-orderingtypes, and universes. Universes could be introduced a la Tarski, adding newconstants as names for types. The formulation a la Russell, where typesdenote themselves, is only possible if we identify the meta-types i and t.Most published formulations of well-ordering types have difficulties involvingextensionality of functions; I suggest that you use some other method fordefining recursive types. List types are easy to introduce by declaring newrules.

CTT uses the 1982 version of Type Theory, with extensional equality. Thecomputation a = b ∈ A and the equality c ∈ Eq(A, a, b) are interchangeable.Its rewriting tactics prove theorems of the form a = b ∈ A. It could bemodified to have intensional equality, but rewriting tactics would have toprove theorems of the form c ∈ Eq(A, a, b) and the computation rules mightrequire a separate simplifier.

5.1 Syntax

The constants are shown in Fig. 5.1. The infixes include the function appli-cation operator (sometimes called ‘apply’), and the 2-place type operators.Note that meta-level abstraction and application, λx . b and f (a), differ fromobject-level abstraction and application, lam x. b and b‘a. A CTT func-tion f is simply an individual as far as Isabelle is concerned: its Isabelle typeis i , not say i ⇒ i .

The notation for CTT (Fig. 5.2) is based on that of Nordstrom et al. [11].The empty type is called F and the one-element type is T ; other finite typesare built as T + T + T , etc.

Quantification is expressed by sums∑

x∈A B [x ] and products∏

x∈A B [x ].Instead of Sum(A,B) and Prod(A,B) we may write SUM x:A. B [x ] andPROD x:A. B [x ]. For example, we may write

SUM y:B. PROD x:A. C(x,y) for Sum(B, %y. Prod(A, %x. C(x,y)))

The special cases as A*B and A-->B abbreviate general sums and productsover a constant family.1 Isabelle accepts these abbreviations in parsing anduses them whenever possible for printing.

1Unlike normal infix operators, * and --> merely define abbreviations; there are noconstants op * and op -->.


symbol name meta-type priority descriptionlam lambda (i ⇒ o) ⇒ i 10 λ-abstraction

Binders

symbol meta-type priority description‘ [i , i ] → i Left 55 function application+ [t , t ] → t Right 30 sum of two types

Infixes

external internal standard notationPROD x:A . B [x ] Prod(A, λx . B [x ]) product

∏x∈A B [x ]

SUM x:A . B [x ] Sum(A, λx . B [x ]) sum∑

x∈A B [x ]A --> B Prod(A, λx . B) function space A → B

A * B Sum(A, λx . B) binary product A× B

Translations

prop = type type

| type = type| term : type| term = term : type

type = expression of type t| PROD id : type . type| SUM id : type . type

term = expression of type i| lam id id∗ . term| < term , term >

Grammar

Figure 5.2: Syntax of CTT


NF N type

NI0 0 : N

NI_succ a : N ==> succ(a) : N

NI_succL a = b : N ==> succ(a) = succ(b) : N

NE [| p: N; a: C(0);

!!u v. [| u: N; v: C(u) |] ==> b(u,v): C(succ(u))

|] ==> rec(p, a, %u v. b(u,v)) : C(p)

NEL [| p = q : N; a = c : C(0);

!!u v. [| u: N; v: C(u) |] ==> b(u,v)=d(u,v): C(succ(u))

|] ==> rec(p, a, %u v. b(u,v)) = rec(q,c,d) : C(p)

NC0 [| a: C(0);


|] ==> rec(0, a, %u v. b(u,v)) = a : C(0)

NC_succ [| p: N; a: C(0);


|] ==> rec(succ(p), a, %u v. b(u,v)) =

b(p, rec(p, a, %u v. b(u,v))) : C(succ(p))

zero_ne_succ [| a: N; 0 = succ(a) : N |] ==> 0: F

Figure 5.4: Rules for type N

ProdF [| A type; !!x. x:A ==> B(x) type |] ==> PROD x:A. B(x) type

ProdFL [| A = C; !!x. x:A ==> B(x) = D(x) |] ==>

PROD x:A. B(x) = PROD x:C. D(x)

ProdI [| A type; !!x. x:A ==> b(x):B(x)

|] ==> lam x. b(x) : PROD x:A. B(x)

ProdIL [| A type; !!x. x:A ==> b(x) = c(x) : B(x)

|] ==> lam x. b(x) = lam x. c(x) : PROD x:A. B(x)

ProdE [| p : PROD x:A. B(x); a : A |] ==> p‘a : B(a)

ProdEL [| p=q: PROD x:A. B(x); a=b : A |] ==> p‘a = q‘b : B(a)

ProdC [| a : A; !!x. x:A ==> b(x) : B(x)

|] ==> (lam x. b(x)) ‘ a = b(a) : B(a)

ProdC2 p : PROD x:A. B(x) ==> (lam x. p‘x) = p : PROD x:A. B(x)

Figure 5.5: Rules for the product type∏

x∈A B [x ]


SumF [| A type; !!x. x:A ==> B(x) type |] ==> SUM x:A. B(x) type

SumFL [| A = C; !!x. x:A ==> B(x) = D(x)

|] ==> SUM x:A. B(x) = SUM x:C. D(x)

SumI [| a : A; b : B(a) |] ==> <a,b> : SUM x:A. B(x)

SumIL [| a=c:A; b=d:B(a) |] ==> <a,b> = <c,d> : SUM x:A. B(x)

SumE [| p: SUM x:A. B(x);

!!x y. [| x:A; y:B(x) |] ==> c(x,y): C(<x,y>)

|] ==> split(p, %x y. c(x,y)) : C(p)

SumEL [| p=q : SUM x:A. B(x);

!!x y. [| x:A; y:B(x) |] ==> c(x,y)=d(x,y): C(<x,y>)

|] ==> split(p, %x y. c(x,y)) = split(q, %x y. d(x,y)) : C(p)

SumC [| a: A; b: B(a);

!!x y. [| x:A; y:B(x) |] ==> c(x,y): C(<x,y>)

|] ==> split(<a,b>, %x y. c(x,y)) = c(a,b) : C(<a,b>)

fst_def fst(a) == split(a, %x y. x)

snd_def snd(a) == split(a, %x y. y)

Figure 5.6: Rules for the sum type∑

x∈A B [x ]

5.2 Rules of inference

The rules obey the following naming conventions. Type formation rules havethe suffix F. Introduction rules have the suffix I. Elimination rules have thesuffix E. Computation rules, which describe the reduction of eliminators, havethe suffix C. The equality versions of the rules (which permit reductions onsubterms) are called long rules; their names have the suffix L. Introductionand computation rules are often further suffixed with constructor names.

Figure 5.3 presents the equality rules. Most of them are straightforward:reflexivity, symmetry, transitivity and substitution. The judgement Reducedoes not belong to Type Theory proper; it has been added to implementrewriting. The judgement Reduce(a, b) holds when a = b : A holds. It alsoholds when a and b are syntactically identical, even if they are ill-typed,because rule refl_red does not verify that a belongs to A.

The Reduce rules do not give rise to new theorems about the standardjudgements. The only rule with Reduce in a premise is trans_red, whoseother premise ensures that a and b (and thus c) are well-typed.

Figure 5.4 presents the rules for N , the type of natural numbers. Theyinclude zero_ne_succ, which asserts 0 6= n + 1. This is the fourth Peano


EqF [| A type; a : A; b : A |] ==> Eq(A,a,b) type

EqFL [| A=B; a=c: A; b=d : A |] ==> Eq(A,a,b) = Eq(B,c,d)

EqI a = b : A ==> eq : Eq(A,a,b)

EqE p : Eq(A,a,b) ==> a = b : A

EqC p : Eq(A,a,b) ==> p = eq : Eq(A,a,b)

Figure 5.9: Rules for the equality type Eq(A, a, b)

replace_type [| B = A; a : A |] ==> a : B

subst_eqtyparg [| a=c : A; !!z. z:A ==> B(z) type |] ==> B(a)=B(c)

subst_prodE [| p: Prod(A,B); a: A; !!z. z: B(a) ==> c(z): C(z)

|] ==> c(p‘a): C(p‘a)

SumIL2 [| c=a : A; d=b : B(a) |] ==> <c,d> = <a,b> : Sum(A,B)

SumE_fst p : Sum(A,B) ==> fst(p) : A

SumE_snd [| p: Sum(A,B); A type; !!x. x:A ==> B(x) type

|] ==> snd(p) : B(fst(p))

Figure 5.10: Derived rules for CTT

axiom and cannot be derived without universes [9, page 91].The constant rec constructs proof terms when mathematical induction,

rule NE, is applied. It can also express primitive recursion. Since rec can beapplied to higher-order functions, it can even express Ackermann’s function,which is not primitive recursive [18, page 104].

Figure 5.5 shows the rules for general product types, which include func-tion types as a special case. The rules correspond to the predicate calculusrules for universal quantifiers and implication. They also permit reasoningabout functions, with the rules of a typed λ-calculus.

Figure 5.6 shows the rules for general sum types, which include binaryproduct types as a special case. The rules correspond to the predicate cal-culus rules for existential quantifiers and conjunction. They also permitreasoning about ordered pairs, with the projections fst and snd.

Figure 5.7 shows the rules for binary sum types. They correspond tothe predicate calculus rules for disjunction. They also permit reasoningabout disjoint sums, with the injections inl and inr and case analysis oper-ator when.

Figure 5.8 shows the rules for the empty and unit types, F and T . Theycorrespond to the predicate calculus rules for absurdity and truth.


Figure 5.9 shows the rules for equality types. If a = b ∈ A is provablethen eq is a canonical element of the type Eq(A, a, b), and vice versa. Theserules define extensional equality; the most recent versions of Type Theoryuse intensional equality [11].

Figure 5.10 presents the derived rules. The rule subst_prodE is derivedfrom prodE, and is easier to use in backwards proof. The rules SumE_fst

and SumE_snd express the typing of fst and snd; together, they are roughlyequivalent to SumE with the advantage of creating no parameters. Section 5.12below demonstrates these rules in a proof of the Axiom of Choice.

All the rules are given in η-expanded form. For instance, every occur-rence of λu v . b(u, v) could be abbreviated to b in the rules for N . Theexpanded form permits Isabelle to preserve bound variable names duringbackward proof. Names of bound variables in the conclusion (here, u and v)are matched with corresponding bound variables in the premises.

5.3 Rule lists

The Type Theory tactics provide rewriting, type inference, and logical rea-soning. Many proof procedures work by repeatedly resolving certain TypeTheory rules against a proof state. CTT defines lists — each with typethm list — of related rules.

form_rls contains formation rules for the types N , Π, Σ, +, Eq , F , and T .

formL_rls contains long formation rules for Π, Σ, +, and Eq . (For othertypes use refl_type.)

intr_rls contains introduction rules for the types N , Π, Σ, +, and T .

intrL_rls contains long introduction rules for N , Π, Σ, and +. (For T userefl_elem.)

elim_rls contains elimination rules for the types N , Π, Σ, +, and F . Therules for Eq and T are omitted because they involve no eliminator.

elimL_rls contains long elimination rules for N , Π, Σ, +, and F .

comp_rls contains computation rules for the types N , Π, Σ, and +. Thosefor Eq and T involve no eliminator.

basic_defs contains the definitions of fst and snd.


5.4 Tactics for subgoal reordering

test_assume_tac : int -> tactic

typechk_tac : thm list -> tactic

equal_tac : thm list -> tactic

intr_tac : thm list -> tactic

Blind application of CTT rules seldom leads to a proof. The eliminationrules, especially, create subgoals containing new unknowns. These subgoalsunify with anything, creating a huge search space. The standard tacticfilt_resolve_tac (see the Reference Manual) fails for goals that are tooflexible; so does the CTT tactic test_assume_tac. Used with the tacticalREPEAT_FIRST they achieve a simple kind of subgoal reordering: the less flex-ible subgoals are attempted first. Do some single step proofs, or study theexamples below, to see why this is necessary.

test_assume_tac i uses assume_tac to solve the subgoal by assumption,but only if subgoal i has the form a ∈ A and the head of a is not anunknown. Otherwise, it fails.

typechk_tac thms uses thms with formation, introduction, and eliminationrules to check the typing of constructions. It is designed to solve goalsof the form a ∈ ?A, where a is rigid and ?A is flexible; thus it performstype inference. The tactic can also solve goals of the form A type.

equal_tac thms uses thms with the long introduction and elimination rulesto solve goals of the form a = b ∈ A, where a is rigid. It is intendedfor deriving the long rules for defined constants such as the arithmeticoperators. The tactic can also perform type-checking.

intr_tac thms uses thms with the introduction rules to break down a type.It is designed for goals like ?a ∈ A where ?a is flexible and A rigid.These typically arise when trying to prove a proposition A, expressedas a type.

5.5 Rewriting tactics

rew_tac : thm list -> tactic

hyp_rew_tac : thm list -> tactic

Object-level simplification is accomplished through proof, using the CTT

equality rules and the built-in rewriting functor TSimpFun.2 The rewrites

2This should not be confused with Isabelle’s main simplifier; TSimpFun is only usefulfor CTT and similar logics with type inference rules. At present it is undocumented.


include the computation rules and other equations. The long versions ofthe other rules permit rewriting of subterms and subtypes. Also used aretransitivity and the extra judgement form Reduce. Meta-level simplificationhandles only definitional equality.

rew_tac thms applies thms and the computation rules as left-to-rightrewrites. It solves the goal a = b ∈ A by rewriting a to b. If b isan unknown then it is assigned the rewritten form of a. All subgoalsare rewritten.

hyp_rew_tac thms is like rew_tac, but includes as rewrites any equationspresent in the assumptions.

5.6 Tactics for logical reasoning

Interpreting propositions as types lets CTT express statements of intuition-istic logic. However, Constructive Type Theory is not just another syntaxfor first-order logic. There are fundamental differences.

Can assumptions be deleted after use? Not every occurrence of a typerepresents a proposition, and Type Theory assumptions declare variables. Infirst-order logic, ∨-elimination with the assumption P∨Q creates one subgoalassuming P and another assuming Q , and P ∨ Q can be deleted safely. InType Theory, +-elimination with the assumption z ∈ A + B creates onesubgoal assuming x ∈ A and another assuming y ∈ B (for arbitrary x andy). Deleting z ∈ A + B when other assumptions refer to z may render thesubgoal unprovable: arguably, meaningless.

Isabelle provides several tactics for predicate calculus reasoning in CTT:

mp_tac : int -> tactic

add_mp_tac : int -> tactic

safestep_tac : thm list -> int -> tactic

safe_tac : thm list -> int -> tactic

step_tac : thm list -> int -> tactic

pc_tac : thm list -> int -> tactic

These are loosely based on the intuitionistic proof procedures of FOL. For thereasons discussed above, a rule that is safe for propositional reasoning maybe unsafe for type-checking; thus, some of the ‘safe’ tactics are misnamed.

mp_tac i searches in subgoal i for assumptions of the form f ∈ Π(A,B)and a ∈ A, where A may be found by unification. It replaces f ∈Π(A,B) by z ∈ B(a), where z is a new parameter. The tactic canproduce multiple outcomes for each suitable pair of assumptions. Inshort, mp_tac performs Modus Ponens among the assumptions.


add_mp_tac i is like mp_tac i but retains the assumption f ∈ Π(A,B). Itavoids information loss but obviously loops if repeated.

safestep_tac thms i attacks subgoal i using formation rules and certainother ‘safe’ rules (FE, ProdI, SumE, PlusE), calling mp_tac when appro-priate. It also uses thms , which are typically premises of the rule beingderived.

safe_tac thms i attempts to solve subgoal i by means of backtracking,using safestep_tac.

step_tac thms i tries to reduce subgoal i using safestep_tac, then triesunsafe rules. It may produce multiple outcomes.

pc_tac thms i tries to solve subgoal i by backtracking, using step_tac.

5.7 A theory of arithmetic

Arith is a theory of elementary arithmetic. It proves the properties of ad-dition, multiplication, subtraction, division, and remainder, culminating inthe theorem

a mod b + (a/b)× b = a.

Figure 5.11 presents the definitions and some of the key theorems, includingcommutative, distributive, and associative laws.

The operators #+, -, |-|, #*, mod and div stand for sum, difference,absolute difference, product, remainder and quotient, respectively. SinceType Theory has only primitive recursion, some of their definitions may beobscure.

The difference a−b is computed by taking b predecessors of a, where thepredecessor function is λv . rec(v , 0, λx y . x ).

The remainder a mod b counts up to a in a cyclic fashion, using 0 as thesuccessor of b−1. Absolute difference is used to test the equality succ(v) = b.

The quotient a/b is computed by adding one for every number x suchthat 0 ≤ x ≤ a and x mod b = 0.

5.8 The examples directory

This directory contains examples and experimental proofs in CTT.

CTT/ex/typechk.ML contains simple examples of type-checking and type de-duction.


symbol meta-type priority description#* [i , i ] ⇒ i Left 70 multiplicationdiv [i , i ] ⇒ i Left 70 divisionmod [i , i ] ⇒ i Left 70 modulus#+ [i , i ] ⇒ i Left 65 addition- [i , i ] ⇒ i Left 65 subtraction

|-| [i , i ] ⇒ i Left 65 absolute difference

add_def a#+b == rec(a, b, %u v. succ(v))

diff_def a-b == rec(b, a, %u v. rec(v, 0, %x y. x))

absdiff_def a|-|b == (a-b) #+ (b-a)

mult_def a#*b == rec(a, 0, %u v. b #+ v)

mod_def a mod b ==

rec(a, 0, %u v. rec(succ(v) |-| b, 0, %x y. succ(v)))

div_def a div b ==

rec(a, 0, %u v. rec(succ(u) mod b, succ(v), %x y. v))

add_typing [| a:N; b:N |] ==> a #+ b : N

addC0 b:N ==> 0 #+ b = b : N

addC_succ [| a:N; b:N |] ==> succ(a) #+ b = succ(a #+ b) : N

add_assoc [| a:N; b:N; c:N |] ==>

(a #+ b) #+ c = a #+ (b #+ c) : N

add_commute [| a:N; b:N |] ==> a #+ b = b #+ a : N

mult_typing [| a:N; b:N |] ==> a #* b : N

multC0 b:N ==> 0 #* b = 0 : N

multC_succ [| a:N; b:N |] ==> succ(a) #* b = b #+ (a#*b) : N

mult_commute [| a:N; b:N |] ==> a #* b = b #* a : N

add_mult_dist [| a:N; b:N; c:N |] ==>

(a #+ b) #* c = (a #* c) #+ (b #* c) : N

mult_assoc [| a:N; b:N; c:N |] ==>

(a #* b) #* c = a #* (b #* c) : N

diff_typing [| a:N; b:N |] ==> a - b : N

diffC0 a:N ==> a - 0 = a : N

diff_0_eq_0 b:N ==> 0 - b = 0 : N

diff_succ_succ [| a:N; b:N |] ==> succ(a) - succ(b) = a - b : N

diff_self_eq_0 a:N ==> a - a = 0 : N

add_inverse_diff [| a:N; b:N; b-a=0 : N |] ==> b #+ (a-b) = a : N

Figure 5.11: The theory of arithmetic


CTT/ex/elim.ML contains some examples from Martin-Lof [9], proved usingpc_tac.

CTT/ex/equal.ML contains simple examples of rewriting.

CTT/ex/synth.ML demonstrates the use of unknowns with some trivial ex-amples of program synthesis.

5.9 Example: type inference

Type inference involves proving a goal of the form a ∈ ?A, where a is a termand ?A is an unknown standing for its type. The type, initially unknown,takes shape in the course of the proof. Our example is the predecessor func-tion on the natural numbers.

Goal "lam n. rec(n, 0, %x y. x) : ?A";

Level 0

lam n. rec(n,0,%x y. x) : ?A

1. lam n. rec(n,0,%x y. x) : ?A

Since the term is a Constructive Type Theory λ-abstraction (not to beconfused with a meta-level abstraction), we apply the rule ProdI, for Π-introduction. This instantiates ?A to a product type of unknown domainand range.

by (resolve_tac [ProdI] 1);

Level 1

lam n. rec(n,0,%x y. x) : PROD x:?A1. ?B1(x)

1. ?A1 type

2. !!n. n : ?A1 ==> rec(n,0,%x y. x) : ?B1(n)

Subgoal 1 is too flexible. It can be solved by instantiating ?A1 to any type,but most instantiations will invalidate subgoal 2. We therefore tackle thelatter subgoal. It asks the type of a term beginning with rec, which can befound by N -elimination.

by (eresolve_tac [NE] 2);

Level 2

lam n. rec(n,0,%x y. x) : PROD x:N. ?C2(x,x)

1. N type

2. !!n. 0 : ?C2(n,0)

3. !!n x y. [| x : N; y : ?C2(n,x) |] ==> x : ?C2(n,succ(x))

Subgoal 1 is no longer flexible: we now know ?A1 is the type of naturalnumbers. However, let us continue proving nontrivial subgoals. Subgoal 2asks, what is the type of 0?


by (resolve_tac [NI0] 2);

Level 3

lam n. rec(n,0,%x y. x) : N --> N

1. N type

2. !!n x y. [| x : N; y : N |] ==> x : N

The type ?A is now fully determined. It is the product type∏

x∈N N , whichis shown as the function type N → N because there is no dependence on x .But we must prove all the subgoals to show that the original term is validlytyped. Subgoal 2 is provable by assumption and the remaining subgoal fallsby N -formation.

by (assume_tac 2);

Level 4

lam n. rec(n,0,%x y. x) : N --> N

1. N type

by (resolve_tac [NF] 1);

Level 5

lam n. rec(n,0,%x y. x) : N --> N

No subgoals!

Calling typechk_tac can prove this theorem in one step.Even if the original term is ill-typed, one can infer a type for it, but

unprovable subgoals will be left. As an exercise, try to prove the followinginvalid goal:

Goal "lam n. rec(n, 0, %x y. tt) : ?A";

5.10 An example of logical reasoning

Logical reasoning in Type Theory involves proving a goal of the form ?a ∈ A,where type A expresses a proposition and ?a stands for its proof term, a valueof type A. The proof term is initially unknown and takes shape during theproof.

Our example expresses a theorem about quantifiers in a sorted logic:

∃x ∈ A . P(x ) ∨Q(x )

(∃x ∈ A . P(x )) ∨ (∃x ∈ A .Q(x ))

By the propositions-as-types principle, this is encoded using Σ and + types.A special case of it expresses a distributive law of Type Theory:

A× (B + C )

(A× B) + (A× C )


Generalizing this from × to Σ, and making the typing conditions explicit,yields the rule we must derive:

A type

[x ∈ A]....

B(x ) type

[x ∈ A]....

C (x ) type p ∈ ∑x∈A B(x ) + C (x )

?a ∈ (∑

x∈A B(x )) + (∑

x∈A C (x ))

To begin, we bind the rule’s premises — returned by the goal command —to the ml variable prems.

val prems = Goal

"[| A type; \

\ !!x. x:A ==> B(x) type; \

\ !!x. x:A ==> C(x) type; \

\ p: SUM x:A. B(x) + C(x) \

\ |] ==> ?a : (SUM x:A. B(x)) + (SUM x:A. C(x))";

Level 0

?a : (SUM x:A. B(x)) + (SUM x:A. C(x))

1. ?a : (SUM x:A. B(x)) + (SUM x:A. C(x))

val prems = ["A type [A type]",

"?x : A ==> B(?x) type [!!x. x : A ==> B(x) type]",

"?x : A ==> C(?x) type [!!x. x : A ==> C(x) type]",

"p : SUM x:A. B(x) + C(x) [p : SUM x:A. B(x) + C(x)]"]

: thm list

The last premise involves the sum type Σ. Since it is a premise rather thanthe assumption of a goal, it cannot be found by eresolve_tac. We couldinsert it (and the other atomic premise) by calling

cut_facts_tac prems 1;

A forward proof step is more straightforward here. Let us resolve the Σ-elimination rule with the premises using RL. This inference yields one result,which we supply to resolve_tac.

by (resolve_tac (prems RL [SumE]) 1);

Level 1

split(p,?c1) : (SUM x:A. B(x)) + (SUM x:A. C(x))

1. !!x y.

[| x : A; y : B(x) + C(x) |] ==>

?c1(x,y) : (SUM x:A. B(x)) + (SUM x:A. C(x))

The subgoal has two new parameters, x and y . In the main goal, ?a hasbeen instantiated with a split term. The assumption y ∈ B(x ) + C (x ) iseliminated next, causing a case split and creating the parameter xa. Thisinference also inserts when into the main goal.


by (eresolve_tac [PlusE] 1);

Level 2

split(p,%x y. when(y,?c2(x,y),?d2(x,y)))

: (SUM x:A. B(x)) + (SUM x:A. C(x))

1. !!x y xa.

[| x : A; xa : B(x) |] ==>

?c2(x,y,xa) : (SUM x:A. B(x)) + (SUM x:A. C(x))

2. !!x y ya.

[| x : A; ya : C(x) |] ==>

?d2(x,y,ya) : (SUM x:A. B(x)) + (SUM x:A. C(x))

To complete the proof object for the main goal, we need to instantiate theterms ?c2(x , y , xa) and ?d2(x , y , xa). We attack subgoal 1 by a +-introductionrule; since the goal assumes xa ∈ B(x ), we take the left injection (inl).

by (resolve_tac [PlusI_inl] 1);

Level 3

split(p,%x y. when(y,%xa. inl(?a3(x,y,xa)),?d2(x,y)))


1. !!x y xa. [| x : A; xa : B(x) |] ==> ?a3(x,y,xa) : SUM x:A. B(x)

2. !!x y xa. [| x : A; xa : B(x) |] ==> SUM x:A. C(x) type

3. !!x y ya.

[| x : A; ya : C(x) |] ==>


A new subgoal 2 has appeared, to verify that∑

x∈A C (x ) is a type. Continu-ing to work on subgoal 1, we apply the Σ-introduction rule. This instantiatesthe term ?a3(x , y , xa); the main goal now contains an ordered pair, whosecomponents are two new unknowns.

by (resolve_tac [SumI] 1);

Level 4

split(p,%x y. when(y,%xa. inl(<?a4(x,y,xa),?b4(x,y,xa)>),?d2(x,y)))


1. !!x y xa. [| x : A; xa : B(x) |] ==> ?a4(x,y,xa) : A

2. !!x y xa. [| x : A; xa : B(x) |] ==> ?b4(x,y,xa) : B(?a4(x,y,xa))


4. !!x y ya.

[| x : A; ya : C(x) |] ==>


The two new subgoals both hold by assumption. Observe how the unknowns?a4 and ?b4 are instantiated throughout the proof state.

by (assume_tac 1);

Level 5

split(p,%x y. when(y,%xa. inl(<x,?b4(x,y,xa)>),?d2(x,y)))



1. !!x y xa. [| x : A; xa : B(x) |] ==> ?b4(x,y,xa) : B(x)


3. !!x y ya.

[| x : A; ya : C(x) |] ==>


by (assume_tac 1);

Level 6

split(p,%x y. when(y,%xa. inl(<x,xa>),?d2(x,y)))



2. !!x y ya.

[| x : A; ya : C(x) |] ==>


Subgoal 1 is an example of a well-formedness subgoal [3]. Such subgoalsare usually trivial; this one yields to typechk_tac, given the current list ofpremises.

by (typechk_tac prems);

Level 7

split(p,%x y. when(y,%xa. inl(<x,xa>),?d2(x,y)))


1. !!x y ya.

[| x : A; ya : C(x) |] ==>


This subgoal is the other case from the +-elimination above, and can beproved similarly. Quicker is to apply pc_tac. The main goal finally gets afully instantiated proof object.

by (pc_tac prems 1);

Level 8

split(p,%x y. when(y,%xa. inl(<x,xa>),%y. inr(<x,y>)))


No subgoals!

Calling pc_tac after the first Σ-elimination above also proves this theorem.

5.11 Example: deriving a currying functional

In simply-typed languages such as ml, a currying functional has the type

(A× B → C ) → (A → (B → C )).

Let us generalize this to the dependent types Σ and Π. The functional takesa function f that maps z : Σ(A,B) to C (z ); the resulting function mapsx ∈ A and y ∈ B(x ) to C (〈x , y〉).


Formally, there are three typing premises. A is a type; B is an A-indexedfamily of types; C is a family of types indexed by Σ(A,B). The goal isexpressed using PROD f to ensure that the parameter corresponding to thefunctional’s argument is really called f ; Isabelle echoes the type using -->

because there is no explicit dependence upon f .

val prems = Goal

"[| A type; !!x. x:A ==> B(x) type; \

\ !!z. z: (SUM x:A. B(x)) ==> C(z) type \

\ |] ==> ?a : PROD f: (PROD z : (SUM x:A . B(x)) . C(z)). \

\ (PROD x:A . PROD y:B(x) . C(<x,y>))";

Level 0

?a : (PROD z:SUM x:A. B(x). C(z)) -->

(PROD x:A. PROD y:B(x). C(<x,y>))

1. ?a : (PROD z:SUM x:A. B(x). C(z)) -->

(PROD x:A. PROD y:B(x). C(<x,y>))



"?z : SUM x:A. B(x) ==> C(?z) type

[!!z. z : SUM x:A. B(x) ==> C(z) type]"] : thm list

This is a chance to demonstrate intr_tac. Here, the tactic repeatedly appliesΠ-introduction and proves the rather tiresome typing conditions.

Note that ?a becomes instantiated to three nested λ-abstractions. Itwould be easier to read if the bound variable names agreed with the param-eters in the subgoal. Isabelle attempts to give parameters the same namesas corresponding bound variables in the goal, but this does not always work.In any event, the goal is logically correct.

by (intr_tac prems);

Level 1

lam x xa xb. ?b7(x,xa,xb)

: (PROD z:SUM x:A. B(x). C(z)) --> (PROD x:A. PROD y:B(x). C(<x,y>))

1. !!f x y.

[| f : PROD z:SUM x:A. B(x). C(z); x : A; y : B(x) |] ==>

?b7(f,x,y) : C(<x,y>)

Using Π-elimination, we solve subgoal 1 by applying the function f .

by (eresolve_tac [ProdE] 1);

Level 2

lam x xa xb. x ‘ <xa,xb>


1. !!f x y. [| x : A; y : B(x) |] ==> <x,y> : SUM x:A. B(x)

Finally, we verify that the argument’s type is suitable for the function appli-cation. This is straightforward using introduction rules.



Level 3

lam x xa xb. x ‘ <xa,xb>


No subgoals!

Calling pc_tac would have proved this theorem in one step; it can also provean example by Martin-Lof, related to ∨-elimination [9, page 58].

5.12 Example: proving the Axiom of Choice

Suppose we have a function h ∈ ∏x∈A

∑y∈B(x)C (x , y), which takes x ∈ A to

some y ∈ B(x ) paired with some z ∈ C (x , y). Interpreting propositions astypes, this asserts that for all x ∈ A there exists y ∈ B(x ) such that C (x , y).The Axiom of Choice asserts that we can construct a function f ∈ ∏

x∈A B(x )such that C (x , f ‘x ) for all x ∈ A, where the latter property is witnessed bya function g ∈ ∏

x∈A C (x , f ‘x ).In principle, the Axiom of Choice is simple to derive in Constructive Type

Theory. The following definitions work:

f ≡ fst ◦ hg ≡ snd ◦ h

But a completely formal proof is hard to find. The rules can be appliedin countless ways, yielding many higher-order unifiers. The proof can getbogged down in the details. But with a careful selection of derived rules(recall Fig. 5.10) and the type-checking tactics, we can prove the theorem innine steps.

val prems = Goal

"[| A type; !!x. x:A ==> B(x) type; \

\ !!x y.[| x:A; y:B(x) |] ==> C(x,y) type \

\ |] ==> ?a : PROD h: (PROD x:A. SUM y:B(x). C(x,y)). \

\ (SUM f: (PROD x:A. B(x)). PROD x:A. C(x, f‘x))";

Level 0

?a : (PROD x:A. SUM y:B(x). C(x,y)) -->

(SUM f:PROD x:A. B(x). PROD x:A. C(x,f ‘ x))

1. ?a : (PROD x:A. SUM y:B(x). C(x,y)) -->




"[| ?x : A; ?y : B(?x) |] ==> C(?x, ?y) type

[!!x y. [| x : A; y : B(x) |] ==> C(x, y) type]"]

: thm list

First, intr_tac applies introduction rules and performs routine type-checking. This instantiates ?a to a construction involving a λ-abstraction


and an ordered pair. The pair’s components are themselves λ-abstractionsand there is a subgoal for each.


Level 1

lam x. <lam xa. ?b7(x,xa),lam xa. ?b8(x,xa)>

: (PROD x:A. SUM y:B(x). C(x,y)) -->


1. !!h x.

[| h : PROD x:A. SUM y:B(x). C(x,y); x : A |] ==>

?b7(h,x) : B(x)

2. !!h x.


?b8(h,x) : C(x,(lam x. ?b7(h,x)) ‘ x)

Subgoal 1 asks to find the choice function itself, taking x ∈ A to some?b7(h, x ) ∈ B(x ). Subgoal 2 asks, given x ∈ A, for a proof object ?b8(h, x ) towitness that the choice function’s argument and result lie in the relation C .This latter task will take up most of the proof.

by (eresolve_tac [ProdE RS SumE_fst] 1);

Level 2

lam x. <lam xa. fst(x ‘ xa),lam xa. ?b8(x,xa)>



1. !!h x. x : A ==> x : A

2. !!h x.


?b8(h,x) : C(x,(lam x. fst(h ‘ x)) ‘ x)

Above, we have composed fst with the function h. Unification has deducedthat the function must be applied to x ∈ A. We have our choice function.

by (assume_tac 1);

Level 3




1. !!h x.


?b8(h,x) : C(x,(lam x. fst(h ‘ x)) ‘ x)

Before we can compose snd with h, the arguments of C must be simplified.The derived rule replace_type lets us replace a type by any equivalent type,shown below as the schematic term ?A13(h, x ):

by (resolve_tac [replace_type] 1);

Level 4





1. !!h x.


C(x,(lam x. fst(h ‘ x)) ‘ x) = ?A13(h,x)

2. !!h x.


?b8(h,x) : ?A13(h,x)

The derived rule subst_eqtyparg lets us simplify a type’s argument (bycurrying, C (x ) is a unary type operator):

by (resolve_tac [subst_eqtyparg] 1);

Level 5




1. !!h x.


(lam x. fst(h ‘ x)) ‘ x = ?c14(h,x) : ?A14(h,x)

2. !!h x z.

[| h : PROD x:A. SUM y:B(x). C(x,y); x : A;

z : ?A14(h,x) |] ==>

C(x,z) type

3. !!h x.


?b8(h,x) : C(x,?c14(h,x))

Subgoal 1 requires simply β-contraction, which is the rule ProdC. The term?c14(h, x ) in the last subgoal receives the contracted result.

by (resolve_tac [ProdC] 1);

Level 6




1. !!h x.


x : ?A15(h,x)

2. !!h x xa.


xa : ?A15(h,x) |] ==>

fst(h ‘ xa) : ?B15(h,x,xa)

3. !!h x z.


z : ?B15(h,x,x) |] ==>

C(x,z) type

4. !!h x.


?b8(h,x) : C(x,fst(h ‘ x))

Routine type-checking goals proliferate in Constructive Type Theory, but


typechk_tac quickly solves them. Note the inclusion of SumE_fst alongwith the premises.

by (typechk_tac (SumE_fst::prems));

Level 7




1. !!h x.


?b8(h,x) : C(x,fst(h ‘ x))

We are finally ready to compose snd with h.

by (eresolve_tac [ProdE RS SumE_snd] 1);

Level 8

lam x. <lam xa. fst(x ‘ xa),lam xa. snd(x ‘ xa)>



1. !!h x. x : A ==> x : A

2. !!h x. x : A ==> B(x) type

3. !!h x xa. [| x : A; xa : B(x) |] ==> C(x,xa) type

The proof object has reached its final form. We call typechk_tac to finishthe type-checking.

by (typechk_tac prems);

Level 9

lam x. <lam xa. fst(x ‘ xa),lam xa. snd(x ‘ xa)>



No subgoals!

It might be instructive to compare this proof with Martin-Lof’s forward proofof the Axiom of Choice [9, page 50].

Bibliography

[1] Stefan Berghofer and Markus Wenzel. Inductive datatypes in HOL —lessons learned in Formal-Logic Engineering. In Y. Bertot, G. Dowek,A. Hirschowitz, C. Paulin, and L. Thery, editors, Theorem Proving inHigher Order Logics: TPHOLs ’99, volume 1690 of Lecture Notes inComputer Science. Springer-Verlag, 1999.

[2] Martin D. Coen. Interactive Program Derivation. PhD thesis, Universityof Cambridge, November 1992. Computer Laboratory Technical Report272.

[3] R. L. Constable et al. Implementing Mathematics with the Nuprl ProofDevelopment System. Prentice-Hall, 1986.

[4] Amy Felty. A logic program for transforming sequent proofs to naturaldeduction proofs. In Extensions of Logic Programming, InternationalWorkshop, Tubingen, FRG, December 8-10, 1989, Proceedings, pages157–178, 1989.

[5] J. H. Gallier. Logic for Computer Science: Foundations of AutomaticTheorem Proving. Harper & Row, 1986.

[6] M. J. C. Gordon and T. F. Melham, editors. Introduction to HOL:A Theorem Proving Environment for Higher Order Logic. CambridgeUniversity Press, 1993.

[7] G. P. Huet and B. Lang. Proving and applying program transformationsexpressed with second-order patterns. Acta Informatica, 11:31–55, 1978.

[8] Lena Magnusson and Bengt Nordstrom. The ALF proof editor and itsproof engine. In Henk Barendregt and Tobias Nipkow, editors, Typesfor Proofs and Programs: International Workshop TYPES ’93, LNCS806, pages 213–237. Springer, published 1994.

[9] Per Martin-Lof. Intuitionistic type theory. Bibliopolis, 1984.

87

BIBLIOGRAPHY 88

[10] Olaf Muller, Tobias Nipkow, David von Oheimb, and Oscar Slotosch.HOLCF = HOL + LCF. Journal of Functional Programming, 9:191–223,1999.

[11] Bengt Nordstrom, Kent Petersson, and Jan Smith. Programming inMartin-Lof ’s Type Theory. An Introduction. Oxford University Press,1990.

[12] Lawrence C. Paulson. Isabelle’s Logics: FOL and ZF. https://isabelle.in.tum.de/doc/logics-ZF.pdf.

[13] Lawrence C. Paulson. Logic and Computation: Interactive proof withCambridge LCF. Cambridge University Press, 1987.

[14] Lawrence C. Paulson. A formulation of the simple theory of types (forIsabelle). In P. Martin-Lof and G. Mints, editors, COLOG-88: In-ternational Conference on Computer Logic, LNCS 417, pages 246–274,Tallinn, Published 1990. Estonian Academy of Sciences, Springer.

[15] F. J. Pelletier. Seventy-five problems for testing automatic theoremprovers. Journal of Automated Reasoning, 2:191–216, 1986. Errata,JAR 4 (1988), 235–236 and JAR 18 (1997), 135.

[16] Konrad Slind. Function definition in higher order logic. In J. von Wright,J. Grundy, and J. Harrison, editors, Theorem Proving in Higher OrderLogics: TPHOLs ’96, volume 1125 of Lecture Notes in Computer Sci-ence, pages 381–397. Springer-Verlag, 1996.

[17] G. Takeuti. Proof Theory. North-Holland, 2nd edition, 1987.

[18] Simon Thompson. Type Theory and Functional Programming. Addison-Wesley, 1991.

https://isabelle.in.tum.de/doc/logics-ZF.pdf

https://isabelle.in.tum.de/doc/logics-ZF.pdf

Index

! symbol, 6, 9, 16, 17, 30| symbol, 6, 45|-| symbol, 76[] symbol, 30# symbol, 30#* symbol, 76#+ symbol, 76& symbol, 6, 45* symbol, 5, 27, 66* type, 24+ symbol, 5, 27, 66+ type, 24- symbol, 5, 27, 76--> symbol, 6, 45, 66: symbol, 15< constant, 26< symbol, 27<-> symbol, 45<= constant, 26<= symbol, 15= symbol, 6, 45, 66? symbol, 6, 9, 17?! symbol, 6@ symbol, 6, 30^ symbol, 5‘ symbol, 66‘‘ symbol, 15{} symbol, 15

0 constant, 8, 27, 64

absdiff_def theorem, 76absolute difference, 76add_assoc theorem, 76add_commute theorem, 76

add_def theorem, 76add_inverse_diff theorem, 76add_mp_tac, 75add_mult_dist theorem, 76add_safes, 57add_typing theorem, 76add_unsafes, 57addC0 theorem, 76addC_succ theorem, 76Addsplits, 23addsplits, 23, 29, 36ALL symbol, 6, 16, 17, 45All constant, 6, 45All_def theorem, 11all_dupE theorem, 13allE theorem, 13allI theorem, 13allL theorem, 48, 57allL_thin theorem, 49allR theorem, 48and_def theorem, 11arg_cong theorem, 12Arith theory, 75assumptions

in CTT, 63, 74

Ball constant, 15, 17Ball_def theorem, 17ballE theorem, 18ballI theorem, 18basic theorem, 47basic_defs, 72best_tac, 58Bex constant, 15, 17Bex_def theorem, 17

89

INDEX 90

bexCI theorem, 18, 20bexE theorem, 18bexI theorem, 18, 20bool type, 5box_equals theorem, 11, 12bspec theorem, 18butlast constant, 30

case symbol, 28, 29, 36case_sum constant, 26case_sum_Inl theorem, 26case_sum_Inr theorem, 26case_tac, 11, 37case_weak_cong, 36CCL theory, 1ccontr theorem, 13classical theorem, 13Collect constant, 14, 15Collect_mem_eq theorem, 17CollectD theorem, 18, 42CollectE theorem, 18CollectI theorem, 18, 43comp_rls, 72Compl_def theorem, 17Compl_disjoint theorem, 21Compl_Int theorem, 21Compl_partition theorem, 21Compl_Un theorem, 21ComplD theorem, 19ComplI theorem, 19concat constant, 30cong theorem, 12conj_cong, 22conjE theorem, 12conjI theorem, 12conjL theorem, 48conjR theorem, 48conjunct1 theorem, 12conjunct2 theorem, 12Constructive Type Theory, 63–86context, 43

contL theorem, 49contLS theorem, 47contR theorem, 49contr constant, 64contRS theorem, 47could_res, 52could_resolve_seq, 52CTT theory, 1, 63Cube theory, 1cut theorem, 47cutL_tac, 51cutR_tac, 51

datatype, 29Delsplits, 23delsplits, 23diff_0_eq_0 theorem, 76diff_def theorem, 76diff_self_eq_0 theorem, 76diff_succ_succ theorem, 76diff_typing theorem, 76diffC0 theorem, 76disjCI theorem, 13disjE theorem, 12disjI1 theorem, 12disjI2 theorem, 12disjL theorem, 48disjR theorem, 48div symbol, 27, 76div_def theorem, 76div_geq theorem, 27div_less theorem, 27Divides theory, 26double_complement theorem, 21drop constant, 30dropWhile constant, 30dvd symbol, 27

Elem constant, 64elim_rls, 72elimL_rls, 72

INDEX 91

empty_def theorem, 17empty_pack, 56emptyE theorem, 19Eps constant, 6, 8Eq constant, 64eq constant, 64, 72EqC theorem, 71EqE theorem, 71Eqelem constant, 64EqF theorem, 71EqFL theorem, 71EqI theorem, 71Eqtype constant, 64equal_tac, 73equal_types theorem, 67equal_typesL theorem, 67equalityCE theorem, 18, 20, 42, 43equalityD1 theorem, 18equalityD2 theorem, 18equalityE theorem, 18equalityI theorem, 18EX symbol, 6, 16, 17, 45Ex constant, 6, 45EX! symbol, 6Ex1 constant, 6Ex1_def theorem, 11ex1E theorem, 13ex1I theorem, 13Ex_def theorem, 11exCI theorem, 13excluded_middle theorem, 13exE theorem, 13exI theorem, 13exL theorem, 48exR theorem, 48, 52, 57exR_thin theorem, 49, 52, 53ext theorem, 10

F constant, 64False constant, 6, 45False_def theorem, 11

FalseE theorem, 12FalseL theorem, 48fast_tac, 58FE theorem, 70, 75FEL theorem, 70FF theorem, 70filseq_resolve_tac, 52filt_resolve_tac, 52, 73filter constant, 30flex-flex constraints, 55FOL theory, 74foldl constant, 30form_rls, 72formL_rls, 72forms_of_seq, 51fst constant, 24, 64, 71, 72fst_conv theorem, 24fst_def theorem, 69Fun theory, 21fun type, 5fun_cong theorem, 12function applications

in CTT, 66

hd constant, 30higher-order logic, 5–43HOL, 9hol system, 5, 9HOL_basic_ss, 22HOL_ss, 22HOLCF theory, 1hyp_rew_tac, 74hyp_subst_tac, 22

i type, 63If constant, 6if, 22if_def theorem, 11if_not_P theorem, 13if_P theorem, 13if_weak_cong, 22

INDEX 92

iff theorem, 10iff_def theorem, 48iffCE theorem, 13, 20iffD1 theorem, 12iffD2 theorem, 12iffE theorem, 12iffI theorem, 12iffL theorem, 49, 54iffR theorem, 49ILL theory, 2image_def theorem, 17imageE theorem, 19imageI theorem, 19impCE theorem, 13impE theorem, 12impI theorem, 10impL theorem, 48impR theorem, 48in symbol, 7ind type, 26induct_tac, 28, 37inj constant, 21inj_def theorem, 21inj_Inl theorem, 26inj_Inr theorem, 26inj_on constant, 21inj_on_def theorem, 21inj_Suc theorem, 27Inl constant, 26inl constant, 64, 71, 80Inl_not_Inr theorem, 26Inr constant, 26inr constant, 64, 71insert constant, 15insert_def theorem, 17insertE theorem, 19insertI1 theorem, 19insertI2 theorem, 19INT symbol, 15–17Int symbol, 15int theorem, 8, 28

Int_absorb theorem, 21Int_assoc theorem, 21Int_commute theorem, 21INT_D theorem, 19Int_def theorem, 17INT_E theorem, 19Int_greatest theorem, 20INT_I theorem, 19Int_lower1 theorem, 20Int_lower2 theorem, 20Int_Un_distrib theorem, 21Int_Union theorem, 21IntD1 theorem, 19IntD2 theorem, 19IntE theorem, 19INTER constant, 15Inter constant, 15INTER1 constant, 15INTER1_def theorem, 17INTER_def theorem, 17Inter_def theorem, 17Inter_greatest theorem, 20Inter_lower theorem, 20Inter_Un_distrib theorem, 21InterD theorem, 19InterE theorem, 19InterI theorem, 19IntI theorem, 19intr_rls, 72intr_tac, 73, 82, 83intrL_rls, 72inv constant, 21inv_def theorem, 21

lam symbol, 66lambda constant, 64, 66λ-abstractions

in CTT, 66last constant, 30LCF theory, 1LEAST constant, 8, 9, 26

INDEX 93

Least constant, 6Least_def theorem, 11length constant, 30less_induct theorem, 28Let constant, 6, 9let symbol, 7Let_def theorem, 9, 11Lin_Arith.tac, 29linorder class, 8, 26, 28List theory, 29, 30list type, 29list.split theorem, 29LK theory, 1, 44, 49LK_dup_pack, 57, 58LK_pack, 57

map constant, 30max constant, 8, 26mem symbol, 30mem_Collect_eq theorem, 17min constant, 8, 26minus class, 5mod symbol, 27, 76mod_def theorem, 76mod_geq theorem, 27mod_less theorem, 27Modal theory, 1mono constant, 8mp theorem, 10mp_tac, 74mult_assoc theorem, 76mult_commute theorem, 76mult_def theorem, 76mult_typing theorem, 76multC0 theorem, 76multC_succ theorem, 76

N constant, 64n_not_Suc_n theorem, 27Nat theory, 26nat type, 26, 27

nat type, 26–29nat theorem, 8nat_induct theorem, 27NatArith theory, 26NC0 theorem, 68NC_succ theorem, 68NE theorem, 68, 71, 77NEL theorem, 68NF theorem, 68, 78NI0 theorem, 68NI_succ theorem, 68NI_succL theorem, 68NIO theorem, 77Not constant, 6, 45not_def theorem, 11not_sym theorem, 12notE theorem, 12notI theorem, 12notL theorem, 48notnotD theorem, 13notR theorem, 48null constant, 30

o type, 44o symbol, 6, 22o_def theorem, 11of symbol, 9or_def theorem, 11Ord theory, 8ord class, 8, 9, 26order class, 8

pack, 56pack ML type, 56pack_of thy , 56Pair constant, 24pair constant, 64Pair_inject theorem, 24pc_tac, 58, 75, 81, 83plus class, 5plus_ac0 class, 8

INDEX 94

PlusC_inl theorem, 70PlusC_inr theorem, 70PlusE theorem, 70, 75, 79PlusEL theorem, 70PlusF theorem, 70PlusFL theorem, 70PlusI_inl theorem, 70, 80PlusI_inlL theorem, 70PlusI_inr theorem, 70PlusI_inrL theorem, 70Pow constant, 15Pow_def theorem, 17PowD theorem, 19power class, 5PowI theorem, 19primrec symbol, 28priorities, 3PROD symbol, 65, 66Prod constant, 64Prod theory, 24prod.exhaust theorem, 24prod.inject theorem, 24prod.split theorem, 24ProdC theorem, 68, 85ProdC2 theorem, 68ProdE theorem, 68, 82, 84, 86ProdEL theorem, 68ProdF theorem, 68ProdFL theorem, 68ProdI theorem, 68, 75, 77ProdIL theorem, 68prop_pack, 57

range constant, 15, 42range_def theorem, 17rangeE theorem, 19, 42rangeI theorem, 19real theorem, 8, 28rec constant, 64, 71rec_nat constant, 28recdef, 38–41

recursiongeneral, 38–41

red_if_equal theorem, 67Reduce constant, 64, 69, 74refl theorem, 10, 47refl_elem theorem, 67, 72refl_red theorem, 67refl_type theorem, 67, 72REPEAT_FIRST, 73repeat_goal_tac, 58replace_type theorem, 71, 84reresolve_tac, 58res_inst_tac, 8rev constant, 30rew_tac, 74RL, 79RS, 84, 86

safe_goal_tac, 58safe_tac, 75safestep_tac, 75search

best-first, 43Seqof constant, 45sequent calculus, 44–58Set theory, 14, 17set constant, 30set type, 14set_diff_def theorem, 17show_sorts, 8show_types, 8Sigma constant, 24Sigma_def theorem, 24SigmaE theorem, 24SigmaI theorem, 24simplification

of case, 36of if, 22of conjunctions, 22

size constant, 37smp_tac, 11

INDEX 95

snd constant, 24, 64, 71, 72snd_conv theorem, 24snd_def theorem, 69sobj type, 44SOME symbol, 6some_equality theorem, 10, 13someI theorem, 10spec theorem, 13split constant, 24, 64, 79split theorem, 24split_all_tac, 25split_if theorem, 13, 23ssubst theorem, 11, 12stac, 22step_tac, 58, 75strip_tac, 11subset_def theorem, 17subset_refl theorem, 18subset_trans theorem, 18subsetCE theorem, 18, 20subsetD theorem, 18, 20subsetI theorem, 18subst theorem, 10, 47subst_elem theorem, 67subst_elemL theorem, 67subst_eqtyparg theorem, 71, 85subst_prodE theorem, 71, 72subst_type theorem, 67subst_typeL theorem, 67Suc constant, 27Suc_not_Zero theorem, 27succ constant, 64SUM symbol, 65, 66Sum constant, 64Sum theory, 25sum constant, 8sum.split_case theorem, 26SumC theorem, 69SumE theorem, 69, 75, 79sumE theorem, 26SumE_fst theorem, 71, 72, 84, 86

SumE_snd theorem, 71, 72, 86SumEL theorem, 69SumF theorem, 69SumFL theorem, 69SumI theorem, 69, 80SumIL theorem, 69SumIL2 theorem, 71surj constant, 21, 22surj_def theorem, 21surjective_pairing theorem, 24surjective_sum theorem, 26swap theorem, 13swap_res_tac, 43sym theorem, 12sym_elem theorem, 67sym_type theorem, 67symL theorem, 49symR theorem, 49

T constant, 64t type, 63take constant, 30takeWhile constant, 30TC theorem, 70TE theorem, 70TEL theorem, 70term class, 5, 44test_assume_tac, 73TF theorem, 70THE symbol, 45The constant, 45The theorem, 48the_equality theorem, 49thinL theorem, 49thinLS theorem, 47thinR theorem, 49thinRS theorem, 47TI theorem, 70times class, 5tl constant, 30tracing

INDEX 96

of unification, 8trans theorem, 12trans_elem theorem, 67trans_red theorem, 67trans_type theorem, 67transR theorem, 49True constant, 6, 45True_def theorem, 11, 48True_or_False theorem, 10TrueI theorem, 12Trueprop constant, 6, 45TrueR theorem, 49tt constant, 64Type constant, 64typechk_tac, 73, 78, 81, 86

UN symbol, 15–17Un symbol, 15Un1 theorem, 20Un2 theorem, 20Un_absorb theorem, 21Un_assoc theorem, 21Un_commute theorem, 21Un_def theorem, 17UN_E theorem, 19UN_I theorem, 19Un_Int_distrib theorem, 21Un_Inter theorem, 21Un_least theorem, 20Un_upper1 theorem, 20Un_upper2 theorem, 20UnCI theorem, 19, 20UnE theorem, 19UnI1 theorem, 19UnI2 theorem, 19unification

incompleteness of, 8Unify.trace_types, 8UNION constant, 15Union constant, 15UNION1 constant, 15

UNION1_def theorem, 17UNION_def theorem, 17Union_def theorem, 17Union_least theorem, 20Union_Un_distrib theorem, 21Union_upper theorem, 20UnionE theorem, 19UnionI theorem, 19unit_eq theorem, 25

when constant, 64, 71, 79

zero_ne_succ theorem, 68, 69

isabelle’s logics

Documents