The HOL Logic in ML

In this chapter, the concrete representation of the HOL logic is described. This involves describing the ML functions that comprise the interface to the logic (up to and including §Theorems); the quotation, parsing, and printing of logical types and terms §Quotations; the representation of theorems (§Theorems); the representation of theories (§Theories); the fundamental HOL theory bool (§bool); the primitive rules of inference (§Rules); and the methods for extending theories (throughout §Theories and also later in §bossLib). It is assumed that the reader is familiar with ML. If not, the introduction to ML in Getting Started with HOL in the TUTORIAL Part should be read first.

The HOL system provides the ML types hol_type and term which implement the types and terms of the HOL logic, as defined in §LOGIC. It also provides primitive ML functions for creating and manipulating values of these types. Upon this basis the HOL logic is implemented. The key idea of the HOL system, due to Robin Milner, and discussed in this chapter, is that theorems are represented as an abstract ML type whose only pre-defined values are axioms, and whose only operations are rules of inference. This means that the only way to construct theorems in HOL is to apply rules of inference to axioms or existing theorems; hence the consistency of the logic is preserved.

The purpose of the meta-language ML is to provide a programming environment in which to build theorem proving tools to assist in the construction of proofs. When the HOL system is built, a range of useful theorems is pre-proved and a set of tools pre-defined. The basic system thus offers a rich initial environment; users can further enrich it by implementing their own application specific tools and building their own application specific theories.

Types

The allowed types depend on which type constants have been declared in the current theory. See §Theories for details of how such declarations are made. There are two primitive constructor functions for values of type hol_type

    mk_vartype : string -> hol_type
    mk_thy_type :
      {Args: hol_type list, Thy: string, Tyop: string} -> hol_type

The function mk_vartype constructs a type variable with a given name; it gives a warning if the name is not an allowable type variable name (i.e., not an apostrophe (') followed by an alphanumeric). The function mk_thy_type constructs a compound type from a record {Tyop,Thy,Args} where Tyop is a string representing the name of the type operator, Thy is a string representing the theory that Tyop was declared in, and Args is a list of types representing the arguments to the operator. Function types $\sigma_1\to\sigma_2$ of the logic are represented in ML as though they were compound types $(\sigma_1,\sigma_2)$fun (in §LOGIC, however, function types were not regarded as compound types).

The evaluation of $$ \mathtt{mk\_thy\_type}\{\mathtt{Tyop} = \mathit{name},\, \mathtt{Thy} = \mathit{thyname},\, \mathtt{Args} = [\sigma_1, \cdots ,\sigma_n]\} $$ fails if

1. $\mathit{name}$ is not a type operator of theory $\mathit{thyname}$;
2. $\mathit{name}$ is a type operator of theory $\mathit{thyname}$, but its arity is not $n$;
3. $\mathit{thyname}$ is not the name of a theory in the current context.

For example, mk_thy_type{Tyop="bool", Thy="min", Args=[]} evaluates to an ML value of type hol_type representing the type bool.

Type constants may be bound to ML values and need not be repeatedly constructed: e.g., the type built by mk_thy_type{Tyop="bool", Thy="min", Args=[]} is abbreviated by the ML value bool. Similarly, function types may be constructed with the infix ML function -->. A few common type variables have been constructed and bound to ML identifers, e.g., alpha is the type variable 'a and beta is the type variable 'b. Thus the ML code alpha --> bool is equal to, but much more concise than

> mk_thy_type{Tyop="fun", Thy="min",
              Args=[mk_vartype "'a",
                    mk_thy_type{Tyop="bool", Thy="min", Args=[]}]}
val it = “:α -> bool”: hol_type

There are two primitive destructor functions for values of type hol_type:

    dest_vartype : hol_type -> string
    dest_thy_type :
      hol_type -> {Args: hol_type list, Thy: string, Tyop: string}

The function dest_vartype extracts the name of a type variable. A compound type is destructed by the function dest_thy_type into the name of the type operator, the name of the theory it was declared in, and a list of the argument types; dest_vartype and dest_thy_type are thus the inverses of mk_vartype and mk_thy_type, respectively. The destructors fail on arguments of the wrong form.

Terms

The four primitive kinds of terms of the logic are described in §LOGIC. The ML functions for manipulating these are described in this section. There are also derived terms that are described in §Derived Syntactic Forms.

At any time, the terms that may be constructed depends on which constants have been declared in the current theory. See §Theories for details of how such declarations are made.

There are four primitive constructor functions for values of type term:

    mk_var : string * hol_type -> term

mk_var($x$,$\sigma$) evaluates to a variable with name $x$ and type $\sigma$; it always succeeds.

    mk_thy_const :
      {Name: string, Thy: string, Ty: hol_type} -> term

mk_thy_const{Name =$\;\mathit{c}$,Thy =$\;\mathit{thyname}$,Ty =$\;\sigma$} evaluates to a term representing the constant with name $c$ and type $\sigma$; it fails if:

1. $c$ is not the name of a constant in the theory $\mathit{thyname}$;
2. $\sigma$ is not an instance of the generic type of $c$ (the generic type of a constant is established when the constant is defined; see §Theories).

    mk_comb : term * term -> term

mk_comb($t_1$,$t_2$) evaluates to a term representing the combination $t_1\ t_2$. It fails if:

1. the type of $t_1$ does not have the form $\sigma_1\to\sigma_2$;
2. the type of $t_1$ has the form $\sigma_1\to\sigma_2$, but the type of $t_2$ is not equal to $\sigma_1$.

    mk_abs : term * term -> term

mk_abs($x$,$t$) evaluates to a term representing the abstraction $\lambda x.\;t$; it fails if $x$ is not a variable.

There are four primitive destructor functions on terms:

    dest_var : term -> string * hol_type
    dest_thy_const :
      term -> {Name: string, Thy: string, Ty: hol_type}
    dest_comb : term -> term * term
    dest_abs : term -> term * term

These are the inverses of mk_var, mk_thy_const, mk_comb and mk_abs, respectively. They fail when applied to terms of the wrong form. Other useful destructor functions are rator, rand, bvar, body, lhs and rhs. See §REFERENCE for details.

The function

    type_of : term -> hol_type

returns the type of a term.

The function

    aconv : term -> term -> bool

implements the $\alpha$-convertibility test for $\lambda$-calculus terms. From the point of view of the HOL logic, $\alpha$-convertible terms are identical. A variety of other functions are available for performing $\beta$-reduction (beta_conv), $\eta$-reduction (eta_conv), substitution (subst), type instantiation (inst), computation of free variables (free_vars) and other common term operations. See §REFERENCE for more details.

Quotations, Parsing and Printing

It would be tedious to always have to input types and terms using the constructor functions. The HOL system, adapting the approach taken in LCF, has special quotation parsers for HOL types and terms which enable types and terms to be input using a fairly standard syntax. For example, the ML expression “:bool -> bool” denotes exactly the same value (of ML type hol_type) as

> mk_thy_type{
   Tyop = "fun",Thy = "min",
   Args = [
     mk_thy_type{Tyop = "bool", Thy = "min", Args = []},
     mk_thy_type{Tyop = "bool", Thy = "min", Args = []}
   ]}
val it = “:bool -> bool”: hol_type

and the expression “\x. x + 1” can be used instead of

> val numty = mk_thy_type{Tyop="num",Thy="num",Args=[]}
val numty = “:num”: hol_type
> val tedious = mk_abs
   (mk_var("x",numty),
    mk_comb(mk_comb (
      mk_thy_const {
        Name="+",Thy="arithmetic",Ty=numty --> numty --> numty
      },
      mk_var("x", numty)
      ),
      mk_comb(
        mk_thy_const{
          Name="NUMERAL", Thy="arithmetic", Ty=numty-->numty
        },
        mk_comb(
          mk_thy_const{
            Name="BIT1", Thy="arithmetic", Ty=numty-->numty
          },
          mk_thy_const{
            Name="ZERO", Thy="arithmetic", Ty=numty
          }))));
val tedious = “λx. x + 1”: term
> val parsed = ``\x. x + 1``;
val parsed = “λx. x + 1”: term
> aconv tedious parsed;
val it = true: bool

The HOL printer, which is integrated into the ML toplevel loop, also outputs types and terms using this syntax. Types are printed in the form “:$\mathit{type}$”. For example, the ML value of type hol_type representing $\alpha\to(\mathtt{ind}\to\mathtt{bool})$ would be printed out as below:

> let
    val ind_ty = mk_thy_type{Tyop="ind", Thy="min", Args=[]}
  in
    alpha --> (ind --> bool)
  end;
val it = “:α -> ind -> bool”: hol_type

Similarly, terms are printed in the form “$\mathit{term}$”, as in the session above printing the term “$\lambda$x. x + 1”. The leading colon is used to distinguish a type quotation from a term quotation: the former have the form “:$\cdots$” and the latter have the form “$\cdots$”.

Lexical Matters

The name of a HOL variable can be any ML string, but the quotation mechanism will parse only names that are identifiers (see §Identifiers below). Using non-identifiers as variable names is discouraged except in special circumstances (for example, when writing derived rules that generate variables with names that are guaranteed to be different from existing names). The name of a type variable in the HOL logic is formed by a prime/apostophe (') followed by an alphanumeric which itself contains no prime (see §Type Variable Names for examples). The name of a type constant or a term constant in the HOL logic can be any identifier, although some names are treated specially by the HOL parser and printer and should therefore be avoided.

Identifiers

In addition to special forms already present in the relevant grammar, a HOL identifier can be of two forms:

1. A finite sequence of alphanumerics starting with a letter. The underscore character is considered a digit character, and so can occur after an identifier's first letter. Greek characters (roughly Unicode range U+0370 to U+03FF) are also letters, except for $\lambda$~(U+03BB), which is treated as a symbol. HOL is case-sensitive: upper and lower case letters are considered to be different.

   Digits are the ASCII characters 0–9, the underscore character, and the Unicode subscripts and superscripts. The apostrophe character is special: it is not a letter, but can appear as part of an alphanumeric term identifier after the first letter. It must appear at the start of a type variable's name, and can also appear in the term context as a sequence of apostrophes on their own.

2. A symbolic identifier, i.e., a finite sequence formed by any combination of the ASCII symbols and the Unicode symbols. The basic ASCII symbols are

     #  ?  +  *  /  \  =  <  >  &  %  @  !  :  |  -  ^  `
   

   Use of the caret and back-tick characters is complicated by the fact that these characters have special meaning in the quotation mechanism; see §Quotations and Antiquotations. The dollar-sign ($) can also be used to form symbolic identifiers, but only in tokens where it is the only symbol. Thus, $, $$, and $$$ will all lex as identifiers.

   This restriction arises because of the other uses to which the dollar sign is put:

   • The dollar can be used as an escaping mechanism to remove special syntactic treatment of other identifiers. Thus, $+ and $if are effectively special forms of the tokens + and if respectively.
   • Finally, the dollar can also be used as a namespace separator character, giving unambiguous “long form” identifiers. For example, the token bool$COND is an unambiguous way of writing the COND constant from theory segment bool.

   The ASCII grouping symbols (braces, brackets, and parentheses), and the tilde (~), full-stop (.), comma (,), semi-colon (;) and hyphen (-) characters are called non-aggregating characters. Unless the desired token is already present in the grammar, these characters do not combine with themselves or other symbolic characters. Thus, the string "((" is viewed as two tokens, as are +; and "-+".

   Unicode code characters that are not letters or digits are regarded as symbolic. The non-aggregating Unicode characters are listed in the table below:

Table: Non-aggregating Unicode characters

3. A number is a string of one or more digits. If not the initial digit, an underscore can be used within the sequence to provide spacing. In order to distinguish different types of numbers a single character suffix may be used: for example 3n is a natural number while 3i is an integer. The 0x and 0b prefixes may also be used to change the base of the number. If the 0x prefix is used, hexadecimal ‘digits’ a–f and A–F can also be used. See also §Numerals.

Separators

The separators used by the HOL lexical analyser are (with ASCII codes in brackets):

space (32), carriage return (13), line feed (10), tab (^I, 9), form feed (^L, 12)

Special identifiers

The following valid identifiers are used by the grammar in the theory of booleans, and thus in all descendant theories as well. They should not be used as the name of a variable or a constant unless the user is very confident of their ability to mess with grammars.

   let  in  and  \  .  ;  =>  |  :  :=  with  updated_by  case  of

Type variable names

The name of a type variable in the HOL logic is a string beginning with a prime (') followed by an alphanumeric which itself contains no prime; for example all of the following are valid type variable names except for the last:

   'a   'b   'cat   'A11   'g_a_p   'f'oo

User tokens

In general, a HOL user has a great deal of freedom to create their own syntax, involving special tokens quite apart from variables and names for constants. For example, the if-then-else syntax for the conditional operator has special tokens (the “if”, “then” and “else”) that are not names for variables, nor constants (the underlying constant is actually called COND). In order to make sure that the operations of printing and parsing tokens are suitably inverse to each other, users should not create tokens that include whitespace, or the comment strings ((* and *)).

Literals

There are two classes of literal in HOL's term syntax: numbers and strings (which latter also includes a treatment of character literals). String literals are a convenient way to write large terms of type :char list; numerals are a convenient way to write values of type :num. In addition, both string and numeric literals can be injected into other types, so that, for example, it is possible to write 23 and have the system see it as a rational number. For more on these syntaxes, see §Numerals and §Strings.

Unicode vs ASCII

As the definition of parsed in the session above suggests, there are ASCII alternatives to the Unicode syntax. To repeat that definition:

> val parsed = ``\x. x + 1``;
val parsed = “λx. x + 1”: term

The backslash can be used instead of $\lambda$, and the `` symbol can be used instead of both the “ and ” symbols. Similarly, the logical connectives have both ASCII and Unicode forms (see §Grammar below), and either can be used (even within the same term), except that the begin- and end-delimiters must be of the same type. Usually the system prefers to print its output with the Unicode symbols. Thus:

> val t1 = ``!x y. x < y ==> ?z. x + z = y``;
val t1 = “∀x y. x < y ⇒ ∃z. x + z = y”: term

> val t2 = “∀x. ∃y. x < y ∧ y < x + 1”;
val t2 = “∀x. ∃y. x < y ∧ y < x + 1”: term

> val t3 = ``!x. ∃y. x < y /\ y < x + 1``;
val t3 = “∀x. ∃y. x < y ∧ y < x + 1”: term

§Parsing and Printing has more detailed information about the capabilities of the term and type parsing and printing facilities in the system. The remainder of this section provides a brief overview of what is possible.

Type Inference

Notice that there is no explicit type information in \x.x+1. The HOL type checker knows that 1 has type :num and + has type :num->(num->num). From this information it can infer that both occurrences of x in \x. x+1 could have type :num. This is not the only possible type assignment; for example, the first occurrence of x could have type bool and the second one have type :num. In that case there would be two different variables with name x, namely x$_{\mathtt{bool}}$ and x$_{\mathtt{num}}$, the second of which is free. However, the only way to construct a term with this second type assignment is by using the ML API, since the type checker uses the heuristic that all variables in a term with the same name have the same type. This is illustrated in the following session.

> ``x = (x = 1)``;
Exception- HOL_ERR
  (at Preterm.type-analysis: on line 1, characters 7-11:
       
Type error in function application.
  Function: $= x :num -> bool
  Argument: x = 1 :bool
  Reason: Attempt to unify different type operators: num$num a...
) raised

The desired value can be directly constructed by the primitive constructor functions:

> mk_eq
  (mk_var("x",bool),
   mk_eq(mk_var("x",numty),
         numSyntax.mk_numeral (Arbnum.fromString "1")));
val it = “x ⇔ x = 1”: term

The original quotation type checker was designed and implemented by Robin Milner. It employs heuristics like the one above to infer a sensible type for all variables occurring in a term.

At times, the user may want to control the exact type of a subterm. To support such functionality, types can be explicitly indicated by following any subterm with a colon and then a type. For example, “f(x:num):bool” will type check with f and x getting types :num->bool and :num respectively. This treatment of types within quotations is inherited from LCF.

Parentheses and Precedence

As with programming languages, the grammar governing the parsing of terms and types includes a notion of precedence. As with standard mathematics, for example, if we write 2 + 3 * 6, we expect this to denote the abstract syntax tree that groups the 3 and 6 together, giving a value of 20 for the term. Again as is usual, to adjust parses in the face of precedence one can use parentheses:

> EVAL “2 + 3 * 6”;
val it = ⊢ 2 + 3 * 6 = 20: thm

> EVAL “(2 + 3) * 6”;
val it = ⊢ (2 + 3) * 6 = 30: thm

Function application can be seen as an invisible high-precedence (or “tightly binding”) infix operator so that f x + 6 is an addition term, with the application of f to x being added to 6. This makes HOL syntax more like functional programming: one typically doesn't bother to write f(x) because f x suffices. Of course, sometimes arguments do need parentheses. For example, f(x + 6).

Finally, drawing inspiration from the Haskell programming language, HOL also supports the dollar-sign as a low precedence function application symbol. In this way, one has an option that can result in needing to write fewer parentheses:

> EVAL “FACT $ SUC $ 2 + 3”;
val it = ⊢ FACT (SUC (2 + 3)) = 720: thm

Note that, as above, the pretty-printer will always print terms with the “invisible” function application symbol and parentheses as necessary, even if they were input with dollar-signs.

Viewing the Grammar

The behaviour of the HOL quotation parser and printer is determined by the current grammar. Thus, a familiarity with the basic vocabulary of the standard collection of HOL theories is important if one is to use HOL effectively. One can examine the current grammar used by the parser with the functions type_grammar and term_grammar.

For example, in the following session, we see that the type grammar used in the startup context of HOL has the type operators fun, sum, prod, list, recspace, num, option, one, cv, ind, and bool:

> type_grammar();
val it =
   Rules:
     (50)   TY  ::=  TY -> TY [fun] (R-associative)
     (60)   TY  ::=  TY + TY [sum] (R-associative)
     (70)   TY  ::=  TY # TY [prod] (R-associative)
            TY  ::=  bool | cv | (TY, TY) fun | ind | TY itself |
                     TY list | num | one | TY option |
                     (TY, TY) prod | TY recspace | TY set |
                     (TY, TY) sum | unit
            TY  ::=  TY[TY] (array type)
   Type abbreviations:
     bool             = min$bool              
     cv               = cv$cv                 
     (α, β) fun       = (α, β) min$fun        
     ind              = min$ind               
     α itself         = α bool$itself         
     α list           = α list$list           
     num              = num$num               
     one              = one$one                [not printed]
     α option         = α option$option       
     (α, β) prod      = (α, β) pair$prod      
     α recspace       = α ind_type$recspace   
     α set            = (α, min$bool) min$fun  [not printed]
     (α, β) sum       = (α, β) sum$sum        
     unit             = one$one               :
   type_grammar.grammar

Also, fun, sum, and prod have infix notation (->), (+), and (#), respectively, with different binding strengths: # (with 70) binds stronger than + (60), which binds stronger than -> (50). All postfix type operators bind more strongly than the infixes.

The next session shows the (abbreviated) output from invoking the term_grammar function in the startup HOL environment. The deleted output includes more rules, a listing of all constants known to the system, including prefix operators, and a list of all overloadings currrently in force. The grammar rules shown include precedence levels, concrete syntax, and how various forms map to actual names (e.g., if-then-else maps to the name COND, and ⇒ maps to actual name ==>).

> term_grammar();
[...Lines elided...]
                | TM "|->" TM  [  combinpp.leftarrow]
                | TM "⇎" TM  [<=/=>] | TM "<=/=>" TM  
                | TM "⇔" TM  [<=>] | TM "<=>" TM  
                    (non-associative)
   (200)  TM  ::= TM "⇨ᵣ" TM  [suspendimp] | TM "⇒" TM  [==>]
                | TM "==>" TM  
                    (R-associative)
   (300)  TM  ::= TM "∨" TM  [\/] | TM "\/" TM     (R-associative)
   (310)  TM  ::= TM ":>" TM     (L-associative)
   (320)  TM  ::= TM "=+" TM  [UPDATE]   (non-associative)
   (400)  TM  ::= TM "⅋ᵣ" TM  [resconj] | TM "∧" TM  [/\]
                | TM "/\" TM  
                    (R-associative)
   (425)  TM  ::= TM "refines" TM   | TM "partitions" TM  
                | TM "equiv_on" TM   | TM "∉" TM  [NOTIN]
                | TM "NOTIN" TM   | TM "∈" TM  [IN] | TM "IN" TM  
                    (non-associative)
   (450)  TM  ::= TM "≼" TM  [<<=] | TM "<<=" TM  
                | TM "PERMUTES" TM   | TM "HAS_SIZE" TM  
                | TM "⊂" TM  [PSUBSET] | TM "PSUBSET" TM  
                | TM "⊆" TM  [SUBSET] | TM "SUBSET" TM  
                | TM "≥" TM  [>=] | TM ">=" TM   | TM "≤" TM  [<=]
                | TM "<=" TM   | TM ">" TM   | TM "<" TM  
                | TM "⊆ᵣ" TM  [RSUBSET] | TM "RSUBSET" TM  
                | TM "≠" TM   | TM "<>" TM   | TM "=" TM  
[...Output elided...]

Namespace control

In order to provide convenience, the parser deals with overloading and ambiguity. Overloading of numeric literals is discussed in §Overloading of Arithmetic Operators, although any symbol may be overloaded, not just numerals. At times such flexibility is quite useful; however, it can happen that one wishes to explicitly designate a particular constant. In that case, the notation $\mathit{thy}$$$\mathit{const}$ may be used in the parser to designate the constant $\mathit{const}$ declared in theory $\mathit{thy}$. In the following example, the less-than operator is explicitly specified.

> “prim_rec$< x y”;
val it = “x < y”: term

Note how the < symbol is not treated as an infix by the parser when given in “fully-qualified” form. Syntactically, such tokens are never given special treatment by the parser of HOL's concrete syntax.

Ways to Construct Types and Terms

The table below shows ML expressions for various kinds of type quotations. The expressions in the same row are equivalent.

Table: Building Types via Quotations or ML

Equivalent ways of inputting the four primitive kinds of term are shown in the next table.

Table: Building Primitive Terms

The following shows a few of these in action:

> val c = mk_const("CONS",
                   mk_vartype("'a") -->
                   mk_type("list", [mk_vartype("'a")]) -->
                   “:'a list”)
val c = “CONS”: term

> dest_thy_const c;
val it = {Name = "CONS", Thy = "list", Ty = “:α -> α list -> α list”}:
   {Name: string, Thy: string, Ty: hol_type}

In addition to the kinds of terms in the tables above, the parser also supports the following syntactic abbreviations.

Table: Syntactic abbreviations

Theorems

In §LOGIC, the notion of deduction was introduced in terms of sequents, where a sequent is a pair whose second component is a formula being asserted (a conclusion), and whose first component is a set of formulas (hypotheses). Based on this was the notion of a deductive system: a set of pairs, whose second component is a sequent, and whose first component is a list of sequents. The concept of a sequent following from a list of sequents via a deductive system was then defined: a sequent follows from a list of sequents if the sequent is the last element of some chain of sequents, each of whose elements is either in the list, or itself follows from the list along with earlier elements of the chain, via the deductive system.

A notation for `follows from' was then introduced. That a sequent $(\{t_1,\dots,t_n\},\ t)$ follows from a set of sequents $\Delta$, via a deductive system 𝒟, is denoted by: $t_1,\dots,t_n\vdash_{𝒟,\Delta} t$. (It was noted that where either 𝒟 or Δ were clear by context, their mention could be omitted; and where the set of hypotheses was empty, its mention could be omitted.)

A sequent that follows from the empty set of sequents via a deductive system is called a \textit{theorem} of that deductive system. That is, a theorem is the last element of a proof (in the sense of §LOGIC) from the empty set of sequents. When a pair $(L,(Γ,t))$ belongs to a deductive system, and the list $L$ is empty, then the sequent $(\Gamma,t)$ is called an axiom. Any pair $(L,(Γ,t))$ belonging to a deductive system is called a primitive inference of the system, with hypotheses¹ $L$ and conclusion $(Γ,t)$.

A formula in the abstract is represented concretely in HOL by a term whose HOL type is :bool. Therefore, a term of type :bool is used to represent a member of the set of hypotheses of a sequent; and likewise to represent the conclusion of a sequent. Sets in this context are represented by an implementation of the ML signature HOLset supporting operations such as member and union.

A theorem in the abstract is represented concretely in the HOL system by a value with the ML abstract type thm. The type thm has a destructor function

    dest_thm : thm -> term list * term

which returns a pair consisting of a list of the hypotheses and the conclusion, respectively, of a theorem. The order of assumptions in the list should not be relied on. Using dest_thm, two further destructor functions are derived:

    hyp : thm -> term list
    concl : thm -> term

\noindent for extracting the hypothesis list and the conclusion, respectively, of a theorem. A theorem's hypotheses are also available in the set form with the function

    hypset : thm -> term set

The ML type thm does not have a primitive constructor function. In this way, the ML type system protects the HOL logic from the arbitrary and unrecorded construction of theorems, which would compromise the consistency of the logic. (Functions which return theorems as values, e.g., functions representing primitive inferences, are discussed in §Primitive Rules.)

It was mentioned in §LOGIC that the deductive system of HOL includes four axioms.² In that manual, the axioms were presented in abstract form. Concretely, axioms are just theorem values that are introduced through the use of the ML function new_axiom (see §Theory Operations below). For example, the axiom BOOL_CASES_AX mentioned in §LOGIC is printed in HOL as follows (where T and F are the HOL logic's constants representing truth and falsity, respectively):

> BOOL_CASES_AX;
val it = ⊢ ∀t. (t ⇔ T) ∨ (t ⇔ F): thm

Note the special print format, with the $\vdash$ notation used to indicate ML type thm status; as well as the absence of HOL quotation marks in the ML context.

The session below illustrates the use of the destructor functions:

> hyp BOOL_CASES_AX;
val it = []: term list

> concl BOOL_CASES_AX;
val it = “∀t. (t ⇔ T) ∨ (t ⇔ F)”: term

> type_of it;
val it = “:bool”: hol_type

In addition to the print conventions mentioned above, the printing of theorems prints hypotheses as periods (i.e., full stops or dots). The flag show_assums allows theorems to be printed with hypotheses shown in full. These points are illustrated with a theorem inferred, for example purposes, from another axiom mentioned in §LOGIC, SELECT_AX.

> val th = UNDISCH (SPEC_ALL SELECT_AX);
val th =  [.] ⊢ P ($@ P): thm

> show_assums := true;
val it = (): unit

> th;
val it =  [P x] ⊢ P ($@ P): thm

Primitive Rules of Inference of the HOL Logic

The primitive rules of inference of the logic were described abstractly in §LOGIC. The descriptions relied on meta-variables $t$, $t_1$, $t_2$, and so on. In the HOL logic, infinite families of primitive inferences are grouped together and thought of as single primitive inference schemes. Each family contains all the concrete instances of one particular inference ‘pattern’. These can be produced, in abstract form, by instantiating the meta-variables in LOGIC’s rules to concrete terms.

In HOL, primitive inference schemes are represented by ML functions that return theorems as values. That is, for particular HOL terms, the ML functions return the instance of the theorem at those terms. The ML functions are part of the ML abstract type thm: although thm has no primitive constructors, it has (eight) operations which return theorems as values: ASSUME, REFL, BETA_CONV, SUBST, ABS, INST_TYPE, DISCH and MP.

The ML functions that implement the primitive inference schemes in the HOL system are described below. The same notation is used here as in §LOGIC: hypotheses above a horizontal line and conclusion beneath. The machine-readable ASCII notation is used for the logical constants.

Assumption Introduction

    ASSUME : term -> thm

    ------------
       t |- t

ASSUME “$t$” evaluates to $t$ |- $t$. Failure occurs if $t$ is not of type bool.

Reflexivity

    REFL : term -> thm

    --------------
       |- t = t

REFL “$t$” evaluates to |- $t = t$. A call to REFL never fails.

Beta-Conversion

    BETA_CONV : term -> thm

    -----------------------------
       |- (λx. t₁)t₂ = t₁[t₂/x]

• where $t_1$[$t_2$/$x$] denotes the result of substituting $t_2$ for $x$ in $t_1$, with suitable renaming of variables to prevent free variables in $t_2$ becoming bound after substitution. The substitution $t_1[t_2/x]$ is always defined.

BETA_CONV “$(\lambda x.\;t_1)t_2$” evaluates to the theorem |- $(\lambda x.\;t_1)t_2 = t_1[t_2/x]$. Failure occurs if the argument to BETA_CONV is not a $\beta$-redex (i.e., is not of the form $(\lambda x.\;t_1)t_2$).

Substitution

    SUBST : (term,thm)Lib.subst -> term -> thm -> thm

       Γ₁ |- t1 = t1'   ...  Γₙ |- tn = tn'   Γ |- t[t1,...,tn]
    --------------------------------------------------------------
                Γ₁ ∪ ... ∪ Γₙ ∪ Γ |- t[t1',...tn']

• where $t[t_1,\ldots,t_n]$ denotes a term $t$ with some free occurrences of the terms $t_1$, $\dots$, $t_n$ singled out and $t[t'_1,\ldots,t'_n]$ denotes the result of simultaneously replacing each such occurrences of $t_i$ by $t'_i$ (for $1{\leq}i {\leq} n$), with suitable renaming of variables to prevent free variables in $t_i'$ becoming bound after substitution.

The first argument to SUBST is a list of what are effectively pairs in the widely used (τ₁,τ₂)Lib.subst ML type. Each element in these lists is a record of type {redex:τ₁,residue:τ₂} with the intention that the redex value is to be replaced by the residue value. Such values can be constructed with the infix arrow |->, so that, for example:

> 3 |-> "foo";
val it = {redex = 3, residue = "foo"}: {redex: int, residue: string}

In SUBST, the redex values are variables $x_i$ and the theorems are $\Gamma_i\vdash t_i = t'_i$. The second argument is a template term $t[x_1,\ldots,x_n]$ in which occurrences of the variable $x_i$ (where $1 \leq i\leq n$) are used to mark the places where substitutions with $\Gamma_i \vdash t_i = t'_i$ are to be done. Thus

  SUBST [“x1” |-> (Γ₁ |- t1 = t1'), ..., “xn” |-> (Γₙ |- tn = tn')]
        t[x1,...xn]
        (Γ |- t[t1,...tn])

returns ∪ᵢΓᵢ ∪ Γ|- t[t1',...,tn']. Failure occurs if:

1. any of the arguments are of the wrong form;
2. the type of $x_i$ is not equal to the type of $t_i$ for some $1\leq i\leq n$.

The following is a somewhat contrived example of using SUBST:

> val th1 = EVAL “1 + 1”;
val th1 = ⊢ 1 + 1 = 2: thm
> val th2 = EVAL “2 * 3”;
val th2 = ⊢ 2 * 3 = 6: thm

> val template = “x + y + x = 10”;
val template = “x + y + x = 10”: term

> val th = EVAL “(1 + 1) + (2 * 3) + (1 + 1)”
val th = ⊢ 1 + 1 + 2 * 3 + (1 + 1) = 10: thm

> val result = SUBST [“x:num” |-> th1, “y:num” |-> th2] template th
val result = ⊢ 2 + 6 + 2 = 10: thm

Abstraction

    ABS : term -> thm -> thm

          Γ |- t1 = t2
    --------------------------
      Γ |- (λx. t1) = (λx. t2)

• where x is not free in Γ.

ABS “x” (Γ |- t1 = t2) returns the theorem Γ |- (λx. t1) = (λx. t2). Failure occurs if x is not a variable, or x occurs free in any assumption in Γ.

Type Instantiation

    INST_TYPE : (hol_type, hol_type) Lib.subst -> thm -> thm

                          Γ |- t
    ---------------------------------------------------
      Γ[σ₁,...,σₙ/α₁,...,αₙ] |- t[σ₁,...,σₙ/α₁,...,αₙ]

• where $t[\sigma_1,\dots,\sigma_n/\alpha_1,\dots,\alpha_n]$ denotes the result of substituting (in parallel) the types $\sigma_1$ to $\sigma_n$ for the type variables $\alpha_1$ to $\alpha_n$ in term $t$. Similarly, $\Gamma[\sigma_1,\dots,\sigma_n/\alpha_1,\dots,\alpha_n]$ denotes the result of performing the same substitution to all of the hypotheses in the set $\Gamma$.

INST_TYPE[α₁ |-> σ₁,...,αₙ |-> σₙ] th returns the result of instantiating each occurrence of αᵢ in the theorem th to σᵢ (for $1 \leq \mathtt{i} \leq n$). Failure occurs if an αᵢ is not a type variable.

For example:

> show_types := true;
val it = (): unit
> INST_TYPE [“:α” |-> “:num”] listTheory.LENGTH;
val it =
   ⊢ LENGTH ([] :num list) = (0 :num) ∧
     ∀(h :num) (t :num list). LENGTH (h::t) = SUC (LENGTH t): thm

Discharging an Assumption

    DISCH : term -> thm -> thm

          Γ |- t₂
    ------------------------
      Γ - {t₁} |- t₁ ⇒ t₂

• Γ - {t₁} denotes the set obtained by removing t₁ from Γ (note that t₁ need not occur in Γ; in this case Γ - t₁ = Γ).

DISCH t₁ (Γ |- t₂) evaluates to the theorem Γ - {t₁} |- t₁ ⇒ t₂. DISCH fails if the term given as its first argument is not of type :bool.

Modus Ponens

    MP : thm -> thm -> thm

       Γ₁ |- t₁ ⇒ t₂       Γ₂ |- t₁
    ---------------------------------
          Γ₁ ∪ Γ₂ |- t₂

MP takes two theorems (in the order shown above) and returns the result of applying Modus Ponens; it fails if the arguments are not of the right form.

Oracles

HOL extends the LCF tradition by allowing the use of an oracle mechanism, enabling arbitrary formulas to become elements of the thm type. By use of this mechanism, HOL can utilize the results of arbitrary proof procedures. In spite of such liberalness, one can still make strong assertions about the security of ML objects of type thm.

To avoid unsoundness, a tag is attached to any theorem coming from an oracle. This tag is propagated through every inference that the theorem participates in (much as ordinary assumptions are propagated in the inference rule MP). If it happens that falsity becomes derived, the offending oracle can be found by examining the tags component of the theorem. A theorem proved without use of any oracle will have an empty tag, and can thus be considered to have been proved solely by deductive steps in the HOL logic.

A tagged theorem can be created via

    mk_oracle_thm : string -> term list * term -> thm

which directly creates the requested theorem and attaches the given tag to it. The tag is created with a call to

    read : string -> tag

As well as providing principled access to the results of external reasoners, tags are used to implement some useful ‘system’ operations on theorems. For example, one can directly create a theorem via the function mk_thm. The tag MK_THM gets attached to each theorem created with this call. This allows users to directly create useful theorems, e.g., to use as test data for derived rules of inference. Another tag is used to implement so-called ‘validity checking’ for tactics.

The tags in a theorem can be viewed by setting Globals.show_tags to true.

> Globals.show_tags := true;
val it = (): unit

> mk_thm([], Term `F`);
val it = [oracles: MK_THM] [axioms: ] [] ⊢ F: thm

There are three elements to the left of the turnstile in the fully printed representation of a theorem: the first two³ comprise the tags component and the third is the standard assumption list. The tag component of a theorem can be extracted by

    tag : thm -> tag

and pretty-printed by

    pp_tag : tag -> pretty

Theories

In §LOGIC a theory is described as a $4$-tuple

$$𝒯 = \langle \mathsf{Struc}_𝒯, \mathsf{Sig}_𝒯, \mathsf{Axioms}_𝒯, \mathsf{Theorems}_𝒯\rangle $$

where

1. $\mathsf{Struc}_𝒯$ is the type structure of 𝒯;
2. $\mathsf{Sig}_𝒯$ is the signature of 𝒯;
3. $\mathsf{Axioms}_𝒯$ is the set of axioms of 𝒯;
4. $\mathsf{Theorems}_𝒯$ is the set of theorems of 𝒯.

In the implementation of HOL, theories are structured hierarchically to represent sequences of extensions called segments of an initial theory called min. A theory segment is not really a logical concept, but rather a means of representing theories in the HOL system. Each segment records some types, constants, axioms and theorems, together with pointers to other segments called its parents. The theory represented by a segment is obtained by taking the union of all the types, constants, axioms and theorems in the segment, together with the types, constants, axioms and theorems in all the segments reachable by following pointers to parents. This collection of reachable segments is called the ancestry of the segment.

ML functions for theory operations

A typical piece of work with the HOL system consists in a number of sessions. In the first of these, a new theory, 𝒯 say, is created by importing some existing theory segments, making a number of definitions, and perhaps proving and storing some theorems in the current segment. Then the current segment (named $\mathit{name}$ say) is exported. The concrete result will be an ML module $\mathsf{name}$Theory whose contents is the current theory segment created during the session and whose ancestry represents the desired logical theory 𝒯. Subsequent work sessions can access the definitions and theorems of 𝒯 by importing $name$Theory; this avoids having to load the tools and replay the proofs that created $name$Theory in the first place.

The naming of data in theories is based on the names given to segments. Specifically an axiom, definition, specification or theorem is accessed by an ML long identifier $\mathit{thy}$Theory.$\mathit{name}$, where $\mathit{thy}$ is the name of the theory segment current when the item was declared and $\mathit{name}$ is a specific name supplied by the user (see the functions new_axiom, new_definition, below). Different items can have the same specific name if the associated segment is different. Thus each theory segment provides a separate namespace of ML bindings of HOL items.

Various additional pieces of information are stored in a theory segment, including the parsing status of the constants (e.g., whether they are infixes or binders).

Determining the Context

There is always a \emph{current theory} which is the theory represented by the current theory segment together with its ancestry. The name of the current theory segment is returned by the ML function:

    current_theory : unit -> string

When an interactive HOL session begins, some theories will already be in the logical context. The exact set of theories in context will vary. If hol --bare is used, then only min and bool will be loaded. When the hol executable is used, a richer context is loaded.

The exact set of theories loaded can be determined with the ancestry command.

    ancestry : string -> string list

This function provides a general mechanism for examining the structure of the theory hierarchy. The argument is the name of a theory (or "-" as an abbreviation for the current theory), to which ancestry will respond with a list of the argument's ancestors in the theory hierarchy.

> ancestry "-";
val it =
   ["ConseqConv", "quantHeuristics", "patternMatches", "ind_type",
    "divides", "While", "cv", "reduce", "one", "sum", "option",
    "quotient", "pair", "combin", "sat", "normalForms", "relation",
    "min", "bool", "marker", "num", "prim_rec", "arithmetic",
    "numeral", "basicSize", "numpair", "pred_set", "list",
    "rich_list", "indexedLists", "hol"]: string list

Creating a Theory Segment

A new theory segment is created by a call to new_theory.

    new_theory : string -> unit

This allocates a new ‘area’ where subsequent theory operations take effect.

A call to new_theory "$\mathit{name}$" fails if:

• $\mathit{name}$ is not an alphanumeric starting with a letter; or

• there is a theory already named $\mathit{name}$ in the ancestry of the current segment.

On startup, the current theory segment of HOL is named scratch, which is an empty theory, having a useful collection of theories in its ancestry. Typically, a user would begin by loading whatever extra logical context is required for the work at hand.

The current theory segment acts as a kind of scratchpad. Elements stored in the current segment may be overwritten by subsequent additions, or deleted outright. Any theory elements built from overwritten or deleted elements are held to be out-of-date, and will not be included in the theory when it is finally exported. Out-of-date constants and types are detected by the HOL printer, which will print them surrounded by odd-looking syntax to alert the user.

In contrast to the current segment, (proper) ancestor segments may not be altered.

Loading Prebuilt Theories

Since HOL theories are represented by ML modules, when one is working interactively, one can import an existing theory segment by importing the corresponding module.

    load : string -> unit

\noindent Executing load "$\mathit{name}$Theory" imports the first occurrence of $\mathit{name}$Theory to be found along the loadPath into the session. Any unloaded ancestors of $\mathit{name}$ will be loaded before loading of $\mathit{name}$Theory continues. Note that load can not be used in ML files that are to be compiled; it can only be used in the interactive system.

Adding to the Current Theory

The following ML functions add types and terms to the current theory segment. In typical usage, these functions will not be needed since higher-level definition facilities will invoke these as necessary. However, these functions can be useful for those writing proof tools and derived definition principles.

    new_type : string * int -> unit

Executing new_type("$\mathit{op}$", $n$) makes $\mathit{op}$ a new $n$-ary type operator in the current theory. If $\mathit{op}$ is not an allowed name for a type, a warning will be issued.

    new_constant : string * hol_type -> unit

Executing new_constant("$c$", $\sigma$) makes $c_{\sigma'}$ a new constant of the current theory, for all $c_{\sigma'}$ where $\sigma'$ is an instance of $\sigma$. The type $\sigma$ is called the generic type of $c$. If $c$ is not an allowed name for a constant, a warning will be issued.

    new_axiom : string * term -> thm

Executing new_axiom("$\mathit{name}$",$t$) declares the sequent ([],$t$) to be an axiom of the current theory with name $\mathit{name}$. Failure occurs if:

• the type of $t$ is not bool; or
• $t$ contains out-of-date constants or types, $i.e.$, constants or types that have been re-declared after $t$ was built.

Once a theorem has been proved, it can be saved with the function

    save_thm : string * thm -> thm

Evaluating save_thm("$\mathit{name}$",$\mathit{th}$) will save the theorem $\mathit{th}$ with name $\mathit{name}$ in the current theory segment. In addition, various tools can be primed to pay particular attention to saved theorems through the use of special attributes. Such attributes are indicated by appending the list of the attribute names to the $\mathit{name}$. Thus, to indicate the simp attribute (for which, see discussion of the stateful simpset in §Stateful Simpset, one can write

    save_thm("name[simp]", th)

Multiple attributes can be listed between the square brackets, separated by commas.

There are also attributes controlling the way in which a theorem is saved, rather than affecting possible consumers of that theorem. The first, local, is used to create theorems that will not be exported to disk, but which are important locally. Such local theorems can have other attributes attached to them, which will have their effect within the given session/script-file. The second, unlisted, makes the theorem more difficult to access. This is appropriate when the theorem is being saved for the consumption of particular tools (which fact might be indicated by the use of other attributes), but the theorem is otherwise uninteresting, and unlikely to be something that a user is going to want to stumble across when searching or surveying theories. Concretely: unlisted theorems do not appear in theory signature files (so: cannot be accessed with the xTheory.thm_name syntax); and unlisted theorems will not be returned as the results of searches made for theorems using the functions in the DB module.

Instead of using the ML function save_thm, a special Theorem syntax is available for use in script files. One can write

   Theorem name = th

to achieve the same effect as an SML declaration

   val name = save_thm("name", th);

Attributes can also be added; for example:

   Theorem name[simp] = th

If one wishes to prove a goal with a tactic (see Chapter 4), and store the resulting theorem, the combination of these actions can be achieved with the store_thm function:

    store_thm : string * term * tactic -> thm

A call to store_thm(name,$t$,tac) results in the application of tac to goal $t$. If the tactic is successful, the resulting theorem is saved under the name name, as before. Also as before, theorem attributes can be added to the name.

Finally, again for use in script files only, there is a Theorem syntax to replace store_thm, reducing the need to write the same name twice, and giving a cleaner appearance. One can write

   Theorem name[attr1,attr2,...]:
     ...goal statement...
   Proof
     ...tactic...
   QED

The goal statement in this form is not an arbitrary term value, but must use the surface syntax used by the system parser (see §Quotations, Parsing and Printing). For example:

   Theorem IMP_CLAUSE[simp]:
     !p. (p ==> p) <=> T
   Proof
     rpt strip_tac
   QED

(The tactic above is shown to illustrate the Proof/QED shape of the form rather than the proof itself; closing this goal will need a little more than rpt strip_tac.) Note further that the Proof and QED keywords must occur in the leftmost column of the script file so that the parser can know when the term and tactic arguments terminate.

Instead of writing Theorem foo[local,...], one can write Triviality foo[...]. NB: This form has been deprecated and will be removed in a future release.

The choice to use Theorem syntax, or to use store_thm or save_thm directly is a matter of users' aesthetic preference. But recall: if writing library code to prove and store theorems, the underlying store_thm must be used, as the special treatment of the Theorem keyword is only available in script files.

Exporting a Theory

Once a theory segment has been constructed, it can be written out to a file, which, after compilation, can be imported into future sessions.

    export_theory : unit -> unit

When export_theory is called, all out-of-date entities are removed from the current segment. Also, the parenthood of the theory is computed. The current theory segment is written to a file nameTheory.sml, and the file nameTheory.sig, which documents the contents of name, is also written. Notice that the exported theory is not compiled by HOL. That is left to an external tool, Holmake (see the section on Holmake), which maintains dependencies among collections of HOL theory segments.

ML functions for accessing theories

The arguments of ML type string to new_axiom, new_definition, etc., are the names of the corresponding axioms and definitions. These names are used when accessing theories with the functions axiom, definition, etc., described below.

The current theory can be extended by adding new parents, types, constants, axioms and definitions. Theories that are in the ancestry of the current theory cannot be extended in this way; they can be thought of as frozen.

There are various functions for loading the contents of theory files:

    parents : string -> string list
    types : string -> (string * int) list
    constants : string -> term list

The first argument is the name of a theory (which must be in the ancestry of the current theory segment); the result is a list of the components of the theory. The name of the current theory can be abbreviated by "-". For example, parents "-" returns the parents of the current theory.

In the case of types a list of name-arity pairs is returned. Individual axioms, definitions and theorems can be read from the current theory using the following ML functions:

    axiom : string -> thm
    definition : string -> thm
    theorem : string -> thm

The first argument is the user supplied name of the axiom, definition or theorem in the current theory. Further, a list of all of a theory's axioms, definitions and theorems can be retrieved with the ML functions:

    axioms : string -> (string * thm) list
    definitions : string -> (string * thm) list
    theorems : string -> (string * thm) list

The contents of the current theory can be printed in a readable format using the function print_theory.

Functions for creating definitional extensions

There are three kinds of definitional extensions: constant definitions, constant specifications and type definitions.

Constant Definitions

In §LOGIC a constant definition over a signature $\Sigma_{\Omega}$ is defined to be an equation, i.e., a formula of the form $c_{\sigma}=t_{\sigma}$, such that:

1. $c$ is not the name of any constant in $\Sigma_{\Omega}$;
2. $t_{\sigma}$ is a closed term in $\mathsf{Terms}_{\Sigma_{\Omega}}$;
3. all the type variables occurring in $t_{\sigma}$ occur in $\sigma$.

In HOL, definitions can be slightly more general than this, in that an equation: $$ c\ v_1\ \cdots\ v_n\ =\ t $$ is allowed to be a definition where $v_1$, $\dots$, $v_n$ are variable structures (i.e., tuples of distinct variables). Such an equation is logically equivalent to: $$ c\ =\ \lambda v_1\ \cdots\ v_n.\ t $$ which is a definition in the sense of §LOGIC if (i), (ii) and (iii) hold.

The following ML function creates a new definition in the current theory.

    new_definition : string * term -> thm

Evaluating new_definition("name", “$c\ v_1\ \cdots\ v_n\ =\ t$”) declares the sequent $(\{\},\ c = \lambda v_1\ \cdots\ v_n.\ t)$ to be a constant definition of the current theory. The name associated with the definition in this theory is name. Failure occurs if:

1. $t$ contains free variables that are not in any of the variable structures $v_1$, $\dots$, $v_n$ (this is equivalent to requiring $\lambda v_1\ \cdots\ v_n.\ t$ to be a closed term);
2. there is a type variable in $v_1$, $\dots$, $v_n$ or $t$ that does not occur in the type of $c$.

Constant Specifications

In §LOGIC a constant specification for a theory $\mathcal{T}$ is defined to be a pair: $$ \langle (c_1,\ldots,c_n),\ \forall {x_1}_{\sigma_1} \cdots {x_n}_{\sigma_n}.\ t_{\mathtt{bool}} \rangle $$ such that:

1. $c_1$, $\dots$, $c_n$ are distinct names;
2. $\forall {x_1}_{\sigma_1} \cdots {x_n}_{\sigma_n}.\ t_{\mathtt{bool}} \in \mathsf{Terms}_{\mathcal{T}}$;
3. $tyvars(\forall {x_1}_{\sigma_1} \cdots {x_n}_{\sigma_n}.\ t_{\mathtt{bool}}) \subseteq tyvars(\sigma_i)$ for $1 \leq i \leq n$;
4. $\exists {x_1}_{\sigma_1}\ \cdots\ {x_n}_{\sigma_n}.\ t \in \mathsf{Theorems}_{\mathcal{T}}$.

The following ML function is used to make constant specifications in the HOL system.

    new_specification : string * string list * thm -> thm

Evaluating:

   new_specification("name", ["c1", ..., "cn"],
                     |- ?x1 ... xn. t[x1, ..., xn])

simultaneously introduces new constants named $c_1$, $\dots$, $c_n$ satisfying the property: $$ \vdash t[c_1, \ldots, c_n] $$ This theorem is stored, with name name, as a definition in the current theory segment. A call to new_specification fails if:

1. the theorem argument has a non-empty assumption list;
2. there are free variables in the theorem argument;
3. $c_1$, $\dots$, $c_n$ are not distinct variables;
4. the type of some $c_i$ does not contain all the type variables which occur in the term \x1 ... xn. t[x1, ..., xn].

Type Definitions

In §LOGIC it is explained that defining a new type $(\alpha_1,\ldots,\alpha_n)\mathit{op}$ in a theory $\mathcal{T}$ consists of introducing $\mathit{op}$ as a new $n$-ary type operator and $$ \vdash \exists f_{(\alpha_1,\ldots,\alpha_n)\mathit{op} \to \sigma}.\ \mathsf{TyDef}\ p\ f $$ as a new axiom, where $p$ is a predicate characterizing a non-empty subset of an existing type $\sigma$. Formally, a type definition for a theory $\mathcal{T}$ is a 3-tuple $$ \langle \sigma,\ (\alpha_1,\ldots,\alpha_n)\mathit{op},\ p_{\sigma\to\mathtt{bool}} \rangle $$ where:

1. $\sigma \in \mathsf{Types}_{\mathcal{T}}$ and $tyvars(\sigma) \in \{\alpha_1, \ldots, \alpha_n\}$;
2. $\mathit{op}$ is not the name of a type constant in $\mathsf{Struc}_{\mathcal{T}}$;
3. $p \in \mathsf{Terms}_{\mathcal{T}}$ is a closed term of type $\sigma\to\mathtt{bool}$ and $tyvars(p) \subseteq \{\alpha_1, \ldots, \alpha_n\}$;
4. $\exists x_{\sigma}.\ p\ x \subseteq \mathsf{Theorems}_{\mathcal{T}}$.

The following ML function makes a type definition in the HOL system.

    new_type_definition : string * thm -> thm

If $t$ is a term of type $\sigma$->bool containing $n$ distinct type variables, then evaluating:

   new_type_definition("op", |- ?x. t x)

results in op being declared as a new $n$-ary type operator characterized by the definitional axiom:

   |- ?rep. TYPE_DEFINITION t rep

which is stored as a definition with the automatically generated name op_TY_DEF. The constant TYPE_DEFINITION is defined in the theory bool by:

   |- TYPE_DEFINITION (P:'a->bool) (rep:'b->'a) =
       (!x' x''. (rep x' = rep x'') ==> (x' = x'')) /\
       (!x. P x = (?x'. x = rep x'))

Executing new_type_definition("op", |- ?$x$. $t\ x$) fails if:

1. $t$ does not have a type of the form $\sigma$->bool.

Defining Bijections

The result of a type definition using new_type_definition is a theorem which asserts only the existence of a bijection from the type it defines to the corresponding subset of an existing type. To introduce constants that in fact denote such a bijection and its inverse, the following ML function is provided:

    define_new_type_bijections :
      {ABS: string, REP: string, name: string, tyax: thm} -> thm

This function takes a record {ABS, REP, name, tyax}. The tyax argument must be a definitional axiom of the form returned by new_type_definition. The name argument is the name under which the constant definition (a constant specification, in fact) made by define_new_type_bijections will be stored in the current theory segment, and the ABS and REP arguments are user-specified names for the two constants that are to be defined. These constants are defined so as to denote mutually inverse bijections between the defined type, whose definition is given by the supplied theorem, and the representing type of this defined type.

Evaluating:

  define_new_type_bijections
       {name="name", ABS="abs", REP="rep",
        tyax = |- ?rep:newty->ty. TYPE_DEFINITION P rep}

automatically defines two new constants abs:ty->newty and rep:ty->newty such that:

   |- (!a. abs(rep a) = a) /\ (!r. P r = (rep(abs r) = r))

This theorem, which is the defining property for the constants abs and rep, is stored under the name "name" in the current theory segment. It is also the value returned by define_new_type_bijections. The theorem states that abs is the left inverse of rep and — for values satisfying P — that rep is the left inverse of abs.

A call to define_new_type_bijections name abs rep th fails if:

1. th is not a theorem of the form returned by new_type_definition.

Properties of Type Bijections

The following ML functions are provided for proving that the bijections introduced by define_new_type_bijections are injective (one-to-one) and surjective (onto):

    prove_rep_fn_one_one : thm -> thm
    prove_rep_fn_onto : thm -> thm
    prove_abs_fn_one_one : thm -> thm
    prove_abs_fn_onto : thm -> thm

The theorem argument to each of these functions must be a theorem of the form returned by define_new_type_bijections:

   |- (!a. abs(rep a) = a) /\ (!r. P r = (rep(abs r) = r))

If th is a theorem of this form, then evaluating prove_rep_fn_one_one th proves that the function rep is one-to-one, and returns the theorem:

   |- !a a'. (rep a = rep a') = (a = a')

Likewise, prove_rep_fn_onto th proves that rep is onto the set of values that satisfy P:

   |- !r. P r = (?a. r = rep a)

Evaluating prove_abs_fn_one_one th proves that abs is one-to-one for values that satisfy P, and returns the theorem:

   |- !r r'. P r ==> P r' ==> ((abs r = abs r') = (r = r'))

And evaluating prove_abs_fn_onto th proves that abs is onto, returning the theorem:

   |- !a. ?r. (a = abs r) /\ P r

All four functions will fail if applied to any theorem that does not have the form of a theorem returned by define_new_type_bijections. None of these functions saves anything in the current theory.

1. Note that ‘hypotheses’ and ‘conclusion’ are also used for the components of sequents. ↩

2. This is a simplification: in fact the various axioms are an extension of the basic logic. ↩

3. Tags are also used for tracking the use of axioms in proofs. ↩

Derived Inference Rules

In this section, HOL proofs and theorems are made concrete. The notion of proof is defined abstractly in the manual §LOGIC: a proof of a sequent $(\Gamma,t)$ from a set of sequents $\Delta$ (with respect to a deductive system $\mathcal{D}$) was defined to be a chain of sequents culminating in $(\Gamma,t)$, such that every element of the chain either belongs to $\Delta$ or else follows from $\Delta$ and earlier elements of the chain by deduction. The notion of a theorem was also defined in §LOGIC: a theorem of a deductive system is a sequent that follows from the empty set of sequents by deduction; i.e., it is the last element of a proof in the deductive system from the empty set of sequents.

The deductive system of HOL was sketched in Section§Rules, where the eight families of primitive inferences making up the deductive system were specified by diagrams. It was explained that these families of inferences are represented in HOL via ML functions, and that theorems are represented by an ML abstract type called thm. The eight ML functions corresponding to the inferences are operations of the type thm, and each of the eight returns a value of type thm. It was explained that the type thm has primitive destructors, but no primitive constructor; and that, in that way, the logic is protected against the computation of theorems except by functions representing primitive inferences, or compositions of these.

Finally, the primitive HOL logic was supplemented by three primitive constants and four axioms, to form the basic logic. The primitive inferences, together with the primitive constants, the five axioms, and a collection of definitions, give a starting point for constructing proofs, and hence computing theorems. However, proving even the simplest theorems from this minimal basis costs considerable effort. The basis does not immediately provide the transitivity of equality, for example, or a means of universal quantification; both of these themselves have to be derived.

Simple Derivations

As an illustration of a proof in HOL, the following chain of theorems forms a proof (from the empty set, in the HOL deductive system), for the particular terms $\mathtt{t}_1$ and $\mathtt{t}_2$, both of HOL type :bool

1. $t_1 \Rightarrow t_2 \vdash t_1 \Rightarrow t_2$

2. $t_1\; |- t_1$

3. $t_1 \Rightarrow t_2, \; t_1 \vdash t_2$

That is, the third theorem follows from the first and second.

In the session below, the proof is performed in the HOL system, using the ML functions ASSUME and MP.

> show_assums := true;
val it = (): unit

> val th1 = ASSUME ``t1 ==> t2``
val th1 =  [t1 ⇒ t2] ⊢ t1 ⇒ t2: thm

> val th2 = ASSUME ``t1:bool``
val th2 =  [t1] ⊢ t1: thm

> MP th1 th2;
val it =  [t1, t1 ⇒ t2] ⊢ t2: thm

In the following, the Count.inferences function is used to count the number of primitive inferences performed in the course of applying the function to the argument. In the first invocation, this means that only the modus ponens step is counted. We create an artificial function to see the count of all three inference steps in the second interaction:

> Count.inferences (MP (ASSUME ``t1 ==> t2``)) (ASSUME ``t1:bool``);
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 1; Total: 1
val it =  [t1, t1 ⇒ t2] ⊢ t2: thm

> fun f () = MP (ASSUME ``t1 ==> t2``) (ASSUME ``t1:bool``);
val f = fn: unit -> thm

> Count.inferences f ();
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 3; Total: 3
val it =  [t1, t1 ⇒ t2] ⊢ t2: thm

Each of the three inference steps of the abstract proof corresponds to the application of an ML function in the performance of the proof in HOL; and each of the ML functions corresponds to a primitive inference of the deductive system.

It is worth emphasising that, in either case, every primitive inference in the proof chain is made, in the sense that for each inference, the corresponding ML function is evaluated. That is, HOL permits no short-cut around the necessity of performing complete proofs. The short-cut provided by derived inference rules (as implemented in ML) is around the necessity of specifying every step; something that would be impossible for a proof of any length. It can be seen from this that the derived rule, and its representation as an ML function, is essential to the HOL methodology; theorem proving would be otherwise impossible.

There are, of course, an infinite number of proofs of the form shown in the example that can be conducted in HOL: one for every pair of :bool-typed terms. Moreover, every time a theorem of the form

$$t_1 \Rightarrow \ t_2, \ t_1 \ \vdash \ t_2$$

is required, its proof must be constructed anew. To capture the general pattern of inference, an ML function can be written to implement an inference rule as a derivation from the primitive inferences. Abstractly, a derived inference rule is a rule that can be justified on the basis of the primitive inference rules (and/or the axioms). In the present case, the rule required undischarged assumptions. It is specified for HOL by

      Γ |- t1 ==> t2
     -----------------
      Γ ∪ {t1} |-  t2

This general rule is valid because, from a HOL theorem of the form $\Gamma \vdash t_1 \Rightarrow t_2$, the theorem $\Gamma \cup\{t_1\} \vdash t_2$ can be derived as in the specific instance above. The rule can be implemented in ML as a function (UNDISCH, say) that calls the appropriate sequence of primitive inferences. The ML definition of UNDISCH is simply

> fun UNDISCH th = MP th (ASSUME $ fst $ dest_imp $ concl th);
val UNDISCH = fn: thm -> thm

This code provides a function that maps a theorem to a theorem; that is, performs proofs in HOL. The following session illustrates the use of the derived rule on a consequence of the axiom IMP_ANTISYM_AX. (The inferences are counted. Assume that the printing of theorems has been adjusted as above and th is bound as shown below:

> val th = SPEC ``t2:bool`` $ SPEC ``t1:bool`` IMP_ANTISYM_AX;
val th =  [] ⊢ (t1 ⇒ t2) ⇒ (t2 ⇒ t1) ⇒ (t1 ⇔ t2): thm

> Count.inferences UNDISCH th;
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 2; Total: 2
val it =  [t1 ⇒ t2] ⊢ (t2 ⇒ t1) ⇒ (t1 ⇔ t2): thm

> Count.inferences UNDISCH it;
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 2; Total: 2
val it =  [t1 ⇒ t2, t2 ⇒ t1] ⊢ t1 ⇔ t2: thm

Each successful application of UNDISCH to a theorem invokes an application of ASSUME, followed by an application of MP; UNDISCH constructs the 2-step proof for any given theorem of the appropriate form. As can be seen, it relies on the class of ML functions that access HOL syntax: in particular, concl to produce the conclusion of the theorem, dest_imp to separate the implication, and the selector fst to choose the antecedent.

This particular example is very simple, but a derived inference rule can perform proofs of arbitrary length. It can also make use of previously defined rules. In this way, the normal inference patterns can be developed much more quickly and easily; transitivity, generalization, and so on, support the familiar patterns of inference.

A number of derived inference rules are pre-defined when the HOL system is entered (UNDISCH is one of the first). In Section, the abstract derivations are given for the pre-defined rules that reflect the more usual inference patterns of the predicate (and lambda) calculi. Like those shown, some of the pre-defined derived rules in HOL generate relatively short proofs. Others invoke thousands of primitive inferences, and clearly save a great deal of effort. Furthermore, rules can be defined by the user to make still larger steps, or to implement more specialized patterns.

All of the pre-defined derived rules in HOL are described in §REFERENCE.

Derivation of the Standard Rules

The HOL system provides all the standard introduction and elimination rules of the predicate calculus pre-defined as derived inferences. It is these derived rules, rather than the primitive rules, that one normally uses in practice. In this section, the derivations of some of the standard rules are given, in sequence. These derivations only use the axioms and definitions in the theory bool (see Section, the eight primitive inferences of the HOL logic, and inferences defined earlier in the sequence.

Theorems, in accordance with the definition given at the beginning of this chapter, are treated as rules without hypotheses; thus the derivation of a theorem resembles the derivation of a rule except in not having hypotheses. (The derivation of TRUTH, Section, is the only example given of this, but there are several others in HOL.) There are also some rules that are intrinsically more general than theorems. For example, for any two terms $t_1$ and $t_2$, the theorem $\vdash(\lambda{x}.t_1)t_2 = t_1[t_2/x]$ follows by the primitive rule BETA_CONV. The rule BETA_CONV returns a theorem for each pair of terms $t_1$ and $t_2$, and is therefore equivalent to an infinite family of theorems. No single theorem can be expressed in the HOL logic that is equivalent to BETA_CONV. See Chapter for further discussion of this point. Note that UNDISCH is not a rule of this sort, as it can, in fact, be expresed as a theorem.

For each derivation given below, there is an ML function definition in the HOL system that implements the derived rule as a procedure in ML. The actual implementation in the HOL system differs in some cases from the derivations given here, since the system code has been optimised for improved performance.

In addition, for reasons that are mostly historical, not all the inferences that are derived in terms of the abstract logic are actually derived in the current version of the HOL system. That is, there are currently a number of rules that are installed in the system on an “axiomatic” basis, all of which should be derived by explicit inference. These rules' status does not actually compromise the consistency of the logic. In effect, the existing HOL system has a deductive system more comprehensive than the one presented abstractly, but the model outlined in §LOGIC would easily extend to cover it. The derivations that follow consist of sequences of numbered steps each of which

1. is an axiom, or
2. is a hypothesis of the rule being derived, or
3. follows from preceding steps by a rule of inference (either primitive or previously derived).

Adding an assumption

   ADD_ASSUM : term -> thm -> thm

   Γ |- t
  ---------------
   Γ ∪ {t'} |- t

Undischarging

   UNDISCH : thm -> thm

   Γ |- t1 ==> t2
  ---------------
   Γ ∪ {t1} |- t2

Symmetry of equality

   SYM : thm -> thm

   Γ |- t1 = t2
  ---------------
   Γ |- t2 = t1

Transitivity of equality

   TRANS : thm -> thm -> thm

   Γ₁ |- t₁ = t₂ ,   Γ₂ |- t₂ = t3
  ---------------------------------
     Γ₁ ∪ Γ₂ |- t₁ = t3

Application of a term to a theorem

   AP_TERM : term -> thm -> thm

   Γ |- t₁ = t₂
  ------------------
   Γ |- t t₁ = t t₂

Application of a theorem to a term

   AP_THM : thm -> conv

   Γ |- t₁ = t₂
  ------------------
   Γ |- t₁ t = t₂ t

Modus Ponens for equality

   EQ_MP : thm -> thm -> thm

   Γ₁ |- t₁ = t₂ ,   Γ₂ |- t₁
  ---------------------------
     Γ₁ ∪ Γ₂ |- t₁ = t₂

Implication from equality

   EQ_IMP_RULE : thm -> thm * thm

          Γ |- t₁ = t₂
  ----------------------------------
   Γ |- t₁ ==> t₂ ,   Γ |- t₂ ==> t₁

$\mathsf{T}$-introduction

   TRUTH : thm

  ------------
     |- T

Equality-with-$\mathsf{T}$ elimination

   EQT_ELIM : thm -> thm

   Γ |- t = T
  -------------
   Γ |- t

Specialization ($\forall$-elimination)

   SPEC : term -> thm -> thm

   Γ |- ∀x. t
  -------------------
   Γ |- t[t'/x]

The notation $t[t'/x]$ denotes the result of replacing each free occurrence of $x$ in $t$ by $t'$. Renaming ensures that no free variables in a resulting occurrence of $t'$ will become bound.

Equality-with-$\mathsf{T}$\ introduction

   EQT_INTRO : thm -> thm

   Γ |- t
  -------------
   Γ |- t = T

Generalization ($\forall$-introduction)

   GEN : term -> thm -> thm

   Γ |- t
  ---------------
   Γ |- ∀x. t

Restriction: variable $x$ can not occur free in $\Gamma$.

Remark: The conventional notation for universal quantification, i.e. $\forall x.\; t$, is, in HOL, surface syntax for the underlying *term structure $\forall(\lambda{x}.\;t)$. This underlying structure is used to give clarity to some derivations in the following.

Simple $\alpha$-conversion

   SIMPLE_ALPHA

  ----------------------------------
   |- (λx₁. t) x₁ = (λx₂. t) x₂

Restriction: neither $x_1$ nor $x_2$ may occur free in $t$.

Remark: SIMPLE_ALPHA is not actually defined in the HOL system, as it is subsumed by other rules. It is included here just to support a later derivation in this section.

$\eta$-conversion

   ETA_CONV : conv

  -------------------
   |- (λx'. t x') = t

Restriction: $x'$ does not occur free in $t$.

Remark: we use $x'$ rather than just $x$ to motivate the use of SIMPLE_ALPHA in the derivation below.

Remark: In the HOL system, the type abbreviation conv = term -> thm describes SML functions that, when given a term $t_1$, return a theorem $\vdash t_1 = t_2$.

Extensionality

   EXT : thm -> thm

   Γ |- ∀x. t₁ x = t₂ x
  ----------------------
   Γ |- t₁ = t₂

Restriction: $x$ must not occur free in $t_1$ or $t_2$.

Choice introduction

   SELECT_INTRO : thm -> thm

   Γ |- t₁ t₂
  ----------------
   Γ |- t₁ (ε t₁)

Choice elimination

   SELECT_ELIM : thm -> term * thm -> thm


   Γ₁ |- t₁ (ε t₁) ,  Γ₂,t₁(v) |- t
  ----------------------------------
   Γ₁ ∪ Γ₂ |- t

Restriction: $v$ occurs nowhere except in the assumption $t_1\ v$ of the second hypothesis.

Existential introduction

   EXISTS : term * term -> thm -> thm

   Γ |- t₁[t₂]
  ---------------
   Γ |- ∃x. t₁[x]

Notation: $t_1[t_2]$ denotes a term $t_1$ with some free occurrences of $t_2$ singled out, and $t_1[x]$ denotes the result of replacing these occurrences of $t_1$ by $x$.

Existential elimination

   CHOOSE : term * thm -> thm -> thm

   Γ₁ |- ∃x. t[x] ,  Γ₂,t[v] |- t'
  ----------------------------------
   Γ₁ ∪ Γ₂ |- t'

Restrictions: $v$ must not be free in $Γ_1,Γ_2$ or $t$.

Applying a definition to one argument

Given an equation where the right-hand sde is a lambda-abstraction, one can derive an equation characterising the application of the function to a specified argument.

   RIGHT_BETA : thm -> thm

   Γ |- t = (λx. t₁ x) t₂
  ----------------------------------
   Γ |- t = t₁[t₂]

Applying a definition to multiple arguments

   RIGHT_LIST_BETA : thm -> thm

   Γ |- t = (λx₁…xₙ. t'[x₁,…,xₙ]) t₁ … tₙ
  -------------------------------------------------
   Γ |- t = t'[t₁,…,tₙ]

For readability, let $\mathcal{M} = \lambda{x_1\cdots x_n}.\; t'[x_1,\ldots,x_n]$ in the following:

Conjunction introduction

   CONJ : thm -> thm -> thm

   Γ₁ |- t₁  ,  Γ₂ |- t₂
  -----------------------
   Γ₁ ∪ Γ₂ |- t₁ ∧ t₂

Conjunction elimination

   CONJUNCT1 : thm -> thm
   CONJUNCT2 : thm -> thm

   Γ |- t₁ ∧ t₂
  -----------------------
   Γ |- t₁  ,  Γ |- t₂

Right disjunction introduction

   DISJ1 : thm -> conv

   Γ |- t₁
  --------------
   Γ |- t₁ ∨ t₂

Left disjunction introduction

   DISJ2 : term -> thm -> thm

   Γ |- t₂
  --------------
   Γ |- t₁ ∨ t₂

Disjunction elimination

   DISJ_CASES : thm -> thm -> thm -> thm

   Γ |- t₁ ∨ t₂  ,  Γ₁,t₁ |- t  ,  Γ₂,t₂ |- t
  --------------------------------------------
   Γ ∪ Γ₁ ∪ Γ₂ |- t

Classical contradiction rule

   CCONTR : term -> thm -> thm

   Γ, ¬t |- F
  ------------
   Γ |- t

Rewriting

Included in the set of derived inferences provided in HOL is a group of rules with complex definitions that do a limited amount of “automatic” theorem-proving in the form of rewriting. The ideas and implementation were originally developed by Milner and Wadsworth for Edinburgh LCF, and were later implemented more flexibly and efficiently by Paulson and Huet for Cambridge LCF. One basic rewriting rule, REWRITE_RULE, is illustrated here. Although HOL proofs typically feature more elaborate rewriters (such as SIMP_RULE, documented in Section), the underlying ideas are the same.

REWRITE_RULE uses a list of equational theorems (theorems whose conclusions can be regarded as having the form $t_1 = t_2$) to replace any subterms of an object theorem that “match” $t_1$ by the corresponding instance of $t_2$. The rule matches recursively and to any depth, until no more replacements can be made, using internally defined search, matching and instantiation algorithms. The validity of REWRITE_RULE rests ultimately on the primitive rules SUBST (for making the substitutions); INST_TYPE (for instantiating types); and the derived rules for generalization and specialization (see Section and Section for instantiating terms. The definition of REWRITE_RULE in ML also relies on a large number of general and HOL-oriented SML functions.

In practice, derived rules like REWRITE_RULE can play a central role in proofs, because they can perform a very large number of inferences which may happen in a complex and unpredictable order. This power is increased by the fact that any existing equational theorem can be supplied as a `rewrite rule', including a standard HOL set of pre-proved tautologies; and these rewrite rules can interact with each other in the rewriting process to transform the original theorem.

The application of REWRITE_RULE, in the session below, illustrates that replacements are made at all levels of the structure of a term. The example is a formula of natural number arithmetic: the infixes > and < are the usual “greater than” and “less than” relations, respectively, and SUC names the usual successor function on natural numbers. Use is made of the pre-existing definition of >, bound to arithmeticTheory.GREATER_DEF in SML (see §REFERENCE). The inference counting facility is used again, and the printing of theorems is adjusted as above.

> Count.inferences
    (REWRITE_RULE [arithmeticTheory.GREATER_DEF])
    (ASSUME ``SUC 3 > 0 /\ SUC 2 > 0 /\ SUC 1 > 0 /\ SUC 0 > 0``);
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 11; Total: 11
val it =  [.] ⊢ 0 < SUC 3 ∧ 0 < SUC 2 ∧ 0 < SUC 1 ∧ 0 < SUC 0:
   thm

Notice that rewriting equations can be extracted from universally quantified theorems. To construct the proof step-wise, with all of the instantiations, substitutions, uses of transitivity, etc, would be a lengthy process. The rewriting rules make it easy, and do so whilst still generating the entire chain of inferences.

Conversions

A conversion in HOL is a rule that maps a term to a theorem expressing the equality of that term to some other term. An example is the rule for $\beta$-conversion: $$ \mathtt{(}\backslash x\mathtt{.}\,t_1\mathtt{)}t_2 \quad \mapsto \quad \mathtt{|-}\,\mathtt{(}\backslash x\mathtt{.}\,t_1\mathtt{)}t_2\;\mathtt{=}\;t_1[t_2/x] $$

Theorems of this sort are used in HOL in a variety of contexts, to justify the replacement of particular terms by semantically equivalent terms.

The ML type of conversions is conv:

type conv = term -> thm

For example, BETA_CONV is an ML function of type conv (i.e., a conversion) that expresses $\beta$-conversion in HOL. It produces the appropriate equational theorem on $\beta$-redexes and fails elsewhere.

> BETA_CONV;
val it = fn: term -> thm

> BETA_CONV ``(\x. (\y. (\z. x + y + z)3)2) 1``;
val it =
   ⊢ (λx. (λy. (λz. x + y + z) 3) 2) 1 =
     (λy. (λz. 1 + y + z) 3) 2: thm

> BETA_CONV ``(\y. (\z. 1 + (y + z))3) 2``;
val it = ⊢ (λy. (λz. 1 + (y + z)) 3) 2 = (λz. 1 + (2 + z)) 3: thm

> BETA_CONV ``(\z. 1 + (2 + z)) 3``;
val it = ⊢ (λz. 1 + (2 + z)) 3 = 1 + (2 + 3): thm

> BETA_CONV ``1 + (2 + 3)``;
Exception- HOL_ERR (at Thm.BETA_CONV: not a beta-redex) raised

The basic conversions, as well as a number of those commonly used, are provided in HOL. There are also groups of application-specific conversions to be found in some of the libraries. (Of those provided, some are derived and some, like BETA_CONV, are taken as axiomatic.) In addition, HOL provides a collection of ML functions enabling users to define new conversions (as well as new rules and tactics) as functions of existing ones. The notion of conversions is inherited from Cambridge LCF; the underlying principles are described in (Paulson 1983, 1987).

Conversions such as BETA_CONV represent infinite families of equations. They are particularly useful in cases in which it is impossible to state, within the logic, a single axiom or theorem instantiable to every equation in a family. Instead, an ML procedure returns the instance of the desired theorem for any given term. This is also the reason that quite a few of the other rules in HOL are not stated instead as axioms or theorems. As rules, conversions are distinguished with an ML type abbreviation simply because there are relatively many of them with the same type, and because they return equational theorems that lend themselves directly to term rewriting. In many HOL applications, the main use of conversions is to produce these equational theorems. A few examples of conversions are illustrated below.

> NOT_FORALL_CONV “~!x. (f:'a->'a) x = g x”;
val it = ⊢ ¬(∀x. f x = g x) ⇔ ∃x. f x ≠ g x: thm

> CONTRAPOS_CONV ``(!x. f x = g x) ==> ((f:'a->'a) = g)``;
val it = ⊢ (∀x. f x = g x) ⇒ f = g ⇔ f ≠ g ⇒ ¬∀x. f x = g x: thm

> SELECT_CONV ``(@f:'a->'a. f x = g x)x = g x``;
val it = ⊢ (@f. f x = g x) x = g x ⇔ ∃f. f x = g x: thm

> EXISTS_UNIQUE_CONV “∃!z. (f:'a->'a) z = g z”;
val it =
   ⊢ (∃!z. f z = g z) ⇔
     (∃z. f z = g z) ∧ ∀z z'. f z = g z ∧ f z' = g z' ⇒ z = z':
   thm

An example of an application-specific conversion is numLib's num_CONV:

> numLib.num_CONV “2”;
val it = ⊢ 2 = SUC 1: thm

> numLib.num_CONV “1”;
val it = ⊢ 1 = SUC 0: thm

> numLib.num_CONV “0” handle e => Raise e;
Exception- 
Exception raised at Num_conv.num_CONV: Term either not a numeral or zero
HOL_ERR (at Num_conv.num_CONV: Term either not a numeral or zero) raised

Another application of conversions, related to the first, is in the implementation of the existing rewriting tools, REWRITE_CONV, REWRITE_RULE and REWRITE_TAC, which are central to theorem proving in HOL. This use is explained in §Rewriting Tools, both as an example and because users may have occasion to construct rewriting tools of their own design, by similar methods. The next section introduces the conversion-building tools in general.

Indicating Unchangedness

All conversions may raise the special exception Conv.UNCHANGED on an input term t, as a “short-hand” instead of returning the reflexive theorem |- t = t. This is done for efficiency reasons. All of the connectives described below in §Conversion Combining Operators handle this exception appropriately. The standard function QCONV is provided to automatically handle this exception in contexts where it would be inappropriate (typically where a conversion is being called to provide a theorem directly). QCONV's implementation is

   fun QCONV c t = c t handle UNCHANGED => REFL t

Conversion Combining Operators

A term $u$ is said to reduce to a term $v$ by a conversion $c$ if there exists a finite sequence of terms $t_1$, $t_2$, $\dots$, $t_n$ such that:

1. $u = t_1$ and $v = t_n$;
2. $c\ t_i$ evaluates to the theorem |- $t_i$=$t_{i+1}$ for $1 \leq i < n$;
3. The evaluation of $c\ t_n$ fails.

The first session of this chapter illustrates the reduction of the term

   (\x. (\y. (\z. x + y + z)3)2)1

to 1 + (2 + 3) by the conversion BETA_CONV, in a reduction sequence of length four:

   (\x. (\y. (\z. x + (y + z))3)2)1
   (\y. (\z. 1 + (y + z))3)2
   (\z. 1 + (2 + z))3
   1 + (2 + 3)

That is, BETA_CONV applies to each term of the sequence, except the fourth and last, to give a theorem equating that term to the next term. Therefore, each term of the sequence, from the second on, can be extracted from the theorem for the previous term; namely, it is the right hand side of the conclusion. The whole reduction can therefore be accomplished by repeated application of BETA_CONV to the terms of the sequence as they are generated.

To transform BETA_CONV to achieve this effect, two operators on conversions are introduced. The first one, infixed, is THENC, which sequences conversions.

    THENC : conv * conv -> conv

If $c_1\ t_1$ evaluates to $\Gamma_1$|- $t_1$=$t_2$ and $c_2\ t_2$ evaluates to $\Gamma_2$|- $t_2$=$t_3$, then ($c_1$THENC$c_2$) $t_1$ evaluates to $\Gamma_1\cup\Gamma_2$|-$t_1$=$t_3$. If the evaluation of $c_1\ t_1$ or the evaluation of $c_2\ t_2$ fails, then so does the evaluation of $c_1$THENC$c_2$. THENC is justified by the transitivity of equality.

The second, also infixed, is ORELSEC; this applies a second conversion if the application of the first one fails.

    ORELSEC : conv * conv -> conv

($c_1$ORELSEC$c_2$) $t$ evaluates to $c_1\ t$ if that evaluation succeeds, and to $c_2\ t$ otherwise. (The failure to evaluate is detected via the ML failure construct.)

The functions THENC and ORELSEC are used to define the desired operator, REPEATC, which successively applies a conversion until it fails:

    REPEATC : conv -> conv

REPEATC $c$ is intuitively equivalent to:

   (c THENC c THENC ... THENC c THENC ...) ORELSEC ALL_CONV

It is defined recursively:

   fun REPEATC c t = ((c THENC (REPEATC c)) ORELSEC ALL_CONV) t

The current example term can thus be completely reduced by use of BETA_CONV transformed by the REPEATC operator:

> REPEATC BETA_CONV;
val it = fn: conv

> REPEATC BETA_CONV ``(\x. (\y. (\z. x + y + z)3)2)1``;
val it = ⊢ (λx. (λy. (λz. x + y + z) 3) 2) 1 = 1 + 2 + 3: thm

BETA_CONV applies to terms of a certain top level form only, namely to $\beta$-redexes, and fails on terms of any other form. In addition, no number of repetitions of BETA_CONV will $\beta$-reduce arbitrary $\beta$-redexes embedded in terms. For example, the term shown below fails even at the top level because it is not a $\beta$-redex:

> BETA_CONV ``(((\x.(\y.(\z. x + y + z))) 1) 2) 3``;
Exception- HOL_ERR (at Thm.BETA_CONV: not a beta-redex) raised

> is_abs ``(((\x.(\y.(\z. x + y + z))) 1) 2)``;
val it = false: bool

The $\beta$-redex (\w.w)3 is not affected in the third input of the session shown below, because of its position in the structure of the whole term. This is so even though the whole term is reduced, and the subterm at top level could be reduced:

> BETA_CONV ``(\z. x + y + z) 3``;
val it = ⊢ (λz. x + y + z) 3 = x + y + 3: thm

> BETA_CONV ``(\w. w) 3``;
val it = ⊢ (λw. w) 3 = 3: thm

> REPEATC BETA_CONV ``(\z. x + y + z) ((\w. w) 3)``;
val it = ⊢ (λz. x + y + z) ((λw. w) 3) = x + y + (λw. w) 3: thm

To produce, from a conversion $c$, a conversion that applies $c$ to every subterm of a term, the function DEPTH_CONV can be applied to $c$:

    DEPTH_CONV : conv -> conv

DEPTH_CONV $c$ is a conversion $$ t \quad\mapsto\quad \mathtt{|-}\,t\,\mathtt{=}\,t' $$ where $t'$ is obtained from $t$ by replacing every subterm $u$ by $v$ if $u$ reduces to $v$ by $c$. (Subterms for which $c\ u$ fails are left unchanged.) The definition leaves open the search strategy; in fact, DEPTH_CONV $c$ traverses a term “bottom up”, once, and left-to-right, repeatedly applying $c$ to each subterm until no longer applicable. This helps with the two problems thus far:

> DEPTH_CONV BETA_CONV ``(((\x. (\y. (\z. x + y + z))) 1) 2) 3``;
val it = ⊢ (λx y z. x + y + z) 1 2 3 = 1 + 2 + 3: thm

> DEPTH_CONV BETA_CONV ``(\z. x + y + z) ((\w. w) 3)``;
val it = ⊢ (λz. x + y + z) ((λw. w) 3) = x + y + 3: thm

It may happen, however, that the result of such a conversion still contains subterms that could themselves be reduced at top level. For example:

> val t = ``(\f. \x. f x) (\n. n + 1)``;
val t = “(λf x. f x) (λn. n + 1)”: term

> DEPTH_CONV BETA_CONV t;
val it = ⊢ (λf x. f x) (λn. n + 1) = (λx. (λn. n + 1) x): thm

The function TOP_DEPTH_CONV does more searching and reduction than DEPTH_CONV: it replaces every subterm $u$ by $v'$ if $u$ reduces to $v$ by $c$ and $v$ recursively reduces to $v'$ by TOP_DEPTH_CONV $c$.

    TOP_DEPTH_CONV : conv -> conv

Thus:

> TOP_DEPTH_CONV BETA_CONV t;
val it = ⊢ (λf x. f x) (λn. n + 1) = (λx. x + 1): thm

Finally, the simpler function ONCE_DEPTH_CONV is provided:

    ONCE_DEPTH_CONV : conv -> conv

ONCE_DEPTH_CONV $c\ t$ applies $c$ once to the first term (and only the first term) on which it succeeds in a top-down traversal:

> ONCE_DEPTH_CONV BETA_CONV t;
val it = ⊢ (λf x. f x) (λn. n + 1) = (λx. (λn. n + 1) x): thm

> ONCE_DEPTH_CONV BETA_CONV ``(\x. (\n. n + 1) x)``;
val it = ⊢ (λx. (λn. n + 1) x) = (λx. x + 1): thm

The equational theorems returned by conversions are not always useful in equational form. To make the results more useful for theorem proving, a conversion can be converted to a rule or a tactic, using the functions CONV_RULE or CONV_TAC, respectively.

    CONV_RULE : conv -> thm -> thm
    CONV_TAC : conv -> tactic

CONV_RULE $c$(|-$t$) returns |- $t'$, where $c\ t$ evaluates to the equation |- $t$=$t'$. CONV_TAC $c$ is a tactic that converts the conclusion of a goal using $c$. CONV_RULE is defined by:

   fun CONV_RULE c th = EQ_MP (c (concl th)) th

(The validation of CONV_TAC also uses EQ_MP.) For example, the built-in rule BETA_RULE reduces some of the $\beta$-redex subterms of a term.

    BETA_RULE : thm -> thm

It is defined by:

   val BETA_RULE = CONV_RULE (DEPTH_CONV BETA_CONV)

The search invoked by BETA_RULE is adequate for some purposes but not others; for example, the first use shown below but not the second:

> BETA_RULE (ASSUME ``(((\x. (\y. (\z. x + y + z))) 1) 2) 3 < 10``);
val it =  [.] ⊢ 1 + 2 + 3 < 10: thm

> val th = ASSUME ``NEXT = ^t``;
val th =  [.] ⊢ NEXT = (λf x. f x) (λn. n + 1): thm

> BETA_RULE th;
val it =  [.] ⊢ NEXT = (λx. (λn. n + 1) x): thm

> BETA_RULE (BETA_RULE th);
val it =  [.] ⊢ NEXT = (λx. x + 1): thm

A more powerful $\beta$-reduction rule that used the second search strategy could be defined as shown below (this is not built into HOL).

> val TOP_BETA_RULE = CONV_RULE (TOP_DEPTH_CONV BETA_CONV);
val TOP_BETA_RULE = fn: thm -> thm

> TOP_BETA_RULE th;
val it =  [.] ⊢ NEXT = (λx. x + 1): thm

TOP_DEPTH_CONV is the traversal strategy used by the HOL rewriting tools described in §Rewriting Tools.

Writing Compound Conversions

There are several other conversion operators in HOL, which, together with THENC, ORELSEC and REPEATC are available for building more complex conversions, as well as rules, tactics, and so on. These are described below; several are good illustrations themselves of how functions are built using conversions. The section culminates with the explanation of how DEPTH_CONV, TOP_DEPTH_CONV, and ONCE_DEPTH_CONV are built.

The conversion NO_CONV is an identity for ORELSEC, useful in building functions.

    NO_CONV : conv

NO_CONV $t$ always fails.

The function FIRST_CONV returns $c\ t$ for the first conversion $c$, in a list of conversions, for which the evaluation of $c\ t$ succeeds.

    FIRST_CONV : conv list -> conv

FIRST_CONV [$c_1$;$\dots$;$c_n$] is equivalent, intuitively, to:

   c1 ORELSEC c2 ORELSEC ... ORELSEC cn

It is defined by:

   fun FIRST_CONV [] tm = NO_CONV tm
     | FIRST_CONV (c :: rst) tm =
         c tm handle HOL_ERR _ => FIRST_CONV rst tm

The conversion ALL_CONV is an identity for THENC, useful in building functions.

    ALL_CONV : conv

ALL_CONV $t$ evaluates to |- $t$=$t$. It is defined as being identical to REFL.

The function EVERY_CONV applies a list of conversions in sequence.

    EVERY_CONV : conv list -> conv

EVERY_CONV [$c_1$;$\dots$;$c_n$] is equivalent, intuitively, to:

   c1 THENC c2 THENC ... THENC cn

It is defined by:

   fun EVERY_CONV cl t =
       List.foldr (op THENC) ALL_CONV cl t
         handle HOL_ERR _ => raise ERR "EVERY_CONV" ""

The operator CHANGED_CONV converts one conversion to another that fails on arguments that it cannot change.

    CHANGED_CONV : conv -> conv

If $c\ t$ evaluates to |- $t$=$t'$, then CHANGED_CONV $c\ t$ also evaluates to |- $t$=$t'$, unless $t$ and $t'$ are the same (up to $\alpha$-conversion), in which case it fails.

The operator TRY_CONV maps one conversion to another that always succeeds, by replacing failures with the identity conversion.

    TRY_CONV : conv -> conv

If $c\ t$ evaluates to |- $t$=$t'$, then TRY_CONV $c\ t$ also evaluates to |- $t$=$t'$. If $c\ t$ fails, then TRY_CONV $c\ t$ evaluates to |- $t$=$t$. TRY_CONV is implemented by:

   fun TRY_CONV c = c ORELSEC ALL_CONV

It is used in the implementation of TOP_DEPTH_CONV (given later).

There are a number of operators for applying conversions to the immediate subterms of a term. These use the ML functions:

    MK_COMB : thm * thm -> thm
    MK_ABS : thm -> thm

MK_COMB and MK_ABS implement the following derived rules: $$ \frac{\Gamma_1\,\mathtt{|-}\,u_1\mathtt{=}v_1 \qquad \Gamma_2\,\mathtt{|-}\,u_2\mathtt{=}v_2}{\Gamma_1\cup\Gamma_2\,\mathtt{|-}\,u_1\,u_2\,\mathtt{=}\,v_1\,v_2} \quad \mathtt{MK\_COMB} $$ $$ \frac{\Gamma\,\mathtt{|-\,!}x\mathtt{.}u\mathtt{=}v}{\Gamma\,\mathtt{|-\,(}\backslash x\mathtt{.}u\mathtt{)\,=\,(}\backslash x\mathtt{.}v\mathtt{)}} \quad \mathtt{MK\_ABS} $$

The function SUB_CONV applies a conversion to the immediate subterms of a term.

    SUB_CONV : conv -> conv

In particular:

• SUB_CONV $c$ “$x$” $=$ |- $x$=$x$;
• SUB_CONV $c$ “$u\;v$” $=$ |- $u\,v$=$u'\,v'$, if $c\,u$ $=$ |- $u$=$u'$ and $c\,v$ $=$ |- $v$=$v'$;
• SUB_CONV $c$ “\$x$.$u$” $=$ |- (\$x$.$u$) = (\$x$.$u'$), if $c\,u$ $=$ |- $u$=$u'$.

SUB_CONV is implemented in terms of MK_COMB and MK_ABS:

   fun SUB_CONV c t =
       if is_comb t then
          let val (rator, rand) = dest_comb t
          in MK_COMB (c rator, c rand) end
       else if is_abs t then
          let val (bv, body) = dest_abs t
              val bodyth = c body
          in MK_ABS (GEN bv bodyth) end
       else ALL_CONV t

SUB_CONV, too, is used in the definitions of DEPTH_CONV and TOP_DEPTH_CONV.

Three other useful conversion operators, also for applying conversions to the immediate subterms of a term, are as follows:

    RATOR_CONV : conv -> conv
    RAND_CONV : conv -> conv
    ABS_CONV : conv -> conv

RATOR_CONV $c$ converts the operator of an application using $c$; RAND_CONV $c$ converts the operand of an application; and ABS_CONV $c$ converts the body of an abstraction. Combinations of these are useful for applying conversions to particular subterms. These are implemented by:

   fun RATOR_CONV c t =
     let val (rator, rand) = dest_comb t
     in
       MK_COMB (c rator, REFL rand)
     end

   fun ABS_CONV c t =
     let val (bv, body) = dest_abs t
         val bodyth = c body
     in
       MK_ABS (GEN bv bodyth)
     end

The following is an example session illustrating these immediate subterm conversions (recalling that the expression $t_1$+$t_2$ actually parses as + $t_1\,t_2$).

> val t = ``(\x.x + 1) m + (\x. x + 2) n``;
val t = “(λx. x + 1) m + (λx. x + 2) n”: term

> RAND_CONV BETA_CONV t;
val it =
   ⊢ (λx. x + 1) m + (λx. x + 2) n = (λx. x + 1) m + (n + 2): thm

> RATOR_CONV (RAND_CONV BETA_CONV) t;
val it = ⊢ (λx. x + 1) m + (λx. x + 2) n = m + 1 + (λx. x + 2) n:
   thm

Finally, the definitions of DEPTH_CONV and TOP_DEPTH_CONV are given below.

   fun DEPTH_CONV c t =
    (SUB_CONV (DEPTH_CONV c) THENC (REPEATC c)) t

   fun TOP_DEPTH_CONV c t =
    (REPEATC c THENC
     (TRY_CONV
       (CHANGED_CONV (SUB_CONV (TOP_DEPTH_CONV c)) THENC
        TRY_CONV (c THENC TOP_DEPTH_CONV c)))) t

   fun ONCE_DEPTH_CONV c t =
    (c ORELSEC (SUB_CONV (ONCE_DEPTH_CONV c))) t

Note that the extra argument t is needed to stop these definitions looping (because ML is a call-by-value language). Note also that the actual definition of ONCE_DEPTH_CONV used in the system has been optimised to use failure to avoid rebuilding unchanged subterms.

Built-in Conversions

Many conversions are predefined in HOL; only those likely to be of general interest are listed here.

Generalized beta-reduction

The conversion:

    PAIRED_BETA_CONV : conv

does generalized beta-conversion of tupled lambda abstractions applied to tuples.

Given the term:

   “(\(x1, ... ,xn).t) (t1, ... ,tn)”

PAIRED_BETA_CONV proves that:

   |- (\(x1, ... ,xn). t[x1,...,xn]) (t1, ... ,tn)  =  t[t1, ... ,tn]

The conversion works for arbitrarily nested tuples. For example:

> PAIRED_BETA_CONV “(\((a,b),(c,d)). [a;b;c;d]) ((1,2),(3,4))”;
val it =
   ⊢ (λ((a,b),c,d). [a; b; c; d]) ((1,2),3,4) = [1; 2; 3; 4]: thm

Arithmetical conversions

The conversion:

    ADD_CONV : conv

does addition by formal proof. If $n$ and $m$ are numerals then ADD_CONV "$n$+$m$" returns the theorem |- $n$+$m$=$s$, where $s$ is the numeral denoting the sum of $n$ and $m$. For example:

> ADD_CONV ``1 + 2``;
val it = ⊢ 1 + 2 = 3: thm

> ADD_CONV ``0 + 1000``;
val it = ⊢ 0 + 1000 = 1000: thm

> ADD_CONV ``101 + 102``;
val it = ⊢ 101 + 102 = 203: thm

For more general arithmetic, the conversion REDUCE_CONV handles all of the operators in the theory of natural number arithmetic (see Section 5.3.1):

> REDUCE_CONV ``2 * 3``;
val it = ⊢ 2 * 3 = 6: thm

> REDUCE_CONV ``2 ** 3 + 101 MOD 6``;
val it = ⊢ 2³ + 101 MOD 6 = 13: thm

List processing conversions

There are two useful built-in conversions for lists:

    LENGTH_CONV : conv
    list_EQ_CONV : conv -> conv

LENGTH_CONV computes the length of a list. A call to:

   LENGTH_CONV ``LENGTH[t1;...;tn]``

generates the theorem:

   |- LENGTH [t1;...;tn] = n

The other conversion, list_EQ_CONV, proves or disproves the equality of two lists, given a conversion for deciding the equality of elements. A call to:

   list_EQ_CONV conv "[u1;...;un] = [v1;...;vm]"

returns |- ([u1;...;un] = [v1;...;vm]) = F if:

1. ~(n=m), or
2. conv proves |- ($u_i$=$v_i$) = F for any $1 \leq i \leq m$.

|- ([u1;...;un] = [v1;...;vm]) = T is returned if:

1. (n=m) and ui is syntactically identical to vi for $1 \leq i \leq m$, or
2. (n=m) and conv proves |- ($u_i$=$v_i$) = T for $1 \leq i \leq n$.

Skolemization

Two conversions are provided for a higher-order version of Skolemization (using existentially quantified function variables rather than first-order Skolem constants).

The conversion

    X_SKOLEM_CONV : term -> conv

takes a variable parameter, $f$ say, and proves:

   |- (!x1 ... xn. ?y. t[x1,...,xn,y])  =  (?f. !x1 ... xn. t[x1,...,xn,f x1...xn])

for any input term !$x_1\ \dots\ x_n$. ?$y$. $t[x_1,\dots,x_n,y]$. Note that when $n=0$, this is equivalent to alpha-conversion:

  |- (?y. t[y]) = (?f. t[f])

and that the conversion fails if there is already a free variable $f$ of the appropriate type in the input term. For example:

> X_SKOLEM_CONV “f:num->'a” “!n:num. ?x:'a. x = (f n)”;
Exception- HOL_ERR (at Conv.X_SKOLEM_CONV: `f` free in the input term) raised

will fail. The conversion SKOLEM_CONV is like X_SKOLEM_CONV, except that it uses a primed variant of the name of the existentially quantified variable as the name of the skolem function it introduces. For example:

> SKOLEM_CONV “!x. ?y. P x y”;
<<HOL message: inventing new type variable names: 'a, 'b>>
val it = ⊢ (∀x. ∃y. P x y) ⇔ ∃y. ∀x. P x (y x): thm

Quantifier movement conversions

A complete and systematically-named set of conversions for moving quantifiers inwards and outwards through the logical connectives ~, /\, \/, and ==> is provided. The naming scheme is based on the following atoms:

   <quant> := FORALL | EXISTS
   <conn>  := NOT | AND | OR | IMP
   [dir]   := LEFT | RIGHT          (optional)

The conversions for moving quantifiers inwards are called:

   <quant>_<conn>_CONV

where the quantifier <quant> is to be moved inwards through <conn>.

The conversions for moving quantifiers outwards are called:

   [dir]_<conn>_<quant>_CONV

where <quant> is to be moved outwards through <conn>, and the optional [dir] identifies which operand (left or right) contains the quantifier. The complete set is:

   NOT_FORALL_CONV    |- ~(!x.P) = ?x.~P
   NOT_EXISTS_CONV    |- ~(?x.P) = !x.~P
   EXISTS_NOT_CONV    |- (?x.~P) = ~!x.P
   FORALL_NOT_CONV    |- (!x.~P) = ~?x.P

   FORALL_AND_CONV         |- (!x. P /\ Q) = (!x.P) /\ (!x.Q)
   AND_FORALL_CONV         |- (!x.P) /\ (!x.Q) = (!x. P /\ Q)
   LEFT_AND_FORALL_CONV    |- (!x.P) /\ Q = (!x'. P[x'/x] /\ Q)
   RIGHT_AND_FORALL_CONV   |- P /\ (!x.Q) = (!x'. P /\ Q[x'/x])

   EXISTS_OR_CONV          |- (?x. P \/ Q) = (?x.P) \/ (?x.Q)
   OR_EXISTS_CONV          |- (?x.P) \/ (?x.Q) = (?x. P \/ Q)
   LEFT_OR_EXISTS_CONV     |- (?x.P) \/ Q = (?x'. P[x'/x] \/ Q)
   RIGHT_OR_EXISTS_CONV    |- P \/ (?x.Q) = (?x'. P \/ Q[x'/x])

   FORALL_OR_CONV
     |- (!x.P \/ Q) = P \/ !x.Q          [x not free in P]
     |- (!x.P \/ Q) = (!x.P) \/ Q        [x not free in Q]
     |- (!x.P \/ Q) = (!x.P) \/ (!x.Q)   [x not free in P or Q]

   OR_FORALL_CONV
     |- (!x.P) \/ (!x.Q) = (!x.P \/ Q)   [x not free in P or Q]

   LEFT_OR_FORALL_CONV    |- (!x.P) \/ Q = !x'. P[x'/x] \/ Q
   RIGHT_OR_FORALL_CONV   |- P \/ (!x.Q)  = !x'. P \/ Q[x'/x]

   EXISTS_AND_CONV
     |- (?x.P /\ Q) = P /\ ?x.Q          [x not free in P]
     |- (?x.P /\ Q) = (?x.P) /\ Q        [x not free in Q]
     |- (?x.P /\ Q) = (?x.P) /\ (?x.Q)   [x not free in P or Q]

   AND_EXISTS_CONV
     |- (?x.P) /\ (?x.Q) = (?x.P /\ Q)   [x not free in P or Q]

   LEFT_AND_EXISTS_CONV    |- (?x.P) /\ Q = ?x'. P[x'/x] /\ Q
   RIGHT_AND_EXISTS_CONV   |- P /\ (?x.Q)  = ?x'. P /\ Q[x'/x]

   FORALL_IMP_CONV
     |- (!x.P ==> Q) = P ==> !x.Q          [x not free in P]
     |- (!x.P ==> Q) = (?x.P) ==> Q        [x not free in Q]
     |- (!x.P ==> Q) = (?x.P) ==> (!x.Q)   [x not free in P or Q]

   LEFT_IMP_FORALL_CONV   |- (!x.P) ==> Q = !x'. P[x/'x] ==> Q
   RIGHT_IMP_FORALL_CONV  |- P ==> (!x.Q) = !x'. P ==> Q[x'/x]

   EXISTS_IMP_CONV
     |- (?x.P ==> Q) = P ==> ?x.Q          [x not free in P]
     |- (?x.P ==> Q) = (!x.P) ==> Q        [x not free in Q]
     |- (?x.P ==> Q) = (!x.P) ==> (?x.Q)   [x not free in P or Q]

   LEFT_IMP_EXISTS_CONV   |- (?x.P) ==> Q = !x'. P[x/'x] ==> Q
   RIGHT_IMP_EXISTS_CONV  |- P ==> (?x.Q) = ?x'. P ==> Q[x'/x]

Rewriting Tools

The rewriting tool REWRITE_RULE was introduced in Chapter 2. There are also rewriting conversions like REWRITE_CONV. All of the various rewriting tools provided in HOL are implemented by use of conversions. Certain new tools could also be built in a similar way.

The rewriting primitive in HOL is REWR_CONV:

    REWR_CONV : thm -> conv

REWR_CONV ($\Gamma$|-$u$=$v$) $t$ evaluates to a theorem $\Gamma$|-$t$=$t'$ if $t$ is an instance (by type and/or variable instantiation) of $u$ and $t'$ is the corresponding instance of $v$. The first argument to REWR_CONV can be quantified. Below is an illustration.

> REWR_CONV ADD1 ``SUC 0``;
val it = ⊢ SUC 0 = 0 + 1: thm

All subterms of $t$ can be rewritten according to an equation $th$ using $$ \mathtt{DEPTH\_CONV(REWR\_CONV}\;th\mathtt{)} $$ as shown below. The function "PRE" is the usual predecessor function.

> DEPTH_CONV (REWR_CONV ADD1) ``SUC (SUC 0) = PRE (SUC 2)``;
val it = ⊢ SUC (SUC 0) = PRE (SUC 2) ⇔ 0 + 1 + 1 = PRE (2 + 1):
   thm

In itself, this is not a very useful rewriting tool, but a collection of others have been developed for use in HOL. All of the rewriting tools are, in fact, logically derived, and are based on conversions similar to DEPTH_CONV. They have been optimized in various ways, so their implementation is in some cases rather complex and is not given here. The conversions, rules and tactics for rewriting all take a list of theorems to be used as rewrites. The theorems in the list need not be in simple equational form (e.g., a conjunction of equations is permissible); but are converted to equational form automatically (and internally). (For example, a conjunction of equations is split into its constituent conjuncts.) There are also a number of standard equations (representing common tautologies) held in the ML variable basic_rewrites, and these are used by some of the rewriting tools. All the built-in rewriting tools are listed below, for reference, beginning with the rules. (All are fully described in §REFERENCE.)

The prefix PURE_ indicates that the built-in equations in basic_rewrites are not used (i.e., only those given explicitly are used). The prefix ONCE_ indicates that the tool makes only one rewriting pass through the expression (this is useful to avoid divergence). It is based on ONCE_DEPTH_CONV, while the other tools traverse using TOP_DEPTH_CONV.

The rewriting conversions are:

   REWRITE_CONV                : thm list -> conv
   PURE_REWRITE_CONV           : thm list -> conv
   ONCE_REWRITE_CONV           : thm list -> conv
   PURE_ONCE_REWRITE_CONV      : thm list -> conv

The basic rewriting rules are:

   REWRITE_RULE                      : thm list -> thm -> thm
   PURE_REWRITE_RULE                 : thm list -> thm -> thm
   ONCE_REWRITE_RULE                 : thm list -> thm -> thm
   PURE_ONCE_REWRITE_RULE            : thm list -> thm -> thm

The prefix ASM_ indicates that the rule rewrites using the assumptions of the theorem as rewrites.

   ASM_REWRITE_RULE                  : thm list -> thm -> thm
   PURE_ASM_REWRITE_RULE             : thm list -> thm -> thm
   ONCE_ASM_REWRITE_RULE             : thm list -> thm -> thm
   PURE_ONCE_ASM_REWRITE_RULE        : thm list -> thm -> thm

The prefix FILTER_ indicates that the rule only rewrites with those assumptions of the theorem satisfying the predicate supplied.

   FILTER_ASM_REWRITE_RULE           : (term -> bool) -> thm list -> thm -> thm
   FILTER_PURE_ASM_REWRITE_RULE      : (term -> bool) -> thm list -> thm -> thm
   FILTER_ONCE_ASM_REWRITE_RULE      : (term -> bool) -> thm list -> thm -> thm
   FILTER_PURE_ONCE_ASM_REWRITE_RULE : (term -> bool) -> thm list -> thm -> thm

Tactics are introduced in Chapter 4, but are listed here for reference. The tactics corresponding to the above rules are the following:

   REWRITE_TAC                       : thm list -> tactic
   PURE_REWRITE_TAC                  : thm list -> tactic
   ONCE_REWRITE_TAC                  : thm list -> tactic
   PURE_ONCE_REWRITE_TAC             : thm list -> tactic

The prefix ASM_ indicates that the tactic rewrites using the assumptions of the goal as rewrites.

   ASM_REWRITE_TAC                   : thm list -> tactic
   PURE_ASM_REWRITE_TAC              : thm list -> tactic
   ONCE_ASM_REWRITE_TAC              : thm list -> tactic
   PURE_ONCE_ASM_REWRITE_TAC         : thm list -> tactic

The prefix FILTER_ indicates that the tactic only rewrites with those assumptions of the goal satisfying the predicate supplied.

   FILTER_ASM_REWRITE_TAC            : (term -> bool) -> thm list -> tactic
   FILTER_PURE_ASM_REWRITE_TAC       : (term -> bool) -> thm list -> tactic
   FILTER_ONCE_ASM_REWRITE_TAC       : (term -> bool) -> thm list -> tactic
   FILTER_PURE_ONCE_ASM_REWRITE_TAC  : (term -> bool) -> thm list -> tactic

Goal Directed Proof: Tactics and Tacticals

There are three primary devices that together make theorem proving practical in HOL. All three originate with Milner for Edinburgh LCF. The first is the theory as a record of (among other things) facts already proved and thence available as lemmas without having to be re-proved. The second, the subject of Chapter 2, is the derived rule of inference as a meta-language procedure that implements a broad pattern of inference, but that also, at each application, generates every primitive step of the proof. The third device is the tactic as a means of organizing the construction of proofs; and the use of tacticals for composing tactics.

Even with recourse to derived inference rules, it is still surprisingly awkward to work forward, to find a chain of theorems that culminates in a desired theorem. This is in part because chains have no structure, while “proof efforts” do. For instance, if within one sequence, two chains of steps are to be combined in the end by conjunction, then one chain must follow or be interspersed with the other in the overall sequence. It can also be difficult to direct the proof toward its object when starting from only hypotheses (if any), lemmas (if any), axioms, and theorems following from no hypotheses (e.g., by ASSUME or REFL). Likewise, it can be equally difficult to reconstruct the plan of the proof effort after the fact, from the linear sequence of theorems; the sequence is unhelpful as documentation.

The idea of goal directed proof is a simple one, well known in artificial intelligence: to organize the search as a tree, and to reverse the process and begin with the objective. The goal is then decomposed, successively if necessary, into what one hopes are more tractable subgoals, each decomposition accompanied by a plan for translating the solution of subgoals into a solution of the goal. The choice of decomposition is an explicit way of expressing a proof “strategy”.

Thus, for example, instead of the linear sequencing of two branches of the proof of the conjunction, each branch starting from scratch, the proof task is organized as a tree search, starting with a conjunctive goal and decomposing it into the two conjunct subgoals (undertaken in optional order), with the intention of conjoining the two solutions when and if found. The proof itself, as a sequence of steps, is the same however it is found; the difference is in the search, and in the preservation, if required, of the structured proof plan.

The representation of this idea in LCF was Milner's inspiration; the idea is similarly central to theorem proving in HOL. Although subgoaling theorem provers had already been built at the time, Milner's particular contribution was in formalizing the method for translating subgoals solutions to solutions of goals.

Tactics, Goals and Validations

A tactic is an ML function that when applied to a goal reduces it to (i) a list of (sub)goals, along with (ii) a validation function mapping a list of theorems to a theorem. The idea is that this function justifies the decomposition of the goal, and so it is also known as a justification. A goal is an ML value whose type is isomorphic to, but distinct from, the ML abstract type thm of theorems. That is, a goal is a list of terms (assumptions) paired with a term. These two components correspond, respectively, to the list of hypotheses and the conclusion of a theorem. The list of assumptions is a working record of facts that may be used in decomposing the goal.

The relation of theorems to goals is achievement: a theorem achieves a goal if the conclusion of the theorem is equal to the term part of the goal (up to $\alpha$-conversion), and if each hypothesis of the theorem is equal (up to $\alpha$-conversion, again) to some assumption of the goal. This definition assures that the theorem purporting to satisfy a goal does not depend on assumptions beyond the working assumptions of the goal.

A tactic is said to solve a goal if it reduces the goal to the empty set of subgoals. This depends, obviously, on there being at least one tactic that maps a goal to the empty subgoal list. The simplest tactic that does this is one that can recognize when a goal is achieved by an axiom or an existing theorem; in HOL, the function ACCEPT_TAC does this. ACCEPT_TAC takes a theorem $\mathit{th}$ and produces a tactic that maps a value of type thm to the empty list of subgoals. It justifies this “decomposition” by a validation function that maps the empty list of theorems to the theorem $\mathit{th}$. The use of this technical device, or other such tactics, ends the decomposition of subgoals, and allows the proof to be built up.

Unlike theorems, goals need not be defined as an abstract type; they are transparent and can be constructed freely. Thus, an ML type abbreviation is introduced for goals. The operations on goals are therefore just the ordinary pair selectors and constructor. Likewise, type abbreviations are introduced for validations and tactics. Conceptually, the following abbreviations are made in HOL:

   goal       = term list * term
   tactic     = goal -> goal list * validation
   validation = thm list -> thm

It does not follow, of course, from the type tactic that a particular tactic is well-behaved. For example, suppose that $T\ g$ = ([$g_1$,$\dots$,$g_n$],$v$), and that the subgoals $g_1$, $\dots$, $g_n$ have been solved. That means that some theorems $\mathit{th}_1$, $\dots$, $\mathit{th}_n$ have been proved such that each $\mathit{th}_i$ ($1 \leq i \leq n$) achieves the goal $g_i$. The validation $v$ is intended to be a function that when applied to the list [$\mathit{th}_1$,$\dots$,$\mathit{th}_n$], succeeds in returning a theorem, $\mathit{th}$, achieving the original goal $g$; but, of course, it might sometimes not succeed. If $v$ succeeds for every list of achieving theorems, then the tactic $T$ is said to be valid. This does not guarantee, however, that the subgoals are solvable in the first place. If, in addition to being valid, a tactic always produces solvable subgoals from a solvable goal, it is called strongly valid.

Tactics can be perfectly useful without being strongly valid, or without even being valid; in fact, some of the most basic theorem proving strategies, expressed as tactics, are invalid or not strongly valid. An invalid tactic cannot result in the proof of false theorems; theorems in HOL are always the result of performing a proof in the basic logic, whether the proof is found by goal directed search or forward search. However, an invalid tactic may produce an unintended theorem — one that does not achieve the original goal. The typical case is when a theorem purporting to achieve a goal actually depends on hypotheses that extend beyond the assumptions of the goal. The inconvenience to the HOL user in this case is that the problem may be not immediately obvious; the default print format of theorems has hypotheses abbreviated as dots. Invalidity may also be the result of the failure of the proof function, in the ML sense of failure, when applied to a list of theorems (if, for example, the function were defined incorrectly); but again, no false theorems can result. Likewise, a tactic that is not strongly valid cannot result in a false theorem; the worst outcome of applying such a tactic is the production of unsolvable subgoals.

Tactics are specified using the following notation:

$$ \dfrac{\mathit{goal}} {\mathit{goal}_1\quad\mathit{goal}_2\quad\dots\quad\mathit{goal}_n} $$

For example, the tactic for decomposing conjunctions into two conjunct subgoals is called conj_tac. (The tactic is also available under the name CONJ_TAC.) It is described by:

$$ \dfrac{t_1\;\land\;t_2}{t_1\qquad t_2} $$

This indicates that conj_tac reduces a goal of the form ($\Gamma$,$t_1$/\$t_2$) to subgoals ($\Gamma$,$t_1$) and ($\Gamma$,$t_2$). The fact that the assumptions of the original goal are propagated unchanged to the two subgoals is indicated by the absence of assumptions in the notation. The notation gives no indication of the proof function.

Another example is numLib.INDUCT_TAC, a low-level tactic for performing mathematical induction on the natural numbers:

$$ \dfrac{\forall n.\;t[n]}{t[\mathtt{0}]\qquad \{t[n]\}\;t[\mathtt{SUC}\;n]} $$

Thus, INDUCT_TAC reduces a goal of the form ($\Gamma,\forall n.\;t[n]$) to a basis subgoal ($\Gamma$,$t[$0$]$) and an induction step subgoal ($\Gamma\cup\{t[n]\}$,$t[$SUC $n]$). The induction assumption is indicated in the tactic notation with set brackets.

Tactics fail (in the ML sense) if they are applied to inappropriate goals. For example, conj_tac will fail if it is applied to a goal whose conclusion is not a conjunction. Some tactics never fail; for example all_tac

$$ \dfrac{t}{t} $$

is the identity tactic; it reduces a goal ($\Gamma$,$t$) to the single subgoal ($\Gamma$,$t$) — i.e., it has no effect. The all_tac tactic is useful for writing compound tactics, as discussed later (see §Tacticals).

In just the way that the derived rule REWRITE_RULE can be used in forward proof, the corresponding tactic rewrite_tac can be used in goal-directed proof. Given a goal and a list of equational theorems, rewrite_tac transforms the term component of the goal by applying the equations as left-to-right rewrites, recursively and to all depths, until no more changes can be made. Unless not required, the function includes as rewrites the same standard set of pre-proved tautologies that REWRITE_RULE uses. By use of the tautologies, some subgoals can be solved internally by rewriting, and in that case, an empty list of subgoals is returned. The transformation of the goal is justified in each case by the appropriate chain of inferences. Rewriting is a simple implementation of an extremely powerful idea. The more sophisticated simplification functions (e.g., simp) often do a very large share of the work in goal directed proof searches.

A simple example from list theory illustrates the use of tactics. A conjunctive goal is declared, and conj_tac applied to it:

> val gl0 = ([]:term list,``(HD[1;2;3] = 1) /\ (TL[1;2;3] = [2;3])``);
val gl0 = ([], “HD [1; 2; 3] = 1 ∧ TL [1; 2; 3] = [2; 3]”):
   term list * term

> val (gl1,p1) = conj_tac gl0;
val gl1 =
   [([], “HD [1; 2; 3] = 1”), ([], “TL [1; 2; 3] = [2; 3]”)]:
   goal list
val p1 = fn: validation

The subgoals are each rewritten, using the definitions of HD and TL:

> open listTheory;   ... output elided ...

> HD;
val it = ⊢ ∀h t. HD (h::t) = h: thm

> TL;
val it = ⊢ ∀h t. TL (h::t) = t: thm

> val (gl1_1,p1_1) = rewrite_tac[HD,TL](hd gl1);
val gl1_1 = []: goal list
val p1_1 = fn: validation

> val (gl1_2,p1_2) = rewrite_tac[HD,TL](hd(tl gl1));
val gl1_2 = []: goal list
val p1_2 = fn: validation

Both of the two subgoals are now solved, so the decomposition is complete and the proof can be built up in stages. First the theorems achieving the subgoals are proved, then from those, the theorem achieving the original goal:

> val th1 = p1_1[];
val th1 = ⊢ HD [1; 2; 3] = 1: thm

> val th2 = p1_2[];
val th2 = ⊢ TL [1; 2; 3] = [2; 3]: thm

> p1[th1,th2];
val it = ⊢ HD [1; 2; 3] = 1 ∧ TL [1; 2; 3] = [2; 3]: thm

Although only the theorems achieving the subgoals are “seen” here, the proof functions of the three tactic applications together perform the entire chain of inferences leading to the theorem achieving the goal. The same proof could be constructed by forward search, starting from the definitions of HD and TL, but not nearly as easily.

The HOL system provides a very large collection of pre-defined tactics that includes conj_tac, INDUCT_TAC, all_tac and rewrite_tac. The pre-defined tactics are adequate for many applications. In addition, there are two means of defining new tactics. Since a tactic is an ML function, the user can define a new tactic directly in ML. Definitions of this sort use ML functions to construct the term part of the subgoals from the term part of the original goal (if any transformation is required); and they specify the justification, which expects a list of theorems achieving the subgoals and returns the theorem achieving (one hopes) the goal. The proof of the theorem is encoded in the definition of the justification function; that is, the means for deriving the desired theorem from the theorems given. This typically involves references to axioms and primitive and defined inference rules, and is usually the more difficult part of the project.

A simple example of a tactic written in ML is afforded by conj_tac, whose definition in HOL is as follows:

   fun conj_tac (asl,w) =
     let val (l,r) = dest_conj w
     in
         ([(asl,l), (asl,r)], (fn [th1, th2] => CONJ th1 th2))
     end

This shows how the subgoals are constructed, and how the proof function is specified in terms of the derived rule CONJ.

The second method is to compose existing tactics by the use of ML functions called tacticals. The tacticals provided in HOL are listed in §Tacticals. For example, two existing tactics can be sequenced by use of the tactical >> (the function can also be written as THEN or as \\): if $T_1$ and $T_2$ are tactics, then the ML expression $T_1$ >> $T_2$ evaluates to a tactic that first applies $T_1$ to a goal and then applies $T_2$ to each subgoal produced by $T_1$. The tactical >> is an infixed ML function. Complex and powerful tactics can be constructed in this way; and new tacticals can also be defined, although this is unusual.

The example from earlier is continued, to illustrate the use of the tactical >>:

> val (gl2,p2) = (conj_tac >> rewrite_tac [HD, TL]) gl0;
val gl2 = []: goal list
val p2 = fn: thm list -> thm

> p2 [];
val it = ⊢ HD [1; 2; 3] = 1 ∧ TL [1; 2; 3] = [2; 3]: thm

The single tactic conj_tac >> rewrite_tac[HD;TL] solves the goal in one single application. The chain of inference computed, however, is exactly the same as in the interactive proof; only the search is different.

In general, the second method is both easier and more reliable. It is easier because it does not involve writing ML procedures (usually rather complicated procedures); and more reliable because the composed tactics are valid when the constituent tactics are valid, as a consequence of the way the tacticals are defined. Tactics written directly in ML may fail in a variety of ways, and although, as usual, they cannot cause false theorems to appear, the failures can be difficult to understand and trace. On the other hand, there are some proof strategies that cannot be implemented as compositions of existing tactics, and these have to be implemented directly in ML. Certain sorts of inductions are an example of this; as well as tactics to support some personal styles of proof.

Either sort of tactic can be difficult to apply by hand, as shown in the examples above. There can be a lot of book-keeping required to support such an activity. For this reason, most interactive theorem-proving uses the subgoal or goalstack package.

Some Tactics Built into HOL

This section contains a selection of the more commonly used tactics in the HOL system. (See §REFERENCE for the complete list, with fuller explanations.)

It should be recalled that the ML type thm_tactic abbreviates thm->tactic, and the type conv abbreviates term->thm.

Specialization

    gen_tac : tactic

Summary: Specializes a universally quantified theorem to an arbitrary value. Also available under the name GEN_TAC.

$$ \dfrac{\forall x.\,t[x]}{t[x']} $$

where $x'$ is a variant of $x$ not free in either goal or assumptions.

Use: Solving universally quantified goals. gen_tac is often the first step of a goal directed proof. strip_tac (see below) applies gen_tac to universally quantified goals.

Conjunction

    conj_tac : tactic

Summary: Splits a goal $t_1\land t_2$ into two subgoals, $t_1$ and $t_2$.

$$ \dfrac{t_1\;\land\;t_2}{t_1\qquad t_2} $$

Use: Solving conjunctive goals. conj_tac is also invoked by strip_tac (see below).

Combined simple decompositions

    strip_tac : tactic

Summary: Breaks a goal apart. The tactic strip_tac removes one outer connective from the goal, using conj_tac, gen_tac, and other tactics. If the goal has the form $t_1\land \cdots \land t_n$ ==> $t$ then strip_tac makes each $t_i$ into a separate assumption.

Use: Useful for splitting a goal up into manageable pieces. Often the best thing to do first is rpt strip_tac, where rpt is the tactical that repeatedly applies a tactic until it fails (see §Repetition).

Case analysis

    Cases_on : term quotation -> tactic

Summary: Cases_on $q$, where $q$ is a quotation denoting a term of an algebraic type (e.g., booleans, lists, natural numbers, types defined by the user with Datatype), does case analysis on that term. Let the relevant type have $m$ constructors $\mathsf{C}_1$ to $\mathsf{C}_m$, where $\mathsf{C}_i$ has $n_i$ arguments. If the term is a variable, then the variable is substituted out of the goal entirely:

$$ \dfrac{t}{t[q := \mathsf{C}_1\,a_{11}\cdots a_{1n_1}]\quad\cdots\quad t[q := \mathsf{C}_m\,a_{m1}\cdots a_{mn_m}]} $$

If the term denoted by $q$ is not simply a variable (e.g., Cases_on `n + 1` ), then fresh assumptions are introduced:

$$ \dfrac{t}{\{q = \mathsf{C}_1\,a_{11}\cdots a_{1n_1}\}t\quad\cdots\quad\{q = \mathsf{C}_m\,a_{m1}\cdots a_{mn_m}\}t} $$

Use: Case analysis.

Rewriting

    rewrite_tac : thm list -> tactic

Summary: rewrite_tac[$\mathit{th}_1$,$\dots$,$\mathit{th}_n$] transforms the term part of a goal by rewriting it with the given theorems $\mathit{th}_1$, $\dots$, $\mathit{th}_n$, and the set of pre-proved standard tautologies. Also written REWRITE_TAC.

$$ \dfrac{\{t_1, \ldots, t_m\}t}{\{t_1, \ldots, t_m\}t'} $$

where $t'$ is obtained from $t$ as described.

Use: Advancing goals by using definitions and previously proved theorems.

Other rewriting tactics (based on rewrite_tac) are:

1. asm_rewrite_tac adds the assumptions of the goal to the list of theorems used for rewriting. Also written ASM_REWRITE_TAC.

PURE_ASM_REWRITE_TAC is like asm_rewrite_tac, but it doesn't use any built-in rewrites.

PURE_REWRITE_TAC uses neither the assumptions nor the built-in rewrites.

FILTER_ASM_REWRITE_TAC $p$ [$\mathit{th}_1$,$\dots$,$\mathit{th}_n$] simplifies the goal by rewriting it with the explicitly given theorems $\mathit{th}_1$, $\dots$, $\mathit{th}_n$, together with those assumptions of the goal which satisfy the predicate $p$ and also the standard rewrites.

See also the more powerful simplification tactics described in the simplifier chapter.

Resolution by Modus Ponens

    imp_res_tac : thm -> tactic

Summary: imp_res_tac $\mathit{th}$ does a limited amount of automated theorem proving in the form of forward inference; it “resolves” the theorem $\mathit{th}$ with the assumptions of the goal and adds any new results to the assumptions. The specification for imp_res_tac is:

$$ \dfrac{\{t_1,\ldots,t_m\}t}{\{t_1,\ldots,t_m,u_1,\ldots,u_n\}t} $$

where $u_1$, $\dots$, $u_n$ are derived by “resolving” the theorem $\mathit{th}$ with the existing assumptions $t_1$, $\dots$, $t_m$. Resolution in HOL is not classical resolution, but just Modus Ponens with one-way pattern matching (not unification) and term and type instantiation. The general case is where $\mathit{th}$ is of the canonical form

$$ \vdash \forall x_1\ldots x_p.\;v_1\Rightarrow v_2\Rightarrow\ldots\Rightarrow v_q\Rightarrow v $$

imp_res_tac $\mathit{th}$ then tries to specialize $x_1$, $\dots$, $x_p$ in succession so that $v_1$, $\dots$, $v_q$ match members of $\{t_1,\ldots,t_m\}$. Each time a match is found for some antecedent $v_i$, for $i$ successively equal to $1$, $2$, $\dots$, $q$, a term and type instantiation is made and the rule of Modus Ponens is applied. If all the antecedents $v_i$ (for $1 \leq i \leq q$) can be dismissed in this way, then the appropriate instance of $v$ is added to the assumptions. Otherwise, if only some initial sequence $v_1$, $\dots$, $v_k$ (for some $k$ where $1 < k < q$) of the assumptions can be dismissed, then the remaining implication:

$$ \vdash v_{k+1}\Rightarrow\ldots\Rightarrow v_q\Rightarrow v $$

is added to the assumptions.

For a more detailed description of resolution and imp_res_tac, see §REFERENCE.

Use: Deriving new results from a previously proved implicative theorem, in combination with the current assumptions, so that subsequent tactics can use these new results.

Identity

    all_tac : tactic

Summary: The identity tactic for the tactical >> (see the example in §Tactics, Goals and Validations, and §Sequencing). Useful for writing tactics.

Use:

Writing tacticals (see description of rpt in §Repetition).

With THENL (see §Selective sequencing); for example, if tactic $T$ produces two subgoals and $T_1$ is to be applied to the first while nothing is to be done to the second, then $T$ THENL $[T_1,$ all_tac$]$ is the tactic required.

Splitting logical equivalences

    eq_tac : tactic

Summary: eq_tac splits an equational goal into two implications (the “if-case” and the “only-if” case):

$$ \dfrac{u \Leftrightarrow v}{u\Rightarrow v\qquad v\Rightarrow u} $$

Use: Proving logical equivalences, i.e., goals of the form "$u \Leftrightarrow v$" where $u$ and $v$ are boolean terms. Note that the same end can often be achieved by rewriting with the theorem EQ_IMP_THM, which states $$ \vdash (u \Leftrightarrow v) \Leftrightarrow (u \Rightarrow v) \land (v \Rightarrow u) $$

Solving existential goals

    EXISTS_TAC : term -> tactic

Summary: EXISTS_TAC $u$ reduces an existential goal $\exists x.\;t[x]$ to the subgoal $t[u]$. (In ASCII form, the existential is printed as a question mark.)

$$ \dfrac{\exists x.\;t[x]}{t[u]} $$

Use: Proving existential goals.

Tacticals

A tactical is not represented by a single ML type, but is in general an ML function that returns a tactic (or tactics) as result. Tacticals may take parameters, and this is reflected in the variety of ML types that the built-in tacticals have. Tacticals are used for building compound tactics. Some important tacticals in the HOL system are listed below. For a complete list of the tacticals in HOL see §REFERENCE.

Alternation

    ORELSE : tactic * tactic -> tactic

The tactical ORELSE is an ML infix. If $T_1$ and $T_2$ are tactics, then the ML expression $T_1$ ORELSE $T_2$ evaluates to a tactic which applies $T_1$ unless that fails; if it fails, it applies $T_2$. ORELSE is defined in ML as a curried infix by

   (T1 ORELSE T2) g = T1 g handle HOL_ERR _ => T2 g

First success

    FIRST : tactic list -> tactic

The tactical FIRST applies the first tactic, in a list of tactics, that succeeds.

   FIRST [T1, T2, ..., Tn] = T1 ORELSE T2 ORELSE ... ORELSE Tn

Change detection

    CHANGED_TAC : tactic -> tactic

CHANGED_TAC $T$ $g$ fails if the subgoals produced by $T$ are just [$g$]; otherwise it is equivalent to $T\,g$. It is defined by the following, where

  set_eq: 'a list -> 'a list -> bool

tests whether two lists denote the same set (i.e., contain the same elements).

   fun CHANGED_TAC tac g =
    let val (gl,p) = tac g
    in
      if set_eq gl [g] then raise ERR "CHANGED_TAC" "no change"
      else (gl,p)
    end

Sequencing

>>   : tactic -> tactic -> tactic
   THEN : tactic -> tactic -> tactic
   \\   : tactic -> tactic -> tactic

The tactical >> is an ML infix. Its aliases THEN and \\ are also infixes. If $T_1$ and $T_2$ are tactics, then the ML expression $T_1\;$>>$\;T_2$ evaluates to a tactic which first applies $T_1$ and then applies $T_2$ to each subgoal produced by $T_1$.

Both >> and THEN associate to the left, which can lead to some counter-intuitive behaviours when they combine with other sequencing operators. However, chains of tactics connected with >> behave as one might expect. In particular, if $T_1$ produces $n$ sub-goals, and $T_2$ produces varying numbers of sub-goals when applied to each of those, then the expression $$ T_1 \texttt{ >> } T_2 \texttt{ >> } T_3 $$ will apply $T_3$ to all of the leaf sub-goals generated by the sequencing of $T_1$ and $T_2$.

Selective sequencing

   THENL : tactic -> tactic list -> tactic
   >|    : tactic -> tactic list -> tactic

If tactic $T$ produces $n$ subgoals and $T_1$, $\dots$, $T_n$ are tactics then $T$ >| [$T_1$,$\dots$,$T_n$] is a tactic which first applies $T$ and then applies $T_i$ to the $i$th subgoal produced by $T$. The tactical THENL is useful if one wants to apply different tactics to different subgoals.

Successive application

    EVERY : tactic list -> tactic

The tactical EVERY applies a list of tactics one after the other.

   EVERY [T1, T2, ..., Tn] = T1 >> T2 >> ... >> Tn

Repetition

    REPEAT : tactic -> tactic
    rpt : tactic -> tactic

If $T$ is a tactic then rpt $T$ is a tactic that repeatedly applies $T$ until it fails. It is defined in ML by:

   fun REPEAT T g = ((T THEN REPEAT T) ORELSE ALL_TAC) g

(The extra argument g is needed because ML does not use lazy evaluation.)

Tactics for Manipulating Assumptions

There are in general two kinds of tactics in HOL: those that transform the conclusion of a goal without affecting the assumptions, and those that do (also or only) affect the assumptions. The various tactics that rewrite are typical of the first class; those that do “resolution” belong to the second. Often, many of the steps of a proof in HOL are carried out “behind the scenes” on the assumptions, by tactics of the second sort. A tactic that in some way changes the assumptions must also have a justification that “knows how” to restore the corresponding hypotheses of the theorem achieving the subgoal. All of this is explicit, and can be examined by a user moving about the subgoal-proof tree. Using these tactics in the most straightforward way, the assumptions at any point in a goal-directed proof, i.e., at any node in the subgoal tree, form an unordered record of every assumption made, but not yet dismissed, up to that point.

In practice, the straightforward use of assumption-changing tactics, with the tools currently provided in HOL, presents at least two difficulties. The first is that assumption sets can grow to an unwieldy size, the number and/or length of terms making them difficult to read. In addition, forward-search tactics such as resolution often add at least some assumptions that are never subsequently used, and these have to be carried along with the useful assumptions; the straightforward method provides no ready way of intercepting their arrival. Likewise, there is no straightforward way of discarding assumptions after they have been used and are merely adding to the clutter. Although perhaps against the straightforward spirit, this is a perfectly valid strategy, and requires no more than a way of denoting the specific assumptions to be discarded. That, however, raises the more general problem of denoting assumptions in the first place. Assumptions are also denoted so that they can be manipulated: given as parameters, combined to draw inferences, etc. The only straightforward way to denote them in the existing system is to supply their quoted text. Though adequate, this method may result in bulky ML expressions; and it may take some effort to present the text correctly (with necessary type information, etc.).

As always in HOL, there are quite a few ways around the various difficulties. One approach, of course, is the one intended in the original design of Edinburgh LCF, and advocates the rationale for providing a full programming language, ML, rather than a simple proof command set: that is for the user to implement new tactics in ML. For example, resolution tactics can be adapted by the user to add new assumptions more selectively; and case analysis tactics to make direct replacements without adding case assumptions. This, again, is adequate, but can involve the user in extensive amounts of programming, and in debugging exercises for which there is no system support.

Short of implementing new tactics, two other standard approaches are reflected in the current system. Both were originally developed for Cambridge LCF; both reflect fresh views of the assumptions; and both rely on tacticals that transform tactics. The two approaches are partly but not completely complementary.

The first approach, described in this section, implicitly regards the assumption set, already represented as a list, as a stack, with a pop operation, so that the assumption at the top of the stack can be (i) discarded and (ii) denoted without explicit quotation. (The corresponding push adds new assumptions at the head of the list.) The stack can be generalized to an array to allow for access to arbitrary assumptions.

The other approach, described in §Theorem continuations without popping, gives a way of intercepting and manipulating results without them necessarily being added as assumptions in the first place. The two approaches can be combined in HOL interactions.

Theorem continuations with popping

The first proof style, that of popping assumptions from the assumption “stack”, is illustrated using its main tool: the tactical POP_ASSUM.

    POP_ASSUM : thm_tactic -> tactic
    pop_assum : thm_tactic -> tactic

Given a function $f$:thm -> tactic, the tactic pop_assum $f$ applies $f$ to the (assumed) first assumption of a goal (i.e., to the top element of the assumption stack) and then applies the tactic created thereby to the original goal minus its top assumption:

   pop_assum f ([t1;...;tn], t) = f (ASSUME t1) ([t2;...;tn], t)

ML functions such as $f$, with type thm -> tactic, abbreviated to thm_tactic, are called theorem continuations, suggesting the fact that they take theorems and then continue the proof. The use of pop_assum can be illustrated by applying it to a particular tactic, namely DISCH_TAC.

    DISCH_TAC : tactic

On a goal whose conclusion is an implication $u \Rightarrow v$, DISCH_TAC reflects the natural strategy of attempting to prove $v$ under the assumption $u$, the discharged antecedent. For example, suppose it were required to prove that $(n = 0) \Rightarrow (n\times n = n)$:

> g `(n = 0) ==> (n * n = n)`;
val it =
   Proof manager status: 1 proof.
   1. Incomplete goalstack:
        Initial goal:
        n = 0 ⇒ n * n = n

> e DISCH_TAC;
OK..
1 subgoal:
val it =
   
    0.  n = 0
   ------------------------------------
        n * n = n

Application of DISCH_TAC to the goal produces one subgoal, as shown, with the added assumption. To engage the assumption as a simple substitution, the tactic SUBST1_TAC is useful (see §REFERENCE for details).

    SUBST1_TAC : thm -> tactic

SUBST1_TAC expects a theorem with an equational conclusion, and substitutes accordingly, into the conclusion of the goal. At this point in the session, the tactical POP_ASSUM is applied to SUBST1_TAC to form a new tactic. The new tactic is applied to the current subgoal.

> p();
val it =
   
    0.  n = 0
   ------------------------------------
        n * n = n

> e(pop_assum SUBST1_TAC);
OK..
1 subgoal:
val it =
   
   0 * 0 = 0

The result, as shown, is that the assumption is used as a substitution rule and then discarded. The one subgoal therefore has no assumptions on its stack. The two tactics used thus far could be combined into one using the tactical >>:

> g `(n = 0) ==> (n * n = n)`;
val it =
   Proof manager status: 1 proof.
   1. Incomplete goalstack:
        Initial goal:
        n = 0 ⇒ n * n = n

> e(DISCH_TAC >> pop_assum SUBST1_TAC);
OK..
1 subgoal:
val it =
   
   0 * 0 = 0

The goal can now be solved by simplification of arithmetic:

> e(simp[]);
OK..

Goal proved.
⊢ 0 * 0 = 0
val it =
   Initial goal proved.
   ⊢ n = 0 ⇒ n * n = n: proof

A single tactic can, of course, be written to solve the goal (indeed, the tactic simp[] solves the entire goal from the outset):

> restart();   ... output elided ...

> e(DISCH_TAC >> pop_assum SUBST1_TAC >> simp[]);
OK..
val it =
   Initial goal proved.
   ⊢ n = 0 ⇒ n * n = n: proof

This example illustrates how the tactical pop_assum provides access to the top of the assumption “stack” (a capability that is useful, obviously, only when the most recently pushed assumption is the very one required). To accomplish this access in the straightforward way would require some more awkward construct, with explicit assumptions:

> g `(n = 0) ==> (n * n = n)`;
val it =
   Proof manager status: 1 proof.
   1. Incomplete goalstack:
        Initial goal:
        n = 0 ⇒ n * n = n

> e DISCH_TAC;
OK..
1 subgoal:
val it =
   
    0.  n = 0
   ------------------------------------
        n * n = n

> e(SUBST1_TAC(ASSUME ``n = 0``));
OK..
1 subgoal:
val it =
   
    0.  n = 0
   ------------------------------------
        0 * 0 = 0

In contrast to the above, the popping example also illustrates the convenient disappearance of an assumption no longer required, by removing it from the stack at the moment when it is accessed and used. This is valid because any theorem that achieves the subgoal will still achieve the original goal. Discarding assumptions is a separate issue from accessing them; there could, if one liked, be another tactical that produced a similar tactic on a theorem continuation to pop_assum but which did not pop the stack.

Finally, pop_assum $f$ induces case splits where $f$ does. To prove $(n=0 \lor n=1) \Rightarrow (n\times n = n)$, the function DISJ_CASES_TAC can be used. The tactic

DISJ_CASES_TAC |- $p$\/$q$

splits a goal into two subgoals that have $p$ and $q$, respectively, as new assumptions.

Simply using DISCH_TAC does not cause the disjunction to split when it becomes an assumption.

> g `((n = 0) \/ (n = 1)) ==> (n * n = n)`;
val it =
   Proof manager status: 1 proof.
   1. Incomplete goalstack:
        Initial goal:
        n = 0 ∨ n = 1 ⇒ n * n = n

> e DISCH_TAC;
OK..
1 subgoal:
val it =
   
    0.  n = 0 ∨ n = 1
   ------------------------------------
        n * n = n

So, we can combine pop_assum and DISJ_CASES_TAC to apply the latter to the theorem corresponding to the disjunctive assumption:

> restart();   ... output elided ...

> e(DISCH_TAC >> pop_assum DISJ_CASES_TAC);
OK..
2 subgoals:
val it =
   
    0.  n = 1
   ------------------------------------
        n * n = n
   
    0.  n = 0
   ------------------------------------
        n * n = n

Indeed, we can then combine this with our earlier use of SUBST1_TAC to have both branches make progress at once:

> restart();   ... output elided ...

> e(DISCH_TAC >> pop_assum DISJ_CASES_TAC >> pop_assum SUBST1_TAC);
OK..
2 subgoals:
val it =
   
   1 * 1 = 1
   
   0 * 0 = 0

As noted earlier, pop_assum is useful when an assumption is required that is still at the top of the stack, as in the examples. However, it is often necessary to access assumptions made at arbitrary previous times, in order to give them as parameters, combine them, etc.

Two other useful tacticals that can be used to manipulate the assumption list are first_assum and qpat_assum. The first has an easy characterisation:

   first_assum f ([t1, ..., tn], t) =
    (f(ASSUME t1) ORELSE ... ORELSE f(ASSUME tn)) ([t1, ..., tn], t)

The first_x_assum tactical is similar to first_assum, but in addition to assuming one of the goal's assumptions as a theorem and passing this to the function $f$, the goal-state that $f\,(t_i\vdash t_i)$ acts upon has had $t_i$ removed from the assumption list. It is a “popping” version of first_assum.

The qpat_assum tactical takes a pattern-quotation as its first argument. The second thm_tactic parameter is then passed the first assumption that matches this pattern.

Thus:

   qpat_assum pat f ([t1, ..., tp, ..., tn], t) = f (ASSUME tp) ([t1, ..., tn], t)

where $t_p$ is the first assumption that matches the pattern pat.

Just as with first_assum, there is a “popping” version called qpat_x_assum that removes the matching assumption from the list. Thus:

   qpat_x_assum pat f ([t1, ..., tp, ..., tn], t) =
     f (ASSUME tp) ([t1, ..., tp-1, tp+1, ..., tn], t)

where $t_p$ is the first assumption that matches the pattern pat.

While first_assum (and first_x_assum) try to apply their theorem-tactic to every assumption, eventually using the first that succeeds, qpat_assum (and qpat_x_assum) only apply their theorem-tactic to one assumption (the first that matches).

Theorem continuations without popping

The idea of the second approach is suggested by the way the array-style tacticals supply a list of theorems (the assumed assumptions) to a function. These tacticals use the function to infer new results from the list of theorems, and then to do something with the results. In some cases, e.g., the last example, the assumptions need never have been made in the first place, which suggests a different use of tacticals. The original example for pop_assum illustrates this: namely, to show that $(n = 0) \Rightarrow (n\times n = n)$. Here, instead of discharging the antecedent by applying DISCH_TAC to the goal, which adds the antecedent as an assumption and returns the consequent as the conclusion, and then supplying the (assumed) added assumption to the theorem continuation SUBST1_TAC and discarding it at the same time, a tactical called disch_then is applied to SUBST1_TAC directly. disch_then transforms SUBST1_TAC into a new tactic: one that applies SUBST1_TAC directly to the (assumed) antecedent, and the resulting tactic to a subgoal with no new assumptions and the consequent as its conclusion:

> disch_then;
val it = fn: thm_tactic -> tactic

> disch_then SUBST1_TAC;
val it = fn: tactic

> g `(n = 0) ==> (n * n = n)`;
val it =
   Proof manager status: 1 proof.
   1. Incomplete goalstack:
        Initial goal:
        n = 0 ⇒ n * n = n

> e(disch_then SUBST1_TAC);
OK..
1 subgoal:
val it =
   
   0 * 0 = 0

This gives the same result as the stack method, but more directly, with a more compact ML expression, and with the attractive feature that the term $n=0$ is never an assumption, even for an interval of one step. This technique is often used at the moment when results are available; as above, where the result produced by discharging the antecedent can be immediately passed to substitution. If the result were only needed later, it would have to be held as an assumption. However, results can be manipulated when they are available, and their results either held as assumptions or used immediately. For example, to prove $(0 = n) \Rightarrow (n \times n = n)$, the result $n=0$ could be reversed immediately:

> g `(0 = n) ==> (n * n = n)`;
val it =
   Proof manager status: 1 proof.
   1. Incomplete goalstack:
        Initial goal:
        0 = n ⇒ n * n = n
> e(disch_then(SUBST1_TAC o SYM));
OK..
1 subgoal:
val it =
   
   0 * 0 = 0

The justification of disch_then SUBST1_TAC is easily constructed from the justification of DISCH_TAC composed with the justification of SUBST1_TAC. The term $n=0$ is assumed, to yield the theorem that is passed to the theorem continuation SUBST1_TAC, and it is accordingly discharged during the construction of the actual proof; but the assumption happens only internally to the tactic disch_then SUBST1_TAC, and not as a step in the tactical proof. In other words, the subgoal tree here has one node fewer than before, when an explicit step (DISCH_TAC) reflected the assumption.

On the goal with the disjunctive antecedent, this method again provides a compact tactic:

> g `((n = 0) \/ (n = 1)) ==> (n * n = n)`;
val it =
   Proof manager status: 1 proof.
   1. Incomplete goalstack:
        Initial goal:
        n = 0 ∨ n = 1 ⇒ n * n = n

> e(disch_then(DISJ_CASES_THEN SUBST1_TAC));
OK..
2 subgoals:
val it =
   
   1 * 1 = 1
   
   0 * 0 = 0

This avoids the repeated popping and pushing of the stack solution, and likewise, gives a shorter ML expression. Both give a shorter expression than the direct method, which is:

   DISCH_TAC
    > DISJ_CASES_TAC(ASSUME ``(n = 0) \/ (n = 1)``)
    val it = fn: tactic
    >| [SUBST1_TAC(ASSUME ``n = 0``);
        SUBST1_TAC(ASSUME ``n = 1``)]

To summarize, there are so far at least five ways to solve a goal (and these are often combined in one interaction): directly, using the stack view of the assumptions, using the array view with or without discarding assumptions, and using a tactical to intercept an assumption step. All of the following work on the goal $(n=0) \Rightarrow (n \times n = n)$:

   DISCH_TAC
    > SUBST1_TAC(ASSUME ``n = 0``)
    val it = fn: tactic
    > simp[]
    val it = fn: tactic

   DISCH_TAC
    > pop_assum SUBST1_TAC
    val it = fn: tactic
    > simp[]
    val it = fn: tactic

   disch_then SUBST1_TAC
    > simp[]
    val it = fn: tactic

Furthermore, all induce the same sequence of inferences leading to the desired theorem; internally, no inference steps are saved by the economies in the ML text or the subgoal tree. In this sense, the choice is entirely one of style and taste; of how to organize the decomposition into subgoals. The first expression illustrates the verbosity of denoting assumptions by text (the goal with the disjunctive antecedent gave a clearer example); but also the intelligibility of the resulting expression, which, of course, is all that is saved of the interaction, aside from the final theorem. The last expression illustrates both the elegance and the inscrutibility of using functions to manipulate intermediate results directly, rather than as assumptions. The middle expression shows how results can be used as assumptions (discarded when redundant, if desired); and how assumptions can be denoted without recourse to their text.

It is a strength of the LCF approach to theorem proving that many different proof styles are supported, (all in a secure way) and indeed, can be studied in their own right.

HOL provides several other theorem continuation functions analogous to disch_then and DISJ_CASES_THEN. (Their names always end with _THEN, _THENL or _THEN2.) Some of these do convenient inferences for the user. For example:

    CHOOSE_THEN : thm_tactical

Where thm_tactical abbreviates thm_tactic -> tactic. CHOOSE_THEN $f$ ($\vdash\;\exists x.\;t[x]$) is a tactic that, given a goal, generates the subgoal obtained by applying $f$ to ($t[x]\vdash t[x]$). The intuition is that if |- $\exists x.\,t[x]$ holds then |- $t[x]$ holds for some value of $x$ (as long as the variable $x$ is not free elsewhere in the theorem or current goal). This gives an easy way of using existentially quantified theorems, something that is otherwise awkward.

The new method has other applications as well, including as an implementation technique. For example, taking DISJ_CASES_THEN as basic, DISJ_CASES_TAC can be defined by:

   val DISJ_CASES_TAC = DISJ_CASES_THEN ASSUME_TAC

Similarly, the method is useful for modifying existing tactics (e.g., resolution tactics) without having to re-program them in ML. This avoids the danger of introducing tactics whose justifications may fail, a particularly difficult problem to track down; it is also much easier than starting from scratch.

The main theorem continuation functions in the system are:

   ANTE_RES_THEN
   CHOOSE_THEN      X_CHOOSE_THEN
   CONJUNCTS_THEN   CONJUNCTS_THEN2
   DISJ_CASES_THEN  DISJ_CASES_THEN2   DISJ_CASES_THENL
   DISCH_THEN
   IMP_RES_THEN
   RES_THEN
   STRIP_THM_THEN
   STRIP_GOAL_THEN

See §REFERENCE for full details.

Advanced Tactics and Proof Techniques

Proof Suspension and Resumption

HOL's proof suspension and resumption facilities offer users the ability to structure large source files and proof effort by separating out sub-goals to be proved in separate Theorem-Proof-QED blocks. The first step of the process is to use the suspend tactic to “solve” a subgoal arising in the middle of a normal proof. This tactic has type:

    suspend : string -> bossLib.tactic

The suspend tactic's string argument is the label for the subgoal that is being suspended. When applied, this tactic immediately ends work on this subgoal as if it had been genuinely proved. Interactively, the goal stack will move on to any remaining subgoals in the proof. Theorems that have been “proved” with the help of this tactic are not stored/saved to the current segment (as they are incomplete), and instead a message is emitted indicating as much:

> Theorem to_suspend:
     p /\ q ==> q /\ p
  Proof
      strip_tac >> conj_tac
      >- suspend "rtp_q"
      >- simp[]
  QED
<<HOL message: Stashing suspended theorem to_suspend with pending subgoal: rtp_q.>>
val to_suspend =  [.] ⊢ p ∧ q ⇒ q ∧ p: thm

Here the user has decided to suspend the subgoal that has assumptions p and q (these are produced through the strip_tac application) and conclusion q (the first goal produced by conj_tac). A theorem is bound to the provided name in the SML namespace, but is not yet saved for export (it is incomplete). To resume work on the unproven subgoal, it is necessary to use the Resume form, specifying the theorem name first, and then providing the subgoal name as if it were a theorem/proof attribute. (See Chapter 9 for more on the syntax of attributes.)

Thus:

> Resume to_suspend[rtp_q,smlname=qsubgoal]:
    first_assum ACCEPT_TAC
  QED
val qsubgoal =  [q] ⊢ q: thm

The optional smlname attribute allows for inspection of the theorem corresponding to the sub-goal. To finish their work on the whole theorem, the user must now “finalise” it. This step checks that the theorem has indeed had all of its subgoals proved and saves it, possibly alongside the usual collection of attributes:

> Finalise to_suspend[simp]
val to_suspend =  [] ⊢ p ∧ q ⇒ q ∧ p: thm

If the subgoals associated with a name have not all been proved, the Finalise step will fail. Also, if a theorem has not been finalised by the end of the containing script-file, the theory-saving process will fail with an exception.

Niceties

• If the suspend tactic is called multiple times with the same name within the same goal, resumption at that label will present the user with a complicated looking encoding of multiple goals within just one. In order to convert this one goal back into the multiple goals that were originally saved, the user should use the RESUME_TAC tactic.
• Goals that have been resumed can again be suspend-ed, reusing subgoal names, or not.
• Editor modes should make it easy to create appropriate goals when working interactively; this functionality is in turn making use of the underlying function

    set_suspended_goal :
      {label_name: string, suspension_name: string} -> proofs
  

Core Theories

The HOL system provides a collection of theories on which to base verification tools or further theory development. In the rest of this section, these theories are briefly described. The sections that follow provide an overview of the contents of each theory. For a complete list of all the axioms, definitions and theorems in HOL, see the online resources distributed with the system. In particular, the HTML file help/HOLindex.html is a good place to start browsing the available theories. For a graphical picture of the theory hierarchy, see help/theorygraph/theories.html.

In addition, core theories of higher mathematics are described in Chapter 6.

The Theory min

The starting theory of HOL is the theory min. In this theory, the type constant bool of booleans, the binary type operator $(\alpha,\beta)$fun of functions, and the type constant ind of individuals are declared. Building on these types, three primitive constants are declared: equality, implication, and a choice operator:

Equality

Equality (= : 'a -> 'a -> bool) is an infix operator.

Implication

Implication (==> : bool -> bool -> bool) is the material implication and is an infix operator that is right-associative, i.e., x ==> y ==> z parses to the same term as x ==> (y ==> z).

Choice

Equality and implication are standard predicate calculus notions, but choice is more exotic: if $t$ is a term having type $\sigma\to{}$bool, then @x.$\,t\,$x (or, equivalently, $@$\,t$) denotes some member of the set whose characteristic function is $t$. If the set is empty, then @x.$\,t\,$x denotes an arbitrary member of the set denoted by $\sigma$. The constant @ is a higher order version of Hilbert's $\hilbert$-operator; it is related to the constant $\iota$ in Church's formulation of higher order logic. For more details, see Church's original paper (Church 1940), Leisenring's book on Hilbert's $\hilbert$-symbol (Leisenring 1969), or Andrews' textbook on type theory (Andrews 1986).

No theorems or axioms are placed in theory min. The primitive rules of inference of HOL depend on the presence of min.

Basic Theories

The most basic theories in HOL provide support for a standard collection of types. The theory bool defines the basis of the HOL logic, including the boolean operations and quantifiers. On this platform, quite a bit of theorem-proving infrastructure can already be built. Further basic types are developed in the theory of pairs (prod), disjoint sums (sum), the one-element type (one), and the option type.

The theory bool

At start-up, the initial theory for users of the HOL system is called bool, which is constructed when the HOL system is built. The theory bool is an extension of the combination of the “conceptual” theories LOG and INIT, described in the LOGIC manual. Thus it contains the four axioms for higher order logic. These axioms, together with the rules of inference described in Section 1.5.1, constitute the core of the HOL logic. Because of the way the HOL system evolved from LCF¹, the particular axiomatization of higher order logic it uses differs from the classical axiomatization due to Church (Church 1940). The biggest difference is that in Church's formulation type variables are in the meta-language, whereas in the HOL logic they are part of the object language.

The logical constants T (truth), F (falsity), ~ (negation), /\ (conjunction), \/ (disjunction), ! (universal quantification), ? (existential quantification), and ?! (unique existence quantifier) can all be defined in terms of equality, implication and choice. The definitions listed below are fairly standard; each one is preceded by its ML name. Later definitions sometimes build on earlier ones.

   T_DEF              |- T  = ((\x:bool. x) = (\x. x))

   FORALL_DEF         |- !  = \P:'a->bool. P = (\x. T)

   EXISTS_DEF         |- ?  = \P:'a->bool. P($@ P)

   AND_DEF            |- /\ = \t1 t2. !t. (t1 ==> t2 ==> t) ==> t

   OR_DEF             |- \/ = \t1 t2. !t. (t1 ==> t) ==> (t2 ==> t) ==> t

   F_DEF              |- F  = !t. t

   NOT_DEF            |- ~  = (\t. t ==> F)

   EXISTS_UNIQUE_DEF  |- ?! = (\P. $? P /\ (!x y. P x /\ P y ==> (x = y)))

There are four axioms in the theory bool; the first three are the following:

BOOL_CASES_AX
  ⊢ ∀t. (t ⇔ T) ∨ (t ⇔ F)

ETA_AX
  ⊢ ∀t. (λx. t x) = t

SELECT_AX
  ⊢ ∀P x. P x ⇒ P ($@ P)

The fourth and last axiom of the HOL logic is the Axiom of Infinity. Its statement is phrased in terms of the function properties ONE_ONE and ONTO. The definitions are:

ONE_ONE_DEF
  ⊢ ONE_ONE = (λf. ∀x1 x2. f x1 = f x2 ⇒ x1 = x2)
ONTO_DEF
  ⊢ ONTO = (λf. ∀y. ∃x. y = f x)

The Axiom of Infinity is

INFINITY_AX
  ⊢ ∃f. ONE_ONE f ∧ ¬ONTO f

This asserts that there exists a one-to-one map from ind to itself that is not onto. This implies that the type ind denotes an infinite set.

The three other axioms of the theory bool, the rules of inference in Section 1.5.1 and the Axiom of Infinity are, together, sufficient for developing all of standard mathematics. Thus, in principle, the user of the HOL system should never need to make a non-definitional theory. In practice, it is often very tempting to take the risk of introducing new axioms because deriving them from definitions can be tedious---proving that ‘axioms’ follow from definitions amounts to proving their consistency.

Further definitions. The theory bool also supplies the definitions of a number of useful constants.

LET_DEF
  ⊢ LET = (λf x. f x)
COND_DEF
  ⊢ COND =
     (λt t1 t2. @x. ((t ⇔ T) ⇒ x = t1) ∧ ((t ⇔ F) ⇒ x = t2))
IN_DEF
  ⊢ $IN = (λx f. f x)

The constant LET is used in representing terms containing local variable bindings (i.e., let-terms). For example, the concrete syntax let v = M in N is translated by the parser to the term LET (\v.N) M. For the full description of how let expressions are translated, see Section 5.2.3.2.

The constant COND is used to represent conditional expressions. The concrete syntax $\mathtt{if}\;t_1\;\mathtt{then}\;t_2\;\mathtt{else}\;t_3$ abbreviates the application COND $t_1$ $t_2$ $t_3$.

The constant IN (written as an infix) is the basis of the modelling of sets by their characteristic functions. The term $x$IN$P$ can be read as "$x$ is an element of the set $P$", or (more in line with its definition) as “the predicate $P$ is true of $x$”.

Finally, the polymorphic constant ARB$:\alpha$ denotes a fixed but arbitrary element. ARB is occasionally useful when attempting to deal with the issue of partiality.

Restricted quantifiers

The theory bool also defines constants that implement restricted quantification. This provides a means of simulating subtypes and dependent types with predicates. The most heavily used are restrictions of the existential and universal quantifiers:

RES_FORALL_DEF
  ⊢ RES_FORALL = (λp m. ∀x. x ∈ p ⇒ m x)
RES_EXISTS_DEF
  ⊢ RES_EXISTS = (λp m. ∃x. x ∈ p ∧ m x)

RES_ABSTRACT_DEF
  ⊢ (∀p m x. x ∈ p ⇒ RES_ABSTRACT p m x = m x) ∧
     ∀p m1 m2.
       (∀x. x ∈ p ⇒ m1 x = m2 x) ⇒
       RES_ABSTRACT p m1 = RES_ABSTRACT p m2

The definition of RES_ABSTRACT is a characterising formula, rather than a direct equation. There are two important properties

• if $y$ is an element of $P$ then $(\lambda x :: P.\; M)\,y = M[y/x]$
• if two restricted abstractions agree on all values over their (common) restricting set, then they are equal.

For completeness, restricted versions of unique existence and indefinite description are provided, although hardly used.

RES_EXISTS_UNIQUE_DEF
  ⊢ RES_EXISTS_UNIQUE =
     (λp m. (∃x::p. m x) ∧ ∀x y::p. m x ∧ m y ⇒ x = y)
RES_SELECT_DEF
  ⊢ RES_SELECT = (λp m. @x. x ∈ p ∧ m x)

The definition of RES_EXISTS_UNIQUE uses the restricted quantification syntax with the :: symbol, referring to the earlier definitions RES_EXISTS and RES_FORALL. The :: syntax is used with restricted quantifiers to allow arbitrary predicates to restrict binding variables. The HOL parser allows restricted quantification of all of a sequence of binding variables by putting the restriction at the end of the sequence, thus with a universal quantification:

$$ \forall x \, y \, z \, {\tt ::} \; P \, . \; Q(x,y,z) $$

Here the predicate $P$ restricts all of $x$, $y$ and $z$.

Derived syntactic forms

The HOL quotation parser can translate various standard logical notations into primitive terms. For example, if + has been declared an infix (as explained in Section 1.6), as it is when arithmeticTheory has been loaded, then x+1 is translated to $+ x 1 . The escape character $ suppresses the infix behaviour of + and prevents the quotation parser getting confused. In general, $ can be used to suppress any special syntactic behaviour a token (such as if, + or let) might have. This is illustrated in the table below, in which the terms in the column headed ML quotation are translated by the quotation parser to the corresponding terms in the column headed Primitive term. Conversely, the terms in the latter column are always printed in the form shown in the former one. The ML constructor expressions in the rightmost column evaluate to the same values (of type term) as the other quotations in the same row.

Table: Non-primitive terms

There are constructors, destructors and indicators for all the obvious constructs. (Indicators, e.g., is_neg, return truth values indicating whether or not a term belongs to the syntax class in question.) In addition to the constructors listed in the table there are constructors, destructors, and indicators for pairs and lists, namely mk_pair, mk_cons and mk_list (see the REFERENCE manual). The constants COND and LET are explained in the section on The theory bool above. The constants \/, /\, ==> and = are examples of infixes and represent $\vee$, $\wedge$, $\Rightarrow$ and equality, respectively. If $c$ is declared to be an infix, then the HOL parser will translate $t_1\;c\;t_2$ to $\mathtt{\$}c;t_1;t_2$.

The constants !, ? and @ are examples of *binders* and represent $\forall$, $\exists$ and $\hilbert$, respectively. If $c$ is declared to be a binder, then the HOL parser will translate $c;x.t$ to the combination $\mathtt{$}c\,(\lambda x.\,t)$ (i.e., the application of the constant $c$ to the representation of the abstraction $\lambda x.\,t$).

Table: Syntactic abbreviations

There are also constructors list_mk_conj, list_mk_disj, list_mk_imp for conjunctions, disjunctions, and implications respectively. The corresponding destructor functions are called strip_comb etc.

Theorems

A large number of theorems involving the logical constants are pre-proved in the theory bool. The following theorems illustrate how higher order logic allows concise expression of theorems supporting quantifier movement.

 LEFT_AND_FORALL_THM  |- !P Q. (!x. P x) /\ Q = !x. P x /\ Q
 RIGHT_AND_FORALL_THM |- !P Q. P /\ (!x. Q x) = !x. P /\ Q x

 LEFT_EXISTS_AND_THM  |- !P Q. (?x. P x /\ Q) = (?x. P x) /\ Q
 RIGHT_EXISTS_AND_THM |- !P Q. (?x. P /\ Q x) = P /\ ?x. Q x

 LEFT_FORALL_IMP_THM  |- !P Q. (!x. P x ==> Q) = (?x. P x) ==> Q
 RIGHT_FORALL_IMP_THM |- !P Q. (!x. P ==> Q x) = P ==> !x. Q x

 LEFT_EXISTS_IMP_THM  |- !P Q. (?x. P x ==> Q) = (!x. P x) ==> Q
 RIGHT_EXISTS_IMP_THM |- !P Q. (?x. P ==> Q x) = P ==> ?x. Q x

 LEFT_FORALL_OR_THM   |- !Q P. (!x. P x \/ Q) = (!x. P x) \/ Q
 RIGHT_FORALL_OR_THM  |- !P Q. (!x. P \/ Q x) = P \/ !x. Q x

 LEFT_OR_EXISTS_THM   |- !P Q. (?x. P x) \/ Q = ?x. P x \/ Q
 RIGHT_OR_EXISTS_THM  |- !P Q. P \/ (?x. Q x) = ?x. P \/ Q x

 EXISTS_OR_THM        |- !P Q. (?x. P x \/ Q x) = (?x. P x) \/ ?x. Q x
 FORALL_AND_THM       |- !P Q. (!x. P x /\ Q x) = (!x. P x) /\ !x. Q x

 NOT_EXISTS_THM       |- !P. ~(?x. P x) = !x. ~P x
 NOT_FORALL_THM       |- !P. ~(!x. P x) = ?x. ~P x

 SKOLEM_THM           |- !P. (!x. ?y. P x y) = ?f. !x. P x (f x)

Also, a theorem justifying Skolemization (SKOLEM_THM) is proved. Many other theorems may be found in bool theory.

Combinators

The theory combin contains the definitions of function composition (infixed o), a reversed function application operator, function override (infixed =+), and the combinators S, K, I, W, and C.

o_DEF
  ⊢ ∀f g. f ∘ g = (λx. f (g x))
APP_DEF
  ⊢ ∀x f. (x :> f) = f x
UPDATE_def
  ⊢ ∀a b. (a =+ b) = (λf c. if a = c then b else f c)
K_DEF
  ⊢ K = (λx y. x)
S_DEF
  ⊢ S = (λf g x. f x (g x))
I_DEF
  ⊢ I = S K K
W_DEF
  ⊢ W = (λf x. f x x)
C_DEF
  ⊢ flip = (λf x y. f y x)

The following elementary properties are proved in the theory combin:

o_THM
  ⊢ ∀f g x. (f ∘ g) x = f (g x)
o_ASSOC
  ⊢ ∀f g h. f ∘ g ∘ h = (f ∘ g) ∘ h

UPDATE_EQ
  ⊢ ∀f a b c. f⦇a ↦ c; a ↦ b⦈ = f⦇a ↦ c⦈
UPDATE_COMMUTES
  ⊢ ∀f a b c d. a ≠ b ⇒ f⦇a ↦ c; b ↦ d⦈ = f⦇b ↦ d; a ↦ c⦈
APPLY_UPDATE_THM
  ⊢ ∀f a b c. f⦇a ↦ b⦈ c = if a = c then b else f c

K_THM
  ⊢ ∀x y. K x y = x
S_THM
  ⊢ ∀f g x. S f g x = f x (g x)
I_THM
  ⊢ ∀x. I x = x
W_THM
  ⊢ ∀f x. W f x = f x x
C_THM
  ⊢ ∀f x y. flip f x y = f y x

The above illustrates that there are two ways of writing function update terms. As per the definition above (UPDATE_def), the infix =+ takes a key $k$ and a value $v$, and returns a higher-order function, which when in turn is passed a function $f$, returns a version of that function that has been updated to return $v$ when applied to $k$, and is otherwise the same as $f$. The same effect can be achieved with the “substitution style” syntax: $f\llparenthesis k\mapsto v\rrparenthesis$. There is an ASCII form of this notation as well:

> ``(k2 =+ v2) ((k1 =+ v1) f)``;
<<HOL message: inventing new type variable names: 'a, 'b>>
val it = “f⦇k2 ↦ v2; k1 ↦ v1⦈”: term
> ``f (| k |-> v |)``;
<<HOL message: inventing new type variable names: 'a, 'b>>
val it = “f⦇k ↦ v⦈”: term

There are no theorems about :>; its use is as a convenient syntax for function applications. For example, chains of updates can lose some parentheses if written

   f :> (k1 =+ v1) :> (k2 =+ v2) :> (k3 =+ v3)

This presentation also makes the order in which functions are applied read from left-to-right.

Having the symbols o, S, K, I, W, and C as built-in constants is sometimes inconvenient because they are often wanted as mnemonic names for variables (e.g., S to range over sets and o to range over outputs).² Variables with these names can be used in the current system if o, S, K, I, W, and C are first hidden (see Section 8.1.2.8). In fact, this happens so often with the constant C that the name C is “hidden” by default. Instead, it can be written in fully-qualified form, as combin$C, or with the alias flip, as can be seen above.

Pairs

The Cartesian product type operator prod is defined in the theory pair. Values of type ($\sigma_1$,$\sigma_2$)prod are ordered pairs whose first component has type $\sigma_1$ and whose second component has type $\sigma_2$. The HOL type parser converts type expressions of the form :$\sigma_1$#$\sigma_2$ into ($\sigma_1$,$\sigma_2$)prod, and the printer inverts this transformation. Pairs are constructed with an infixed comma symbol

   $, : 'a -> 'b -> 'a # 'b

so, for example, if $t_1$ and $t_2$ have types $\sigma_1$ and $\sigma_2$ respectively, then $t_1$,$t_2$ is a term with type $\sigma_1$#$\sigma_2$. Usually, pairs are written within brackets: ($t_1$,$t_2$). The comma symbol associates to the right, so that ($t_1$,$t_2$,$\ldots$,$t_n$) means ($t_1$,($t_2$,$\ldots$,$t_n$)).

Defining the product type. The type of Cartesian products is defined by representing a pair ($t_1$,$t_2$) by the function

   \a b. (a = t1) /\ (b = t2)

The representing type of $\sigma_1$#$\sigma_2$ is thus $\sigma_1$->$\sigma_2$->bool. It is easy to prove the following theorem.³

   |- ?p:'a->'b->bool. (\p. ?x y. p = \a b. (a = x) /\ (b = y)) p

The type operator prod is defined by invoking new_type_definition with this theorem which results in the definitional axiom prod_TY_DEF shown below being asserted in the theory pair.

prod_TY_DEF
  ⊢ ∃rep.
       TYPE_DEFINITION (λp. ∃x y. p = (λa b. a = x ∧ b = y)) rep

Next, the representation and abstraction functions REP_prod and ABS_prod for the new type are introduced, along with the following characterizing theorem, by use of the function define_new_type_bijections.

ABS_REP_prod
  ⊢ (∀a. ABS_prod (REP_prod a) = a) ∧
     ∀r. (λp. ∃x y. p = (λa b. a = x ∧ b = y)) r ⇔
         REP_prod (ABS_prod r) = r

Pairs and projections. The infix constructor ',' is then defined to be an application of the abstraction function. Subsequently, two crucial theorems are proved: PAIR_EQ asserts that equal pairs have equal components and ABS_PAIR_THM shows that every term having a product type can be decomposed into a pair of terms.

COMMA_DEF
  ⊢ ∀x y. (x,y) = ABS_prod (λa b. a = x ∧ b = y)
PAIR_EQ
  ⊢ (x,y) = (a,b) ⇔ x = a ∧ y = b
ABS_PAIR_THM
  ⊢ ∀x. ∃q r. x = (q,r)

By Skolemizing ABS_PAIR_THM and making constant specifications for FST and SND, the following theorems are proved.

PAIR
  ⊢ ∀x. (FST x,SND x) = x
FST
  ⊢ ∀x y. FST (x,y) = x
SND
  ⊢ ∀x y. SND (x,y) = y

Pairs and functions. In HOL, a function of type $\alpha\#\beta\to\gamma$ always has a counterpart of type $\alpha\to\beta\to\gamma$, and vice versa. This conversion is accomplished by the functions CURRY and UNCURRY. These functions are inverses.

CURRY_DEF
  ⊢ ∀f x y. CURRY f x y = f (x,y)
UNCURRY_DEF
  ⊢ ∀f x y. UNCURRY f (x,y) = f x y

CURRY_UNCURRY_THM
  ⊢ ∀f. CURRY (UNCURRY f) = f
UNCURRY_CURRY_THM
  ⊢ ∀f. UNCURRY (CURRY f) = f

Mapping functions over a pair. Functions $f:\alpha\to\gamma_1$ and $g:\beta\to\gamma_2$ can be applied component-wise (##, infix) over a pair of type $\alpha\#\beta$ to obtain a pair of type $\gamma_1\#\gamma_2$.

PAIR_MAP_THM
  ⊢ ∀f g x y. (f ## g) (x,y) = (f x,g y)

Binders and pairs. When doing proofs, statements involving tuples may take the form of a binding (quantification or $\lambda$-abstraction) of a variable with a product type. It may be convenient in subsequent reasoning steps to replace the variables with tuples of variables. The following theorems support this.

FORALL_PROD
  ⊢ (∀p. P p) ⇔ ∀p_1 p_2. P (p_1,p_2)
EXISTS_PROD
  ⊢ (∃p. P p) ⇔ ∃p_1 p_2. P (p_1,p_2)
LAMBDA_PROD
  ⊢ ∀P. (λp. P p) = (λ(p1,p2). P (p1,p2))

The theorem LAMBDA_PROD involves a paired abstraction, discussed in Section 5.2.3.1.

Wellfounded relations on pairs. Wellfoundedness, defined in Section 5.3.1.4, is a useful notion, especially for proving termination of recursive functions. For pairs, the lexicographic combination of relations (LEX, infix) may be defined by using paired abstractions. Then the theorem that lexicographic combination of wellfounded relations delivers a wellfounded relation is easy to prove.

LEX_DEF
  ⊢ ∀R1 R2. R1 LEX R2 = (λ(s,t) (u,v). R1 s u ∨ s = u ∧ R2 t v)
WF_LEX
  ⊢ ∀R Q. WF R ∧ WF Q ⇒ WF (R LEX Q)

Paired abstractions

It is notationally convenient to include pairing in the lambda notation, as a simple pattern-matching mechanism. The quotation parser will convert the term \($x_1$,$x_2$).$t$ to UNCURRY(\$x_1\,x_2$.$t$). The transformation is done recursively so that, for example,

   \(x1, x2, x3). t

is converted to

   UNCURRY (\x1. UNCURRY(\x2 x3. t))

More generally, the quotation parser repeatedly applies the transformation:

$$ \mathtt{\backslash(}v_1\mathtt{,}v_2\mathtt{).}t \quad\leadsto\quad \mathtt{UNCURRY(\backslash}v_1\mathtt{.\backslash}v_2\mathtt{.}t\mathtt{)} $$

until no more variable structures remain. For example:

$$ \begin{aligned} \mathtt{\backslash(}x\mathtt{,}y\mathtt{).}t &\;\leadsto\; \mathtt{UNCURRY(\backslash}x\,y\mathtt{.}t\mathtt{)}\\ \mathtt{\backslash(}x_1\mathtt{,}x_2\mathtt{,}\ldots\mathtt{,}x_n\mathtt{).}t &\;\leadsto\; \mathtt{UNCURRY(\backslash}x_1\mathtt{.\backslash(}x_2\mathtt{,}\ldots\mathtt{,}x_n\mathtt{).}t\mathtt{)}\\ \mathtt{\backslash((}x_1\mathtt{,}\ldots\mathtt{,}x_n\mathtt{),}y_1\mathtt{,}\ldots\mathtt{,}y_m\mathtt{).}t &\;\leadsto\; \mathtt{UNCURRY(\backslash(}x_1\mathtt{,}\ldots\mathtt{,}x_n\mathtt{).\backslash(}y_1\mathtt{,}\ldots\mathtt{,}y_m\mathtt{).}t\mathtt{)} \end{aligned} $$

As a result of this parser translation, a variable structure, such as (x,y) in \(x,y).x+y, is not a subterm of the abstraction in which it occurs; it disappears on parsing. This can lead to unexpected errors (accompanied by obscure error messages). For example, antiquoting a pair into the bound variable position of a lambda abstraction fails:

> ``\(x,y).x+y``;
val it = “λ(x,y). x + y”: term

> val p = Term `(x:num,y:num)`;
val p = “(x,y)”: term

> Lib.try Term `\^p.x+y` handle _ => T

Exception raised at Term.dest_var: not a var
val it = “T”: term

If $b$ is a binder, then `b(x_1,x_2).t` is parsed as `b(\(x_1,x_2).t)`, and hence transformed as above. For example, !(x,y). x > y parses to $!(UNCURRY(\x.\y. x > y)).

let-terms

The quotation parser accepts let-terms similar to those in ML. For example, the following terms are allowed:

   let x = 1 and y = 2 in x+y

   let f(x,y) = (x*x)+(y*y); a = 20*20; b = 50*49 in f(a,b)

let-terms are actually abbreviations for ordinary terms which are specially supported by the parser and pretty printer. The constant LET is defined (in the theory bool) by:

   LET = (\f x. f x)

and is used to encode let-terms in the logic. The parser repeatedly applies the transformations:

$$ \begin{aligned} \mathtt{let}\ f\,v_1\,\ldots\,v_n=t_1\ \mathtt{in}\ t_2 &\;\leadsto\; \mathtt{LET(\backslash} f\mathtt{.}t_2\mathtt{)(\backslash} v_1\,\ldots\,v_n\mathtt{.}t_1\mathtt{)}\\ \mathtt{let}\ (v_1,\ldots,v_n)=t_1\ \mathtt{in}\ t_2 &\;\leadsto\; \mathtt{LET(\backslash(}v_1\mathtt{,}\ldots\mathtt{,}v_n\mathtt{).}t_2\mathtt{)}t_1\\ \mathtt{let}\ v_1=t_1\,\mathtt{and}\,\ldots\,\mathtt{and}\,v_n=t_n\ \mathtt{in}\ t &\;\leadsto\; \mathtt{LET(\ldots(LET(LET(\backslash}v_1\ldots v_n\mathtt{.} t\mathtt{)}t_1\mathtt{)}t_2\mathtt{)\ldots)}t_n \end{aligned} $$

The underlying structure of the term can be seen by applying destructor operations. For example:

> Term `let x = 1; y = 2; in x+y`;
val it = “let x = 1; y = 2 in x + y”: term

> dest_comb it;
val it = (“LET (λx. (let y = 2 in x + y))”, “1”): term * term

> Term `let (x,y) = (1,2) in x+y`;
val it = “let (x,y) = (1,2) in x + y”: term

> dest_comb it;
val it = (“LET (λ(x,y). x + y)”, “(1,2)”): term * term

Readers are encouraged to convince themselves that the translations of let-terms represent the intuitive meaning suggested by the surface syntax.

Disjoint sums

The theory sum defines the binary disjoint union type operator sum. A type ($\sigma_1$,$\sigma_2$)sum denotes the disjoint union of types $\sigma_1$ and $\sigma_2$. The type operator sum can be defined, just as prod was, but the details are omitted here.⁴ The HOL parser converts :$\sigma_1$+$\sigma_2$`` `` into `` ``:($\sigma_1$,$\sigma_2$`)sum , and the printer inverts this.

The standard operations on sums are:

   INL  : 'a -> 'a + 'b
   INR  : 'b -> 'a + 'b
   ISL  : 'a + 'b -> bool
   ISR  : 'a + 'b -> bool
   OUTL : 'a + 'b -> 'a
   OUTR : 'a + 'b -> 'b

These are all defined as constants in the theory sum. The constants INL and INR inject into the left and right summands, respectively. The constants ISL and ISR test for membership of the left and right summands, respectively. The constants OUTL and OUTR project from a sum to the left and right summands, respectively.

The following theorem is proved in the theory sum. It provides a complete and abstract characterization of the disjoint sum type, and is used to justify the definition of functions over sums.

sum_Axiom
  ⊢ ∀f g. ∃h. (∀x. h (INL x) = f x) ∧ ∀y. h (INR y) = g y

Also provided are the following theorems having to do with the discriminator functions ISL and ISR:

ISL
  ⊢ (∀x. ISL (INL x) ⇔ T) ∧ ∀y. ISL (INR y) ⇔ F
ISR
  ⊢ (∀x. ISR (INR x) ⇔ T) ∧ ∀y. ISR (INL y) ⇔ F

ISL_OR_ISR
  ⊢ ∀x. ISL x ∨ ISR x

The sum theory also provides the following theorems relating the projection functions and the discriminators.

OUTL
  ⊢ ∀x. OUTL (INL x) = x
OUTR
  ⊢ ∀x. OUTR (INR x) = x

INL
  ⊢ ∀x. ISL x ⇒ INL (OUTL x) = x
INR
  ⊢ ∀x. ISR x ⇒ INR (OUTR x) = x

The sum type operator can be seen as functorial over its arguments and so has a “map” function, SUM_MAP, with definition and results showing its functoriality:

SUM_MAP_def
  ⊢ (∀f g a. SUM_MAP f g (INL a) = INL (f a)) ∧
     ∀f g b. SUM_MAP f g (INR b) = INR (g b)
SUM_MAP_I
  ⊢ SUM_MAP I I = I
SUM_MAP_o
  ⊢ SUM_MAP f g ∘ SUM_MAP h k = SUM_MAP (f ∘ h) (g ∘ k)

The one-element type

The theory one defines the type one which contains one element. The type is also abbreviated as unit, which is the name of the analogous type in ML, and this is the type's preferred printing form. The constant one denotes this one element, but, again by analogy with ML, the preferred parsing and printing form for this constant is ().⁵ The pre-proved theorems in the theory one are:

one_axiom
  ⊢ ∀(f :α -> unit) (g :α -> unit). f = g
one
  ⊢ ∀(v :unit). v = ()
one_Axiom
  ⊢ ∀(e :α). ∃!(fn :unit -> α). fn () = e

These three theorems are equivalent characterizations of the type with only one value. The theory one is typically used in constructing more elaborate types.

The itself type

The unary itself type operator (in boolTheory) provides a family of singleton types akin to one. Thus, for every type $\alpha$, `α itself` is a type containing just one value. This value's name is the_value, but the parser and pretty-printer are set up so that for the type `α itself`, the_value can be written as `(:α)` (the syntax includes the parentheses). For example, (:num) is the single value inhabiting the type num itself.

The point of the itself type is that if one defines a function with `α itself` as the domain, the function picks out just one value in its range, and so one can think of the function as being one from the type to a value for the whole type.

For example, one could define

   finite_univ (:'a) = FINITE (UNIV :'a set)

It would then be straightforward to prove the following theorems

   ⊢ finite_univ(:bool)
   ⊢ ¬finite_univ(:num)
   ⊢ finite_univ(:'a) ∧ finite_univ(:'b) ⇒ finite_univ(:'a # 'b)

The itself type is used in the Finite Cartesian Product construction that underlies the fixed-width word type (see Section 5.3.8 below).

The option type

The theory option defines a type operator option that ‘lifts’ its argument type, creating a type with all of the values of the argument and one other, specially distinguished value. The constructors of this type are

   NONE : 'a option
   SOME : 'a -> 'a option

Options can be used to model partial functions. If a function of type $\alpha\rightarrow\beta$ does not have useful $\beta$ values for all $\alpha$ inputs, then this distinction can be marked by making the range of the function $\beta\,$option, and mapping the undefined $\alpha$ values to NONE.

An inductive type, options have a recursion theorem supporting the definition of primitive recursive functions over option values.

option_Axiom
  ⊢ ∀e f. ∃fn. fn NONE = e ∧ ∀x. fn (SOME x) = f x

The option theory also defines a case constant that allows one to inspect option values in a “pattern-matching” style.

   case e of
     NONE => u
   | SOME x => f x

The constant underlying this syntactic sugar is option_CASE with definition

option_case_def
  ⊢ (∀v f. option_CASE NONE v f = v) ∧
     ∀x v f. option_CASE (SOME x) v f = f x

Another useful function maps a function over an option:

OPTION_MAP_DEF
  ⊢ (∀f x. OPTION_MAP f (SOME x) = SOME (f x)) ∧
     ∀f. OPTION_MAP f NONE = NONE

Finally, the THE function takes a SOME value to that constructor's argument, and is unspecified on NONE:

THE_DEF
  ⊢ ∀x. THE (SOME x) = x

Numbers

The natural numbers, integers, and real numbers are provided in a series of theories. Also available are theories of extended real numbers, $n$-bit words (numbers modulo $2^n$), floating point and fixed point numbers.

Natural numbers

The natural numbers are developed in a series of theories: num, prim_rec, arithmetic, and numeral. In num, the type of numbers is defined from the Axiom of Infinity, and Peano's axioms are derived. In prim_rec the Primitive Recursion theorem is proved. Based on that, a large theory treating the standard arithmetic operations is developed in arithmetic. Lastly, a theory of numerals is developed in numeral.

The theory num

The theory num defines the type num of natural numbers to be isomorphic to a countable subset of the primitive type ind. In this theory, the constants 0 and SUC (the successor function) are defined and Peano's axioms pre-proved in the form:

NOT_SUC
  ⊢ ∀n. SUC n ≠ 0
INV_SUC
  ⊢ ∀m n. SUC m = SUC n ⇒ m = n
INDUCTION
  ⊢ ∀P. P 0 ∧ (∀n. P n ⇒ P (SUC n)) ⇒ ∀n. P n

In higher order logic, Peano's axioms are sufficient for developing number theory because addition and multiplication can be defined. In first order logic these must be taken as primitive. Note also that INDUCTION could not be stated as a single axiom in first order logic because predicates (e.g., P) cannot be quantified.

The theory prim_rec

In classical logic, unlike domain theory logics such as PP$\lambda$, arbitrary recursive definitions are not allowed. For example, there is no function $f$ (of type num->num) such that

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

Certain restricted forms of recursive definition do, however, uniquely define functions. An important example are the primitive recursive functions.⁶ For any $x$ and $f$ the primitive recursion theorem tells us that there is a unique function fn such that:

   (fn 0 = x) /\ (!n. fn(SUC n) = f (fn n) n)

The primitive recursion theorem, named num_Axiom in HOL, follows from Peano's axioms.

num_Axiom
  ⊢ ∀e f. ∃fn. fn 0 = e ∧ ∀n. fn (SUC n) = f n (fn n)

The theorem states the validity of primitive recursive definitions on the natural numbers: for any x and f there exists a corresponding total function fn which satisfies the primitive recursive definition whose form is determined by x and f.

The less-than relation. The less-than relation '<' is most naturally defined by primitive recursion. However, in our development it is needed for the proof of the primitive recursion theorem, so it must be defined before definition by primitive recursion is available. The theory prim_rec therefore contains the following non-recursive definition of <:

LESS_DEF
  ⊢ ∀m n. m < n ⇔ ∃P. (∀n. P (SUC n) ⇒ P n) ∧ P m ∧ ¬P n

This definition says that m < n if there exists a set (with characteristic function P) that is downward closed⁷ and contains m but not n.

Mechanizing primitive recursive definitions

The primitive recursion theorem can be used to justify any definition of a function on the natural numbers by primitive recursion. For example, a primitive recursive definition in higher order logic of the form

$$ \begin{aligned} \mathtt{fun}\,0\,x_1\,\ldots\,x_i &= f_1[x_1,\ldots,x_i]\\ \mathtt{fun}\,(\mathtt{SUC}\,n)\,x_1\,\ldots\,x_i &= f_2[\mathtt{fun}\,n\,t_1\,\ldots\,t_i,\,n,\,x_1,\ldots,x_i] \end{aligned} $$

where all the free variables in the terms $t_1,\ldots,t_i$ are contained in $\{n,x_1,\ldots,x_i\}$, is logically equivalent to:

$$ \begin{aligned} \mathtt{fun}\,0 &= \lambda x_1\,\ldots\,x_i.\,f_1[x_1,\ldots,x_i]\\ \mathtt{fun}\,(\mathtt{SUC}\,n) &= \lambda x_1\,\ldots\,x_i.\,f_2[\mathtt{fun}\,n\,t_1\,\ldots\,t_i,\,n,\,x_1,\ldots,x_i]\\ &= (\lambda f\,n\,x_1\,\ldots\,x_i.\,f_2[f\,t_1\,\ldots\,t_i,\,n,\,x_1,\ldots,x_i])\,(\mathtt{fun}\,n)\,n \end{aligned} $$

The existence of a recursive function fun which satisfies these two equations follows directly from the primitive recursion theorem num_Axiom shown above. Specializing the quantified variables x and f in a suitably type-instantiated version of num_Axiom so that

$$ \begin{aligned} x &= \lambda x_1\,\ldots\,x_i.\,f_1[x_1,\ldots,x_i]\quad\text{and}\\ f &= \lambda f\,n\,x_1\,\ldots\,x_i.\,f_2[f\,t_1\,\ldots\,t_i,\,n,\,x_1,\ldots,x_i] \end{aligned} $$

yields the existence theorem shown below:

$$ \begin{aligned} \vdash\,\exists\mathtt{fn}.\, &\mathtt{fn}\,0 = \lambda x_1\,\ldots\,x_i.\,f_1[x_1,\ldots,x_i]\;\wedge\\ &\mathtt{fn}\,(\mathtt{SUC}\,n) = (\lambda f\,n\,x_1\,\ldots\,x_i.\,f_2[f\,t_1\,\ldots\,t_i,\,n,\,x_1,\ldots,x_i])\,(\mathtt{fn}\,n)\,n \end{aligned} $$

This theorem allows a constant fun to be introduced (via the definitional mechanism of constant specifications—see Section 1.6.3.2) to denote the recursive function that satisfies the two equations in the body of the theorem. Introducing a constant fun to name the function asserted to exist by the theorem shown above, and simplifying using $\beta$-reduction, yields the following theorem:

$$ \begin{aligned} \vdash\, &\mathtt{fun}\,0 = \lambda x_1\,\ldots\,x_i.\,f_1[x_1,\ldots,x_i]\;\wedge\\ &\mathtt{fun}\,(\mathtt{SUC}\,n) = \lambda x_1\,\ldots\,x_i.\,f_2[\mathtt{fun}\,n\,t_1\,\ldots\,t_i,\,n,\,x_1,\ldots,x_i] \end{aligned} $$

It follows immediately from this theorem that the constant fun satisfies the primitive recursive defining equations given by the theorem shown below:

$$ \begin{aligned} \vdash\, &\mathtt{fun}\,0\,x_1\,\ldots\,x_i = f_1[x_1,\ldots,x_i]\\ &\mathtt{fun}\,(\mathtt{SUC}\,n)\,x_1\,\ldots\,x_i = f_2[\mathtt{fun}\,n\,t_1\,\ldots\,t_i,\,n,\,x_1,\ldots,x_i] \end{aligned} $$

To automate the use of the primitive recursion theorem in deriving recursive definitions of this kind, the HOL system provides a function which automatically proves the existence of primitive recursive functions and then makes a constant specification to introduce the constant that denotes such a function:

   new_recursive_definition :
      {def : term, name : string, rec_axiom : thm} -> thm

In fact, new_recursive_definition handles primitive recursive definitions over a range of types, not just the natural numbers. For details, see the REFERENCE documentation.

More conveniently still, the Define function (see Section 8.3.1) supports primitive recursion, along with other styles of recursion, and does not require the user to quote the primitive recursion axiom. It may, however, require termination proofs to be performed; fortunately, these need not be done for primitive recursions.

Dependent choice and wellfoundedness

The primitive recursion theorem is useful beyond its main purpose of justifying recursive definitions. For example, the theory prim_rec proves the Axiom of Dependent Choice (DC).

DC
  ⊢ ∀P R a.
       P a ∧ (∀x. P x ⇒ ∃y. P y ∧ R x y) ⇒
       ∃f. f 0 = a ∧ ∀n. P (f n) ∧ R (f n) (f (SUC n))

The proof uses SELECT_AX. The theorem DC is useful when one wishes to build a function having a certain property from a relation. For example, one way to define the wellfoundedness of a relation $R$ is to say that it has no infinite decreasing $R$ chains.

wellfounded_def
  ⊢ ∀R. Wellfounded R ⇔ ¬∃f. ∀n. R (f (SUC n)) (f n)
WF_IFF_WELLFOUNDED
  ⊢ ∀R. WF R ⇔ Wellfounded R

By use of DC, this statement can be proved to be equal to the notion of wellfoundedness WF (namely, that every set has an $R$-minimal element) defined in the theory relation.

Theorems asserting the wellfoundedness of the predecessor relation and the less-than relation, as well as the wellfoundedness of measure functions are also proved in prim_rec.

WF_PRED
  ⊢ WF (λx y. y = SUC x)
WF_LESS
  ⊢ WF $<

measure_def
  ⊢ measure = inv_image $<
measure_thm
  ⊢ ∀f x y. measure f x y ⇔ f x < f y
WF_measure
  ⊢ ∀m. WF (measure m)

Arithmetic

The HOL theory arithmetic contains primitive recursive definitions of the following standard arithmetic operators.

ADD
  ⊢ (∀n. 0 + n = n) ∧ ∀m n. SUC m + n = SUC (m + n)

SUB
  ⊢ (∀m. 0 − m = 0) ∧
     ∀m n. SUC m − n = if m < n then 0 else SUC (m − n)

MULT
  ⊢ (∀n. 0 * n = 0) ∧ ∀m n. SUC m * n = m * n + n

EXP
  ⊢ (∀m. m ** 0 = 1) ∧ ∀m n. m ** SUC n = m * m ** n

Note that EXP is an infix. The infix notation ** may be used in place of EXP. Thus (x EXP y) means $x^y$, and so does (x ** y). In addition, the parser special-cases superscript 2 and 3 notations, so that `x²` is actually the same term as x EXP 2, and `x³` is the same term as x EXP 3.

Comparison operators. A full set of comparison operators is defined in terms of <.

GREATER_DEF
  ⊢ ∀m n. m > n ⇔ n < m
LESS_OR_EQ
  ⊢ ∀m n. m ≤ n ⇔ m < n ∨ m = n
GREATER_OR_EQ
  ⊢ ∀m n. m ≥ n ⇔ m > n ∨ m = n

Note that in all of HOL's standard numeric theories, it is usual practice to avoid uses of the “greater-than” constants and to express everything with either $<$ or $\le$.

Division and modulus. A constant specification is used to introduce division (DIV, infix) and modulus (MOD, infix) operators, together with their characterizing property.

DIVISION
  ⊢ ∀n. 0 < n ⇒ ∀k. k = k DIV n * n + k MOD n ∧ k MOD n < n

Even and odd. The properties of a number being even or odd are defined recursively.

EVEN
  ⊢ (EVEN 0 ⇔ T) ∧ ∀n. EVEN (SUC n) ⇔ ¬EVEN n

ODD
  ⊢ (ODD 0 ⇔ F) ∧ ∀n. ODD (SUC n) ⇔ ¬ODD n

Maximum and minimum. The minimum and maximum of two numbers are defined in the usual way.

MAX_DEF
  ⊢ ∀m n. MAX m n = if m < n then n else m
MIN_DEF
  ⊢ ∀m n. MIN m n = if m < n then m else n

Factorial. The factorial of a number is a primitive recursive definition.

FACT
  ⊢ FACT 0 = 1 ∧ ∀n. FACT (SUC n) = SUC n * FACT n

Function iteration. The iterated application $f^n(x)$ of a function $f:\alpha\to\alpha$ is defined by primitive recursion. The definition (FUNPOW) is tail-recursive, which can be awkward to reason about. An alternative characterization (FUNPOW_SUC) may be easier to apply when doing proofs.

FUNPOW
  ⊢ (∀f x. FUNPOW f 0 x = x) ∧
     ∀f n x. FUNPOW f (SUC n) x = FUNPOW f n (f x)
FUNPOW_SUC
  ⊢ ∀f n x. FUNPOW f (SUC n) x = f (FUNPOW f n x)

On this basis, an ad hoc but useful collection of over two hundred and fifty elementary theorems of arithmetic are proved when HOL is built and stored in the theory arithmetic. For a complete list of the available theorems, see the REFERENCE manual. See also Section 5.6 for discussion of the LEAST operator, which returns the least number satisfying a predicate.

Grammar information

The following table gives the parsing status of the arithmetic constants.

Numerals

The type num is usually thought of as being supplied with an infinite collection of numerals: 1, 2, 3, etc. However, the HOL logic has no way to define such infinite families of constants; instead, all numerals other than $0$ are actually built up from the constants introduced by the following definitions:

NUMERAL_DEF
  ⊢ ∀x. NUMERAL x = x

BIT1
  ⊢ ∀n. BIT1 n = n + (n + SUC 0)
BIT2
  ⊢ ∀n. BIT2 n = n + (n + SUC (SUC 0))

ALT_ZERO
  ⊢ ZERO = 0

For example, the numeral $5$ is represented by the term

$$ \mathtt{NUMERAL}(\mathtt{BIT1}(\mathtt{BIT2}\;\mathtt{ZERO})) $$

and the HOL parser and pretty-printer make such terms appear as numerals. This binary representation for numerals allows for asymptotically efficient calculation. Theorems supporting arithmetic calculations on numerals can be found in the numeral theory; these are mechanized by the reduce library. Thus, arithmetic calculations are performed by deductive steps in HOL. For example the following calculation of $2^{(1023+14)/9}$ takes approximately 4,200 primitive inference steps and returns quickly:

> Count.apply reduceLib.REDUCE_CONV ``2 EXP ((1023 + 14) DIV 9)``;
runtime: 0.00063s,    gctime: 0.00000s,     systime: 0.00001s.
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 4202; Total: 4202
val it =
   ⊢ 2 ** ((1023 + 14) DIV 9) =
     41538374868278621028243970633760768: thm

Construction of numerals. Numerals may of course be built using mk_comb, and taken apart with dest_comb; however, a more convenient interface to this functionality is provided by the functions mk_numeral, dest_numeral, and is_numeral (found in the structure numSyntax). These entry-points make use of an ML structure Arbnum which implements arbitrary precision numbers num. The following session shows how HOL numerals are constructed from elements of type num and how numerals are destructed. The structure Arbnum provides a full collection of arithmetic operations, using the usual names for the operations, e.g., +, *, -, etc.

> numSyntax.mk_numeral
    (Arbnum.fromString "3432432423423423234");
val it = “3432432423423423234”: term

> numSyntax.dest_numeral it;
val it = 3432432423423423234: num

> Arbnum.+(it,it);
val it = 6864864846846846468: num

Numerals and the parser. Simple digit sequences are parsed as decimal numbers, but the parser also supports the input of numbers in binary, octal and hexadecimal notation. Numbers may be written in binary and hexadecimal form by prefixing them with the strings 0b and 0x respectively. The ‘digits’ A–F in hexadecimal numbers may be written in upper or lower case. Binary numbers have their most significant digits left-most. In the interests of backwards compatibility, octal numbers are not enabled by default, but if the reference base_tokens.allow_octal_input is set to true, then octal numbers are those that appear with leading zeroes.

Finally, all numbers may be padded with underscore characters (_). These can be used to groups digits for added legibility and have no semantic effect.

Thus

> ``0xAA``;
val it = “170”: term

> ``0b1010_1011``;
val it = “171”: term

> base_tokens.allow_octal_input := true;
val it = (): unit

> ``067``;
val it = “55”: term

Numerals and Peano numbers. Numerals are related to numbers built from 0 and SUC via the derived inference rule num_CONV, found in the numLib library.

   num_CONV : term -> thm

num_CONV can be used to generate the 'SUC' equation for any non-zero numeral. For example:

> open numLib;   ... output elided ...
> num_CONV ``2``;
val it = ⊢ 2 = SUC 1: thm

> num_CONV ``3141592653``;
val it = ⊢ 3141592653 = SUC 3141592652: thm

The num_CONV function works purely by inference.

Overloading of arithmetic operators

When other numeric theories are loaded (such as those for the reals or integers), numerals are overloaded so that the numeral 1 can actually stand for a natural number, an integer or a real value. The parser has a pass of overloading resolution in which it attempts to determine the actual type to give to a numeral. For example, in the following session, the theory of integers is loaded, whereupon the numeral 2 is taken to be an integer.

> load "integerTheory";
val it = (): unit

> ``2``;
<<HOL message: more than one resolution of overloading was possible>>
val it = “2”: term

> type_of it;
val it = “:int”: hol_type

In order to precisely specify the desired type, the user can use single character suffixes ('n' for the natural numbers, and 'i' for the integers):

> type_of ``2n``;
val it = “:num”: hol_type

> type_of ``42i``;
val it = “:int”: hol_type

A numeric literal for a HOL type other than num, such as 42i, is represented by the application of an injection function of type num -> ty to a numeral. The injection function is different for each type ty. See Section 5.3.4 for further discussion.

The functions mk_numeral, dest_numeral, and is_numeral only work for numerals, and not for numeric literals with character suffixes other than n. For information on how to install new character suffixes, consult the add_numeral_form entry in the REFERENCE manual.

Integers

There is an extensive theory of integers in HOL. The type of integers is constructed as a quotient on pairs of natural numbers. A standard collection of operators are defined. These are overloaded with similar operations on the natural numbers, and on the real numbers. The constants defined in the integer theory include those found in the following table.

The overloaded symbol & : num -> int denotes the injection function from natural numbers to integers. The following session illustrates how overloading and integers literals are treated.

> “1i = &(1n + 0n)”;
val it = “1 = &(1 + 0)”: term

> show_numeral_types := true;
val it = (): unit

> “&1 = &(1n + 0n)”;
<<HOL message: more than one resolution of overloading was possible>>
val it = “1i = &(1n + 0n)”: term
> show_numeral_types := false;   ... output elided ...

In addition, there is an absolute value function ABS:

integerTheory.INT_ABS
  ⊢ ∀n. ABS n = if n < 0 then -n else n

with the obvious definition.

This then characterises the Num function which maps from integers back into natural numbers (of type :int -> num therefore):

integerTheory.Num_EQ_ABS
  ⊢ ∀i. &Num i = ABS i

Rational numbers

The type of rationals is constructed as a quotient on ordered pairs of integers (the numerator and the denominator of a fraction) whose second component must not be zero. To make things easier in the HOL theory, the sign of a rational number is always moved to the numerator. So, the denominator is always positive.

A standard collection of operators, which are overloaded with similar operations on the integers, are defined. These include those found in the following table. Injection from natural numbers is supported by the overloaded symbol & : num -> rat and the suffix q.

The theorems in the theory of rational numbers include field properties, arithmetic rules, manipulation of (in)equations and their reduction to (in)equations between integers, properties of less-than relations and the density of rational numbers. For details, consult the REFERENCE manual and the source files.

Real numbers

There is an extensive collection of theories that make up the development of real numbers and analysis in HOL, due to John Harrison (Harrison 1998). We will only give a sketchy overview of the development; the interested reader should consult the REFERENCE manual and Harrison's thesis.

The axioms for the real numbers are derived from the ‘half reals’ which are constructed from the ‘half rationals’. This part of the development is recorded in hratTheory and hrealTheory, but is not used once the reals have been constructed. The real axioms are derived in the theory realaxTheory. A standard collection of operators on the reals, and theorems about them, is found in realaxTheory and realTheory. The operators and their parse status are listed in the following table.

On the basis of realTheory, the following sequence of theories is constructed:

real_sigma

Summation of real numbers (the $\Sigma$ operator, etc.)

topology

General topology.

metric

Metric spaces, including metric on the real line.

nets

Moore-Smith convergence nets, and special cases like sequences.

real_topology

Topology of one-dimensional Euclidean space (Section 6.2).

seq

Sequences and series of real numbers.

derivative

The new univariate differential calculus (Section 6.3).

lim

Limits, continuity and the old differentiation.

powser

Power series.

transc

Transcendental functions, e.g., exp, sin, cos, ln, root, sqrt, pi, tan, asn, acs, atn.

integration

The new univariate integral calculus (Section 6.3).

integral

The old univariate integral calculus.

HOL also includes a basic theory of the complex numbers (complexTheory), where the type complex is a type abbreviation for a pair of real numbers. The $\sqrt{-1}$ value is the HOL constant i. Numerals are supported (with the suffix c available to force numerals to be parsed as complex numbers). The standard arithmetic operations are defined, with the appropriate theorems proved about them.

Extended real numbers

The HOL provides an extensive theory of extended real numbers (extreal), originally developed by T. Mhamdi, O. Hasan, and S. Tahar (Mhamdi, Hasan, and Tahar 2011). With extended reals, the limit of a monotonic sequence is always defined, infinite when the sequence is divergent, but still defined and properties can be proven on it.

It is often helpful to use the values $+\infty$ and $-\infty$ in calculations. To do this properly, we have to consider the extended real line $\overline{\mathbb{R}} := [-\infty, +\infty]$. If we agree that $-\infty < x$ and $y < +\infty$ for all $x, y \in \mathbb{R}$, then $\overline{\mathbb{R}}$ inherits the ordering from $\mathbb{R}$ as well as the usual rules of addition, subtraction, multiplication and division of elements from $\mathbb{R}$. The latter needs to be augmented as shown in Table 5.3.7 (Schilling 2017, 61):

Table: $+$, $-$, $\cdot$ and $/$ in $\overline{\mathbb{R}}$, where $x, y \in \mathbb{R}$ and $a, b \in (0, \infty)$.

Addition.

Subtraction.

Multiplication.

Division.

In HOL, the type of extended real numbers (extreals hereafter) is constructed by an algebraic datatype extreal (see Section 7.2):

   Datatype `extreal = NegInf | PosInf | Normal real`

Thus Normal r denotes the extreal corresponding to the real number r, while PosInf and NegInf denote $+\infty$ and $-\infty$, respectively. In order to precisely specify extreals corresponding to natural numbers, the user can use the single character suffix 'x':

> type_of ``0x``;
val it = “:extreal”: hol_type

The function real can be used to convert extreals back to the corresponding reals ($+\infty$ and $-\infty$ are mapped to 0x).

A standard collection of arithmetic operators⁸ and elementary functions on the extreals are defined and overloaded on the corresponding operators of real numbers, shown in Table 5.3.7.

Table: Arithmetic operators and transcendental functions for extreals.

The addition of extreals is not associative and commutative in general, because PosInf + NegInf and NegInf + PosInf are not defined (see Table 5.3.7). To swap the elements of additions, the user must avoid mixing of PosInf and NegInf in the involved elements (e.g., by letting one of them be normal):

add_comm
  ⊢ ∀x y. x ≠ −∞ ∧ y ≠ −∞ ∨ x ≠ +∞ ∧ y ≠ +∞ ⇒ x + y = y + x
add_comm_normal
  ⊢ ∀x y. Normal x + y = y + Normal x
add_assoc
  ⊢ ∀x y z.
       x ≠ −∞ ∧ y ≠ −∞ ∧ z ≠ −∞ ∨ x ≠ +∞ ∧ y ≠ +∞ ∧ z ≠ +∞ ⇒
       x + (y + z) = x + y + z

On the other hand, the set of extreals is a totally ordered set such that for all $a \in \overline{\mathbb{R}}$, $-\infty \leq a \leq +\infty$. With this order, $\overline{\mathbb{R}}$ is a complete lattice where every subset has a supremum (extreal_sup or sup) and an infimum (extreal_inf or inf). In particular, for empty sets (of extreals) we have:

sup_empty
  ⊢ sup ∅ = −∞
inf_empty
  ⊢ inf ∅ = +∞

Finite and infinite sum of extreals. The sum of extreals over a finite set (EXTREAL_SUM_IMAGE, overloaded on SIGMA), $\sum_{i\in s} f(i)$, is defined by pred_set.ITSET (see Section 5.5.1):

EXTREAL_SUM_IMAGE_DEF
  ⊢ ∀f s. ∑ f s = ITSET (λe acc. f e + acc) s 0

To actually work with EXTREAL_SUM_IMAGE, beside that $s$ must be a finite set, there must be no mixing of PosInf and NegInf in the values of f, i.e., either all $f(i)$ are not $+\infty$ or they are not $-\infty$ ($i \in s$). The following theorem fully captures the properties of EXTREAL_SUM_IMAGE:

EXTREAL_SUM_IMAGE_THM
  ⊢ ∀f. ∑ f ∅ = 0 ∧ (∀e. ∑ f {e} = f e) ∧
         ∀e s.
           FINITE s ∧
           ((∀x. x ∈ e INSERT s ⇒ f x ≠ +∞) ∨
            ∀x. x ∈ e INSERT s ⇒ f x ≠ −∞) ⇒
           ∑ f (e INSERT s) = f e + ∑ f (s DELETE e)

The (countably) infinite sum of extreals (ext_suminf, overloaded on suminf), $\sum_{i\in\mathbb{N}} f(i)$, is only defined on non-negative function $f$ as the supremum of the $n$th partial sum:

ext_suminf_def
  ⊢ ∀f. (∀n. 0 ≤ f n) ⇒
         suminf f = sup (IMAGE (λn. ∑ f (count n)) 𝕌(:num))

Thus mathematically ext_suminf represents positive series, which always has a unique nonnegative value: PosInf if the positive series is divergent, other normal extreals (i.e., < PosInf) if the positive series is convergent (on that normal extreal). A fundamental result for positive series says that it converges if and only if its $n$th partial sums are bounded:

pos_summable
  ⊢ ∀f. (∀n. 0 ≤ f n) ∧ (∃r. ∀n. ∑ f (count n) ≤ Normal r) ⇒
         suminf f < +∞

Finally, 2-dimensional (positive) infinite sums $\sum_{i,j\in\mathbb{N}} f(i,j)$ can be reduced to iterated sums $\sum_{i\in\mathbb{N}} \sum_{j\in\mathbb{N}} f(i,j)$ given an arbitrary bijection between $\mathbb{N}$ and $\mathbb{N}\times\mathbb{N}$:

ext_suminf_2d_full
  ⊢ ∀f g h.
       (∀m n. 0 ≤ f m n) ∧ (∀n. suminf (f n) = g n) ∧
       BIJ h 𝕌(:num) (𝕌(:num) × 𝕌(:num)) ⇒
       suminf (UNCURRY f ∘ h) = suminf g

Upper and lower limits of extreal sequences. For a sequence of extreal numbers, the limes inferior or lower limit is defined as (see, e.g., Appendix A of (Schilling 2017) for more details.)

ext_liminf_def
  ⊢ ∀a. liminf a = sup (IMAGE (λm. inf {a n | m ≤ n}) 𝕌(:num))

and the limes superior or upper limit is defined as

ext_limsup_def
  ⊢ ∀a. limsup a = inf (IMAGE (λm. sup {a n | m ≤ n}) 𝕌(:num))

Some basic properties of ext_limsup and ext_liminf are provided in extreal theory:

ext_liminf_alt_limsup
  ⊢ ∀a. liminf a = -limsup (numeric_negate ∘ a)
ext_liminf_pos
  ⊢ ∀a. (∀n. 0 ≤ a n) ⇒ 0 ≤ liminf a
ext_liminf_le_limsup
  ⊢ ∀a. liminf a ≤ limsup a
ext_limsup_alt_liminf
  ⊢ ∀a. limsup a = -liminf (numeric_negate ∘ a)
ext_limsup_pos
  ⊢ ∀a. (∀n. 0 ≤ a n) ⇒ 0 ≤ limsup a

The most important property, however, that the normal limit of a sequence of extreal numbers (when forcely converted to real numbers) coincides with its upper and lower limits (in this case they are also the same), together with useful lemmas, are provided in martingale theory:

ext_limsup_thm
  ⊢ ∀a l.
       (∀n. a n ≠ +∞ ∧ a n ≠ −∞) ⇒
       ((real ∘ a ⟶ l) sequentially ⇔
        limsup a = Normal l ∧ liminf a = Normal l)

ext_limsup_le_subseq
  ⊢ ∀a f l.
       (∀n. a n ≠ +∞ ∧ a n ≠ −∞) ∧ (∀m n. m < n ⇒ f m < f n) ∧
       (real ∘ a ∘ f ⟶ l) sequentially ⇒
       Normal l ≤ limsup a
ext_liminf_le_subseq
  ⊢ ∀a f l.
       (∀n. a n ≠ +∞ ∧ a n ≠ −∞) ∧ (∀m n. m < n ⇒ f m < f n) ∧
       (real ∘ a ∘ f ⟶ l) sequentially ⇒
       liminf a ≤ Normal l
ext_limsup_imp_subseq
  ⊢ ∀a. (∀n. a n ≠ +∞ ∧ a n ≠ −∞) ∧ limsup a ≠ +∞ ∧
         limsup a ≠ −∞ ⇒
         ∃f. (∀m n. m < n ⇒ f m < f n) ∧
             (real ∘ a ∘ f ⟶ real (limsup a)) sequentially
ext_liminf_imp_subseq
  ⊢ ∀a. (∀n. a n ≠ +∞ ∧ a n ≠ −∞) ∧ liminf a ≠ +∞ ∧
         liminf a ≠ −∞ ⇒
         ∃f. (∀m n. m < n ⇒ f m < f n) ∧
             (real ∘ a ∘ f ⟶ real (liminf a)) sequentially

Bit vectors

HOL provides a theory of bit vectors, or $n$-bit words. For example, in computer architectures one finds: bytes/octets ($n=8$), half-words ($n=16$), words ($n=32$) and long-words ($n=64$). In the theory words, bit vectors are represented as finite Cartesian products: an $n$-bit word is given type $\worda$ where the size of the type $\alpha$ determines the word length $n$. This approach comes from an idea of John Harrison, which was presented at TPHOLs 2005.⁹

Finite Cartesian products

The HOL theory fcp introduces an infix type operator **, which is used to represent finite Cartesian products.¹⁰ The type 'a ** 'b, or equivalently $\fcp{\mathit{a}}{\mathit{b}}$, is conceptually equivalent to:

$$ \underbrace{\mathit{a}\;\#\;\mathit{a}\;\#\;\cdots\;\#\;\mathit{a}}_{\mathtt{dimindex('b)}} $$

where dimindex('b) is the cardinality of univ(:'b) when 'b is finite and is one when it is infinite. Thus, $\fcp{\mathit{a}}{\mathit{num}}$ is similar to 'a, and $\fcp{\mathit{a}}{\mathit{bool}}$ is similar to 'a # 'a. Numeral type names are supported, so one can freely work with indexing sets of any size, e.g., the type 32 has thirty-two elements and $\fcp{\mathit{bool}}{32}$ represents 32-bit words.

The components of a finite Cartesian product are accessed with an indexing function

   fcp_index : 'a ** 'b -> num -> 'a

which is typically written with an infixed apostrophe: x ' i denotes the value of vector x at position i. Typically, indices are constrained to be less than the size of 'b.¹¹

The following theorem shows that two Cartesian products x and y are equal if, and only if, all of their components x ' i and y ' i are equal:

CART_EQ
  ⊢ ∀x y. x = y ⇔ ∀i. i < dimindex (:β) ⇒ x ' i = y ' i

In order to construct Cartesian products, the theory fcp introduces a binder FCP, which is characterised by the following theorems:

FCP_BETA
  ⊢ ∀i. i < dimindex (:β) ⇒ $FCP g ' i = g i
FCP_ETA
  ⊢ ∀g. (FCP i. g ' i) = g

The theorem FCP_BETA shows that the components of $FCP g are determined by the function g:num -> 'a. The theorem FCP_ETA shows that a binding can be eliminated when all of the components are identical to that of x. These two theorems, together with CART_EQ, can be found in the simpset fragment fcpLib.FCP_ss.

Finite Cartesian products provide a good means to model $n$-bit words. That is to say, the type $\fcp{\mathit{bool}}{\mathit{a}}$ can represent a binary word whose length $n$ corresponds with the size of the type 'a. The binder FCP provides a flexible means for defining words — one can supply a function f:num -> bool that gives the word's bit values, each of which can be accessed using the indexing map fcp_index.

Bit theory

The theory bit defines some bit operations over the natural numbers, e.g., BITS, SLICE, BIT, BITWISE and BIT_MODIFY. In this context, natural numbers are treated as binary words of unbounded length. The operations in bit are primarily defined using DIV, MOD and EXP. For example, from the definition of BIT, the following theorem holds:

BIT_DEF
  ⊢ ∀b n. BIT b n ⇔ n DIV 2 ** b MOD 2 = 1

Here BIT b n states that the $b$-th bit (counted from the least significant bit, starting by 0) of $n$ is 1. (In other words, BIT b n maps the $b$-th bit of $n$ from 0 to false and 1 to true.)

On the other hand, SBIT can be used to construct a number by summing up values corresponding to each bits. SBIT b n represents the single $n$-th bit value indicated by the Boolean value $b$, to be accumulated for constructing the destination number:

SBIT_def
  ⊢ ∀b n. SBIT b n = if b then 2 ** n else 0

This theory is used in the development of the word theory and it also provides a mechanism for the efficient evaluation of some word operations via the theory numeral_bit.

Words theory

The theory words introduces a selection of polymorphic constants and operations, which can be type instantiated to any word size. For example, word addition has type:

$$ +:\worda \to \worda \to \worda $$

If 'a is instantiated to 32 then this operation corresponds with 32-bit addition. All theorems about word operations apply for any word length.¹²

Some basic operations. The function w2n: $\worda \to \mathit{num}$ gives the natural number value of a word. If $x \in \mathit{bool}^{\{0,1,\ldots,n-1\}}$ is a finite Cartesian product representing an $n$-bit word then its natural number value is:

$$ \mathrm{w2n}(x) = \sum_{i=0}^{n-1}\textbf{if } x_i\textbf{ then } 2^i\textbf{ else } 0\,. $$

The length of a word (the number $n$) is given by the function word_len: $\worda \to \mathit{num}$. The function n2w: $\mathit{num} \to \worda$ maps from a number to a word, and the function w2n: $\worda \to \mathit{num}$ maps from a word to a number. They are defined in HOL by:

n2w_def
  ⊢ ∀n. n2w n = FCP i. BIT i n
w2n_def
  ⊢ ∀w. w2n w = SUM (dimindex (:α)) (λi. SBIT (w ' i) i)

The suffix w is used to denote word literals, e.g., 255w is the same as n2w 255.

The function w2w: $\worda \to \wordb$ provides word-to-word conversion (casting):

w2w_def
  ⊢ ∀w. w2w w = n2w (w2n w)

If $\beta$ is smaller than $\alpha$ then the higher bits of w will be lost (it performs bit extraction), otherwise the longer word will have the same value as the original (in effect providing zero padding). However, if one were treating w as a two's complement number then the word needs to be sign extended, i.e.,

$$ \begin{aligned} \text{($-$ve)}\quad &1 b_{n-2}\cdots b_0 \;\mapsto\; 1\cdots 11 b_{n-2}\cdots b_0\\ \text{($+$ve)}\quad &0 b_{n-2}\cdots b_0 \;\mapsto\; 0\cdots 00 b_{n-2}\cdots b_0 \end{aligned} $$

The function sw2sw: $\worda \to \wordb$ provides this sign extending version of w2w.

A collection of operations are provided for mapping to and from strings and number (digit) lists, e.g.,

|- word_to_dec_string 876w = "876"

and

|- word_to_hex_list 876w = [12; 6; 3]

These function are specialised versions of w2s and w2l respectively.

Concatenation. The operation word_concat: $\worda \to \wordb \to \wordc$ concatenates words. Note that the return type is not constrained. This means that two sixteen bit words can be concatenated to give a word of any length — which may be smaller or larger than the expected value of 32. The related function word_join does return a word of the expected length, i.e., of type $\fcp{\mathit{bool}}{\alpha+\beta}$; however, the concatenation operation is more useful because we often want $\fcp{\mathit{bool}}{32}$ and not the logically distinct $\fcp{\mathit{bool}}{16+16}$.

Signed and unsigned words. Words can be viewed as being either signed (using the two's complement representation) or as being unsigned. However, this is not made explicit within the theory¹³ and all of the arithmetic operations are defined using the natural numbers, i.e., via w2n and n2w. In particular, addition and multiplication work naturally (have the same definition) under the two's complement representation. This is not the case however with word-to-word conversion, orderings, division and right shifting, where signed and unsigned variants are needed. When operating over the natural numbers, some of the two's complement versions have slightly unnatural looking presentations. For example, with the signed (two's complement) version of “less than” we have 255w < (0w:word8) because the word 255w is actually taken to be representing the integer $-1$, whereas the unsigned version is more natural: 0w <+ (255w:word8).

Bit field operations. The standard Boolean bit field operations are provided, i.e., bitwise negation (one's complement), conjunction, disjunction and exclusive-or. These functions are defined quite naturally using the Cartesian product binder; for example, bitwise conjunction is defined by:

|- !v w. v && w = FCP i. v ' i /\ w ' i .

There is also a collection of word reduction operations, which reduce bit vectors to 1-bit words, e.g.,

$$ \mathrm{reduce\_and}(x)\;'\;0 = \bigwedge_{i=0}^{n-1} x_i\,. $$

The functions word_lsb, word_msb and word_bit(i) give the bit value of a word at positions $0$, $n-1$ and $i$ respectively. Four operations are provided for selecting bit fields, or sub-words: word_bits (--), word_signed_bits (---), word_slice ('') and word_extract (><). For example, word_bits 4 1 will select four bits starting from bit position

1. The slice function is an in-place variant (it zeroes bits outside of the bit range) and the extract function combines word_bits with a word cast (w2w). The operation word_signed_bits is similar to word_bits, except that it sign-extends the bit field.

The bit_field_insert operation inserts a bit field. For example,

bit_field_insert 5 2 a b

is word b with bits 5–2 replaced by bits 3–0 of a.

A word's bit ordering can be flipped over with word_reverse, i.e., bit zero is swapped with bit $n-1$ and so forth.

The function word_modify:(num -> bool -> bool) -> $\worda \to \worda$ changes a word by applying a map at each bit position. This operation provides a very flexible and convenient mechanism for manipulating words, e.g.,

word_modify (\i b. if EVEN i then ~b else b) w

negates the bits of w that are in even positions. Of course, the binder FCP also provides a very general means to represent words using a predicate; e.g., $FCP ODD represents a word where all the odd bits are set.

Shifts. Six types of shifts are provided: logical shift left/right (<< and >>>), arithmetic shift right (>>), rotate left/right (#<< and #>>) and rotate right extended by 1 place (word_rrx). These shifts are illustrated in Figure 5.3.8.3 and are defined in a similar manner to the other bit field operations. For example, rotating right is defined by:

|- !w n. w #>> x = FCP i. w ' (i + x) MOD dimindex (:'a) .

Rotating left by $x$ places is defined as rotating right by $n - x \bmod n$ places.

(a) Logical shift left: w = v << x.	(b) Logical shift right: w = v >>> x.
(c) Arithmetic shift right: w = v >> x.	(d) Rotate right: w = v #>> x.
(e) Rotate right extended by 1 place: (d,w) = word_rrx (c,v).

Arithmetic and orderings. The arithmetic operations are: addition, subtraction, unary minus (two's complement), logarithm (base-2), multiplication, modulus and division (signed and unsigned). These operations are defined with respect to the natural numbers. For example, word addition is defined by:

|- !v w. v + w = n2w (w2n v + w2n w)

The + on the left-hand side is word addition and on the right it is natural number addition.

All of the standard word orderings are provided, with signed and unsigned versions of $<$, $\leq$, $>$ and $\geq$. The unsigned versions are suffixed with a plus; for example, <+ is unsigned “less than”.

Constants. The word theory also defines a few word constants:

List of bit vector operations. A list of operations is provided in the table below.

Sequences

HOL provides theories for various kinds of sequences: finite lists, lazy lists, paths, and finite strings.

Lists

HOL lists are inductively defined finite sequences where each element in a list has the same type. The theory list introduces the unary type operator $\alpha\;\konst{list}$ by a type definition and a standard collection of list processing functions are defined. The primitive constructors NIL and CONS

   NIL  : 'a list
   CONS : 'a -> 'a list -> 'a list

are used to build lists and have been defined from the representing type for lists. The HOL parser has been specially modified to parse the expression [] into NIL, to parse the expression h::t into CONS h t, and to parse the expression [$t_1$;$t_2$;…;$t_n$] into CONS $t_1$(CONS$t_2$ $\cdots$(CONS$t_n$NIL)$\cdots$). The HOL printer reverses these transformations.

Based on the inductive characterization of the type, the following fundamental theorems about lists are proved and stored in the theory list.

list_Axiom
  ⊢ ∀f0 f1. ∃fn.
       fn [] = f0 ∧ ∀a0 a1. fn (a0::a1) = f1 a0 a1 (fn a1)
list_INDUCT
  ⊢ ∀P. P [] ∧ (∀t. P t ⇒ ∀h. P (h::t)) ⇒ ∀l. P l
list_CASES
  ⊢ ∀l. l = [] ∨ ∃h t. l = h::t
CONS_11
  ⊢ ∀a0 a1 a0' a1'. a0::a1 = a0'::a1' ⇔ a0 = a0' ∧ a1 = a1'
NOT_NIL_CONS
  ⊢ ∀a1 a0. [] ≠ a0::a1
NOT_CONS_NIL
  ⊢ ∀a1 a0. a0::a1 ≠ []

The theorem list_Axiom shown above is analogous to the primitive recursion theorem on the natural numbers discussed above in Section 5.3.1.3. It states the validity of primitive recursive definitions on lists, and can be used to justify any such definition. The ML function new_recursive_definition uses this theorem to do automatic proofs of the existence of primitive recursive functions on lists and then make constant specifications to introduce constants that denote such functions.

The induction theorem for lists, list_INDUCT, provides the main proof tool used to reason about operations that manipulate lists. The theorem list_CASES is used to perform case analysis on whether a list is empty or not.

The theorem CONS_11 shows that CONS is injective; the theorems NOT_NIL_CONS and NOT_CONS_NIL show that NIL and CONS are distinct, i.e., cannot give rise to the same structure. Together, these three theorems are used for equational reasoning about lists.

The predicate NULL and the selectors HD and TL are defined in the theory list by

NULL
  ⊢ NULL [] ∧ ∀h t. ¬NULL (h::t)
HD
  ⊢ ∀h t. HD (h::t) = h
TL_DEF
  ⊢ TL [] = [] ∧ ∀h t. TL (h::t) = t

The nil-clause for the TL constant is included to make the function total, but does represent a case that often needs to be excluded. For example:

LIST_NOT_NIL
  ⊢ ∀ls. ls ≠ [] ⇔ ls = HD ls::TL ls

The following functions on lists are also defined in the theory list.

Case expressions. Compound HOL expressions that branch based on whether a term is an empty or non-empty list have the surface syntax (roughly borrowed from ML)

   case e1
    of [] => e2
     | (h::t) => e3

Such an expression is translated to $\mathtt{list\_CASE}\;e_1\;e_2\;(\lambda h\;t.\;e_3)$ where the constant list_CASE is defined as follows:

list_case_def
  ⊢ (∀v f. list_CASE [] v f = v) ∧
     ∀a0 a1 v f. list_CASE (a0::a1) v f = f a0 a1

List membership. Membership in a list, written using the MEM syntax, is characterised as follows:

MEM
  ⊢ (∀x. MEM x [] ⇔ F) ∧ ∀x h t. MEM x (h::t) ⇔ x = h ∨ MEM x t

Concatenation of lists.

Binary list concatenation (APPEND) may also be denoted by the infix operator ++; thus the expression L1 ++ L2 is translated into APPEND L1 L2. The concatenation of a list of lists into a list is achieved by FLAT. The special case where a single element is appended to the end of a list (the “opposite” of CONS, which adds elements to the front of a list), is implemented by SNOC.

APPEND
  ⊢ (∀l. [] ⧺ l = l) ∧ ∀l1 l2 h. h::l1 ⧺ l2 = h::(l1 ⧺ l2)
FLAT
  ⊢ FLAT [] = [] ∧ ∀h t. FLAT (h::t) = h ⧺ FLAT t
SNOC
  ⊢ (∀x. SNOC x [] = [x]) ∧
     ∀x x' l. SNOC x (x'::l) = x'::SNOC x l

Numbers and lists.

The length (LENGTH) and size (list_size) of a list are related notions. The size of a list takes account of the size of each element of the list (given by parameter $f:\alpha\to\konst{num}$), while the length of the list ignores the size of each list element. The alternate length definition (LEN) is tail-recursive. Numbers can also be used to index into lists, extracting the element at the specified position.

LENGTH
  ⊢ LENGTH [] = 0 ∧ ∀h t. LENGTH (h::t) = SUC (LENGTH t)
LEN_DEF
  ⊢ (∀n. LEN [] n = n) ∧ ∀h t n. LEN (h::t) n = LEN t (n + 1)
list_size_def
  ⊢ (∀f. list_size f [] = 0) ∧
     ∀f a0 a1. list_size f (a0::a1) = 1 + (f a0 + list_size f a1)
EL
  ⊢ (∀l. l❲0❳ = HD l) ∧ ∀l n. l❲SUC n❳ = (TL l)❲n❳

Note that the extraction of the $n$th element (as described in the theorem EL) of a list starts its indexing from 0. If the length of the list $\ell$ is less than or equal to n, the result of `ℓ❲n❳` is unspecified. The special syntax with the brackets hides the underlying constant, which is EL of type :num -> 'a list -> 'a. It is legal to use the constant explicitly, writing EL n ℓ.

The GENLIST constant can be used to generate a list of a particular size, where the value of each element is independently determined by reference to a function that takes natural numbers (the set $\{0\dots n-1\}$) to element values:

GENLIST
  ⊢ (∀f. GENLIST f 0 = []) ∧
     ∀f n. GENLIST f (SUC n) = SNOC (f n) (GENLIST f n)
EL_GENLIST
  ⊢ ∀f n x. x < n ⇒ (GENLIST f n)❲x❳ = f x

Working with SNOC, and thus the definition above, can occasionally be awkward, so a characterisation of GENLIST's SUC clause in terms of CONS can also be useful:

GENLIST_CONS
  ⊢ GENLIST f (SUC n) = f 0::GENLIST (f ∘ SUC) n

For more on the “indexed” treatment of lists, see Section 5.4.1.2 below.

Mapping functions over lists.

There are functions for mapping a function $f:\alpha\to\beta$ over a single list (MAP), a “partial” function $f:\alpha\to\beta\,\mathsf{option}$ over a list (mapPartial), or a function $f:\alpha\to\beta\to\gamma$ over two lists (MAP2):

MAP
  ⊢ (∀f. MAP f [] = []) ∧ ∀f h t. MAP f (h::t) = f h::MAP f t
mapPartial_def
  ⊢ (∀f. mapPartial f [] = []) ∧
     ∀f x xs.
       mapPartial f (x::xs) =
       case f x of
         NONE => mapPartial f xs
       | SOME y => y::mapPartial f xs
MAP2_DEF
  ⊢ (∀t2 t1 h2 h1 f.
        MAP2 f (h1::t1) (h2::t2) = f h1 h2::MAP2 f t1 t2) ∧
     (∀y f. MAP2 f [] y = []) ∧ ∀v5 v4 f. MAP2 f (v4::v5) [] = []

If passed lists of unequal length, MAP2 returns a list of length equal to that of the shorter list.

Predicates over lists.

Predicates can be applied to lists in a universal sense (the predicate must hold of every element in the list) or an existential sense (the predicate must hold of some element in the list). This functionality is supported by EVERY and EXISTS, respectively. The elimination of all elements in list not satisfying a given predicate is performed by FILTER.

EVERY_DEF
  ⊢ (∀P. EVERY P [] ⇔ T) ∧
     ∀P h t. EVERY P (h::t) ⇔ P h ∧ EVERY P t
EXISTS_DEF
  ⊢ (∀P. EXISTS P [] ⇔ F) ∧
     ∀P h t. EXISTS P (h::t) ⇔ P h ∨ EXISTS P t
FILTER
  ⊢ (∀P. FILTER P [] = []) ∧
     ∀P h t.
       FILTER P (h::t) =
       if P h then h::FILTER P t else FILTER P t
ALL_DISTINCT
  ⊢ (ALL_DISTINCT [] ⇔ T) ∧
     ∀h t. ALL_DISTINCT (h::t) ⇔ ¬MEM h t ∧ ALL_DISTINCT t

The predicate ALL_DISTINCT holds on a list just in case no element in the list is equal to any other. A list can have its duplicates removed through the use of the nub constant:

nub_def
  ⊢ nub [] = [] ∧
     ∀x l. nub (x::l) = if MEM x l then nub l else x::nub l

Relations over lists. A binary relation on elements can be “lifted” to a relation on lists of such elements with the LIST_REL constant:

LIST_REL_def
  ⊢ (LIST_REL R [] [] ⇔ T) ∧ (LIST_REL R (a::as) [] ⇔ F) ∧
     (LIST_REL R [] (b::bs) ⇔ F) ∧
     (LIST_REL R (a::as) (b::bs) ⇔ R a b ∧ LIST_REL R as bs)

This can be viewed as an application of EVERY:

LIST_REL_EVERY_ZIP
  ⊢ ∀R l1 l2.
       LIST_REL R l1 l2 ⇔
       LENGTH l1 = LENGTH l2 ∧ EVERY (UNCURRY R) (ZIP (l1,l2))

Acknowledging this view, the system overloads the name EVERY2 to map to the same constant.

> “EVERY2 (λm n. EVEN (m + n)) [1;2;3] [3;4;5]”;
val it = “LIST_REL (λm n. EVEN (m + n)) [1; 2; 3] [3; 4; 5]”:
   term

Some theorems in listTheory have names that reflect this.

Equally, LIST_REL can be seen as a test that checks the relation at all relevant indices:

LIST_REL_EL_EQN
  ⊢ ∀R l1 l2.
       LIST_REL R l1 l2 ⇔
       LENGTH l1 = LENGTH l2 ∧ ∀n. n < LENGTH l1 ⇒ R l1❲n❳ l2❲n❳

Finally, there is a natural induction principle for this constant (as per Section 7.7.1, the tactic ``Induct_on `LIST_REL``` applies it):

LIST_REL_strongind
  ⊢ ∀R LIST_REL'.
       LIST_REL' [] [] ∧
       (∀h1 h2 t1 t2.
          R h1 h2 ∧ LIST_REL R t1 t2 ∧ LIST_REL' t1 t2 ⇒
          LIST_REL' (h1::t1) (h2::t2)) ⇒
       ∀a0 a1. LIST_REL R a0 a1 ⇒ LIST_REL' a0 a1

Folding.

Applying a binary function $f:\alpha\to\beta\to\beta$ pairwise through a list and accumulating the result is known as folding. At times, it is necessary to do this operation from left-to-right (FOLDL), and at others the right-to-left direction (FOLDR) is required.

FOLDL
  ⊢ (∀f e. FOLDL f e [] = e) ∧
     ∀f e x l. FOLDL f e (x::l) = FOLDL f (f e x) l
FOLDR
  ⊢ (∀f e. FOLDR f e [] = e) ∧
     ∀f e x l. FOLDR f e (x::l) = f x (FOLDR f e l)

List reversal. The reversal of a list (REVERSE) and its tail recursive counterpart REV are defined in list.

   REVERSE_DEF
     |- (REVERSE [] = []) /\
        (!h t. REVERSE (h::t) = REVERSE t ++ [h])
   REV_DEF
     |- (!acc. REV [] acc = acc) /\
        (!h t acc. REV (h::t) acc = REV t (h::acc))

Conversion to sets. Lists can be converted to sets with the LIST_TO_SET constant, which is overloaded to the prettier name set. The definition is made by primitive recursion in listTheory:

> listTheory.LIST_TO_SET;
val it = ⊢ set [] = ∅ ∧ set (h::t) = h INSERT set t: thm

Note that MEM is an overloaded form of syntax such that MEM x l is actually a pretty-printing of the underlying term x ∈ set l.

Further support for translating between different kinds of collections may be found in the container theory.

Pairs and lists. Two lists of equal length may be component-wise paired by the ZIP operation. As with MAP2, the result of zipping lists of unequal lengths is a list whose length is that of the shorter argument. The inverse operation, UNZIP, translates a list of pairs into a pair of lists.

ZIP_def
  ⊢ (∀l2. ZIP ([],l2) = []) ∧ (∀l1. ZIP (l1,[]) = []) ∧
     ∀x1 l1 x2 l2. ZIP (x1::l1,x2::l2) = (x1,x2)::ZIP (l1,l2)
UNZIP_THM
  ⊢ UNZIP [] = ([],[]) ∧
     UNZIP ((x,y)::t) = (let (L1,L2) = UNZIP t in (x::L1,y::L2))

Alternate access.

Lists are essentially treated in a stack-like manner. However, at times it is convenient to access the last element (LAST) of a non-empty list directly. The last element of a non-empty list is dropped by FRONT.

LAST_DEF
  ⊢ ∀h t. LAST (h::t) = if t = [] then h else LAST t
FRONT_DEF
  ⊢ FRONT [] = [] ∧
     ∀h t. FRONT (h::t) = if t = [] then [] else h::FRONT t
APPEND_FRONT_LAST
  ⊢ ∀l. l ≠ [] ⇒ FRONT l ⧺ [LAST l] = l

Joining the front part and the last element of a non-empty list yields the original list. Both LAST and FRONT are unspecified on empty lists.

Prefix checking. The relation capturing whether a list $\ell_1$ is a prefix of $\ell_2$ (isPREFIX) can be defined by recursion. The infix symbols <<= (ASCII) and $\preccurlyeq$ (U+227C) can also be used as notation for this partial order.

isPREFIX_THM
  ⊢ ([] ≼ l ⇔ T) ∧ (h::t ≼ [] ⇔ F) ∧
     (h1::t1 ≼ h2::t2 ⇔ h1 = h2 ∧ t1 ≼ t2)

The above theorem states that: the empty list is a prefix of any other list (clause 1); that no non-empty list is a prefix of the empty list (clause 2); and that a non-empty list is a prefix of another non-empty list if the first elements of the lists are the same, and if the tail of the first is a prefix of the tail of the second.

For a complete list of available theorems in list, see the REFERENCE manual. Further development of list theory can be found in rich_list.

List permutations and sorting

The sorting theory defines a notion of two lists being permutations of each other, then defines a general notion of sorting, then shows that Quicksort is a sorting function. The mergesort theory defines Merge sort and shows that it is a stable sorting function.

List permutation. Two lists are in permutation if they have exactly the same members, and each member has the same number of occurrences in both lists. One definition (PERM) that captures this relationship is the following:

PERM_DEF
  ⊢ ∀L1 L2. PERM L1 L2 ⇔ ∀x. FILTER ($= x) L1 = FILTER ($= x) L2
PERM_IND
  ⊢ ∀P. P [] [] ∧ (∀x l1 l2. P l1 l2 ⇒ P (x::l1) (x::l2)) ∧
         (∀x y l1 l2. P l1 l2 ⇒ P (x::y::l1) (y::x::l2)) ∧
         (∀l1 l2 l3. P l1 l2 ∧ P l2 l3 ⇒ P l1 l3) ⇒
         ∀l1 l2. PERM l1 l2 ⇒ P l1 l2

A derived induction theorem (PERM_IND) is very useful in proofs about permutations.

Sorting. A list is $R$-sorted if $R$ holds pairwise through the list. This notion (SORTED) is captured by a recursive definition. Then a function of type

   ('a -> 'a -> bool) -> 'a list -> 'a list

is a sorting function (SORTS) with respect to $R$ if it delivers a permutation of its input, and the result is $R$-sorted.

SORTED_DEF
  ⊢ (∀R. SORTED R [] ⇔ T) ∧ (∀x R. SORTED R [x] ⇔ T) ∧
     ∀y x rst R. SORTED R (x::y::rst) ⇔ R x y ∧ SORTED R (y::rst)
SORTS_DEF
  ⊢ ∀f R. SORTS f R ⇔ ∀l. PERM l (f R l) ∧ SORTED R (f R l)

Quicksort is defined in the usual functional programming style, and it is indeed a sorting function, provided $R$ is a transitive and total relation.

QSORT_DEF
  ⊢ (∀ord. QSORT ord [] = []) ∧
     ∀t ord h.
       QSORT ord (h::t) =
       (let
          (l1,l2) = PARTITION (λy. ord y h) t
        in
          QSORT ord l1 ⧺ [h] ⧺ QSORT ord l2)
QSORT_SORTS
  ⊢ ∀R. transitive R ∧ total R ⇒ SORTS QSORT R

The notion of $R$ holding pairwise through a list can be expressed using the predicate adjacent, where $\mathtt{adjacent}\;\ell\;a\;b$ holds if values $a$ and $b$ appear together (in that order) in list $\ell$. Then, we have

SORTED_adjacent
  ⊢ SORTED R L ⇔ adjacent L ⊆ᵣ R

where the $\subseteq\subr$ relation is the notion of relation-subset (see Section 5.5.3). There are a number of other theorems in listTheory about adjacency, including for example:

adjacent_REVERSE
  ⊢ ∀xs a b. adjacent (REVERSE xs) a b ⇔ adjacent xs b a
adjacent_MAP
  ⊢ ∀xs a b f.
       adjacent (MAP f xs) a b ⇔ ∃x y. adjacent xs x y ∧ a = f x ∧ b = f y

Indexed lists

As mentioned earlier, lists can be indexed with the constant EL, viewing lists as partial functions from natural numbers (starting at 0!) into the element type. The definition is given by primitive recursion over the index argument, in theorem EL:

EL
  ⊢ (∀l. l❲0❳ = HD l) ∧ ∀l n. l❲SUC n❳ = (TL l)❲n❳

The term underlying the pretty presentation $\ell\lbrbrak n\rbrbrak$ is $\mathtt{EL}\;n\;\ell$; and both forms can be used when writing terms. If desired, the pretty-printing with the “array-subscript” notation can be turned off by the invocation

   val _ = clear_overloads_on "fEL"

Note that because of the use of HD and TL, the value of $\ell\lbrbrak n\rbrbrak$ is unspecified when $n \geq \mathtt{LENGTH}\;\ell$. Subsequently, many theorems involving EL have preconditions to preclude this possibility.

For example, these theorems describing the relationship between EL, MAP and MEM:

EL_MAP
  ⊢ ∀n l. n < LENGTH l ⇒ ∀f. (MAP f l)❲n❳ = f l❲n❳
MEM_EL
  ⊢ ∀l x. MEM x l ⇔ ∃n. n < LENGTH l ∧ x = l❲n❳

It is occasionally useful to be able to update lists at particular positions, viewing them as similar to programming language arrays. The relevant constant is LUPDATE, where the term $\mathtt{LUPDATE}\;e\;n\;\ell$ has the same value as list $\ell$, except that the $n$-th element of the list is equal to $e$. The definition illustrates the pretty syntax for the above ($\ell\lbrbrak n\mapsto e\rbrbrak$), and is given in three clauses:

LUPDATE_def
  ⊢ (∀e n. []❲n ↦ e❳ = []) ∧ (∀e x l. (x::l)❲0 ↦ e❳ = e::l) ∧
     ∀e n x l. (x::l)❲SUC n ↦ e❳ = x::l❲n ↦ e❳

The definition implies that attempting to update a list at an index beyond the end of the list returns the input list unchanged.

The basic characterisation of the link between EL and LUPDATE is

EL_LUPDATE
  ⊢ ∀ys x i k. ys❲k ↦ x❳❲i❳ = if i = k ∧ k < LENGTH ys then x else ys❲i❳

The pretty syntax supports chained or nested LUPDATE applications using a list-like notation:

> “LUPDATE v1 k1 (LUPDATE v2 k2 ℓ)”;
<<HOL message: inventing new type variable names: 'a>>
val it = “ℓ❲k1 ↦ v1; k2 ↦ v2❳”: term

The indexedLists theory. The indexedLists theory defines a number of extra constants that are “aware” of lists as indexed values. Some of these constants are:

   delN      : num -> 'a list -> 'a list
   findi     : 'a -> 'a list -> num
   LIST_RELi : (num -> 'a -> 'b -> bool) -> 'a list -> 'b list -> bool
   MAPi      : (num -> 'a -> 'b) -> 'a list -> 'b list

The findi constant is such that $\mathtt{findi}\;e\;\ell$ returns the first index of element $e$ within list $\ell$, or a number equal to $\ell$'s length, if $e$ is not present. The definition is by recursion over the structure of the input list:

findi_def
  ⊢ (∀x. findi x [] = 0) ∧
     ∀x h t. findi x (h::t) = if x = h then 0 else 1 + findi x t

The delN constant is used to remove the $n$-th element from a list. It is also defined by recursion over the structure of the input list:

delN_def
  ⊢ (∀i. delN i [] = []) ∧
     ∀i h t. delN i (h::t) = if i = 0 then t else h::delN (i − 1) t

The higher-order MAPi function exemplifies another set of constants within the indexedLists theory: its function parameter, which works on elements of the list argument is given access to the index of the list element as well as its value. A simple example use might be to generate a numbered version of a list, using the term $\mathtt{MAPi}\;(\lambda i\;e.\;(i,e))$. If this term were applied to the list [a;c;d] the resulting value would be [(0,a);(1,c);(2,d)].

An example theorem about MAPi relates it to MEM:

MEM_MAPi
  ⊢ ∀x f l. MEM x (MAPi f l) ⇔ ∃n. n < LENGTH l ∧ x = f n l❲n❳

Possibly infinite sequences (llist)

The theory llist contains the definition of a type of possibly infinite sequences. This type is similar to the “lazy lists” of programming languages like Haskell, hence the name of the theory. The llist theory has a number of constants that are analogous to constants in the theory of finite lists. The llist versions of these constants have the same names, but with a capital 'L' prepended. Thus, some of the core constants in this theory are:

   LNIL  : 'a llist
   LCONS : 'a -> 'a llist -> 'a llist
   LHD   : 'a llist -> 'a option
   LTL   : 'a llist -> 'a llist option

The LHD and LTL constants return NONE when applied to the empty sequence, LNIL. This use of an option type is another way of modelling the essential partiality of these constants. (In the theory of lists, the analogous HD and TL functions simply have unspecified values when applied to empty lists.)

The type llist is not inductive, and there is no primitive recursion theorem supporting the definition of functions that have domains of type llist. Rather, llist is a coinductive type, and has an axiom that justifies the definition of (co-)recursive functions that map into the llist type:

   llist_Axiom
     ⊢ ∀f. ∃g.
          (∀x. LHD (g x) = OPTION_MAP SND (f x)) ∧
          ∀x. LTL (g x) = OPTION_MAP (g ∘ FST) (f x)

An equivalent form of the above is

llist_Axiom_1
  ⊢ ∀f. ∃g. ∀x. g x = case f x of NONE => [||] | SOME (a,b) => b:::g a

Other constants in the theory llist include LMAP, LFINITE, LNTH, LTAKE, LDROP, and LFILTER. Their types are

   LMAP    : ('a -> 'b) -> 'a llist -> 'b llist
   LFINITE : 'a llist -> bool
   LNTH    : num -> 'a llist -> 'a option
   LTAKE   : num -> 'a llist -> 'a list option
   LDROP   : num -> 'a llist -> 'a llist option
   LFILTER : ('a -> bool) -> 'a llist -> 'a llist

They are characterised by the following theorems

LMAP
  ⊢ (∀f. LMAP f [||] = [||]) ∧ ∀f h t. LMAP f (h:::t) = f h:::LMAP f t
LFINITE_THM
  ⊢ (LFINITE [||] ⇔ T) ∧ ∀h t. LFINITE (h:::t) ⇔ LFINITE t
LNTH_THM
  ⊢ (∀n. LNTH n [||] = NONE) ∧ (∀h t. LNTH 0 (h:::t) = SOME h) ∧
     ∀n h t. LNTH (SUC n) (h:::t) = LNTH n t
LTAKE_THM
  ⊢ (∀l. LTAKE 0 l = SOME []) ∧ (∀n. LTAKE (SUC n) [||] = NONE) ∧
     ∀n h t. LTAKE (SUC n) (h:::t) = OPTION_MAP (CONS h) (LTAKE n t)
LDROP_THM
  ⊢ (∀ll. LDROP 0 ll = SOME ll) ∧ (∀n. LDROP (SUC n) [||] = NONE) ∧
     ∀n h t. LDROP (SUC n) (h:::t) = LDROP n t
LFILTER_THM
  ⊢ (∀P. LFILTER P [||] = [||]) ∧
     ∀P h t. LFILTER P (h:::t) = if P h then h:::LFILTER P t else LFILTER P t

Concatenation. Two lazy lists may be concatenated by LAPPEND (written below using its infix Unicode form ++$_l$). If the first lazy list is infinite, elements of the second are inaccessible in the result. A lazy list of lazy lists can be flattened to a lazy list by LFLATTEN.

LAPPEND
  ⊢ (∀x. [||] ++ₗ x = x) ∧ ∀h t x. h:::t ++ₗ x = h:::(t ++ₗ x)
LFLATTEN_THM
  ⊢ LFLATTEN [||] = [||] ∧ (∀tl. LFLATTEN ([||]:::t) = LFLATTEN t) ∧
     ∀h t tl. LFLATTEN ((h:::t):::tl) = h:::LFLATTEN (t:::tl)

Lists and lazy lists. Mapping back and forth from lists to lazy lists is accomplished by fromList and toList:

fromList_def
  ⊢ fromList [] = [||] ∧ ∀h t. fromList (h::t) = h:::fromList t
toList_THM
  ⊢ toList [||] = SOME [] ∧
     ∀h t. toList (h:::t) = OPTION_MAP (CONS h) (toList t)

Note that toList ll = NONE when ll is infinite.

Proof principles. Finally, there are two very important proof principles for proving that two llist values are equal. The first states that two sequences are equal if they return the same prefixes of length $n$ for all possible values of $n$:

LTAKE_EQ
  ⊢ ∀ll1 ll2. ll1 = ll2 ⇔ ∀n. LTAKE n ll1 = LTAKE n ll2

This theorem is subsequently used to derive the bisimulation principle:

LLIST_BISIMULATION
  ⊢ ∀ll1 ll2.
       ll1 = ll2 ⇔
       ∃R. R ll1 ll2 ∧
           ∀ll3 ll4.
             R ll3 ll4 ⇒
             ll3 = [||] ∧ ll4 = [||] ∨
             LHD ll3 = LHD ll4 ∧ R (THE (LTL ll3)) (THE (LTL ll4))

The principle of bisimulation states that two llist values $l_1$ and $l_2$ are equal if (and only if) it is possible to find a relation $R$ such that

• $R$ relates the two values, i.e., $R\;l_1\;l_2$; and
• if $R$ holds of any two values $l_3$ and $l_4$, then either
  • both $l_3$ and $l_4$ are empty; or
  • the head elements of $l_3$ and $l_4$ are the same, and the tails of those two values are again related by $R$

Of course, a possible $R$ would be equality itself, but the strength of this theorem is that other, more convenient relations can also be used.

Labelled paths (path)

The theory path defines a binary type operator $(\alpha,\beta)\,\mathtt{path}$, which stands for possibly infinite paths of the following form

$$ \alpha_1 \stackrel{\beta_1}{\longrightarrow} \alpha_2 \stackrel{\beta_2}{\longrightarrow} \alpha_3 \stackrel{\beta_3}{\longrightarrow} \cdots \alpha_n \stackrel{\beta_n}{\longrightarrow} \alpha_{n+1} \stackrel{\beta_{n+1}}{\longrightarrow} \cdots $$

The path type is thus an appropriate model for reduction sequences, where the $\alpha$ parameter corresponds to “states”, and the $\beta$ parameter corresponds to the labels on the arrows.

The model of $(\alpha,\beta)\,\mathtt{path}$ is $\alpha \times ((\alpha\times\beta)\,\mathtt{llist})$. The type of paths has two constructors:

   stopped_at : 'a -> ('a,'b) path
   pcons      : 'a -> 'b -> ('a,'b) path -> ('a,'b) path

The stopped_at constructor returns a path containing just one state, and no transitions. (Thus, the reduction sequence has “stopped at” this state.) The pcons constructor takes a state, a label, and a path, and returns a path which is now headed by the state argument, and which moves from that state via the label argument to the path. Graphically, $\mathtt{pcons}\;x\;l\;p$ is equal to

$$ x \stackrel{l}{\longrightarrow} \underbrace{p_1 \stackrel{l_1}{\longrightarrow} p_2 \stackrel{l_2}{\longrightarrow} \cdots\quad}_p $$

Other constants defined in theory path include

   finite  : ('a,'b) path -> bool
   first   : ('a,'b) path -> 'a
   labels  : ('a,'b) path -> 'b llist
   last    : ('a,'b) path -> 'a
   length  : ('a,'b) path -> num option
   okpath  : ('a -> 'b -> 'a -> bool) -> ('a,'b) path -> bool
   pconcat : ('a,'b) path -> 'b -> ('a,'b) path -> ('a,'b) path
   pmap    : ('a -> 'c) -> ('b -> 'd) -> ('a,'b)path -> ('c,'d)path

The first function returns the first element of a path. There always is such an element, and the defining equations are

first_thm
  ⊢ (∀x. first (stopped_at x) = x) ∧ ∀x r p. first (pcons x r p) = x

On the other hand, the last function does not always have a well-specified value, though it still has nice characterising equations:

last_thm
  ⊢ (∀x. last (stopped_at x) = x) ∧ ∀x r p. last (pcons x r p) = last p

The theorem for finite has a similar feel, but has a definite value (F, or false) on infinite paths, whereas the value of last on such paths is unspecified:

finite_thm
  ⊢ (∀x. finite (stopped_at x) ⇔ T) ∧
     ∀x r p. finite (pcons x r p) ⇔ finite p

The function pconcat concatenates two paths, linking them with a provided label. If the first path is infinite, then the result is equal to that first path. The defining equation is

pconcat_thm
  ⊢ (∀x lab p2. pconcat (stopped_at x) lab p2 = pcons x lab p2) ∧
     ∀x r p lab p2.
       pconcat (pcons x r p) lab p2 = pcons x r (pconcat p lab p2)

These equations are true even when the first argument to pconcat is an infinite path.

The okpath predicate tests whether or not a path is a valid transition given a ternary transition relation. Its characterising theorem is

okpath_thm
  ⊢ ∀R. (∀x. okpath R (stopped_at x)) ∧
         ∀x r p. okpath R (pcons x r p) ⇔ R x r (first p) ∧ okpath R p

There is also an induction principle that simplifies reasoning about finite $R$-paths:

finite_okpath_ind
  ⊢ ∀R. (∀x. P (stopped_at x)) ∧
         (∀x r p.
            okpath R p ∧ finite p ∧ R x r (first p) ∧ P p ⇒ P (pcons x r p)) ⇒
         ∀sigma. okpath R sigma ∧ finite sigma ⇒ P sigma

One can show that a set P of paths are all $R$-paths with the co-induction principle:

okpath_co_ind
  ⊢ ∀P. (∀x r p. P (pcons x r p) ⇒ R x r (first p) ∧ P p) ⇒
         ∀p. P p ⇒ okpath R p

Character strings (string)

The theory string defines a type of characters and a type of finite strings built from those characters, along with a useful suite of definitions for operating on strings.

Characters. The type char is represented by the numbers less than 256. Two constants are defined: CHR : $\konst{num}\to\konst{char}$ and ORD : $\konst{char}\to\konst{num}$. The following theorems hold:

  CHR_ORD  |- !a. CHR (ORD a) = a
  ORD_CHR  |- !r. r < 256 = (ORD (CHR r) = r)

Character literals can also be entered using ML syntax, with a hash character immediately followed by a string literal of length one. Thus:

> load "stringTheory";
val it = (): unit
> val t = ``f #"c" #"\n"``;
<<HOL message: inventing new type variable names: 'a>>
val t = “f #"c" #"\n"”: term

> dest_comb ``#"\t"``;
val it = (“CHR”, “9”): term * term

Strings. The type string is an alias for the type char list. All functions and predicates over lists are thus available for use over strings. Some of these constants are overloaded so that they are printed (and can be parsed) with names that are more appropriate for the particular case of lists of characters.

For example, NIL and CONS over strings have alternative names EMPTYSTRING and STRING respectively:

   EMPTYSTRING : string
   STRING      : char -> string -> string

The HOL parser maps the syntax "" to EMPTYSTRING, and the HOL printer inverts this. The parser expands string literals of the form "$c_1\,c_2\,\ldots\,c_n$" to the compound term

$$ \mathtt{STRING}\;c_1\;(\mathtt{STRING}\;c_2\,\ldots\, (\mathtt{STRING}\;c_{n-1}\;(\mathtt{STRING}\; c_n\;\mathtt{EMPTYSTRING}))\,\ldots\,) $$

Of course, one could also write

> ``[#"a"; #"b"]``;
val it = “"ab"”: term

String literals can be constructed using the various special escape sequences that are used in ML. For example, \n for the newline character, and a backslash followed by three decimal digits for characters of the given number.

> val t = ``"foo bar\n\001"``;
val t = “"foo bar\n\^A"”: term

Note that if one wants to use the control-character syntax with the caret that the pretty-printer has chosen to use in printing the given string, and this occurs inside a quotation, then the caret will need to be doubled. (See Section 8.1.3.)

As with numerals, string literals can be injected into other types, where it might make sense to have string literals appear to inhabit types in addition to the core system's string type. Such literals can be written with different delimiters to make it clear that such an injection has occurred. For more on this facility, see the REFERENCE manual's description of the add_strliteral_form function.

There is also a destructor function DEST_STRING for strings which returns an option type:

DEST_STRING_def
  ⊢ DEST_STRING "" = NONE ∧
     ∀c rst. DEST_STRING (STRING c rst) = SOME (c,rst)

Case expressions. Compound HOL expressions that branch based on whether a term is an empty or non-empty string can be written with the surface syntax

   case s
    of "" => e1
     | STRING c rst => e2

Such an expression is actually a case-expression over the underlying list, and so the underlying constant is that for lists.

Length and concatenation. A standard function LENGTH can be written STRLEN when applied to a string, and APPEND can be written as STRCAT. There are also theorems characterising these constants in stringTheory, though they are simply instantiations of results from listTheory:

   STRLEN_THM
     |- (STRLEN "" = 0) /\
        (STRLEN (STRING c s) = 1 + STRLEN s)

   STRCAT_EQNS =
     |- (STRCAT "" s = s) /\
        (STRCAT s "" = s) /\
        (STRCAT (STRING c s1) s2 = STRING c (STRCAT s1 s2))

Strings into numbers, and vice versa.

It is natural to want to convert strings to and from (natural) numbers. Constants supporting this for a variety of bases ($2$, $8$, $10$, and $16$) are defined in the theory ASCIInumbersTheory. There the constants are named according to the scheme

$$ \mathtt{num\_}\{\mathtt{to},\mathtt{from}\}\mathtt{\_}\{\mathtt{bin},\mathtt{oct},\mathtt{dec},\mathtt{hex}\}\mathtt{\_string} $$

making for a total of eight constants. The two decimal constants are also available under the (overloaded) names toString and toNum. The natural theorem expressing these last two are inverse is

toNum_toString
  ⊢ ∀n. toNum (toString n) = n

and there is also a theorem specifying how long the strings produced by toString will be:

LENGTH_num_to_dec_string
  ⊢ STRLEN (toString n) = if n = 0 then 1 else LOG 10 n + 1

Collections

Several different notions of a collection of elements are available in HOL: sets, multisets, relations, and finite maps.

Sets (pred_set)

An extensive development of set theory is available in the theory pred_set. Sets are represented by functions of the type $\alpha\to\konst{bool}$, i.e., they are so-called characteristic functions. One can use the type abbreviation $\alpha\;\konst{set}$ instead of $\alpha\to\konst{bool}$. Sets may be finite or infinite. All of the elements in a set must have the same type.

Set membership is the basic notion that formalized set theory is based on. In HOL, membership is represented by a the infix constant IN, defined in theory bool for convenience.

IN_DEF
  ⊢ $IN = (λx f. f x)

The IN operator is merely a way of applying the characteristic function to an item, as the following trivial consequence of the definition shows:

SPECIFICATION
  ⊢ ∀P x. x ∈ P ⇔ P x

Two sets are equal if they have the same elements.

EXTENSION
  ⊢ ∀s t. s = t ⇔ ∀x. x ∈ s ⇔ x ∈ t

The negation of set-membership is not a separate constant, but is available as a convenient overload (in both ASCII and Unicode forms). Thus, instead of writing ~(e IN s), one can instead write e NOTIN s or e ∉ s.

Empty and universal sets. The empty set is the characteristic function that is constantly false. The constant EMPTY denotes the empty set; it may be written as {} and ∅ (U+2205). The universal set, UNIV, on a type is the characteristic function that is always true for elements of that type.

EMPTY_DEF
  ⊢ ∅ = (λx. F)
UNIV_DEF
  ⊢ 𝕌(:α) = (λx. T)

In addition to UNIV (perhaps with a type annotation :'a set), one may also write univ(:'a) to represent the universal set over type :'a. The Unicode syntax 𝕌(:'a) means the same. The Unicode symbol for $\mathbb{U}$ is U+1D54C, and may not exist in many fonts.

One of these forms will be used to print UNIV by default. The user trace (see Section 10.2) "Univ pretty-printing" can be set to zero to cancel this behaviour. Additionally, the trace "Unicode Univ printing" can be used to stop the U+1D54C syntax from being used, even if the Unicode trace is set.

The symbols univ and 𝕌 are high-priority prefixes (see Section 8.1.2.6), and overloaded patterns (see Section 8.1.2.3) mapping a value of the itself type to the corresponding UNIV constant. One effect is that one can write things like

   FINITE univ(:'a)

without the need for parentheses around FINITE's argument.

Insertion, union, and intersection. The insertion (INSERT, written infix) of an element into a set is defined with a set comprehension. Set comprehension is discussed in the next subsection. Set union (UNION, written infix) and intersection (INTER, also infix) are given their usual definitions by set comprehension.

INSERT_DEF
  ⊢ ∀x s. x INSERT s = {y | y = x ∨ y ∈ s}
UNION_DEF
  ⊢ ∀s t. s ∪ t = {x | x ∈ s ∨ x ∈ t}
INTER_DEF
  ⊢ ∀s t. s ∩ t = {x | x ∈ s ∧ x ∈ t}

UNION and INTER are binary operations. Indexed union and intersection operations, i.e., $\bigcup_{i\in P}$ and $\bigcap_{i\in P}$ are provided by the definitions of BIGUNION and BIGINTER.

BIGUNION
  ⊢ ∀P. BIGUNION P = {x | ∃s. s ∈ P ∧ x ∈ s}
BIGINTER
  ⊢ ∀P. BIGINTER P = {x | ∀s. s ∈ P ⇒ x ∈ s}

Both BIGUNION and BIGINTER reduce a set of sets to a set and thus have the type $((\alpha\to\konst{bool})\to\konst{bool})\to(\alpha\to\konst{bool})$.

Subsets. Set inclusion (SUBSET, infix), proper set inclusion (PSUBSET, infix), and power set (POW) are defined as follows:

SUBSET_DEF
  ⊢ ∀s t. s ⊆ t ⇔ ∀x. x ∈ s ⇒ x ∈ t
PSUBSET_DEF
  ⊢ ∀s t. s ⊂ t ⇔ s ⊆ t ∧ s ≠ t
POW_DEF
  ⊢ ∀set. POW set = {s | s ⊆ set}

Set difference and complement. The difference between two sets (DIFF, infix) is defined by a set comprehension. Based on that, the deletion of a single element (DELETE, infix) from a set is straightforward. Since the universe of a type is always available via UNIV, the complement (COMPL) of a set may be taken.

DIFF_DEF
  ⊢ ∀s t. s DIFF t = {x | x ∈ s ∧ x ∉ t}
DELETE_DEF
  ⊢ ∀s x. s DELETE x = s DIFF {x}
COMPL_DEF
  ⊢ ∀P. COMPL P = 𝕌(:α) DIFF P

Functions on sets. The image of a function $f:\alpha\to\beta$ on a set (IMAGE) is defined with a set comprehension.

IMAGE_DEF
  ⊢ ∀f s. IMAGE f s = {f x | x ∈ s}

Injections, surjections, and bijections between sets are defined as follows:

INJ_DEF
  ⊢ ∀f s t.
       INJ f s t ⇔
       (∀x. x ∈ s ⇒ f x ∈ t) ∧ ∀x y. x ∈ s ∧ y ∈ s ⇒ f x = f y ⇒ x = y
SURJ_DEF
  ⊢ ∀f s t.
       SURJ f s t ⇔
       (∀x. x ∈ s ⇒ f x ∈ t) ∧ ∀x. x ∈ t ⇒ ∃y. y ∈ s ∧ f y = x
BIJ_DEF
  ⊢ ∀f s t. BIJ f s t ⇔ INJ f s t ∧ SURJ f s t

Finite sets. The finite sets (FINITE) are defined inductively as those built from the empty set by a finite number of insertions.

FINITE_DEF
  ⊢ ∀s. FINITE s ⇔ ∀P. P ∅ ∧ (∀s. P s ⇒ ∀e. P (e INSERT s)) ⇒ P s

A set is infinite iff it is not finite, and there is an abbreviation in the system that parses "INFINITE s" into "~FINITE s". The pretty-printer reverses this transformation.

The finite sets have an induction theorem:

FINITE_INDUCT
  ⊢ ∀P. P ∅ ∧ (∀s. FINITE s ∧ P s ⇒ ∀e. e ∉ s ⇒ P (e INSERT s)) ⇒
         ∀s. FINITE s ⇒ P s

As mentioned, set operations apply to both finite and infinite sets. However, some operations, such as cardinality (CARD), are only defined for finite sets. (See Section 6.1.2 for the theory of cardinality of possibly infinite sets.)

CARD_DEF
  ⊢ CARD ∅ = 0 ∧
     ∀s. FINITE s ⇒
         ∀x. CARD (x INSERT s) = if x ∈ s then CARD s else SUC (CARD s)

Since the finite and infinite sets are dealt with uniformly in pred_set, properties of operations on finite sets must explicitly include constraints about finiteness. For example the following theorem relating cardinality and subsets is only true for finite sets.

CARD_PSUBSET
  ⊢ ∀s. FINITE s ⇒ ∀t. t ⊂ s ⇒ CARD t < CARD s

An extensive suite of theorems dealing with finiteness and cardinality is available in pred_set.

Cross product. The product of two sets (CROSS, infix) is defined with a set comprehension.

CROSS_DEF
  ⊢ ∀P Q. P × Q = {p | FST p ∈ P ∧ SND p ∈ Q}

Cardinality and cross product are related by the following theorem:

CARD_CROSS
  ⊢ ∀P Q. FINITE P ∧ FINITE Q ⇒ CARD (P × Q) = CARD P * CARD Q

Recursive functions on sets. Recursive functions on sets may be defined by wellfounded recursion. Usually, the totality of such a function is established by measuring the cardinality of the (finite) set. However, another theorem may be used to justify a fold (ITSET) for finite sets. Provided a function $f:\alpha\to\beta\to\beta$ obeys a condition known as left-commutativity, namely, $f\;x\;(f\;y\;z) = f\;y\;(f\;x\;z)$, then $f$ can be applied by folding it on the set in a tail-recursive fashion.

ITSET_THM
  ⊢ ∀s f b.
       FINITE s ⇒
       ITSET f s b = if s = ∅ then b else ITSET f (REST s) (f (CHOICE s) b)

ITSET_EMPTY
  ⊢ ∀f b. ITSET f ∅ b = b

COMMUTING_ITSET_INSERT
  ⊢ ∀f s.
       (∀x y z. f x (f y z) = f y (f x z)) ∧ FINITE s ⇒
       ∀x b. ITSET f (x INSERT s) b = ITSET f (s DELETE x) (f x b)

A recursive version is also available:

COMMUTING_ITSET_RECURSES
  ⊢ ∀f e s b.
       (∀x y z. f x (f y z) = f y (f x z)) ∧ FINITE s ⇒
       ITSET f (e INSERT s) b = f e (ITSET f (s DELETE e) b)

For the full derivation, see the sources of pred_set. The definition of ITSET allows, for example, the definition of summing the results of a function on a finite set of elements, from which a recursive characterization and other useful theorems are derived.

SUM_IMAGE_DEF
  ⊢ ∀f s. ∑ f s = ITSET (λe acc. f e + acc) s 0
SUM_IMAGE_THM
  ⊢ ∀f. ∑ f ∅ = 0 ∧
         ∀e s. FINITE s ⇒ ∑ f (e INSERT s) = f e + ∑ f (s DELETE e)

Other definitions and theorems. There are more definitions in pred_set, but they are not as heavily used as the ones presented here. Similarly, most theorems in pred_set relate the various common set operations to each other, but do not express any deep theorems of set theory.

However, one notable theorem is Koenig's Lemma, which states that every finitely branching infinite tree has an infinite path. There are many ways to formulate this theorem, depending on how the notion of tree is formalized. In HOL's formulation, the tree is characterised by making various assumptions about the finite-ness or otherwise of elements reachable using a relation R. Then the following version of Koenig's Lemma is stated and proved:

KoenigsLemma
  ⊢ ∀R. (∀x. FINITE {y | R x y}) ⇒
         ∀x. INFINITE {y | R꙳ x y} ⇒ ∃f. f 0 = x ∧ ∀n. R (f n) (f (SUC n))

Syntax for sets

The special purpose set-theoretic notations {$t_1; t_2; \ldots; t_n$} and {$t$|$p$} are recognized by the HOL parser and printer when the theory pred_set is loaded.

The normal interpretation of {$t_1;t_2;\ldots;t_n$} is the finite set containing just $t_1, t_2, \ldots, t_n$. This can be modelled by starting with the empty set and performing a sequence of insertions. For example, {1;2;3;4} parses to

   1 INSERT (2 INSERT (3 INSERT (4 INSERT EMPTY)))

Set comprehensions. The normal interpretation of {$t$|$p$} is the set of all $t$s such that $p$. In HOL, such syntax parses to:

GSPEC(\($x_1$,…,$x_n$).($t$,$p$))

where $x_1, \ldots, x_n$ are those free variables that occur in both $t$ and $p$ if both have at least one free variable. If $t$ or $p$ has no free variables, then $x_1,\ldots,x_n$ are taken to be the free variables of the other term. If both terms have free variables, but there is no overlap, then an error results. The order in which the variables are listed in the variable structure of the paired abstraction is an unspecified function of the structure of $t$ (it is approximately left to right). For example,

   {p+q | p < q /\ q < r}

parses to:

   GSPEC(\(p,q). ((p+q), (p < q /\ q < r)))

where GSPEC is characterized by:

GSPECIFICATION
  ⊢ ∀f v. v ∈ GSPEC f ⇔ ∃x. (v,T) = f x

This somewhat cryptic specification can be understood by exercising an example. The syntax

   a IN {p+q | p < q /\ q < r}

is mapped by the HOL parser to

   a IN GSPEC(\(p,q). ((p+q), (p < q /\ q < r)))

which, by GSPECIFICATION, is equal to

   ?x. (a,T) = (\(p,q). ((p+q), (p < q /\ q < r))) x

The existentially quantified variable x has a pair type, so it can be replaced by a pair (p,q) and a paired-$\beta$-reduction can be performed, yielding

   ?(p,q). (a,T) = ((p+q), (p < q /\ q < r))

which is equal to the intended meaning of the original syntax:

   ?(p,q). (a = p+q) /\ (p < q /\ q < r)

Unambiguous set comprehensions. There is also an unambiguous set comprehension syntax, which allows the user to specify which variables are to be quantified over in the abstraction that is the argument of GSPEC. Terms of the form

   { t | vs | P }

generate sets containing values of the form given by t, where the variables mentioned in vs must satisfy the constraint P. For example, the set

   { x + y | x | x < y }

is the set of numbers from y up to but not including 2 * y. The set can be “read” computationally: draw out all those x that are less than y, and to each such x add y, thereby generating a set of numbers.

In the example above, the underlying GSPEC term will be

   GSPEC (\x. (x + y, x < y))

The vs component of the unambiguous notation must be a single “variable structure” that might appear underneath a possibly paired abstraction as in Section 5.2.3.1. In other words, this

   { x + y | (x,y) | x < y }

is fine, but this

   { x + y | x y | x < y }

will raise an error. (Additionally, the outermost parentheses around pairs in the vs position can be omitted.)

The unambiguous notation is printed by the pretty-printer whenever the set to be printed can not be expressed with the default notation, or if the trace variable with name pp_unambiguous_comprehensions is set to 1. (If the same trace is set to 2, then the unambiguous notation will never be used.)

Decision procedure for set-theoretic theorems

HOL provides some tools (in bossLib) to automate the proof of some routine pred_set theorems by a reduction to first-order logic, ported from HOL Light. They are based on metisLib (see Section 8.4.2). Below are the entry-points: (see the REFERENCE manual for more details.)

   SET_TAC     : thm list -> tactic
   ASM_SET_TAC : thm list -> tactic
   SET_RULE    : term -> thm

The difference between SET_TAC and ASM_SET_TAC is that the latter one also makes use of assumptions. With them, many simple set-theoretic results can be directly proved without finding needed lemmas in pred_setTheory. For instance, a simple lemma from util_probTheory:

Theorem DISJOINT_RESTRICT_L :
  !s t c. DISJOINT s t ==> DISJOINT (s INTER c) (t INTER c)
Proof SET_TAC []
QED

Multisets (bag)

Multisets, also known as bags, are similar to sets, except that they allow repeat occurrences of an element. Whereas sets are represented by functions of type $\alpha\to\konst{bool}$, which signal the presence, or absence, of an element, multisets are represented by functions of type $\alpha\to\konst{num}$, which give the multiplicity of each element in the multiset. Multisets may be finite or infinite.

The type abbreviations $\alpha\;\konst{multiset}$ and $\alpha\;\konst{bag}$ can be used instead of $\alpha\to\konst{num}$.

Empty multiset. The empty bag has no elements. Thus, the function implementing it returns $0$ for every input.

EMPTY_BAG
  ⊢ {||} = K 0

The special syntax {||} (the analogue of [] for lists, and {} for sets) is used for both printing and parsing, but the underlying constant is indeed called EMPTY_BAG, and this name can also be passed to the parser.

Membership. Much of the theory can be based on the notion of membership in a bag. There are two notions: does an element occur at least $n$ times in a bag (BAG_INN); and does an element occur in a bag at all (BAG_IN).

BAG_INN
  ⊢ ∀e n b. BAG_INN e n b ⇔ b e ≥ n
BAG_IN
  ⊢ ∀e b. e ⋲ b ⇔ BAG_INN e 1 b

Two bags are equal if all elements have the same tally.

BAG_EXTENSION
  ⊢ ∀b1 b2. b1 = b2 ⇔ ∀n e. BAG_INN e n b1 ⇔ BAG_INN e n b2

Sub-multiset. A sub-bag relationship (SUB_BAG) holds between $b_1$ and $b_2$ provided that every element in $b_1$ occurs at least as often in $b_2$. The notion of a proper sub-bag (PSUB_BAG) is easily defined.

SUB_BAG
  ⊢ ∀b1 b2. b1 ≤ b2 ⇔ ∀x n. BAG_INN x n b1 ⇒ BAG_INN x n b2
PSUB_BAG
  ⊢ ∀b1 b2. b1 < b2 ⇔ b1 ≤ b2 ∧ b1 ≠ b2

Insertion. Inserting an element into a bag (BAG_INSERT) updates the tally for that element and leaves the others unchanged.

BAG_INSERT
  ⊢ ∀e b. BAG_INSERT e b = (λx. if x = e then b e + 1 else b x)

Explicitly-given multisets are supported by the syntax {|$t_1; t_2; \ldots; t_n$|}, where there may, of course, be repetitions. This is modelled by starting with the empty multiset and performing a sequence of insertions. For example, {|1; 2; 3; 2; 1|} parses to

   BAG_INSERT 1 (BAG_INSERT 2 (BAG_INSERT 3
                                 (BAG_INSERT 2 (BAG_INSERT 1 {||}))))

Union and difference. The union (BAG_UNION) and difference (BAG_DIFF) operations on bags both reduce to an arithmetic calculation on their elements. Deleting a single element from a bag may be expressed by taking the multiset difference with a single-element multiset; however, there is also a relational presentation (BAG_DELETE) which relates its first and last arguments only if the first contains exactly one more occurrence of the middle argument than the last. This is not the same as using BAG_DIFF to remove a one-element bag because it insists that the element being removed actually appear in the larger bag.

BAG_UNION
  ⊢ ∀b c. b ⊎ c = (λx. b x + c x)
BAG_DIFF
  ⊢ ∀b1 b2. b1 − b2 = (λx. b1 x − b2 x)
BAG_DELETE
  ⊢ ∀b0 e b. BAG_DELETE b0 e b ⇔ b0 = BAG_INSERT e b

Intersection, merge, and filter. The intersection of two bags (BAG_INTER) takes the pointwise minimum. The dual operation, merging (BAG_MERGE), takes the pointwise maximum. A bag can be ‘filtered’ by a set to return the bag where all the elements not in the set have been dropped (BAG_FILTER).

BAG_INTER
  ⊢ ∀b1 b2. BAG_INTER b1 b2 = (λx. if b1 x < b2 x then b1 x else b2 x)
BAG_MERGE
  ⊢ ∀b1 b2. BAG_MERGE b1 b2 = (λx. if b1 x < b2 x then b2 x else b1 x)
BAG_FILTER_DEF
  ⊢ ∀P b. BAG_FILTER P b = (λe. if P e then b e else 0)

Sets and multisets. Moving between bags and sets is accomplished by the following two definitions.

SET_OF_BAG
  ⊢ ∀b. SET_OF_BAG b = (λx. x ⋲ b)
BAG_OF_SET
  ⊢ ∀P. BAG_OF_SET P = (λx. if x ∈ P then 1 else 0)

Image. Taking the image of a function on a multiset to get a new multiset seems to be simply a matter of applying the function to each element of the multiset. However, there is a problem if $f$ is non-injective and the multiset is infinite. For example, take the multiset consisting of all the natural numbers and apply $\lambda x.\;1$ to each element. The resulting multiset would hold an infinite number of $1$s. To avoid this requires some constraints: for example, stipulating that the function be only finitely non-injective, or that the input multiset be finite. Such conditions would be onerous in proof; the compromise is to map the multipicity of problematic elements to $0$.

BAG_IMAGE_DEF
  ⊢ ∀f b.
       BAG_IMAGE f b =
       (λe.
            (let
               sb = BAG_FILTER (λe0. f e0 = e) b
             in
               if FINITE_BAG sb then BAG_CARD sb else 1))

Finite multisets. The finite multisets (FINITE_BAG) are defined inductively as those built from the empty bag by a finite number of insertions.

FINITE_BAG
  ⊢ ∀b. FINITE_BAG b ⇔ ∀P. P {||} ∧ (∀b. P b ⇒ ∀e. P (BAG_INSERT e b)) ⇒ P b

The finite multisets have an induction theorem, and also a strong induction theorem.

FINITE_BAG_INDUCT
  ⊢ ∀P. P {||} ∧ (∀b. P b ⇒ ∀e. P (BAG_INSERT e b)) ⇒ ∀b. FINITE_BAG b ⇒ P b

STRONG_FINITE_BAG_INDUCT
  ⊢ ∀P. P {||} ∧ (∀b. FINITE_BAG b ∧ P b ⇒ ∀e. P (BAG_INSERT e b)) ⇒
         ∀b. FINITE_BAG b ⇒ P b

The cardinality (BAG_CARD) of a multiset counts the total number of occurrences. It is only specified for finite multisets.

BAG_CARD_THM
  ⊢ BAG_CARD {||} = 0 ∧
     ∀b. FINITE_BAG b ⇒ ∀e. BAG_CARD (BAG_INSERT e b) = BAG_CARD b + 1

Recursive functions on multisets. Recursive functions on multiset may be defined by wellfounded recursion. Usually, the totality of such a function is established by measuring the cardinality of the (finite) multiset. However, a fold (ITBAG) for finite sets is provided. Provided a function $f:\alpha\to\beta\to\beta$ obeys a condition known as left-commutativity, namely, $f\;x\;(f\;y\;z) = f\;y\;(f\;x\;z)$, then $f$ can be applied by folding it on the multiset in a tail-recursive fashion.

ITBAG_EMPTY
  ⊢ ∀f acc. ITBAG f {||} acc = acc
COMMUTING_ITBAG_INSERT
  ⊢ ∀f b.
       (∀x y z. f x (f y z) = f y (f x z)) ∧ FINITE_BAG b ⇒
       ∀x a. ITBAG f (BAG_INSERT x b) a = ITBAG f b (f x a)

A recursive version is also available:

COMMUTING_ITBAG_RECURSES
  ⊢ ∀f e b a.
       (∀x y z. f x (f y z) = f y (f x z)) ∧ FINITE_BAG b ⇒
       ITBAG f (BAG_INSERT e b) a = f e (ITBAG f b a)

Relations (relation)

Mathematical relations can be represented in HOL by the type $\alpha\to\beta\to\konst{bool}$. (In most applications, the type of a relation is an instance of $\alpha\to\alpha\to\konst{bool}$, but the extra generality doesn't hurt.) The theory relation provides definitions of basic properties and operations on relations, defines various kinds of orders and closures, defines wellfoundedness and proves the wellfounded recursion theorem, and develops some basic results used in Term Rewriting.

Basic properties. The following basic properties of relations are defined.

transitive_def
  ⊢ ∀R. transitive R ⇔ ∀x y z. R x y ∧ R y z ⇒ R x z
reflexive_def
  ⊢ ∀R. reflexive R ⇔ ∀x. R x x
irreflexive_def
  ⊢ ∀R. irreflexive R ⇔ ∀x. ¬R x x
symmetric_def
  ⊢ ∀R. symmetric R ⇔ ∀x y. R x y ⇔ R y x
antisymmetric_def
  ⊢ ∀R. antisymmetric R ⇔ ∀x y. R x y ∧ R y x ⇒ x = y
equivalence_def
  ⊢ ∀R. equivalence R ⇔ reflexive R ∧ symmetric R ∧ transitive R
trichotomous
  ⊢ ∀R. trichotomous R ⇔ ∀a b. R a b ∨ R b a ∨ a = b
total_def
  ⊢ ∀R. total R ⇔ ∀x y. R x y ∨ R y x

Basic operations. The following basic operations on relations are defined: the empty relation (EMPTY_REL, or $\emptyset\subr$), relation composition (O, or $\circ\subr$, infix), inversion (inv, or $\_^{\mathsf{T}}$ (suffix superscript ‘T’)), domain (RDOM), and range (RRANGE).

EMPTY_REL_DEF
  ⊢ ∀x y. ∅ᵣ x y ⇔ F
O_DEF
  ⊢ ∀R1 R2 x z. (R1 ∘ᵣ R2) x z ⇔ ∃y. R2 x y ∧ R1 y z
inv_DEF
  ⊢ ∀R x y. Rᵀ x y ⇔ R y x
RDOM_DEF
  ⊢ ∀R x. RDOM R x ⇔ ∃y. R x y
RRANGE
  ⊢ ∀R y. RRANGE R y ⇔ ∃x. R x y

Set operations lifted to work on relations include subset (RSUBSET, or $\subseteq\subr$, infix), union (RUNION, or $\cup\subr$, infix), intersection (RINTER, or $\cap\subr$, infix), complement (RCOMPL), and universe (RUNIV, or $\mathbb{U}\subr$).

RSUBSET
  ⊢ ∀R1 R2. R1 ⊆ᵣ R2 ⇔ ∀x y. R1 x y ⇒ R2 x y
RUNION
  ⊢ ∀R1 R2 x y. (R1 ∪ᵣ R2) x y ⇔ R1 x y ∨ R2 x y
RINTER
  ⊢ ∀R1 R2 x y. (R1 ∩ᵣ R2) x y ⇔ R1 x y ∧ R2 x y
RCOMPL
  ⊢ ∀R x y. RCOMPL R x y ⇔ ¬R x y
RUNIV
  ⊢ ∀x y. 𝕌ᵣ x y ⇔ T

Orders. A sequence of definitions capturing various notions of order are made in relation.

PreOrder
  ⊢ ∀R. PreOrder R ⇔ reflexive R ∧ transitive R
Order
  ⊢ ∀Z. Order Z ⇔ antisymmetric Z ∧ transitive Z
WeakOrder
  ⊢ ∀Z. WeakOrder Z ⇔ reflexive Z ∧ antisymmetric Z ∧ transitive Z
StrongOrder
  ⊢ ∀Z. StrongOrder Z ⇔ irreflexive Z ∧ transitive Z
LinearOrder
  ⊢ ∀R. LinearOrder R ⇔ Order R ∧ trichotomous R
WeakLinearOrder
  ⊢ ∀R. WeakLinearOrder R ⇔ WeakOrder R ∧ trichotomous R
StrongLinearOrder
  ⊢ ∀R. StrongLinearOrder R ⇔ StrongOrder R ∧ trichotomous R

Closures. The transitive closure (TC) of a relation $R:\alpha\to\alpha\to\konst{bool}$ is defined inductively, as the least relation including $R$ and closed under transitivity. Similarly, the reflexive-transitive closure (RTC) is defined to be the least relation closed under transitivity and reflexivity. The ASCII syntax for the transitive closure R^+ is meant to suggest the prettier R⁺. Similarly, R^* is meant to suggest R∗. Indeed, with Unicode enabled, transitive closure will print with a superscript +, and RTC will print as a superscript asterisk.

From the underlying definitions, one can recover the initial rules:

TC_RULES
  ⊢ ∀R. (∀x y. R x y ⇒ R⁺ x y) ∧ ∀x y z. R⁺ x y ∧ R⁺ y z ⇒ R⁺ x z
RTC_RULES
  ⊢ ∀R. (∀x. R꙳ x x) ∧ ∀x y z. R x y ∧ R꙳ y z ⇒ R꙳ x z
RTC_RULES_RIGHT1
  ⊢ ∀R. (∀x. R꙳ x x) ∧ ∀x y z. R꙳ x y ∧ R y z ⇒ R꙳ x z

Notice that RTC_RULES, in keeping with the definition of RTC, extends an R-step from x to y with a sequence of R-steps from y to z to construct R* x z. The theorem RTC_RULES_RIGHT1 first makes a sequence of R steps and then a single R step to form R* x z. Similar alternative theorems are proved for case analysis and induction.

For example, TC_CASES1 and TC_CASES2 in the following decompose R+ x z to either R x y followed by R+ y z (TC_CASES1) or R+ x y followed by R y z (TC_CASES2).

TC_CASES1
  ⊢ R⁺ x z ⇔ R x z ∨ ∃y. R x y ∧ R⁺ y z
TC_CASES2
  ⊢ R⁺ x z ⇔ R x z ∨ ∃y. R⁺ x y ∧ R y z

RTC_CASES1
  ⊢ ∀R x y. R꙳ x y ⇔ x = y ∨ ∃u. R x u ∧ R꙳ u y
RTC_CASES2
  ⊢ ∀R x y. R꙳ x y ⇔ x = y ∨ ∃u. R꙳ x u ∧ R u y
RTC_CASES_RTC_TWICE
  ⊢ ∀R x y. R꙳ x y ⇔ ∃u. R꙳ x u ∧ R꙳ u y

As well as the basic induction theorems for TC and RTC, there are so-called strong induction theorems, which have stronger induction hypotheses.

TC_INDUCT
  ⊢ ∀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
RTC_INDUCT
  ⊢ ∀R P.
       (∀x. P x x) ∧ (∀x y z. R x y ∧ P y z ⇒ P x z) ⇒
       ∀x y. R꙳ x y ⇒ P x y
TC_STRONG_INDUCT
  ⊢ ∀R P.
       (∀x y. R x y ⇒ P x y) ∧
       (∀x y z. P x y ∧ P y z ∧ R⁺ x y ∧ R⁺ y z ⇒ P x z) ⇒
       ∀u v. R⁺ u v ⇒ P u v
RTC_STRONG_INDUCT
  ⊢ ∀R P.
       (∀x. P x x) ∧ (∀x y z. R x y ∧ R꙳ y z ∧ P y z ⇒ P x z) ⇒
       ∀x y. R꙳ x y ⇒ P x y

Variants of these induction theorems are also available which break apart the closure from the left or right, as for the case analysis theorems.

The reflexive (RC) and symmetric closures (SC) are straightforward to define. The equivalence closure (EQC) is the symmetric then transitive then reflexive closure of $R$. When applied to an argument, as in EQC R, EQC is written with the suffix ^=. Note how the suffix binds more tightly than function application, so that in EQC_DEF, RC really is applied to the transitive closure of the symmetric closure of R.

RC_DEF
  ⊢ ∀R x y. RC R x y ⇔ x = y ∨ R x y
SC_DEF
  ⊢ ∀R x y. SC R x y ⇔ R x y ∨ R y x
EQC_DEF
  ⊢ ∀R. R^= = RC (SC R)⁺

Wellfounded relations.

A relation $R$ is wellfounded (WF) if every non-empty set has an $R$-minimal element. Wellfoundedness is used to justify the principle of wellfounded induction (WF_INDUCTION_THM).

WF_DEF
  ⊢ ∀R. WF R ⇔ ∀B. (∃w. B w) ⇒ ∃min. B min ∧ ∀b. R b min ⇒ ¬B b
WF_INDUCTION_THM
  ⊢ ∀R. WF R ⇒ ∀P. (∀x. (∀y. R y x ⇒ P y) ⇒ P x) ⇒ ∀x. P x

The wellfounded part (WFP) of a relation can be inductively defined, from which its rules, case-analysis theorem and induction theorems may be derived.

WFP_DEF
  ⊢ ∀R a. WFP R a ⇔ ∀P. (∀x. (∀y. R y x ⇒ P y) ⇒ P x) ⇒ P a
WFP_RULES
  ⊢ ∀R x. (∀y. R y x ⇒ WFP R y) ⇒ WFP R x
WFP_CASES
  ⊢ ∀R x. WFP R x ⇔ ∀y. R y x ⇒ WFP R y
WFP_INDUCT
  ⊢ ∀R P. (∀x. (∀y. R y x ⇒ P y) ⇒ P x) ⇒ ∀x. WFP R x ⇒ P x
WFP_STRONG_INDUCT
  ⊢ ∀R. (∀x. WFP R x ∧ (∀y. R y x ⇒ P y) ⇒ P x) ⇒ ∀x. WFP R x ⇒ P x

Wellfoundedness can also be used to justify a general recursion theorem. Intuitively, a collection of recursion equations can be admitted into the HOL logic with no loss of consistency provided that every possible sequence of recursive calls is finite. Wellfounded relations are used to capture this notion: if there is a wellfounded relation $R$ on the domain of the desired function such that every sequence of recursive calls is $R$-decreasing, then the recursion equations specify a unique total function and the equations can be admitted into the logic.

The recursion theorems WFREC_COROLLARY and WF_RECURSION_THM use the notion of a function restriction (RESTRICT) in order to force the recursive function to be applied to $R$-smaller arguments in recursive calls.

RESTRICT_DEF
  ⊢ ∀f R x. RESTRICT f R x = (λy. if R y x then f y else ARB)
WFREC_COROLLARY
  ⊢ ∀M R f. f = WFREC R M ⇒ WF R ⇒ ∀x. f x = M (RESTRICT f R x) x

WF_RECURSION_THM
  ⊢ ∀R. WF R ⇒ ∀M. ∃!f. ∀x. f x = M (RESTRICT f R x) x

The theorems WF_INDUCTION_THM and WFREC_COROLLARY are used to automate recursive definitions; see Section 7.6. A few basic operators for wellfounded relations are also defined, along with theorems stating that they propagate wellfoundedness.

inv_image_def
  ⊢ ∀R f. inv_image R f = (λx y. R (f x) (f y))

WF_inv_image
  ⊢ ∀R f. WF R ⇒ WF (inv_image R f)
WF_SUBSET
  ⊢ ∀R P. WF R ∧ (∀x y. P x y ⇒ R x y) ⇒ WF P
WF_TC
  ⊢ ∀R. WF R ⇒ WF R⁺
WF_EMPTY_REL
  ⊢ WF ∅ᵣ

Term Rewriting. A few basic definitions from Term Rewriting theory (the diamond property (diamond), the Church-Rosser property (CR and WCR), and Strong Normalization (SN)) appear in relation.

diamond_def
  ⊢ ∀R. diamond R ⇔ ∀x y z. R x y ∧ R x z ⇒ ∃u. R y u ∧ R z u
CR_def
  ⊢ ∀R. CR R ⇔ diamond R꙳
WCR_def
  ⊢ ∀R. WCR R ⇔ ∀x y z. R x y ∧ R x z ⇒ ∃u. R꙳ y u ∧ R꙳ z u
SN_def
  ⊢ ∀R. SN R ⇔ WF Rᵀ

From those, Newman's Lemma is proved.

Newmans_lemma
  ⊢ ∀R. WCR R ∧ SN R ⇒ CR R

Bisimulation for labelled transition systems (bisimulation)

HOL provides a minimal theory (bisimulation) for generating bisimulation and bisimulation relations (Milner 1989) from any labelled transition relation of the type $\alpha\to\beta\to\alpha\to\konst{bool}$. Suppose there is a user-defined labelled transition system (LTS) and ts is the transition relation in it, then ts p l q denotes a transition from $p$ to $q$ by an action $l$, i.e., $p\overset{l}{\longrightarrow}q$. A binary relation $R$ is called a bisimulation if BISIM ts R holds under the following definition:

BISIM_def
  ⊢ ∀ts R.
       BISIM ts R ⇔
       ∀p q.
         R p q ⇒
         ∀l. (∀p'. ts p l p' ⇒ ∃q'. ts q l q' ∧ R p' q') ∧
             ∀q'. ts q l q' ⇒ ∃p'. ts p l p' ∧ R p' q'

Furthermore, the bisimulation relation (or bisimilarity, usually denoted by $\sim$), BISIM_REL ts, is the union (in the sense of RUNION) of all bisimulations in this LTS, and it can be proven to be an equivalence relation: (the original definition hereafter)

BISIM_REL_def
  ⊢ ∀ts. BISIM_REL ts = (λp q. ∃R. BISIM ts R ∧ R p q)
BISIM_REL_IS_EQUIV_REL
  ⊢ ∀ts. equivalence (BISIM_REL ts)

Bisimulation is a special case of coinduction, by far the most studied coinductive concept (Sangiorgi 2012). In practice it is hard to directly work with the above definition of BISIM_REL. Partly for this reason, BISIM_REL is defined by the coinductive relation package (see Section 7.7.2):

CoInductive BISIM_REL :
    !p q. (!l.
            (!p'. ts p l p' ==> ?q'. ts q l q' /\ (BISIM_REL ts) p' q') /\
            (!q'. ts q l q' ==> ?p'. ts p l p' /\ (BISIM_REL ts) p' q'))
      ==> (BISIM_REL ts) p q
End

which automatically generates the following coinduction principle:

BISIM_REL_coind
  ⊢ ∀ts BISIM_REL'.
       (∀a0 a1.
          BISIM_REL' a0 a1 ⇒
          ∀l. (∀p'. ts a0 l p' ⇒ ∃q'. ts a1 l q' ∧ BISIM_REL' p' q') ∧
              ∀q'. ts a1 l q' ⇒ ∃p'. ts a0 l p' ∧ BISIM_REL' p' q') ⇒
       ∀a0 a1. BISIM_REL' a0 a1 ⇒ BISIM_REL ts a0 a1

A simple rewrite by BISIM_def shows that BISIM_REL defined in this way is actually equivalent to the original definition (which now becomes a theorem):¹⁴

> Q.SPECL [`ts`, `R`]
          (REWRITE_RULE [GSYM BISIM_def, GSYM RSUBSET] BISIM_REL_coind);
val it = ⊢ BISIM ts R ⇒ R ⊆ᵣ BISIM_REL ts: thm

The bisimulation and bisimulation relation considered so far are the strong ones, in the sense that all involved transitions are one-step transitions. To define weak bisimulation (and the corresponding weak bisimulation relation), beside the transition relation, the user must also designate a special unique action to be invisible (usually denoted by $\tau$). An empty transition (ETS) is the reflexive-transitive closure (RTC) of (one-step) invisible transitions:

ETS_def
  ⊢ ∀ts tau. ETS ts tau = (λx y. ts x tau y)꙳

Then a weak transition (WTS) is a one-step transition (the action may be invisible) concatenated with two empty transitions:

WTS_def
  ⊢ ∀ts tau.
       WTS ts tau =
       (λp l q. ∃p' q'. ETS ts tau p p' ∧ ts p' l q' ∧ ETS ts tau q' q)

An empty transition ETS ts tau p q is usually denoted by $p\overset{\varepsilon}{\Longrightarrow}q$ (assuming ts and tau is clear from the context), and a weak transition WTS ts tau p l q is denoted by $p\overset{l}{\Longrightarrow}q$. Note that a weak transition must have at least one transition (even it is $\tau$), while an empty transition may have no actual transition at all. To simplify the informal definitions, we denote by $p\overset{\hat{a}}{\Longrightarrow}q$ the special notion of weak transitions such that, whenever the action $a$ is invisible, it is the same as $p\overset{\varepsilon}{\Longrightarrow}q$.

A binary relation $R$ is a weak bisimulation if, whenever $p\;R\;q$,

• $p\overset{a}{\longrightarrow}p'$ implies that there is $q'$ such that $q\overset{\hat{a}}{\Longrightarrow}q'$ and $p'\;R\;q'$;
• $q\overset{a}{\longrightarrow}q'$ implies that there is $p'$ such that $p\overset{\hat{a}}{\Longrightarrow}p'$ and $p'\;R\;q'$.

$p$ and $p$ are weakly bisimilar, written as $p\approx q$, if $p\;R\;q$ for some bisimulation $R$.

Following the example of the strong case (including the use of the CoInductive command), below are the definition of weak bisimulation (WBISIM), the equivalent definition of weak bisimulation relation (WBISIM_REL) and the theorem saying WBISIM_REL ts tau is indeed an equivalence relation (in the LTS given by ts and tau):

WBISIM_def
  ⊢ ∀ts tau R.
       WBISIM ts tau R ⇔
       ∀p q.
         R p q ⇒
         (∀l. l ≠ tau ⇒
              (∀p'. ts p l p' ⇒ ∃q'. WTS ts tau q l q' ∧ R p' q') ∧
              ∀q'. ts q l q' ⇒ ∃p'. WTS ts tau p l p' ∧ R p' q') ∧
         (∀p'. ts p tau p' ⇒ ∃q'. ETS ts tau q q' ∧ R p' q') ∧
         ∀q'. ts q tau q' ⇒ ∃p'. ETS ts tau p p' ∧ R p' q'
WBISIM_REL_def
  ⊢ ∀ts tau. WBISIM_REL ts tau = (λp q. ∃R. WBISIM ts tau R ∧ R p q)
WBISIM_REL_IS_EQUIV_REL
  ⊢ ∀ts tau. equivalence (WBISIM_REL ts tau)

In examples/CCS, the HOL distribution includes a comprehensive formalization of Milner's Calculus of Communicating Systems (CCS) (Milner 1989), where the definitions of strong and weak bisimulations are based on the present bisimulation theory.

Finite maps (finite_map)

The theory finite_map formalizes a type $(\alpha,\beta)\,\mathtt{fmap}$ of finite functions. These notionally have type $\alpha\to\beta$, but additionally have only finitely many elements in their domain. Finite maps are useful for formalizing substitutions and arrays. The representing type is $\alpha\to\beta+\konst{one}$, where only a finite number of the $\alpha$ map to a $\beta$ and the rest map to one. The syntax $\alpha\,\mathtt{|->}\,\beta$ is recognized by the parser as an alternative to $(\alpha,\beta)\,\mathtt{fmap}$.

Basic notions. The empty map (FEMPTY), the updating of a map (FUPDATE), the application of a map to an argument (FAPPLY), and the domain of a map (FDOM) are the main notions in the theory.

   FEMPTY  : 'a |-> 'b
   FUPDATE : ('a |-> 'b) -> 'a # 'b -> ('a |-> 'b)
   FAPPLY  : ('a |-> 'b) -> 'a -> 'b
   FDOM    : ('a |-> 'b) -> 'a set

The HOL parser and printer will treat the syntax f ' x as the application of finite map f to argument x, i.e., as FAPPLY f x. The notation f |+ (k,v) represents FUPDATE f (k,v), i.e., the updating of finite map f by the pair (k,v). These are purely ASCII syntaxes, but the HOL printer and parser also support (and prefer, in the case of printing), $f\langle k\rangle$ for finite map application, and $f\langle k\mapsto v\rangle$ for FUPDATE. As with lists (see Section 5.4.1.2), the update syntax between angle brackets supports multiple updates, allowing $f\langle k_1\mapsto v_1;\;k_2\mapsto v_2;\dots\rangle$.

The basic constants have obscure definitions, from which more useful properties are then derived. FAPPLY_FUPDATE_THM relates map update with map application. fmap_EXT is an extensionality result: two maps are equal if they have the same domain and agree when applied to arguments in that domain. One can prove properties of finite maps by induction on the construction of the map (fmap_INDUCT). The cardinality of a finite map is just the cardinality of its domain (FCARD_DEF); from this a recursive characterization (FCARD_FUPDATE) is derived.

   FAPPLY_FUPDATE_THM
     ⊢ ∀f a b x. f⟨a ↦ b⟩⟨x⟩ = if x = a then b else f⟨x⟩
   fmap_EXT
     ⊢ ∀f g. f = g ⇔ FDOM f = FDOM g ∧ ∀x. x ∈ FDOM f ⇒ f⟨x⟩ = g⟨x⟩
   fmap_INDUCT
     ⊢ ∀P. P FEMPTY ∧ (∀f. P f ⇒ ∀x y. x ∉ FDOM f ⇒ P f⟨x ↦ y⟩) ⇒ ∀f. P f
   FCARD_DEF
     ⊢ ∀fm. FCARD fm = CARD (FDOM fm)
   FCARD_FUPDATE
     ⊢ ∀fm a b.
          FCARD fm⟨a ↦ b⟩ = if a ∈ FDOM fm then FCARD fm else 1 + FCARD fm

Iterated updates (FUPDATE_LIST) to a map are useful. The infix notation |++ may also be used. For example, fm |++ [(k1,v1); (k2,v2)] is equal to (fm |+ (k1,v1)) |+ (k2,v2).

   FUPDATE_LIST
     ⊢ $|++ = FOLDL $|+
   FUPDATE_LIST_THM
     ⊢ ∀f. f |++ [] = f ∧ ∀h t. f |++ (h::t) = f |+ h |++ t

Domain and range. The domain of a finite map is the set of elements that it applies to; this can be characterized recursively (FDOM_FUPDATE). The range of a map is defined in the usual way.

   FDOM_FUPDATE
     ⊢ ∀f a b. FDOM f⟨a ↦ b⟩ = a INSERT FDOM f
   FRANGE_DEF
     ⊢ ∀f. FRANGE f = {y | ∃x. x ∈ FDOM f ∧ f⟨x⟩ = y}

A finite map may have its domain (DRESTRICT) or range (RRESTRICT) restricted by intersection with a set. These notions have recursive versions as well (DRESTRICT_FUPDATE and RRESTRICT_FUPDATE).

   DRESTRICT_DEF
     ⊢ ∀f r.
          FDOM (DRESTRICT f r) = FDOM f ∩ r ∧
          ∀x. (DRESTRICT f r)⟨x⟩ = if x ∈ FDOM f ∩ r then f⟨x⟩ else FEMPTY⟨x⟩
   RRESTRICT_DEF
     ⊢ ∀f r.
          FDOM (RRESTRICT f r) = {x | x ∈ FDOM f ∧ f⟨x⟩ ∈ r} ∧
          ∀x. (RRESTRICT f r)⟨x⟩ =
              if x ∈ FDOM f ∧ f⟨x⟩ ∈ r then f⟨x⟩ else FEMPTY⟨x⟩
   DRESTRICT_FUPDATE
     ⊢ ∀f r x y.
          DRESTRICT f⟨x ↦ y⟩ r =
          if x ∈ r then (DRESTRICT f r)⟨x ↦ y⟩ else DRESTRICT f r
   RRESTRICT_FUPDATE
     ⊢ ∀f r x y.
          RRESTRICT f⟨x ↦ y⟩ r =
          if y ∈ r then (RRESTRICT f r)⟨x ↦ y⟩
          else RRESTRICT (DRESTRICT f (COMPL {x})) r

The removal of a single element from the domain of a map (\\, infix) is a simple application of DRESTRICT, but sufficiently useful to deserve its own definition. Again, this concept has a alternate recursive presentation (DOMSUB_FUPDATE_THM).

   fmap_domsub
     ⊢ ∀fm k. fm \\ k = DRESTRICT fm (COMPL {k})
   DOMSUB_FUPDATE_THM
     ⊢ ∀fm k1 k2 v.
          fm⟨k1 ↦ v⟩ \\ k2 = if k1 = k2 then fm \\ k2 else (fm \\ k2)⟨k1 ↦ v⟩

Similarly, the removal of multiple elements from the domain of a map (FDIFF) is defined in terms of DRESTRICT. It too has an alternate recursive presentation.

   FDIFF_def
     ⊢ ∀f1 s. FDIFF f1 s = DRESTRICT f1 (COMPL s)
   FDIFF_FUPDATE
     ⊢ FDIFF fm⟨k ↦ v⟩ s = if k ∈ s then FDIFF fm s else (FDIFF fm s)⟨k ↦ v⟩

Union and sub-maps. Unlike set union, the union of two finite maps (FUNION) is not symmetric: the domain of the first map takes precedence. The notion of a finite map being a submap of another (SUBMAP, infix) is an extension of how subsets are formalized.

   FUNION_DEF
     ⊢ ∀f g.
          FDOM (f ⊌ g) = FDOM f ∪ FDOM g ∧
          ∀x. (f ⊌ g)⟨x⟩ = if x ∈ FDOM f then f⟨x⟩ else g⟨x⟩
   SUBMAP_DEF
     ⊢ ∀f g. f ⊑ g ⇔ ∀x. x ∈ FDOM f ⇒ x ∈ FDOM g ∧ f⟨x⟩ = g⟨x⟩

Merges. The key-aware merge of two finite maps (FMERGE_WITH_KEY) generalises the left-biased union of two finite maps (FUNION). In FMERGE_WITH_KEY f m1 m2, rather than the domain of m1 taking precedence (as in FUNION), overlapping keys and their associated values are processed by the function parameter f.

   FMERGE_WITH_KEY_DEF
     ⊢ ∀f m1 m2.
          FDOM (FMERGE_WITH_KEY f m1 m2) = FDOM m1 ∪ FDOM m2 ∧
          ∀x. (FMERGE_WITH_KEY f m1 m2)⟨x⟩ =
              if x ∈ FDOM m1 ∧ x ∈ FDOM m2 then f x m1⟨x⟩ m2⟨x⟩
              else if x ∈ FDOM m1 then m1⟨x⟩
              else m2⟨x⟩

The key-ignorant merge of two finite maps (FMERGE) specialises FMERGE_WITH_KEY, and is itself a generalisation of FUNION.

   FMERGE_WITH_KEY_FMERGE
     ⊢ FMERGE f = FMERGE_WITH_KEY (λk v1 v2. f v1 v2)
   FMERGE_FUNION
     ⊢ FUNION = FMERGE (λx y. x)

Finite maps and functions. As much as possible, finite maps should be like ordinary functions. Thus, if f is a finite map, then FAPPLY f is an ordinary function. Similarly, there is an operation for totalizing a finite map (FLOOKUP) so that an application of it returns an ordinary function, the range of which is the option type. An ordinary function can be turned into a finite map by restricting the function to a finite set of arguments (FUN_FMAP_DEF).

   FLOOKUP_DEF
     ⊢ ∀f x. FLOOKUP f x = if x ∈ FDOM f then SOME f⟨x⟩ else NONE

   FUN_FMAP_DEF
     ⊢ ∀f P.
          FINITE P ⇒
          FDOM (FUN_FMAP f P) = P ∧ ∀x. x ∈ P ⇒ (FUN_FMAP f P)⟨x⟩ = f x

Composition of maps.

There are three new definitions of composition, determined by whether the composed functions are finite maps or not. The composition of two finite maps (f_o_f, infix) has domain constraints attached. Composition of a finite map with an ordinary function (o_f, infix) applies the finite map first, then the ordinary function. Composition of an ordinary function with a finite map (f_o, infix) applies the ordinary function and then the finite map; the application of the ordinary function is achieved by turning it into a finite map.

   f_o_f_DEF
     ⊢ ∀f g.
          FDOM (f f_o_f g) = FDOM g ∩ {x | g⟨x⟩ ∈ FDOM f} ∧
          ∀x. x ∈ FDOM (f f_o_f g) ⇒ (f f_o_f g)⟨x⟩ = f⟨g⟨x⟩⟩
   o_f_DEF
     ⊢ ∀f g.
          FDOM (f o_f g) = FDOM g ∧
          ∀x. x ∈ FDOM (f o_f g) ⇒ (f o_f g)⟨x⟩ = f g⟨x⟩
   f_o_DEF
     ⊢ ∀f g. f f_o g = f f_o_f FUN_FMAP g {x | g x ∈ FDOM f}

While Loops

It is a curious fact that higher order logic, although a logic of total functions, allows the definition of functions that don't seem total, at least from a computational perspective. An example is WHILE-loops. The following equation is derived in theory While:

WHILE
  ⊢ ∀P g x. WHILE P g x = if P x then WHILE P g (g x) else x

Clearly, if P in this theorem was instantiated to $\lambda x.\;\konst{T}$, the resulting instance of WHILE would ‘run forever’ if executed. Why is such an “obviously” partial function definable in HOL? The answer lies in a subtle definition of WHILE,¹⁵ which uses the expressive power of HOL to surprising effect. Consider the following total and non-recursive function:

  \x. if (?n. P (FUNPOW g n x))
       then FUNPOW g (@n. P (FUNPOW g n x) /\
                          !m.  m < n ==> ~P (FUNPOW g m x)) x
       else ARB

This function does a case analysis on the iterations of function g: the finite ones return the first value in the iteration at which P holds (i.e., when the iteration stops); the infinite ones are mapped to ARB. This function is used as the witness for f in the proof of the following theorem:

ITERATION
  ⊢ ∀P g. ∃f. ∀x. f x = if P x then x else f (g x)

From this, it is a simple application of Skolemization and new_specification to obtain the equation for WHILE.

Reasoning about WHILE loops. The induction theorem for WHILE loops is proved by wellfounded induction, and carries wellfoundedness constraints limiting its application. In order to apply WHILE_INDUCTION, the instantiations for B and C must be known before a wellfounded relation for R is found and used to eliminate the constraints.

WHILE_INDUCTION
  ⊢ ∀B C R.
       WF R ∧ (∀s. B s ⇒ R (C s) s) ⇒
       ∀P. (∀s. (B s ⇒ P (C s)) ⇒ P s) ⇒ ∀v. P v

A more refined level of support is provided by the standard Hoare Logic WHILE rule, phrased in terms of Hoare triples (HOARE_SPEC).

HOARE_SPEC_DEF
  ⊢ ∀P C Q. HOARE_SPEC P C Q ⇔ ∀s. P s ⇒ Q (C s)
WHILE_RULE
  ⊢ ∀R B C.
       WF R ∧ (∀s. B s ⇒ R (C s) s) ⇒
       HOARE_SPEC (λs. P s ∧ B s) C P ⇒
       HOARE_SPEC P (WHILE B C) (λs. P s ∧ ¬B s)

As a follow-on, an operator for finding the least number with property P is defined.

LEAST_DEF
  ⊢ ∀P. $LEAST P = WHILE ($¬ ∘ P) SUC 0

The LEAST constant is treated as a binder by the parser, which explains the special printing of the name above. Its use as a binder can be seen in:

LEAST_LESS_EQ
  ⊢ (LEAST x. y ≤ x) = y

A fundamental result, the operation of which is embodied in the tactic LEAST_ELIM_TAC is:

LEAST_ELIM
  ⊢ ∀Q P. (∃n. P n) ∧ (∀n. (∀m. m < n ⇒ ¬P m) ∧ P n ⇒ Q n) ⇒ Q ($LEAST P)

If one wants a specified result even when the predicate is everywhere false, the OLEAST function (also treated as a binder by the parser and pretty-printer) may be helpful:

OLEAST_def
  ⊢ ∀P. $OLEAST P = if ∃n. P n then SOME (LEAST n. P n) else NONE

More theorems for reasoning about LEAST, OLEAST and WHILE may be found in theory While.

Monads

HOL's simple type system means that it is impossible to define a general type of monad in the way that is possible in programming languages such as Haskell. Nonetheless, a number of the types predefined in HOL, such as options and lists, can indeed be seen as monads, and it is useful to be able to write functions over those types that leverage this view. Equally, it is useful to be able to declare monads of one's own that can use the same syntactic facilities.

Monads are defined by their “unit” and “bind” functions, and these can be composed in expressive ways. In particular, HOL supports a syntax inspired by Haskell's do notation, wherein it is possible to write such functions as

> Definition mapM_def:
    mapM f [] = return [] ∧
    mapM f (x::xs) = do
       e  <- f x;
       es <- mapM f xs;
       return (e::es);
     od
  End
<<HOL message: inventing new type variable names: 'a, 'b>>
Definition has been stored under "mapM_def"
val mapM_def =
   ⊢ (∀f. mapM f [] = [[]]) ∧
     ∀f x xs. mapM f (x::xs) = do e <- f x; es <- mapM f xs; [e::es] od: thm

> type_of “mapM”;
<<HOL message: inventing new type variable names: 'a, 'b>>
val it = “:(α -> β list) -> α list -> β list list”: hol_type

Again, because HOL does not have a sufficiently expressive type system, though the notation is generic, the function is fixed to a particular monad instance. In this case, the monad instance is that of lists. We can use the mapM function to implement what one might term a cross-product operation on lists:

> EVAL “mapM I [[1;2;3]; [a;b]; [x;y;z]]”;
val it =
   ⊢ mapM I [[1; 2; 3]; [a; b]; [x; y; z]] =
     [[1; a; x]; [1; a; y]; [1; a; z]; [1; b; x]; [1; b; y]; [1; b; z];
      [2; a; x]; [2; a; y]; [2; a; z]; [2; b; x]; [2; b; y]; [2; b; z];
      [3; a; x]; [3; a; y]; [3; a; z]; [3; b; x]; [3; b; y]; [3; b; z]]: thm

The general abstract syntax is described by the following grammar

$$ \begin{array}{rcl} M &::=& e_{\alpha\,\mathtt{M}} \;\;\mid\;\; \mathtt{do}\;\,\mathit{binds}\,\;\mathtt{od} \;\;\mid\;\; \mathtt{return}\;e_\alpha\\ \mathit{binds} &::=& \mathit{bind}\;\mathtt{;}^? \;\;\mid\;\; \mathit{bind}\,\mathtt{;}\,\;\mathit{binds}\\ \mathit{bind} &::=& M \;\;\mid\;\; \mathit{vs}\;\,\mathtt{<-}\;M \;\;\mid\;\; \mathit{vs}\;\,\mathtt{<<-}\;e_\alpha \end{array} $$

where $\mathit{e}_\tau$ is a HOL expression required to be of type $\tau$, and $\mathit{vs}$ is a single variable, or a tuple of variables (e.g., (x,y,z)). If a given $M$ has type :$\alpha$ M for a monad instance M, then writing a binding such as v <- M will require variable $v$ to have type $\alpha$. This variable is then bound in later bindings within the same do-od block. One can also bind variables directly to expressions of the appropriate type with the <<- arrow. This corresponds to an underlying let-term, but equally, one can see v <<- e as semantically equivalent to v <- return e.

The special monad syntax has a straightforward translation into underlying HOL terms. The do-od delimiters have no semantic effect; they can be viewed as a special form of parenthesis that identifies where the binding syntax is going to be used.¹⁶ Subsequently, the translation from $\mathit{vs}\;\mathtt{<-}\,M_1\mathtt{;}\;M_2$ is to $\mathtt{monad\_bind}\;M_1\;(\lambda\mathit{vs}.\,M_2)$, making it clear that $\mathit{vs}$ can be used (and is bound) in $M_2$. If there is no variable-arrow on the first binding, then $M_1\mathtt{;}\;M_2$ translates to something equivalent to $\mathtt{monad\_bind}\;M_1\;(\mathtt{K}\;M_2)$, where K is the K-combinator from combinTheory (see Section 5.2.2). As already suggested, $\mathit{vs}\;\mathtt{<<-}\;e\mathtt{;}\;M$ translates to $\mathtt{let}\;\mathit{vs}\;\mathtt{=}\;e\;\mathtt{in}\;M$. Finally, the return keyword is an overloading for the monad instance's unit function (which will have type $\alpha\to\alpha\,\mathtt{M}$).

Declaring monads

Monad instances have to be declared if the system is to support their parsing and pretty-printing. The function responsible is declare_monad in the monadsyntax module.

type monadinfo =
   \{bind: term,
     choice: term option,
     fail: term option,
     guard: term option, ignorebind: term option, unit: term\}
val declare_monad = fn: string * monadsyntax.monadinfo -> unit

The terms for the bind and unit fields are the terms implementing the corresponding monad functions. For example, the bind function for the option function is OPTION_BIND, characterised by its defining theorem:

OPTION_BIND_def
  ⊢ (∀f. OPTION_BIND NONE f = NONE) ∧ ∀x f. OPTION_BIND (SOME x) f = f x

The unit function is just the SOME constructor for the type.

All of the other fields in the monadinfo record can be left unspecified. The ignorebind field is used to encode the situation where the user writes

   do m1; m2 od

meaning that though m1 may return a value, the remainder of the function does not use that value. As above, this can be handled through the use of the K combinator, which is what is done if the ignorebind field is set to NONE. However, if desired, one can specify a specific term to be used in this situation. For example, the system's encoding of the option monad uses a separate constant with exactly the definition one would expect:

OPTION_IGNORE_BIND_def
  ⊢ ∀m1 m2. OPTION_IGNORE_BIND m1 m2 = OPTION_BIND m1 (K m2)

The three remaining fields (guard, fail and choice) are relevant for monads with errors or failure modes. The underlying property is that if $m_1$ is an error value, then $\mathtt{monad\_bind}\;m_1\;f \;\;=\;\; m_1$, meaning that attempting to sequence computations after an error just causes the error to be the result, without any use of the $f$ value. In this way, one might see $m_1$ as a computation that has thrown some sort of exception.

If one specifies a fail term in declaring a monad, an overload is set up from the string fail to that term. This is flexible enough to allow parameterised errors: make the term be the function that takes a parameter and returns a monad error value. There is no monad-specific support required for this concept: the overload is sufficient.

When provided, the guard and choice terms are similarly established as overloads so that monadic code across different monads will look similar. If one views fail as throwing an exception, then the choice notation allows for catching an exception and trying another computation. The overload is to the infix ++ syntax, meaning that one can write $M_1\;\mathtt{++}\;M_2$ to represent the “choice” between $M_1$ and $M_2$. (Note that in the list monad, ++ is APPEND. This explains the choice of notation, though in the list monad, viewing “choice” as throwing and catching exceptions is actually harder to motivate.)

Finally, the guard term (if given) overloads to the term assert, which is expected to be defined such that

$$ \mathtt{assert}\;b\;\; = \;\;\textsf{if}\;b\;\textsf{then}\;\mathtt{return}\;()\;\textsf{else}\;\mathtt{fail} $$

A typical use of assert might be in a function such as

  do
     list <- some_monad;
     assert(list <> []);
     return (HD list + 1)
  od

where the assert ensures that the subsequent call to HD makes sense.

Enabling monad syntax

There are two steps to being able to use monadic syntax. Both steps persist, meaning that their effects are preserved for the benefit of descendant theories. Because of this persistence, the function calls implementing these two steps should only be used in xScript.sml files. As with other parsing and pretty-printing functions, there are temp_ versions of the functions. These do not cause persistence and can safely be used in other .sml files (such as library implementations).

The first step is to enable the generic monad syntax, by calling

   monadsyntax.enable_monadsyntax : unit -> unit

After this, one can write do…od blocks, even though without any specific instances enabled the output will be unhelpful (the monad_bind printed in the session below is actually a variable):

> monadsyntax.enable_monadsyntax();
val it = (): unit
> “do x <- M1; M2 od”;
<<HOL message: inventing new type variable names: 'a, 'b, 'c, 'd>>
val it = “monad_bind M1 (λx. M2)”: term

One can see which monads have been declared with a call to all_monads:

> monadsyntax.all_monads()
val it =
   [("list",
     {bind = “LIST_BIND”, choice = SOME (“APPEND”), fail = SOME (“[]”),
      guard = SOME (“LIST_GUARD”), ignorebind = SOME (“LIST_IGNORE_BIND”),
      unit = “λx. [x]”}),
    ("option",
     {bind = “OPTION_BIND”, choice = SOME (“OPTION_CHOICE”), fail =
      SOME (“NONE”), guard = SOME (“OPTION_GUARD”), ignorebind =
      SOME (“OPTION_IGNORE_BIND”), unit = “SOME”})]:
   (string * monadsyntax.monadinfo) list

Particular monads can be enabled with calls to enable_monad. The most recently enabled is preferred when the context makes the choice ambiguous.

> List.app monadsyntax.enable_monad ["list", "option"];
val it = (): unit

> val t = “do x <- M; return (x + 1) od”;
<<HOL message: more than one resolution of overloading was possible>>
val t = “do x <- M; SOME (x + 1) od”: term
> type_of t;
val it = “:num option”: hol_type

> val t' = “do x <- MAP f l; return (x + 1); od”;
<<HOL message: inventing new type variable names: 'a>>
val t' = “do x <- MAP f l; [x + 1] od”: term
> type_of t';
val it = “:num list”: hol_type

Thanks to the persistence features of these API points, loading fresh theories may cause more monads to be declared and/or enabled:

> load "errorStateMonadTheory";
val it = (): unit
> monadsyntax.all_monads();
val it =
   [("errorState",
     {bind = “BIND”, choice = SOME (“ES_CHOICE”), fail = SOME (“ES_FAIL”),
      guard = SOME (“ES_GUARD”), ignorebind = SOME (“IGNORE_BIND”), unit =
      “UNIT”}),
    ("list",
     {bind = “monad_bind”, choice = SOME (“$++”), fail = SOME (“[]”), guard =
      SOME (“assert”), ignorebind = SOME (“monad_unitbind”), unit =
      “λx. [x]”}),
    ("option",
     {bind = “monad_bind”, choice = SOME (“$++”), fail = SOME (“NONE”),
      guard = SOME (“assert”), ignorebind = SOME (“monad_unitbind”), unit =
      “SOME”})]: (string * monadsyntax.monadinfo) list

Everything that has been enabled can in turn be disabled, with calls drawn from:

     disable_monad            : string -> unit
     temp_disable_monad       : string -> unit

     disable_monadsyntax      : unit -> unit
     temp_disable_monadsyntax : unit -> unit

Some built-in monad theories

See Figure 5.7.3 for the bind definitions for a number of different monads that are present in the core HOL set of theories.

errorStateMonadTheory.BIND_DEF
  ⊢ ∀g f s0.
       errorStateMonad$BIND g f s0 =
       case g s0 of NONE => NONE | SOME (b,s) => f b s

listTheory.LIST_BIND_THM
  ⊢ LIST_BIND [] f = [] ∧
     LIST_BIND (h::t) f = APPEND (f h) (LIST_BIND t f)

optionTheory.OPTION_BIND_def
  ⊢ (∀f. OPTION_BIND NONE f = NONE) ∧
     ∀x f. OPTION_BIND (SOME x) f = f x

readerMonadTheory.BIND_def
  ⊢ ∀M f s. readerMonad$BIND M f s = f (M s) s

state_transformerTheory.BIND_DEF
  ⊢ ∀g f. state_transformer$BIND g f = UNCURRY f ∘ g

Other Theories

Other theories of interest in HOL are listed and briefly described in the table below.

1. To simplify the porting of the LCF theorem-proving tools to the HOL system, the HOL logic was made as like PP$\lambda$ (the logic built-in to LCF) as possible. ↩

2. Constants declared in new theories can freely re-use these names, with ambiguous inputs resolved by type inference. ↩

3. This theorem has an un-reduced $\beta$-redex in order to meet the interface required by the type definition principle. ↩

4. The definition of disjoint unions in the HOL system is due to Tom Melham. The technical details of this definition can be found in (Melham 1989). ↩

5. When using the parenthesis-version, the one value's syntax consists of two parenthesis tokens, so that one can write the value with white-space between the parentheses if desired. ↩

6. In higher order logic, primitive recursion is much more powerful than in first order logic; for example, Ackermann's function can be defined by primitive recursion in higher order logic. ↩

7. A set of numbers is downward closed if whenever it contains the successor of a number, it also contains the number. ↩

8. Note that, unlike the case of real numbers in HOL, $0/0 = 0$ (or “division by zero” in general) does not hold on extreals. This particular design choice sometimes makes proofs of extreal-related theorems a bit harder (but more aligned with their textbook proofs), as whenever terms like inv x or 1 / x are involved, x <> 0 must be proved to proceed. ↩

9. The current theory subsumes previous word theories — it evolved from a development based on an equivalence class construction. Wai Wong's word theory, which was based on Paul Curzon's rich_list theory, is no longer distributed with HOL. The principle advantages of the current theory are that there is just one theory for all word sizes and that word length side conditions are not required. ↩

10. The theory of finite Cartesian products was ported from HOL Light. ↩

11. Note that FCP indices in HOL Light are ranged from 1 to dimindex('b), while in HOL4 they are ranged from 0 to dimindex('b) - 1, thus is less than the size of 'b. Also note that the function fcp_index in HOL Light is specified for index values: f ' i = 0 when i = 0 or i > dimindex('b). In HOL4, however, f ' i is unspecified when i >= dimindex('b). ↩

12. Note that it is impossible to introduce words of length zero because all types must be inhabited, and hence their size will always be greater than or equal to one. ↩

13. Words are not tagged as being signed/unsigned. Mappings to/from the integers (w2i and i2w) are provided in the theory integer_word. ↩

14. Starting with the original definition it is not that easy to derive the coinduction principle, which is very useful in practice. ↩

15. The original idea is due to J Moore, who suggested it for use in ACL2. ↩

16. Indeed, writing do M od for a single binding form $M$ will see the system print back $M$ on its own. ↩

Core Theories — Higher Mathematics

Ordinals and Cardinals in HOL

HOL provides the theory of ordinals and cardinals in wellorderTheory, cardinalTheory, and ordinalTheory, etc. (Norrish and Huffman 2013). Unfortunately, the typed logic implemented in the various HOL systems (including Isabelle/HOL) is not strong enough to define a type for all possible ordinal values. It turns out, however, that for any fixed $n \in \mathbb{N}$, we can model all ordinals of cardinality $\aleph_n$. The user is thus able to choose an ordinal domain of sufficient size for their purposes.

Ordinals in HOL

The ordinals are an extension of the natural numbers¹. The idea is to add new “numbers” after the naturals. For example, if we add $\omega$, we get $0$, $1$, $2$, $\ldots$, $\omega$, where $0 < 1 < 2 < \cdots < \omega$. Notice that this new set extends the naturals and is countable. In addition, under this ordering it has a biggest element $\omega$, is linearly ordered, and well-founded. The ordinals are what you get if you keep adding elements. The first few ordinals are: $0$, $1$, $\ldots$, $\omega$, $\omega + 1$, $\ldots$, $\omega\times 2$. Notice that (the ordinals less than) $\omega\times 2$ is what you get if you put two copies of (the ordinals less than) $\omega$ next to each other, i.e., $0, 1, \ldots, 0, 1, \ldots$ (and then rename the elements in the second copy). Continuing to add “numbers”, we get $\omega$, $\omega\times 2$, $\omega\times 3$, $\ldots$, $\omega^2$. Now we have introduced ordinal exponentiation. Note that $\omega^2$ is what you get if you put $\omega$ copies of $\omega$, one after the other (and rename elements). We will pick up where we left off, but will now start extending the ordinals at a faster rate: $\omega^2$, $\omega^2+1$, $\ldots$, $\omega^2+\omega$, $\omega^2+\omega+1$, $\ldots$, $\omega^2+(\omega\times 2)$, $\omega^2+(\omega\times 2)+1$, $\ldots$, $\omega^2+(\omega\times 3)$, $\ldots$, $\omega^2+(\omega\times 4)$, $\ldots$, $\omega^2\times 2$, $\ldots$, $\omega^2\times 3$, $\ldots$, $\omega^3$, $\omega^4$, $\ldots$, $\omega^\omega$, $\ldots$, $\omega^{(\omega^\omega)}$, $\ldots$, $\omega^{(\omega^{(\omega^\omega)})}$, $\ldots$, $\epsilon_0$. The set of ordinals less than $\epsilon_0$ remain countable. The first ordinal with uncountably many predecessors is called $\omega_1$.

omega1_def
  ⊢ ω₁ = sup {a | countableOrd a}
x_lt_omega1_countable
  ⊢ x < ω₁ ⇔ countableOrd x

Cardinals in HOL

In mathematics, a cardinal number, or cardinal for short, is what is commonly called the number of elements of a set. In the case of a finite set $s$, its cardinal number, or cardinality is therefore a natural number, say $n$. Within pred_setTheory (Section 5.5.1), this is denoted by either by CARD s = n, or by s HAS_SIZE n. For dealing with the case of infinite sets, the infinite cardinal numbers have been introduced, which are often denoted with the Hebrew letter $\aleph$ marked with subscript indicating their rank among the infinite cardinals.

Currently HOL does not have cardinal arithmetic, such as those (Blanchette, Popescu, and Traytel 2014) available in Isabelle/HOL. Nevertheless, it is possible to compare the cardinalities of any two infinite sets. Cardinality is defined in terms of bijective functions:

cardleq_def
  ⊢ ∀s1 s2. s1 ≼ s2 ⇔ ∃f. INJ f s1 s2

Topology of One-Dimensional Euclidean Space

The theory real_topology provides some deeper analytical properties for real numbers and real sets (one-dimensional Euclidean space). It was ported from HOL Light by Muhammad Qasim and Osman Hasan et al. In particular, real_topology contains more general and advanced concepts and theorems than those provided by lim and seq (Section 5.3.6).

There are more than 60 concepts and 1600 theorems in real_topology, including properties of continuous functions and the completeness of real numbers, which is the foundation of other higher mathematics theories, such as differential and integral calculus, measure and probability theories. For instance, the following version of the Heine-Borel theorem (and the fact that a real set is compact iff it is bounded and closed) plays an essential role in the construction of Borel-measurable spaces in measure theory:

COMPACT_EQ_HEINE_BOREL
  ⊢ ∀s. compact s ⇔
         ∀f. (∀t. t ∈ f ⇒ open t) ∧ s ⊆ BIGUNION f ⇒
             ∃f'. f' ⊆ f ∧ FINITE f' ∧ s ⊆ BIGUNION f'

COMPACT_EQ_BOUNDED_CLOSED
  ⊢ ∀s. compact s ⇔ bounded s ∧ closed s

The concept of open (and closed) sets is fundamental and is needed, for example, in the definition of Borel sets (see Section 6.4.1):

open_def
  ⊢ ∀s. open s ⇔
         ∀x. x ∈ s ⇒ ∃e. 0 < e ∧ ∀x'. dist (x',x) < e ⇒ x' ∈ s

closed_def
  ⊢ ∀s. closed s ⇔ open (𝕌(:real) DIFF s)

Univariate Differential and Integral Calculus

HOL offers two groups of theories for univariate differential and integral calculus. The old one consists of limTheory (limits of functions, differentiation and continuity) and integralTheory (integration), while the new one consists of derivativeTheory and integrationTheory with fundamental concepts from real_topologyTheory. Both groups of theories were originally developed by John Harrison².

These two group of theories are now compatible by having some bridging theorems showing the equivalences between their key concepts. The old theories align more tightly to conventional textbooks, while the new theories usually offer some extra functionalities. HOL users can use both of them within the same proof scripts. The rest of this section briefly introduce some important concepts and theorems, focusing on the bridges between old and new theories³.

Derivative

A quintessentially analytic property is the derivative of a (real-valued) function. The concept of derivative is first suggested by the intuitive notion of the tangent to a smooth curve $y = f(x)$ at a point $P$ with the coordinates $x$ and $y$. See Figure 6.3.1 for an illustration of this differentiation process. Mathematically, one shall generally use either the notation of Lagrange, $y' = f'(x)$, to denote the derivative, or, as Leibnitz did, the symbol $dy/dx$ or $df(x)/dx$. The notation $f'(x)$ indicates the fact that the derivative is itself a function of $x$ since a value of $f'(x)$ corresponds to each value of $x$ (in the interval considered). The definition of the derivative appears in several different forms, one of the following:

$$f'(x) = \lim_{h\rightarrow 0}\frac{f(x+h) - f(x)}{h}$$

One might expect to find a higher-order ‘derivative’ function deriv $\colon (\mathbb{R}\rightarrow\mathbb{R})\rightarrow(\mathbb{R}\rightarrow\mathbb{R})$ mapping a function $f$ to its derivative $f'$. Actually, no such thing is defined in HOL, but rather a ternary operator diffl (defined in limTheory) where (f diffl l) x means 'the function $f$ has a derivative with value $l$ at the point $x$'. Expanding out the definition, we see that the definition is much as an analyst might expect:

diffl
  ⊢ ∀f l x. (f diffl l) x ⇔ ((λh. (f (x + h) − f x) / h) -> l) 0

(f has_derivative f') (at x) means 'the function $f$ has a derivative $f'$ at the point $x$', or (f has_derivative f') (at x within s) means 'the function $f$ has a derivative $f'$ at the point $x$ within the set $s$'. Expanding out the definition, we see that the definition is much as an analyst might expect: (cf. Figure 6.3.1 for an illustration of this differentiation process.)

HAS_DERIVATIVE_AT
  ⊢ ∀f f' x.
       (f has_derivative f') (at x) ⇔
       linear f' ∧
       ∀e. 0 < e ⇒
           ∃d. 0 < d ∧
               ∀x'.
                 0 < abs (x' − x) ∧ abs (x' − x) < d ⇒
                 abs (f x' − f x − f' (x' − x)) / abs (x' − x) < e

has_vector_derivative
  ⊢ ∀f f' net.
       (f has_vector_derivative f') net ⇔ (f has_derivative (λx. x * f')) net

Similarly, (f has_vector_derivative f') (at x) means that the function $f$ has a derivative with value $f'$ at the point $x$. The usual kinds of combining theorems are proved. For example, the derivative of a sum of two functions is the sum of their derivatives:

DIFF_ADD
  ⊢ ∀f g l m x.
       (f diffl l) x ∧ (g diffl m) x ⇒ ((λx. f x + g x) diffl (l + m)) x

HAS_DERIVATIVE_ADD
  ⊢ ∀f f' g g' net.
       (f has_derivative f') net ∧ (g has_derivative g') net ⇒
       ((λx. f x + g x) has_derivative (λh. f' h + g' h)) net

DIFF_MUL
  ⊢ ∀f g l m x.
       (f diffl l) x ∧ (g diffl m) x ⇒
       ((λx. f x * g x) diffl (l * g x + m * f x)) x

HAS_DERIVATIVE_MUL_AT
  ⊢ ∀f f' g g' a.
       (f has_derivative f') (at a) ∧ (g has_derivative g') (at a) ⇒
       ((λx. f x * g x) has_derivative (λh. f a * g' h + f' h * g a)) (at a)

DIFF_DIV
  ⊢ ∀f g l m x.
       (f diffl l) x ∧ (g diffl m) x ∧ g x ≠ 0 ⇒
       ((λx. f x / g x) diffl ((l * g x − m * f x) / (g x)²)) x

DIFF_CHAIN
  ⊢ ∀f g l m x.
       (f diffl l) (g x) ∧ (g diffl m) x ⇒ ((λx. f (g x)) diffl (l * m)) x

limTheory.MVT
  ⊢ ∀f a b.
       a < b ∧ (∀x. a ≤ x ∧ x ≤ b ⇒ f contl x) ∧
       (∀x. a < x ∧ x < b ⇒ f differentiable x) ⇒
       ∃l z. a < z ∧ z < b ∧ (f diffl l) z ∧ f b − f a = (b − a) * l

derivativeTheory.MVT
  ⊢ ∀f f' a b.
       a < b ∧ f continuous_on interval [(a,b)] ∧
       (∀x. x ∈ interval (a,b) ⇒ (f has_derivative f' x) (at x)) ⇒
       ∃x. x ∈ interval (a,b) ∧ f b − f a = f' x (b − a)

diffl_has_vector_derivative
  ⊢ ∀f l x. (f diffl l) x ⇔ (f has_vector_derivative l) (at x)

A function is differentiable at certain point if it has derivative at that point.

The continuity of a function is very close with its differentiability. The HOL formalization of "$f$ is (right-)continuous at the point $x$" is f contl x with contl ('locally continuous' from limTheory), or f continuous (at x) from real_topologyTheory, both are infix binary operators. The two operators are equivalent (when continuous is used with the at net) by the following bridging theorem:

contl_eq_continuous_at
  ⊢ ∀f x. f contl x ⇔ f continuous at x

However, using continuous it is also possible to express continuity of a function at a point within a set of points (usually an interval), i.e. f continuous (at x within s).

The global version of continuous for a set of points (usually an open or closed interval) is called continuous_on.⁴

continuous_on
  ⊢ ∀f s.
       f continuous_on s ⇔
       ∀x. x ∈ s ⇒
           ∀e. 0 < e ⇒
               ∃d. 0 < d ∧
                   ∀x'. x' ∈ s ∧ dist (x',x) < d ⇒ dist (f x',f x) < e

CONTINUOUS_ON_EQ_CONTINUOUS_AT
  ⊢ ∀f s. open s ⇒ (f continuous_on s ⇔ ∀x. x ∈ s ⇒ f continuous at x)

CONTINUOUS_ON_EQ_CONTINUOUS_WITHIN
  ⊢ ∀f s. f continuous_on s ⇔ ∀x. x ∈ s ⇒ f continuous (at x within s)

One of the most fundamental facts about continuous functions is the intermediate value property (IVT): if a function takes two values then it also somewhere takes any value in between. The HOL formulation is that if $f$ is continuous at all points of an interval $[a,b]$, and $f(a)\leqslant y\leqslant f(b)$ then there is some point $x$ in the interval where $f(x) = y$:

IVT
  ⊢ ∀f a b y.
       a ≤ b ∧ (f a ≤ y ∧ y ≤ f b) ∧ (∀x. a ≤ x ∧ x ≤ b ⇒ f contl x) ⇒
       ∃x. a ≤ x ∧ x ≤ b ∧ f x = y

CONTINUOUS_ON_IVT
  ⊢ ∀f a b y.
       a ≤ b ∧ f a ≤ y ∧ y ≤ f b ∧ f continuous_on interval [(a,b)] ⇒
       ∃x. x ∈ interval [(a,b)] ∧ f x = y

IVT2
  ⊢ ∀f a b y.
       a ≤ b ∧ (f b ≤ y ∧ y ≤ f a) ∧ (∀x. a ≤ x ∧ x ≤ b ⇒ f contl x) ⇒
       ∃x. a ≤ x ∧ x ≤ b ∧ f x = y

Integration

The version of integral calculus formalized in HOL is a generalized Riemann integration called Henstock-Kurzweil Integration, or gauge integration (Bartle 2001). Many functions which are not Riemann integrable can be shown to be Henstock-Kurzweil integrable. (In particular, a function is Lebesgue integrable if and only if the function and its absolute value are Henstock-Kurzweil integrable.)

f integrable_on s means that the function $f$ is integrable on a real set $s$ (there is another similar concept called absolute integrability: f absolutely_integrable_on s.) If $f$ is integrable on a closed interval $[a,b]$, then the usual integration of $f$ on $[a,b]$, i.e. $\displaystyle\int_a^b f \,\mathrm{d}x$, is denoted by integral (interval [a,b]) f in HOL. In general, the integration of $f$ on a set $s$ of real numbers is integral s f.

gauge
  ⊢ ∀E g. gauge E g ⇔ ∀x. E x ⇒ 0 < g x

fine
  ⊢ ∀g D p. fine g (D,p) ⇔ ∀n. n < dsize D ⇒ D (SUC n) − D n < g (p n)

tdiv
  ⊢ ∀a b D p.
       tdiv (a,b) (D,p) ⇔ division (a,b) D ∧ ∀n. D n ≤ p n ∧ p n ≤ D (SUC n)

division
  ⊢ ∀a b D.
       division (a,b) D ⇔
       D 0 = a ∧ ∃N. (∀n. n < N ⇒ D n < D (SUC n)) ∧ ∀n. n ≥ N ⇒ D n = b

Dint
  ⊢ ∀a b f k.
       Dint (a,b) f k ⇔
       ∀e. 0 < e ⇒
           ∃g. gauge (λx. a ≤ x ∧ x ≤ b) g ∧
               ∀D p.
                 tdiv (a,b) (D,p) ∧ fine g (D,p) ⇒ abs (rsum (D,p) f − k) < e

integral
  ⊢ ∀a b f. integral (a,b) f = @i. Dint (a,b) f i

In integration, ported from HOL Light, a more general form of Henstock-Kurzweil integration has been defined:

gauge_def
  ⊢ ∀d. gauge d ⇔ ∀x. x ∈ d x ∧ open (d x)

FINE
  ⊢ ∀d s. d FINE s ⇔ ∀x k. (x,k) ∈ s ⇒ k ⊆ d x

tagged_partial_division_of
  ⊢ ∀s i.
       s tagged_partial_division_of i ⇔
       FINITE s ∧
       (∀x k. (x,k) ∈ s ⇒ x ∈ k ∧ k ⊆ i ∧ ∃a b. k = interval [(a,b)]) ∧
       ∀x1 k1 x2 k2.
         (x1,k1) ∈ s ∧ (x2,k2) ∈ s ∧ (x1,k1) ≠ (x2,k2) ⇒
         interior k1 ∩ interior k2 = ∅

tagged_division_of
  ⊢ ∀s i.
       s tagged_division_of i ⇔
       s tagged_partial_division_of i ∧ BIGUNION {k | (∃x. (x,k) ∈ s)} = i

has_integral_compact_interval
  ⊢ ∀f y i.
       (f has_integral_compact_interval y) i ⇔
       ∀e. 0 < e ⇒
           ∃d. gauge d ∧
               ∀p. p tagged_division_of i ∧ d FINE p ⇒
                   abs (sum p (λ(x,k). content k * f x) − y) < e

has_integral_def
  ⊢ ∀f y i.
       (f has_integral y) i ⇔
       if ∃a b. i = interval [(a,b)] then
         (f has_integral_compact_interval y) i
       else
         ∀e. 0 < e ⇒
             ∃B. 0 < B ∧
                 ∀a b.
                   ball (0,B) ⊆ interval [(a,b)] ⇒
                   ∃z. ((λx. if x ∈ i then f x else 0) has_integral_compact_interval
                        z) (interval [(a,b)]) ∧ abs (z − y) < e

integral_def
  ⊢ ∀i f. integral i f = @y. (f has_integral y) i

The fundamental theorem of calculus (in the equivalent forms of Riemann integral) is expressed below:

FTC1
  ⊢ ∀f f' a b.
       a ≤ b ∧ (∀x. a ≤ x ∧ x ≤ b ⇒ (f diffl f' x) x) ⇒
       Dint (a,b) f' (f b − f a)

FUNDAMENTAL_THEOREM_OF_CALCULUS
  ⊢ ∀f f' a b.
       a ≤ b ∧
       (∀x. x ∈ interval [(a,b)] ⇒
            (f has_vector_derivative f' x) (at x within interval [(a,b)])) ⇒
       (f' has_integral f b − f a) (interval [(a,b)])

The above theorem requires that the function $f$ must be everywhere differentiable (i.e., has derivative) in the closed interval $[a,b]$. In fact, Henstock-Kurzweil Integration permits a countable number of exceptional points. This yields a significant improvement, as shown in the following strong version of the fundamental theorem of calculus:

FUNDAMENTAL_THEOREM_OF_CALCULUS_STRONG
  ⊢ ∀f f' s a b.
       countable s ∧ a ≤ b ∧ f continuous_on interval [(a,b)] ∧
       (∀x. x ∈ interval [(a,b)] DIFF s ⇒
            (f has_vector_derivative f' x) (at x within interval [(a,b)])) ⇒
       (f' has_integral f b − f a) (interval [(a,b)])

Finally, the following two bridging theorems can be used to convert between integrals of the integral and integration theories:

integral_old_to_new
  ⊢ ∀f a b.
       a ≤ b ∧ integrable (a,b) f ⇒
       integral (a,b) f = integral (interval [(a,b)]) f

integral_new_to_old
  ⊢ ∀f a b.
       a ≤ b ∧ f integrable_on interval [(a,b)] ⇒
       integral (interval [(a,b)]) f = integral (a,b) f

Measure Theory

The theme of measure theory implemented in sigma_algebra and measure theories is the problem of how to assign a size, a content, a probability, etc. to certain sets. The most common examples of measure is the length (in one dimension), area (in two dimensions) and volume (in three dimensions) in Euclidean spaces. In HOL's measure theory, a measure is a set function of the type $(\alpha \to \konst{bool}) \to \konst{extreal}$.⁵ (See Section 5.3.7 for more details of extended real numbers.) This allows us to express, for example, the “length” of the entire real line $\mathbb{R}$, i.e. PosInf.

A reasonable measure should be able to deal with disjoint countable partitions of sets. Therefore a measure function must be defined on a system of sets which is stable whenever we repeat any of the basic set operations -- $\cup$, $\cap$, ${}^{\mathrm{c}}$ -- countably many times, i.e. $\sigma$-algebra. In HOL, a system of sets is a pair (sp,sts) of the type $(\alpha \to \konst{bool}) \,\#\, ((\alpha \to \konst{bool}) \to \konst{bool})$ satisfying subset_class sp sts:

subset_class_def
  ⊢ ∀sp sts. subset_class sp sts ⇔ ∀x. x ∈ sts ⇒ x ⊆ sp

Given any system of sets a = (sp,sts), the two functions space and subsets can be used to access sp and sts, respectively.

Then algebra and $\sigma$-algebra⁶ are defined below:

algebra_def
  ⊢ ∀a. algebra a ⇔
         subset_class (space a) (subsets a) ∧ ∅ ∈ subsets a ∧
         (∀s. s ∈ subsets a ⇒ space a DIFF s ∈ subsets a) ∧
         ∀s t. s ∈ subsets a ∧ t ∈ subsets a ⇒ s ∪ t ∈ subsets a

sigma_algebra_def
  ⊢ ∀a. sigma_algebra a ⇔
         algebra a ∧ ∀c. countable c ∧ c ⊆ subsets a ⇒ BIGUNION c ∈ subsets a

There are several equivalent ways of defining $\sigma$-algebra. The following alternative definition (as a theorem), for instance, perfectly matches Definition 3.1 of (Schilling 2017):

SIGMA_ALGEBRA_ALT_SPACE
  ⊢ ∀a. sigma_algebra a ⇔
         subset_class (space a) (subsets a) ∧ space a ∈ subsets a ∧
         (∀s. s ∈ subsets a ⇒ space a DIFF s ∈ subsets a) ∧
         ∀f. f ∈ (𝕌(:num) → subsets a) ⇒
             BIGUNION (IMAGE f 𝕌(:num)) ∈ subsets a

Any measure (function) must be defined with respect to a measure space. In HOL, a measure space is represented by a tuple (sp,sts,mu), where sp and sts forms a $\sigma$-algebra⁷, and mu is the measure function. If m = (sp,sts,mu) is a measure space, the functions m_space, measurable_sets and measure can be used to access sp, sts and mu, respectively. Any measure space must be both positive and countably_additive:

measure_space_def
  ⊢ ∀m. measure_space m ⇔
         sigma_algebra (measurable_space m) ∧ positive m ∧
         countably_additive m

positive_def
  ⊢ ∀m. positive m ⇔
         measure m ∅ = 0 ∧ ∀s. s ∈ measurable_sets m ⇒ 0 ≤ measure m s

countably_additive_def
  ⊢ ∀m. countably_additive m ⇔
         ∀f. f ∈ (𝕌(:num) → measurable_sets m) ∧
             (∀i j. i ≠ j ⇒ DISJOINT (f i) (f j)) ∧
             BIGUNION (IMAGE f 𝕌(:num)) ∈ measurable_sets m ⇒
             measure m (BIGUNION (IMAGE f 𝕌(:num))) = suminf (measure m ∘ f)

In particular, if (sp,sts,mu) is positive and countably_additive but (sp,sts) is not (yet) a $\sigma$-algebra, it is called a premeasure (space):

premeasure_def
  ⊢ ∀m. premeasure m ⇔ positive m ∧ countably_additive m

The reason of introducing premeasure is that it is not a trivial task to assign explicitly a value to every set from a $\sigma$-algebra. Rather than doing this it is often more natural to assign values to sets from some generators. To get such an automatic extension the following (technically motivated) class of generators is useful. A semiring (usually denoted by $\mathscr{S}$) is a family with the following properties:

sigma_algebraTheory.semiring_def
  ⊢ ∀r. semiring r ⇔
         subset_class (space r) (subsets r) ∧ ∅ ∈ subsets r ∧
         (∀s t. s ∈ subsets r ∧ t ∈ subsets r ⇒ s ∩ t ∈ subsets r) ∧
         ∀s t.
           s ∈ subsets r ∧ t ∈ subsets r ⇒
           ∃c. c ⊆ subsets r ∧ FINITE c ∧ disjoint c ∧ s DIFF t = BIGUNION c

Any ($\sigma$-)algebra is also a semiring but not vice versa. For instance, the set of all right open intervals $\big\{ [a,b) \colon a,b\in\mathbb{R} \big\}$ is a semiring (because the set difference of any two right open intervals is at most two new right open intervals). Furthermore, for any system of sets (sp sts) there exists a smallest $\sigma$-algebra containing it (also called the $\sigma$-algebra generated from it), denoted by $\sigma(\cdot)$:

sigma_def
  ⊢ ∀sp sts.
       sigma sp sts = (sp,BIGINTER {s | sts ⊆ s ∧ sigma_algebra (sp,s)})

SIGMA_ALGEBRA_SIGMA
  ⊢ ∀sp sts. subset_class sp sts ⇒ sigma_algebra (sigma sp sts)

SIGMA_SUBSET_SUBSETS
  ⊢ ∀sp a. a ⊆ subsets (sigma sp a)

The following deep extension theorem for measures goes back to Carathéodory (Schilling 2017):

CARATHEODORY_SEMIRING
  ⊢ ∀m0.
       semiring (measurable_space m0) ∧ premeasure m0 ⇒
       ∃m. (∀s. s ∈ measurable_sets m0 ⇒ measure m s = measure m0 s) ∧
           measurable_space m = sigma (m_space m0) (measurable_sets m0) ∧
           measure_space m

In addition, the uniqueness of measures extended from generators is guaranteed by the following theorem, given that the involved generators are stable under $\cap$ and $\sigma$-finite:

sigma_finite_def
  ⊢ ∀m. sigma_finite m ⇔
         ∃f. f ∈ (𝕌(:num) → measurable_sets m) ∧ (∀n. f n ⊆ f (SUC n)) ∧
             BIGUNION (IMAGE f 𝕌(:num)) = m_space m ∧
             ∀n. measure m (f n) < +∞

sigma_finite_measure_space_def
  ⊢ ∀m. sigma_finite_measure_space m ⇔ measure_space m ∧ sigma_finite m

UNIQUENESS_OF_MEASURE
  ⊢ ∀sp sts u v.
       subset_class sp sts ∧ (∀s t. s ∈ sts ∧ t ∈ sts ⇒ s ∩ t ∈ sts) ∧
       sigma_finite (sp,sts,u) ∧
       measure_space (sp,subsets (sigma sp sts),u) ∧
       measure_space (sp,subsets (sigma sp sts),v) ∧
       (∀s. s ∈ sts ⇒ u s = v s) ⇒
       ∀s. s ∈ subsets (sigma sp sts) ⇒ u s = v s

Borel measurable function and sets

The theory real_borel provides Borel sets and Borel measurable functions based on reals, in addition the theory borel provides the same things based on extreals, plus the constructions of Borel and Lebesgue measure spaces.

In HOL, the real-valued Borel sets borel $\mathscr{B}(\mathbb{R})$ is the $\sigma$-algebra generated by open sets (of the type $\konst{real} \to \konst{bool}$).

borel
  ⊢ borel = sigma 𝕌(:real) {s | open s}

borel can also be generated by half spaces, open or closed intervals:

borel_eq_le
  ⊢ borel = sigma 𝕌(:real) (IMAGE (λa. {x | x ≤ a}) 𝕌(:real))
borel_eq_less
  ⊢ borel = sigma 𝕌(:real) (IMAGE (λa. {x | x < a}) 𝕌(:real))
borel_eq_gr
  ⊢ borel = sigma 𝕌(:real) (IMAGE (λa. {x | a < x}) 𝕌(:real))
borel_eq_gr_le
  ⊢ borel =
     sigma 𝕌(:real) (IMAGE (λ(a,b). {x | a < x ∧ x ≤ b}) 𝕌(:real # real))
borel_eq_gr_less
  ⊢ borel =
     sigma 𝕌(:real) (IMAGE (λ(a,b). {x | a < x ∧ x < b}) 𝕌(:real # real))
borel_eq_ge_le
  ⊢ borel =
     sigma 𝕌(:real) (IMAGE (λ(a,b). {x | a ≤ x ∧ x ≤ b}) 𝕌(:real # real))
borel_eq_ge_less
  ⊢ borel =
     sigma 𝕌(:real) (IMAGE (λ(a,b). {x | a ≤ x ∧ x < b}) 𝕌(:real # real))

The extreal-valued Borel sets Borel $\mathscr{B}(\mathbb{\overline{R}})$ is defined by augmenting borel with infinities:

Borel
  ⊢ Borel =
     (𝕌(:extreal),
      {B' |
       ∃B S.
         B' = IMAGE Normal B ∪ S ∧ B ∈ subsets borel ∧
         S ∈ {∅; {−∞}; {+∞}; {−∞; +∞}}})

Borel can also be generated by half spaces (of the type $\konst{extreal} \to \konst{bool}$):⁸

Borel_def
  ⊢ Borel = sigma 𝕌(:extreal) (IMAGE (λa. {x | x < Normal a}) 𝕌(:real))
Borel_eq_le
  ⊢ Borel = sigma 𝕌(:extreal) (IMAGE (λa. {x | x ≤ Normal a}) 𝕌(:real))
Borel_eq_gr
  ⊢ Borel = sigma 𝕌(:extreal) (IMAGE (λa. {x | Normal a < x}) 𝕌(:real))
Borel_eq_ge
  ⊢ Borel = sigma 𝕌(:extreal) (IMAGE (λa. {x | Normal a ≤ x}) 𝕌(:real))

Let a and b be two measurable spaces ($\sigma$-algebras). A map $f \colon \konst{space}\,a \to \konst{space}\,b$ is called $a/b$-measurable (or measurable unless this is too ambiguous) if the pre-image of every measurable set is a measurable set: (the definition is in sigma_algebra theory)

measurable_def
  ⊢ ∀a b.
       measurable a b =
       {f |
        f ∈ (space a → space b) ∧
        ∀s. s ∈ subsets b ⇒ PREIMAGE f s ∩ space a ∈ subsets a}

A function is called Borel-measurable if it is a measurable map from any measurable space to borel or Borel:

val _ = overload_on ("borel_measurable", ``\a. measurable a borel``);
val _ = overload_on ("Borel_measurable", ``\a. measurable a Borel``);

For instance, a random variable is nothing but a measurable map from a probability space (which is also a measure space, see Section 6.6) to Borel. Thus in HOL there are actually two different types of Borel-measurable functions, real-valued or extreal-valued, each with a large set of theorems for proving the Borel-measurabilities, in real_borel and borel theories, respectively. For instance, the addition or subtraction of two real-valued (or extreal-valued) Borel-measurable functions $f$ and $g$ is still Borel-measurable:

in_borel_measurable_add
  ⊢ ∀a f g h.
       sigma_algebra a ∧ f ∈ borel_measurable a ∧ g ∈ borel_measurable a ∧
       (∀x. x ∈ space a ⇒ h x = f x + g x) ⇒
       h ∈ borel_measurable a

IN_MEASURABLE_BOREL_ADD'
  ⊢ ∀a f g h.
       sigma_algebra a ∧ f ∈ Borel_measurable a ∧ g ∈ Borel_measurable a ∧
       (∀x. x ∈ space a ⇒ h x = f x + g x) ⇒
       h ∈ Borel_measurable a

in_borel_measurable_sub
  ⊢ ∀a f g h.
       sigma_algebra a ∧ f ∈ borel_measurable a ∧ g ∈ borel_measurable a ∧
       (∀x. x ∈ space a ⇒ h x = f x − g x) ⇒
       h ∈ borel_measurable a

IN_MEASURABLE_BOREL_SUB'
  ⊢ ∀a f g h.
       sigma_algebra a ∧ f ∈ Borel_measurable a ∧ g ∈ Borel_measurable a ∧
       (∀x. x ∈ space a ⇒ h x = f x − g x) ⇒
       h ∈ Borel_measurable a

in_borel_measurable_mul
  ⊢ ∀a f g h.
       sigma_algebra a ∧ f ∈ borel_measurable a ∧ g ∈ borel_measurable a ∧
       (∀x. x ∈ space a ⇒ h x = f x * g x) ⇒
       h ∈ borel_measurable a

IN_MEASURABLE_BOREL_TIMES'
  ⊢ ∀a f g h.
       sigma_algebra a ∧ f ∈ Borel_measurable a ∧ g ∈ Borel_measurable a ∧
       (∀x. x ∈ space a ⇒ h x = f x * g x) ⇒
       h ∈ Borel_measurable a

Furthermore, if a real-valued function is Borel-measurable, so is its extreal-valued version. The converse also holds.

IN_MEASURABLE_BOREL_IMP_BOREL'
  ⊢ ∀a f.
       sigma_algebra a ∧ f ∈ borel_measurable a ⇒
       Normal ∘ f ∈ Borel_measurable a

in_borel_measurable_from_Borel
  ⊢ ∀a f.
       sigma_algebra a ∧ f ∈ Borel_measurable a ⇒
       real ∘ f ∈ borel_measurable a

Construction of Borel measure space (lborel)

The Borel measure space lborel (of the type $(\konst{real} \to \konst{bool}) \,\#\, ((\konst{real} \to \konst{bool}) \to \konst{bool}) \,\#\, ((\konst{real} \to \konst{bool}) \to \konst{extreal})$) is the household measure space defined on the real-valued Borel sets (borel) such that any interval with end points $a,b \in \mathbb{R}$ ($a \leqslant b$) has the extreal-valued measure of $b - a \in \mathbb{\overline{R}}$. The construction of lborel is done by extending a premeasure in the following steps:

1. Define the system of all right-open intervals and a “premeasure” lambda0 on it:

   right_open_interval
     ⊢ ∀a b. right_open_interval a b = {x | a ≤ x ∧ x < b}
   
   right_open_intervals
     ⊢ right_open_intervals = (𝕌(:real),{right_open_interval a b | T})
   
   lambda0_def
     ⊢ ∀a b. a ≤ b ⇒ lambda0 (right_open_interval a b) = Normal (b − a)
   

2. Prove that the set of all right open intervals is a semiring and the $\sigma$-algebra generated from it is nothing but borel:

   right_open_intervals_semiring
     ⊢ semiring right_open_intervals
   
   right_open_intervals_sigma_borel
     ⊢ sigma (space right_open_intervals) (subsets right_open_intervals) =
        borel
   

3. Prove (space right_open_intervals, subsets right_open_intervals, lambda0) (abbreviated as lborel0) is additive, finite_additive and eventually a premeasure (positive and countably_additive):

   lborel0_additive
     ⊢ additive lborel0
   
   lborel0_finite_additive
     ⊢ finite_additive lborel0
   
   lborel0_premeasure
     ⊢ premeasure lborel0
   

   (The proof of lborel0_premeasure depends on real_topology theory, especially the Heine-Borel Theorem. See Section 6.2.)

4. By Carathéodory Extension Theorem (CARATHEODORY_SEMIRING, see Section 6.4), there exists an extension of lborel0, denoted by lborel, which is now a measure space:

   lborel_def
     ⊢ (∀s. s ∈ subsets right_open_intervals ⇒ lambda s = lambda0 s) ∧
        measurable_space lborel = borel ∧ measure_space lborel
   

Let lambda = measure lborel be an abbreviation, the measure of the following typical Borel sets are proved as theorems:

lambda_prop
  ⊢ ∀a b. a ≤ b ⇒ lambda (right_open_interval a b) = Normal (b − a)

lambda_sing
  ⊢ ∀c. lambda {c} = 0

lambda_open_interval
  ⊢ ∀a b. a ≤ b ⇒ lambda (interval (a,b)) = Normal (b − a)

lambda_closed_interval
  ⊢ ∀a b. a ≤ b ⇒ lambda (interval [(a,b)]) = Normal (b − a)

Furthermore, the extreal-based Borel measurable space (ext_lborel) is defined by:

ext_lborel_def
  ⊢ ext_lborel = (space Borel,subsets Borel,lambda ∘ real_set)

real_set_def
  ⊢ ∀s. real_set s = {real x | x ≠ +∞ ∧ x ≠ −∞ ∧ x ∈ s}

where real_set (extreal theory) converts a set of extreals to the corresponding set of reals, filtering out $\pm\infty$. It can be proven that ext_lborel is indeed a $\sigma$-finite measure space:

measure_space_ext_lborel
  ⊢ measure_space ext_lborel

sigma_finite_ext_lborel
  ⊢ sigma_finite ext_lborel

Construction of Lebesgue measure space (lebesgue)

It is well known that lborel is not complete, in the sense that if for non-empty set s we have lambda s = 0, it's not true that all subsets of s has also the measure 0, as some of them may not be Borel sets at all. The completion of lborel is called Lebesgue measure space, denoted by lebesgue. In extreal theory (at $(HOLDIR)/examples/probability directory), it is defined directly by Henstock-Kurzweil Integration (see Section 6.3.2):

lebesgue_def
  ⊢ lebesgue =
     (𝕌(:real),{A | ∀n. indicator A integrable_on line n},
      (λA. sup {Normal (integral (line n) (indicator A)) | n ∈ 𝕌(:num)}))

real_borelTheory.line
  ⊢ ∀n. line n = {x | -&n ≤ x ∧ x ≤ &n}

The above definition indeed defines a $\sigma$-algebra and measure space. The Lebesgue measure of closed intervals is also proven (directly by integration theory):

sigma_algebra_lebesgue
  ⊢ sigma_algebra (𝕌(:real),{A | ∀n. indicator A integrable_on line n})

measure_space_lebesgue
  ⊢ measure_space lebesgue

lebesgue_closed_interval
  ⊢ ∀a b. a ≤ b ⇒ lmeasure (interval [(a,b)]) = Normal (b − a)

Now comes the relationship between lborel and lebesgue, which have two very different definitions. In fact, all Borel-measurable sets are also Lebesgue-measurable sets:

borel_imp_lebesgue_sets
  ⊢ ∀s. s ∈ subsets borel ⇒ s ∈ measurable_sets lebesgue

Finally, by uniqueness of measure, the two measure spaces lborel and lebesgue coincide on Borel sets (recall that lambda is an abbreviation of measure lborel):

lebesgue_eq_lambda
  ⊢ ∀s. s ∈ subsets borel ⇒ lmeasure s = lambda s

Lebesgue Integration Theory

The fundamental idea of integration is to measure the area between the graph of a function and the abscissa (i.e. $x$-axis). Riemann's approach partitions the domain of the function without taking into account the shape of the function, thus slicing up the area under the function vertically. Lebesgue's approach is exactly the opposite: the domain is partitioned according to the values of the function at hand, leading to a horizontal decomposition of the area.

In case the values of the function $f$ is finite, its domain can also be decomposed into the same number of disjoint sets (but each of them may not be a continuous interval). If the function is also nonnegative, i.e. $\forall x.\,0 \leqslant f(x)$, this function is called a positive simple function which can be also represented by a finite sum:

$$f = \sum_{j=0}^M y_j \mathbf{1}_{A_j}, \quad \text{where $\forall x\in A_j.\,f(x) = y_j$.}\quad\quad (\text{eq:posSimpleFn})$$

And the “integration” of $f$ is simply $\sum_{j=0}^M y_j\mu(A_j)$, where $\mu$ is the measure function of a measure space, e.g. lborel and lebesgue constructed in Section 6.4.1. Note that the representations of positive simple functions are not unique, but each representation can be uniquely determined by an index set $J$, a disjoint set of sets $A_j, j \in J$ and the set of values $y_j$ corresponding to each $A_j$. In HOL, the connection between positive simple functions (extreal-valued) and their representations is captured by pos_simple_fn, while the integration of positive simple functions is defined by pos_simple_fn_integral:

pos_simple_fn_def
  ⊢ ∀m f s a x.
       pos_simple_fn m f s a x ⇔
       (∀t. t ∈ m_space m ⇒ 0 ≤ f t) ∧
       (∀t. t ∈ m_space m ⇒ f t = ∑ (λi. Normal (x i) * 𝟙 (a i) t) s) ∧
       (∀i. i ∈ s ⇒ a i ∈ measurable_sets m) ∧ FINITE s ∧
       (∀i. i ∈ s ⇒ 0 ≤ x i) ∧
       (∀i j. i ∈ s ∧ j ∈ s ∧ i ≠ j ⇒ DISJOINT (a i) (a j)) ∧
       BIGUNION (IMAGE a s) = m_space m

pos_simple_fn_integral_def
  ⊢ ∀m s a x.
       pos_simple_fn_integral m s a x =
       ∑ (λi. Normal (x i) * measure m (a i)) s

Since the representations of a positive simple function are not unique, for each positive simple function there exists a set of representations (psfs), and a set of integrations (psfis) (although it can be proved that all these integrations are the same). The integration of an arbitrary positive function $f$ is defined as the supremum of all positive simple functions $g$ which is pointwise smaller than $f$:

pos_fn_integral_def
  ⊢ ∀m f.
       ∫⁺ m f = sup {r | (∃g. r ∈ psfis m g ∧ ∀x. x ∈ m_space m ⇒ g x ≤ f x)}

psfs_def
  ⊢ ∀m f. psfs m f = {(s,a,x) | pos_simple_fn m f s a x}

psfis_def
  ⊢ ∀m f.
       psfis m f =
       IMAGE (λ(s,a,x). pos_simple_fn_integral m s a x) (psfs m f)

For any positive function $f$, it is possible to construct a pointwise increasing sequence of positive simple functions $f_i$ which is always pointwise smaller than $f$. In another words, each $f(x)$ is the limit of $f_i(x)$ which is mono-increasing with $i$. Then the following monotone convergence theorem (actually due to Beppo Levi, see (Schilling 2017, 75)) reduces the integration of $f$ to the limit of integrations of $f_i$:

lebesgue_monotone_convergence
  ⊢ ∀m f fi.
       measure_space m ∧ (∀i. fi i ∈ Borel_measurable (measurable_space m)) ∧
       (∀i x. x ∈ m_space m ⇒ 0 ≤ fi i x) ∧
       (∀x. x ∈ m_space m ⇒ mono_increasing (λi. fi i x)) ∧
       (∀x. x ∈ m_space m ⇒ sup (IMAGE (λi. fi i x) 𝕌(:num)) = f x) ⇒
       ∫⁺ m f = sup (IMAGE (λi. ∫⁺ m (fi i)) 𝕌(:num))

Finally, the (Lebesgue) integration of an arbitrary function $f$ is defined by the subtraction of integrations of its positive and negative parts:

integral_def
  ⊢ ∀m f. ∫ m f = ∫⁺ m f⁺ − ∫⁺ m f⁻

extrealTheory.fn_plus_def
  ⊢ ∀f. f⁺ = (λx. if 0 < f x then f x else 0)

extrealTheory.fn_minus_def
  ⊢ ∀f. f⁻ = (λx. if f x < 0 then -f x else 0)

Note that it is possible that the two integrations above both result in the PosInf value, giving the entire integration an unspecified value (see Section 5.3.7 for more details on extreal arithmetics). A function $f$ is (Lebesgue) integrable if it is Borel-measurable and the integrations of its positive and negative parts are both finite (i.e. not $+\infty$):

integrable_def
  ⊢ ∀m f.
       integrable m f ⇔
       f ∈ Borel_measurable (measurable_space m) ∧ ∫⁺ m f⁺ ≠ +∞ ∧
       ∫⁺ m f⁻ ≠ +∞

A large set of theorems are provided in lebesgue theory on the properties of integrable functions and their integrations, including the following famous Markov's inequality:

markov_inequality
  ⊢ ∀m f a c.
       measure_space m ∧ integrable m f ∧ a ∈ measurable_sets m ∧ 0 < c ⇒
       measure m ({x | c ≤ abs (f x)} ∩ a) ≤
       c⁻¹ * ∫ m (λx. abs (f x) * 𝟙 a x)

Null sets and ‘almost everywhere’

A measurable set is called null set (with respect to its measure space) if its measure is zero:

null_set_def
  ⊢ ∀m s. null_set m s ⇔ s ∈ measurable_sets m ∧ measure m s = 0

A property $P(x)$ holds almost everywhere (AE) in a measure space $m$, denoted by AE x::m. P x in HOL⁹, if $P(x)$ holds for every $x$ excluding a null set:

borelTheory.AE_DEF
  ⊢ ∀m P. (AE x::m. P x) ⇔ ∃N. null_set m N ∧ ∀x. x ∈ m_space m DIFF N ⇒ P x

‘Almost everywhere’ is the basis of AE convergence in probability theory (see the next section). The following two theorems about the integration on null sets are very useful (Theorem 11.2 of (Schilling 2017, 89–90)):

integral_abs_eq_0
  ⊢ ∀m f.
       measure_space m ∧ f ∈ Borel_measurable (measurable_space m) ⇒
       (∫ m (abs ∘ f) = 0 ⇔ AE x::m. (abs ∘ f) x = 0) ∧
       ((AE x::m. (abs ∘ f) x = 0) ⇔
        measure m {x | x ∈ m_space m ∧ f x ≠ 0} = 0)

integral_null_set
  ⊢ ∀m f N.
       measure_space m ∧ f ∈ Borel_measurable (measurable_space m) ∧
       N ∈ null_set m ⇒
       integrable m (λx. f x * 𝟙 N x) ∧ ∫ m (λx. f x * 𝟙 N x) = 0

Radon-Nikodým theorem

So far there is no concept “derivative” being discussed. In Lebesgue integration, Radon-Nikodým (RN) Theorem (see, e.g., (Schilling 2017, 230) or (Fitzpatrick and Royden 2010, 382)) has the position of “Fundamental Theorem of Calculus” as in Riemann Integration. Recall in Lebesgue's theory one starts directly from the concept “integration” without defining “derivative” first. It is RN theorem which introduces the concept of “derivative” for Lebesgue integration and asserts its existence. The theorem says that for any $\sigma$-finite measure space $m$, if there is another measure $v$ absolutely continuous with respect to $m$, i.e. whenever any set $s$ has zero measure in measure space $m$ it also has same zero measure in $v$: