Results 1 - 10
of
17
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 16 (2 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 (higher-ranked) 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.
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 in-built equality at each type, taking a complementary approach to that of Benke, Dyb ..."
Abstract
-
Cited by 13 (3 self)
- Add to MetaCart
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 in-built 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
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 11 (1 self)
- Add to MetaCart
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 run-time 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 fully-verified 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]:
Why dependent types matter
- In preparation, http://www.e-pig.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 9 (2 self)
- Add to MetaCart
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 reduction-preserving 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 6 (4 self)
- Add to MetaCart
Abstract. This paper gives a reduction-preserving 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
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 two-level approach—they require less work than the standard techniques which inspired them [11 ..."
Abstract
-
Cited by 5 (3 self)
- Add to MetaCart
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 two-level 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 behind-the-scenes rôle in Epigram [25]. 1
Trace-based coinductive operational semantics for While; Big-step and small-step, 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 non-terminating program runs: big-step and small-step relational semantics and big-step and small-step functional semantics. The semantics employ traces (possibly infinite sequences ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
Abstract. We present four coinductive operational semantics for the While language accounting for both terminating and non-terminating program runs: big-step and small-step relational semantics and big-step and small-step functional semantics. The semantics employ traces (possibly infinite sequences of states) to record the states that program runs go through. The relational semantics relate statement-state pairs to traces, whereas the functional semantics return traces for statement-state pairs. All four semantics are equivalent. We formalize the semantics and their equivalence proofs in the constructive setting of Coq. 1
I am not a number: I am a free variable
- In Haskell workshop
, 2004
"... 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 [dB72] for bound variables. By doing so, we retain the advantages of both representations: naming supports easy, arithmetic-f ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
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 [dB72] for bound variables. By doing so, we retain the advantages of both representations: naming supports easy, arithmetic-free manipulation of terms; de Bruijn indices eliminate the need for α-conversion. Further, we have ensure 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 representation for names which readily supports a power structure naturally reflecting the structure of the implementation. Name choice is safe and straightforward. Our technology combines easily with an approach to syntax manipulation inspired by Huet’s ‘zippers’[Hue97]. Without the technology in this paper, we could not have implemented Epigram [McB04]. Our example—constructing inductive elimination operators for datatype families—is but one of many where it proves invaluable. Prologue In conversation, we like to have names for the people we’re talking about. If we had to say things like ‘the person three to the left of me ’ rather than ‘Fred’, things would get complicated whenever anyone went to the lavatory. You don’t need to have formalized the strengthening property for Pure Type Systems [MP99] to appreciate this basic phenomenon of social interaction. It is in the company of strangers that more primitive pointing-based modes of reference acquire a useful rôle as a way of indicating unambiguously an individual with no socially agreed name. Even so, once a stranger enters the context of the conversation, he or she typically acquires a name. What this name is and who chooses it depends on the power relationships between those involved, as we learned in the playground at school. Moreover, if we are having a conversation about hypothetical individuals—say, Alice, Bob and Unscrupulous Charlie—we have a tendency to name them locally to the discussion. We do not worry about whether Unscrupulous Charlie might actually turn out to be called Shameless David whenever he turns up. That is, we exploit naming locally to assist the construction of explanations which apply to individuals regardless of what they are called. 1 1
The Epigram Prototype: a nod and two winks
, 2005
"... I intend this document as a guide to the prototype EPIGRAM system. As things stand, there are still a great many things which need to be done, but the system can now be ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
I intend this document as a guide to the prototype EPIGRAM system. As things stand, there are still a great many things which need to be done, but the system can now be
Simply Easy! An Implementation of a Dependently Typed Lambda Calculus
, 2007
"... We present an implementation in Haskell of a dependently-typed lambda calculus that can be used as the core of a programming language. We show that a dependently-typed lambda calculus is no more difficult to implement than other typed lambda calculi. In fact, our implementation is almost as easy as ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
We present an implementation in Haskell of a dependently-typed lambda calculus that can be used as the core of a programming language. We show that a dependently-typed lambda calculus is no more difficult to implement than other typed lambda calculi. In fact, our implementation is almost as easy as an implementation of the simply typed lambda calculus, which we emphasize by discussing the modifications necessary to go from one to the other. We explain how to add data types and write simple programs in the core language, and discuss the steps necessary to build a full-fledged programming language on top of our simple core.

