interactive theorem proving (itp) course - hol · interactive theorem proving (itp) course web...

Interactive Theorem Proving (ITP) CourseWeb Version

Thomas Tuerk ([email protected])

version 3a4d050 of Thu May 17 14:03:02 2018

Contents

Part I Preface 3Part II Introduction 6Part III HOL 4 History and Architecture 16Part IV HOL’s Logic 24Part V Basic HOL Usage 38Part VI Forward Proofs 46Part VII Backward Proofs 61Part VIII Basic Tactics 83Part IX Induction Proofs 110Part X Basic Definitions 119Part XI Good Definitions 163Part XII Deep and Shallow Embeddings 184Part XIII Rewriting 192Part XIV Advanced Definition Principles 246Part XV Maintainable Proofs 267Part XVI Overview of HOL 4 289Part XVII Other Interactive Theorem Provers 302

2 / 315

Part I

Preface

Preface

these slides originate from a course for advanced master students

it was given by the PROSPER group at KTH in Stockholm in 2017(see https://www.kth.se/social/group/interactive-theorem-)

the course focused on how to use HOL 4

students taking the course were expected toI know functional programming, esp. SMLI understand predicate logicI have some experience with pen and paper proofs

the course consisted of 9 lectures, which each took 90 minutes

there were 19 supervised practical sessions, which each took 2 h

usually there was 1 lecture and 2 practical sessions each week

students were expected to work about 10 h each week on exercises

4 / 315

https://www.kth.se/social/group/interactive-theorem-

Preface II

usually, these slides present concepts and some high-level entry points

often some more details were explained than covered on the slides

technical details were covered in the practical sessions

they are provided as they are in the hope that they are useful1 (thereare no guarentees of correctness :-))

the exercise question-sheets are available as well

if you have questions, feel free to contact Thomas Tuerk([email protected])

1if you find errors, please contact Thomas Tuerk5 / 315

Part II

Introduction

Motivation

Complex systems almost certainly contain bugs.

Critical systems (e. g. avionics) need to meet very high standards.

It is infeasible in practice to achieve such high standards just bytesting.

Debugging via testing suffers from diminishing returns.

“Program testing can be used to show the presenceof bugs, but never to show their absence!”

— Edsger W. Dijkstra

7 / 315

Famous Bugs

Pentium FDIV bug (1994)(missing entry in lookup table, $475 million damage)

Ariane V explosion (1996)(integer overflow, $1 billion prototype destroyed)

Mars Climate Orbiter (1999)(destroyed in Mars orbit, mixup of units pound-force and newtons)

Knight Capital Group Error in Ultra Short Time Trading (2012)(faulty deployment, repurposing of critical flag, $440 lost in 45 minon stock exchange)

. . .

Fun to read

http://www.cs.tau.ac.il/~nachumd/verify/horror.html

https://en.wikipedia.org/wiki/List_of_software_bugs

8 / 315

http://www.cs.tau.ac.il/~nachumd/verify/horror.html

https://en.wikipedia.org/wiki/List_of_software_bugs

Proof

proof can show absence of errors in design

but proofs talk about a design, not a real system

⇒ testing and proving complement each other

“As far as the laws of mathematicsrefer to reality, they are not certain;

and as far as they are certain,they do not refer to reality.”

— Albert Einstein

9 / 315

Mathematical vs. Formal Proof

Mathematical Proof

informal, convince othermathematicians

checked by community ofdomain experts

subtle errors are hard to find

often provide some newinsight about our world

often short, but requirecreativity and a brilliant idea

Formal Proof

formal, rigorously use alogical formalism

checkable by stupidmachines

very reliable

often contain no new ideasand no amazing insights

often long, very tedious, butlargely trivial

We are interested in formal proofs in this lecture.

10 / 315

Automated vs Manual (Formal) Proof

Fully Manual Proof

very tedious; one has to grind through many trivial but detailed proofs

easy to make mistakes

hard to keep track of all assumptions and preconditions

hard to maintain, if something changes (see Ariane V)

Automated Proof

amazing success in certain areas

but still often infeasible for interesting problems

hard to get insights in case a proof attempt fails

even if it works, it is often not that automatedI run automated tool for a few daysI abort, change command line arguments to use different heuristicsI run again and iterate till you find a set of heuristics that prove it fully

automatically in a few seconds

11 / 315

Interactive Proofs

combine strengths of manual and automated proofs

many different options to combine automated and manual proofsI mainly check existing proofs (e. g. HOL Zero)I user mainly provides lemmata statements, computer searches proofs

using previous lemmata and very few hints (e. g. ACL 2)I most systems are somewhere in the middle

typically the human userI provides insights into the problemI structures the proofI provides main arguments

typically the computerI checks proofI keeps track of all used assumptionsI provides automation to grind through lengthy, but trivial proofs

12 / 315

Typical Interactive Proof Activities

provide precise definitions of concepts

state properties of these conceptsprove these properties

I human provides insight and structureI computer does book-keeping and automates simple proofs

build and use libraries of formal definitions and proofsI formalisations of mathematical theories like

F lists, sets, bags, . . .F real numbersF probability theory

I specifications of real-world artefacts likeF processorsF programming languagesF network protocols

I reasoning tools

There is a strong connection with programming.Lessons learned in Software Engineering apply.

13 / 315

Different Interactive Provers

there are many different interactive provers, e. g.I Isabelle/HOLI CoqI PVSI HOL family of proversI ACL2I . . .

important differencesI the formalism usedI level of trustworthinessI level of automationI librariesI languages for writing proofsI user interfaceI . . .

14 / 315

Which theorem prover is the best one? :-)

there is no best theorem prover

better question: Which is the best one for a certain purpose?

important points to considerI existing librariesI used logicI level of automationI user interfaceI importance development speed versus trustworthinessI How familiar are you with the different provers?I Which prover do people in your vicinity use?I your personal preferencesI . . .

In this course we use the HOL theorem prover,because it is used by the TCS group.

15 / 315

Part III

HOL 4 History and Architecture

LCF - Logic of Computable Functions

Standford LCF 1971-72 by Milner et al.

formalism devised by Dana Scott in 1969

intended to reason about recursively definedfunctions

intended for computer science applications

strengthsI powerful simplification mechanismI support for backward proof

limitationsI proofs need a lot of memoryI fixed, hard-coded set of proof commands

Robin Milner(1934 - 2010)

17 / 315

LCF - Logic of Computable Functions II

Milner worked on improving LCF in Edinburgh

research assistantsI Lockwood MorrisI Malcolm NeweyI Chris WadsworthI Mike Gordon

Edinburgh LCF 1979

introduction of Meta Language (ML)

ML was invented to write proof procedures

ML became an influential functional programming language

using ML allowed implementing the LCF approach

18 / 315

LCF Approach

implement an abstract datatype thm to represent theorems

semantics of ML ensure that values of type thm can only be createdusing its interface

interface is very smallI predefined theorems are axiomsI function with result type theorem are inferences

interface is carefully designed and checkedI size of interface and implementation allow careful checkingI one checks that the interface really implements only axioms and

inferences that are valid in the used logic

However you create a theorem, there is a proof for it.

together with similar abstract datatypes for types and terms, thisforms the kernel

19 / 315

LCF Approach II

Modus Ponens Example

Inference Rule

Γ ` a⇒ b ∆ ` a

Γ ∪∆ ` b

SML function

val MP : thm -> thm -> thm

MP(Γ ` a⇒ b)(∆ ` a) = (Γ∪∆ ` b)

very trustworthy — only the small kernel needs to be trusted

efficient — no need to store proofs

Easy to extend and automate

However complicated and potentially buggy your code is, if a value of typetheorem is produced, it has been created through the small trustedinterface. Therefore the statement really holds.

20 / 315

LCF Style Systems

There are now many interactive theorem provers out there that use anapproach similar to that of Edinburgh LCF.

HOL familyI HOL theorem proverI HOL LightI HOL ZeroI Proof PowerI . . .

Isabelle

Nuprl

Coq

. . .

21 / 315

History of HOL

1979 Edinburgh LCF by Milner, Gordon, et al.

1981 Mike Gordon becomes lecturer in Cambridge

1985 Cambridge LCFI Larry Paulson and Gerard HuetI implementation of ML compilerI powerful simplifierI various improvements and extensions

1988 HOLI Mike Gordon and Keith HannaI adaption of Cambridge LCF to classical higher order logicI intention: hardware verification

1990 HOL90reimplementation in SML by Konrad Slind at University of Calgary

1998 HOL98implementation in Moscow ML and new library and theory mechanism

since then HOL Kananaskis releases, called informally HOL 4

22 / 315

Family of HOL

ProofPowercommercial version of HOL88 by RogerJones, Rob Arthan et al.

HOL Lightlean CAML / OCaml port by John Harrison

HOL Zerotrustworthy proof checker by Mark Adams

IsabelleI 1990 by Larry PaulsonI meta-theorem prover that supports

multiple logicsI however, mainly HOL used, ZF a littleI nowadays probably the most widely used

HOL systemI originally designed for software verification

Edinburgh LCF

Cambridge LCF

HOL88

hol90

ProofPower

Isabelle/HOL

HOL Light

hol98 HOL Zero

HOL4

23 / 315

Part IV

HOL’s Logic

HOL Logic

the HOL theorem prover uses a version of classical higher order logic:classical higher order predicate calculus withterms from the typed lambda calculus (i. e. simple type theory)

this sounds complicated, but is intuitive for SML programmers

(S)ML and HOL logic designed to fit each other

if you understand SML, you understand HOL logic

HOL = functional programming + logic

Ambiguity Warning

The acronym HOL refers to both the HOL interactive theorem prover andthe HOL logic used by it. It’s also a common abbreviation for higher orderlogic in general.

25 / 315

Types

SML datatype for typesI Type Variables (’a, α, ’b, β, . . .)

Type variables are implicitly universally quantified. Theoremscontaining type variables hold for all instantiations of these. Proofsusing type variables can be seen as proof schemata.

I Atomic Types (c)Atomic types denote fixed types. Examples: num, bool, unit

I Compound Types ((σ1, . . . , σn)op)op is a type operator of arity n and σ1, . . . , σn argument types. Typeoperators denote operations for constructing types.Examples: num list or ’a # ’b.

I Function Types (σ1 → σ2)σ1 → σ2 is the type of total functions from σ1 to σ2.

types are never empty in HOL, i. e.for each type at least one value exists

all HOL functions are total

26 / 315

Terms

SML datatype for termsI Variables (x, y, . . .)I Constants (c, . . .)I Function Application (f a)I Lambda Abstraction (\x. f x or λx . fx)

Lambda abstraction represents anonymous function definition.The corresponding SML syntax is fn x => f x.

terms have to be well-typed

same typing rules and same type-inference as in SML take place

terms very similar to SML expressions

notice: predicates are functions with return type bool, i. e. nodistinction between functions and predicates, terms and formulae

27 / 315

Terms II

HOL term SML expression type HOL / SML0 0 num / int

x:’a x:’a variable of type ’a

x:bool x:bool variable of type bool

x + 5 x + 5 applying function + to x and 5

\x. x + 5 fn x => x + 5 anonymous (a. k. a. inline) functionof type num -> num

(5, T) (5, true) num # bool / int * bool

[5;3;2]++[6] [5,3,2]@[6] num list / int list

28 / 315

Free and Bound Variables / Alpha Equivalence

in SML, the names of function arguments does not matter (much)

similarly in HOL, the names of variables used by lambda-abstractionsdoes not matter (much)

the lambda-expression λx . t is said to bind the variables x in term t

variables that are guarded by a lambda expression are called bound

all other variables are free

Example: x is free and y is bound in (x = 5) ∧ (λy . (y < x)) 3

the names of bound variables are unimportant semantically

two terms are called alpha-equivalent iff they differ only in thenames of bound variables

Example: λx . x and λy . y are alpha-equivalent

Example: x and y are not alpha-equivalent

29 / 315

Theorems

theorems are of the form Γ ` p whereI Γ is a set of hypothesisI p is the conclusion of the theoremI all elements of Γ and p are formulae, i. e. terms of type bool

Γ ` p records that using Γ the statement p has been proved

notice difference to logic: there it means can be proved

the proof itself is not recorded

theorems can only be created through a small interface in the kernel

30 / 315

HOL Light Kernel

the HOL kernel is hard to explainI for historic reasons some concepts are represented rather complicatedI for speed reasons some derivable concepts have been added

instead consider the HOL Light kernel, which is a cleaned-up version

there are two predefined constantsI = : ’a -> ’a -> boolI @ : (’a -> bool) -> ’a

there are two predefined typesI boolI ind

the meaning of these types and constants is given by inference rulesand axioms

31 / 315

HOL Light Inferences I

` t = tREFL

Γ ` s = t∆ ` t = u

Γ ∪∆ ` s = uTRANS

Γ ` s = t∆ ` u = v

types fit

Γ ∪∆ ` s(u) = t(v)COMB

Γ ` s = tx not free in Γ

Γ ` λx . s = λx . tABS

` (λx . t)x = tBETA

{p} ` pASSUME

32 / 315

HOL Light Inferences II

Γ ` p ⇔ q ∆ ` p

Γ ∪∆ ` qEQ MP

Γ ` p ∆ ` q

(Γ− {q}) ∪ (∆− {p}) ` p ⇔ qDEDUCT ANTISYM RULE

Γ[x1, . . . , xn] ` p[x1, . . . , xn]

Γ[t1, . . . , tn] ` p[t1, . . . , tn]INST

Γ[α1, . . . , αn] ` p[α1, . . . , αn]

Γ[γ1, . . . , γn] ` p[γ1, . . . , γn]INST TYPE

33 / 315

HOL Light Axioms and Definition Principles

3 axioms needed

ETA AX | − (λx . t x) = tSELECT AX | − P x =⇒ P((@)P))INFINITY AX predefined type ind is infinite

definition principle for constantsI constants can be introduced as abbreviationsI constraint: no free vars and no new type vars

definition principle for typesI new types can be defined as non-empty subtypes of existing types

both principlesI lead to conservative extensionsI preserve consistency

34 / 315

HOL Light derived concepts

Everything else is derived from this small kernel.

T =def (λp. p) = (λp. p)∧ =def λp q. (λf . f p q) = (λf . f T T )

=⇒ =def λp q. (p ∧ q ⇔ p)∀ =def λP. (P = λx . T )∃ =def λP. (∀q. (∀x . P(x) =⇒ q) =⇒ q). . .

35 / 315

Multiple Kernels

Kernel defines abstract datatypes for types, terms and theorems

one does not need to look at the internal implementation

therefore, easy to exchange

there are at least 3 different kernels for HOLI standard kernel (de Bruijn indices)I experimental kernel (name / type pairs)I OpenTheory kernel (for proof recording)

36 / 315

HOL Logic Summary

HOL theorem prover uses classical higher order logic

HOL logic is very similar to SMLI syntaxI type systemI type inference

HOL theorem prover very trustworthy because of LCF approachI there is a small kernelI proofs are not stored explicitly

you don’t need to know the details of the kernel

usually one works at a much higher level of abstraction

37 / 315

Part V

Basic HOL Usage

HOL Technical Usage Issues

practical issues are discussed in practical sessionsI how to install HOLI which key-combinations to use in emacs-modeI detailed signature of libraries and theoriesI all parameters and options of certain toolsI . . .

exercise sheets sometimesI ask to read some documentationI provide examplesI list references where to get additional information

if you have problems, ask me outside lecture ([email protected])

covered only very briefly in lectures

39 / 315

mailto:[email protected]

Installing HOL

webpage: https://hol-theorem-prover.org

HOL supports two SML implementationsI Moscow ML (http://mosml.org)I PolyML (http://www.polyml.org)

I recommend using PolyML

please use emacs withI hol-modeI sml-modeI hol-unicode, if you want to type Unicode

please install recent revision from git repo or Kananaskis 11 release

documentation found on HOL webpage and with sources

40 / 315

https://hol-theorem-prover.org

http://mosml.org

http://www.polyml.org

General Architecture

HOL is a collection of SML modules

starting HOL starts a SML Read-Eval-Print-Loop (REPL) withI some HOL modules loadedI some default modules openedI an input wrapper to help parsing terms called unquote

unquote provides special quotes for terms and typesI implemented as input filterI ‘‘my-term‘‘ becomes Parse.Term [QUOTE "my-term"]I ‘‘:my-type‘‘ becomes Parse.Type [QUOTE ":my-type"]

main interfacesI emacs (used in the course)I vimI bare shell

41 / 315

Filenames

*Script.sml — HOL proof script fileI script files contain definitions and proof scriptsI executing them results in HOL searching and checking proofsI this might take very longI resulting theorems are stored in *Theory.{sml|sig} files

*Theory.{sml|sig} — HOL theory

I auto-generated by corresponding script fileI load quickly, because they don’t search/check proofsI do not edit theory files

*Syntax.{sml|sig} — syntax libraries

I contain syntax related functionsI i. e. functions to construct and destruct terms and types

*Lib.{sml|sig} — general libraries

*Simps.{sml|sig} — simplifications

selftest.sml — selftest for current directory

42 / 315

Directory Structure

bin — HOL binaries

src — HOL sources

examples — HOL examplesI interesting projects by various peopleI examples owned by their developerI coding style and level of maintenance differ a lot

help — sources for reference manualI after compilation home of reference HTML page

Manual — HOL manualsI TutorialI DescriptionI Reference (PDF version)I InteractionI Quick (cheat pages)I Style-guideI . . .

43 / 315

Unicode

HOL supports both Unicode and pure ASCII input and output

advantages of Unicode compared to ASCIII easier to read (good fonts provided)I no need to learn special ASCII syntax

disadvanges of Unicode compared to ASCIII harder to type (even with hol-unicode.el)I less portable between systems

whether you like Unicode is highly a matter of personal taste

HOL’s policyI no Unicode in HOL’s source directory srcI Unicode in examples directory examples is fine

I recommend turning Unicode output off initiallyI this simplifies learning the ASCII syntaxI no need for special fontsI it is easier to copy and paste terms from HOL’s output

44 / 315

Where to find help?

reference manualI available as HTML pages, single PDF file and in-system help

description manual

Style-guide (still under development)

HOL webpage (https://hol-theorem-prover.org)

mailing-list hol-info

DB.match and DB.find

*Theory.sig and selftest.sml files

ask someone, e. g. me :-) ([email protected])

45 / 315


mailto:[email protected]

Part VI

Forward Proofs

Kernel too detailed

we already discussed the HOL Logic

the kernel itself does not even contain basic logic operators

usually one uses a much higher level of abstractionI many operations and datatypes are definedI high-level derived inference rules are used

let’s now look at this more common abstraction level

47 / 315

Common Terms and TypesUnicode ASCII

type vars α, β, . . . ’a, ’b, . . .type annotated term term:type term:type

true T T

false F F

negation ¬b ~bconjunction b1 ∧ b2 b1 /\ b2

disjunction b1 ∨ b2 b1 \/ b2

implication b1 =⇒ b2 b1 ==> b2

equivalence b1 ⇐⇒ b2 b1 <=> b2

disequation v1 6= v2 v1 <> v2

all-quantification ∀x. P x !x. P x

existential quantification ∃x. P x ?x. P x

Hilbert’s choice operator @x. P x @x. P x

There are similar restrictions to constant and variable names as in SML.HOL specific: don’t start variable names with an underscore

48 / 315

Syntax conventions

common function syntaxI prefix notation, e. g. SUC xI infix notation, e. g. x + yI quantifier notation, e. g. ∀x. P x means (∀) (λx. P x)

infix and quantifier notation can be turned into prefix notationExample: (+) x y and $+ x y are the same as x + y

quantifiers of the same type don’t need to be repeatedExample: ∀x y. P x y is short for ∀x. ∀y. P x y

there is special syntax for some functionsExample: if c then v1 else v2 is nice syntax for COND c v1 v2

associative infix operators are usually right-associativeExample: b1 /\ b2 /\ b3 is parsed as b1 /\ (b2 /\ b3)

49 / 315

Creating Terms

Term Parser

Use special quotation provided by unquote.

Operator Precedence

It is easy to misjudge the binding strength of certain operators. Thereforeuse plenty of parenthesis.

Use Syntax Functions

Terms are just SML values of type term. You can use syntax functions(usually defined in *Syntax.sml files) to create them.

50 / 315

Creating Terms II

Parser Syntax Funs‘‘:bool‘‘ mk type ("bool", []) or bool type of Booleans‘‘T‘‘ mk const ("T", bool) or T term true‘‘~b‘‘ mk neg ( negation of

mk var ("b", bool)) Boolean var b‘‘... /\ ...‘‘ mk conj (..., ...) conjunction‘‘... \/ ...‘‘ mk disj (..., ...) disjunction‘‘... ==> ...‘‘ mk imp (..., ...) implication‘‘... = ...‘‘ mk eq (..., ...) equation‘‘... <=> ...‘‘ mk eq (..., ...) equivalence‘‘... <> ...‘‘ mk neg (mk eq (..., ...)) negated equation

51 / 315

Inference Rules for Equality

` t = tREFL


Γ ` λx . s = λx .tABS

Γ ` s = t∆ ` u = v

types fit

Γ ∪∆ ` s(u) = t(v)MK COMB

Γ ` s = t

Γ ` t = sGSYM

Γ ` s = t∆ ` t = u


Γ ` p ⇔ q ∆ ` p

Γ ∪∆ ` qEQ MP

` (λx . t)x = tBETA

52 / 315

Inference Rules for free Variables

Γ[x1, . . . , xn] ` p[x1, . . . , xn]

Γ[t1, . . . , tn] ` p[t1, . . . , tn]INST

Γ[α1, . . . , αn] ` p[α1, . . . , αn]

Γ[γ1, . . . , γn] ` p[γ1, . . . , γn]INST TYPE

53 / 315

Inference Rules for Implication

Γ ` p =⇒ q∆ ` p

Γ ∪∆ ` qMP, MATCH MP

Γ ` p = q

Γ ` p =⇒ qΓ ` q =⇒ p

EQ IMP RULE

Γ ` p =⇒ q∆ ` q =⇒ p

Γ ∪∆ ` p = qIMP ANTISYM RULE

Γ ` p =⇒ q∆ ` q =⇒ r

Γ ∪∆ ` p =⇒ rIMP TRANS

Γ ` p

Γ− {q} ` q =⇒ pDISCH

Γ ` q =⇒ p

Γ ∪ {q} ` pUNDISCH

Γ ` p =⇒ F

Γ ` ~pNOT INTRO

Γ ` ~pΓ ` p =⇒ F

NOT ELIM

54 / 315

Inference Rules for Conjunction / Disjunction

Γ ` p ∆ ` q

Γ ∪∆ ` p ∧ qCONJ

Γ ` p ∧ q

Γ ` pCONJUNCT1

Γ ` p ∧ q

Γ ` qCONJUNCT2

Γ ` p

Γ ` p ∨ qDISJ1

Γ ` q

Γ ` p ∨ qDISJ2

Γ ` p ∨ q∆1 ∪ {p} ` r∆2 ∪ {q} ` r

Γ ∪∆1 ∪∆2 ` rDISJ CASES

55 / 315

Inference Rules for Quantifiers

Γ ` p x not free in Γ

Γ ` ∀x . pGEN

Γ ` ∀x . pΓ ` p[u/x ]

SPEC

Γ ` p[u/x ]

Γ ` ∃x . pEXISTS

Γ ` ∃x . p∆ ∪ {p[u/x ]} ` r

u not free in Γ,∆, p and r

Γ ∪∆ ` rCHOOSE

56 / 315

Forward Proofs

axioms and inference rules are used to derive theorems

this method is called forward proofI one starts with basic building blocksI one moves step by step forwardI finally the theorem one is interested in is derived

one can also implement own proof tools

57 / 315

Forward Proofs — Example I

Let’s prove ∀p. p =⇒ p.

val IMP_REFL_THM = let

val tm1 = ‘‘p:bool‘‘;

val thm1 = ASSUME tm1;

val thm2 = DISCH tm1 thm1;

in

GEN tm1 thm2

end

fun IMP_REFL t =

SPEC t IMP_REFL_THM;

> val tm1 = ‘‘p‘‘: term

> val thm1 = [p] |- p: thm

> val thm2 = |- p ==> p: thm

> val IMP_REFL_THM =

|- !p. p ==> p: thm

> val IMP_REFL =

fn: term -> thm

58 / 315

Forward Proofs — Example II

Let’s prove ∀P v . (∃x . (x = v) ∧ P x)⇐⇒ P v .

val tm_v = ‘‘v:’a‘‘;

val tm_P = ‘‘P:’a -> bool‘‘;

val tm_lhs = ‘‘?x. (x = v) /\ P x‘‘

val tm_rhs = mk_comb (tm_P, tm_v);

val thm1 = let

val thm1a = ASSUME tm_rhs;

val thm1b =

CONJ (REFL tm_v) thm1a;

val thm1c =

EXISTS (tm_lhs, tm_v) thm1b

in

DISCH tm_rhs thm1c

end

> val thm1a = [P v] |- P v: thm

> val thm1b =

[P v] |- (v = v) /\ P v: thm

> val thm1c =

[P v] |- ?x. (x = v) /\ P x

> val thm1 = [] |-

P v ==> ?x. (x = v) /\ P x: thm

59 / 315

Forward Proofs — Example II cont.

val thm2 = let

val thm2a =

ASSUME ‘‘(u:’a = v) /\ P u‘‘

val thm2b = AP_TERM tm_P

(CONJUNCT1 thm2a);

val thm2c = EQ_MP thm2b

(CONJUNCT2 thm2a);

val thm2d =

CHOOSE (‘‘u:’a‘‘,

ASSUME tm_lhs) thm2c

in

DISCH tm_lhs thm2d

end

val thm3 = IMP_ANTISYM_RULE thm2 thm1

val thm4 = GENL [tm_P, tm_v] thm3

> val thm2a = [(u = v) /\ P u] |-

(u = v) /\ P u: thm

> val thm2b = [(u = v) /\ P u] |-

P u <=> P v

> val thm2c = [(u = v) /\ P u] |-

P v

> val thm2d = [?x. (x = v) /\ P x] |-

P v

> val thm2 = [] |-

?x. (x = v) /\ P x ==> P v

> val thm3 = [] |-

?x. (x = v) /\ P x <=> P v

> val thm4 = [] |- !P v.

?x. (x = v) /\ P x <=> P v

60 / 315

Part VII

Backward Proofs

Motivation I

let’s prove !A B. A /\ B <=> B /\ A

(* Show |- A /\ B ==> B /\ A *)

val thm1a = ASSUME ‘‘A /\ B‘‘;

val thm1b = CONJ (CONJUNCT2 thm1a) (CONJUNCT1 thm1a);

val thm1 = DISCH ‘‘A /\ B‘‘ thm1b

(* Show |- B /\ A ==> A /\ B *)

val thm2a = ASSUME ‘‘B /\ A‘‘;

val thm2b = CONJ (CONJUNCT2 thm2a) (CONJUNCT1 thm2a);

val thm2 = DISCH ‘‘B /\ A‘‘ thm2b

(* Combine to get |- A /\ B <=> B /\ A *)

val thm3 = IMP_ANTISYM_RULE thm1 thm2

(* Add quantifiers *)

val thm4 = GENL [‘‘A:bool‘‘, ‘‘B:bool‘‘] thm3

this is how you write down a proof

for finding a proof it is however often useful to think backwards

62 / 315

Motivation II - thinking backwards

we want to proveI !A B. A /\ B <=> B /\ A

all-quantifiers can easily be added later, so let’s get rid of them

I A /\ B <=> B /\ A

now we have an equivalence, let’s show 2 implications

I A /\ B ==> B /\ AI B /\ A ==> A /\ B

we have an implication, so we can use the precondition as anassumption

I using A /\ B show B /\ AI A /\ B ==> B /\ A

63 / 315

Motivation III - thinking backwards

we have a conjunction as assumption, let’s split itI using A and B show B /\ AI A /\ B ==> B /\ A

we have to show a conjunction, so let’s show both partsI using A and B show BI using A and B show AI A /\ B ==> B /\ A

the first two proof obligations are trivialI A /\ B ==> B /\ A

. . .

we are done

64 / 315

Motivation IV

common practiseI think backwards to find proofI write found proof down in forward style

often switch between backward and forward style within a proofExample: induction proof

I backward step: induct on . . .I forward steps: prove base case and induction case

whether to use forward or backward proofs depend onI support by the interactive theorem prover you use

F HOL 4 and close family: emphasis on backward proofF Isabelle/HOL: emphasis on forward proofF Coq : emphasis on backward proof

I your way of thinkingI the theorem you try to prove

65 / 315

HOL Implementation of Backward Proofs

in HOLI proof tactics / backward proofs used for most user-level proofsI forward proofs used usually for writing automation

backward proofs are implemented by tactics in HOLI decomposition into subgoals implemented in SMLI SML datastructures used to keep track of all open subgoalsI forward proof used to construct theorems

to understand backward proofs in HOL we need to look atI goal — SML datatype for proof obligationsI goalStack — library for keeping track of goalsI tactic — SML type for functions performing backward proofs

66 / 315

Goals

goals represent proof obligations, i. e. theorems we need/want to prove

the SML type goal is an abbreviation for term list * term

the goal ([asm 1, ..., asm n], c) records that we need/want toprove the theorem {asm 1, ..., asm n} |- c

Example Goals

Goal Theorem([‘‘A‘‘, ‘‘B‘‘], ‘‘A /\ B‘‘) {A, B} |- A /\ B

([‘‘B‘‘, ‘‘A‘‘], ‘‘A /\ B‘‘) {A, B} |- A /\ B

([‘‘B /\ A‘‘], ‘‘A /\ B‘‘) {B /\ A} |- A /\ B

([], ‘‘(B /\ A) ==> (A /\ B)‘‘) |- (B /\ A) ==> (A /\ B)

67 / 315

Tactics

the SML type tactic is an abbreviation forthe type goal -> goal list * validation

validation is an abbreviation for thm list -> thm

given a goal, a tacticI decides into which subgoals to decompose the goalI returns this list of subgoalsI returns a validation that

F given a list of theorems for the computed subgoalsF produces a theorem for the original goal

special case: empty list of subgoalsI the validation (given []) needs to produce a theorem for the goal

notice: a tactic might be invalid

68 / 315

Tactic Example — CONJ TAC

Γ ` p ∆ ` q

Γ ∪∆ ` p ∧ qCONJ

t ≡ conj1 /\ conj2

asl ` conj1 asl ` conj2asl ` t

val CONJ_TAC: tactic = fn (asl, t) =>

let

val (conj1, conj2) = dest_conj t

in

([(asl, conj1), (asl, conj2)],

fn [th1, th2] => CONJ th1 th2 | _ => raise Match)

end

handle HOL_ERR _ => raise ERR "CONJ_TAC" ""

69 / 315

Tactic Example — EQ TAC

Γ ` p =⇒ q∆ ` q =⇒ p

Γ ∪∆ ` p = qIMP ANTISYM RULE

t ≡ lhs = rhs

asl ` lhs ==> rhs

asl ` rhs ==> lhs

asl ` t

val EQ_TAC: tactic = fn (asl, t) =>

let

val (lhs, rhs) = dest_eq t

in

([(asl, mk_imp (lhs, rhs)), (asl, mk_imp (rhs, lhs))],

fn [th1, th2] => IMP_ANTISYM_RULE th1 th2

| _ => raise Match)

end

handle HOL_ERR _ => raise ERR "EQ_TAC" ""

70 / 315

proofManagerLib / goalStack

the proofManagerLib keeps track of open goals

it uses goalStack internally

important commandsI g — set up new goalI e — expand a tacticI p — print the current statusI top thm — get the proved thm at the end

71 / 315

Tactic Proof Example I

Previous Goalstack-

User Action

g ‘!A B. A /\ B <=> B /\ A‘;

New GoalstackInitial goal:

!A B. A /\ B <=> B /\ A

: proof

72 / 315

Tactic Proof Example II

Previous GoalstackInitial goal:

!A B. A /\ B <=> B /\ A

: proof

User Actione GEN_TAC;

e GEN_TAC;

New Goalstack

A /\ B <=> B /\ A

: proof

73 / 315

Tactic Proof Example III

Previous Goalstack

A /\ B <=> B /\ A

: proof

User Actione EQ_TAC;

New Goalstack

B /\ A ==> A /\ B

A /\ B ==> B /\ A

: proof

74 / 315

Tactic Proof Example IV

Previous Goalstack

B /\ A ==> A /\ B

A /\ B ==> B /\ A : proof

User Actione STRIP_TAC;

New Goalstack

B /\ A

------------------------------------

0. A

1. B

75 / 315

Tactic Proof Example V

Previous GoalstackB /\ A

------------------------------------

0. A

1. B

User Actione CONJ_TAC;

New GoalstackA

------------------------------------

0. A

1. B

B

------------------------------------

0. A

1. B

76 / 315

Tactic Proof Example VI

Previous GoalstackA

------------------------------------

0. A

1. B

B

------------------------------------

0. A

1. B

User Actione (ACCEPT_TAC (ASSUME ‘‘B:bool‘‘));

e (ACCEPT_TAC (ASSUME ‘‘A:bool‘‘));

New GoalstackB /\ A ==> A /\ B

: proof

77 / 315

Tactic Proof Example VII

Previous GoalstackB /\ A ==> A /\ B

: proof

User Actione STRIP_TAC;

e (ASM_REWRITE_TAC[]);

New GoalstackInitial goal proved.

|- !A B. A /\ B <=> B /\ A:

proof

78 / 315

Tactic Proof Example VIII

Previous GoalstackInitial goal proved.

|- !A B. A /\ B <=> B /\ A:

proof

User Actionval thm = top_thm();

Resultval thm =

|- !A B. A /\ B <=> B /\ A:

thm

79 / 315

Tactic Proof Example IX

Combined Tacticval thm = prove (‘‘!A B. A /\ B <=> B /\ A‘‘,

GEN_TAC >> GEN_TAC >>

EQ_TAC >| [

STRIP_TAC >>

STRIP_TAC >| [

ACCEPT_TAC (ASSUME ‘‘B:bool‘‘),

ACCEPT_TAC (ASSUME ‘‘A:bool‘‘)

],

STRIP_TAC >>

ASM_REWRITE_TAC[]

]);

Resultval thm =

|- !A B. A /\ B <=> B /\ A:

thm

80 / 315

Tactic Proof Example X

Cleaned-up Tacticval thm = prove (‘‘!A B. A /\ B <=> B /\ A‘‘,

REPEAT GEN_TAC >>

EQ_TAC >> (

REPEAT STRIP_TAC >>

ASM_REWRITE_TAC []

));

Resultval thm =

|- !A B. A /\ B <=> B /\ A:

thm

81 / 315

Summary Backward Proofs

in HOL most user-level proofs are tactic-basedI automation often written in forward styleI low-level, basic proofs written in forward styleI nearly everything else is written in backward (tactic) style

there are many different tactics

in the lecture only the most basic ones will be discussed

you need to learn about tactics on your ownI good starting point: Quick manualI learning finer points takes a lot of timeI exercises require you to read up on tactics

often there are many ways to prove a statement, which tactics to usedepends on

I personal way of thinkingI personal style and preferencesI maintainability, clarity, elegance, robustnessI . . .

82 / 315

Part VIII

Basic Tactics

Syntax of Tactics in HOL

originally tactics were written all in capital letters with underscoresExample: ALL TAC

since 2010 more and more tactics have overloaded lower-case syntaxExample: all tac

sometimes, the lower-case version is shortenedExample: REPEAT, rpt

sometimes, there is special syntaxExample: THEN, \\, >>

which one to use is mostly a matter of personal tasteI all-capital names are hard to read and typeI however, not for all tactics there are lower-case versionsI mixed lower- and upper-case tactics are even harder to readI often shortened lower-case name is not speaking

In the lecture we will use mostly the old-style names.

84 / 315

Some Basic Tactics

GEN TAC remove outermost all-quantifierDISCH TAC move antecedent of goal into assumptionsCONJ TAC splits conjunctive goalSTRIP TAC splits on outermost connective (combination

of GEN TAC, CONJ TAC, DISCH TAC, . . . )DISJ1 TAC selects left disjunctDISJ2 TAC selects right disjunctEQ TAC reduce Boolean equality to implicationsASSUME TAC thm add theorem to list of assumptionsEXISTS TAC term provide witness for existential goal

85 / 315

Tacticals

tacticals are SML functions that combine tactics to form new tactics

common workflowI develop large tactic interactivelyI using goalStack and editor support to execute tactics one by oneI combine tactics manually with tacticals to create larger tacticsI finally end up with one large tactic that solves your goalI use prove or store thm instead of goalStack

make sure to clearly mark proof structure by e. g.I use indentationI use parenthesesI use appropriate connectivesI . . .

goalStack commands like e or g should not appear in your final proof

86 / 315

Some Basic Tacticals

tac1 >> tac2 THEN, \\ applies tactics in sequencetac >| tacL THENL applies list of tactics to subgoalstac1 >- tac2 THEN1 applies tac2 to the first subgoal of tac1REPEAT tac rpt repeats tac until it failsNTAC n tac apply tac n timesREVERSE tac reverse reverses the order of subgoalstac1 ORELSE tac2 applies tac1 only if tac2 failsTRY tac do nothing if tac failsALL TAC all tac do nothingNO TAC fail

87 / 315

Basic Rewrite Tactics

(equational) rewriting is at the core of HOL’s automation

we will discuss it in detail later

details complex, but basic usage is straightforwardI given a theorem rewr thm of form |- P x = Q x and a term tI rewriting t with rewr thm meansI replacing each occurrence of a term P c for some c with Q c in t

warning: rewriting may loopExample: rewriting with theorem |- X <=> (X /\ T)

REWRITE TAC thms rewrite goal using equations foundin given list of theorems

ASM REWRITE TAC thms in addition use assumptionsONCE REWRITE TAC thms rewrite once in goal using equationsONCE ASM REWRITE TAC thms rewrite once using assumptions

88 / 315

Case-Split and Induction Tactics

Induct on ‘term‘ induct on term

Induct induct on all-quantifierCases on ‘term‘ case-split on term

Cases case-split on all-quantifierMATCH MP TAC thm apply ruleIRULE TAC thm generalised apply rule

89 / 315

Assumption Tactics

POP ASSUM thm-tac use and remove first assumptioncommon usage POP ASSUM MP TAC

PAT ASSUM term thm-tac use (and remove) firstalso PAT X ASSUM term thm-tac assumption matching pattern

WEAKEN TAC term-pred removes first assumptionsatisfying predicate

90 / 315

Decision Procedure Tactics

decision procedures try to solve the current goal completely

they either succeed or fail

no partial progress

decision procedures vital for automation

TAUT TAC propositional logic tautology checkerDECIDE TAC linear arithmetic for numMETIS TAC thms first order provernumLib.ARITH TAC Presburger arithmeticintLib.ARITH TAC uses Omega test

91 / 315

Subgoal Tactics

it is vital to structure your proofs wellI improved maintainabilityI improved readabilityI improved reusabilityI saves time in medium-run

therefore, use many small lemmata

also, use many explicit subgoals

‘term-frag‘ by tac show term with tac andadd it to assumptions

‘term-frag‘ suffices by tac show it suffices to prove term

92 / 315

Term Fragments / Term Quotations

notice that by and suffices by take term fragments

term fragments are also called term quotations

they represent (partially) unparsed terms

parsing takes place during execution of tactic in context of goal

this helps to avoid type annotations

however, this means syntax errors show late as well

the library Q defines many tactics using term fragments

93 / 315

Importance of Exercises

here many tactics are presented in a very short amount of time

there are many, many more important tactics out there

few people can learn a programming language just by reading manuals

similar few people can learn HOL just by reading and listening

you should write your own proofs and play around with these tactics

solving the exercises is highly recommended(and actually required if you want credits for this course)

94 / 315

Tactical Proof - Example I - Slide 1

we want to prove !l. LENGTH (APPEND l l) = 2 * LENGTH l

first step: set up goal on goalStack

at same time start writing proof script

Proof Script

val LENGTH_APPEND_SAME = prove (

‘‘!l. LENGTH (APPEND l l) = 2 * LENGTH l‘‘,

Actions

run g ‘‘!l. LENGTH (APPEND l l) = 2 * LENGTH l‘‘

this is done by hol-mode

move cursor inside term and press M-h g

(menu-entry HOL - Goalstack - New goal)

95 / 315


Current Goal!l. LENGTH (l ++ l) = 2 * LENGTH l

the outermost connective is an all-quantifier

let’s get rid of it via GEN TAC

Proof Script


‘‘!l. LENGTH (l ++ l) = 2 * LENGTH l‘‘,

GEN_TAC

Actionsrun e GEN TAC

this is done by hol-mode

mark line with GEN TAC and press M-h e

(menu-entry HOL - Goalstack - Apply tactic)

96 / 315


Current GoalLENGTH (l ++ l) = 2 * LENGTH l

LENGTH of APPEND can be simplified

let’s search an appropriate lemma with DB.match

Actions

run DB.print match [] ‘‘LENGTH ( ++ )‘‘

this is done via hol-mode

press M-h m and enter term pattern(menu-entry HOL - Misc - DB match)

this finds the theorem listTheory.LENGTH APPEND

|- !l1 l2. LENGTH (l1 ++ l2) = LENGTH l1 + LENGTH l2

97 / 315



let’s rewrite with found theorem listTheory.LENGTH APPEND

Proof Script



GEN_TAC >>

REWRITE_TAC[listTheory.LENGTH APPEND]

Actions

connect the new tactic with tactical >> (THEN)

use hol-mode to expand the new tactic

98 / 315


Current GoalLENGTH l + LENGTH l = 2 * LENGTH l

let’s search a theorem for simplifying 2 * LENGTH l

prepare for extending the previous rewrite tactic

Proof Script



GEN_TAC >>

REWRITE_TAC[listTheory.LENGTH APPEND]

Actions

DB.match finds theorem arithmeticTheory.TIMES2

press M-h b and undo last tactic expansion(menu-entry HOL - Goalstack - Back up)

99 / 315



extend the previous rewrite tactic

finish proof

Proof Script



GEN_TAC >>

REWRITE_TAC[listTheory.LENGTH APPEND, arithmeticTheory.TIMES2]);

Actions

add TIMES2 to the list of theorems used by rewrite tactic

use hol-mode to expand the extended rewrite tactic

goal is solved, so let’s add closing parenthesis and semicolon

100 / 315


we have a finished tactic proving our goal

notice that GEN TAC is not needed

let’s polish the proof script

Proof Script



GEN_TAC >>


Polished Proof Script




101 / 315

Tactical Proof - Example II - Slide 1

let’s prove something slightly more complicated

drop old goal by pressing M-h d

(menu-entry HOL - Goalstack - Drop goal)

set up goal on goalStack (M-h g)

at same time start writing proof script

Proof Script

val NOT_ALL_DISTINCT_LEMMA = prove (‘‘!x1 x2 x3 l1 l2 l3.

(MEM x1 l1 /\ MEM x2 l2 /\ MEM x3 l3) /\

((x1 <= x2) /\ (x2 <= x3) /\ x3 <= SUC x1) ==>

~(ALL_DISTINCT (l1 ++ l2 ++ l3))‘‘,

102 / 315


Current Goal!x1 x2 x3 l1 l2 l3.


x1 <= x2 /\ x2 <= x3 /\ x3 <= SUC x1 ==>

~ALL_DISTINCT (l1 ++ l2 ++ l3)

let’s strip the goal

Proof Script

val NOT_ALL_DISTINCT_LEMMA = prove (‘‘!x1 x2 x3 l1 l2 l3.


((x1 <= x2) /\ (x2 <= x3) /\ x3 <= SUC x1) ==>


REPEAT STRIP TAC

103 / 315


Current Goal!x1 x2 x3 l1 l2 l3.


x1 <= x2 /\ x2 <= x3 /\ x3 <= SUC x1 ==>

~ALL_DISTINCT (l1 ++ l2 ++ l3)

let’s strip the goal

Proof Script



REPEAT STRIP TAC

Actions

add REPEAT STRIP TAC to proof script

expand this tactic using hol-mode

104 / 315


Current GoalF

------------------------------------

0. MEM x1 l1 4. x2 <= x3

1. MEM x2 l2 5. x3 <= SUC x1

2. MEM x3 l3 6. ALL_DISTINCT (l1 ++ l2 ++ l3)

3. x1 <= x2

oops, we did too much, we would like to keep ALL DISTINCT in goal

Proof Script

val NOT_ALL_DISTINCT_LEMMA = prove (‘‘...‘‘,

REPEAT GEN TAC >> STRIP TAC

Actions

undo REPEAT STRIP TAC (M-h b)

expand more fine-tuned strip tactic

105 / 315


Current Goal~ALL_DISTINCT (l1 ++ l2 ++ l3)

------------------------------------

0. MEM x1 l1 3. x1 <= x2

1. MEM x2 l2 4. x2 <= x3

2. MEM x3 l3 5. x3 <= SUC x1

now let’s simplify ALL DISTINCT

search suitable theorems with DB.match

use them with rewrite tactic

Proof Script

val NOT_ALL_DISTINCT_LEMMA = prove (‘‘...‘‘,

REPEAT GEN TAC >> STRIP TAC >>

REWRITE TAC[listTheory.ALL_DISTINCT APPEND, listTheory.MEM APPEND]

106 / 315


Current Goal~((ALL_DISTINCT l1 /\ ALL_DISTINCT l2 /\ !e. MEM e l1 ==> ~MEM e l2) /\

ALL_DISTINCT l3 /\ !e. MEM e l1 \/ MEM e l2 ==> ~MEM e l3)

------------------------------------

0. MEM x1 l1 3. x1 <= x2

1. MEM x2 l2 4. x2 <= x3

2. MEM x3 l3 5. x3 <= SUC x1

from assumptions 3, 4 and 5 we know x2 = x1 \/ x2 = x3

let’s deduce this fact by DECIDE TAC

Proof Scriptval NOT_ALL_DISTINCT_LEMMA = prove (‘‘...‘‘,


REWRITE TAC[listTheory.ALL_DISTINCT APPEND, listTheory.MEM APPEND] >>

‘(x2 = x1) \/ (x2 = x3)‘ by DECIDE_TAC

107 / 315


Current Goals — 2 subgoals, one for each disjunct~((ALL_DISTINCT l1 /\ ALL_DISTINCT l2 /\ !e. MEM e l1 ==> ~MEM e l2) /\

ALL_DISTINCT l3 /\ !e. MEM e l1 \/ MEM e l2 ==> ~MEM e l3)

------------------------------------

0. MEM x1 l1 4. x2 <= x3

1. MEM x2 l2 5. x3 <= SUC x1

2. MEM x3 l3 6a. x2 = x1

3. x1 <= x2 6b. x2 = x3

both goals are easily solved by first-order reasoning

let’s use METIS TAC[] for both subgoals

Proof Scriptval NOT_ALL_DISTINCT_LEMMA = prove (‘‘...‘‘,



‘(x2 = x1) \/ (x2 = x3)‘ by DECIDE_TAC >> (

METIS TAC[]

));

108 / 315


Finished Proof Scriptval NOT_ALL_DISTINCT_LEMMA = prove (

‘‘!x1 x2 x3 l1 l2 l3.


((x1 <= x2) /\ (x2 <= x3) /\ x3 <= SUC x1) ==>




‘(x2 = x1) \/ (x2 = x3)‘ by DECIDE_TAC >> (

METIS TAC[]

));

notice that proof structure is explicit

parentheses and indentation used to mark new subgoals

109 / 315

Part IX

Induction Proofs

Mathematical Induction

mathematical (a. k. a. natural) induction principle:If a property P holds for 0 and P(n) implies P(n + 1) for all n,then P(n) holds for all n.

HOL is expressive enough to encode this principle as a theorem.

|- !P. P 0 /\ (!n. P n ==> P (SUC n)) ==> !n. P n

Performing mathematical induction in HOL means applying thistheorem (e. g. via HO MATCH MP TAC)

there are many similarish induction theorems in HOL

Example: complete induction principle

|- !P. (!n. (!m. m < n ==> P m) ==> P n) ==> !n. P n

111 / 315

Structural Induction Theorems

structural induction theorems are an important special form ofinduction theorems

they describe performing induction on the structure of a datatype

Example: |- !P. P [] /\ (!t. P t ==> !h. P (h::t)) ==> !l. P l

structural induction is used very frequently in HOL

for each algabraic datatype, there is an induction theorem

112 / 315

Other Induction Theorems

there are many induction theorems in HOLI datatype definitions lead to induction theoremsI recursive function definitions produce corresponding induction theoremsI recursive relation definitions give rise to induction theoremsI many are manually defined

Examples

|- !P. P [] /\ (!l. P l ==> !x. P (SNOC x l)) ==> !l. P l

|- !P. P FEMPTY /\

(!f. P f ==> !x y. x NOTIN FDOM f ==> P (f |+ (x,y))) ==> !f. P f

|- !P. P {} /\

(!s. FINITE s /\ P s ==> !e. e NOTIN s ==> P (e INSERT s)) ==>

!s. FINITE s ==> P s

|- !R P. (!x y. R x y ==> P x y) /\ (!x y z. P x y /\ P y z ==> P x z) ==>

!u v. R+ u v ==> P u v

113 / 315

Induction (and Case-Split) Tactics

the tactic Induct (or Induct on) is usually used to start inductionproofs

it looks at the type of the quantifier (or its argument) and applies thedefault induction theorem for this type

this is usually what one needs

other (non default) induction theorems can be applied viaINDUCT THEN or HO MATCH MP TAC

similarish Cases on picks and applies default case-split theorems

114 / 315

Induction Proof - Example I - Slide 1

let’s prove via induction!l1 l2. REVERSE (l1 ++ l2) = REVERSE l2 ++ REVERSE l1

we set up the goal and start an induction proof on l1

Proof Script

val REVERSE_APPEND = prove (

‘‘!l1 l2. REVERSE (l1 ++ l2) = REVERSE l2 ++ REVERSE l1‘‘,

Induct

115 / 315

Induction Proof - Example I - Slide 2

the induction tactic produced two cases

base case:!l2. REVERSE ([] ++ l2) = REVERSE l2 ++ REVERSE []

induction step:

!h l2. REVERSE (h::l1 ++ l2) = REVERSE l2 ++ REVERSE (h::l1)

-----------------------------------------------------------

!l2. REVERSE (l1 ++ l2) = REVERSE l2 ++ REVERSE l1

both goals can be easily proved by rewriting

Proof Scriptval REVERSE_APPEND = prove (‘‘

!l1 l2. REVERSE (l1 ++ l2) = REVERSE l2 ++ REVERSE l1‘‘,

Induct >| [

REWRITE_TAC[REVERSE_DEF, APPEND, APPEND_NIL],

ASM_REWRITE_TAC[REVERSE_DEF, APPEND, APPEND_ASSOC]

]);

116 / 315

Induction Proof - Example II - Slide 2

let’s prove via induction!l. REVERSE (REVERSE l) = l

we set up the goal and start an induction proof on l

Proof Script

val REVERSE_REVERSE = prove (

‘‘!l. REVERSE (REVERSE l) = l‘‘,

Induct

117 / 315

Induction Proof - Example II - Slide 2

the induction tactic produced two cases

base case:REVERSE (REVERSE []) = []

induction step:

!h. REVERSE (REVERSE (h::l1)) = h::l1

--------------------------------------------

REVERSE (REVERSE l) = l

again both goals can be easily proved by rewriting

Proof Scriptval REVERSE_REVERSE = prove (

‘‘!l. REVERSE (REVERSE l) = l‘‘,

Induct >| [

REWRITE_TAC[REVERSE_DEF],

ASM_REWRITE_TAC[REVERSE_DEF, REVERSE_APPEND, APPEND]

]);

118 / 315

Part X

Basic Definitions

Definitional Extensions

there are conservative definition principles for types and constants

conservative means that all theorems that can be proved in extendedtheory can also be proved in original one

however, such extensions make the theory more comfortable

definitions introduce no new inconsistencies

the HOL community has a very strong tradition of a purelydefinitional approach

120 / 315

Axiomatic Extensions

axioms are a different approach

they allow postulating arbitrary properties, i. e. extending the logicwith arbitrary theorems

this approach might introduce new inconsistencies

in HOL axioms are very rarely needed

using definitions is often considered more elegant

it is hard to keep track of axioms

use axioms only if you really know what you are doing

121 / 315

Oracles

oracles are families of axioms

however, they are used differently than axioms

they are used to enable usage of external tools and knowledge

you might want to use an external automated prover

this external tool acts as an oracleI it provides answersI it does not explain or justify these answers

you don’t know, whether this external tool might be buggy

all theorems proved via it are tagged with a special oracle-tag

tags are propagated

this allows keeping track of everything depending on the correctnessof this tool

122 / 315

Oracles II

Common oracle-tagsI DISK THM — theorem was written to disk and read againI HolSatLib — proved by MiniSatI HolSmtLib — proved by external SMT solverI fast proof — proof was skipped to compile a theory rapidlyI cheat — we cheated :-)

cheating via e. g. the cheat tactic means skipping proofs

it can be helpful during proof developmentI test whether some lemmata allow you finishing the proofI skip lengthy but boring cases and focus on critical parts firstI experiment with exact form of invariantsI . . .

cheats should be removed reasonable quickly

HOL warns about cheats and skipped proofs

123 / 315

Pitfalls of Definitional Approach

definitions can’t introduce new inconsistencies

they force you to state all assumed properties at one location

however, you still need to be careful

Is your definition really expressing what you had in mind ?

Does your formalisation correspond to the real world artefact ?

How can you convince others that this is the case ?

we will discuss methods to deal with this later in this courseI formal sanityI conformance testingI code reviewI comments, good names, clear coding styleI . . .

this is highly complex and needs a lot of effort in general

124 / 315

Specifications

HOL allows to introduce new constants with certain properties,provided the existence of such constants has been shown

Specification of EVEN and ODD> EVEN ODD EXISTS

val it = |- ?even odd. even 0 /\ ~odd 0 /\ (!n. even (SUC n) <=> odd n) /\

(!n. odd (SUC n) <=> even n)

> val EO SPEC = new specification ("EO SPEC", ["EVEN", "ODD"], EVEN ODD EXISTS);

val EO SPEC = |- EVEN 0 /\ ~ODD 0 /\ (!n. EVEN (SUC n) <=> ODD n) /\

(!n. ODD (SUC n) <=> EVEN n)

new specification is a convenience wrapperI it uses existential quantification instead of Hilbert’s choiceI deals with pair syntaxI stores resulting definitions in theory

new specification captures the underlying principle nicely

125 / 315

Definitions

special case: new constant defined by equality

Specification with Equality> double_EXISTS

val it =

|- ?double. (!n. double n = (n + n))

> val double_def = new_specification ("double_def", ["double"], double_EXISTS);

val double_def =

|- !n. double n = n + n

there is a specialised methods for such simple definitions

Non Recursive Definitions> val DOUBLE_DEF = new_definition ("DOUBLE_DEF", ‘‘DOUBLE n = n + n‘‘)

val DOUBLE_DEF =

|- !n. DOUBLE n = n + n

126 / 315

Restrictions for Definitions

all variables occurring on right-hand-side (rhs) need to be argumentsI e. g. new definition (..., ‘‘F n = n + m‘‘) failsI m is free on rhs

all type variables occurring on rhs need to occur on lhsI e. g. new definition ("IS FIN TY",

‘‘IS FIN TY = FINITE (UNIV : ’a set)‘‘) failsI IS FIN TY would lead to inconsistencyI |- FINITE (UNIV : bool set)I |- ~FINITE (UNIV : num set)I T <=> FINITE (UNIV:bool set) <=>

IS FIN TY <=>

FINITE (UNIV:num set) <=> FI therefore, such definitions can’t be allowed

127 / 315

Underspecified Functions

function specification do not need to define the function precisely

multiple different functions satisfying one spec are possible

functions resulting from such specs are called underspecified

underspecified functions are still total, one just lacks knowledge

one common application: modelling partial functionsI functions like e. g. HD and TL are totalI they are defined for empty listsI however, it is not specified, which value they have for empty listsI only known: HD [] = HD [] and TL [] = TL []

val MY_HD_EXISTS = prove (‘‘?hd. !x xs. (hd (x::xs) = x)‘‘, ...);

val MY_HD_SPEC =

new_specification ("MY_HD_SPEC", ["MY_HD"], MY_HD_EXISTS)

128 / 315

Primitive Type Definitions

HOL allows introducing non-empty subtypes of existing types

a predicate P : ty -> bool describes a subset of an existing type ty

ty may contain type variables

only non-empty types are allowed

therefore a non-emptyness proof ex-thm of form ?e. P e is needed

new type definition (op-name, ex-thm) then introduces a newtype op-name specified by P

129 / 315

Primitive Type Definitions - Example 1

lets try to define a type dlist of lists containing no duplicates

predicate ALL DISTINCT : ’a list -> bool is used to define it

easy to prove theorem dlist exists: |- ?l. ALL DISTINCT l

val dlist TY DEF = new type definitions("dlist",

dlist exists) defines a new type ’a dlist and returns a theorem

|- ?(rep :’a dlist -> ’a list).

TYPE_DEFINITION ALL_DISTINCT rep

rep is a function taking a ’a dlist to the list representing itI rep is injectiveI a list satisfies ALL DISTINCT iff there is a corresponding dlist

130 / 315

Primitive Type Definitions - Example 2

define new type bijections can be used to define bijectionsbetween old and new type

> define_new_type_bijections {name="dlist_tybij", ABS="abs_dlist",

REP="rep_dlist", tyax=dlist_TY_DEF}

val it =

|- (!a. abs_dlist (rep_dlist a) = a) /\

(!r. ALL_DISTINCT r <=> (rep_dlist (abs_dlist r) = r))

other useful theorems can be automatically proved byI prove abs fn one oneI prove abs fn ontoI prove rep fn one oneI prove rep fn onto

131 / 315

Primitive Definition Principles Summary

primitive definition principles are easily explained

they lead to conservative extensions

however, they are cumbersome to use

LCF approach allows implementing more convenient definition toolsI Datatype packageI TFL (Total Functional Language) packageI IndDef (Inductive Definition) packageI quotientLib Quotient Types LibraryI ...

132 / 315

Functional Programming

the Datatype package allows to define datatypes conveniently

the TFL package allows to define (mutually recursive) functions

the EVAL conversion allows evaluating those definitions

this gives many HOL developments the feeling of a functional program

there is really a close connection between functional programming anddefinitions in HOL

I functional programming design principles applyI EVAL is a great way to test quickly, whether your definitions are

working as intended

133 / 315

Functional Programming Example

> Datatype ‘mylist = E | L ’a mylist‘

val it = (): unit

> Define ‘(mylen E = 0) /\ (mylen (L x xs) = SUC (mylen xs))‘

Definition has been stored under "mylen def"

val it =

|- (mylen E = 0) /\ !x xs. mylen (L x xs) = SUC (mylen xs):

thm

> EVAL ‘‘mylen (L 2 (L 3 (L 1 E)))‘‘

val it =

|- mylen (L 2 (L 3 (L 1 E))) = 3:

thm

134 / 315

Datatype Package

the Datatype package allows to define SML style datatypes easily

there is support forI algebraic datatypesI record typesI mutually recursive typesI ...

many constants are automatically introducedI constructorsI case-split constantI size functionI field-update and accessor functions for recordsI ...

many theorems are derived and stored in current theoryI injectivity and distinctness of constructorsI nchotomy and structural induction theoremsI rewrites for case-split, size and record update functionsI ...

135 / 315

Datatype Package - Example I

Tree Datatype in SMLdatatype (’a,’b) btree = Leaf of ’a

| Node of (’a,’b) btree * ’b * (’a,’b) btree

Tree Datatype in HOLDatatype ‘btree = Leaf ’a

| Node btree ’b btree‘

Tree Datatype in HOL — Deprecated SyntaxHol_datatype ‘btree = Leaf of ’a

| Node of btree => ’b => btree‘

136 / 315

Datatype Package - Example I - Derived Theorems 1

btree distinct|- !a2 a1 a0 a. Leaf a <> Node a0 a1 a2

btree 11|- (!a a’. (Leaf a = Leaf a’) <=> (a = a’)) /\

(!a0 a1 a2 a0’ a1’ a2’.

(Node a0 a1 a2 = Node a0’ a1’ a2’) <=>

(a0 = a0’) /\ (a1 = a1’) /\ (a2 = a2’))

btree nchotomy

|- !bb. (?a. bb = Leaf a) \/ (?b b1 b0. bb = Node b b1 b0)

btree induction|- !P. (!a. P (Leaf a)) /\

(!b b0. P b /\ P b0 ==> !b1. P (Node b b1 b0)) ==>

!b. P b

137 / 315

Datatype Package - Example I - Derived Theorems 2

btree size def|- (!f f1 a. btree_size f f1 (Leaf a) = 1 + f a) /\

(!f f1 a0 a1 a2.

btree_size f f1 (Node a0 a1 a2) =

1 + (btree_size f f1 a0 + (f1 a1 + btree_size f f1 a2)))

btree case def|- (!a f f1. btree_CASE (Leaf a) f f1 = f a) /\

(!a0 a1 a2 f f1. btree_CASE (Node a0 a1 a2) f f1 = f1 a0 a1 a2)

btree case cong

|- !M M’ f f1.

(M = M’) /\ (!a. (M’ = Leaf a) ==> (f a = f’ a)) /\

(!a0 a1 a2.

(M’ = Node a0 a1 a2) ==> (f1 a0 a1 a2 = f1’ a0 a1 a2)) ==>

(btree_CASE M f f1 = btree_CASE M’ f’ f1’)

138 / 315

Datatype Package - Example II

Enumeration type in SMLdatatype my_enum = E1 | E2 | E3

Enumeration type in HOLDatatype ‘my_enum = E1 | E2 | E3‘

139 / 315

Datatype Package - Example II - Derived Theorems

my enum nchotomy

|- !P. P E1 /\ P E2 /\ P E3 ==> !a. P a

my enum distinct

|- E1 <> E2 /\ E1 <> E3 /\ E2 <> E3

my enum2num thm

|- (my_enum2num E1 = 0) /\ (my_enum2num E2 = 1) /\ (my_enum2num E3 = 2)

my enum2num num2my enum

|- !r. r < 3 <=> (my_enum2num (num2my_enum r) = r)

140 / 315

Datatype Package - Example III

Record type in SMLtype rgb = { r : int, g : int, b : int }

Record type in HOLDatatype ‘rgb = <| r : num; g : num; b : num |>‘

141 / 315

Datatype Package - Example III - Derived Theorems

rgb component equality

|- !r1 r2. (r1 = r2) <=>

(r1.r = r2.r) /\ (r1.g = r2.g) /\ (r1.b = r2.b)

rgb nchotomy

|- !rr. ?n n0 n1. rr = rgb n n0 n1

rgb r fupd

|- !f n n0 n1. rgb n n0 n1 with r updated_by f = rgb (f n) n0 n1

rgb updates eq literal

|- !r n1 n0 n.

r with <|r := n1; g := n0; b := n|> = <|r := n1; g := n0; b := n|>

142 / 315

Datatype Package - Example IV

nested record types are not allowed

however, mutual recursive types can mitigate this restriction

Filesystem Datatype in SMLdatatype file = Text of string

| Dir of {owner : string ,

files : (string * file) list}

Not Supported Nested Record Type Example in HOLDatatype ‘file = Text string

| Dir <| owner : string ;

files : (string # file) list |>‘

Filesystem Datatype - Mutual Recursion in HOLDatatype ‘file = Text string

| Dir directory

;

directory = <| owner : string ;

files : (string # file) list |>‘

143 / 315

Datatype Package - No support for Co-Algebraic Types

there is no support for co-algebraic types

the Datatype package could be extended to do so

other systems like Isabelle/HOL provide high-level methods fordefining such types

Co-algebraic Type Example in SML — Lazy Listsdatatype ’a lazylist = Nil

| Cons of (’a * (unit -> ’a lazylist))

144 / 315

Datatype Package - Discussion

Datatype package allows to define many useful datatypes

however, there are many limitationsI some types cannot be defined in HOL, e. g. empty typesI some types are not supported, e. g. co-algebraic typesI there are bugs (currently e. g. some trouble with certain mutually

recursive definitions)

biggest restrictions in practice (in my opinion and my line of work)I no support for co-algebraic datatypesI no nested record datatypes

depending on datatype, different sets of useful lemmata are derived

most important ones are added to TypeBaseI tools like Induct on, Cases on use themI there is support for pattern matching

145 / 315

Total Functional Language (TFL) package

TFL package implements support for terminating functional definitions

Define defines functions from high-level descriptions

there is support for pattern matching

look and feel is like function definitions in SML

based on well-founded recursion principle

Define is the most common way for definitions in HOL

146 / 315

Well-Founded Relations

a relation R : ’a -> ’a -> bool is called well-founded, iff thereare no infinite descending chains

wellfounded R = ~?f. !n. R (f (SUC n)) (f n)

Example: $< : num -> num -> bool is well-founded

if arguments of recursive calls are smaller according to well-foundedrelation, the recursion terminates

this is the essence of termination proofs

147 / 315

Well-Founded Recursion

a well-founded relation R can be used to define recursive functions

this recursion principle is called WFREC in HOL

idea of WFRECI if arguments get smaller according to R, perform recursive callI otherwise abort and return ARB

WFREC always defines a function

if all recursive calls indeed decrease according to R, the originalrecursive equations can be derived from the WFREC representation

TFL uses this internally

however, this is well-hidden from the user

148 / 315

Define - Initial Examples

Simple Definitions> val DOUBLE_def = Define ‘DOUBLE n = n + n‘

val DOUBLE_def =

|- !n. DOUBLE n = n + n:

thm

> val MY_LENGTH_def = Define ‘(MY_LENGTH [] = 0) /\

(MY_LENGTH (x::xs) = SUC (MY_LENGTH xs))‘

val MY_LENGTH_def =

|- (MY_LENGTH [] = 0) /\ !x xs. MY_LENGTH (x::xs) = SUC (MY_LENGTH xs):

thm

> val MY_APPEND_def = Define ‘(MY_APPEND [] ys = ys) /\

(MY_APPEND (x::xs) ys = x :: (MY_APPEND xs ys))‘

val MY_APPEND_def =

|- (!ys. MY_APPEND [] ys = ys) /\

(!x xs ys. MY_APPEND (x::xs) ys = x::MY_APPEND xs ys):

thm

149 / 315

Define discussion

Define feels like a function definition in HOL

it can be used to define ”terminating” recursive functions

Define is implemented by a large, non-trivial piece of SML code

it uses many heuristics

outcome of Define sometimes hard to predict

the input descriptions are only hintsI the produced function and the definitional theorem might be differentI in simple examples, quantifiers addedI pattern compilation takes placeI earlier “conjuncts” have precedence

150 / 315

Define - More Examples

> val MY_HD_def = Define ‘MY_HD (x :: xs) = x‘

val MY_HD_def = |- !x xs. MY_HD (x::xs) = x : thm

> val IS_SORTED_def = Define ‘

(IS_SORTED (x1 :: x2 :: xs) = ((x1 < x2) /\ (IS_SORTED (x2::xs)))) /\

(IS_SORTED _ = T)‘

val IS_SORTED_def =

|- (!xs x2 x1. IS_SORTED (x1::x2::xs) <=> x1 < x2 /\ IS_SORTED (x2::xs)) /\

(IS_SORTED [] <=> T) /\ (!v. IS_SORTED [v] <=> T)

> val EVEN_def = Define ‘(EVEN 0 = T) /\ (ODD 0 = F) /\

(EVEN (SUC n) = ODD n) /\ (ODD (SUC n) = EVEN n)‘

val EVEN_def =

|- (EVEN 0 <=> T) /\ (ODD 0 <=> F) /\ (!n. EVEN (SUC n) <=> ODD n) /\

(!n. ODD (SUC n) <=> EVEN n) : thm

> val ZIP_def = Define ‘(ZIP (x::xs) (y::ys) = (x,y)::(ZIP xs ys)) /\

(ZIP = [])‘

val ZIP_def =

|- (!ys y xs x. ZIP (x::xs) (y::ys) = (x,y)::ZIP xs ys) /\

(!v1. ZIP [] v1 = []) /\ (!v4 v3. ZIP (v3::v4) [] = []) : thm

151 / 315

Primitive Definitions

Define introduces (if needed) the function using WFREC

intended definition derived as a theorem

the theorems are stored in current theory

usually, one never needs to look at it

Examplesval IS_SORTED_primitive_def =

|- IS_SORTED =

WFREC (@R. WF R /\ !x1 xs x2. R (x2::xs) (x1::x2::xs))

(\IS_SORTED a.

case a of

[] => I T

| [x1] => I T

| x1::x2::xs => I (x1 < x2 /\ IS_SORTED (x2::xs)))

|- !R M. WF R ==> !x. WFREC R M x = M (RESTRICT (WFREC R M) R x) x

|- !f R x. RESTRICT f R x = (\y. if R y x then f y else ARB)

152 / 315

Induction Theorems

Define automatically defines induction theorems

these theorems are stored in current theory with suffix ind

use DB.fetch "-" "something ind" to retrieve them

these induction theorems are useful to reason about correspondingrecursive functions

Exampleval IS_SORTED_ind = |- !P.

((!x1 x2 xs. P (x2::xs) ==> P (x1::x2::xs)) /\

P [] /\

(!v. P [v])) ==>

!v. P v

153 / 315

Define failing

Define might fail for various reasons to define a functionI such a function cannot be defined in HOLI such a function can be defined, but not via the methods used by TFLI TFL can define such a function, but its heuristics are too weak and

user guidance is requiredI there is a bug :-)

termination is an important concept for Define

it is easy to misunderstand termination in the context of HOL

we need to understand what is meant by termination

154 / 315

Termination in HOL

in SML it is natural to talk about termination of functions

in the HOL logic there is no concept of execution

thus, there is no concept of termination in HOL

3 characterisations of a function f : num -> num

I |- !n. f n = 0

I |- (f 0 = 0) /\ !n. (f (SUC n) = f n)

I |- (f 0 = 0) /\ !n. (f n = f (SUC n))

Is f terminating? All 3 theorems are equivalent.

155 / 315

Termination in HOL II

it is useful to think in terms of termination

the TFL package implements heuristics to define functions that wouldterminate in SML

the TFL package uses well-founded recursion

the required well-founded relation corresponds to a termination proof

therefore, it is very natural to think of Define searching atermination proof

important: this is the idea behind this function definition package,not a property of HOL

HOL is not limited to ”terminating” functions

156 / 315

Termination in HOL III

one can define ”non-terminating” functions in HOL

however, one cannot do so (easily) with Define

Definition of WHILE in HOL|- !P g x. WHILE P g x = if P x then WHILE P g (g x) else x

Execution OrderThere is no ”execution order”. One can easily define a complicated constant function:

(myk : num -> num) (n:num) = (let x = myk (n+1) in 0)

Unsound DefinitionsA function f : num -> num with the following property cannot be defined in HOL unless HOLhas an inconsistancy:

!n. f n = ((f n) + 1)

Such a function would allow to prove 0 = 1.

157 / 315

Manual Termination Proofs I

TFL uses various heuristics to find a well-founded relation

however, these heuristics may not be strong enough

in such cases the user can provide a well-founded relation manually

the most common well-founded relations are measures

measures map values to natural numbers and use the less relation|- !(f:’a -> num) x y. measure f x y <=> (f x < f y)

all measures are well-founded: |- !f. WF (measure f)

moreover, existing well-founded relations can be combinedI lexicographic order LEXI list lexicographic order LLEXI . . .

158 / 315

Manual Termination Proofs II

if Define fails to find a termination proof, Hol defn can be used

Hol defn defers termination proofs

it derives termination conditions and sets up the function definitions

all results are packaged as a value of type defn

after calling Hol defn the defined function(s) can be used

however, the intended definition theorem has not been derived yet

to derive it, one needs toI provide a well-founded relationI show that termination conditions respect that relation

Defn.tprove and Defn.tgoal are intended for this

proofs usually start by providing relation via tactic WF REL TAC

159 / 315

Manual Termination Proof Example 1

> val qsort_defn = Hol_defn "qsort" ‘

(qsort ord [] = []) /\

(qsort ord (x::rst) =

(qsort ord (FILTER ($~ o ord x) rst)) ++

[x] ++

(qsort ord (FILTER (ord x) rst)))‘

val qsort_defn = HOL function definition (recursive)

Equation(s) :

[...] |- qsort ord [] = []

[...] |- qsort ord (x::rst) =

qsort ord (FILTER ($~ o ord x) rst) ++ [x] ++

qsort ord (FILTER (ord x) rst)

Induction : ...

Termination conditions :

0. !rst x ord. R (ord,FILTER (ord x) rst) (ord,x::rst)

1. !rst x ord. R (ord,FILTER ($~ o ord x) rst) (ord,x::rst)

2. WF R

160 / 315


> Defn.tgoal qsort_defn

Initial goal:

?R.

WF R /\

(!rst x ord. R (ord,FILTER (ord x) rst) (ord,x::rst)) /\

(!rst x ord. R (ord,FILTER ($~ o ord x) rst) (ord,x::rst))

> e (WF_REL_TAC ‘measure (\( , l). LENGTH l)‘)

1 subgoal :

(!rst x ord. LENGTH (FILTER (ord x) rst) < LENGTH (x::rst)) /\

(!rst x ord. LENGTH (FILTER (\x’. ~ord x x’) rst) < LENGTH (x::rst))

> ...

161 / 315


> val (qsort_def, qsort_ind) =

Defn.tprove (qsort_defn,

WF_REL_TAC ‘measure (\( , l). LENGTH l)‘) >> ...)

val qsort_def =

|- (qsort ord [] = []) /\

(qsort ord (x::rst) =

qsort ord (FILTER ($~ o ord x) rst) ++ [x] ++

qsort ord (FILTER (ord x) rst))

val qsort_ind =

|- !P. (!ord. P ord []) /\

(!ord x rst.

P ord (FILTER (ord x) rst) /\

P ord (FILTER ($~ o ord x) rst) ==>

P ord (x::rst)) ==>

!v v1. P v v1

162 / 315

Part XI

Good Definitions

Importance of Good Definitions

using good definitions is very importantI good definitions are vital for clarityI proofs depend a lot on the form of definitions

unluckily, it is hard to state what a good definition is

even harder to come up with good definitions

let’s look at it a bit closer anyhow

164 / 315

Importance of Good Definitions — Clarity I

HOL guarantees that theorems do indeed hold

However, does the theorem mean what you think it does?

you can separate your development inI main theorems you care forI auxiliary stuff used to derive your main theorems

it is essential to understand your main theorems

165 / 315

Importance of Good Definitions — Clarity II

Guarded by HOL

proofs checked

internal, technical definitions

technical lemmata

proof tools

Manual review needed for

meaning of main theorems

meaning of definitions usedby main theorems

meaning of types used bymain theorems

166 / 315

Importance of Good Definitions — Clarity III

it is essential to understand your main theoremsI you need to understand all the definitions directly usedI you need to understand the indirectly used ones as wellI you need to convince others that you express the intended statementI therefore, it is vital to use very simple, clear definitions

defining concepts is often the main development task

checking resulting model against real artefact is vitalI testing via e. g. EVALI formal sanityI conformance testing

wrong models are main source of error when using HOL

proofs, auxiliary lemmata and auxiliary definitionsI can be as technical and complicated as you likeI correctness is guaranteed by HOLI reviewers don’t need to care

167 / 315

Importance of Good Definitions — Proofs

good definitions can shorten proofs significantly

they improve maintainability

they can improve automation drastically

unluckily for proofs definitions often need to be technical

this contradicts clarity aims

168 / 315

How to come up with good definitions

unluckily, it is hard to state what a good definition is

it is even harder to come up with themI there are often many competing interestsI a lot of experience and detailed tool knowledge is neededI much depends on personal style and taste

general advice: use more than one definitionI in HOL you can derive equivalent definitions as theoremsI define a concept as clearly and easily as possibleI derive equivalent definitions for various purposes

F one very close to your favourite textbookF one nice for certain types of proofsF another one good for evaluationF . . .

lessons from functional programming apply

169 / 315

Good Definitions in Functional Programming

Objectives

clarity (readability, maintainability)

performance (runtime speed, memory usage, ...)

General Advice

use the powerful type-system

use many small function definitions

encode invariants in types and function signatures

170 / 315

Good Definitions – no number encodingsmany programmers familiar with C encode everything as a numberenumeration types are very cheap in SML and HOLuse them instead

Example Enumeration TypesIn C the result of an order comparison is an integer with 3 equivalence classes: 0, negative andpositive integers. In SML and HOL, it is better to use a variant type.

val _ = Datatype ‘ordering = LESS | EQUAL | GREATER‘;

val compare_def = Define ‘

(compare LESS lt eq gt = lt)

/\ (compare EQUAL lt eq gt = eq)

/\ (compare GREATER lt eq gt = gt) ‘;

val list_compare_def = Define ‘

(list_compare cmp [] [] = EQUAL) /\ (list_compare cmp [] l2 = LESS)

/\ (list_compare cmp l1 [] = GREATER)

/\ (list_compare cmp (x::l1) (y::l2) = compare (cmp (x:’a) y)

(* x<y *) LESS

(* x=y *) (list_compare cmp l1 l2)

(* x>y *) GREATER) ‘;

171 / 315

Good Definitions — Isomorphic Types

the type-checker is your friendI it helps you find errorsI code becomes more robustI using good types is a great way of writing self-documenting code

therefore, use many types

even use types isomorphic to existing ones

Virtual and Physical Memory AddressesVirtual and physical addresses might in a development both be numbers. It is still nice to useseparate types to avoid mixing them up.

val _ = Datatype ‘vaddr = VAddr num‘;

val _ = Datatype ‘paddr = PAddr num‘;

val virt_to_phys_addr_def = Define ‘

virt_to_phys_addr (VAddr a) = PAddr( translation of a )‘;

172 / 315

Good Definitions — Record Types I

often people use tuples where records would be more appropriate

using large tuples quickly becomes awkwardI it is easy to mix up order of tuple entries

F often types coincide, so type-checker does not help

I no good error messages for tuplesF hard to decipher type mismatch messages for long product typesF hard to figure out which entry is missing at which positionF non-local error messagesF variable in last entry can hide missing entries

records sometimes require slightly more proof effort

however, records have many benefits

173 / 315

Good Definitions — Record Types II

using recordsI introduces field namesI provides automatically defined accessor and update functionsI leads to better type-checking error messages

records improve readabilityI accessors and update functions lead to shorter codeI field names act as documentation

records improve maintainabilityI improved error messagesI much easier to add extra fields

174 / 315

Good Definitions — Encoding Invariants

try to encode as many invariants as possible in the types

this allows the type-checker to ensure them for you

you don’t have to check them manually any more

your code becomes more robust and clearer

Network Connections (Example by Yaron Minsky from Jane Street)Consider the following datatype for network connections. It has many implicit invariants.

datatype connection_state = Connected | Disconnected | Connecting;

type connection_info = {

state : connection_state,

server : inet_address,

last_ping_time : time option,

last_ping_id : int option,

session_id : string option,

when_initiated : time option,

when_disconnected : time option

}

175 / 315

Good Definitions — Encoding Invariants II

Network Connections (Example by Yaron Minsky from Jane Street) IIThe following definition of connection info makes the invariants explicit:

type connected = { last_ping : (time * int) option,

session_id : string };

type disconnected = { when_disconnected : time };

type connecting = { when_initiated : time };

datatype connection_state =

Connected of connected

| Disconnected of disconneted

| Connecting of connecting;

type connection_info = {

state : connection_state,

server : inet_address

}

176 / 315

Good Definitions in HOL

Objectives

clarity (readability)

good for proofs

performance (good for automation, easily evaluatable, ...)

General Advice

same advice as for functional programming applies

use even smaller definitionsI introduce auxiliary definitions for important function partsI use extra definitions for important constantsI ...

tiny definitionsI allow keeping proof state small by unfolding only needed onesI allow many small lemmataI improve maintainability

177 / 315

Good Definitions in HOL II

Technical Issues

write definitions such that they work well with HOL’s tools

this requires you to know HOL well

a lot of experience is required

general adviceI avoid explicit case-expressionsI prefer curried functions

Exampleval ZIP_GOOD_def = Define ‘(ZIP (x::xs) (y::ys) = (x,y)::(ZIP xs ys)) /\

(ZIP _ _ = [])‘

val ZIP_BAD1_def = Define ‘ZIP xs ys = case (xs, ys) of

(x::xs, y::ys) => (x,y)::(ZIP xs ys)

| (_, _) => []‘

val ZIP_BAD2_def = Define ‘(ZIP (x::xs, y::ys) = (x,y)::(ZIP (xs, ys))) /\

(ZIP _ = [])‘

178 / 315

Good Definitions in HOL III

Multiple Equivalent Definitions

satisfy competing requirements by having multiple equivalentdefinitions

derive them as theorems

initial definition should be as clear as possibleI clarity allows simpler reviewsI simplicity reduces the likelihood of errors

Example - ALL DISTINCT

|- (ALL_DISTINCT [] <=> T) /\

(!h t. ALL_DISTINCT (h::t) <=> ~MEM h t /\ ALL_DISTINCT t)

|- !l. ALL_DISTINCT l <=>

(!x. MEM x l ==> (FILTER ($= x) l = [x]))

|- !ls. ALL_DISTINCT ls <=> (CARD (set ls) = LENGTH ls):

179 / 315

Formal Sanity

Formal Sanity

to ensure correctness test your definitions via e. g. EVAL

in HOL testing means symbolic evaluation, i. e. proving lemmata

formally proving sanity check lemmata is very beneficialI they should express core properties of your definitionI thereby they check your intuition against your actual definitionsI these lemmata are often useful for following proofsI using them improves robustness and maintainability of your

development

I highly recommend using formal sanity checks

180 / 315

Formal Sanity Example I

> val ALL_DISTINCT = Define ‘

(ALL_DISTINCT [] = T) /\

(ALL_DISTINCT (h::t) = ~MEM h t /\ ALL_DISTINCT t)‘;

Example Sanity Check Lemmata|- ALL_DISTINCT []

|- !x xs. ALL_DISTINCT (x::xs) <=> ~MEM x xs /\ ALL_DISTINCT xs

|- !x. ALL_DISTINCT [x]

|- !x xs. ~(ALL_DISTINCT (x::x::xs))

|- !l. ALL_DISTINCT (REVERSE l) <=> ALL_DISTINCT l

|- !x l. ALL_DISTINCT (SNOC x l) <=> ~MEM x l /\ ALL_DISTINCT l

|- !l1 l2. ALL_DISTINCT (l1 ++ l2) <=>

ALL_DISTINCT l1 /\ ALL_DISTINCT l2 /\ !e. MEM e l1 ==> ~MEM e l2

181 / 315

Formal Sanity Example II 1

> val ZIP_def = Define ‘

(ZIP [] ys = []) /\ (ZIP xs [] = []) /\

(ZIP (x::xs) (y::ys) = (x, y)::(ZIP xs ys))‘

val ZIP_def =

|- (!ys. ZIP [] ys = []) /\ (!v3 v2. ZIP (v2::v3) [] = []) /\

(!ys y xs x. ZIP (x::xs) (y::ys) = (x,y)::ZIP xs ys)

above definition of ZIP looks straightforward

small changes cause heuristics to produce different theorems

use formal sanity lemmata to compensate

> val ZIP_def = Define ‘

(ZIP xs [] = []) /\ (ZIP [] ys = []) /\

(ZIP (x::xs) (y::ys) = (x, y)::(ZIP xs ys))‘

val ZIP_def =

|- (!xs. ZIP xs [] = []) /\ (!v3 v2. ZIP [] (v2::v3) = []) /\

(!ys y xs x. ZIP (x::xs) (y::ys) = (x,y)::ZIP xs ys0

182 / 315

Formal Sanity Example II 2

val ZIP_def =

|- (!ys. ZIP [] ys = []) /\ (!v3 v2. ZIP (v2::v3) [] = []) /\

(!ys y xs x. ZIP (x::xs) (y::ys) = (x,y)::ZIP xs ys)

Example Formal Sanity Lemmata|- (!xs. ZIP xs [] = []) /\ (!ys. ZIP [] ys = []) /\

(!y ys x xs. ZIP (x::xs) (y::ys) = (x,y)::ZIP xs ys)

|- !xs ys. LENGTH (ZIP xs ys) = MIN (LENGTH xs) (LENGTH ys)

|- !x y xs ys. MEM (x, y) (ZIP xs ys) ==> (MEM x xs /\ MEM y ys)

|- !xs1 xs2 ys1 ys2. LENGTH xs1 = LENGTH ys1 ==>

(ZIP (xs1++xs2) (ys1++ys2) = (ZIP xs1 ys1 ++ ZIP xs2 ys2))

...

in your proofs use sanity lemmata, not original definition

this makes your development robust againstI small changes to the definition required laterI changes to Define and its heuristicsI bugs in function definition package

183 / 315

Part XII

Deep and Shallow Embeddings

Deep and Shallow Embeddings

often one models some kind of formal language

important design decision: use deep or shallow embedding

in a nutshell:I shallow embeddings just model semanticsI deep embeddings model syntax as well

a shallow embedding directly uses the HOL logic

a deep embeddingI defines a datatype for the syntax of the languageI provides a function to map this syntax to a semantic

185 / 315

Example: Embedding of Propositional Logic I

propositional logic is a subset of HOL

a shallow embedding is therefore trivial

val sh_true_def = Define ‘sh_true = T‘;

val sh_var_def = Define ‘sh_var (v:bool) = v‘;

val sh_not_def = Define ‘sh_not b = ~b‘;val sh_and_def = Define ‘sh_and b1 b2 = (b1 /\ b2)‘;

val sh_or_def = Define ‘sh_or b1 b2 = (b1 \/ b2)‘;

val sh_implies_def = Define ‘sh_implies b1 b2 = (b1 ==> b2)‘;

186 / 315

Example: Embedding of Propositional Logic II

we can also define a datatype for propositional logic

this leads to a deep embedding

val _ = Datatype ‘bvar = BVar num‘

val _ = Datatype ‘prop = d_true | d_var bvar | d_not prop

| d_and prop prop | d_or prop prop

| d_implies prop prop‘;

val _ = Datatype ‘var_assignment = BAssign (bvar -> bool)‘

val VAR_VALUE_def = Define ‘VAR_VALUE (BAssign a) v = (a v)‘

val PROP_SEM_def = Define ‘

(PROP_SEM a d_true = T) /\

(PROP_SEM a (d_var v) = VAR_VALUE a v) /\

(PROP_SEM a (d_not p) = ~(PROP_SEM a p)) /\

(PROP_SEM a (d_and p1 p2) = (PROP_SEM a p1 /\ PROP_SEM a p2)) /\

(PROP_SEM a (d_or p1 p2) = (PROP_SEM a p1 \/ PROP_SEM a p2)) /\

(PROP_SEM a (d_implies p1 p2) = (PROP_SEM a p1 ==> PROP_SEM a p2))‘

187 / 315

Shallow vs. Deep Embeddings

Shallow

quick and easy to build

extensions are simple

Deep

can reason about syntax

allows verifiedimplementations

sometimes tricky to defineI e. g. bound variables

Important Questions for Deciding

Do I need to reason about syntax?

Do I have hard to define syntax like bound variables?

How much time do I have?

188 / 315

Example: Embedding of Propositional Logic III

with deep embedding one can easily formalise syntactic properties likeI Which variables does a propositional formula contain?I Is a formula in negation-normal-form (NNF)?

with shallow embeddingsI syntactic concepts can’t be defined in HOLI however, they can be defined in SMLI no proofs about them possible

val _ = Define ‘

(IS_NNF (d_not d_true) = T) /\ (IS_NNF (d_not (d_var v)) = T) /\

(IS_NNF (d_not _) = F) /\

(IS_NNF d_true = T) /\ (IS_NNF (d_var v) = T) /\

(IS_NNF (d_and p1 p2) = (IS_NNF p1 /\ IS_NNF p2)) /\

(IS_NNF (d_or p1 p2) = (IS_NNF p1 /\ IS_NNF p2)) /\

(IS_NNF (d_implies p1 p2) = (IS_NNF p1 /\ IS_NNF p2))‘

189 / 315

Verified vs. Verifying Program

Verified Programs

are formalised in HOL

their properties have beenproven once and for all

all runs have provenproperties

are usually less sophisticated,since they need verification

is what one wants ideally

often require deep embedding

Verifying Programs

are written in meta-language

they produce a separateproof for each run

only certain that current runhas properties

allow more flexibility, e. g.fancy heuristics

good pragmatic solution

shallow embedding fine

190 / 315

Summary Deep vs. Shallow Embeddings

deep embeddings require more work

they however allow reasoning about syntaxI induction and case-splits possibleI a semantic subset can be carved out syntactically

syntax sometimes hard to define for deep embeddings

combinations of deep and shallow embeddings commonI certain parts are deeply embeddedI others are embedded shallowly

191 / 315

Part XIII

Rewriting

Rewriting in HOL

simplification via rewriting was already a strength of Edinburgh LCF

it was further improved for Cambridge LCF

HOL inherited this powerful rewriter

equational reasoning is still the main workhorse

there are many different equational reasoning tools in HOLI Rewrite library

inherited from Cambridge LCFyou have seen it in the form of REWRITE TAC

I computeLib — fast evaluationbuild for speed, optimised for ground termsseen in the form of EVAL

I simpLib — Simplificationsophisticated rewrite engine, HOL’s main workhorsenot discussed in this lecture, yet

I . . .

193 / 315

Semantic Foundations

we have seen primitive inference rules for equality before

Γ ` s = t∆ ` u = v

types fit

Γ ∪∆ ` s(u) = t(v)COMB

Γ ` s = t∆ ` t = u



Γ ` λx . s = λx . tABS

` t = tREFL

these rules allow us to replace any subterm with an equal one

this is the core of rewriting

194 / 315

Conversions

in HOL, equality reasoning is implemented by conversions

a conversion is a SML function of type term -> thm

given a term t, a conversionI produces a theorem of the form |- t = t’I raises an UNCHANGED exception orI fails, i. e. raises an HOL ERR exception

Example> BETA CONV ‘‘(\x. SUC x) y‘‘

val it = |- (\x. SUC x) y = SUC y

> BETA CONV ‘‘SUC y‘‘

Exception-HOL_ERR ... raised

> REPEATC BETA CONV ‘‘SUC y‘‘

Exception- UNCHANGED raised

195 / 315

Conversionals

similar to tactics and tacticals there are conversionals for conversions

conversionals allow building conversions from simpler ones

there are many of themI THENCI ORELSECI REPEATCI TRY CONVI RAND CONVI RATOR CONVI ABS CONVI . . .

196 / 315

Depth Conversionals

for rewriting depth-conversionals are important

a depth-conversional applies a conversion to all subterms

there are many different onesI ONCE DEPTH CONV c — top down, applies c once at highest possible

positions in distinct subtermsI TOP SWEEP CONV c — top down, like ONCE DEPTH CONV, but continues

processing rewritten termsI TOP DEPTH CONV c — top down, like TOP SWEEP CONV, but try

top-level again after changeI DEPTH CONV c — bottom up, recurse over subterms, then apply c

repeatedly at top-levelI REDEPTH CONV c — bottom up, like DEPTH CONV, but revisits subterms

197 / 315

REWR CONV

it remains to rewrite terms at top-level

this is achieved by REWR CONV

given a term t and a theorem |- t1 = t2, REWR CONV t thmI searches an instantiation of term and type variables such that t1

becomes α-equivalent to tI fails, if no instantiation is foundI otherwise, instantiate the theorem and get |- t1’ = t2’I return theorem |- t = t2’

Exampleterm LENGTH [1;2;3], theorem |- LENGTH ((x:’a)::xs) = SUC (LENGTH xs)

found type instantiation: [‘‘:’a‘‘ |-> ‘‘:num‘‘]

found term instantiation: [‘‘x:num‘‘ |-> ‘‘1‘‘; ‘‘xs‘‘ |-> ‘‘[2;3]‘‘]

returned theorem: |- LENGTH [1;2;3] = SUC (LENGTH [2;3])

the tricky part is finding the instantiation

this problem is called the (term) matching problem

198 / 315

Term Matching

given term t org and a term t goal try to findI type substitution ty sI term substitution tm s

such that subst tm s (inst ty s t org)α≡ t goal

this can be easily implemented by a recursive search

t org t goal actiont1 org t2 org t1 goal t2 goal recurset1 org t2 org otherwise fail\x. t org x \y. t goal y match types of x, y and recurse\x. t org x otherwise failconst same const match typesconst otherwise failvar anything try to bind var,

take care of existing bindings

199 / 315

Examples Term Matching

t org t goal substsLENGTH ((x:’a)::xs) LENGTH [1;2;3] ’a → num, x → 1, xs → [2;3]

[]:’a list []:’b list ’a → ’b

0 0 empty substitution

b /\ T (P (x:’a) ==> Q) /\ T b → P x ==> Q

b /\ b P x /\ P x b → P x

b /\ b P x /\ P y fail!x:num. P x /\ Q x !y:num. P’ y /\ Q’ y P → P’, Q → Q’

!x:num. P x /\ Q x !y. (2 = y) /\ Q’ y P → ($= 2), Q → Q’

!x:num. P x /\ Q x !y. (y = 2) /\ Q’ y fail

it is often very annoying that the last match in the list above fails

it prevents us for example rewriting !y. (2 = y) /\ Q y to(!y. (2=y)) /\ (!y. Q y)

Can we do better? Yes, with higher order (term) matching.

200 / 315

Higher Order Term Matching

term matching searches for substitutions such that t org becomesα-equivalent to t goal

higher order term matching searches for substitutions such thatt org becomes t subst such that the βη-normalform of t subst isα-equivalent equivalent to βη-normalform of t goal, i. e.higher order term matching is aware of the semantics of λ

β-reduction (λx . f ) y = f [y/x ]η-conversion (λx . f x) = f where x is not free in f

the HOL implementation expects t org to be a higher-orderpattern

I t org is β-reducedI if X is a variable that should be instantiated, then all arguments should

be distinct variables

for other forms of t org, HOL’s implementation might fail

higher order matching is used by HO REWR CONV

201 / 315

Examples Higher Order Term Matching

t org t goal substs!x:num. P x /\ Q x !y. (y = 2) /\ Q’ y P → (\y. y = 2), Q → Q’

!x. P x /\ Q x !x. P x /\ Q x /\ Z x Q → \x. Q x /\ Z x

!x. P x /\ Q !x. P x /\ Q x fails!x. P (x, x) !x. Q x fails!x. P (x, x) !x. FST (x,x) = SND (x,x) P → \xx. FST xx = SND xx

Don’t worry, it might look complicated, butin practice it is easy to get a feeling for higher order matching.

202 / 315

Rewrite Library

the rewrite library combines REWR CONV with depth conversions

there are many different conversions, rules and tactics

at their core, they all work very similarlyI given a list of theorems, a set of rewrite theorems is derived

F split conjunctionsF remove outermost universal quantificationF introduce equations by adding = T (or = F) if needed

I REWR CONV is applied to all the resulting rewrite theoremsI a depth-conversion is used with resulting conversion

for performance reasons an efficient indexing structure is used

by default implicit rewrites are added

203 / 315

Rewrite Library II

REWRITE CONV

REWRITE RULE

REWRITE TAC

ASM REWRITE TAC

ONCE REWRITE TAC

PURE REWRITE TAC

PURE ONCE REWRITE TAC

. . .

204 / 315

Ho Rewrite Library

similar to Rewrite lib, but uses higher order matching

internally uses HO REWR CONV

similar conversions, rules and tactics as Rewrite libI Ho Rewrite.REWRITE CONVI Ho Rewrite.REWRITE RULEI Ho Rewrite.REWRITE TACI Ho Rewrite.ASM REWRITE TACI Ho Rewrite.ONCE REWRITE TACI Ho Rewrite.PURE REWRITE TACI Ho Rewrite.PURE ONCE REWRITE TACI . . .

205 / 315

Examples Rewrite and Ho Rewrite Library

> REWRITE CONV [LENGTH] ‘‘LENGTH [1;2]‘‘

val it = |- LENGTH [1; 2] = SUC (SUC 0)

> ONCE REWRITE CONV [LENGTH] ‘‘LENGTH [1;2]‘‘

val it = |- LENGTH [1; 2] = SUC (LENGTH [2])

> REWRITE CONV [] ‘‘A /\ A /\ ~A‘‘Exception- UNCHANGED raised

> PURE REWRITE CONV [NOT AND] ‘‘A /\ A /\ ~A‘‘val it = |- A /\ A /\ ~A <=> A /\ F

> REWRITE CONV [NOT AND] ‘‘A /\ A /\ ~A‘‘val it = |- A /\ A /\ ~A <=> F

> REWRITE CONV [FORALL_AND_THM] ‘‘!x. P x /\ Q x /\ R x‘‘


> Ho_Rewrite.REWRITE CONV [FORALL_AND_THM] ‘‘!x. P x /\ Q x /\ R x‘‘

val it = |- !x. P x /\ Q x /\ R x <=> (!x. P x) /\ (!x. Q x) /\ (!x. R x)

206 / 315

Summary Rewrite and Ho Rewrite Library

the Rewrite and Ho Rewrite library provide powerful infrastructurefor term rewriting

thanks to clever implementations they are reasonably efficient

basics are easily explained

however, efficient usage needs some experience

207 / 315

Term Rewriting Systems

to use rewriting efficiently, one needs to understand about termrewriting systems

this is a large topic

unluckily, it cannot be covered here in detail for time constraints

however, in practise you quickly get a feeling

important points in practiseI ensure termination of your rewritesI make sure they work nicely together

208 / 315

Term Rewriting Systems — Termination

Theory

choose well-founded order ≺for each rewrite theorem |- t1 = t2 ensure t2 ≺ t1

Practice

informally define for yourself what simpler means

ensure each rewrite makes terms simpler

good heuristicsI subterms are simpler than whole termI use an order on functions

209 / 315

Termination — Subterm examples

a proper subterm is always simplerI !l. APPEND [] l = lI !n. n + 0 = nI !l. REVERSE (REVERSE l) = lI !t1 t2. if T then t1 else t2 <=> t1I !n. n * 0 = 0

the right hand side should not use extra vars, throwing parts away isusually simpler

I !x xs. (SNOC x xs = []) = FI !x xs. LENGTH (x::xs) = SUC (LENGTH xs)I !n x xs. DROP (SUC n) (x::xs) = DROP n xs

210 / 315

Termination — use simpler terms

it is useful to consider some functions simple and other complicated

replace complicated ones with simple ones

never do it in the opposite direction

clear examplesI |- !m n. MEM m (COUNT LIST n) <=> (m < n)I |- !ls n. (DROP n ls = []) <=> (n >= LENGTH ls)

unclear exampleI |- !L. REVERSE L = REV L []

211 / 315

Termination — Normalforms

some equations can be used in both directions

one should decide on one direction

this implicitly defines a normalform one wants terms to be in

examplesI |- !f l. MAP f (REVERSE l) = REVERSE (MAP f l)I |- !l1 l2 l3. l1 ++ (l2 ++ l3) = l1 ++ l2 ++ l3

212 / 315

Termination — Problematic rewrite rules

some equations immediately lead to non-termination, e. g.I |- !m n. m + n = n + mI |- !m. m = m + 0

slightly more subtle are rules likeI |- !n. fact n = if (n = 0) then 1 else n * fact(n-1)

often combination of multiple rules leads to non-terminationthis is especially problematic when adding to predefined sets ofrewrites

I |- !m n p. m + (n + p) = (m + n) + p and|- !m n p. (m + n) + p = m + (n + p)

213 / 315

Rewrites working together

rewrite rules should not compete with each other

if a term ta can be rewritten to ta1 and ta2 applying differentrewrite rules, then ta1 and ta2 it should be possible to furtherrewrite them both to a common tb

this can often be achieved by adding extra rewrite rules

Example

Assume we have the rewrite rules |- DOUBLE n = n + n and|- EVEN (DOUBLE n) = T.With these the term EVEN (DOUBLE 2) can be rewritten to

T or

EVEN (2 + 2).

To avoid a hard to predict result, EVEN (2+2) should be rewritten to T.Adding an extra rewrite rule |- EVEN (n + n) = T achieves this.

214 / 315

Rewrites working together II

to design rewrite systems that work well, normalforms are vital

a term is in normalform, if it cannot be rewritten any further

one should have a clear idea what the normalform of common termslooks like

all rules should work together to establish this normalform

the right-hand-side of each rule should be in normalform

the left-hand-side should not be simplifiable by any other rule

the order in which rules are applied should not influence the finalresult

215 / 315

computeLib

computeLib is the library behind EVAL

it is a rewriting library designed for evaluating ground terms (i. e.terms without variables) efficiently

it uses a call-by-value strategy similar to SML’s

it uses first order term matching

it performs β reduction in addition to rewrites

216 / 315

compset

computeLib uses compsets to store its rewrites

a compset storesI rewrite rulesI extra conversions

the extra conversions are guarded by a term pattern for efficiency

users can define their own compsets

however, computeLib maintains one special compset calledthe compset

the compset is used by EVAL

217 / 315

EVAL

EVAL uses the compset

tools like the Datatype or TFL libraries automatically extendthe compset

this way, EVAL knows about (nearly) all types and functions

one can extended the compset manually as well

rewrites exported by Define are good for ground terms but may leadto non-termination for non-ground terms

zDefine prevents TFL from automatically extending the compset

218 / 315

simpLib

simpLib is a sophisticated rewrite engine

it is HOL’s main workhorse

it providesI higher order rewritingI usage of context informationI conditional rewritingI arbitrary conversionsI support for decision proceduresI simple heuristics to avoid non-terminationI fancier preprocessing of rewrite theoremsI . . .

it is very powerful, but compared to Rewrite lib sometimes slow

219 / 315

Basic Usage I

simpLib uses simpsets

simpsets are special datatypes storingI rewrite rulesI conversionsI decision proceduresI congruence rulesI . . .

in addition there are simpset-fragments

simpset-fragments contain similar information as simpsets

fragments can be added to and removed from simpsets

common usage: basic simpset combined with one or moresimpset-fragments, e. g.

I list ss ++ pairSimps.gen beta ssI std ss ++ QI ssI . . .

220 / 315

Basic Usage II

a call to the simplifier takes as argumentsI a simpsetI a list of rewrite theorems

common high-level entry points areI SIMP CONV ss thmL — conversionI SIMP RULE ss thmL — ruleI SIMP TAC ss thmL — tactic without considering assumptionsI ASM SIMP TAC ss thmL — tactic using assumptions to simplify goalI FULL SIMP TAC ss thmL — tactic simplifying assumptions with each

other and goal with assumptionsI REV FULL SIMP TAC ss thmL — similar to FULL SIMP TAC but with

reversed order of assumptions

there are many derived tools not discussed here

221 / 315

Basic Simplifier Examples

> SIMP_CONV bool_ss [LENGTH] ‘‘LENGTH [1;2]‘‘

val it = |- LENGTH [1; 2] = SUC (SUC 0)

> SIMP_CONV std_ss [LENGTH] ‘‘LENGTH [1;2]‘‘

val it = |- LENGTH [1; 2] = 2

> SIMP_CONV list_ss [] ‘‘LENGTH [1;2]‘‘

val it = |- LENGTH [1; 2] = 2

222 / 315

FULL SIMP TAC Example

Current GoalStackP (SUC (SUC x0)) (SUC (SUC y0))

------------------------------------

0. SUC y1 = y2

1. x1 = SUC x0

2. y1 = SUC y0

3. SUC x1 = x2

ActionFULL_SIMP_TAC std_ss []

Resulting GoalStackP (SUC (SUC x0)) y2

------------------------------------

0. SUC (SUC y0) = y2

1. x1 = SUC x0

2. y1 = SUC y0

3. SUC x1 = x2

223 / 315

REV FULL SIMP TAC Example

Current GoalStackP (SUC (SUC x0)) y2

------------------------------------


1. x1 = SUC x0

2. y1 = SUC y0

3. SUC x1 = x2

ActionREV_FULL_SIMP_TAC std_ss []

Resulting GoalStackP x2 y2

------------------------------------


1. x1 = SUC x0

2. y1 = SUC y0

3. SUC (SUC x0) = x2

224 / 315

Common simpsets

pure ss — empty simpset

bool ss — basic simpset

std ss — standard simpset

arith ss — arithmetic simpset

list ss — list simpset

real ss — real simpset

225 / 315

Common simpset-fragments

many theories and libraries provide their own simpset-fragments

PRED SET ss — simplify sets

STRING ss — simplify strings

QI ss — extra quantifier instantiations

gen beta ss — β reduction for pairs

ETA ss — η conversion

EQUIV EXTRACT ss — extract common part of equivalence

CONJ ss — use conjunctions for context

LIFT COND ss — lifting if-then-else

. . .

226 / 315

Build-In Conversions and Decision Procedures

in contrast to Rewrite lib the simplifier can run arbitrary conversions

most common and useful conversion is probably β-reduction

std ss has support for basic arithmetic and numerals

it also has simple, syntactic conversions for instantiating quantifiersI !x. ... /\ (x = c) /\ ... ==> ...I !x. ... \/ ~(x = c) \/ ...I ?x. ... /\ (x = c) /\ ...

besides very useful conversions, there are decision procedures as well

the most frequently used one is probably the arithmetic decisionprocedure you already know from DECIDE

227 / 315

Examples I

> SIMP_CONV std_ss [] ‘‘(\x. x + 2) 5‘‘

val it = |- (\x. x + 2) 5 = 7

> SIMP_CONV std_ss [] ‘‘!x. Q x /\ (x = 7) ==> P x‘‘

val it = |- (!x. Q x /\ (x = 7) ==> P x) <=> (Q 7 ==> P 7)‘‘

> SIMP_CONV std_ss [] ‘‘?x. Q x /\ (x = 7) /\ P x‘‘

val it = |- (?x. Q x /\ (x = 7) /\ P x) <=> (Q 7 /\ P 7)‘‘

> SIMP_CONV std_ss [] ‘‘x > 7 ==> x > 5‘‘


> SIMP_CONV arith_ss [] ‘‘x > 7 ==> x > 5‘‘

val it = |- (x > 7 ==> x > 5) <=> T

228 / 315

Higher Order Rewriting

the simplifier supports higher order rewriting

this is often very handy

for example it allows moving quantifiers around easily

Examples> SIMP_CONV std_ss [FORALL_AND_THM] ‘‘!x. P x /\ Q /\ R x‘‘

val it = |- (!x. P x /\ Q /\ R x) <=>

(!x. P x) /\ Q /\ (!x. R x)

> SIMP_CONV std_ss [GSYM RIGHT_EXISTS_AND_THM, GSYM LEFT_FORALL_IMP_THM]

‘‘!y. (P y /\ (?x. y = SUC x)) ==> Q y‘‘

val it = |- (!y. P y /\ (?x. y = SUC x) ==> Q y) <=>

!x. P (SUC x) ==> Q (SUC x)

229 / 315

Context

a great feature of the simplifier is that it can use context information

by default simple context information is used likeI the precondition of an implicationI the condition of if-then-else

one can configure which context to use via congruence rulesI e. g. by using CONJ ss one can easily use context of conjunctionsI warning: using CONJ ss can be slow

using context often simplifies proofs drasticallyI using Rewrite lib, often a goal needs to be split and a precondition

moved to the assumptionsI then ASM REWRITE TAC can be usedI with SIMP TAC there is no need to split the goal

230 / 315

Context Examples

> SIMP_CONV std_ss [] ‘‘((l = []) ==> P l) /\ Q l‘‘

val it = |- ((l = []) ==> P l) /\ Q l <=>

((l = []) ==> P []) /\ Q l

> SIMP_CONV arith_ss [] ‘‘if (c /\ x < 5) then (P c /\ x < 6) else Q c‘‘

val it = |- (if c /\ x < 5 then P c /\ x < 6 else Q c) <=>

if c /\ x < 5 then P T else Q c:

> SIMP_CONV std_ss [] ‘‘P x /\ (Q x /\ P x ==> Z x)‘‘


> SIMP_CONV (std_ss++boolSimps.CONJ_ss) [] ‘‘P x /\ (Q x /\ P x ==> Z x)‘‘

val it = |- P x /\ (Q x /\ P x ==> Z x) <=> P x /\ (Q x ==> Z x)

231 / 315

Conditional Rewriting I

perhaps the most powerful feature of the simplifier is that it supportsconditional rewriting

this means it allows conditional rewrite theorems of the form|- cond ==> (t1 = t2)

if the simplifier finds a term t1’ it can rewrite via t1 = t2 to t2’, ittries to discharge the assumption cond’

for this, it calls itself recursively on cond’I all the decision procedures and all context information is usedI conditional rewriting can be usedI to prevent divergence, there is a limit on recursion depth

if cond’ = T can be shown, t1’ is rewritten to t2’

otherwise t1’ is not modified

232 / 315

Conditional Rewriting Example

consider the conditional rewrite theorem!l n. LENGTH l <= n ==> (DROP n l = [])

let’s assume we want to prove(DROP 7 [1;2;3;4]) ++ [5;6;7] = [5;6;7]

we can without conditional rewritingI show |- LENGTH [1;2;3;4] <= 7I use this to discharge the precondition of the rewrite theoremI use the resulting theorem to rewrite the goal

with conditional rewriting, this is all automated

> SIMP_CONV list_ss [DROP_LENGTH_TOO_LONG]

‘‘(DROP 7 [1;2;3;4]) ++ [5;6;7]‘‘

val it = |- DROP 7 [1; 2; 3; 4] ++ [5; 6; 7] = [5; 6; 7]

conditional rewriting often shortens proofs considerably

233 / 315

Conditional Rewriting Example II

Proof with Rewriteprove (‘‘(DROP 7 [1;2;3;4]) ++ [5;6;7] = [5;6;7]‘‘,

‘DROP 7 [1;2;3;4] = []‘ by (

MATCH_MP_TAC DROP_LENGTH_TOO_LONG >>

REWRITE_TAC[LENGTH] >>

DECIDE_TAC

) >>

ASM_REWRITE_TAC[APPEND])

Proof with Simplifierprove (‘‘(DROP 7 [1;2;3;4]) ++ [5;6;7] = [5;6;7]‘‘,

SIMP_TAC list_ss [])

Notice that DROP LENGTH TOO LONG is part of list ss.

234 / 315

Conditional Rewriting II

conditional rewriting is a very powerful technique

decision procedures and sophisticated rewrites can be used todischarge preconditions without cluttering proof state

it provides a powerful search for theorems that apply

however, if used naively, it can be slow

moreover, to work well, rewrite theorems need to of a special form

235 / 315

Conditional Rewriting Pitfalls I

if the pattern is too general, the simplifier becomes very slow

consider the following, trivial but hopefully educational example

Looping example> val my_thm = prove (‘‘~P ==> (P = F)‘‘, PROVE_TAC[])

> time (SIMP_CONV std_ss [my_thm]) ‘‘P1 /\ P2 /\ P3 /\ ... /\ P10‘‘

runtime: 0.84000s, gctime: 0.02400s, systime: 0.02400s.


> time (SIMP_CONV std_ss []) ‘‘P1 /\ P2 /\ P3 /\ ... /\ P10‘‘

runtime: 0.00000s, gctime: 0.00000s, systime: 0.00000s.


I notice that the rewrite is applied at plenty of places (quadratic innumber of conjuncts)

I notice that each backchaining triggers many more backchainingsI each has to be aborted to prevent divergingI as a result, the simplifier becomes very slowI incidentally, the conditional rewrite is useless

236 / 315

Conditional Rewriting Pitfalls II

good conditional rewrites |- c ==> (l = r) should mention onlyvariables in c that appear in l

if c contains extra variables x1 ... xn, the conditional rewriteengine has to search instantiations for them

this mean that conditional rewriting is trying discharge theprecondition ?x1 ... xn. c

the simplifier is usually not able to find such instances

Transitivity> val P_def = Define ‘P x y = x < y‘;

> val my_thm = prove (‘‘!x y z. P x y ==> P y z ==> P x z‘‘, ...)

> SIMP_CONV arith_ss [my_thm] ‘‘P 2 3 /\ P 3 4 ==> P 2 4‘‘


(* However transitivity of < build in via decision procedure *)

> SIMP_CONV arith_ss [P_def] ‘‘P 2 3 /\ P 3 4 ==> P 2 4‘‘

val it = |- P 2 3 /\ P 3 4 ==> P 2 4 <=> T:

237 / 315

Conditional Rewriting Pitfalls III

let’s look in detail why SIMP CONV did not make progress above

> set_trace "simplifier" 2;

> SIMP_CONV arith_ss [my_thm] ‘‘P 2 3 /\ P 3 4 ==> P 2 4‘‘

[468000]: more context: |- !x y z. P x y ==> P y z ==> P x z

[468000]: New rewrite: |- (?y. P x y /\ P y z) ==> (P x z <=> T)

...

[584000]: more context: [.] |- P 2 3 /\ P 3 4

[584000]: New rewrite: [.] |- P 2 3 <=> T

[584000]: New rewrite: [.] |- P 3 4 <=> T

[588000]: rewriting P 2 4 with |- (?y. P x y /\ P y z) ==> (P x z <=> T)

[588000]: trying to solve: ?y. P 2 y /\ P y 4

[588000]: rewriting P 2 y with |- (?y. P x y /\ P y z) ==> (P x z <=> T)

[592000]: trying to solve: ?y’. P 2 y’ /\ P y’ y

...

[596000]: looping - cut

...

[608000]: looping - stack limit reached

...

[640000]: couldn’t solve: ?y. P 2 y /\ P y 4


238 / 315

Conditional vs. Unconditional Rewrite Rules

conditional rewrite rules are often much more powerful

however, Rewrite lib does not support them

for this reason there are often two versions of rewrite theorems

drop example

DROP LENGTH NIL is a useful rewrite rule:|- !l. DROP (LENGTH l) l = []

in proofs, one needs to be careful though to preserve exactly this formI one should not (partly) evaluate LENGTH l or modify l somehow

with the conditional rewrite rule DROP LENGTH TOO LONG one doesnot need to be as careful|- !l n. LENGTH l <= n ==> (DROP n l = [])

I the simplifier can use simplify the precondition using information aboutLENGTH and even arithmetic decision procedures

239 / 315

Special Rewrite Forms

some theorems given in the list of rewrites to the simplifier are usedfor special purposes

there are marking functions that mark these theoremsI Once : thm -> thm use given theorem at most onceI Ntimes : thm -> int -> thm use given theorem at most the given

number of timesI AC : thm -> thm -> thm use given associativity and commutativity

theorems for AC rewritingI Cong : thm -> thm use given theorem as a congruence rule

these special forms are easy ways to add this information to a simpset

it can be directly set in a simpset as well

240 / 315

Example Once

> SIMP_CONV pure_ss [Once ADD_COMM] ‘‘a + b = c + d‘‘

val it = |- (a + b = c + d) <=> (b + a = c + d)

> SIMP_CONV pure_ss [Ntimes ADD_COMM 2] ‘‘a + b = c + d‘‘

val it = |- (a + b = c + d) <=> (a + b = c + d)

> SIMP_CONV pure_ss [ADD_COMM] ‘‘a + b = c + d‘‘


> ONCE_REWRITE_CONV [ADD_COMM] ‘‘a + b = c + d‘‘

val it = |- (a + b = c + d) <=> (b + a = d + c)

> REWRITE_CONV [ADD_COMM] ‘‘a + b = c + d‘‘

... diverges ...

241 / 315

Stateful Simpset

the simpset srw ss() is maintained by the systemI it is automatically extended by new type-definitionsI theories can extend it via export rewritesI libs can augment it via augment srw ss

the stateful simpset contains many rewrites

it is very powerful and easy to use

Example> SIMP_CONV (srw_ss()) [] ‘‘case [] of [] => (2 + 4)‘‘

val it = |- (case [] of [] => 2 + 4 | v::v1 => ARB) = 6

242 / 315

Discussion on Stateful Simpset

the stateful simpset is very powerful and easy to use

however, results are hard to predict

proofs using it unwisely are hard to maintain

the stateful simpset can expand too muchI bigger, harder to read proof statesI high level arguments become hard to see

whether to use the stateful simpset depends on personal proof style

I advise to not use srw ss at the beginning

once you got a good intuition on how the simplifier works, make yourown choice

243 / 315

Adding Own Conversions

it is complicated to add arbitrary decision procedures to a simpset

however, adding simple conversions is straightforward

a conversion is described by a stdconvdata recordtype stdconvdata = {

name: string, (* name for debugging *)

pats: term list, (* list of patterns, when to try conv *)

conv: conv (* the conversion *)

}

use std conv ss to create simpset-fragement

Exampleval WORD_ADD_ss =

simpLib.std_conv_ss

{conv = CHANGED_CONV WORD_ADD_CANON_CONV,

name = "WORD_ADD_CANON_CONV",

pats = [‘‘words$word_add (w:’a word) y‘‘]}

244 / 315

Summary Simplifier

the simplifier is HOL’s main workhorse for automation

it is very powerful

conditional rewriting very powerfulI here only simple examples were presentedI experiment with it to get a feeling

many advanced features not discussed here at allI using congruence rulesI writing own decision proceduresI rewriting with respect to arbitrary congruence relations

Warning

The simplifier is very powerful. Make sure you understand it and are incontrol when using it. Otherwise your proofs easily become lengthy,convoluted and hard to maintain.

245 / 315

Part XIV

Advanced Definition Principles

Relations

a relation is a function from some arguments to bool

the following example types are all types of relations:I : ’a -> ’a -> boolI : ’a -> ’b -> boolI : ’a -> ’b -> ’c -> ’d -> boolI : (’a # ’b # ’c) -> boolI : boolI : ’a -> bool

relations are closely related to setsI R a b c <=> (a, b, c) IN {(a, b, c) | R a b c}I (a, b, c) IN S <=> (\a b c. (a, b, c) IN S) a b c

247 / 315

Relations II

relations are often defined by a set of rules

Definition of Reflexive-Transitive Closure

The transitive reflexive closure of a relation R : ’a -> ’a ->

bool can be defined as the least relation RTC R that satisfies thefollowing rules:

R x y

RTC R x y RTC R x x

RTC R x y RTC R y z

RTC R x z

if the rules are monoton, a least and a greatest fix point exists(Knaster-Tarski theorem)

least fixpoints give rise to inductive relations

greatest fixpoints give rise to coinductive relations

248 / 315

(Co)inductive Relations in HOL

(Co)IndDefLib provides infrastructure for defining (co)inductiverelations

given a set of rules Hol (co)reln defines (co)inductive relations

3 theorems are returned and stored in current theoryI a rules theorem — it states that the defined constant satisfies the rulesI a cases theorem — this is an equational form of the rules showing that

the defined relation is indeed a fixpointI a (co)induction theorem

additionally a strong (co)induction theorem is stored in current theory

249 / 315

Example: Transitive Reflexive Closure

> val (RTC_REL_rules, RTC_REL_ind, RTC_REL_cases) = Hol_reln ‘

(!x y. R x y ==> RTC_REL R x y) /\

(!x. RTC_REL R x x) /\

(!x y z. RTC_REL R x y /\ RTC_REL R y z ==> RTC_REL R x z)‘

val RTC_REL_rules = |- !R.

(!x y. R x y ==> RTC_REL R x y) /\ (!x. RTC_REL R x x) /\

(!x y z. RTC_REL R x y /\ RTC_REL R y z ==> RTC_REL R x z)

val RTC_REL_cases = |- !R a0 a1.

RTC_REL R a0 a1 <=>

(R a0 a1 \/ (a1 = a0) \/ ?y. RTC_REL R a0 y /\ RTC_REL R y a1)

250 / 315

Example: Transitive Reflexive Closure II

val RTC_REL_ind = |- !R RTC_REL’.

((!x y. R x y ==> RTC_REL’ x y) /\ (!x. RTC_REL’ x x) /\

(!x y z. RTC_REL’ x y /\ RTC_REL’ y z ==> RTC_REL’ x z)) ==>

(!a0 a1. RTC_REL R a0 a1 ==> RTC_REL’ a0 a1)

> val RTC_REL_strongind = DB.fetch "-" "RTC_REL_strongind"

val RTC_REL_strongind = |- !R RTC_REL’.

(!x y. R x y ==> RTC_REL’ x y) /\ (!x. RTC_REL’ x x) /\

(!x y z.

RTC_REL R x y /\ RTC_REL’ x y /\ RTC_REL R y z /\

RTC_REL’ y z ==>

RTC_REL’ x z) ==>

( !a0 a1. RTC_REL R a0 a1 ==> RTC_REL’ a0 a1)

251 / 315

Example: EVEN

> val (EVEN_REL_rules, EVEN_REL_ind, EVEN_REL_cases) = Hol_reln

‘(EVEN_REL 0) /\ (!n. EVEN_REL n ==> (EVEN_REL (n + 2)))‘;

val EVEN_REL_cases =

|- !a0. EVEN_REL a0 <=> (a0 = 0) \/ ?n. (a0 = n + 2) /\ EVEN_REL n

val EVEN_REL_rules =

|- EVEN_REL 0 /\ !n. EVEN_REL n ==> EVEN_REL (n + 2)

val EVEN_REL_ind = |- !EVEN_REL’.

(EVEN_REL’ 0 /\ (!n. EVEN_REL’ n ==> EVEN_REL’ (n + 2))) ==>

(!a0. EVEN_REL a0 ==> EVEN_REL’ a0)

notice that in this example there is exactly one fixpoint

therefore, for these rules the inductive and coinductive relationcoincide

252 / 315

Example: Dummy Relations

> val (DF_rules, DF_ind, DF_cases) = Hol_reln

‘(!n. DF (n+1) ==> (DF n))‘

> val (DT_rules, DT_coind, DT_cases) = Hol_coreln

‘(!n. DT (n+1) ==> (DT n))‘

val DT_coind =

|- !DT’. (!a0. DT’ a0 ==> DT’ (a0 + 1)) ==> !a0. DT’ a0 ==> DT a0

val DF_ind =

|- !DF’. (!n. DF’ (n + 1) ==> DF’ n) ==> !a0. DF a0 ==> DF’ a0

val DT_cases = |- !a0. DT a0 <=> DT (a0 + 1):

val DF_cases = |- !a0. DF a0 <=> DF (a0 + 1):

notice that the definitions of DT and DF look like a non-terminatingrecursive definition

DT is always true, i. e. |- !n. DT n

DF is always false, i. e. |- !n. ~(DF n)

253 / 315

Quotient Types

quotientLib allows to define types as quotients of existing typeswith respect to partial equivalence relation

each equivalence class becomes a value of the new type

partiality allows ignoring certain values of original type

quotientLib allows to lift definitions and lemmata as well

details are technical and won’t be presented here

254 / 315

Quotient Types Example

let’s assume we have an implementation of finite sets of numbers asbinary trees with

I type binsetI binary tree invariant WF BINSET : binset -> boolI constant empty binsetI add and member functions add : num -> binset -> binset,

mem : binset -> num -> bool

we can define a partial equivalence relation bybinset equiv b1 b2 := (

WF BINSET b1 /\ WF BINSET b2 /\

(!n. mem b1 n <=> mem b2 n))

this allows defining a quotient type of sets of numbers

functions empty binset, add and mem as well as lemmata aboutthem can be lifted automatically

255 / 315

Quotient Types Summary

quotient types are sometimes very usefulI e. g. rational numbers are defined as a quotient type

there is powerful infrastructure for them

many tasks are automated

however, the details are technical and won’t be discussed here

256 / 315

Pattern Matching / Case Expressions

pattern matching ubiquitous in functional programming

pattern matching is a powerful technique

it helps to write concise, readable definitions

very handy and frequently used for interactive theorem proving

however, it is not directly supported by HOL’s logic

representations in HOLI sets of equations as produced by DefineI decision trees (printed as case-expressions)

257 / 315

TFL / Define

we have already used top-level pattern matches with the TFL package

Define is able to handle themI all the semantic complexity is taken care ofI no special syntax or functions remainI no special rewrite rules, reasoning tools needed afterwards

Define produces a set of equations

this is the recommended way of using pattern matching in HOL

Example> val ZIP_def = Define ‘(ZIP (x::xs) (y::ys) = (x,y)::(ZIP xs ys)) /\

(ZIP [] [] = [])‘

val ZIP_def = |- (!ys y xs x. ZIP (x::xs) (y::ys) = (x,y)::ZIP xs ys) /\

(ZIP [] [] = [])

258 / 315

Case Expressions

sometimes one does not want to use this compilation by TFLI one wants to use pattern-matches somewhere nested in a termI one might not want to introduce a new constantI one might want to avoid using TFL for technical reasons

in such situations, case-expressions can be used

their syntax is similar to the syntax used by SML

Example> val ZIP_def = Define ‘ZIP xs ys = case (xs, ys) of

(x::xs, y::ys) => (x,y)::(ZIP xs ys)

| ([], []) => []‘

val ZIP_def = |- !ys xs. ZIP xs ys =

case (xs,ys) of

([],[]) => []

| ([],v4::v5) => ARB

| (x::xs’,[]) => ARB

| (x::xs’,y::ys’) => (x,y)::ZIP xs’ ys’

259 / 315

Case Expressions II

the datatype package defines case-constants for each datatype

the parser contains a pattern compilation algorithm

case-expressions are by the parser compiled to decision trees usingcase-constants

pretty printer prints these decision trees as case-expressions again

Exampleval ZIP_def = |- !ys xs. ZIP xs ys =

pair_CASE (xs,ys)

(\v v1.

list_CASE v (list_CASE v1 [] (\v4 v5. ARB))

(\x xs’. list_CASE v1 ARB (\y ys’. (x,y)::ZIP xs’ ys’))):

260 / 315

Case Expression Issues

using case expressions feels very natural to functional programmers

case-expressions allow concise, well-readable definitions

however, there are also many drawbacks

there is large, complicated code in the parser and pretty printerI this is outside the kernelI parsing a pretty-printed term can result in a non α-equivalent oneI there are bugs in this code (see e. g. Issue #416 reported 8 May 2017)

the results are hard to predictI heuristics involved in creating decision treeI however, it is beneficial that proofs follow this internal, volatile

structure

261 / 315

Case Expression Issues II

technical issuesI it is tricky to reason about decision treesI rewrite rules about case-constants needs to be fetched from TypeBase

F alternative srw ss often does more than wanted

I partially evaluated decision-trees are not pretty printed nicely any more

underspecified functionsI decision trees are exhaustiveI they list underspecified cases explicitly with value ARBI this can be lengthyI Define in contrast hides underspecified cases

262 / 315

Case Expression Example I

Partial Proof Scriptval _ = prove (‘‘!l1 l2.

(LENGTH l1 = LENGTH l2) ==>

((ZIP l1 l2 = []) <=> ((l1 = []) /\ (l2 = [])))‘‘,

ONCE_REWRITE_TAC [ZIP_def]

Current Goal!l1 l2.


(((case (l1,l2) of

([],[]) => []

| ([],v4::v5) => ARB

| (x::xs’,[]) => ARB

| (x::xs’,y::ys’) => (x,y)::ZIP xs’ ys’) =

[]) <=> (l1 = []) /\ (l2 = []))

263 / 315

Case Expression Example IIa – partial evaluation



((ZIP l1 l2 = []) <=> ((l1 = []) /\ (l2 = [])))‘‘,

ONCE_REWRITE_TAC [ZIP_def] >>

REWRITE_TAC[pairTheory.pair_case_def] >> BETA_TAC

Current Goal!l1 l2.


(((case l1 of

[] => (case l2 of [] => [] | v4::v5 => ARB)

| x::xs’ => case l2 of [] => ARB | y::ys’ => (x,y)::ZIP xs’ ys’) =

[]) <=> (l1 = []) /\ (l2 = []))

264 / 315

Case Expression Example IIb — following tree structure



((ZIP l1 l2 = []) <=> ((l1 = []) /\ (l2 = [])))‘‘,

ONCE_REWRITE_TAC [ZIP_def] >>

Cases_on ‘l1‘ >| [

REWRITE_TAC[listTheory.list_case_def]

Current Goal!l2.

(LENGTH [] = LENGTH l2) ==>

(((case ([],l2) of

([],[]) => []

| ([],v4::v5) => ARB

| (x::xs’,[]) => ARB

| (x::xs’,y::ys’) => (x,y)::ZIP xs’ ys’) =

[]) <=> (l2 = []))

265 / 315

Case Expression Summary

case expressions are natural to functional programmers

they allow concise, readable definitions

however, fancy parser and pretty-printer neededI trustworthiness issuesI sanity check lemmata advisable

reasoning about case expressions can be tricky and lengthy

proofs about case expression often hard to maintain

therefore, use top-level pattern matching via Define if easily possible

266 / 315

Part XV

Maintainable Proofs

Motivation

proofs are hopefully still used in a few weeks, months or even years

often the environment changes slightly during the lifetime of a proofI your definitions change slightlyI your own lemmata change (e. g. become more general)I used libraries changeI HOL changes

F automation becomes more powerfulF rewrite rules in certain simpsets changeF definition packages produce slightly different theoremsF autogenerated variable-names changeF . . .

even if HOL and used libraries are stable, proofs often go throughseveral iterations

often they are adapted by someone else than the original author

therefore it is important that proofs are easily maintainable

268 / 315

Nice Properties of Proofs

maintainability is closely linked to other desirable properties of proofs

proofs should beI easily understandableI well-structuredI robust

F they should be able to cope with minor changes to environmentF if they fail they should do so at sensible points

I reusable

How can one write proofs with such properties?

as usual, there are no easy answers but plenty of good advice

I recommend following the advice of ProofStyle manual

parts of this advice as well as a few extra points are discussed in thefollowing

269 / 315

Formatting

format your proof such that it easily understandable

make the structure of the proof very clear

show clearly where subgoals start and stop

use indentation to mark proofs of subgoals

use empty lines to separate large proofs of subgoals

use comments where appropriate

270 / 315

Formatting Example I

Bad Example Term Formattingprove (‘‘!l1 l2. l1 <> [] ==> LENGTH l2 <

LENGTH (l1 ++ l2)‘‘,

...)

Good Example Term Formattingprove (‘‘!l1 l2. l1 <> [] ==>

(LENGTH l2 < LENGTH (l1 ++ l2))‘‘,

...)

271 / 315

Formatting Example II

Bad Example Subgoalsprove (‘‘!l1 l2. l1 <> [] ==> (LENGTH l2 < LENGTH (l1 ++ l2))‘‘,

Cases >>

REWRITE_TAC[] >>

REWRITE_TAC[listTheory.LENGTH, listTheory.LENGTH_APPEND] >>

REPEAT STRIP_TAC >>

DECIDE_TAC)

Improved Example Subgoals

At least show when a subgoal starts and ends

prove (‘‘!l1 l2. l1 <> [] ==> (LENGTH l2 < LENGTH (l1 ++ l2))‘‘,

Cases >> (

REWRITE_TAC[]

) >>


REPEAT STRIP_TAC >>

DECIDE_TAC)

272 / 315

Formatting Example II 2

Good Example Subgoals

Make sure REWRITE TAC is only applied to first subgoal and proof fails, ifit does not solve this subgoal.


Cases >- (

REWRITE_TAC[]

) >>


REPEAT STRIP_TAC >>

DECIDE_TAC)

273 / 315

Formatting Example II 3

Alternative Good Example Subgoals

Alternative good formatting using THENL


Cases >| [

REWRITE_TAC[],


REPEAT STRIP_TAC >>

DECIDE_TAC

])

Another Bad Example Subgoals

Bad formatting using THENL


Cases >| [REWRITE_TAC[],


REPEAT STRIP_TAC >> DECIDE_TAC])

274 / 315

Some basic advice

use semicoli after each declarationI if exception is raised during interactive processing (e. g. by a failing

proof), previous successful declarations are keptI it sometimes leads to better error messages in case of parsing errors

use plenty of parentheses to make structure very clear

don’t ignore parser warningsI especially warnings about multiple possible parse trees are likely to lead

to unstable proofsI understand why such warnings occur and make sure there is no problem

format your development wellI use indentationI use linebreaks at sensible pointsI don’t use overlong linesI . . .

don’t use open in middle of files

personal opinion: avoid unicode in source files

275 / 315

KISS and Premature Optimisation

follow standard design principlesI KISS principleI “premature optimization is the root of all evil” (Donald Knuth)

don’t try to be overly clever

simple proofs are preferable

proof-checking-speed mostly unimportant

conciseness not a value in itself but desirable if it helpsI readabilityI maintainability

abstraction is often desirable, but also has a priceI don’t use too complex, artificial definitions and lemmata

276 / 315

Too much abstraction

Too much abstraction Exampleval TOO_ABSTRACT_LEMMA = prove (‘‘

!(size :’a -> num) (P : ’a -> bool) (combine : ’a -> ’a -> ’a).

(!x. P x ==> (0 < size x)) /\

(!x1 x2. size x1 + size x2 <= size (combine x1 x2)) ==>

(!x1 x2. P x1 ==> (size x2 < size (combine x1 x2)))‘‘,

...)


some proof using ABSTRACT_LEMMA

)

277 / 315

Too clever tactics

a common mistake is to use too clever tacticsI intended to work on many (sub)goalsI using TRY and other fancy trial and error mechanismsI intended to replace multiple simple, clear tactics

typical case: a tactic containing TRY applied to many subgoals

it is often hard to see why such tactics work

if something goes wrong, they are hard to debug

general advice: don’t factor with tactics, instead use definitions andlemmata

278 / 315

Too Clever Tactics Example I

Bad Example Subgoalsprove (‘‘!l1 l2. l1 <> [] ==> (LENGTH l2 < LENGTH (l1 ++ l2))‘‘,

Cases >> (


REPEAT STRIP_TAC >>

DECIDE_TAC

))

Alternative Good Example Subgoals IIprove (‘‘!l1 l2. l1 <> [] ==> (LENGTH l2 < LENGTH (l1 ++ l2))‘‘,

Cases >> SIMP_TAC list_ss [])


Cases >| [

REWRITE_TAC[],


REPEAT STRIP_TAC >>

DECIDE_TAC

])

279 / 315

Too Clever Tactics Example II

Bad Exampleval oadd_def = Define ‘(oadd (SOME n1) (SOME n2) = (SOME (n1 + n2))) /\

(oadd _ _ = NONE)‘;

val osub_def = Define ‘(osub (SOME n1) (SOME n2) = (SOME (n1 - n2))) /\

(osub _ _ = NONE)‘;

val omul_def = Define ‘(omul (SOME n1) (SOME n2) = (SOME (n1 * n2))) /\

(omul _ _ = NONE)‘;

val onum_NONE_TAC =

Cases_on ‘o1‘ >> Cases_on ‘o2‘ >>

SIMP_TAC std_ss [oadd_def, osub_def, omul_def];

val oadd_NULL = prove (

‘‘!o1 o2. (oadd o1 o2 = NONE) <=> (o1 = NONE) \/ (o2 = NONE)‘‘,

onum_NONE_TAC);

val osub_NULL = prove (

‘‘!o1 o2. (osub o1 o2 = NONE) <=> (o1 = NONE) \/ (o2 = NONE)‘‘,

onum_NONE_TAC);

val omul_NULL = prove (

‘‘!o1 o2. (omul o1 o2 = NONE) <=> (o1 = NONE) \/ (o2 = NONE)‘‘,

onum_NONE_TAC);

280 / 315

Too Clever Tactics Example II

Good Exampleval obin_def = Define ‘(obin op (SOME n1) (SOME n2) = (SOME (op n1 n2))) /\

(obin _ _ _ = NONE)‘;

val oadd_def = Define ‘oadd = obin $+‘;val osub_def = Define ‘osub = obin $-‘;val omul_def = Define ‘omul = obin $*‘;

val obin_NULL = prove (

‘‘!op o1 o2. (obin op o1 o2 = NONE) <=> (o1 = NONE) \/ (o2 = NONE)‘‘,

Cases_on ‘o1‘ >> Cases_on ‘o2‘ >> SIMP_TAC std_ss [obin_def]);

val oadd_NULL = prove (

‘‘!o1 o2. (oadd o1 o2 = NONE) <=> (o1 = NONE) \/ (o2 = NONE)‘‘,

REWRITE_TAC[oadd_def, obin_NULL]);

val osub_NULL = prove (

‘‘!o1 o2. (osub o1 o2 = NONE) <=> (o1 = NONE) \/ (o2 = NONE)‘‘,

REWRITE_TAC[osub_def, obin_NULL]);

val omul_NULL = prove (

‘‘!o1 o2. (omul o1 o2 = NONE) <=> (o1 = NONE) \/ (o2 = NONE)‘‘,

REWRITE_TAC[omul_def, obin_NULL]);

281 / 315

Use many subgoals and lemmata

often it is beneficial to use subgoalsI they structure long proofs wellI they help keeping the proof state cleanI they mark clearly what one tries to proofI they provide points where proofs can break sensibly

general enough subgoals should become lemmataI this improves reusabilityI proof script for main lemma becomes shorterI proofs are disentangled

282 / 315

Subgoal Example

the following example is taken from exercise 5

we try to prove !l. IS WEAK SUBLIST FILTER l l

given are following definitions and lemmata

val FILTER_BY_BOOLS_def = Define ‘

FILTER_BY_BOOLS bl l = MAP SND (FILTER FST (ZIP (bl, l)))‘;

val IS_WEAK_SUBLIST_FILTER_def = Define ‘IS_WEAK_SUBLIST_FILTER l1 l2 =

?(bl : bool list). (LENGTH bl = LENGTH l1) /\ (l2 = FILTER_BY_BOOLS bl l1)‘;

val FILTER_BY_BOOLS_REWRITES = store_thm ("FILTER_BY_BOOLS_REWRITES",

‘‘(FILTER_BY_BOOLS [] [] = []) /\

(!b bl x xs. (FILTER_BY_BOOLS (b::bl) (x::xs) =

if b then x::(FILTER_BY_BOOLS bl xs) else FILTER_BY_BOOLS bl xs))‘‘,

REWRITE_TAC [FILTER_BY_BOOLS_def, ZIP, MAP, FILTER] >>

Cases_on ‘b‘ >> REWRITE_TAC [MAP]);

283 / 315

Subgoal Example II

First Versionval IS_WEAK_SUBLIST_FILTER_REFL = store_thm ("IS_WEAK_SUBLIST_FILTER_REFL",

‘‘!l. IS_WEAK_SUBLIST_FILTER l l‘‘,

REWRITE_TAC[IS_WEAK_SUBLIST_FILTER_def] >>

Induct_on ‘l‘ >- (

Q.EXISTS_TAC ‘[]‘ >>

SIMP_TAC list_ss [FILTER_BY_BOOLS_REWRITES]

) >>

FULL_SIMP_TAC std_ss [] >>

GEN_TAC >>

Q.EXISTS_TAC ‘T::bl‘ >>

ASM_SIMP_TAC list_ss [FILTER_BY_BOOLS_REWRITES])

the proof mixes properties of IS WEAK SUBLIST FILTER andproperties of FILTER BY BOOLS

it is hard to see what the main idea is

284 / 315

Subgoal Example III

the following proof separates the property of FILTER BY BOOLS as asubgoal

the main idea becomes clearer

Subgoal Versionval IS_WEAK_SUBLIST_FILTER_REFL = store_thm ("IS_WEAK_SUBLIST_FILTER_REFL",


GEN_TAC >>


‘FILTER_BY_BOOLS (REPLICATE (LENGTH l) T) l = l‘ suffices_by (

METIS_TAC[LENGTH_REPLICATE]

) >>

Induct_on ‘l‘ >> (

ASM_SIMP_TAC list_ss [FILTER_BY_BOOLS_REWRITES, REPLICATE]

))

285 / 315

Subgoal Example IV

the subgoal is general enough to justify a lemma

the structure becomes even cleaner

this improves reusability

Lemma Versionval FILTER_BY_BOOLS_REPL_T = store_thm ("FILTER_BY_BOOLS_REPL_T",

‘‘!l. FILTER_BY_BOOLS (REPLICATE (LENGTH l) T) l = l‘‘,

Induct >> ASM_REWRITE_TAC [REPLICATE, FILTER_BY_BOOLS_REWRITES, LENGTH]);

val IS_WEAK_SUBLIST_FILTER_REFL = store_thm ("IS_WEAK_SUBLIST_FILTER_REFL",


GEN_TAC >>


Q.EXISTS_TAC ‘REPLICATE (LENGTH l) T‘ >>

SIMP_TAC list_ss [FILTER_BY_BOOLS_REPL_T, LENGTH_REPLICATE])

286 / 315

Avoid Autogenerated Names

many HOL-tactics introduce new variable namesI InductI CasesI . . .

the new names are often very artificial

even worse, generated names might change in future

proof scripts using autogenerated names are thereforeI hard to readI potentially fragile

therefore rename variables after they have been introduced

HOL has multiple tactics supporting renaming

most useful is rename1 ‘pat‘, it searches for pattern and renamesvars accordingly

287 / 315

Autogenerated Names Example

Bad Exampleprove (‘‘!l. 1 < LENGTH l ==> (?x1 x2 l’. l = x1::x2::l’)‘‘,

GEN_TAC >>

Cases_on ‘l‘ >> SIMP_TAC list_ss [] >>

Cases_on ‘t‘ >> SIMP_TAC list_ss [])

Good Exampleprove (‘‘!l. 1 < LENGTH l ==> (?x1 x2 l’. l = x1::x2::l’)‘‘,

GEN_TAC >>

Cases_on ‘l‘ >> SIMP_TAC list_ss [] >>

rename1 ‘LENGTH l2‘ >>

Cases_on ‘l2‘ >> SIMP_TAC list_ss [])

Proof State before rename11 < SUC (LENGTH t) ==> ?x2 l’. t = x2::l’

Proof State after rename11 < SUC (LENGTH l2) ==> ?x2 l’. l2 = x2::l’

288 / 315

Part XVI

Overview of HOL 4

Overview of HOL 4

in this course we discussed the basics of HOL 4

you were encouraged to learn more on your own in exercises

there is a lot more to learn even after the end of the courseI many more librariesI proof toolsI existing formalisationsI ...

to really use HOL well, you should continue learning

to help getting started, a short overview is presented here

290 / 315

HOL Bare Source Directories

The following source directories are the very basis of HOL. They arerequired to build hol.bare.

src/portableML – common stuff for PolyML and MoscowML

src/prekernel

src/0 – Standard Kernel

src/logging-kernel – Logging Kernel

src/experimental-kernel – Experimental Kernel

src/postkernel

src/opentheory

src/parse

src/bool

src/1

src/proofman

291 / 315

HOL Basic Directories I

On top of hol.bare, there are many basic theories and tools. These areall required for building the main hol executable.

src/compute – fast ground term rewriting

src/HolSat – SAT solver interfaces

src/taut – propositional proofs using HolSat

src/marker – marking terms

src/q – parsing support

src/combin – combinators

src/lite – some simple lib with various stuff

src/refute – refutation prover, normal forms

src/metis – first order resolution prover

src/meson – first order model elimination prover

292 / 315

HOL Basic Directories II

src/simp – simplifier

src/holyhammer – tool for finding Metis proofs

src/tactictoe – machine learning tool for finding proofs

src/IndDef – (co)inductive relation definitions

src/basicProof – library containing proof tools

src/relation – relations and order theory

src/one – unit type theory

src/pair – tuples

src/sum – sum types

src/tfl – defining terminating functions

src/option – option types

293 / 315

HOL Basic Directories III

src/num – numbers and arithmetic

src/pred set – predicate sets

src/datatype – Datatype package

src/list – list theories

src/monad – monads

src/quantHeuristics – instantiating quantifiers

src/unwind – lib for unwinding structural hardware definitions

src/pattern matches – pattern matches alternative

src/bossLib – main HOL lib loaded at start

bossLib is one central library. It loads all basic theories and libraries andprovides convenient wrappers for the most common tools.

294 / 315

HOL More Theories I

Besides the basic libraries and theories that are required and loaded byhol, there are many more developements in HOL’s source directory.

src/sort – sorting lists

src/string – strings

src/TeX – exporting LaTeX code

src/res quan – restricted quantifiers

src/quotient – quotient type package

src/finite map – finite map theory

src/bag – bags a. k. a. multisets

src/n-bit – machine words

295 / 315

HOL More Theories II

src/ring – reasoning about rings

src/integer – integers

src/llists – lazy lists

src/path – finite and infinite paths through a transition system

src/patricia – efficient finite map implementations using trees

src/emit – emitting SML and OCaml code

src/search – traversal of graphs that may contain cycles

296 / 315

HOL More Theories III

src/rational – rational numbers

src/real – real numbers

src/complex – comples numbers

src/HolQbf – quantified boolean formulas

src/HolSmt – support for external SMT solvers

src/float – IEEE floating point numbers

src/floating-point – new version of IEEE floating point numbers

src/probability – some propability theory

src/temporal – shallow embedding of temporal logic

. . .

297 / 315

HOL Selected Examples I

The directory examples hosts many theories and libraries as well. There isnot always a clear distinction between an example and a development insrc. However, in general examples are more specialised and often larger.They are not required to follow HOL’s coding style as much asdevelopments in src.

examples/balanced bst – finite maps via balanced trees

examples/unification – (nominal) unification

examples/Crypto – various block ciphers

examples/elliptic – elliptic curve cryptography

examples/formal-languages – regular and context free formallanguages

examples/computability – basic computability theory

298 / 315

HOL Selected Examples II

examples/set-theory – axiomatic formalisation of set theory

examples/lambda – lambda calculus

examples/acl2 – connection to ACL2 prover

examples/theorem-prover – soundness proof of Milawa prover

examples/PSL – formalisation of PSL

examples/HolBdd – Binary Decision Diagrams

examples/HolCheck – basic model checker

examples/temporal deep – deep embedding of temporal logics andautomata

299 / 315

HOL Selected Examples III

examples/pgcl formalisation of pGCL (the Probabilistic GuardedCommand Language)

examples/dev – some hardware compilation

examples/STE – symbolic trajectory evalutation

examples/separationLogic – formalisation of separation logic

examples/ARM – formalisation of ARM architecture

examples/l3-machine-code – l3 language

examples/machine-code – compilers and decompilers tomachine-code

. . .

300 / 315

Concluding Remarks

some useful tools are a bit hidden in the HOL sources

moreover there are developments outside the main HOL 4 sourcesI CakeML https://cakeml.org

keep in touch with community to continue learning about HOL 4I mailing-list hol-infoI GitHub https://github.com/HOL-Theorem-Prover/HOLI https://hol-theorem-prover.org

if you continue using HOL, please consider sharing your work with thecommunity

301 / 315

https://cakeml.org

https://github.com/HOL-Theorem-Prover/HOL


Part XVII

Other Interactive Theorem Provers

Other Interactive Theorem Provers

at the beginning we very briefly discussed other theorem provers

now, with more knowledge about HOL 4 we can discuss other proversand their differences to HOL 4 in more detail

HOL 4 is a good system

it is very well suited for the tasks required by the PROSPER project

however, as always choose the right tool for your task

you might find a different prover more suitable for your needs

hopefully this course has enabled you to learn to use other provers onyour own without much trouble

303 / 315

HOL 4

based on classical higher order logic

logic is sweet spot between expressivity and automation

+ very trustworthy thanks to LCF approach

+ simple enough to understand easily

+ very easy to write custom proof tools, i. e. own automation

+ reasonably fast and efficient

decent automation

− no user-interface

− no special proof language

− no IDE, very little editor support

304 / 315

HOL Omega

mainly developed by Peter Homeierhttp://www.trustworthytools.com/

extension of HOL 4

+ logic extended by kinds+ allows type operator variables+ allows quantification over type variables

+ sometimes handy to e. g. model category theory

− not very actively developed

− HOL 4 usually sufficient and better supported

305 / 315

http://www.trustworthytools.com/

HOL Light

mainly developed by John Harrison

https://github.com/jrh13/hol-light

cleanup and reimplementation of HOL in OCaml

little legacy code

however, still very similar to HOL 4

+ much better automation for real analysis

+ cleaner

− OCaml introduces some minor issues with trustworthiness

− some other libs and tools of HOL 4 are missing

− HOL 4 has bigger community

306 / 315

https://github.com/jrh13/hol-light

Isabelle

Isabelle is also a descendant of LCF

originally developed by Larry Paulson in Cambridgehttps://www.cl.cam.ac.uk/research/hvg/Isabelle/

meanwhile also developed at TU Munich by Tobias Nipkowhttp://www21.in.tum.de

huge contributions by Markarius Wenzelhttp://sketis.net

Isabelle is a generic theorem prover

most used instantiation is Isabelle/HOL

other important one is Isabelle/ZF

307 / 315

https://www.cl.cam.ac.uk/research/hvg/Isabelle/

http://www21.in.tum.de

http://sketis.net

Isabelle / HOL - Logic

logic of Isabelle / HOL very similar to HOL’s logicI meta logic leads to meta level quantification and object level

quantification+ type classes+ powerful module system+ existential variablesI . . .

Isabelle is implemented using the LCF approach

it uses SML (Poly/ML)

many original tools (e. g. simplifier) similar to HOL

focused as HOL on equational reasoning

many tools are exchanged between HOL 4 and Isabelle / HOLI MetisI SledgehammerI . . .

308 / 315

Isabelle / HOL - Engineering

+ a lot of engineering went into Isabelle/HOL

+ it has a very nice GUII IDE based on JEditI special language for proofs (Isar)I good error messagesI . . .

+ very good automation

+ efficient implementations

+ many libraries (Archive of Formal Proof)

+ excellent code extraction

+ good documentation

+ easy for new users

309 / 315

Isabelle / HOL - Isar

special proof language Isar used

this allows to write declarative proofsI very high levelI easy to read by humansI very robustI very good tool supportI . . .

− however, tactical proofs are not easily accessible any moreI many intermediate goals need to be stated (declared) explicitlyI this can be very tediousI tools like verification condition generators are hard to use

310 / 315

Isabelle / HOL - Drawbacks

+ Isabelle/HOL provides excellent out of the box automation

+ it provides a very nice user interface

+ it is very nice for new users

− however, this comes at a priceI multiple layers added between kernel and userI hard to understand all these layersI a lot of knowledge is needed to write your own automation

− hard to write own automation

− Isabelle/HOL due to focus on declarative proofs not well suited fore. g. PROSPER

311 / 315

Coq

Coq is a proof assistant using the Calculus of Inductive Constructions

inspired by HOL 88

backward proofs as in HOL 4 used

however, very big differencesI much more powerful logicI dependent typesI constructive logicI not exactly following LCF approach

+ good user interface

+ very good community support

312 / 315

Coq - Logic

+ Coq’s logic is very powerful

+ it is very natural for mathematicians

+ very natural for language theory

+ allows reasoning about proofs

allows to add axioms as needed

as a result, Coq is used often toI formalise mathematicsI formalise programming language semanticsI reason about proof theory

313 / 315

Coq - Drawbacks

Coq’s power comes at a price

− there is not much automation

− proofs tend to be very longI they are very simple though

+ comparably easy to maintain

− Coq’s proof checking can be very slow

− when verifying programs or hardware you notice that HOL wasdesigned for this purpose

I need for obvious termination is tediousI missing automationI very slow

314 / 315

Summary

there are many good theorem provers out there

pick the right tool for your purpose

the HOL theorem prover is a good system for many purposes

for PROSPER it is a good choice

I encourage you to continue learning about HOL and interactivetheorem proving in general

if you have any questions feel free to contact me (Thomas Tuerk,email [email protected] or [email protected])

315 / 315

interactive theorem proving (itp) course - hol · interactive theorem proving (itp) course web...

Documents