Results 1 
5 of
5
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 125 (5 self)
 Add to MetaCart
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 collectio ..."
Abstract

Cited by 24 (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.