DOCSLIB.ORG

Type Systems for Programming Languages1 (DRAFT)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Type Systems for Programming Languages1 (DRAFT) Type Systems for Programming Languages1 (DRAFT) Robert Harper School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213-3891 E-mail: [email protected] WWW: http://www.cs.cmu.edu/~rwh Spring, 2000 Copyright c 1995-2000. All rights reserved. 1These are course notes Computer Science 15–814 at Carnegie Mellon University. This is an incomplete, working draft, not intended for publication. Citations to the literature are spotty at best; no results presented here should be considered original unless explicitly stated otherwise. Please do not distribute these notes without the permission of the author. ii Contents I Type Structure 1 1 Basic Types 3 1.1 Introduction . 3 1.2 Statics . 3 1.3 Dynamics . 4 1.3.1 Contextual Semantics . 4 1.3.2 Evaluation Semantics . 5 1.4 Type Soundness . 7 1.5 References . 8 2 Function and Product Types 9 2.1 Introduction . 9 2.2 Statics . 9 2.3 Dynamics . 10 2.4 Type Soundness . 11 2.5 Termination . 12 2.6 References . 13 3 Sums 15 3.1 Introduction . 15 3.2 Sum Types . 15 3.3 References . 16 4 Subtyping 17 4.1 Introduction . 17 4.2 Subtyping . 17 4.2.1 Subsumption . 18 4.3 Primitive Subtyping . 18 4.4 Tuple Subtyping . 19 4.5 Record Subtyping . 22 4.6 References . 24 iii 5 Variable Types 25 5.1 Introduction . 25 5.2 Variable Types . 25 5.3 Type Definitions . 26 5.4 Constructors, Types, and Kinds . 28 5.5 References . 30 6 Recursive Types 31 6.1 Introduction . 31 6.2 G¨odel’s T ............................... 31 6.2.1 Statics . 31 6.2.2 Dynamics . 32 6.2.3 Termination . 32 6.3 Mendler’s S .............................. 34 6.4 General Recursive Types . 36 6.5 References . 37 7 Polymorphism 39 7.1 Introduction . 39 7.2 Statics . 39 7.3 Dynamics . 40 7.4 Impredicative Polymorphism . 41 7.4.1 Termination . 42 7.4.2 Definability of Types . 46 7.5 References . 47 8 Abstract Types 49 8.1 Statics . 49 8.2 Dynamics . 50 8.3 Impredicativity . 50 8.4 Dot Notation . 51 8.5 References . 53 9 Higher Kinds 55 9.1 Introduction . 55 9.2 Functional Kinds . 55 9.3 Subtyping and Higher Kinds . 56 9.4 Bounded Quantification and Power Kinds . 57 9.5 Singleton Kinds, Dependent Kinds, and Subkinding . 59 9.6 References . 59 10 Modularity 61 10.1 Introduction . 61 10.2 A Critique of Some Modularity Mechanisms . 68 10.3 A Modules Language . 71 10.3.1 Structures . 72 iv 10.3.2 Module Hierarchies . 76 10.3.3 Parameterized Modules . 77 10.4 Second-Class Modules . 79 10.5 Higher-Order Modules . 79 10.6 References . 79 11 Objects 81 11.1 Introduction . 81 11.2 Primitive Objects . 81 11.3 Object Subtyping . 81 11.4 Second-Order Object Types . 81 11.5 References . 81 12 Dynamic Types 83 12.1 Type Dynamic . 83 12.2 Hierarchical Tagging . 83 13 Classes 85 13.1 Introduction . 85 13.2 Public, Private, and Protected . 85 13.3 Constructors . 85 13.4 Subtyping and Inheritance . 85 13.5 Dynamic Dispatch . 85 13.6 References . 85 II Computational Effects 87 14 Recursive Functions 89 14.1 Introduction . 89 14.2 Statics . 89 14.3 Dynamics . 90 14.4 Type Soundness . 90 14.5 Compactness . 91 14.6 References . 93 15 Continuations 95 15.1 Introduction . 95 15.2 Statics . 95 15.3 Dynamics . 96 15.4 Soundness . 98 15.5 References . 100 v 16 References 101 16.1 Introduction . 101 16.2 Statics . 101 16.3 Dynamics . 102 16.4 Type System . 102 16.5 Allocation and Collection . 103 16.6 References . 105 17 Exceptions 107 17.1 Introduction . 107 17.2 Statics . 107 17.3 Dynamics . 108 17.4 Exceptions and First-Class Continuations . 110 17.5 References . 111 III Implementation 113 18 Type Checking 115 18.1 Introduction . 115 18.2 Type Synthesis . 115 18.3 Definitional Equality . 116 18.4 Subtyping . 118 18.5 Subtyping . 119 18.6 References . 120 19 Type Reconstruction 121 19.1 Introduction . 121 →,∀ 19.2 Type Reconstruction for LΩ . 121 19.3 Type Reconstruction as Static Semantics . 122 19.4 Reconstruction as Constraint Solving . 124 19.4.1 Unification Logic . 124 19.4.2 Constraint Generation . 126 19.5 Reconstruction and Definitions . 128 19.6 References . 129 20 Coercion Interpretation of Subtyping 131 21 Named Form 133 21.1 Introduction . ..
Load more

Recommended publications
  • A Polymorphic Type System for Extensible Records and Variants
    A Polymorphic Typ e System for Extensible Records and Variants Benedict R. Gaster and Mark P. Jones Technical rep ort NOTTCS-TR-96-3, November 1996 Department of Computer Science, University of Nottingham, University Park, Nottingham NG7 2RD, England. fbrg,[email protected] Abstract b oard, and another indicating a mouse click at a par- ticular p oint on the screen: Records and variants provide exible ways to construct Event = Char + Point : datatyp es, but the restrictions imp osed by practical typ e systems can prevent them from b eing used in ex- These de nitions are adequate, but they are not par- ible ways. These limitations are often the result of con- ticularly easy to work with in practice. For example, it cerns ab out eciency or typ e inference, or of the di- is easy to confuse datatyp e comp onents when they are culty in providing accurate typ es for key op erations. accessed by their p osition within a pro duct or sum, and This pap er describ es a new typ e system that reme- programs written in this way can b e hard to maintain. dies these problems: it supp orts extensible records and To avoid these problems, many programming lan- variants, with a full complement of p olymorphic op era- guages allow the comp onents of pro ducts, and the al- tions on each; and it o ers an e ective type inference al- ternatives of sums, to b e identi ed using names drawn gorithm and a simple compilation metho d.
    [Show full text]
  • Countability of Inductive Types Formalized in the Object-Logic Level
    Countability of Inductive Types Formalized in the Object-Logic Level QinxiangCao XiweiWu * Abstract: The set of integer number lists with finite length, and the set of binary trees with integer labels are both countably infinite. Many inductively defined types also have countably many ele- ments. In this paper, we formalize the syntax of first order inductive definitions in Coq and prove them countable, under some side conditions. Instead of writing a proof generator in a meta language, we develop an axiom-free proof in the Coq object logic. In other words, our proof is a dependently typed Coq function from the syntax of the inductive definition to the countability of the type. Based on this proof, we provide a Coq tactic to automatically prove the countability of concrete inductive types. We also developed Coq libraries for countability and for the syntax of inductive definitions, which have value on their own. Keywords: countable, Coq, dependent type, inductive type, object logic, meta logic 1 Introduction In type theory, a system supports inductive types if it allows users to define new types from constants and functions that create terms of objects of that type. The Calculus of Inductive Constructions (CIC) is a powerful language that aims to represent both functional programs in the style of the ML language and proofs in higher-order logic [16]. Its extensions are used as the kernel language of Coq [5] and Lean [14], both of which are widely used, and are widely considered to be a great success. In this paper, we focus on a common property, countability, of all first-order inductive types, and provide a general proof in Coq’s object-logic.
    [Show full text]
  • Multi-Level Constraints
    Multi-Level Constraints Tony Clark1 and Ulrich Frank2 1 Aston University, UK, [email protected] 2 University of Duisburg-Essen, DE, [email protected] Abstract. Meta-modelling and domain-specific modelling languages are supported by multi-level modelling which liberates model-based engi- neering from the traditional two-level type-instance language architec- ture. Proponents of this approach claim that multi-level modelling in- creases the quality of the resulting systems by introducing a second ab- straction dimension and thereby allowing both intra-level abstraction via sub-typing and inter-level abstraction via meta-types. Modelling ap- proaches include constraint languages that are used to express model semantics. Traditional languages, such as OCL, support intra-level con- straints, but not inter-level constraints. This paper motivates the need for multi-level constraints, shows how to implement such a language in a reflexive language architecture and applies multi-level constraints to an example multi-level model. 1 Introduction Conceptual models aim to bridge the gap between natural languages that are required to design and use a system and implementation languages. To this end, general-purpose modelling languages (GPML) like the UML consist of concepts that represent semantic primitives such as class, attribute, etc., that, on the one hand correspond to concepts of foundational ontologies, e.g., [4], and on the other hand can be nicely mapped to corresponding elements of object-oriented programming languages. Since GPML can be used to model a wide range of systems, they promise at- tractive economies of scale. At the same time, their use suffers from the fact that they offer generic concepts only.
    [Show full text]
  • Union Types for Semistructured Data
    Edinburgh Research Explorer Union Types for Semistructured Data Citation for published version: Buneman, P & Pierce, B 1999, Union Types for Semistructured Data. in Union Types for Semistructured Data: 7th International Workshop on Database Programming Languages, DBPL’99 Kinloch Rannoch, UK, September 1–3,1999 Revised Papers. Lecture Notes in Computer Science, vol. 1949, Springer-Verlag GmbH, pp. 184-207. https://doi.org/10.1007/3-540-44543-9_12 Digital Object Identifier (DOI): 10.1007/3-540-44543-9_12 Link: Link to publication record in Edinburgh Research Explorer Document Version: Peer reviewed version Published In: Union Types for Semistructured Data General rights Copyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s) and / or other copyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associated with these rights. Take down policy The University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorer content complies with UK legislation. If you believe that the public display of this file breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim. Download date: 27. Sep. 2021 Union Typ es for Semistructured Data Peter Buneman Benjamin Pierce University of Pennsylvania Dept of Computer Information Science South rd Street Philadelphia PA USA fpeterbcpiercegcisupenn edu Technical
    [Show full text]
  • Certification of a Tool Chain for Deductive Program Verification Paolo Herms
    Certification of a Tool Chain for Deductive Program Verification Paolo Herms To cite this version: Paolo Herms. Certification of a Tool Chain for Deductive Program Verification. Other [cs.OH]. Université Paris Sud - Paris XI, 2013. English. NNT : 2013PA112006. tel-00789543 HAL Id: tel-00789543 https://tel.archives-ouvertes.fr/tel-00789543 Submitted on 18 Feb 2013 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. UNIVERSITÉ DE PARIS-SUD École doctorale d’Informatique THÈSE présentée pour obtenir le Grade de Docteur en Sciences de l’Université Paris-Sud Discipline : Informatique PAR Paolo HERMS −! − SUJET : Certification of a Tool Chain for Deductive Program Verification soutenue le 14 janvier 2013 devant la commission d’examen MM. Roberto Di Cosmo Président du Jury Xavier Leroy Rapporteur Gilles Barthe Rapporteur Emmanuel Ledinot Examinateur Burkhart Wolff Examinateur Claude Marché Directeur de Thèse Benjamin Monate Co-directeur de Thèse Jean-François Monin Invité Résumé Cette thèse s’inscrit dans le domaine de la vérification du logiciel. Le but de la vérification du logiciel est d’assurer qu’une implémentation, un programme, répond aux exigences, satis- fait sa spécification. Cela est particulièrement important pour le logiciel critique, tel que des systèmes de contrôle d’avions, trains ou centrales électriques, où un mauvais fonctionnement pendant l’opération aurait des conséquences catastrophiques.
    [Show full text]
  • Djangoshop Release 0.11.2
    djangoSHOP Release 0.11.2 Oct 27, 2017 Contents 1 Software Architecture 1 2 Unique Features of django-SHOP5 3 Upgrading 7 4 Tutorial 9 5 Reference 33 6 How To’s 125 7 Development and Community 131 8 To be written 149 9 License 155 Python Module Index 157 i ii CHAPTER 1 Software Architecture The django-SHOP framework is, as its name implies, a framework and not a software which runs out of the box. Instead, an e-commerce site built upon django-SHOP, always consists of this framework, a bunch of other Django apps and the merchant’s own implementation. While this may seem more complicate than a ready-to-use solution, it gives the programmer enormous advantages during the implementation: Not everything can be “explained” to a software system using graphical user interfaces. After reaching a certain point of complexity, it normally is easier to pour those requirements into executable code, rather than to expect yet another set of configuration buttons. When evaluating django-SHOP with other e-commerce solutions, I therefore suggest to do the following litmus test: Consider a product which shall be sold world-wide. Depending on the country’s origin of the request, use the native language and the local currency. Due to export restrictions, some products can not be sold everywhere. Moreover, in some countries the value added tax is part of the product’s price, and must be stated separately on the invoice, while in other countries, products are advertised using net prices, and tax is added later on the invoice.
    [Show full text]
  • Inductive Types an Proof Assistants
    Inductive Types Proof Assistants Homotopy Type Theory Radboud University Lecture 4: Inductive types an Proof Assistants H. Geuvers Radboud University Nijmegen, NL 21st Estonian Winter School in Computer Science Winter 2016 H. Geuvers - Radboud Univ. EWSCS 2016 Typed λ-calculus 1 / 58 Inductive Types Proof Assistants Homotopy Type Theory Radboud University Outline Inductive Types Proof Assistants Homotopy Type Theory H. Geuvers - Radboud Univ. EWSCS 2016 Typed λ-calculus 2 / 58 Inductive Types Proof Assistants Homotopy Type Theory Radboud University Curry-Howard-de Bruijn logic ∼ type theory formula ∼ type proof ∼ term detour elimination ∼ β-reduction proposition logic ∼ simply typed λ-calculus predicate logic ∼ dependently typed λ-calculus λP intuitionistic logic ∼ . + inductive types higher order logic ∼ . + higher types and polymorphism classical logic ∼ . + exceptions H. Geuvers - Radboud Univ. EWSCS 2016 Typed λ-calculus 3 / 58 Inductive Types Proof Assistants Homotopy Type Theory Radboud University Inductive types by examples from the Coq system • booleans • natural numbers • integers • pairs • linear lists • binary trees • logical operations H. Geuvers - Radboud Univ. EWSCS 2016 Typed λ-calculus 5 / 58 Inductive Types Proof Assistants Homotopy Type Theory Radboud University Inductive types • types • recursive functions • definition using pattern matching • ι-reduction = evaluation of recursive functions • recursion principle • proof by cases proof by induction • induction principle H. Geuvers - Radboud Univ. EWSCS 2016 Typed λ-calculus 6 / 58 Inductive Types Proof Assistants Homotopy Type Theory Radboud University Booleans: type Coq definition: Inductive bool : Set := | true : bool | false : bool. Coq produces: bool rec. bool rect. bool ind. H. Geuvers - Radboud Univ. EWSCS 2016 Typed λ-calculus 7 / 58 Inductive Types Proof Assistants Homotopy Type Theory Radboud University Booleans: elimination Check bool ind.
    [Show full text]
  • Presentation on Ocaml Internals
    OCaml Internals Implementation of an ML descendant Theophile Ranquet Ecole Pour l’Informatique et les Techniques Avancées SRS 2014 [email protected] November 14, 2013 2 of 113 Table of Contents Variants and subtyping System F Variants Type oddities worth noting Polymorphic variants Cyclic types Subtyping Weak types Implementation details α ! β Compilers Functional programming Values Why functional programming ? Allocation and garbage Combinatory logic : SKI collection The Curry-Howard Compiling correspondence Type inference OCaml and recursion 3 of 113 Variants A tagged union (also called variant, disjoint union, sum type, or algebraic data type) holds a value which may be one of several types, but only one at a time. This is very similar to the logical disjunction, in intuitionistic logic (by the Curry-Howard correspondance). 4 of 113 Variants are very convenient to represent data structures, and implement algorithms on these : 1 d a t a t y p e tree= Leaf 2 | Node of(int ∗ t r e e ∗ t r e e) 3 4 Node(5, Node(1,Leaf,Leaf), Node(3, Leaf, Node(4, Leaf, Leaf))) 5 1 3 4 1 fun countNodes(Leaf)=0 2 | countNodes(Node(int,left,right)) = 3 1 + countNodes(left)+ countNodes(right) 5 of 113 1 t y p e basic_color= 2 | Black| Red| Green| Yellow 3 | Blue| Magenta| Cyan| White 4 t y p e weight= Regular| Bold 5 t y p e color= 6 | Basic of basic_color ∗ w e i g h t 7 | RGB of int ∗ i n t ∗ i n t 8 | Gray of int 9 1 l e t color_to_int= function 2 | Basic(basic_color,weight) −> 3 l e t base= match weight with Bold −> 8 | Regular −> 0 in 4 base+ basic_color_to_int basic_color 5 | RGB(r,g,b) −> 16 +b+g ∗ 6 +r ∗ 36 6 | Grayi −> 232 +i 7 6 of 113 The limit of variants Say we want to handle a color representation with an alpha channel, but just for color_to_int (this implies we do not want to redefine our color type, this would be a hassle elsewhere).
    [Show full text]
  • Generic Programming
    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
    [Show full text]
  • Practical Subtyping for System F with Sized (Co-)Induction Rodolphe Lepigre, Christophe Raffalli
    Practical Subtyping for System F with Sized (Co-)Induction Rodolphe Lepigre, Christophe Raffalli To cite this version: Rodolphe Lepigre, Christophe Raffalli. Practical Subtyping for System F with Sized (Co-)Induction. 2017. hal-01289760v3 HAL Id: hal-01289760 https://hal.archives-ouvertes.fr/hal-01289760v3 Preprint submitted on 10 Jul 2017 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. Distributed under a Creative Commons Attribution - NonCommercial - NoDerivatives| 4.0 International License PRACTICAL SUBTYPING FOR SYSTEM F WITH SIZED (CO-)INDUCTION RODOLPHE LEPIGRE AND CHRISTOPHE RAFFALLI LAMA, UMR 5127 CNRS - Universit´eSavoie Mont Blanc e-mail address: frodolphe.lepigre j christophe.raff[email protected] Abstract. We present a rich type system with subtyping for an extension of System F. Our type constructors include sum and product types, universal and existential quanti- fiers, inductive and coinductive types. The latter two may carry annotations allowing the encoding of size invariants that are used to ensure the termination of recursive programs. For example, the termination of quicksort can be derived by showing that partitioning a list does not increase its size. The system deals with complex programs involving mixed induction and coinduction, or even mixed polymorphism and (co-)induction (as for Scott- encoded data types).
    [Show full text]
  • The Strength of Some Martin–Löf Type Theories
    The Strength of Some Martin{LÄofType Theories Michael Rathjen¤y Abstract One objective of this paper is the determination of the proof{theoretic strength of Martin{ LÄof's type theory with a universe and the type of well{founded trees. It is shown that this type system comprehends the consistency of a rather strong classical subsystem of second order 1 arithmetic, namely the one with ¢2 comprehension and bar induction. As Martin-LÄofintended to formulate a system of constructive (intuitionistic) mathematics that has a sound philosophical basis, this yields a constructive consistency proof of a strong classical theory. Also the proof- theoretic strength of other inductive types like Aczel's type of iterative sets is investigated in various contexts. Further, we study metamathematical relations between type theories and other frameworks for formalizing constructive mathematics, e.g. Aczel's set theories and theories of operations and classes as developed by Feferman. 0 Introduction The intuitionistic theory of types as developed by Martin-LÄofis intended to be a system for formalizing intuitionistic mathematics together with an informal semantics, called \meaning expla- nation", which enables him to justify the rules of his type theory by showing their validity with respect to that semantics. Martin-LÄof's theory gives rise to a full scale philosophy of constructivism. It is a typed theory of constructions containing types which themselves depend on the constructions contained in previously constructed types. These dependent types enable one to express the general Cartesian product of the resulting families of types, as well as the disjoint union of such a family.
    [Show full text]
  • Data Types and Variables
    Color profile: Generic CMYK printer profile Composite Default screen Complete Reference / Visual Basic 2005: The Complete Reference / Petrusha / 226033-5 / Chapter 2 2 Data Types and Variables his chapter will begin by examining the intrinsic data types supported by Visual Basic and relating them to their corresponding types available in the .NET Framework’s Common TType System. It will then examine the ways in which variables are declared in Visual Basic and discuss variable scope, visibility, and lifetime. The chapter will conclude with a discussion of boxing and unboxing (that is, of converting between value types and reference types). Visual Basic Data Types At the center of any development or runtime environment, including Visual Basic and the .NET Common Language Runtime (CLR), is a type system. An individual type consists of the following two items: • A set of values. • A set of rules to convert every value not in the type into a value in the type. (For these rules, see Appendix F.) Of course, every value of another type cannot always be converted to a value of the type; one of the more common rules in this case is to throw an InvalidCastException, indicating that conversion is not possible. Scalar or primitive types are types that contain a single value. Visual Basic 2005 supports two basic kinds of scalar or primitive data types: structured data types and reference data types. All data types are inherited from either of two basic types in the .NET Framework Class Library. Reference types are derived from System.Object. Structured data types are derived from the System.ValueType class, which in turn is derived from the System.Object class.
    [Show full text]