DOCSLIB.ORG

What Is a Recursive Module?*

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
What Is a Recursive Module?* What is a Recursive Module?* Karl Gary Robert Harper Sidd Puri Carnegie Mellon University Carnegie Mellon University Microsoft Corporation Abstract also support parameterized, or generic, modules to bet- ter support code reuse. A hierarchical module system is an effective tool for There is no question that hierarchical design is an structuring large programs. Strictly hierarchical mod- important tool for structuring large systems. It has of- ule systems impose an acyclic ordering on import depen- ten been noted, however, that strict adherence to a hi- dencies among program units. This can impede modu- erarchical architecture can preclude the decomposition lar programming by forcing mutually-dependent compo- of a system into “mind-sized” components. In some nents to be consolidated into a single module. Recently situations the natural decomposition of a system into there have been several proposals for module systems modules introduces cyclic dependencies, which cannot that admit cyclic dependencies, but it is not clear how be expressed in a purely hierarchical formalism. The these proposals relate to one another, nor how one might only solution is to consolidate mutually-dependent frag- integrate them into an expressive module system such ments into a single module, which partially undermines as that of ML. the very idea of modular organization. To address this question we provide a type-theoretic In response several authors have proposed linguis- analysis of the notion of a recursive module in the con- tic mechanisms to support non-hierarchical modular text of a “phase-distinction” formalism for higher-order decomposition. Recent examples include: Sirer, et module systems. We extend this calculus with a recur- al.‘s extension of Modula-3 with a “cross-linking” sive module mechanism and a new form of signature, mechanism [21]; Flatt and Felleisen’s extension of called a recursively dependent signature, to support the their MzScheme language with cyclically-dependent definition of recursive modules. These extensions are “units” [8]; Duggan and Sourelis’s “mixin modules” that justified by an interpretation in terms of more primitive extend the Standard ML module system with a special language constructs. This interpretation may also serve “mixlink” construct for integrating mutually-dependent as a guide for implementation. structures [6, 71; and Ancona and Zucca’s algebraic for- malism for mixin modules [2]. Each of these proposals 1 Introduction seeks to address the problem of cyclic dependencies in a module system, but each does so in a slightly. different Hierarchical decomposition is a fundamental design way. For example, Flatt and Felleisen’s formalism does principle for controlling the complexity of large pro- not address the critical issue of controlling propagation grams. According to this principle a software sys- of type information across module boundaries. Duggan tem is to be decomposed into a collection of modules and Sourelis’s framework relies on a syntactic transfor- whose dependency relationships form a directed, acyclic mation that, in effect, coalesces the code of mutually- graph. Most modern programming languages include dependent modules into a single module. It is not clear module systems that support hierarchical decomposi- what are the fundamental ideas, nor is it clear how to tion. Many, such as Standard ML [16] and O’Caml[14], integrate the various aspects of these proposals into a full-featured module system. ‘This research was sponsored by the Advanced Research It is natural to ask: what is a recursive module? We Projects Agency CSTO under the title “The Fox Project: Ad- vanced Languages for Systems Software”, ARPA Order No. propose to address this question in the framework of C533, issued by ESC/ENS under Contract No. F19628-95-C- type theory, which has proved to be a powerful tool for 0050. The views and conclusions contained in this document are both the design and implementation of module systems. those of the authors and should not be interpreted as represent- We conduct our analysis in the context of the “phase ing official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S. Government. distinction” module formalism introduced by Harper, Mitchell, and Moggi [ll] (hereafter, HMM), augmented Permission to make digital or hard copies of all or part of this work for to support recursive types and functions, and to support personal or classroom uss is granted without fee provided that type definitions in signatures [9, 131. The phase distinc- copies are not made or distributed for profit or commercial advan- tion tage and that copies bear this notice and the full citation On the first Page. calculus provides a rigorous account of higher-order To copy otherwise, to republish, to post on servers or to modules (supporting hierarchy and parameterization) in redistribute to lists, requires prior specific permission and/or a fee. a framework that makes explicit the critical distinction SIGPLAN ‘99 (PLDI) 5/99 Atlanta, GA., USA between the static, or compile-time, part of a module 0 1999 ACM l-581 13-033.3/99/001 l-85.00 50 and the dynamic, or run-time, part. This calculus has structure calculus, extending the core language with proved to be of fundamental importance to the imple- a primitive module construct without explicit mecha- mentation of higher-order modules, as evidenced by its nisms for hierarchy (e.g., substructures) or parameter- use in Shao’s FLINT formalism used in the SML/NJ ization (e.g., functors). Primitive modules consist of a compiler [18, 201 and in the TIL/ML compiler [23]. static, or compile-time, part containing the type con- Our analysis proceeds in two stages. First we con- structors of the module, together with a dynamic, or sider a straightforward extension of the phase distinc- run-time, part containing the executable code of the tion calculus with a notion of recursive (self-referential) module. This separation is known as the phase distinc- module. An interpretation of this new construct is pro- tion. An important property of the formalism is that vided by an interpretation of it into the primitive mod- the phase distinction is maintained, even in the pres- ule formalism of the phase distinction calculus. This ence of higher-order (and, as we shall see, recursive) interpretation renders the compile-time part as a recur- module constructs. sive type and the run-time part as a recursive function, The main result of HMM is that higher-order mod- as might be expected. In essence a recursive module is ule constructs are a definitional extension of the prim- just a convenient way of introducing recursive types and itive structure calculus. In other words higher-order functions. constructs are already present in the primitive struc- Unfortunately this simple-minded extension does ture calculus in the sense that they may be defined in not go far enough to be of much practical use. As Dug- terms of existing constructs. (This interpretation may gan and Sourelis have observed [7], it is of critical impor- be thought of as a compilation strategy for higher-order tance for most practical examples that the type equa- modules, and indeed this fact has been exploited in the tions that hold of a recursive module be propagated into FLINT [20] and TIL [23] compilers.) This means that the definition of the recursive module itself. In essence we need not explicitly discuss higher-order module con- the definitions of the type components of a recursive structs in this paper, but rather appeal to HMM for a module must be taken to be the types that they will detailed discussion of their implicit presence. eventually turn out to be once the recursive declara- To support the extension with recursive modules we tion has been processed. Accounting for this “forward enrich the core phase distinction calculus with these ad- reference” is the core contribution of our work. We in- ditional constructs: troduce a new form of signature (interface) for recursive modules, called a recursively dependent signature, that Singleton and dependent kinds to allow expression allows us to capture the required type identities during of type sharing information in signatures. Related type checking of a recursive module binding. This sig- formalisms for expressing type sharing informa- nificantly increases the expressive power of the recursive tion are given by Harper and Lillibridge [9] and module formalism, and is, we assert, of fundamental im- Leroy [13]. portance to the very idea of recursive modules. A fixed point operation for building collections In this paper we aim to focus on the core issues lying of mutually-recursive type constructors. These at the center of a recursive module system, so we study recursive constructors are definitionally equal to recursive modules in the framework of a small internal their unrollings. We term such constructors equi- language that is sufficient to bring out the main issues recursive, to distinguish them from the more con- and that could be used by a type-directed compiler to ventional iso-recursive constructors, for which con- implement recursive modules. Therefore, we make no versions between the constructors and their un- specific proposals as to what form an external language rollings must be mediated by the explicit use of supporting recursive modules should take, although we an isomorphism. We discuss the interplay of equi- do present most of our examples in a hypothetical ex- and iso-recursive constructors in Section 5.3. ternal language. Indeed, some important questions re- garding the design of an external language remain open, A fixed point operation for building collections of such as the practicality of typechecking. In Section 5 we mutually-recursive functions. As will become ap- make some observations and preliminary proposals re- parent later on, we cannot (as in SML) limit this garding the design of an external language.
Load more

Recommended publications
  • Methods for Fitting the Linear Ballistic Accumulator
    Behavior Research Methods 2009, 41 (4), 1095-1110 doi:10.3758/BRM.41.4.1095 Getting more from accuracy and response time data: Methods for fitting the linear ballistic accumulator CHRIS DONKIN , LEE A VERE ll , SC OTT BROWN , A N D A N D REW HE ATH C OTE University of Newcastle, Callaghan, New South Wales, Australia Cognitive models of the decision process provide greater insight into response time and accuracy than do stan- dard ANOVA techniques. However, such models can be mathematically and computationally difficult to apply. We provide instructions and computer code for three methods for estimating the parameters of the linear ballistic accumulator (LBA), a new and computationally tractable model of decisions between two or more choices. These methods—a Microsoft Excel worksheet, scripts for the statistical program R, and code for implementation of the LBA into the Bayesian sampling software WinBUGS—vary in their flexibility and user accessibility. We also provide scripts in R that produce a graphical summary of the data and model predictions. In a simulation study, we explored the effect of sample size on parameter recovery for each method. The materials discussed in this article may be downloaded as a supplement from http://brm.psychonomic-journals.org/content/supplemental. Many tasks used in experimental psychology involve edly samples information from the environment and that participants making relatively simple decisions, for which this information is used as evidence for one of the potential the experimenter measures the response times (RTs) and responses. As soon as the evidence in favor of one potential the accuracy of the responses.
    [Show full text]
  • Indexed Induction-Recursion
    Indexed Induction-Recursion Peter Dybjer a;? aDepartment of Computer Science and Engineering, Chalmers University of Technology, 412 96 G¨oteborg, Sweden Email: [email protected], http://www.cs.chalmers.se/∼peterd/, Tel: +46 31 772 1035, Fax: +46 31 772 3663. Anton Setzer b;1 bDepartment of Computer Science, University of Wales Swansea, Singleton Park, Swansea SA2 8PP, UK, Email: [email protected], http://www.cs.swan.ac.uk/∼csetzer/, Tel: +44 1792 513368, Fax: +44 1792 295651. Abstract An indexed inductive definition (IID) is a simultaneous inductive definition of an indexed family of sets. An inductive-recursive definition (IRD) is a simultaneous inductive definition of a set and a recursive definition of a function from that set into another type. An indexed inductive-recursive definition (IIRD) is a combination of both. We present a closed theory which allows us to introduce all IIRDs in a natural way without much encoding. By specialising it we also get a closed theory of IID. Our theory of IIRDs includes essentially all definitions of sets which occur in Martin-L¨of type theory. We show in particular that Martin-L¨of's computability predicates for dependent types and Palmgren's higher order universes are special kinds of IIRD and thereby clarify why they are constructively acceptable notions. We give two axiomatisations. The first and more restricted one formalises a prin- ciple for introducing meaningful IIRD by using the data-construct in the original version of the proof assistant Agda for Martin-L¨of type theory. The second one admits a more general form of introduction rule, including the introduction rule for the intensional identity relation, which is not covered by the restricted one.
    [Show full text]
  • Formal Systems: Combinatory Logic and -Calculus
    INTRODUCTION APPLICATIVE SYSTEMS USEFUL INFORMATION FORMAL SYSTEMS:COMBINATORY LOGIC AND λ-CALCULUS Andrew R. Plummer Department of Linguistics The Ohio State University 30 Sept., 2009 INTRODUCTION APPLICATIVE SYSTEMS USEFUL INFORMATION OUTLINE 1 INTRODUCTION 2 APPLICATIVE SYSTEMS 3 USEFUL INFORMATION INTRODUCTION APPLICATIVE SYSTEMS USEFUL INFORMATION COMBINATORY LOGIC We present the foundations of Combinatory Logic and the λ-calculus. We mean to precisely demonstrate their similarities and differences. CURRY AND FEYS (KOREAN FACE) The material discussed is drawn from: Combinatory Logic Vol. 1, (1958) Curry and Feys. Lambda-Calculus and Combinators, (2008) Hindley and Seldin. INTRODUCTION APPLICATIVE SYSTEMS USEFUL INFORMATION FORMAL SYSTEMS We begin with some definitions. FORMAL SYSTEMS A formal system is composed of: A set of terms; A set of statements about terms; A set of statements, which are true, called theorems. INTRODUCTION APPLICATIVE SYSTEMS USEFUL INFORMATION FORMAL SYSTEMS TERMS We are given a set of atomic terms, which are unanalyzed primitives. We are also given a set of operations, each of which is a mode for combining a finite sequence of terms to form a new term. Finally, we are given a set of term formation rules detailing how to use the operations to form terms. INTRODUCTION APPLICATIVE SYSTEMS USEFUL INFORMATION FORMAL SYSTEMS STATEMENTS We are given a set of predicates, each of which is a mode for forming a statement from a finite sequence of terms. We are given a set of statement formation rules detailing how to use the predicates to form statements. INTRODUCTION APPLICATIVE SYSTEMS USEFUL INFORMATION FORMAL SYSTEMS THEOREMS We are given a set of axioms, each of which is a statement that is unconditionally true (and thus a theorem).
    [Show full text]
  • MODULA-2 TRANSLATOR USER's MANUAL First Edition May 1986
    LOGITECH SOFTWARE ENGINEERING LIBRARY PASCAL TO MODULA-2 TRANSLATOR USER'S MANUAL First Edition May 1986 Copyright (C) 1984, 1985, 1986, 1987 LOGITECH, Inc. All Rights Reserved. No part of this document may be copied or reproduced in any form or by any means without the prior written consent of LOGITECH, Inc. LOGITECH, MODULA-2186,and MODULA-2IVX86 are trademarks ofLOGITECH, Inc. Microsoft is a registered trademark of Microsoft Corporation. MS-DOS is a trademark of Microsoft Corporation. Intel is a registered trademark ofIntel Corporation. IBM is a registered trademark ofInternational Business Machines Corporation. Turbo Pascal is a registered trademark ofBorland International, Inc. LOGITECH, Inc. makes no warranties with respect to this documentation and disclaims any implied warranties of merchantability and fitness for a particular purpose. The information in this document is subject to change without notice. LOGITECH, Inc. assumes no responsibility for any errors that may appear in this document. From time to time changes may occur in the filenames and in the files actually included on the distribution disks. LOGITECH, Inc. makes no warranties that such files or facilities as mentioned in this documentation exist on the distribution disks or as part of the materials distributed. LU-GUllO-1 Initial issue: May 1986 Reprinted: September 1987 This edition applies to Release 1.00 or later of the software. ii TRANSLATOR Preface LOGITECH'S POLICIES AND SERVICES Congratulations on the purchase of your LOGITECH Pascal To Modula-2 Translator. Please refer to the following infonnation for details about LOGITECH's policies and services. We feel that effective communication with our customers is the key to quality service.
    [Show full text]
  • Wittgenstein, Turing and Gödel
    Wittgenstein, Turing and Gödel Juliet Floyd Boston University Lichtenberg-Kolleg, Georg August Universität Göttingen Japan Philosophy of Science Association Meeting, Tokyo, Japan 12 June 2010 Wittgenstein on Turing (1946) RPP I 1096. Turing's 'Machines'. These machines are humans who calculate. And one might express what he says also in the form of games. And the interesting games would be such as brought one via certain rules to nonsensical instructions. I am thinking of games like the “racing game”. One has received the order "Go on in the same way" when this makes no sense, say because one has got into a circle. For that order makes sense only in certain positions. (Watson.) Talk Outline: Wittgenstein’s remarks on mathematics and logic Turing and Wittgenstein Gödel on Turing compared Wittgenstein on Mathematics and Logic . The most dismissed part of his writings {although not by Felix Mülhölzer – BGM III} . Accounting for Wittgenstein’s obsession with the intuitive (e.g. pictures, models, aspect perception) . No principled finitism in Wittgenstein . Detail the development of Wittgenstein’s remarks against background of the mathematics of his day Machine metaphors in Wittgenstein Proof in logic is a “mechanical” expedient Logical symbolisms/mathematical theories are “calculi” with “proof machinery” Proofs in mathematics (e.g. by induction) exhibit or show algorithms PR, PG, BB: “Can a machine think?” Language (thought) as a mechanism Pianola Reading Machines, the Machine as Symbolizing its own actions, “Is the human body a thinking machine?” is not an empirical question Turing Machines Turing resolved Hilbert’s Entscheidungsproblem (posed in 1928): Find a definite method by which every statement of mathematics expressed formally in an axiomatic system can be determined to be true or false based on the axioms.
    [Show full text]
  • Clouds and the Earth's Radiant Energy System (CERES) Data Management System
    NASA'S MISSION TO PLANET EARTH EARTH PROBES EOS DATA INFORMATION SYSTEM EARTH OBSERVING SYSTEM National Aeronautics and Space Administration Langley Research Center Hampton, Virginia 23681-2199 Clouds and the Earth's Radiant Energy System (CERES) Data Management System View HDF User's Guide S RA TH DIA AR N E T E E N H E T R D G N Y A CERES S S Y D S U T E O M L Version 5.0 C November 2007 NASA Clouds and the Earth's Radiant Energy System (CERES) Data Management System View_Hdf User’s Guide Version 5.0 Primary Author Kam-Pui Lee Science Systems and Applications, Inc. (SSAI) One Enterprise Parkway Hampton, Virginia 23666 November 2007 TABLE OF CONTENTS Section Page 1.0 Introduction . 1 2.0 Installation . 2 3.0 How to Start . 4 4.0 GUI Description . 12 4.1 Main Menu . 15 4.2 Select Function Menu . 68 4.3 Plot Window Menu . 92 5.0 Recognized Variable Names . 107 6.0 Configuration File . 111 7.0 Examples . 114 8.0 References . 132 9.0 List of Acronyms . 133 10.0 Data Center/Data Access Information . 134 iii LIST OF FIGURES Figure Page Fig. 3-1. Main Menu . 4 Fig. 3-2. File Menu . 5 Fig. 3-3. Select File Window . 5 Fig. 3-4. List SDS and Vdata Names . 6 Fig. 3-5. SDS Range Input Window . 7 Fig. 3-6. Import SDS . 7 Fig. 3-7. Vdata Fields Window . 8 Fig. 3-8. Vdata Field Range Window . 8 Fig. 3-9.
    [Show full text]
  • Warum Unix-Ports Pascal Bis Oberon in Der Bremer Informatik
    Warum Unix-Ports Pascal bis Oberon in der Bremer Informatik Günter Feldmann Universität Bremen [email protected] 1970th, Dept. of Electrical Engineering ● 1974/75: first university computer CII-Honeywell Bull, IRIS-80 ● first Pascal port from a university in Paris. ● learned Pascal by reading the compiler sources ● engineers needed 64-bit REALS, compiler got modified accordingly ● compiling and linking the compiler took 2 days ● N. Wirth: Systematisches Programmieren Since 1981, Dept. of Mathematics and Computer Science ● first personal computers: DEC PDT 11 ● PDP11 instruction set, but some instructions were missing, these had to be emulated in software as the interpreters and compilers used them. ● UCSD Pascal and some times a Modula (not Modula-2) compiler under RT11. ● Small local area network via V24 connections Computer Science ● A series of different computers ● DEC PDP11/44, BSD Unix ● DEC VAX 750 with 8 VT100 terminals, BSD Unix ● 30 Atari 520 ST (M6800) ● 20 Sun3 Workstations (M6820) ● all machines were equipped with Pascal and/or Modula-2 compilers ● Some machines (Pascal Microengine, PERQ) were microprogrammed for Pascal (p-code, Q- code) Computer Science ● workstation pool for students ● 30 machines (1986), 100 machines today ● in the beginning of 1990th we acquired Sun4 workstations (SPARC). No Modula-2 compiler! ● ETHZ released the SPARC Oberon system hosted by SunOS. This system was used in the course “Software Projekt” until 1996. Then “Java” came … ● programming courses got replaced by courses in “internet programming” Keeping Oberon alive on our hardware ● OS change: SunOS (BSD) to Solaris (SYSVR4) ● despite binary compatibility SPARC Oberon failed. Oberon compiler used registers reserved for usage by the system.
    [Show full text]
  • Warren Goldfarb, Notes on Metamathematics
    Notes on Metamathematics Warren Goldfarb W.B. Pearson Professor of Modern Mathematics and Mathematical Logic Department of Philosophy Harvard University DRAFT: January 1, 2018 In Memory of Burton Dreben (1927{1999), whose spirited teaching on G¨odeliantopics provided the original inspiration for these Notes. Contents 1 Axiomatics 1 1.1 Formal languages . 1 1.2 Axioms and rules of inference . 5 1.3 Natural numbers: the successor function . 9 1.4 General notions . 13 1.5 Peano Arithmetic. 15 1.6 Basic laws of arithmetic . 18 2 G¨odel'sProof 23 2.1 G¨odelnumbering . 23 2.2 Primitive recursive functions and relations . 25 2.3 Arithmetization of syntax . 30 2.4 Numeralwise representability . 35 2.5 Proof of incompleteness . 37 2.6 `I am not derivable' . 40 3 Formalized Metamathematics 43 3.1 The Fixed Point Lemma . 43 3.2 G¨odel'sSecond Incompleteness Theorem . 47 3.3 The First Incompleteness Theorem Sharpened . 52 3.4 L¨ob'sTheorem . 55 4 Formalizing Primitive Recursion 59 4.1 ∆0,Σ1, and Π1 formulas . 59 4.2 Σ1-completeness and Σ1-soundness . 61 4.3 Proof of Representability . 63 3 5 Formalized Semantics 69 5.1 Tarski's Theorem . 69 5.2 Defining truth for LPA .......................... 72 5.3 Uses of the truth-definition . 74 5.4 Second-order Arithmetic . 76 5.5 Partial truth predicates . 79 5.6 Truth for other languages . 81 6 Computability 85 6.1 Computability . 85 6.2 Recursive and partial recursive functions . 87 6.3 The Normal Form Theorem and the Halting Problem . 91 6.4 Turing Machines .
    [Show full text]
  • Towards Mathix / Math-X, a Computer Algebra Language That Can Create Its Own Operating System, and That Is Amazingly User- Friendly and Secure
    Towards Mathix / Math-x, a computer algebra language that can create its own operating system, and that is amazingly user- friendly and secure Thomas Colignatus, August 19 2009, some clarifications August 23 2009 http://www.dataweb.nl/~cool Summary Given the current supply and demand for computer languages and systems, there is a clear window of opportunity for the software community to collaborate and create Mathix and Math-x. The base would be Oberon, which itself derives from Algol / Pascal / Modula and which is better designed than Unix / Linux, and which now has the system Bluebottle / A2 at http://bluebottle.ethz.ch. Mathix is defined as Oberon/A2 extended with a suitable computer algebra language (say, CAL). Math-x is defined as Minix ported to Oberon/A2 (via Cyclone) and extended with that CAL. Mathix and Math-x thus can create their own OS. Mathix and Math-x are flexible in that they contain both a strongly typed dialect relevant for OS creation (current Oberon) and a more flexible dialect relevant for the human user (CAL, to be created). The dialects have much syntax in common but the CAL allows more flexibility. The CAL is internally translated into Oberon/A2 which allows compilation as well. 2 2009-08-23-Math-x.nb Note This paper is best understood in the context of my book Elegance with Substance on mathematics education - see http://www.dataweb.nl/~cool/Papers/Math/Index.html. My book advises that each national parliament investigates the stagnation in doing mathematics on the computer in school. This paper suggests how the software community might anticipate on common sense conclusions and start working on improvement.
    [Show full text]
  • Report on the Programming Language Modula-2
    The Programming language Modula-2 133 Report on the Programming Language Modula-2 1. Introduction Modula-2 grew out of a practical need for a general, efficiently implementable systems programming language for minicomputers. Its ancestors are Pascal and Modula. From the latter It has inherited the name, the important module concept, and a systematic, modern syntax, from Pascal most of the rest. This includes in particular the data structures, I.e. arrays, records, variant records, sets, and pointers. Structured statements include the familiar if, case, repeat, while, for, and with statements. Their syntax is such that every structure ends with an explicit termination symbol. The language is essentially machine-independent, with the exception of limitations due to word size. This appears to be in contradiction to the notion of a system-programming language, in which it must be possible to express all operations inherent in the underlying computer. The dilemma is resolved with the aid of the module concept. Machine-dependent items can be introduced in specific modules, and their use can thereby effectively be confined and isolated. In particular, the language provides the possibility to relax rules about data type compatibility in these cases. In a capable system-programming language it is possible to express input/output conversion procedures, file handling routines, storage allocators, process schedulers etc. Such facilities must therefore not be included as elements of the language itself, but appear as (so-called low-level) modules which are components of most programs written. Such a collection of standard modules is therefore an essential part of a Modula-2 implementation.
    [Show full text]
  • 15-819 Homotopy Type Theory Lecture Notes
    15-819 Homotopy Type Theory Lecture Notes Nathan Fulton October 9 and 11, 2013 1 Contents These notes summarize and extend two lectures from Bob Harper’s Homotopy Type Theory course. The cumulative hierarchy of type universes, Extensional Type theory, the ∞-groupoid structure of types and iterated identity types are presented. 2 Motivation and Overview Recall from previous lectures the definitions of functionality and transport. Function- ality states that functions preserve identity; that is, domain elements equal in their type map to equal elements in the codomain. Transportation states the same for 0 0 type families. Traditionally, this means that if a =A a , then B[a] true iff B[a ] true. In proof-relevant mathematics, this logical equivalence is generalized to a statement 0 0 about identity in the family: if a =A a , then B[a] =B B[a ]. Transportation can be thought of in terms of functional extensionality. Un- fortunately, extensionality fails in ITT. One way to recover extensionality, which comports with traditional mathematics, is to reduce all identity to reflexivity. This approach, called Extensional Type theory (ETT), provides a natural setting for set-level mathematics. The HoTT perspective on ETT is that the path structure of types need not be limited to that of strict sets. The richer path structure of an ∞-groupoid is induced by the induction principle for identity types. Finding a type-theoretic description of this behavior (that is, introduction, elimination and computation rules which comport with Gentzen’s Inversion Principle) is an open problem. 1 Homotopy Type Theory 3 The Cumulative Hierarchy of Universes In previous formulations of ITT, we used the judgement A type when forming types.
    [Show full text]
  • Formal Systems .1In
    Formal systems | University of Edinburgh | PHIL08004 | 1 / 32 January 16, 2020 Puzzle 3 A man was looking at a portrait. Someone asked him, \Whose picture are you looking at?" He replied: \Brothers and sisters have I none, but this man's father is my father's son." Whose picture was the man looking at? 2 / 32 3 / 32 I Is the man in the picture the man himself? I Self-portrait? 4 / 32 I Is the man in the picture the man himself? I Self-portrait? 4 / 32 I Is the man in the picture the man himself? I Self-portrait? 4 / 32 I No. I If the man in the picture is himself, then this father would be his own son! I \this man is my father's son" vs. I \this man's father is my father's son" 5 / 32 I No. I If the man in the picture is himself, then this father would be his own son! I \this man is my father's son" vs. I \this man's father is my father's son" 5 / 32 I No. I If the man in the picture is himself, then this father would be his own son! I \this man is my father's son" vs. I \this man's father is my father's son" 5 / 32 I No. I If the man in the picture is himself, then this father would be his own son! I \this man is my father's son" vs. I \this man's father is my father's son" 5 / 32 I No.
    [Show full text]