SOFTWARE VERIFICATION RESEARCH CENTRE DEPARTMENT OF COMPUTER SCIENCE THE UNIVERSITY OF QUEENSLAND. Queensland 4072 Australia TECHNICAL REPORT

Transcription

1 SOFTWARE VERIFICATION RESEARCH CENTRE DEPARTMENT OF COMPUTER SCIENCE THE UNIVERSITY OF QUEENSLAND Queensland 4072 Australia TECHNICAL REPORT No The demonstration interactive theorem prover Demo3.3 Peter J. Robinson and K. Whitwell June 1993 Phone: Fax:

2 The demonstration interactive theorem prover Demo3.3 Peter J. Robinson K. Whitwell Software Verication Research Centre Department of Computer Science The University of Queensland June 1993 Abstract This paper describes the prototype interactive theorem prover demo3.3. The prototype demonstrates several proposals for increasing the eciency and convenience of interactive deductive reasoning. These include: the use of a very high-level logic programming language (Qu-Prolog) for implementation, which provides strong support for symbolic computation with mathematical notations, rapid prototyping, schematic notations and programming of interactive theorem prover tactics; a new window inference method specifically designed to capture hierarchical goal-directed proofs; and a capacity to support a variety of logics. 1

3 Contents 1 Introduction 3 2 Qu-Prolog 3 3 Elementary Use of Demo Getting Started : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Positions and Opening Windows : : : : : : : : : : : : : : : : : : : : : : : : Equivalence Transformations : : : : : : : : : : : : : : : : : : : : : : : : : : Closing Windows : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 9 4 Equivalences 11 5 Splitting and Simplication 12 6 Lemmas 12 7 Conjectures 15 8 Tactics 17 9 Macros Metavariable Management in Proofs Proof Editor Commands User Commands : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Tactic Commands : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : The Default Proof Tactic Creating New Theories Vocabulary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : The Demo3.3 Database : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Setting Up A New Theory : : : : : : : : : : : : : : : : : : : : : : : : : : : Example Proof Editor Session 32 Index 43 2

4 1 Introduction The interactive theorem prover Demo3.3 is a prototype interactive verication system. It demonstrates several proposals for increasing the eciency and convenience of interactive reasoning. It is also a testbed for evaluating and rening these proposals. These proposals include: Rapid prototyping of interactive verication systems using the extended logic programming language Qu-Prolog (see [1], [2]). The implementation of Demo3.3 in Qu-Prolog 3.1 takes advantage of built-in high-level support for the sorts of symbolic computation used in interactive verication systems, including schematic notations for full rst order syntax, a hierarchically structured database, and a very high-level, rule-based language for prototyping and for user-programmed proof tactics. A new proof concept especially designed for interactive use. This window inference approach is described in [3]. For a variety of logics it supports the construction of equivalence transformations relative to arbitrary equivalences, hierarchical goal-directed reasoning, and the use of contextual information for the transformation of subexpressions. It also exploits Qu-Prolog's schematic notation, to support schematic reasoning and the use of answer extraction during reasoning. A new, functional logic (see [4], [5]) which is designed to closely integrate mainstream mathematics and (classical) logic with programming logics such as Hoare logic, to provide a high-level vocabulary for reasoning about procedural code. Demo3.3 is however a prototype rather than a fully mature system. The theories in its database are not yet much developed, and it lacks attributes which are essential for a production verication system, including support for typed logic syntax, and fully independent user syntax for each theory supported. These features are unimplemented because support for their rapid prototyping is not available in Qu-Prolog 3.1. It is intended to provide them as support becomes available in future versions of Qu-Prolog. Demo3.3 currently has two versions. The rst is a simple line-oriented version and is the one used for all examples in this paper. The second version is a prototype of a screen-based system and is implemented in a variant of Qu-Prolog that has access to an X-windows environment (see [6]). A main advantage of the second version is its ability to use X-windows highlighting to choose, for example, terms and subterms from those currently displayed. 2 Qu-Prolog It is not the aim of this paper to describe Qu-Prolog in detail. However, since Demo3.3 is implemented in Qu-Prolog some comments about Qu-Prolog are required in order to use its syntax during interaction with the system. The reader is referred to [1], [2] for a fuller discussion of Qu-Prolog. It is assumed the reader is familiar with standard Prolog, and in particular with Prolog's method of declaring the precedence and associativity of function symbols. 3

5 Qu-Prolog's syntax is an extension of the syntax of standard Prolog. includes syntax for object variables, quantiers and substitutions. The extension The syntax for object variables is that of the syntax for atoms. They are distinguished from atoms by declaration. Once a string has been declared as an object variable then all further occurrences of that string, or that string followed by an underscore and an integer, are taken as object variables. In the examples that follow in this section, we assume x, y and z have been declared as object variables. Quantiers are declared in Qu-Prolog in a similar way to function symbols. Once a quantier, say all, has been declared then the user has access to syntax of the form all x TERM. Such syntax represents a quantied term with x as the bound object variable. Note that, as with user-declared function symbols, there is no intended semantics associated with a quantier declaration. A substitution is represented as a Prolog list whose elements are of the form T/x, where T is a term and x is a declared object variable. Substitutions are applied to terms using * as the inx operator representing substitution application. As an example, consider the term [a/x]*[b/y, c/z]*term. The intention is that all free occurrences of y and z in TERM are to be replaced by b and c respectively, then all free occurrences of x in this new term are to be replaced by a. To conclude this section we note some other properties of Qu-Prolog that may aid the user in understanding the behaviour of the system. Firstly, Qu-Prolog's unication extends standard Prolog unication by attempting to make terms equal up to change of bound variable. The extra complexity of unication may cause Qu-Prolog's unication algorithm to generate delayed unication problems. When such delayed problems are produced, Demo3.3 uses a heurisitic unication algorithm in an attempt to nd some unier. Secondly, for some axioms (and theorems) in the system, the user may wish to state that a given object variable should not occur free in a term as for example in the theorem all x (C => A) <=> (C => all x A). Here x should not occur free in C. This can be achieved by the Qu-Prolog call x not free in C. The user of Demo3.3 can specify and access non-freeness information in this fashion when declaring axioms and in proofs of theorems. Lastly, we briey mention the freeze/thaw mechanism of Qu-Prolog. In Qu-Prolog, we are able to freeze variables and so prevent them from being instantiated during unication. For Demo3.3 this means we are able to carry out the one-sided unication that is commonly required for the application of rules such as simplication rules. Also, by freezing variables within proofs, the user is unable to instantiate these variables other than via system commands. 4

6 3 Elementary Use of Demo Getting Started Demo3.3 is implemented in Qu-Prolog under UNIX 1 and is invoked by typing the command demo3.3 in an appropriate UNIX environment. The following characters will appear on the screen. $ demo3.3 DEMO3.3: a prototype verification system Copyright (C) 1992 Dept Computer Science, University of Queensland. loading obvars... loaded loading symbols... loaded loading root data... loaded loading root dir... loaded / : The sole `/' indicates that the current theory is the root theory root. The prompt `:' requests user input. The structure of the interactive theorem prover database appears to the user as a UNIXlike hierarchy of les in which a directory represents a theory, and non-directory items within a theory represent the attributes of that theory. The root of the tree represents the theory root. Each theory other than root is regarded as an extension of the theory at its parent directory. The supplied root theory is a fragment of intuitionist predicate logic with equality. Soundness of window inference is justied in this fragment, and equality is used throughout to make denitions. A user can change the working theory (current directory) using the command cd/1. (Here, `/1' means that the command has one parameter.) For example, if the user wants to prove a theorem in the predened theory of rst-order logic, the new working theory should be fol. The following characters show on the screen after typing the command cd(fol) or cd('fol'). Note that every command except a y/n request should be followed by a period. : cd(fol). loading root fol data... loading root fol dir... loading skolem.ql... loaded loaded loaded /fol Within a theory a central activity is the construction of proofs. This interactive theorem prover demonstrates the window inference method (see [3]) whose basic purpose is to 1 UNIX is a trademark of Bell Laboratories 5

7 construct equivalences. To prove a theorem TH the equivalence TH <=> true is proved (Demo3.3 uses <=> to denote logical equivalence). To refute an assertion ASS, the equivalence ASS <=> false is proved. Equivalences other than logic equivalences, for example arithmetical equalities, can be proved in the same uniform way. A window is a data structure comprising: an equivalence relation e, indicating which sort of equivalence is being proved; a focus F, which is the term to be transformed by equivalence transformations; some hypotheses H, which are being assumed true for the transformation of the focus; for heuristic purposes, a goal G which indicates the desired outcome of transforming the focus. Intuitively, a window as above denes an intention to prove H => (F e G). As well as directly transforming the focus or a hypothesis by rules available in the current theory, the user can transform some subterm of a focus or hypothesis by setting up a subwindow, with that subterm as its focus. The user's choice of opening rules from those available in the current theory determines the attributes (equivalence, focus, hypotheses, goal) of the subwindow. The window inference method can then be applied to the subwindow, and so on recursively. Since the approach can be used recursively, a single stage in a proof may comprise a sequence, or stack, of windows, each opened on a part of the previous window. A proof is started by using one of the prove commands listed in section 11. The command prove/2 creates a starting window with a nominated term as the focus, logical equivalence as the equivalence of the window and true as the goal. It oers the user the possibility of transforming a term A into a logically equivalent term A 0 so that a theorem A <=> A 0 may be proved. For example, suppose that in the theory fol the user types the command prove(th, (X => Y) => (not Y => not X)). Here, th is the name given to the theorem after the proof is completed. Demo3.3 shows the following rst-level window on the screen. : prove(th, (X => Y) => not Y => not X). Window level: 1 Window number: 1 (X => Y) => (not Y => not X) /fol (theorem - top level) Demo3.3 has created a window with focus (X => Y) => (not Y => not X), with equivalence <=>, with goal true, and with no hypotheses. In this example, X and Y are schematic variables. Intuitively, schematic variables represent undetermined pieces of syntax which may be chosen as the proof proceeds. 6

8 In the above display, the window level is the number of windows that are currently opened while the window number is the total number of windows that have been opened (including those that were opened and later closed) up to and including the creation of this window. The window number is used in the identication of choicepoints used in section Positions and Opening Windows As already mentioned, during a proof a window may be opened at a subterm of the focus, or at a subterm of any hypothesis of the current window. This leads to a stack of windows that expands and contracts as windows are opened and closed. Within a single Demo3.3 proof, the user has access only to the top window of the stack (i.e. the most recently opened window). The openwin/1 command is used to open a window at a chosen subterm of the focus. The argument of openwin/1 is a list of integers called a position and is used to choose the desired subterm. Each integer in the list is used to choose a particular argument of a function or the body of a quantier of the expression being considered. Rather than providing a formal denition, we illustrate the notion of positions by considering subterms of the term f(a, g(all x C, B), r(d)), where all is a quantier, as follows: (a) A has position [1] in the term, because it is the rst argument of f; (b) (c) (d) (e) (f) g(all x C, B) has position [2] in the term; r(d) has position [3] in the term; B has position [2,2] in the term because g(all x C, B) has position [2] in the term, and B has a position [2] in the subterm g(all x C, B), i.e. the position [2,2] is the sequence of the positions [2] and [2]; C has position [2,1,2] in the term because all x C has position [2,1] in the term, and C has position [2] in the subterm all x C; D has position [3,1] in the term. In the case when opening a window at the body of a quantier, a tactic may wish to know the gererated object-variable. In this case, the position [b(ov)] may be used instead of [2]. Here OV will be unied with the generated object-variable. In our example proof, the position of not X in the focus is [2,2] and so the command openwin([2,2]) will open the following second-level window. : openwin([2,2]). Window level: 2 Window number: 2 not X 2: not Y 1: X => Y 7

9 Note the appearance of two hypotheses in this second window. They, and the equivalence relation in this window, are determined by the window inference rules applied by openwin. For some complex hypotheses, Demo3.3 will automatically split them into several simpler hypotheses using splitting rules. These splitting rules are discussed in section 5. A user may focus on a subterm of any hypothesis, by using the command openwin/2. The rst parameter of openwin/2 names the hypothesis, and the second is the position of the required subterm. For example, if the command openwin(1,[2]) is used in the above example, the subterm Y, which has position [2] in hypothesis 1, is chosen as focus in a third-level window as follows: : openwin(1, [2]). Window level: 3 Window number: 3 Y 3: X 2: not Y Goal: false Here, the hypothesis not Y is copied from the parent window and the hypothesis X is generated by the window opening rule. 3.3 Equivalence Transformations The window inference method gives a central place to equivalence transformations. Its construction of new equivalence transformations is based on the use of existing equivalence transformations, and more generally on the use of theorems, axioms or hypotheses of the following form: (A 1 and A 2 and A n ) => (B e C) where e is an equivalence relation. Given information concerning which theorem, axiom or hypothesis is to be unied with the above form, and which theorems, axioms or hypotheses are to be unied with the A 1 ; A 2 ; : : : ; A n, a suitable command trans(fname, AList) will transform the focus of the current window from B to C. Unication can be used to make this strategy succeed. In general, the argument FName is the name of a theorem, axiom or hypothesis of the form (A 1 and A 2 and A n ) => (B e C); the argument AList is a list of names of hypotheses, theorems or axioms which are to be unied with A 1 ; A 2 ; : : : ; A n respectively. Lemmas and conjectures (see sections 6 and 7) are considered as hypotheses when carrying out equivalence transformations. Example 1 In our running example, if the theory fol has an axiom not A => (A <=> false) labelled notimpbool, the command trans(notimpbool, [2]) has the following eect: 8

10 : trans(notimpbool, [2]). Window level: 3 Window number: 3 false 3: X 2: not Y Goal: false In this example n = 1, and not Y is unied with not A in the axiom by instantiating A to Y. This also achieves the unication of A with the focus Y. Hence the rule applies and the focus is transformed to false. Example 2 The command h trans(hname, FName, AList) is used to transform the hypothesis called HName in a similar way to the trans command given above. In the command, the argument FName is the name of the theorem, axiom or hypothesis which is to be unied with the expression (A 1 and A 2 and A n ) => (B <=> C); the argument AList is a list of names of hypotheses, theorems or axioms which are to be unied with A 1 ; A 2 ; : : : ; A n respectively; and the hypothesis labelled HName is unied with B. Suppose that in a proof the current window has three hypotheses, and that the rst hypothesis is Y, the second hypothesis is X => (Y <=> Z), and the third hypothesis is X. When the user types the command h trans(1,2,[3]), the rst hypothesis is transformed from Y to Z. Example 3 In the case n = 0, the argument FName of the command trans and h trans is the name of a theorem, axiom or hypothesis which has the form B e C. For this case, the transformation commands do not need the argument AList, and can be written trans(fname) and h trans(hname, FName). Suppose for example that there is an axiom (A <=> B) <=> (A => B) and (B => A) labelled def(<=>), and that the focus is X <=> Y in the current window. If the user types the command trans(def(<=>)), then the focus is transformed to (X => Y) and (Y => X). Other variants of the transformation commands are listed in Section Closing Windows A subwindow at level n + 1 is used to transform a subterm S of a term in the window at level n. The command closewin used at the subwindow replaces S in the n-th level 9

11 window by the current focus of the subwindow, and deletes the subwindow. Simplication of the resulting term is then carried out. The opening rules in window inference are chosen so that when this closing transformation occurs, the n-th level window is transformed to an equivalent window (see [3]). The command closewin is often used when the current focus is simple, e.g. true or false. In our running example when the user types closewin in window 3 (a third-level window), Demo3.3 closes window 3 and changes window 2 as follows: : closewin. Window level: 2 Window number: 2 not X 3: not X 2: not Y Here, the nal focus of window 3 has replaced subterm Y of window 2's second hypothesis X => Y. That hypothesis therefore becomes X => false. That in turn is automatically simplied to not X using simplication rules. In Demo3.3, there are specic simplication rules for each theory. They are used to simplify transformed terms automatically when windows are closed. Simplication rules are discussed in section 5. Now assume there is another axiom A => (A <=> true) labelled impeqltrue in the theory fol. In the current window 2, the second hypothesis and the focus are the same, so the user can use the command trans(impeqltrue,[3]) to transform the focus to true. The proof is completed as follows: : trans(impeqltrue, [3]). Window level: 2 Window number: 2 true 3: not X 2: not Y : closewin. Window level: 1 Window number: 1 true 10

12 /fol (theorem - top level) : closeproof. The following theorem has been proven ********************************************************* th: (X => Y) => (not Y => not X) Do you wish to save this theorem? y /fol The proof is complete when the command closeproof is used in the top level window. If the proof has transformed a term A to a term B in a top level window with equivalence e, then the theorem A e B is generated and added to the database of theorems. A single application of the simplication rules is used on the generated theorem which, for example, will transform a theorem of the form A <=> true to A. 4 Equivalences Equivalence transformations play a central role in Demo3.3 proofs and the system is capable of managing a range of equivalence relations. These equivalence relations must be declared to the system before use as equivalence relations. This is carried out using the command set equ(refthm, SymThm, TransThm, Equivalence). Here the rst three arguments are the names of theorems or axioms that state that Equivalence is a reexive, symmetric and transitive relation. Following this declaration, Equivalence may be used in any place where the system expects an equivalence relation. Given that the system is capable of managing several equivalences, even within the one proof, it is convenient that the system be capable of replacing one equivalence with another when carrying out transformations, provided soundness is not compromised. This is achieved by describing a partial order on a set of equivalence relations dened by `e 1 is greater than e 2 ' provided (A e 1 B) => (A e 2 B) is a theorem. In this case we say e 2 is compatible with e 1. This partial order can be used in Demo3.3 when applying transformations, opening rules and simplications. For example, in a window with equivalence e 2 a transformation rule using a theorem term 1 e 1 term 2 may be used provided e 2 is compatible with e 1. The use of this partial order increases the eciency of reasoning by implicitly combining several lower level inference steps. The user may add to the partial order with the command add epo(thm, Eq 1, Eq 2 ) 11

13 where Eq 1 and Eq 2 are declared equivalence relations and Thm is the name of a theorem (or an axiom) of the form (A Eq 1 B) => (A Eq 2 B). 5 Splitting and Simplication To increase eciency during proofs, some theorems (or axioms) of a theory can be designated as splitting or simplication rules. These rules are automatically applied by the system during a proof. Splitting rules allow some hypotheses to be split into a collection of simpler hypotheses. For example, the hypothesis A and B can be split into hypothesis A and hypothesis B because the required splitting rule is part of the root theory. Simplication rules are used to simplify expressions in a window. The main use of simplication is when a window is closed. Here, for example, the theorem (axiom) A and true <=> A can be used to simplify A and true to A. Simplication is also used when hypotheses are split and for simplifying the new goal when a window is opened. In all of these cases simplication is repeatedly applied until no further simplication rules apply. When a proof is completed, a single application of simplication is made to the theorem. This would, for example, transform a generated theorem of the form (A => true) <=> true to A => true. No further simplication is applied to this theorem. The single application is used because, particularly in the initial development of a theory, it is often important to include true and false as part of the statement of some theorems. Repeated simplication may remove such occurrences. 6 Lemmas During a large proof the user may wish to prove a small result to aid in the overall proof. This can be achieved in one of two ways. Firstly, the user could use the prove command to start up a new proof. When this proof is nished the new result is saved as a theorem and control returns to the main proof which now has access to the new theorem. Secondly, if the small result is only needed for the main proof, the user could prove a lemma within the main proof using lemma/1. This command starts a new subproof for the proposed lemma with the top-level window of the lemma proof containing all the hypotheses of the current window of the main proof. On completion of the lemma proof, the closelemma command called in the top-level window of the lemma proof nishes the lemma proof and adds the new lemma to the current window of the main proof. When a window is closed the results of transformations applied to the ordinary hypotheses of this window are lost. On the other hand the results of lemma proofs are retained on closing windows. This is achieved in the implementation of Demo3.3 by having the system automatically generate a version of each lemma to be added to the parent window on closing. The construction of each version is specied by a `lemma lifting rule' which is part of each opening rule (see Section 13). 12

14 Following is a simple example of part of a proof involving a lemma. This example makes use of a theorem A => ((A => B) <=> B) which is labelled mp. Window level: 2 Window number: 2 (Y => Z) => W 1: X => Y : openwin([2]). Window level: 3 Window number: 3 W 2: Y => Z 1: X => Y : lemma(x => Z). Window level: 4 Window number: 4 X => Z 2: Y => Z 1: X => Y /fol (lemma - top level) : openwin([2]). Window level: 5 Window number: 5 Z 3: X 2: Y => Z 1: X => Y /fol (lemma) : h_trans(1, mp, [3]). 13

15 Window level: 5 Window number: 5 Z 4: Y 3: X 2: Y => Z /fol (lemma) : h_trans(2, mp, [4]). Window level: 5 Window number: 5 Z 5: Z 4: Y 3: X /fol (lemma) : trans_true(5). Window level: 5 Window number: 5 true 5: Z 4: Y 3: X /fol (lemma) : closewin. Window level: 4 Window number: 4 true 2: Y => Z 1: X => Y /fol (lemma - top level) : closelemma. 14

16 Window level: 3 Window number: 3 W 2: Y => Z 1: X => Y l(1): X => Z : closewin. Window level: 2 Window number: 2 (Y => Z) => W 1: X => Y l(1): (Y => Z) and X => Z In the last step, window 3 is closed and the lemma of window 3 is lifted to a lemma in window 2. This is achieved by the system in two stages. The rst is by the application of the lemma lifting rule associated with the corresponding opening rule. This particular rule lifts X => Z to (Y => Z) => (X => Z) when closing the window. The second is by the transformation of this new lemma to the equivalent lemma ((Y => Z) and X) => Z. This form is more eciently used by the system. 7 Conjectures Demo3.3 allows the user to add to any window a new hypothesis, called a conjecture, using the command conjecture/1. For each conjecture the system automatically creates a new conjecture in the parent window when closing the current window. Here is a simple example, where the user begins a proof with the intention of proving Y => X, but uses a conjecture to nd a weaker result. As with lemmas, a `conjecture lifting rule' is used to generate a version of each conjecture when closing windows. : prove(th1, Y => X). Window level: 1 Window number: 1 Y => X /fol (theorem - top level) 15

17 : openwin([1]). Window level: 2 Window number: 2 Y 1: not X Goal: false : conjecture(not Y). Window level: 2 Window number: 2 Y 1: not X c(1): not Y Goal: false : trans(notimpbool, [c(1)]). Window level: 2 Window number: 2 false 1: not X c(1): not Y Goal: false : closewin. Window level: 1 Window number: 1 true c(1): not X => not Y /fol (theorem - top level) : closeproof. The following theorem has been proven ********************************************************* th1: (not X => not Y) => (Y => X) 16

18 When closing the proof, a theorem (not X => not Y) => (Y => X) is proved, where (not X => not Y) is an antecedent generated from the conjecture of window 1. For safety, it is not possible in Demo3.3 to remove a conjecture from a proof, once introduced, except by undoing the proof to the point before the conjecture was introduced. Future versions of the system will permit users to discharge conjectures by proving them at some point within the main proof. 8 Tactics Tactics in Demo3.3 are Qu-Prolog programs and are typically used in the construction of proofs. There are two major types of tactics - those that manage entire proofs, and those that carry out parts of proofs. All proofs in Demo3.3 are controlled by a tactic. When a prove or provet command is called, control is passed to the tactic nominated by the command. The prove command passes control to the default system tactic called sys tactic. This tactic is a low-level interactive tactic for carrying out proofs and is described in section 12. The sample proofs of this paper are constructed using this tactic. The provet command passes control to the named tactic. Such tactics may attempt to carry out the entire proof automatically, or produce an interactive environment or a combination of both. The system is supplied with the tactic kprove/2, described in [7], that produces a higher-level interaction than sys tactic. Tactics can also be used to combine common sequences of proof steps into a single command, or to carry out sub-proofs automatically. The system is supplied with the tactic skolem/1 that has an eect similar to skolomizing the named hypothesis, and the tactic trans bool that applies one of the three boolean introduction rules. Each tactic is prepared in a separate le with a name of the form lename.ql, in which each tactic command TacticCommand with its arity Arity is declared using a clause?- declare(tacticcommand/arity). This le is loaded into the system by typing the command add tactic(lename). The current theory (and its descendent theories) then have access to the tactic commands dened in lename. Before exiting the system the save command should be used so that subsequent invocations of Demo3.3 will automatically load the tactic. 9 Macros The Demo3.3 command macro(lename) executes a sequence of system commands listed in the named le. On terminating a Demo3.3 session, all the commands the user has typed are saved in a le named user commands. This le will be overwritten at the start of the following session, 17

19 and so it should be copied to another le if the command sequence is to be saved. If the user has copied the le user commands to another le, for example my commands, the command sequence can be repeated by re-entering Demo3.3 and typing macro(my commands) after the prompt `:' appears. The command sequence may be modied by editing the macro le before re-entering the system. The macro command can also be used to execute a common sequence of commands. 10 Metavariable Management in Proofs Schematic proofs typically contain two conceptually distinct types of metavariable. Firstly there are the variables which appeared in the statement of the theorem to be proven. Typically these proof variables are used to enable schematic theorems to be stated and used in subsequent proofs. It is unlikely that these variables are meant to be instantiated during the proof and should therefore remain frozen throughout the proof. The second class of variables are those introduced through proof commands, and are expected to eventually unify with terms possibly containing proof variables. These new variables are expected to behave as if thawed during unications carried out as part of the execution of trans commands. Demo3.3 keeps a list of these new variables, and thaws it when carrying out such unications, purging the list for variables which have been instantiated to structures or frozen variables. The management of the list of new variables supersedes the full unify concept of previous versions of the theorem prover. 11 Proof Editor Commands Demo3.3 has a UNIX-style hierarchy of directories, each containing a theory. As in UNIX, Demo3.3 uses the concept of current directory. Most commands are relative to the current directory (working theory). The commands are divided into user commands and tactic commands User Commands The available user commands are divided into the following groups: Accessing theories. Initiating proofs. Displaying information. Declaration commands for an open theory. Symbol denition commands. Other denition/declaration commands. 18

20 Exit. Accessing theories cd(pathname). Change the current (working) theory to a theory indicated by PathName which must be either an absolute position or relative to the current directory. For example, if the current theory is /, i.e. the theory root, then cd(`fol') will make the current theory fol. If some of the directories given in the PathName have not been loaded into the system then this command will load them. Initiating proofs prove(name, Term, Equ, Goal). This command is used to start a window proof. A new proof is created with the initial window (level 1) having focus Term, goal Goal and equivalence Equ. The resulting theorem will be given the name Name. The proof is managed by the tactic sys tactic. prove(name, Term). The same as prove(name, Term, <=>, true). prove(name, Term, Equ, Goal, NFI). The same as prove/4 except that not free in constraints are added. Here NFI is a list whose elements are of the form x not free in T. prove(name, Term, NFI). The same as prove(name, Term, <=>, true, NFI). provet(tactic, Name, Term, Equ, Goal). The same as prove/4 except that Tactic is called to manage the proof. provet(tactic, Name, Term). The same as provet(tactic, Name, Term, <=>, true). provet(tactic, Name, Term, Equ, Goal, NFI). The same as provet/4 except that not free in constraints are added. Here NFI is a list whose elements are of the form x not free in T. provet(tactic, Name, Term, NFI). The same as provet(tactic, Name, Term, <=>, true, NFI). Displaying information help. Display a list of available commands. ls. nfi. List the extension (child) theories of the current theory. 19

21 List all the not free in problems associated with the current proof. show(attribute). Display the information concerning Attribute in the current directory. Attribute must be one of the following: theory status axiom theorem deff defq primf primq openwin split simp epo tactic file tactic command. show(file, Attribute). Same as show(attribute) except that output is appended to the named le. show all(attribute). Same as show(attribute) except that all relevant information from the ancestor theories is also displayed. show all(file, Attribute). Same as show all(attribute) except that output is appended to the named le. showp(attribute, Pattern). Display the information concerning Attribute in the current directory that matches Pattern. Here Attribute is either axiom or theorem. showp(file, Attribute, Pattern). Same as showp(attribute, Pattern) except that output is appended to the named le. showp all(attribute, Pattern). Same as showp(attribute, Pattern) except that all relevant information from the ancestor theories is also displayed. showp all(file, Attribute, Pattern). Same as showp all(attribute, Pattern) except that output is appended to the named le. Declaration commands for an open theory close. Close the current theory. Closing a theory irreversibly terminates the declaration of the theory. defet(name). Declare Name as an (open) extension theory of the current theory. const(name). Declares Name as a constant in the current, open theory. primf(name, Arity, Prece, OpAss). 20

22 Declares Name as a primitive function in the current, open theory with arity Arity, operator precedence Prece and operator associativity OpAss. primf(name, Arity). Declares Name as a primitive function with arity Arity in the current, open theory. For example, the command primf(f,2) declares a binary function f. primq(name, Prece). Declares Name as a primitive quantier with precedence Prece in the current, open theory. obj var(name). Declares Name as an object variable. Object variable names are global to all theories. Declaring Name as an object variable automatically declares object variables of the form Name followed by ` ' and an integer. mkaxiom(name, Axiom). Declares an axiom Axiom with a name Name in the current, open theory. mkaxiom(name, Axiom, NFI). Same as mkaxiom(name, Axiom), but includes a list of not free in constraints. These constraints are added to the axiom when it is created. mkoprule(t, Pos, SubT, ExH, OtNHL, OtNE, OtNG, FocLR, LemLR, ConLR). Declares an opening rule for a function in the current theory. The items in the command are explained in Section 13. For this version of the interactive theorem prover, all opening rules are primitive rules. mkoprule(t, Pos, ObV, SubT, ExH, OtNHL, OtNE, OtNG, FocLR, LemLR, ConLR). Declares an opening rule for a quantied term in the current theory. The items in the command are explained in Section 13. delete theory. Deletes the current theory and exits the system. This command only succeeds if the current theory has no extension theories. Symbol denition commands deff(name, ObVarList, Term, Precedence, OpAss). Denes Name as a dened function in the current theory with operator precedence Precedence and associativity OpAss. An example of the use of this command is given in Section 13. deff(name, ObVarList, Term). Similar to deff/5 except that it declares Name as a function using standard function notation. defq(name, Bound, Body, Definition, Precedence). 21

23 Declares Name as a dened quantier with precedence Precedence in the current theory. An example of the use of this command is given in Section 13. Other denition/declaration commands set equ(refthm, SymThm, TransThm, Equivalence). Declares Equivalence as an equivalence in the current theory. To guarantee that this function symbol is an equivalence, theorems stating that this relation is reexive, symmetric and transitive must be given. RefThm, SymThm and TransThm are the names of the respective theorems. add epo(theorem, Eq1, Eq2). Adds `Eq1 greater than Eq2' to the equivalence partial order. Theorem is the name of the theorem of the form (A Eq1 B) => (A Eq2 B) needed to justify this declaration. mksplit(name). Declares a splitting rule split rule(pattern,[a 1,...,A n ]) in the current theory from a theorem (or axiom) Pattern <=> (A 1 and A 2 and A n ) labelled Name in the database (see Section 13). rmsplit(pattern). Removes the splitting rule split rule(pattern, List) in the current theory that was created by the previous command with the same item Pattern. mksimp(name). Declares a simplication rule simp rule(pattern,e,term) in the current theory from a theorem (Pattern e Term) labelled Name in the database, where e is an equivalence symbol. rmsimp(pattern, Equivalence). Removes the simplication rule simp rule(pattern, Equivalence, Term) in the current theory that was created by the previous command with the same items Pattern and Equivalence. add tactic(file). Declare the tactic le File and load it (see Section 8). rm tactic(file). Remove reference to the tactic le File so that, after saving, further invocations of the system will not load this tactic le. macro(file). Input from File replaces the input from the terminal (see Section 9). Exit save. Save the current theory and all its loaded extension theories (recursively). bye. Exit Demo

24 11.2 Tactic Commands These commands are available for programming tactics. openwin(position). A window is opened at the subterm of the current focus specied by a position Position (see 3.2). If no window opening rule applies for some entry in Position then the command fails and no window is opened, and otherwise a window is opened at the specied subterm. openwin(name). A window is opened at an entire hypothesis given by Name. openwin(name, Position). This command has the same eect as openwin(position) except that a window is opened at a hypothesis given by Name. closewin. Close the current window incorporating its focus into the parent window. The parent window becomes the current window. closelemma. This terminates a lemma proof and adds the proved lemma as a hypothesis in the window of the main proof. This command only succeeds in the top-level window of the lemma proof. trans(thmname, Direction, Goal, Antecedents). This form of trans is typically only used in tactics. The forms that follow are used to abreviate specic instances of this command and tend to be used during interaction. Direction is one of ft, f, rg, standing for `true', `forward' and `reverse' respectively. In order for the command to succeed, Goal must unify with the new focus. If Direction is t then this command attempts to apply an axiom, theorem or hypothesis (labelled ThmName) of the form (A 1 and A 2 and A n ) => B, where Antecedents names axioms, theorems and/or hypotheses which (after uni- cation) are A 1 ; : : : ; A n respectively, and if (after unication) B is the current focus, and the current equivalence is <=>, then the current focus is replaced by true. If Direction is f then this command attempts to apply an axiom, theorem or hypothesis (labelled ThmName) of the form (A 1 and A 2 and A n ) => (B e C), 23

25 where Antecedents names axioms, theorems and/or hypotheses which (after uni- cation) are A 1 ; : : : ; A n respectively, and if (after unication) B is the current focus, and the current equivalence is compatible with e then the current focus is replaced by the corresponding instantiation of C. If Direction is r then this command attempts to apply an axiom, theorem or hypothesis (labelled ThmName) of the form (A 1 and A 2 and A n ) => (B e C), where Antecedents names axioms, theorems and/or hypotheses which (after uni- cation) are A 1 ; : : : ; A n respectively, and if (after unication) C is the current focus, and the current equivalence is compatible with e then the current focus is replaced by the corresponding instantiation of B. trans(thmname). This command abbreviates trans(thmname, f,, []). trans r(thmname). This command abbreviates trans(thmname, r,, []). trans(thmname, Antecedents). This command abbreviates trans(thmname, f, trans r(thmname, Antecedents). This command abbreviates trans(thmname, r,, Antecedents)., Antecedents). trans true(thmname). This command abbreviates trans(thmname, t, true, []). trans true(thmname, Antecedents). This command abbreviates trans(thmname, t, true, Antecedents). h trans(hypname, ThmName, Direction, Goal, Antecedents). This command is similar to trans/4 except that the transformation is applied to the hypothesis labelled HypName. Also, <=> is used instead of the current equivalence when testing for compatibility of equivalences. h trans(hypname, ThmName). This command abbreviates h trans(hypname, ThmName, f,, []). h trans r(hypname, ThmName). This command abbreviates h trans(hypname, ThmName, r,, []). h trans(hypname, ThmName, Antecedents). This command abbreviates h trans(hypname, ThmName, f, h trans r(hypname, ThmName, Antecedents). This command abbreviates h trans(hypname, ThmName, r,, Antecedents)., Antecedents). lemma(term, Equ, Goal). 24

26 This command is used to start a proof of a lemma within an existing proof window W. Its top-level window has Term as its focus and all the hypotheses in window W as hypotheses. Goal is the goal of the window, and Equ is the equivalence. Demo3.3 can now be used to transform Term to Term1. When this lemma proof is closed, the user will return to window W of the main proof, and (Term Equ Term1) will be added to the hypotheses of this window. As with closing proofs, a single application of simplication is made to the lemma. lemma(term). The same as lemma(term, <=>, true). lemma(term, Equ, Goal, NFI). Similar to lemma(term, Equ, Goal) but includes a list of not free in constraints. lemma(term, NFI). The same as lemma(term, <=>, true, NFI). conjecture(term). The command conjecture(term) adds the Term as a new hypothesis in the current window. Demo3.3 will automatically add a corresponding hypothesis into the parent window on closing so as to keep all transformations sound. conjecture(term, NFI). The same as conjecture(term) but includes extra not free in constraints. change focus(term). Change the focus to Term. This will succeed only if one of the hypotheses is false. inst var(var, Term). Instantiate the variable Var to Term. is newvarlist(newvars). NewVars is the collection of variables generated during the proof. promote var(var). Promote a new variable Var to the status of a proof variable. demote var(var). Demote a proof variable Var to the status of a new variable. match terms(term1, Term2). Unify Term1 and Term2 with all the new variables thawed. Checks are made to ensure that the resultant term is a sentence of the current theory's language. ObVar not free in Term. Add the not free in constraint. 25

27 take theorem(name). Take a theorem or axiom labelled Name as a new hypothesis in the current window. take theorem(name, Template). Take a theorem or axiom labelled Name (after unication with Template) as a new hypothesis in the current window. take theorem(name, NewHyp, N). Introduces a new hypothesis NewHyp with number N (generated by Demo3.3), which is an instance of the theorem or axiom labelled Name. delete hyp(number). Deletes the hypothesis or lemma whose number is Number. is focus(term). Term is the current focus. is hyp(n, Term). Term is the current hypothesis numbered N. This command is typically used to extract a given hypothesis numbered N or to nd the number of a hypothesis that matches the pattern given in Term. is theorem(name, Theorem). Name is the name of the theorem that matches Theorem. This command is typically used to extract the name of a theorem that matches the pattern given in Theorem. is goal(goal). Goal is the current goal. is cw(current Window). Current Window is the current window level. is equ(equivalence). Equivalence is the current equivalence. set goal(goal). Replaces the current goal by Goal. number of hyps(nhyps). NHyps is the number of hypotheses in the current window. number of lemmas(nlemmas). NLemmas is the number of lemmas in the current window. number of conjectures(nconjs). NConjs is the number of conjectures in the current window. reportwindow. Display the current window. 26

28 12 The Default Proof Tactic The tactic sys tactic/0 is a low-level interactive tactic that manages the proof when the prove command is used. It gives users direct access to most of the low level commands used in the construction of proofs. This tactic is a recursive interpreter that creates a choicepoint for each command, thus allowing the user to backtrack over the previous commands using the undo command. There are additional commands that aid in the management of choicepoints and so allow users to backtrack over several commands. The command mark/1 allows users to create and mark choicepoints to aid the user in marking positions in a proof for large scale backtracking. The argument to mark is an atom used to label the choicepoint. The system automatically marks each choicepoint created by openwin commands with the window number to further aid the user in backtracking. The user can remove all choicepoints from a marked choicepoint, M, with the command commit(m). If this command is followed by undo the proof will fail past the committed point. The tactic takes the view that, when a window is closed, all the choicepoints generated during the processing of the subwindow will be removed as the default. Users have a chance to override the default if the command immediately following closewin is either undo or no commit. In this situation undo will backtrack over the closewin command returning the user to the subwindow. The no commit command will leave all the choicepoints untouched. The list of marked choicepoints may be viewed with the command show marks. Writers of other tactics, particularly semi-automatic ones, are able to call sys tactic to commence an interaction at any point during the proof. The sys tactic command exit exits the recursive interpreter and returns control to the caller. 13 Creating New Theories 13.1 Vocabulary This interactive theorem prover supports theories whose expressions (terms, formulas) are the untyped expressions supported by Qu-Prolog. Later versions of Qu-Prolog are planned to support typed syntax also. These theories are called object theories, since their expressions are the objects which are manipulated by the interactive theorem prover. For a specic object theory, declarations determine the basic symbols (constants, functions, quantiers) which are available to construct expressions. Additional symbols may be introduced by denitions. Object theory variables are common to all object theories. This vocabulary is completely untyped; in particular there is no built-in syntactic distinction between terms and formulas of object theories. The interactive theorem prover syntax for working with object theories is a meta level syntax which allows, for example, a single meta level expression to describe an innite 27

29 scheme of object expressions (see [2]) The Demo3.3 Database The structure of theories in Demo3.3 is a tree structure similar to the UNIX directory system. Each theory directory may contain theory subdirectories. In this tree structured database, each theory is an extension theory of its parent and has access to all the information relating to its parent; and so on, transitively. The database uses a naming convention similar to that of UNIX, with the root of the tree named /. The system is supplied with a collection of theories which includes a rst order logic theory with equality (fol) sitting immediately below the root of the tree. Its full position name is /fol. All examples in this section come from the construction of the root and rst order logic theories. Every theory includes a fact declaring the theory to be either open or closed. Also the following collections of facts are contained in every theory. (sub)theory names; primitive quantiers; primitive functions; dened quantiers; dened functions; window opening rules; hypothesis splitting rules; simplication rules; axioms; theorems; aliases; tactics; equivalence relation information. Each window in a proof contains the level number of the window, the focus, goal, equivalence, and a numbered list of lemmas, hypotheses and conjectures Setting Up A New Theory To set up a new theory, the user supplies facts from the collections listed above. We discuss this process under the following headings: Creating a theory. Choosing a vocabulary. Loading axioms. Loading opening rules. Generating simplication rules and splitting rules. 28