Results 1  10
of
28
Some lambda calculus and type theory formalized
 Journal of Automated Reasoning
, 1999
"... Abstract. We survey a substantial body of knowledge about lambda calculus and Pure Type Systems, formally developed in a constructive type theory using the LEGO proof system. On lambda calculus, we work up to an abstract, simplified, proof of standardization for beta reduction, that does not mention ..."
Abstract

Cited by 57 (7 self)
 Add to MetaCart
(Show Context)
Abstract. We survey a substantial body of knowledge about lambda calculus and Pure Type Systems, formally developed in a constructive type theory using the LEGO proof system. On lambda calculus, we work up to an abstract, simplified, proof of standardization for beta reduction, that does not mention redex positions or residuals. Then we outline the meta theory of Pure Type Systems, leading to the strengthening lemma. One novelty is our use of named variables for the formalization. Along the way we point out what we feel has been learned about general issues of formalizing mathematics, emphasizing the search for formal definitions that are convenient for formal proof and convincingly represent the intended informal concepts.
Hoare Logic and VDM: MachineChecked Soundness and Completeness Proofs
, 1998
"... Investigating soundness and completeness of verification calculi for imperative programming languages is a challenging task. Many incorrect results have been published in the past. We take advantage of the computeraided proof tool LEGO to interactively establish soundness and completeness of both H ..."
Abstract

Cited by 31 (1 self)
 Add to MetaCart
Investigating soundness and completeness of verification calculi for imperative programming languages is a challenging task. Many incorrect results have been published in the past. We take advantage of the computeraided proof tool LEGO to interactively establish soundness and completeness of both Hoare Logic and the operation decomposition rules of the Vienna Development Method (VDM) with respect to operational semantics. We deal with parameterless recursive procedures and local variables in the context of total correctness. As a case study, we use LEGO to verify the correctness of Quicksort in Hoare Logic. As our main contribution, we illuminate the rle of auxiliary variables in Hoare Logic. They are required to relate the value of program variables in the final state with the value of program variables in the initial state. In our formalisation, we reflect their purpose by interpreting assertions as relations on states and a domain of auxiliary variables. Furthermore, we propose a new structural rule for adjusting auxiliary variables when strengthening preconditions and weakening postconditions. This rule is stronger than all previously suggested structural rules, including rules of adaptation. With the new treatment, we are able to show that, contrary to common belief, Hoare Logic subsumes VDM in that every derivation in VDM can be naturally embedded in Hoare Logic. Moreover, we establish completeness results uniformly as corollaries of Most General Formula theorems which remove the need to reason about arbitrary assertions.
Foundational proof checkers with small witnesses
, 2003
"... Proof checkers for proofcarrying code (and similar) systems can suer from two problems: huge proof witnesses and untrustworthy proof rules. No previous design has addressed both of these problems simultaneously. We show the theory, design, and implementation of a proofchecker that permits small p ..."
Abstract

Cited by 26 (6 self)
 Add to MetaCart
Proof checkers for proofcarrying code (and similar) systems can suer from two problems: huge proof witnesses and untrustworthy proof rules. No previous design has addressed both of these problems simultaneously. We show the theory, design, and implementation of a proofchecker that permits small proof witnesses and machinecheckable proofs of the soundness of the system. 1.
Searching Constant Width Mazes Captures the AC° Hierarchy
 In Proceedings of the 15th Annual Symposium on Theoretical Aspects of Computer Science
, 1997
"... We show that searching a width /' maze is complete for II, i.e., for the /"th level of the AC hierarchy. Equivalently, stconnectivity for width /' grid graphs is complete for II. As an application, we show that there is a data structure solving dynamic stconnectivity for constan ..."
Abstract

Cited by 26 (5 self)
 Add to MetaCart
We show that searching a width /' maze is complete for II, i.e., for the /"th level of the AC hierarchy. Equivalently, stconnectivity for width /' grid graphs is complete for II. As an application, we show that there is a data structure solving dynamic stconnectivity for constant width grid graphs with time bound O (log log n) per operation on a random access machine. The dynamic algorithm is derived from the parallel one in an indirect way using algebraic tools.
Relational Reasoning about Contexts
 HIGHER ORDER OPERATIONAL TECHNIQUES IN SEMANTICS, PUBLICATIONS OF THE NEWTON INSTITUTE
, 1998
"... ..."
Towards Selfverification of HOL Light
 In International Joint Conference on Automated Reasoning
, 2006
"... Abstract. The HOL Light prover is based on a logical kernel consisting of about 400 lines of mostly functional OCaml, whose complete formal verification seems to be quite feasible. We would like to formally verify (i) that the abstract HOL logic is indeed correct, and (ii) that the OCaml code does c ..."
Abstract

Cited by 19 (0 self)
 Add to MetaCart
(Show Context)
Abstract. The HOL Light prover is based on a logical kernel consisting of about 400 lines of mostly functional OCaml, whose complete formal verification seems to be quite feasible. We would like to formally verify (i) that the abstract HOL logic is indeed correct, and (ii) that the OCaml code does correctly implement this logic. We have performed a full verification of an imperfect but quite detailed model of the basic HOL Light core, without definitional mechanisms, and this verification is entirely conducted with respect to a settheoretic semantics within HOL Light itself. We will duly explain why the obvious logical and pragmatic difficulties do not vitiate this approach, even though it looks impossible or useless at first sight. Extension to include definitional mechanisms seems straightforward enough, and the results so far allay most of our practical worries. 1 Introduction: quis custodiet ipsos custodes? Mathematical proofs are subjected to peer review before publication, but there
Selfcertification: Bootstrapping certified typecheckers in F* with Coq
 In POPL
, 2012
"... 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

Cited by 5 (3 self)
 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 typechecker is given a specification (in F ⋆ ) strong enough to ensure that it computes valid typing derivations. We obtain a typing derivation for the core typechecker by running it on itself, and we export it to Coq as a typederivation certificate. By typechecking this derivation (in Coq) and applying the F ⋆ metatheory (also mechanized in Coq), we conclude that our type checker is correct. Once certified in this manner, the F ⋆ typechecker is emancipated from Coq. Selfcertification leads to an efficient certification scheme—we no longer depend on verifying certificates in Coq—as well as a more broadly applicable one. For instance, the selfcertified F ⋆ checker is suitable for use in adversarial settings where Coq is not intended for use, such as runtime certification of mobile code.
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 2 (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...
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 2 (2 self)
 Add to MetaCart
(Show Context)
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