Results 1 
6 of
6
Using dependent types to express modular structure
 In Thirteenth ACM Symposium on Principles of Programming Languages
, 1986
"... Several related typed languages for modular programming and data abstraction have been proposed recently, including Pebble, SOL, and ML modules. We review and compare the basic typetheoretic ideas behind these languages and evaluate how they ..."
Abstract

Cited by 130 (5 self)
 Add to MetaCart
(Show Context)
Several related typed languages for modular programming and data abstraction have been proposed recently, including Pebble, SOL, and ML modules. We review and compare the basic typetheoretic ideas behind these languages and evaluate how they
Type Checking with Universes
, 1991
"... Various formulations of constructive type theories have been proposed to serve as the basis for machineassisted proof and as a theoretical basis for studying programming languages. Many of these calculi include a cumulative hierarchy of "universes," each a type of types closed under a ..."
Abstract

Cited by 26 (6 self)
 Add to MetaCart
Various formulations of constructive type theories have been proposed to serve as the basis for machineassisted proof and as a theoretical basis for studying programming languages. Many of these calculi include a cumulative hierarchy of "universes," each a type of types closed under a collection of typeforming operations. Universes are of interest for a variety of reasons, some philosophical (predicative vs. impredicative type theories), some theoretical (limitations on the closure properties of type theories), and some practical (to achieve some of the advantages of a type of all types without sacrificing consistency.) The Generalized Calculus of Constructions (CC ! ) is a formal theory of types that includes such a hierarchy of universes. Although essential to the formalization of constructive mathematics, universes are tedious to use in practice, for one is required to make specific choices of universe levels and to ensure that all choices are consistent. In this pa...
A construction of Type:Type in MartinLöf's partial type theory with one universe
"... ing on w and pairing with oe(p(c); (x)Ap(q(c); x) ! p(c)) in the first coordinate yields hoe(p(c);(x)Ap(q(c); x) ! p(c)); (w)(Ap(q(c); p(w)); (x)Ap(q(c); Ap(q(w); x)))i 2 PAR; i.e. s (c) 2 PAR. We define the operator that builds the universe (U 1 ; T 1 ) by putting f(c) := s (c) +hn 1 ; (x ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
ing on w and pairing with oe(p(c); (x)Ap(q(c); x) ! p(c)) in the first coordinate yields hoe(p(c);(x)Ap(q(c); x) ! p(c)); (w)(Ap(q(c); p(w)); (x)Ap(q(c); Ap(q(w); x)))i 2 PAR; i.e. s (c) 2 PAR. We define the operator that builds the universe (U 1 ; T 1 ) by putting f(c) := s (c) +hn 1 ; (x)R 1 (x; p(c))i; for c 2 PAR, and let e := fix((c)f(c)). Hence e 2 PAR is a fixed point of f , e = f(e). The right summand of f corresponds to the rules (2). We now interpret Type:Type. The universe (U 1 ; T 1 ) is defined by letting U 1 := T (p(e)) and T 1 (a) := T (Ap(q(e); a)); for a 2 U 1 . Thus the rules (1) are verified. Using the equality e = f(e) and the commutation of T with \Sigma, \Pi and + we get U 1 = T (p(e)) = T (p(f(e))) (4) = T (oe(p(e); (x)Ap(q(e); x) ! p(e))) + T (n 1 ) = (\Sigmax 2 T (p(e)))[T (Ap(q(e); x)) \Gamma! T (p(e))] +N 1 = (\Sigmax 2 U 1 )[T 1 (x) \Gamma! U 1 ] +N 1 and hence j(0 1 ) 2 U 1 . Furthermore we have T 1 (j(0 1 )) = T (Ap(q(...
Irrelevance, Polymorphism, and Erasure in Type Theory
, 2008
"... Dependent type theory is a proven technology for verified functional programming in which programs and their correctness proofs may be developed using the same rules in a single formal system. In practice, large portions of programs developed in this way have no computational relevance to the ultima ..."
Abstract
 Add to MetaCart
Dependent type theory is a proven technology for verified functional programming in which programs and their correctness proofs may be developed using the same rules in a single formal system. In practice, large portions of programs developed in this way have no computational relevance to the ultimate result of the program and should therefore be removed prior to program execution. In previous work on identifying and removing irrelevant portions of programs, computational irrelevance is usually treated as an intrinsic property of program expressions. We find that such an approach forces programmers to maintain two copies of commonly used datatypes: a computationally relevant one and a computationally irrelevant one. We instead develop an extrinsic notion of computational irrelevance and find that it yields several benefits including (1) avoidance of the above mentioned code duplication problem; (2) an identification of computational irrelevance with a highly general form of parametric polymorphism; and (3) an elective (i.e., user2 directed) notion of proof irrelevance. We also develop a program analysis for identifying irrelevant expressions and show how previously studied types embodying computational irrelevance (including subset types and squash types) are expressible in the extension of type theory developed herein.
Reusability and Dependent Types: Case for Support
"... Robin Milner coined the slogan well typed programs cannot go wrong, advertising the power of types in functional languages like ML and Haskell to catch runtime errors. Nowadays, we can and should go further: dependently typed programming exploits the power of very expressive type systems to delive ..."
Abstract
 Add to MetaCart
(Show Context)
Robin Milner coined the slogan well typed programs cannot go wrong, advertising the power of types in functional languages like ML and Haskell to catch runtime errors. Nowadays, we can and should go further: dependently typed programming exploits the power of very expressive type systems to deliver stronger guarantees but also additional support for software development, using types to guide the development process. This is witnessed by a recent surge of language proposals with the goal to harness the power of dependent types, e.g. Haskell with GADTs [84, 85], Agda [90], Coq [18], Ωmega [88], Concoqtion [83], Guru [89], Ynot [77], Epigram [68], and so on. However, expressive type systems have their price: more specific types frequently reduce the reusability of code, whose toospecific implementation type may not fit its current application. This phenomenon already shows up in the traditional HindleyMilner style type system of ML and Haskell; it becomes even more prevalent in a dependently typed setting. Luckily, all is not lost: dependent types are expressive enough that they can talk about themselves reflectively, makingmetaprogramming one of their potential killer applications [11], with the potential to combine expressive types and reusable software components. Based on and inspired by recent research at Nottingham on dependently typed programming (EPSRC EP/C512022/1) and container types (EPSRC EP/C511964/2) and at Oxford on datatypegeneric programming (EPSRC GR/S27078/01, EP/E02128X/1) we plan to explore the potential of dependent types to deliver reusable and reliable software components. To