@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ NAME: EVES/NEVER KEYWORDS: automatic induction, decision procedures, forward rules, interactive theorem proving, program verification, rewrite rules, proof logging, proof checking, formal methods, Verdi, Z, high integrity applications. DESCRIPTION: SEMANTICS: EVES uses untyped first-order logic, without the conventional distinction between terms and formulas. The axioms of Zermello-Fraenkel set theory are included in the EVES "initial theory." EVES has a mechanism for defining new functions. Every declaration must be proved to define a conservative extension of the theory in which it appears. There is also a library system that allows theories to be combined. Every axiomatic theory in the library must have a corresponding "model" that establishes its soundness. EVES also allows for procedure definitions. Procedures are specified using pre and post assertions, and are proved by proving certain "proof obligations" determined from the procedure definition and its annotations. The semantics of Verdi follows the usual first-order model theory, with simple extensions to handlle definitions and libraries. The semantics of procedures is defined by a denotational definition that is fully integrated with the model theory for the rest of Verdi. DEDUCTIVE MACHINERY: Proofs are done in the system using commands that perform equivalent-preserving transformations on the current formula. The workhorse of the theorem prover, the reducer, is invoked using the SIMPLIFY, REWRITE, or REDUCE command. The SIMPLIFY command instructs the reducer to attempt to replace the current formula with an equivalent formula which the reducer considers to be simpler. The reducer performs propositional simplification (propositional tautologies are always detected), reasons about equalities, inequalities, integers, and quantifiers, as well as applying forward rules (rules that are specifically introduced to extend the simplifier). The REWRITE command causes the reducer to apply rewrite rules in addition to the above. The REDUCE command causes the reducer to expand function applications using their definitions as well as performing everything that is done under REWRITE. (Heuristics gneralized from those developed by Boyer-Moore are used for recursive functions to prevent indefinite expansion of function applications.) The system provides the user with commands to perform simpler inferences (such as explicit instantiation of a quantified variable) as well as a command to perform Boyer-Moore-style automatic induction. In addition, command modifiers may be used to allow the user to have finer control over the effects of a command (they are intended mainly for reduction commands). DYNAMICS: Theories are built up incrementally by entering declarations into the system. There may be a proof obligation associated with a declaration, e.g., for a recursive function declaration, the user must show that the recursion terminates, and for an axiom declaration, the user must show that the body of the axiom declaration is in fact a theorem. The proof obligation may be worked on immediately after the declaration is entered, or the user may proceed with other declarations and come back to the proof later. However, to prevent circularity of reasoning, the proof of a declaration may only use axioms that were introduced by earlier declarations. To perform a proof, commands described in the previous section may be used. In addition, the user may undo the effects of proof commands as well as declarations (the undoing is strictly last-in-first-out). PERSISTENCE: The system retains partial and complete proofs of declarations. In addition the current theory may be saved as a library unit. The kind of library unit that can be loaded into the system is called a spec unit. For a spec unit, proofs do not have to be completed and are in fact discarded. Information hiding is supported by allowing stub declarations in a spec unit. Proofs must be completed and are saved in the corresponding model unit, and a consistency check is performed between the spec unit and the model unit. An incomplete theory development may be saved as a freeze unit. For a freeze unit, proofs do not have to be completed but partial and complete proofs are saved. The user may later thaw the unit which causes the state of the development to be completely restored (including the partial and complete proofs). Saved theories may be undone by deleting library units. The system keeps track of the dependencies among library units since the deletion of a unit may require the deletion of other units that depend on the deleted unit. CONTACT PERSONS: Dan Craigen ORA Canada Suite 100 267 Richmond Rd., Ottawa, Ontario K1Z 6X3 CANADA dan@ora.on.ca USER GROUP To this point, EVES has only been distributed to a small number of sites. Various establishments (government and academic) have been using EVES on experimental applications. The U.S Naval Research Labs and the U.K. Royal Signals and Radar Establishment (now DRA), used EVES technology in security-critical applications. Currently, EVES is being used (by ORA Canada and CGI), under a contract to the Canadian Atomic Energy Control Board, for the development of a (pedagogical) boiler control and shutdown system. EVES is being used by various universities, not only for R&D, but for teaching formal methods. In the Fall/Winter'95, we intend to make EVES and Z/EVES (see below) available over the Internet. PRAGMATICS The theorem prover combines the power of its automatic capabilities (embodied in the reduction commands) with the ability of the user to have fine-grained control (using command modifiers and low level inference commands). We view the unique attribes of EVES as being the combination of (i) an expressive formal specification and programming language, (ii) practical automated deduction support, (iii) mathematical soundness, (iv) rigorous tool development, and (v) availability on workstations and PCs. As per weaknesses, the main weaknesses are that EVES is an isolated tool and Verdi is certainly not a mainstream development language. As described below, our current work on developing a Z front-end to EVES is meant to ease technology transfer and to provide a unique integration of European and North American capabilities. DOCUMENTATION An annotated bibliography of EVES reports is available at our Web site (http://www.ora.on.ca/). Most of our reports and publications are available in postscript or dvi formats. Also available at the Web site, are five introductory examples on how EVES was used across various computing science areas, including computer-security, hardware verification, and ring theory. APPLICATIONS: During 1995-7 a series of software engineering and critical systems applications are either planned or underway. See our Web site (http://www.ora.on.ca/) for updated information. EXTENSIONS/ENHANCEMENTS: Work is underway to integrate the Z notation with EVES. Such an integration brings together state-of-the-art formal methods techniques from Europe and North America. In Z/EVES, Z is extended to included paragraphs for stating theorems and for performing proofs. Z/EVES will be available in the Fall/Winter 1995. Work is also progressing on developing an independent proof checking capability, through which the proofs discovered by EVES/NEVER are validated. Work was recently completed in defining the Verdi inference rules and for logging, in terms of those rules, the proofs discovered using EVES/NEVER. During 1996/7, ORA Canada will be involved in a number of applications involving EVES. Other work at developing a general formal methods environment are also progressing. RESOURCE REQUIREMENTS: The system is implemented in a disciplined subset of Common-Lisp. It currently runs under KCL (Kyoto Common Lisp), AKCL (Austin Kyoto Common Lisp), and Allegro Common Lisp on Sun workstations. On a Sun-3 workstation, 16Mb RAM or more is recommended. On sparcstations, 32Mb RAM is recommended. The system is also available on PCs (running DOS). For a PC, one should have, at least, a 486 processor and 8Mb RAM. WHERE-TO-GET-IT: EVES ORA Canada Suite 100 267 Richmond Rd., Ottawa, Ontario K1Z 6X3 CANADA ora@ora.on.ca [Info source, date ] Dan Craigen, August 1995 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%