Results 1 
8 of
8
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 12 (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 7 (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.
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... ..."
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 inc ..."
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...
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
An integration of deductive retrieval into deductive synthesis
 In Proceedings of the 14th IEEE International Conference on Automated Software Engineering (ASE'99
, 1999
"... Deductive retrieval and deductive synthesis are two conceptually closely related software development methods which apply theorem proving techniques to support the construction of correct programs. In this paper, we describe an integration of both methods which combines their complementary benefits ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
Deductive retrieval and deductive synthesis are two conceptually closely related software development methods which apply theorem proving techniques to support the construction of correct programs. In this paper, we describe an integration of both methods which combines their complementary benefits and alleviates some of their drawbacks. The core of our integration is an algorithm which automatically extracts queries from the synthesis proof state and submits them to a specialized retrieval system. Retrieved components are then used to close open subgoals in the proof. We use a higherorder framework for synthesis in which higherorder metavariables are used to represent program fragments still to be synthesized. Hence, the introduction of a new metavariable is an attempt to synthesize a new fragment and so highlights a possible reuse step. This observation allows us to invoke retrieval only after a substantial change rather than at every proof step and prevents overloading the retrieval mechanism. Our integration raises the granularity level of synthesis by avoiding a substantial number of proof steps. It also provides a framework for adapting “nearmiss ” components in the case that an exact match cannot be retrieved. 1.
Logical Framework Based Program Development
, 1998
"... in the base theory. The use of a logical framework as opposed to, say, a theorem prover for firstorder logic, is important here, as this step requires formalizing and reasoning about rules as opposed to formulae. The rules formalized are designed to be adequate to simulate derivations of the targ ..."
Abstract
 Add to MetaCart
in the base theory. The use of a logical framework as opposed to, say, a theorem prover for firstorder logic, is important here, as this step requires formalizing and reasoning about rules as opposed to formulae. The rules formalized are designed to be adequate to simulate derivations of the target calculus. (3) We write tactics (programs that construct proofs) that help automate the application of proof rules. For example, by adopting ideas from [Bundy et al. 1991; Basin and Walsh 1996], in [Kraan et al. 1996] we completely automated the synthesis of many (albeit relatively simple) logic programs. This methodology is based on, and arose from, case studies including: unfold/fold style development for functional and logic programs; Deductive Tableaux style development of sorting programs [Ayari and Basin 1996]; synthesis of logic programs [Kraan et al. 1996]; transformation of logic programs using transformation template libraries [Ande