No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Reasoning about ACL2 file input
Abstract
We introduce the logical story behind file input in ACL2 and discuss the types of theorems that can be proven about file-reading operations. We develop a low level library for reasoning about the primitive input routines. We then develop a representation for Unicode text, and implement efficient functions to translate our representation to and from the UTF-8 encoding scheme. We introduce an efficient function to read UTF-8-encoded files, and prove that when files are well formed, the function produces valid Unicode text which corresponds to the contents of the file.We find exhaustive testing to be a useful technique for proving many theorems in this work. We show how ACL2 can be directed to prove a theorem by exhaustive testing.
... Davis reported on proofs about file I/O in ACL2 [6], which uses an explicit state-passing style and disallows non-termination. Dracula allows users to write interactive graphical programs without monads or state passing, and can express both nonterminating interactions and provable liveness properties, e.g., termination. ...
Modern software applications come with interactive graph-ical displays. In the past, verification efforts for such pro-grams have usually ignored the I/O aspects of programs and focused instead on their core functionality. This approach leaves open the question of how errors in the interactive part of the program can affect its overall functionality. In this paper we present an extension of Dracula (the ACL2 development environment for DrScheme) with a simple graphical framework. With Dracula we can automat-ically prove theorems about interactive graphical programs, guaranteeing their complete behavior. We have successfully verified theorems about a number of interactive programs with Dracula; we have also successfully used Dracula as a motivational tool to introduce students to the world of automated theorem proving.
... Davis [8] used exhaustive testing to prove lemmas toward the correctness of UTF-8 processing functions . The most difficult proof carried out this way was a well-formedness and inversion property for four-byte UTF-8 sequences, which involved checking 2 32 cases. ...
Interactive theorem proving requires a lot of human guidance. Proving a
property involves (1) figuring out why it holds, then (2) coaxing the theorem
prover into believing it. Both steps can take a long time. We explain how to
use GL, a framework for proving finite ACL2 theorems with BDD- or SAT-based
reasoning. This approach makes it unnecessary to deeply understand why a
property is true, and automates the process of admitting it as a theorem. We
use GL at Centaur Technology to verify execution units for x86 integer, MMX,
SSE, and floating-point arithmetic.
This paper presents, we believe, the most comprehensive evidence of a theorem prover’s soundness to date. Our subject is the Milawa theorem prover. We present evidence of its soundness down to the machine code. Milawa is a theorem prover styled after NQTHM and ACL2. It is based on an idealised version of ACL2’s computational logic and provides the user with high-level tactics similar to ACL2’s. In contrast to NQTHM and ACL2, Milawa has a small kernel that is somewhat like an LCF-style system. We explain how the Milawa theorem prover is constructed as a sequence of reflective extensions from its kernel. The kernel establishes the soundness of these extensions during Milawa’s bootstrapping process. Going deeper, we explain how we have shown that the Milawa kernel is sound using the HOL4 theorem prover. In HOL4, we have formalized its logic, proved the logic sound, and proved that the source code for the Milawa kernel (1,700 lines of Lisp) faithfully implements this logic. Going even further, we have combined these results with the x86 machine-code level verification of the Lisp runtime Jitawa. Our top-level theorem states that Milawa can never claim to prove anything that is false when it is run on this Lisp runtime.
We give a useful set of unconditional rewrite rules for reasoning about record structures, which are essentially finite functions. The problem, then, is to define functions for which these rules are true and then prove the rules. We begin with a series of definitions that attempt to satisfy these rules but fall short for various reasons. Then we give two solutions, one of which generalizes to other finite structures. The definitions of our access and update functions are somewhat subtle, complex, and ineffecient, but they return the expected values and the theorems exported are elegant and efficient for automatic, unconditional rewriting.