Results 1 
5 of
5
Logic Programming in the LF Logical Framework
, 1991
"... this paper we describe Elf, a metalanguage intended for environments dealing with deductive systems represented in LF. While this paper is intended to include a full description of the Elf core language, we only state, but do not prove here the most important theorems regarding the basic building b ..."
Abstract

Cited by 175 (50 self)
 Add to MetaCart
this paper we describe Elf, a metalanguage intended for environments dealing with deductive systems represented in LF. While this paper is intended to include a full description of the Elf core language, we only state, but do not prove here the most important theorems regarding the basic building blocks of Elf. These proofs are left to a future paper. A preliminary account of Elf can be found in [26]. The range of applications of Elf includes theorem proving and proof transformation in various logics, definition and execution of structured operational and natural semantics for programming languages, type checking and type inference, etc. The basic idea behind Elf is to unify logic definition (in the style of LF) with logic programming (in the style of Prolog, see [22, 24]). It achieves this unification by giving types an operational interpretation, much the same way that Prolog gives certain formulas (Hornclauses) an operational interpretation. An alternative approach to logic programming in LF has been developed independently by Pym [28]. Here are some of the salient characteristics of our unified approach to logic definition and metaprogramming. First of all, the Elf search process automatically constructs terms that can represent objectlogic proofs, and thus a program need not construct them explicitly. This is in contrast to logic programming languages where executing a logic program corresponds to theorem proving in a metalogic, but a metaproof is never constructed or used and it is solely the programmer's responsibility to construct objectlogic proofs where they are needed. Secondly, the partial correctness of many metaprograms with respect to a given logic can be expressed and proved by Elf itself (see the example in Section 5). This creates the possibilit...
Dynamics in ML
, 1993
"... Objects with dynamic types allow the integration of operations that essentially require runtime typechecking into staticallytyped languages. This article presents two extensions of the ML language with dynamics, based on our work on the CAML implementation of ML, and discusses their usefulness. ..."
Abstract

Cited by 56 (0 self)
 Add to MetaCart
Objects with dynamic types allow the integration of operations that essentially require runtime typechecking into staticallytyped languages. This article presents two extensions of the ML language with dynamics, based on our work on the CAML implementation of ML, and discusses their usefulness. The main novelty of this work is the combination of dynamics with polymorphism.
Verifying programs in the Calculus of Inductive Constructions
, 1997
"... . This paper deals with a particular approach to the verification of functional programs. A specification of a program can be represented by a logical formula [Con86, NPS90]. In a constructive framework, developing a program then corresponds to proving this formula. Given a specification and a progr ..."
Abstract

Cited by 6 (0 self)
 Add to MetaCart
. This paper deals with a particular approach to the verification of functional programs. A specification of a program can be represented by a logical formula [Con86, NPS90]. In a constructive framework, developing a program then corresponds to proving this formula. Given a specification and a program, we focus on reconstructing a proof of the specification whose algorithmic contents corresponds to the given program. The best we can hope is to generate proof obligations on atomic parts of the program corresponding to logical properties to be verified. First, this paper studies a weak extraction of a program from a proof that keeps track of intermediate specifications. From such a program, we prove the determinism of retrieving proof obligations. Then, heuristic methods are proposed for retrieving the proof from a natural program containing only partial annotations. Finally, the implementation of this method as a tactic of the Coq proof assistant is presented. 1. Introduction A large p...
Impredicative Representations of Categorical Datatypes
, 1994
"... this document that certain implications are not based on a well stated formal theory but require a certain amount of handwaving. ..."
Abstract
 Add to MetaCart
this document that certain implications are not based on a well stated formal theory but require a certain amount of handwaving.
Gedanken: A tool for pondering the tractability of correct program technology
, 1994
"... syntax of elementary languages in Gedanken . . . . . . . . . . . 129 7.1 Match counting algorithm for patterns over PC k . . . . . . . . . . . . . 157 8.1 log 2 speed of Model Graphs after elimination . . . . . . . . . . . . . . . 187 8.2 log 2 speedup of Model Graphs after elimination . . . . . . ..."
Abstract
 Add to MetaCart
syntax of elementary languages in Gedanken . . . . . . . . . . . 129 7.1 Match counting algorithm for patterns over PC k . . . . . . . . . . . . . 157 8.1 log 2 speed of Model Graphs after elimination . . . . . . . . . . . . . . . 187 8.2 log 2 speedup of Model Graphs after elimination . . . . . . . . . . . . . 188 8.3 log 2 speed of Model Graphs after invalidation . . . . . . . . . . . . . . . 188 8.4 log 2 speedup of Model Graphs after invalidation . . . . . . . . . . . . . 189 ix Chapter 1 Summary One goal of computer science has been to develop a tool T to aid a programmer in building a program P that satisfies a specification S by helping the programmer build a proof in some logic of programs L that shows that P satisfies S. S typically is a pair of propositions (#, #) such that, for an input x to P , #(x) # #(P (x)) when P is defined on x. # is called the precondition or assumption, and # is called the postcondition or assertion. The problem of finding a suitable logic L of programs and specifications and verification tool T may be generically referred to as the "FloydHoare problem", formulated around 1967 [Flo67, Hoa69]. Around 1977, Davis and Schwartz proposed an extension of the FloydHoare problem in which there are multiple assumptions and assertions, referring to the state of a program as execution passes through di#erent places # in the program [DS77, Sch77]. A placed proposition is then a pair (#, #), where # is either a line of a program or the name of a function. A placed proposition (#, #) holds when, if execution reaches # and the value of the variables X in P is V , then #(V ) is valid. A program with assumptions and assertions or praa is then a triple R = (P, E, F ) where the assumptions E and assertions F are sets of placed propositions. T...