DOCSLIB.ORG

Towards a Practical Programming Language Based on Dependent Type Theory

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Towards a Practical Programming Language Based on Dependent Type Theory Thesis for the degree of Doctor of Philosophy Towards a practical programming language based on dependent type theory Ulf Norell Department of Computer Science and Engineering Chalmers University of Technology and Goteborg¨ University G¨oteborg, Sweden, 2007 Towards a practical programming language based on dependent type theory Ulf Norell c Ulf Norell, 2007 ISBN 978-91-7291-996-9 ISSN 0346-718X Doktorsavhandlingar vid Chalmers tekniska h¨ogskola, Ny serie Nr 2677. Technical report 33D Department of Computer Science and Engineering Research group: Programming Logic Department of Computer Science and Engineering Chalmers University of Technology and Goteborg¨ University SE-412 96 G¨oteborg Sweden Telephone +46 (0)31-772 1000 Printed at the Department of Computer Science and Engineering G¨oteborg, 2007 3 Abstract Dependent type theories [ML72] have a long history of being used for theorem proving. One aspect of type theory which makes it very powerful as a proof language is that it mixes deduction with computation. This also makes type theory a good candidate for programming—the strength of the type system allows properties of programs to be stated and established, and the computational properties provide semantics for the programs. This thesis is concerned with bridging the gap between the theoretical presentations of type theory and the requirements on a practical program- ming language. Although there are many challenging research problems left to solve before we have an industrial scale programming language based on type theory, this thesis takes us a good step along the way. In functional programming languages pattern matching provides a concise notation for defining functions. In dependent type theory, pattern matching becomes even more powerful, in that inspecting the value of a particular term can reveal information about the types and values of other terms. In this thesis we give a type checking algorithm for definitions by pattern matching in type theory, supporting overlapping patterns, and pattern matching on intermediate results using the with rule [MM04a]. Traditional presentations of type theory suffers from rather verbose no- tation, cluttering programs and proofs with, for instance, explicit type in- formation. One solution to this problem is to allow terms that can be in- ferred automatically to be omitted. This is usually implemented by inserting metavariables in place of the omitted terms and using unification to solve these metavariables during type checking. We present a type checking algo- rithm for a theory with metavariables and prove its soundness independent of whether the metavariables are solved or not. In any programming language it is important to be able to structure large programs into separate units or modules and limit the interaction between these modules. In this thesis we present a simple, but powerful module sys- tem for a dependently typed language. The main focus of the module system is to manage the name space of a program, and an important characteristic is a clear separation between the module system and the type checker, making it largely independent of the underlying language. As a side track, not directly related to the use of type theory for pro- gramming, we present a connection between type theory and a first-order logic theorem prover. This connection saves the user the burden of prov- ing simple, but tedious first-order theorems by leaving them for the prover. We use a transparent translation to first-order logic which makes the proofs constructed by the theorem prover human readable. The soundness of the 4 connection is established by a general metatheorem. Finally we put our work into practise in the implementation of a pro- gramming language, Agda, based on type theory. As an illustrating example we show how to program a simple certified prover for equations in a commu- tative monoid, which can be used internally in Agda. Much more impressive examples have been done by others, showing that the ideas developed in this thesis are viable in practise. 5 Acknowledgements I would like to thank all the people without whom this thesis would not have been possible. My supervisor Patrik Jansson for supporting me throughout my studies, my colleagues Andreas Abel, Catarina Coquand, Thierry Coquand, Nils Anders Danielsson, Peter Dybjer, and many more for excellent collaborations and many fruitful discussions about my work, Conor McBride for providing invaluable feedback on the thesis, my fianc´eeCecilia for keeping me sane during the process of writing the thesis, and last but not least, my mother for teaching me programming 20 some years ago. 6 Contents 1 Introduction 11 1.1 Overview of the thesis . 12 1.2 Context . 13 1.3 A basic dependent type theory . 14 1.4 Type checking . 18 1.5 Extensions to the theory . 24 1.5.1 Inductive definitions . 24 1.5.2 Uniqueness of identity proofs . 25 1.5.3 Record types . 25 1.5.4 Implicit arguments . 26 2 Pattern Matching 27 2.1 Type checking pattern match equations . 30 2.1.1 Context mappings . 30 2.1.2 Overview of the algorithm . 31 2.1.3 Matching . 31 2.1.4 Unification . 32 2.1.5 Context splitting . 33 2.1.6 Type checking algorithm . 36 2.1.7 Checking inaccessible patterns . 37 2.1.8 Refuting elements of empty types . 38 2.1.9 Checking the right hand side . 39 2.2 Coverage checking . 40 2.2.1 Coverage algorithm . 42 2.2.2 Uniqueness of identity proofs . 44 2.3 The with construct . 45 2.3.1 Examples . 46 3 Metavariables 49 3.1 Introduction . 49 3.2 The underlying logic MLF .................... 51 7 8 CONTENTS 3.3 The type checking algorithm . 53 3.3.1 Operations on the signature . 54 3.3.2 The algorithm . 55 3.4 Examples . 60 3.5 Proof of correctness . 62 3.5.1 Soundness without constraint solving . 62 3.5.2 Soundness of constraint solving . 65 3.5.3 Relating user expressions and checked terms . 68 3.5.4 Main result . 68 3.6 Implicit arguments . 69 3.7 Extending the underlying theory . 70 3.7.1 Sigma types and the unit type . 71 3.7.2 Function types as terms . 72 3.7.3 Universe hierarchy . 72 3.7.4 Pattern matching . 72 3.8 Summary . 73 4 Module System 75 4.1 Introduction . 75 4.2 Description . 76 4.2.1 Private definitions . 77 4.2.2 Name modifiers . 78 4.2.3 Re-exporting names . 79 4.2.4 Parameterised modules . 79 4.2.5 Splitting a program over multiple files . 81 4.3 Equipment for record types . 82 4.4 An example . 83 4.4.1 A note on record subtyping . 87 4.5 Implementation . 87 4.5.1 Scope checking state . 88 4.5.2 Looking up and adding names . 89 4.5.3 Pushing and popping . 89 4.5.4 Scope modifiers . 90 4.5.5 Scope checking . 91 4.5.6 Type checking . 93 4.6 Summary . 95 5 The Agda Language 97 5.1 Language description . 97 5.1.1 Names . 97 5.1.2 Interaction points . 98 CONTENTS 9 5.1.3 Implicit syntax . 98 5.1.4 Functions . 98 5.1.5 Implicit arguments . 99 5.1.6 Datatypes and function definitions . 100 5.1.7 Records . 102 5.1.8 Local definitions . 102 5.1.9 Module system . 103 5.1.10 Additional features . 104 5.2 A bigger example . 104 5.2.1 Logic . 105 5.2.2 Basic datatypes . 105 5.2.3 Equivalence relations . 108 5.2.4 Chain reasoning . 112 5.2.5 Monoids . 114 5.2.6 Representing commutative monoid equations . 115 5.2.7 Semantics . 118 6 First-order Logic 125 6.1 Introduction . 125 6.2 The Logical Framework MLFProp ................. 127 6.3 Translation from MLFProp toFOL ................ 132 6.3.1 Formal Description of the Translation . 132 6.3.2 Resolution Calculus . 134 6.3.3 Proof of Correctness . 135 6.3.4 Simple Examples . 138 6.4 Implementation . 139 6.4.1 Implicit Arguments . 140 6.4.2 The Plug-in Mechanism . 141 6.4.3 The FOL Plug-in . 141 6.5 Examples . 142 6.5.1 Relational Algebra . 143 6.5.2 Category Theory . 144 6.5.3 Computer Algebra . 145 6.6 Related Work . 148 6.7 Future Work . 150 7 Conclusions 153 10 CONTENTS Chapter 1 Introduction Programming is the craft of giving instructions to machines. Being machines they will follow these instructions regardless of whether they make sense or not. The purpose of a programming language is to make it easier to express the things that do make sense while making it harder or impossible to express things that do not make sense. The first step in this direction is to make programming languages readable by human beings. That way the programmer can read her program and convince herself that it makes sense, but since programmers are humans they will make mistakes both writing programs and trying to make sense of them. To help with this modern programming languages come equipped with type systems, which allows the programmer to declare the purpose of a program in the form of a type. The machine can then check that a given program has the intended behaviour. Types can also be used to guide the programmer in constructing the correct program. In its simplest form a type system allows you to state, for instance, that the purpose of a sorting program is to take a list as input and produce a list as output. This is a very crude approximation of what it means to be a sorting program but it does provide some guarantees. In more expressive type systems, such as the ones discussed in this thesis, it is possible to express that the sorting program takes a list of elements over which there is a total order, and computes an ordered permutation of this list.
Load more

Recommended publications
  • Types Are Internal Infinity-Groupoids Antoine Allioux, Eric Finster, Matthieu Sozeau
    Types are internal infinity-groupoids Antoine Allioux, Eric Finster, Matthieu Sozeau To cite this version: Antoine Allioux, Eric Finster, Matthieu Sozeau. Types are internal infinity-groupoids. 2021. hal- 03133144 HAL Id: hal-03133144 https://hal.inria.fr/hal-03133144 Preprint submitted on 5 Feb 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Types are Internal 1-groupoids Antoine Allioux∗, Eric Finstery, Matthieu Sozeauz ∗Inria & University of Paris, France [email protected] yUniversity of Birmingham, United Kingdom ericfi[email protected] zInria, France [email protected] Abstract—By extending type theory with a universe of defini- attempts to import these ideas into plain homotopy type theory tionally associative and unital polynomial monads, we show how have, so far, failed. This appears to be a result of a kind of to arrive at a definition of opetopic type which is able to encode circularity: all of the known classical techniques at some point a number of fully coherent algebraic structures. In particular, our approach leads to a definition of 1-groupoid internal to rely on set-level algebraic structures themselves (presheaves, type theory and we prove that the type of such 1-groupoids is operads, or something similar) as a means of presenting or equivalent to the universe of types.
    [Show full text]
  • Sequent Calculus and Equational Programming (Work in Progress)
    Sequent Calculus and Equational Programming (work in progress) Nicolas Guenot and Daniel Gustafsson IT University of Copenhagen {ngue,dagu}@itu.dk Proof assistants and programming languages based on type theories usually come in two flavours: one is based on the standard natural deduction presentation of type theory and involves eliminators, while the other provides a syntax in equational style. We show here that the equational approach corresponds to the use of a focused presentation of a type theory expressed as a sequent calculus. A typed functional language is presented, based on a sequent calculus, that we relate to the syntax and internal language of Agda. In particular, we discuss the use of patterns and case splittings, as well as rules implementing inductive reasoning and dependent products and sums. 1 Programming with Equations Functional programming has proved extremely useful in making the task of writing correct software more abstract and thus less tied to the specific, and complex, architecture of modern computers. This, is in a large part, due to its extensive use of types as an abstraction mechanism, specifying in a crisp way the intended behaviour of a program, but it also relies on its declarative style, as a mathematical approach to functions and data structures. However, the vast gain in expressivity obtained through the development of dependent types makes the programming task more challenging, as it amounts to the question of proving complex theorems — as illustrated by the double nature of proof assistants such as Coq [11] and Agda [18]. Keeping this task as simple as possible is then of the highest importance, and it requires the use of a clear declarative style.
    [Show full text]
  • On Modeling Homotopy Type Theory in Higher Toposes
    Review: model categories for type theory Left exact localizations Injective fibrations On modeling homotopy type theory in higher toposes Mike Shulman1 1(University of San Diego) Midwest homotopy type theory seminar Indiana University Bloomington March 9, 2019 Review: model categories for type theory Left exact localizations Injective fibrations Here we go Theorem Every Grothendieck (1; 1)-topos can be presented by a model category that interprets \Book" Homotopy Type Theory with: • Σ-types, a unit type, Π-types with function extensionality, and identity types. • Strict universes, closed under all the above type formers, and satisfying univalence and the propositional resizing axiom. Review: model categories for type theory Left exact localizations Injective fibrations Here we go Theorem Every Grothendieck (1; 1)-topos can be presented by a model category that interprets \Book" Homotopy Type Theory with: • Σ-types, a unit type, Π-types with function extensionality, and identity types. • Strict universes, closed under all the above type formers, and satisfying univalence and the propositional resizing axiom. Review: model categories for type theory Left exact localizations Injective fibrations Some caveats 1 Classical metatheory: ZFC with inaccessible cardinals. 2 Classical homotopy theory: simplicial sets. (It's not clear which cubical sets can even model the (1; 1)-topos of 1-groupoids.) 3 Will not mention \elementary (1; 1)-toposes" (though we can deduce partial results about them by Yoneda embedding). 4 Not the full \internal language hypothesis" that some \homotopy theory of type theories" is equivalent to the homotopy theory of some kind of (1; 1)-category. Only a unidirectional interpretation | in the useful direction! 5 We assume the initiality hypothesis: a \model of type theory" means a CwF.
    [Show full text]
  • Irrelevance, Heterogeneous Equality, and Call-By-Value Dependent Type Systems
    Irrelevance, Heterogeneous Equality, and Call-by-value Dependent Type Systems Vilhelm Sjoberg¨ Chris Casinghino Ki Yung Ahn University of Pennsylvania University of Pennsylvania Portland State University [email protected] [email protected] [email protected] Nathan Collins Harley D. Eades III Peng Fu Portland State University University of Iowa University of Iowa [email protected] [email protected] [email protected] Garrin Kimmell Tim Sheard Aaron Stump University of Iowa Portland State University University of Iowa [email protected] [email protected] [email protected] Stephanie Weirich University of Pennsylvania [email protected] We present a full-spectrum dependently typed core language which includes both nontermination and computational irrelevance (a.k.a. erasure), a combination which has not been studied before. The two features interact: to protect type safety we must be careful to only erase terminating expressions. Our language design is strongly influenced by the choice of CBV evaluation, and by our novel treatment of propositional equality which has a heterogeneous, completely erased elimination form. 1 Introduction The Trellys project is a collaborative effort to design a new dependently typed programming language. Our goal is to bridge the gap between ordinary functional programming and program verification with dependent types. Programmers should be able to port their existing functional programs to Trellys with minor modifications, and then gradually add more expressive types as appropriate. This goal has implications for our design. First, and most importantly, we must consider nonter- mination and other effects. Unlike Coq and Agda, functional programming languages like OCaml and Haskell allow general recursive functions, so to accept functional programs ‘as-is’ we must be able to turn off the termination checker.
    [Show full text]
  • The Common HOL Platform
    The Common HOL Platform Mark Adams Proof Technologies Ltd, UK Radboud University, Nijmegen, The Netherlands The Common HOL project aims to facilitate porting source code and proofs between members of the HOL family of theorem provers. At the heart of the project is the Common HOL Platform, which defines a standard HOL theory and API that aims to be compatible with all HOL systems. So far, HOL Light and hol90 have been adapted for conformance, and HOL Zero was originally developed to conform. In this paper we provide motivation for a platform, give an overview of the Common HOL Platform’s theory and API components, and show how to adapt legacy systems. We also report on the platform’s successful application in the hand-translation of a few thousand lines of source code from HOL Light to HOL Zero. 1 Introduction The HOL family of theorem provers started in the 1980s with HOL88 [5], and has since grown to include many systems, most prominently HOL4 [16], HOL Light [8], ProofPower HOL [3] and Is- abelle/HOL [12]. These four main systems have developed their own advanced proof facilities and extensive theory libraries, and have been successfully employed in major projects in the verification of critical hardware and software [1, 11] and the formalisation of mathematics [7]. It would clearly be of benefit if these systems could “talk” to each other, specifically if theory, proofs and source code could be exchanged in a relatively seamless manner. This would reduce the considerable duplication of effort otherwise required for one system to benefit from the major projects and advanced capabilities developed on another.
    [Show full text]
  • Proof-Assistants Using Dependent Type Systems
    CHAPTER 18 Proof-Assistants Using Dependent Type Systems Henk Barendregt Herman Geuvers Contents I Proof checking 1151 2 Type-theoretic notions for proof checking 1153 2.1 Proof checking mathematical statements 1153 2.2 Propositions as types 1156 2.3 Examples of proofs as terms 1157 2.4 Intermezzo: Logical frameworks. 1160 2.5 Functions: algorithms versus graphs 1164 2.6 Subject Reduction . 1166 2.7 Conversion and Computation 1166 2.8 Equality . 1168 2.9 Connection between logic and type theory 1175 3 Type systems for proof checking 1180 3. l Higher order predicate logic . 1181 3.2 Higher order typed A-calculus . 1185 3.3 Pure Type Systems 1196 3.4 Properties of P ure Type Systems . 1199 3.5 Extensions of Pure Type Systems 1202 3.6 Products and Sums 1202 3.7 E-typcs 1204 3.8 Inductive Types 1206 4 Proof-development in type systems 1211 4.1 Tactics 1212 4.2 Examples of Proof Development 1214 4.3 Autarkic Computations 1220 5 P roof assistants 1223 5.1 Comparing proof-assistants . 1224 5.2 Applications of proof-assistants 1228 Bibliography 1230 Index 1235 Name index 1238 HANDBOOK OF AUTOMAT8D REASONING Edited by Alan Robinson and Andrei Voronkov © 2001 Elsevier Science Publishers 8.V. All rights reserved PROOF-ASSISTANTS USING DEPENDENT TYPE SYSTEMS 1151 I. Proof checking Proof checking consists of the automated verification of mathematical theories by first fully formalizing the underlying primitive notions, the definitions, the axioms and the proofs. Then the definitions are checked for their well-formedness and the proofs for their correctness, all this within a given logic.
    [Show full text]
  • Interactive Theorem Proving (ITP) Course Web Version
    Interactive Theorem Proving (ITP) Course Web Version Thomas Tuerk ([email protected]) Except where otherwise noted, this work is licened under Creative Commons Attribution-ShareAlike 4.0 International License version 3c35cc2 of Mon Nov 11 10:22:43 2019 Contents Part I Preface 3 Part II Introduction 6 Part III HOL 4 History and Architecture 16 Part IV HOL's Logic 24 Part V Basic HOL Usage 38 Part VI Forward Proofs 46 Part VII Backward Proofs 61 Part VIII Basic Tactics 83 Part IX Induction Proofs 110 Part X Basic Definitions 119 Part XI Good Definitions 163 Part XII Deep and Shallow Embeddings 184 Part XIII Rewriting 192 Part XIV Advanced Definition Principles 246 Part XV Maintainable Proofs 267 Part XVI Overview of HOL 4 289 Part XVII Other Interactive Theorem Provers 302 2 / 315 Part I Preface Except where otherwise noted, this work is licened under Creative Commons Attribution-ShareAlike 4.0 International License. Preface these slides originate from a course for advanced master students it was given by the PROSPER group at KTH in Stockholm in 2017 (see https://www.kth.se/social/group/interactive-theorem-) the course focused on how to use HOL 4 students taking the course were expected to I know functional programming, esp. SML I understand predicate logic I have some experience with pen and paper proofs the course consisted of 9 lectures, which each took 90 minutes there were 19 supervised practical sessions, which each took 2 h usually there was 1 lecture and 2 practical sessions each week students were expected to work about 10 h each
    [Show full text]
  • HOL-Testgen Version 1.8 USER GUIDE
    HOL-TestGen Version 1.8 USER GUIDE Achim Brucker, Lukas Brügger, Abderrahmane Feliachi, Chantal Keller, Matthias Krieger, Delphine Longuet, Yakoub Nemouchi, Frédéric Tuong, Burkhart Wolff To cite this version: Achim Brucker, Lukas Brügger, Abderrahmane Feliachi, Chantal Keller, Matthias Krieger, et al.. HOL-TestGen Version 1.8 USER GUIDE. [Technical Report] Univeristé Paris-Saclay; LRI - CNRS, University Paris-Sud. 2016. hal-01765526 HAL Id: hal-01765526 https://hal.inria.fr/hal-01765526 Submitted on 12 Apr 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. R L R I A P P O R HOL-TestGen Version 1.8 USER GUIDE T BRUCKER A D / BRUGGER L / FELIACHI A / KELLER C / KRIEGER M P / LONGUET D / NEMOUCHI Y / TUONG F / WOLFF B D Unité Mixte de Recherche 8623 E CNRS-Université Paris Sud-LRI 04/2016 R Rapport de Recherche N° 1586 E C H E R C CNRS – Université de Paris Sud H Centre d’Orsay LABORATOIRE DE RECHERCHE EN INFORMATIQUE E Bâtiment 650 91405 ORSAY Cedex (France) HOL-TestGen 1.8.0 User Guide http://www.brucker.ch/projects/hol-testgen/ Achim D. Brucker Lukas Brügger Abderrahmane Feliachi Chantal Keller Matthias P.
    [Show full text]
  • Why Dependent Types Matter
    Why Dependent Types Matter Thorsten Altenkirch Conor McBride James McKinna The University of Nottingham The University of St Andrews {txa,ctm}@cs.nott.ac.uk [email protected] Abstract 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. Introduction Types matter. That’s what they’re for—to classify data with respect to criteria which matter: how they should be stored in memory, whether they can be safely passed as inputs to a given operation, even who is allowed to see them. Dependent types are types expressed in terms of data, explicitly relating their inhabitants to that data. As such, they enable you to express more of what matters about data. While conventional type systems allow us to validate our programs with respect to a fixed set of criteria, dependent types are much more flexible, they realize a continuum of precision from the basic assertions we are used to expect from types up to a complete specification of the program’s behaviour. It is the programmer’s choice to what degree he wants to exploit the expressiveness of such a powerful type discipline. While the price for formally certified software may be high, it is good to know that we can pay it in installments and that we are free to decide how far we want to go.
    [Show full text]
  • Proof Theory of Constructive Systems: Inductive Types and Univalence
    Proof Theory of Constructive Systems: Inductive Types and Univalence Michael Rathjen Department of Pure Mathematics University of Leeds Leeds LS2 9JT, England [email protected] Abstract In Feferman’s work, explicit mathematics and theories of generalized inductive definitions play a cen- tral role. One objective of this article is to describe the connections with Martin-L¨of type theory and constructive Zermelo-Fraenkel set theory. Proof theory has contributed to a deeper grasp of the rela- tionship between different frameworks for constructive mathematics. Some of the reductions are known only through ordinal-theoretic characterizations. The paper also addresses the strength of Voevodsky’s univalence axiom. A further goal is to investigate the strength of intuitionistic theories of generalized inductive definitions in the framework of intuitionistic explicit mathematics that lie beyond the reach of Martin-L¨of type theory. Key words: Explicit mathematics, constructive Zermelo-Fraenkel set theory, Martin-L¨of type theory, univalence axiom, proof-theoretic strength MSC 03F30 03F50 03C62 1 Introduction Intuitionistic systems of inductive definitions have figured prominently in Solomon Feferman’s program of reducing classical subsystems of analysis and theories of iterated inductive definitions to constructive theories of various kinds. In the special case of classical theories of finitely as well as transfinitely iterated inductive definitions, where the iteration occurs along a computable well-ordering, the program was mainly completed by Buchholz, Pohlers, and Sieg more than 30 years ago (see [13, 19]). For stronger theories of inductive 1 i definitions such as those based on Feferman’s intutitionic Explicit Mathematics (T0) some answers have been provided in the last 10 years while some questions are still open.
    [Show full text]
  • CS 6110 S18 Lecture 32 Dependent Types 1 Typing Lists with Lengths
    CS 6110 S18 Lecture 32 Dependent Types When we added kinding last time, part of the motivation was to complement the functions from types to terms that we had in System F with functions from types to types. Of course, all of these languages have plain functions from terms to terms. So it's natural to wonder what would happen if we added functions from values to types. The result is a language with \compile-time" types that can depend on \run-time" values. While this arrangement might seem paradoxical, it is a very powerful way to express the correctness of programs; and via the propositions-as-types principle, it also serves as the foundation for a modern crop of interactive theorem provers. The language feature is called dependent types (i.e., types depend on terms). Prominent dependently-typed languages include Coq, Nuprl, Agda, Lean, F*, and Idris. Some of these languages, like Coq and Nuprl, are more oriented toward proving things using propositions as types, and others, like F* and Idris, are more oriented toward writing \normal programs" with strong correctness guarantees. 1 Typing Lists with Lengths Dependent types can help avoid out-of-bounds errors by encoding the lengths of arrays as part of their type. Consider a plain recursive IList type that represents a list of any length. Using type operators, we might use a general type List that can be instantiated as List int, so its kind would be type ) type. But let's use a fixed element type for now. With dependent types, however, we can make IList a type constructor that takes a natural number as an argument, so IList n is a list of length n.
    [Show full text]
  • Reasoning in an ∞-Topos with Homotopy Type Theory
    Reasoning in an 1-topos with homotopy type theory Dan Christensen University of Western Ontario 1-Topos Institute, April 1, 2021 Outline: Introduction to homotopy type theory Examples of applications to 1-toposes 1 / 23 2 / 23 Motivation for Homotopy Type Theory People study type theory for many reasons. I'll highlight two: Its intrinsic homotopical/topological content. Things we prove in type theory are true in any 1-topos. Its suitability for computer formalization. This talk will focus on the first point. So, what is an 1-topos? 3 / 23 1-toposes An 1-category has objects, (1-)morphisms between objects, 2-morphisms between 1-morphisms, etc., with all k-morphisms invertible for k > 1. Alternatively: a category enriched over spaces. The prototypical example is the 1-category of spaces. An 1-topos is an 1-category C that shares many properties of the 1-category of spaces: C is presentable. In particular, C is cocomplete. C satisfies descent. In particular, C is locally cartesian closed. Examples include Spaces, slice categories such as Spaces/S1, and presheaves of Spaces, such as G-Spaces for a group G. If C is an 1-topos, so is every slice category C=X. 4 / 23 History of (Homotopy) Type Theory Dependent type theory was introduced in the 1970's by Per Martin-L¨of,building on work of Russell, Church and others. In 2006, Awodey, Warren, and Voevodsky discovered that dependent type theory has homotopical models, extending 1998 work of Hofmann and Streicher. At around this time, Voevodsky discovered his univalance axiom.
    [Show full text]