Results 1  10
of
39
Observational Equality, Now!
 A SUBMISSION TO PLPV 2007
, 2007
"... This paper has something new and positive to say about propositional equality in programming and proof systems based on the CurryHoward correspondence between propositions and types. We have found a way to present a propositional equality type • which is substitutive, allowing us to reason by repla ..."
Abstract

Cited by 26 (9 self)
 Add to MetaCart
This paper has something new and positive to say about propositional equality in programming and proof systems based on the CurryHoward correspondence between propositions and types. We have found a way to present a propositional equality type • which is substitutive, allowing us to reason by replacing equal for equal in propositions; • which reflects the observable behaviour of values rather than their construction: in particular, we have extensionality— functions are equal if they take equal inputs to equal outputs; • which retains strong normalisation, decidable typechecking and canonicity—the property that closed normal forms inhabiting datatypes have canonical constructors; • which allows inductive data structures to be expressed in terms of a standard characterisation of wellfounded trees; • which is presented syntactically—you can implement it directly, and we are doing so—this approach stands at the core of Epigram 2; • which you can play with now: we have simulated our system by a shallow embedding in Agda 2, shipping as part of the standard examples package for that system [20]. Until now, it has always been necessary to sacrifice some of these aspects. The closest attempt in the literature is Altenkirch’s construction of a setoidmodel for a system with canonicity and extensionality on top of an intensional type theory with proofirrelevant propositions [4]. Our new proposal simplifies Altenkirch’s construction by adopting McBride’s heterogeneous approach to equality [18].
A Polymorphic Intermediate Verification Language: Design and Logical Encoding
"... Intermediate languages are a paradigm to separate concerns in software verification systems when bridging the gap between programming languages and the logics understood by theorem provers. While such intermediate languages traditionally only offer rather simple type systems, this paper argues that ..."
Abstract

Cited by 26 (3 self)
 Add to MetaCart
Intermediate languages are a paradigm to separate concerns in software verification systems when bridging the gap between programming languages and the logics understood by theorem provers. While such intermediate languages traditionally only offer rather simple type systems, this paper argues that it is both advantageous and feasible to integrate richer type systems with features like (higherranked) polymorphism and quantification over types. As a concrete solution, the paper presents the type system of Boogie 2, an intermediate verification language that is used in several program verifiers. The paper gives two encodings of types and formulae in simply typed logic such that SMT solvers and other theorem provers can be used to discharge verification conditions.
Toward a Verified Relational Database Management System ∗
"... We report on our experience implementing a lightweight, fully verified relational database management system (RDBMS). The functional specification of RDBMS behavior, RDBMS implementation, and proof that the implementation meets the specification are all written and verified in Coq. Our contributions ..."
Abstract

Cited by 20 (2 self)
 Add to MetaCart
(Show Context)
We report on our experience implementing a lightweight, fully verified relational database management system (RDBMS). The functional specification of RDBMS behavior, RDBMS implementation, and proof that the implementation meets the specification are all written and verified in Coq. Our contributions include: (1) a complete specification of the relational algebra in Coq; (2) an efficient realization of that model (B+ trees) implemented with the Ynot extension to Coq; and (3) a set of simple query optimizations proven to respect both semantics and runtime cost. In addition to describing the design and implementation of these artifacts, we highlight the challenges we encountered formalizing them, including the choice of representation for finite relations of typed tuples and the challenges of reasoning about data structures with complex sharing. Our experience shows that though many challenges remain, building fullyverified systems software in Coq is within reach. Categories and Subject Descriptors F.3.1 [Logics and meanings of programs]: Mechanical verification; D.2.4 [Software Engineering]:
Exploring the regular tree types
 In Types for Proofs and Programs
, 2004
"... Abstract. In this paper we use the Epigram language to define the universe of regular tree types—closed under empty, unit, sum, product and least fixpoint. We then present a generic decision procedure for Epigram’s inbuilt equality at each type, taking a complementary approach to that of Benke, Dyb ..."
Abstract

Cited by 18 (4 self)
 Add to MetaCart
(Show Context)
Abstract. In this paper we use the Epigram language to define the universe of regular tree types—closed under empty, unit, sum, product and least fixpoint. We then present a generic decision procedure for Epigram’s inbuilt equality at each type, taking a complementary approach to that of Benke, Dybjer and Jansson [7]. We also give a generic definition of map, taking our inspiration from Jansson and Jeuring [21]. Finally, we equip the regular universe with the partial derivative which can be interpreted functionally as Huet’s notion of ‘zipper’, as suggested by McBride in [27] and implemented (without the fixpoint case) in Generic Haskell by Hinze, Jeuring and Löh [18]. We aim to show through these examples that generic programming can be ordinary programming in a dependently typed language. 1
Why dependent types matter
 In preparation, http://www.epig.org/downloads/ydtm.pdf
, 2005
"... We exhibit the rationale behind the design of Epigram, a dependently typed programming language and interactive program development system, using refinements of a well known program—merge sort—as a running example. We discuss its relationship with other proposals to introduce aspects of dependent ty ..."
Abstract

Cited by 11 (3 self)
 Add to MetaCart
(Show Context)
We exhibit the rationale behind the design of Epigram, a dependently typed programming language and interactive program development system, using refinements of a well known program—merge sort—as a running example. We discuss its relationship with other proposals to introduce aspects of dependent types into functional programming languages and sketch some topics for further work in this area. 1.
Eliminating dependent pattern matching
 of Lecture Notes in Computer Science
, 2006
"... Abstract. This paper gives a reductionpreserving translation from Coquand’s dependent pattern matching [4] into a traditional type theory [11] with universes, inductive types and relations and the axiom K [22]. This translation serves as a proof of termination for structurally recursive pattern mat ..."
Abstract

Cited by 10 (5 self)
 Add to MetaCart
(Show Context)
Abstract. This paper gives a reductionpreserving translation from Coquand’s dependent pattern matching [4] into a traditional type theory [11] with universes, inductive types and relations and the axiom K [22]. This translation serves as a proof of termination for structurally recursive pattern matching programs, provides an implementable compilation technique in the style of functional programming languages, and demonstrates the equivalence with a more easily understood type theory. Dedicated to Professor Joseph Goguen on the occasion of his 65th birthday. 1
Functional pearl: I am not a number–I am a free variable
 In Proc. Haskell workshop
"... In this paper, we show how to manipulate syntax with binding using a mixed representation of names for free variables (with respect to the task in hand) and de Bruijn indices [5] for bound variables. By doing so, we retain the advantages of both representations: naming supports easy, arithmeticfree ..."
Abstract

Cited by 9 (2 self)
 Add to MetaCart
(Show Context)
In this paper, we show how to manipulate syntax with binding using a mixed representation of names for free variables (with respect to the task in hand) and de Bruijn indices [5] for bound variables. By doing so, we retain the advantages of both representations: naming supports easy, arithmeticfree manipulation of terms; de Bruijn indices eliminate the need for αconversion. Further, we have ensured that not only the user but also the implementation need never deal with de Bruijn indices, except within key basic operations. Moreover, we give a hierarchical representation for names which naturally reflects the structure of the operations we implement. Name choice is safe and straightforward. Our technology combines easily with an approach to syntax manipulation inspired by Huet’s ‘zippers’[10]. Without the ideas in this paper, we would have struggled to implement EPIGRAM [19]. Our example—constructing inductive elimination operators for datatype families—is but one of many where it proves invaluable.
A few constructions on constructors
 Types for Proofs and Programs
, 2005
"... Abstract. We present four constructions for standard equipment which can be generated for every inductive datatype: case analysis, structural recursion, no confusion, acyclicity. Our constructions follow a twolevel approach—they require less work than the standard techniques which inspired them [11 ..."
Abstract

Cited by 8 (5 self)
 Add to MetaCart
(Show Context)
Abstract. We present four constructions for standard equipment which can be generated for every inductive datatype: case analysis, structural recursion, no confusion, acyclicity. Our constructions follow a twolevel approach—they require less work than the standard techniques which inspired them [11, 8]. Moreover, given a suitably heterogeneous notion of equality, they extend without difficulty to inductive families of datatypes. These constructions are vital components of the translation from dependently typed programs in pattern matching style [7] to the equivalent programs expressed in terms of induction principles [21] and as such play a crucial behindthescenes rôle in Epigram [25]. 1
Tracebased coinductive operational semantics for While; Bigstep and smallstep, relational and functional styles
 In Theorem Proving in Higher Order Logics, 22nd International Conference, TPHOLs 2009, volume 5674 of LNCS
, 2009
"... Abstract. We present four coinductive operational semantics for the While language accounting for both terminating and nonterminating program runs: bigstep and smallstep relational semantics and bigstep and smallstep functional semantics. The semantics employ traces (possibly infinite sequences ..."
Abstract

Cited by 6 (1 self)
 Add to MetaCart
Abstract. We present four coinductive operational semantics for the While language accounting for both terminating and nonterminating program runs: bigstep and smallstep relational semantics and bigstep and smallstep functional semantics. The semantics employ traces (possibly infinite sequences of states) to record the states that program runs go through. The relational semantics relate statementstate pairs to traces, whereas the functional semantics return traces for statementstate pairs. All four semantics are equivalent. We formalize the semantics and their equivalence proofs in the constructive setting of Coq. 1