University of Pennsylvania ScholarlyCommons Departmental Papers (CIS) Department of Computer & Information Science 1-17-2010 Dependent types and Program Equivalence Limin Jia University of Pennsylvania Jianzhou Zhao University of Pennsylvania Vilhelm Sjoberg University of Pennsylvania Stephanie Weirich University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/cis_papers Part of the Computer Sciences Commons Recommended Citation Limin Jia, Jianzhou Zhao, Vilhelm Sjoberg, and Stephanie Weirich, "Dependent types and Program Equivalence", . January 2010. © ACM, 2010. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in 37th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, {(2010)} http://doi.acm.org/10.1145/10.1145/1707801.1706333 Email [email protected] This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_papers/632 For more information, please contact [email protected]. Dependent types and Program Equivalence Abstract The definition of type equivalence is one of the most important design issues for any typed language. In dependently-typed languages, because terms appear in types, this definition must elyr on a definition of term equivalence. In that case, decidability of type checking requires decidability for the term equivalence relation. Almost all dependently-typed 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, Omega, 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 equi valence, we parameterize our type system with an abstract relation that is not n ecessarily decidable. We then design a novel set of typing rules that require on ly weak properties of this abstract relation in the proof of the preservation an d progress lemmas. This design provides flexibility: we compare valid instantiat ions of term equivalence which range from beta-equivalence, to contextual equiva lence, to some exotic equivalences. Disciplines Computer Sciences Comments © ACM, 2010. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in 37th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, {(2010)} http://doi.acm.org/10.1145/10.1145/ 1707801.1706333 Email [email protected] This conference paper is available at ScholarlyCommons: https://repository.upenn.edu/cis_papers/632 Dependent Types and Program Equivalence Limin Jia Jianzhou Zhao Vilhelm Sjöberg Stephanie Weirich Computer and Information Sciences Department, University of Pennsylvania {liminjia,jianzhou,vilhelm,sweirich}@cis.upenn.edu Abstract 1. Introduction The definition of type equivalence is one of the most impor- Dependent type systems promise the smooth integration of tant design issues for any typed language. In dependently- lightweight invariant checking with full program verifica- typed languages, because terms appear in types, this defini- tion. In languages with dependent types, the types of a pro- tion must rely on a definition of term equivalence. In that gram may express rich, statically-checkable properties about case, decidability of type checking requires decidability for its behavior. the term equivalence relation. Central in the design of a dependently-typed language is Almost all dependently-typed languages require this rela- the notion of type equivalence. Because types include pro- tion to be decidable. Some, such as Coq, Epigram or Agda, do grams, type checking requires a definition of term equiva- so by employing analyses to force all programs to terminate. lence. Therefore, decidable type checking requires that the Conversely, others, such as DML, ATS, Ωmega, or Haskell, term equivalence relation be decidable. allow nonterminating computation, but do not allow those Previous work has almost uniformly insisted on decidable terms to appear in types. Instead, they identify a terminating type checking, and hence decidable term equivalence. Some index language and use singleton types to connect indices to languages, such as Coq [Coq Development Team 2009], Epi- computation. In both cases, decidable type checking comes gram [McBride and McKinna 2004] or Agda [Norell 2007], at a cost, in terms of complexity and expressiveness. do so by employing analysis that force all programs to ter- Conversely, the benefits to be gained by decidable type minate. This strong requirement has the benefit that type checking are modest. Termination analyses allow depen- checking implies total correctness. If a function has type dently typed programs to verify total correctness proper- τ ! Σy:τ 0: P y then one can be assured that it will terminate ties. However, decidable type checking is not a prerequi- and produce a value satisfying property P . site for type safety. Furthermore, decidability does not imply Other languages, such as Dependent ML [Xi and Pfenning tractability. A decidable approximation of program equiva- 1999], ATS [Xi 2004], Ωmega [Sheard 2006] and Haskell (with lence may not be useful in practice. GADTs [Peyton Jones et al. 2006]), allow diverging compu- Therefore, we take a different approach: instead of a fixed tation and sacrifice total correctness. They retain decidable notion for term equivalence, we parameterize our type sys- type checking by not allowing terms to appear in types. In- tem with an abstract relation that is not necessarily decid- stead, they identify a terminating index language (such as able. We then design a novel set of typing rules that re- the type language in the case of Haskell) and use singleton quire only weak properties of this abstract relation in the types to connect indices to computation. proof of the preservation and progress lemmas. This design In each of these cases, decidable type checking comes at a provides flexibility: we compare valid instantiations of term cost, in terms of both complexity and expressiveness. Requir- equivalence which range from beta-equivalence, to contex- ing all programs to terminate severely limits the generality tual equivalence, to some exotic equivalences. of a programming language. Furthermore, the complexity of the termination analysis can make it difficult for program- Categories and Subject Descriptors D.3.1 [Programming mers to understand why their code does not type check. In Languages]: Formal Definitions and Theory phase-sensitive languages, singleton types lead to code du- General Terms Design, Languages, Theory plication, as programs must often be written twice, once in the computation language and again in the index language. Keywords Dependent types, Program equivalence More troublesome, there is no restriction that the semantics of the index language match that of the computation lan- guage: only their first-order values are required to agree. At the same time, the benefits to be gained by decidable type checking are modest. Although termination analyses provide stronger correctness guarantees, they do not need to be integrated into the type system. Partial correctness guar- antees that are implied by type safety could be extended to Permission to make digital or hard copies of all or part of this work for total correctness where necessary by an external termination personal or classroom use is granted without fee provided that copies are analysis. Furthermore, decidability does not imply practical- not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to ity. Why rule out undecidable specifications a priori, when republish, to post on servers or to redistribute to lists, requires prior specific they could behave well in practice? permission and/or a fee. Therefore, we design a full-spectrum, dependently-typed ∼ POPL’10, January 17–23, 2010, Madrid, Spain. language λ=, pronounced “lambda-eek”, that does not pre- Copyright c 2010 ACM 978-1-60558-479-9/10/01. $10.00 suppose decidable program equivalence. This language is Terms e; u :: = x j unit j fun f (x) = e j e1 e2 both simple and expressive: not only does it include general j h e1 ; e2 i j e: 1 j e: 2 i recursive function definitions and dependent products, but j C e j case e of f Ci xi ) ei g it also supports indexed datatypes with elimination forms to Values v :: = unit j fun f (x) = e j h v1 ; v2 i j C v both terms (case expressions) and types (large eliminations). Dependent type systems with undecidable type checking Figure 1. Syntax are compatible with type safety [Cardelli 1986], and have been explored before [Augustsson 1998]. We extend this line of work by making key design decisions that permit a simple ( fun f (x) = e1 ) v2 −! e1fv2=xgffun f (x) = e1=f g proof of type saftey. Our straightforward proof of type safety is based on standard preservation and progress lemmas and h v1 ; v2 i: 1 −! v1 h v1 ; v2 i: 2 −! v2 has been formalized in the Coq proof assistant. i21::n ∼ C 2 C An important aspect of λ= is that it is actually a family of j i i21::n languages because its type system is parameterized by an ab- case Cj v of f Ci xi ) ei g −! ej fv=xj g stract relation that specifies program equivalence.