Results 1 
5 of
5
Formal mathematics for verifiably correct program synthesis
 Journal of the IGPL
, 1996
"... We describe a formalization of the metamathematics of programming in a higherorder logical calculus as a means to create verifiably correct implementations of program synthesis tools. Using reflected notions of programming concepts we can specify the actions of synthesis methods within the object ..."
Abstract

Cited by 8 (5 self)
 Add to MetaCart
We describe a formalization of the metamathematics of programming in a higherorder logical calculus as a means to create verifiably correct implementations of program synthesis tools. Using reflected notions of programming concepts we can specify the actions of synthesis methods within the object language of the calculus and prove formal theorems about their behavior. The theorems serve as derived inference rules implementing the kernel of these methods in a flexible, safe, efficient and comprehensible way. We demonstrate the advantages of using formal mathematics in support of program development systems through an example in which we formalize a strategy for deriving global search algorithms from formal specifications.
On Extensibility of Proof Checkers
 in Dybjer, Nordstrom and Smith (eds), Types for Proofs and Programs: International Workshop TYPES'94, Bastad
, 1995
"... This paper is about mechanical checking of formal mathematics. Given some formal system, we want to construct derivations in that system, or check the correctness of putative derivations; our job is not to ascertain truth (that is the job of the designer of our formal system), but only proof. Howeve ..."
Abstract

Cited by 6 (2 self)
 Add to MetaCart
This paper is about mechanical checking of formal mathematics. Given some formal system, we want to construct derivations in that system, or check the correctness of putative derivations; our job is not to ascertain truth (that is the job of the designer of our formal system), but only proof. However, we are quite rigid about this: only a derivation in our given formal system will do; nothing else counts as evidence! Thus it is not a collection of judgements (provability), or a consequence relation [Avr91] (derivability) we are interested in, but the derivations themselves; the formal system used to present a logic is important. This viewpoint seems forced on us by our intention to actually do formal mathematics. There is still a question, however, revolving around whether we insist on objects that are immediately recognisable as proofs (direct proofs), or will accept some metanotations that only compute to proofs (indirect proofs). For example, we informally refer to previously proved results, lemmas and theorems, without actually inserting the texts of their proofs in our argument. Such an argument could be made into a direct proof by replacing all references to previous results by their direct proofs, so it might be accepted as a kind of indirect proof. In fact, even for very simple formal systems, such an indirect proof may compute to a very much bigger direct proof, and if we will only accept a fully expanded direct proof (in a mechanical proof checker for example), we will not be able to do much mathematics. It is well known that this notion of referring to previous results can be internalized in a logic as a cut rule, or Modus Ponens. In a logic containing a cut rule, proofs containing cuts are considered direct proofs, and can be directly accepted by a proof ch...
A costeffective foundational certified code system
, 2005
"... Certified code systems enable untrusted programs to be proven safe to execute in a machine–checkable manner. Recent work has focused on building foundational certified code systems, where safety is defined relative to a concrete machine architecture. We wish to build a cost–effective system, with pr ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
Certified code systems enable untrusted programs to be proven safe to execute in a machine–checkable manner. Recent work has focused on building foundational certified code systems, where safety is defined relative to a concrete machine architecture. We wish to build a cost–effective system, with practicality along two dimensions — the intellectual effort to engineer the proofs, and the resource usage by the machine in verifying these proofs. Thus, we factor the proof that a particular program is safe to execute into two parts, a generic part and a program–specific part. These parts are linked by a mediating logic, typically a type system, which we call the safety condition. Consequently, we must prove that all programs that satisfy this condition are safe to execute, and then, we prove that the particular program satisfies this safety condition. Moreover, each of these proofs must be done in a cost–effective manner. In previous work, we have described a machine–checkable proof for the first part, based on defining an operational semantics in LF and using the Twelf metalogic. For the second part, experience has shown that proof terms for a reasonable logic, or type system, are too big to generate, send across the network, and check. We wish to check adherence to the safety condition by an untrusted functional program. It remains to prove (in a machine–checkable manner) that the program implements the logic specified in a LF signature. We propose to accomplish this by static typechecking. We have designed an expressive type system using dependent refinements for this purpose. 1
A Dependently Typed Programming Language, with applications to Foundational Certified Code Systems
, 2009
"... Certified code systems enable trust to be generated in untrusted pieces of code. This is done by requiring that a machine–verifiable certificate be packaged with code, which can then be proved safe independently. Safety is defined with respect to a defined safety policy. Recent work has focused on “ ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
Certified code systems enable trust to be generated in untrusted pieces of code. This is done by requiring that a machine–verifiable certificate be packaged with code, which can then be proved safe independently. Safety is defined with respect to a defined safety policy. Recent work has focused on “foundational certified code systems”, which define the safety policy as execution on a concrete machine architecture. This makes the safety guarantees of the system more concrete relative to previous systems. There are two advantages. One, we gain in flexibility since the proof producers can use different assumptions and techniques. Two, the parts of the system that must be trusted become substantially simpler. This work describes our design of a practical foundational certified code system. Foundational systems have new proof obligations, for which we need different proof techniques and verification environments. In common with other such systems, we use an intermediate formal system such as a type system to isolate a group of programs. There are then two proof obligations. A program– specific proof verifies that the program belongs to the group so defined. This is the type checking problem. A generic safety proof says that all programs belonging to the group is safe to execute on the concrete machine. For a type system this is the type safety property.