Results 11  20
of
20
Checking foundational proof certificates for firstorder logic
"... We present the design philosophy of a proof checker based on a notion of foundational proof certificates. This checker provides a semantics of proof evidence using recent advances in the theory of proofs for classical and intuitionistic logic. That semantics is then performed by a (higherorder) log ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
We present the design philosophy of a proof checker based on a notion of foundational proof certificates. This checker provides a semantics of proof evidence using recent advances in the theory of proofs for classical and intuitionistic logic. That semantics is then performed by a (higherorder) logic program: successful performance means that a formal proof of a theorem has been found. We describe how the λProlog programming language provides several features that help guarantee such a soundness claim. Some of these features (such as strong typing, abstract datatypes, and higherorder programming) were features of the ML programming language when it was first proposed as a proof checker for LCF. Other features of λProlog (such as support for bindings, substitution, and backtracking search) turn out to be equally important for describing and checking the proof evidence encoded in proof certificates. Since trusting our proof checker requires trusting a programming language implementation, we discuss various avenues for enhancing one’s trust of such a checker. 1
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
Chapter 6 Linear Calculus
"... roofs in intuitionistic propositional natural deduction and simplytyped terms. A related observation on proof in combinatory logic had been made previously by Curry [CF58]. A generalization of this observation to include quanti ers gives rise to the rich eld of type theory, which we will analyz ..."
Abstract
 Add to MetaCart
roofs in intuitionistic propositional natural deduction and simplytyped terms. A related observation on proof in combinatory logic had been made previously by Curry [CF58]. A generalization of this observation to include quanti ers gives rise to the rich eld of type theory, which we will analyze in Chapter ??. Here we study the basic correspondence, extended to the case of linear logic. A linear calculus of proof terms will be useful for us in various circumstances. First of all, it gives a compact and faithful representation of proofs as terms. Proof checking is reduced to typechecking in a calculus. For example, if we do not trust the implementation of our theorem prover, we can instrument it to generate proof terms which can be veri ed independently. In this scenario we are just exploiting that validity of proof terms is an analytic judgment. Secondly, the terms in the calculus provide the core of a functional language with an expressive type system, in which statemen
Chapter 6 Linear λCalculus
, 2001
"... proofs in intuitionistic propositional natural deduction and simplytyped #terms. A related observation on proof in combinatory logic had been made previously by Curry [CF58]. A generalization of this observation to include quantifiers gives rise to the rich field of type theory, which we will ana ..."
Abstract
 Add to MetaCart
proofs in intuitionistic propositional natural deduction and simplytyped #terms. A related observation on proof in combinatory logic had been made previously by Curry [CF58]. A generalization of this observation to include quantifiers gives rise to the rich field of type theory, which we will analyze in Chapter ??. Here we study the basic correspondence, extended to the case of linear logic. A linear #calculus of proof terms will be useful for us in various circumstances. First of all, it gives a compact and faithful representation of proofs as terms. Proof checking is reduced to typechecking in a #calculus. For example, if we do not trust the implementation of our theorem prover, we can instrument it to generate proof terms which can be verified independently. In this scenario we are just exploiting that validity of proof terms is an analytic judgment. Secondly, the terms in the #calculus provide the core of a functional language with an expressive type system, in which statem
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
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
Communicating and trusting proofs: The case for foundational proof certificates
"... It is well recognized that proofs serve two different goals. On one hand, they can serve the didactic purpose of explaining why a theorem holds: that is, a proof has a message that is meant to describe the “why ” behind a theorem. On the other hand, proofs can serve as certificates of validity. In t ..."
Abstract
 Add to MetaCart
It is well recognized that proofs serve two different goals. On one hand, they can serve the didactic purpose of explaining why a theorem holds: that is, a proof has a message that is meant to describe the “why ” behind a theorem. On the other hand, proofs can serve as certificates of validity. In this case, once a certificate
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
UITP 2010 Pollackinconsistency
"... For interactive theorem provers a very desirable property is consistency: it should not be possible to prove false theorems. However, this is not enough: it also should not be possible to think that a theorem that actually is false has been proved. More precisely: the user should be able to know wha ..."
Abstract
 Add to MetaCart
For interactive theorem provers a very desirable property is consistency: it should not be possible to prove false theorems. However, this is not enough: it also should not be possible to think that a theorem that actually is false has been proved. More precisely: the user should be able to know what it is that the interactive theorem prover is proving. To make these issues concrete we introduce the notion of Pollackconsistency. This property is related to a system being able to correctly parse formulas that it printed itself. In current systems it happens regularly that this fails. We argue that a good interactive theorem prover should be Pollackconsistent. We show with examples that many interactive theorem provers currently are not Pollackconsistent. Finally we describe a simple approach for making a system Pollackconsistent, which only consists of a small modification to the printing code of the system. The most intelligent creature in the universe is a rock. None would know it because they have lousy I/O. — quote from the Internet
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.
A SYNTHESIS OF THE PROCEDURAL AND DECLARATIVE STYLES OF INTERACTIVE THEOREM PROVING
"... Abstract. We propose a synthesis of the two proof styles of interactive theorem proving: the procedural style (where proofs are scripts of commands, like in Coq) and the declarative style (where proofs are texts in a controlled natural language, like in Isabelle/Isar). Our approach combines the adva ..."
Abstract
 Add to MetaCart
Abstract. We propose a synthesis of the two proof styles of interactive theorem proving: the procedural style (where proofs are scripts of commands, like in Coq) and the declarative style (where proofs are texts in a controlled natural language, like in Isabelle/Isar). Our approach combines the advantages of the declarative style – the possibility to write formal proofs like normal mathematical text – and the procedural style – strong automation and help with shaping the proofs, including determining the statements of intermediate steps. Our approach is new, and differs significantly from the ways in which the procedural and declarative proof styles have been combined before in the Isabelle, Ssreflect and Matita systems. Our approach is generic and can be implemented on top of any procedural interactive theorem prover, regardless of its architecture and logical foundations. To show the viability of our proposed approach, we fully implemented it as a proof interface called miz3, on top of the HOL Light interactive theorem prover. The declarative language that this interface uses is a slight variant of the language of the Mizar system, and can be used for any interactive theorem prover regardless of its logical foundations. The miz3 interface allows easy access to the full set of tactics and formal libraries of HOL Light, and as such has ‘industrial strength’. Our approach gives a way to automatically convert any procedural proof to a declarative counterpart, where the converted proof is similar in size to the original. As all declarative systems have essentially the same proof language, this gives a straightforward way to port proofs between interactive theorem provers. 1.