Results 1 
6 of
6
A Comparison of PVS and Isabelle/HOL
 Theorem Proving in Higher Order Logics, number 1479 in Lect. Notes Comp. Sci
, 1998
"... . There is an overwhelming number of different proof tools available and it is hard to find the right one for a particular application. Manuals usually concentrate on the strong points of a proof tool, but to make a good choice, one should also know (1) which are the weak points and (2) whether the ..."
Abstract

Cited by 11 (3 self)
 Add to MetaCart
. There is an overwhelming number of different proof tools available and it is hard to find the right one for a particular application. Manuals usually concentrate on the strong points of a proof tool, but to make a good choice, one should also know (1) which are the weak points and (2) whether the proof tool is suited for the application in hand. This paper gives an initial impetus to a consumers' report on proof tools. The powerful higherorder logic proof tools PVS and Isabelle are compared with respect to several aspects: logic, specification language, prover, soundness, proof manager, user interface (and more). The paper concludes with a list of criteria for judging proof tools, it is applied to both PVS and Isabelle. 1 Introduction There is an overwhelming number of different proof tools available (e.g. in the Database of Existing Mechanised Reasoning Systems one can find references to over 60 proof tools [Dat]). All have particular applications that they are especially suited ...
Program Development Schemata as Derived Rules
, 2000
"... This paper makes several contributions towards a clarified view of schemabased program development. First, we propose that schemata can be understood, formalized, and used in a simple way: program development schemata are derived rules. We mean this in the standard sense of a derived rule of infere ..."
Abstract

Cited by 9 (2 self)
 Add to MetaCart
This paper makes several contributions towards a clarified view of schemabased program development. First, we propose that schemata can be understood, formalized, and used in a simple way: program development schemata are derived rules. We mean this in the standard sense of a derived rule of inference in logic. A schema like Figure i can be formulated as a rule stating that the conclusion follows from the premises defining F, G, and the applicability conditions. By deriving the rule in an axiomatic theory, we validate a semantic statement about it: the conclusion of the rule holds in every model where both the axioms of the theory and the premises of the rule are true. Hence, by selecting a language to work in we control which development schemata are formalizable, and by selecting a theory we determine which schemata are derivable
Synthesis of programs in computational logic
 PROGRAM DEVELOPMENT IN COMPUTATIONAL LOGIC
, 2004
"... Since the early days of programming and automated reasoning, researchers have developed methods for systematically constructing programs from their specifications. Especially the last decade has seen a flurry of activities including the advent of specialized conferences, such as LOPSTR, covering the ..."
Abstract

Cited by 8 (0 self)
 Add to MetaCart
Since the early days of programming and automated reasoning, researchers have developed methods for systematically constructing programs from their specifications. Especially the last decade has seen a flurry of activities including the advent of specialized conferences, such as LOPSTR, covering the synthesis of programs in computational logic. In this paper we analyze and compare three stateoftheart methods for synthesizing recursive programs in computational logic. The three approaches are constructive/deductive synthesis, schemaguided synthesis, and inductive synthesis. Our comparison is carried out in a systematic way where, for each approach, we describe the key ideas and synthesize a common running example. In doing so, we explore the synergies between the approaches, which we believe are necessary in order to achieve progress over the next decade in this field.
Modeling a Hardware Synthesis Methodology in Isabelle
 In Theorem Proving in Higher Order Logics (TPHOLs'96), volume 1125 of LNCS
, 1996
"... . Formal Synthesis is a methodology developed at Kent for combining circuit design and verification, where a circuit is constructed from a proof that it meets a given formal specification. We have reinterpreted this methodology in Isabelle's theory of higherorder logic so that circuits are incremen ..."
Abstract

Cited by 6 (4 self)
 Add to MetaCart
. Formal Synthesis is a methodology developed at Kent for combining circuit design and verification, where a circuit is constructed from a proof that it meets a given formal specification. We have reinterpreted this methodology in Isabelle's theory of higherorder logic so that circuits are incrementally built during proofs using higherorder resolution. Our interpretation simplifies and extends Formal Synthesis both conceptually and in implementation. It also supports integration of this development style with other proofbased synthesis methodologies and leads to techniques for developing new classes of circuits, e.g., recursive descriptions of parametric designs. Keywords: Hardware verification and synthesis, theorem proving, higherorder logic, higherorder unification. 1. Introduction Verification by formal proof is time intensive and this is a burden in bringing formal methods into software and hardware design. One approach to reducing the verification burden is to combine develop...
Tool Support for Logics of Programs
 Mathematical Methods in Program Development: Summer School Marktoberdorf 1996, NATO ASI Series F
, 1996
"... Proof tools must be well designed if they... ..."
Formalization of the Development Process
, 1998
"... Introduction 14.1.1 What is development? Software development encompasses many phases including requirements engineering, specification, design, implementation, verification or testing, and maintenance. In this chapter we concentrate on the intermediate tasks: the transition from requirements spec ..."
Abstract

Cited by 4 (3 self)
 Add to MetaCart
Introduction 14.1.1 What is development? Software development encompasses many phases including requirements engineering, specification, design, implementation, verification or testing, and maintenance. In this chapter we concentrate on the intermediate tasks: the transition from requirements specification to verified design and design optimization; in particular techniques for developing correct designs as opposed to ad hoc or a posteriori methods in which a postulated design is later verified or tested. We view software development as the composition of correctness preserving refinement steps. Hence, a development is meaningful relative to a notion of refinement and correctness. There are many such notions (e.g., Chapter 6), each defining a type of problem transformation or reduction. For example specification refinement from a specification SP to SP 0 through a refinement map ae might be defined as co