Results 1  10
of
35
Dependently typed programming in Agda
 In Lecture Notes from the Summer School in Advanced Functional Programming
, 2008
"... In HindleyMilner style languages, such as Haskell and ML, there is a clear separation between types and values. In a dependently typed language the line is more blurry – types can contain (depend on) arbitrary values and appear as arguments and results of ordinary functions. ..."
Abstract

Cited by 60 (1 self)
 Add to MetaCart
In HindleyMilner style languages, such as Haskell and ML, there is a clear separation between types and values. In a dependently typed language the line is more blurry – types can contain (depend on) arbitrary values and appear as arguments and results of ordinary functions.
The Gentle Art of Levitation
"... We present a closed dependent type theory whose inductive types are given not by a scheme for generative declarations, but by encoding in a universe. Each inductive datatype arises by interpreting its description—a firstclass value in a datatype of descriptions. Moreover, the latter itself has a de ..."
Abstract

Cited by 31 (8 self)
 Add to MetaCart
(Show Context)
We present a closed dependent type theory whose inductive types are given not by a scheme for generative declarations, but by encoding in a universe. Each inductive datatype arises by interpreting its description—a firstclass value in a datatype of descriptions. Moreover, the latter itself has a description. Datatypegeneric programming thus becomes ordinary programming. We show some of the resulting generic operations and deploy them in particular, useful ways on the datatype of datatype descriptions itself. Surprisingly this apparently selfsupporting setup is achievable without paradox or infinite regress. 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 28 (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]:
Parametricity and dependent types
, 2010
"... Reynolds ’ abstraction theorem shows how a typing judgement in System F can be translated into a relational statement (in second order predicate logic) about inhabitants of the type. We obtain a similar result for a single lambda calculus (a pure type system), in which terms, types and their relatio ..."
Abstract

Cited by 18 (2 self)
 Add to MetaCart
(Show Context)
Reynolds ’ abstraction theorem shows how a typing judgement in System F can be translated into a relational statement (in second order predicate logic) about inhabitants of the type. We obtain a similar result for a single lambda calculus (a pure type system), in which terms, types and their relations are expressed. Working within a single system dispenses with the need for an interpretation layer, allowing for an unusually simple presentation. While the unification puts some constraints on the type system (which we spell out), the result applies to many interesting cases, including dependentlytyped ones. Categories and Subject Descriptors F.3.3 [Logics and Meanings
Dependently Typed Programming with Singletons
 DRAFT FOR SUBMISSION TO HASKELL 2012
, 2012
"... Haskell programmers have been experimenting with dependent types for at least a decade, using clever encodings that push the limits of the Haskell type system. However, the cleverness of these encodings is also their main drawback. Although the ideas are inspired by dependently typed programs, the c ..."
Abstract

Cited by 14 (4 self)
 Add to MetaCart
Haskell programmers have been experimenting with dependent types for at least a decade, using clever encodings that push the limits of the Haskell type system. However, the cleverness of these encodings is also their main drawback. Although the ideas are inspired by dependently typed programs, the code looks significantly different. As a result, GHC implementors have responded with extensions to Haskell’s type system, such as GADTs, type families, and datatype promotion. However, there remains a significant difference between programming in Haskell and in fullspectrum dependently typed languages. Haskell enforces a phase separation between runtime values and compiletime types. Therefore, singleton types are necessary to express the dependency between values and types. These singleton types introduce overhead and redundancy for the programmer. This paper presents the singletons library, which generates the boilerplate code necessary for dependently typed programming using GHC. To compare with fullspectrum languages, we present an extended example based on an Agda interface for safe database access. The paper concludes with a detailed discussion on the current capabilities of GHC for dependently typed programming and suggestions for future extensions to better support this style of programming.
Invertible Syntax Descriptions: Unifying Parsing and Pretty Printing
"... Parsers and prettyprinters for a language are often quite similar, yet both are typically implemented separately, leading to redundancy and potential inconsistency. We propose a new interface of syntactic descriptions, with which both parser and prettyprinter can be described as a single program. ..."
Abstract

Cited by 11 (0 self)
 Add to MetaCart
Parsers and prettyprinters for a language are often quite similar, yet both are typically implemented separately, leading to redundancy and potential inconsistency. We propose a new interface of syntactic descriptions, with which both parser and prettyprinter can be described as a single program. Whether a syntactic description is used as a parser or as a prettyprinter is determined by the implementation of the interface. Syntactic descriptions enable programmers syntax once and for all, and use these descriptions for parsing or prettyprinting as needed. We also discuss the generalization of our programming technique towards an algebra of partial isomorphisms.
Attribute grammars fly firstclass: how to do aspect oriented programming in Haskell
 in: Proceedings of the International Conference on Functional Programming, ACM, 2009
"... Attribute Grammars (AGs), a generalpurpose formalism for describing recursive computations over data types, avoid the tradeoff which arises when building software incrementally: should it be easy to add new data types and data type alternatives or to add new operations on existing data types? How ..."
Abstract

Cited by 11 (3 self)
 Add to MetaCart
(Show Context)
Attribute Grammars (AGs), a generalpurpose formalism for describing recursive computations over data types, avoid the tradeoff which arises when building software incrementally: should it be easy to add new data types and data type alternatives or to add new operations on existing data types? However, AGs are usually implemented as a preprocessor, leaving e.g. type checking to later processing phases and making interactive development, proper error reporting and debugging difficult. Embedding AG into Haskell as a combinator library solves these problems. Previous attempts at embedding AGs as a domainspecific language were based on extensible records and thus exploiting Haskell’s type system to check the wellformedness of the AG, but fell short in compactness and the possibility to abstract over oft occurring AG patterns. Other attempts used a very generic mapping for which the AG wellformedness could not be statically checked. We present a typed embedding of AG in Haskell satisfying all these requirements. The key lies in using HListlike typed heterogeneous collections (extensible polymorphic records) and expressing AG wellformedness conditions as typelevel predicates (i.e., typeclass constraints). By further typelevel programming we can also express common programming patterns, corresponding to the typical use cases of monads such as Reader, Writer and State. The paper presents a realistic example of typeclassbased typelevel programming in Haskell.
Proofs for free — parametricity for dependent types
 Journal of Functional Programming
, 2012
"... Reynolds ’ abstraction theorem (Reynolds, J. C. (1983) Types, abstraction and parametric polymorphism, Inf. Process. 83(1), 513–523) shows how a typing judgement in System F can be translated into a relational statement (in secondorder predicate logic) about inhabitants of the type. We obtain a sim ..."
Abstract

Cited by 10 (0 self)
 Add to MetaCart
(Show Context)
Reynolds ’ abstraction theorem (Reynolds, J. C. (1983) Types, abstraction and parametric polymorphism, Inf. Process. 83(1), 513–523) shows how a typing judgement in System F can be translated into a relational statement (in secondorder predicate logic) about inhabitants of the type. We obtain a similar result for pure type systems (PTSs): for any PTS used as a programming language, there is a PTS that can be used as a logic for parametricity. Types in the source PTS are translated to relations (expressed as types) in the target. Similarly, values of a given type are translated to proofs that the values satisfy the relational interpretation. We extend the result to inductive families. We also show that the assumption that every term satisfies the parametricity condition generated by its type is consistent with the generated logic. 1
Dependent types and program equivalence
 In Proceedings of the 37th ACM SIGACTSIGPLAN Symposium on Principles of Programming Languages (POPL). ACM
, 2009
"... The definition of type equivalence is one of the most important design issues for any typed language. In dependentlytyped languages, because terms appear in types, this definition must rely on a definition of term equivalence. In that case, decidability of type checking requires decidability for the ..."
Abstract

Cited by 9 (3 self)
 Add to MetaCart
(Show Context)
The definition of type equivalence is one of the most important design issues for any typed language. In dependentlytyped languages, because terms appear in types, this definition must rely on a definition of term equivalence. In that case, decidability of type checking requires decidability for the term equivalence relation. Almost all dependentlytyped languages require this relation to be decidable. Some, such as Coq, Epigram or Agda, do so by employing analyses to force all programs to terminate. Conversely, others, such as DML, ATS, Ωmega, or Haskell, allow nonterminating computation, but do not allow those terms to appear in types. Instead, they identify a terminating index language and use singleton types to connect indices to computation. In both cases, decidable type checking comes at a cost, in terms of complexity and expressiveness. Conversely, the benefits to be gained by decidable type checking are modest. Termination analyses allow dependently typed programs to verify total correctness properties. However, decidable type checking is not a prerequisite for type safety. Furthermore, decidability does not imply tractability. A decidable approximation of program equivalence may not be useful in practice. Therefore, we take a different approach: instead of a fixed notion for term equivalence, we parameterize our type system with an abstract relation that is not necessarily decidable. We then design a novel set of typing rules that require only weak properties of this abstract relation in the proof of the preservation and progress lemmas. This design provides flexibility: we compare valid instantiations of term equivalence which range from betaequivalence, to contextual equivalence, to some exotic equivalences.
Dependently Typed Programming with DomainSpecific Logics
 SUBMITTED TO POPL ’09
, 2008
"... We define a dependent programming language in which programmers can define and compute with domainspecific logics, such as an accesscontrol logic that statically prevents unauthorized access to controlled resources. Our language permits programmers to define logics using the LF logical framework, ..."
Abstract

Cited by 6 (3 self)
 Add to MetaCart
We define a dependent programming language in which programmers can define and compute with domainspecific logics, such as an accesscontrol logic that statically prevents unauthorized access to controlled resources. Our language permits programmers to define logics using the LF logical framework, whose notion of binding and scope facilitates the representation of the consequence relation of a logic, and to compute with logics by writing functional programs over LF terms. These functional programs can be used to compute values at runtime, and also to compute types at compiletime. In previous work, we studied a simplytyped framework for representing and computing with variable binding [LICS 2008]. In this paper, we generalize our previous type theory to account for dependently typed inference rules, which are necessary to adequately represent domainspecific logics, and we present examples of using our type theory for certified software and mechanized metatheory.