Results 11  20
of
29
Communicating and trusting proofs: The case for broad spectrum proof certificates. Available from author’s website
, 2011
"... Abstract. Proofs, both formal and informal, are documents that are intended to circulate within societies of humans and machines distributed across time and space in order to provide trust. Such trust might lead one mathematician to accept a certain statement as true or it might help convince a cons ..."
Abstract

Cited by 3 (2 self)
 Add to MetaCart
(Show Context)
Abstract. Proofs, both formal and informal, are documents that are intended to circulate within societies of humans and machines distributed across time and space in order to provide trust. Such trust might lead one mathematician to accept a certain statement as true or it might help convince a consumer that a certain software system is secure. Using this general characterization of proofs, we examine a range of perspectives about proofs and their roles within mathematics and computer science that often appear contradictory. We then consider the possibility of defining a broad spectrum proof certificate format that is intended as a universal language for communicating formal proofs among computational logic systems. We identify four desiderata for such proof certificates: they must be (i) checkable by simple proof checkers, (ii) flexible enough that existing provers can conveniently produce such certificates from their internal evidence of proof, (iii) directly related to proof formalisms used within the structural proof theory literature, and (iv) permit certificates to elide some proof information with the expectation that a proof checker can reconstruct the missing information using bounded and structured proof search. We consider various consequences of these desiderata, including how they can mix computation and deduction and what they mean for the establishment of marketplaces and libraries of proofs. In a companion paper we proposal a specific framework for achieving all four of these desiderata. 1
Representing Nuprl Proof Objects in ACL2: toward a proof checker for Nuprl
, 2002
"... Stipulations on the correctness of proofs produced in a formal system include that the axioms and proof rules are the intended ones and that the proof has been properly constructed (i.e. it is a correct instantiation of the axioms and proof rules.) In software implementations of formal systems, ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
Stipulations on the correctness of proofs produced in a formal system include that the axioms and proof rules are the intended ones and that the proof has been properly constructed (i.e. it is a correct instantiation of the axioms and proof rules.) In software implementations of formal systems, correctness additionally depends both on the correctness of the program implementing the system and on the hardware it is executed on. Once we implement a system in software and execute it on a computer, we have moved from the abstract world of mathematics into the physical world; absolute correctness can never be achieved here. We can only strive to increase our confidence that the system is producing correct results. In the process of creating proofs, foundational systems like Nuprl construct formal proof objects. These proof objects can be independently checked to verify they are correct instantiations of the axioms and proof rules thereby increasing confidence that the putative proof object faithfully represents a proof in the formal system. Note that this kind of proof checking does not address issues related to the models of the proof system, it simply provides more evidence that a proof has been correctly constructed. The Nuprl implementation consists of more than 100K lines of Lisp and tactic code implemented in ML. Although parts of the system consist of legacy codes going as far back as the late 1970's (Edinburgh LCF), and even though the Nuprl system has been extensively used since 1986 in formalizing a significant body of mathematics, the chances that the implementation is correct are slim. Verifying the system itself is infeasible, instead we propose to increase confidence in Nuprl proofs by independently checking them in ACL2. In this paper...
Encoding the HOL Light logic in Coq
"... Abstract. We show how to encode the HOL Light logic in Coq. This makes an automatic translation of HOL proofs to Coq possible. The translated HOL proofs refer to translated HOL data types but those data types can be related to the standard Coq data types, making the HOL results useful for Coq. The t ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
(Show Context)
Abstract. We show how to encode the HOL Light logic in Coq. This makes an automatic translation of HOL proofs to Coq possible. The translated HOL proofs refer to translated HOL data types but those data types can be related to the standard Coq data types, making the HOL results useful for Coq. The translated proofs have a size linear in the time HOL takes to process the original proofs. However the constant of linearity is large. The approach described in this paper is similar to the method of Pavel Naumov, MarkOliver Stehr and José Mesequer for translating HOL98 proofs to Nuprl [10].
Received (Day Month Year)
"... Automated Theorem Proving (ATP) systems are complex pieces of software, and thus may have bugs that make them unsound. In order to guard against unsoundness, the derivations output by an ATP system may be semantically verified by trusted ATP systems that check the required semantic properties of eac ..."
Abstract
 Add to MetaCart
Automated Theorem Proving (ATP) systems are complex pieces of software, and thus may have bugs that make them unsound. In order to guard against unsoundness, the derivations output by an ATP system may be semantically verified by trusted ATP systems that check the required semantic properties of each inference step. Such verification needs to be augmented by structural verification that checks that inferences have been used correctly in the context of the overall derivation. This paper describes techniques for semantic verification of derivations, and reports on their implementation and testing in the GDV verifier.
Checking Nuprl Proofs in ACL2: A Progress Report
"... Abstract. Stipulations on the correctness of proofs produced in a formal system include that the axioms and proof rules are the intended ones and that the proof has been properly constructed (i.e. it is a correct instantiation of the axioms and proof rules.) In software implementations of formal sys ..."
Abstract
 Add to MetaCart
Abstract. Stipulations on the correctness of proofs produced in a formal system include that the axioms and proof rules are the intended ones and that the proof has been properly constructed (i.e. it is a correct instantiation of the axioms and proof rules.) In software implementations of formal systems, correctness additionally depends both on the correctness of the program implementing the system and on the hardware it is executed on. Once we implement a system in software and execute it on a computer, we have moved from the abstract world of mathematics into the physical world; absolute correctness can never be achieved here. We can only strive to increase our confidence that the system is producing correct results. In the process of creating proofs, foundational systems like Nuprl construct formal proof objects. These proof objects can be independently checked to verify they are correct instantiations of the axioms and proof rules thereby increasing confidence that the putative proof object faithfully represents a proof in the formal system. Note that this kind of proof checking does not address issues related to the models of the proof system, it simply provides more evidence that a proof has been correctly constructed. The Nuprl implementation consists of more than 100K lines of LISP and tactic code implemented in ML. Although parts of the system consist of legacy codes going as far back as the late 1970’s (Edinburgh LCF), and even though the Nuprl system has been extensively used since 1986 in formalizing a significant body of mathematics, the chances that the implementation is correct are slim. Verifying the system itself is infeasible, instead we propose to increase confidence in Nuprl proofs by independently checking them in ACL2. In this paper we describe: (i.) the ACL2 formalization of Nuprl terms, proof rules, and proofs, (ii.) first steps in the implementation of a proof checker, and (iii.) discuss issues related to the future of the project. 1
Author manuscript, published in "39th ACM SIGPLANSIGACT Symposium on Principles of Programming Languages POPL'12 (2012)" SelfCertification Bootstrapping Certified Typecheckers in F ⋆ with Coq
, 2011
"... Wellestablished dependentlytyped languages like Agda and Coq provide reliable ways to build and check formal proofs. Several other dependentlytyped languages such as Aura, ATS, Cayenne, Epigram, F ⋆ , F7, Fine, Guru, PCML5, and Ur also explore reliable ways to develop and verify programs. All the ..."
Abstract
 Add to MetaCart
(Show Context)
Wellestablished dependentlytyped languages like Agda and Coq provide reliable ways to build and check formal proofs. Several other dependentlytyped languages such as Aura, ATS, Cayenne, Epigram, F ⋆ , F7, Fine, Guru, PCML5, and Ur also explore reliable ways to develop and verify programs. All these languages shine in their own regard, but their implementations do not themselves enjoy the degree of safety provided by machinechecked verification. We propose a general technique called selfcertification that allows a typechecker for a suitably expressive language to be certified for correctness. We have implemented this technique for F ⋆ , a dependently typed language on the.NET platform. Selfcertification involves implementing a typechecker for F ⋆ in F ⋆ , while using all the conveniences F ⋆ provides for the compilerwriter (e.g., partiality, effects, implicit conversions, proof automation, libraries). This
Linear Type Checking
"... but ag it to indicate that it may not be exact, but that some of these linear hypotheses may be absorbed if necessary. In other words, in the judgment any of the remaining hypotheses in O need not be consumed in the other branches of the typing derivation. On the other hand, the judgment ; I n O ` ..."
Abstract
 Add to MetaCart
but ag it to indicate that it may not be exact, but that some of these linear hypotheses may be absorbed if necessary. In other words, in the judgment any of the remaining hypotheses in O need not be consumed in the other branches of the typing derivation. On the other hand, the judgment ; I n O ` 0 M : A indicates the M uses exactly the variables in I O . When we think of the judgment ; I n O ` i M : A as describing an algorithm, we think of , I and M as given, and O and the slack indicator i as part of the result of the computation. The type A may or may not be givenin one case it is synthesized, in the other case checked. This re nes our view as computation being described as the bottomup construction of a derivation to include parts of the judgment in dierent roles (as input, output, or bidirectional components). In logic programming, which is based on the notion of computationasproofsearch, these roles of the syntactic constituents of a judgment are called