DOCSLIB.ORG

Fully Generic Programming Over Closed Universes of Inductive-Recursive Types

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Portland State University PDXScholar Dissertations and Theses Dissertations and Theses Spring 6-6-2017 Fully Generic Programming Over Closed Universes of Inductive-Recursive Types Larry Diehl Portland State University Follow this and additional works at: https://pdxscholar.library.pdx.edu/open_access_etds Part of the Computer Sciences Commons Let us know how access to this document benefits ou.y Recommended Citation Diehl, Larry, "Fully Generic Programming Over Closed Universes of Inductive-Recursive Types" (2017). Dissertations and Theses. Paper 3647. https://doi.org/10.15760/etd.5531 This Dissertation is brought to you for free and open access. It has been accepted for inclusion in Dissertations and Theses by an authorized administrator of PDXScholar. Please contact us if we can make this document more accessible: [email protected]. Fully Generic Programming Over Closed Universes of Inductive-Recursive Types by Larry Diehl A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science Dissertation Committee: Tim Sheard, Chair James Hook Mark P. Jones Andrew Tolmach Robert Bass Portland State University 2017 i ABSTRACT Dependently typed programming languages allow the type system to express arbitrary propositions of intuitionistic logic, thanks to the Curry-Howard isomor- phism. Taking full advantage of this type system requires defining more types than usual, in order to encode logical correctness criteria into the definitions of datatypes. While an abundance of specialized types helps ensure correctness, it comes at the cost of needing to redefine common functions for each specialized type. This dissertation makes an effort to attack the problem of code reuse in de- pendently typed languages. Our solution is to write generic functions, which can be applied to any datatype. Such a generic function can be applied to datatypes that are defined at the time the generic function was written, but they can also be applied to any datatype that is defined in the future. Our solution builds upon previous work on generic programming within dependently typed programming. Type theory supports generic programming using a construction known as a universe. A universe can be considered the model of a programming language, such that writing functions over it models writing generic programs in the programming language. Historically, there has been a trade-off between the expressive power of the modeled programming language, and the kinds of generic functions that can be written in it. Our dissertation shows that no such trade-off is necessary, and that we can write future-proof generic functions in a model of a dependently typed programming language with a rich collection of types. ii ACKNOWLEDGMENTS I would like to thank Tim Sheard, my advisor, for giving me the freedom to ex- plore my own research interests, for always being available to listen and provide constructive feedback, and for instilling in me the importance of thoroughly ex- plaining background material, supplemented by plenty of examples. I would also like to thank my parents, for supporting my decision to pursue aca- demic interests, despite needing to abandon a lucrative job and career in software development. Finally, I would like to thank Conor McBride, for inspiring me to work on the topic of generic programming. This inspiration is in part due to his academic publications and artifacts resulting from the Epigram programme, and is in part due to him warmly and enthusiastically welcoming a naive industry programmer. iii TABLE OF CONTENTS Abstract i Acknowledgments ii List of Figures ix Color Conventions x Part I Prelude 1 Chapter 1 Introduction 2 1.1 Dependently Typed Languages & Motivation . 3 1.1.1 Curry-Howard Isomorphism . 3 1.1.2 Indexed Types . 5 1.1.3 Motivation . 6 1.2 A Taste of Fully Generic Programming . 6 1.2.1 Traditional Generic Programming . 7 1.2.2 Fully Generic Programming . 9 1.2.3 Universes . 11 1.2.4 Fully Generic versus Deriving . 14 1.3 Class of Supported Datatypes . 14 1.3.1 Dependent Algebraic Types . 14 1.3.2 Indexing versus Induction-Recursion . 15 1.3.3 Smallness versus Largeness . 16 1.4 Thesis . 18 1.4.1 Thesis Statement . 18 1.4.2 Contributions . 19 1.4.3 Outline . 19 iv Chapter 2 Types & Universes 24 2.1 Types . 25 2.1.1 Function Types . 25 2.1.2 Non-Inductive Types . 26 2.1.3 Inductive Types . 27 2.1.4 Parameterized Types . 27 2.1.5 Indexed Types . 28 2.1.6 Type Families . 31 2.1.7 Derived Types . 31 2.1.8 Infinitary Types . 34 2.1.9 Inductive-Recursive Types . 35 2.1.10 Algebraic Types . 37 2.1.11 Computational Families . 38 2.1.12 Open Types . 39 2.1.13 Closed Types . 39 2.2 Universes . 40 2.2.1 Universe Model . 40 2.2.2 Open Universes . 41 2.2.3 Closed Universes . 43 2.2.4 Inductive Universes . 44 2.2.5 Non-Inductive Universes . 44 2.2.6 Subordinate Universes . 45 2.2.7 Autonomous Universes . 45 2.2.8 Derived Universes . 46 2.2.9 Parameterized Universes . 47 Chapter 3 Generic Programming 50 3.1 Parametric Polymorphism . 51 3.1.1 Parametric over Types . 51 3.1.2 Parametric over Levels . 51 3.2 Ad Hoc Polymorphism . 52 3.2.1 Ad Hoc by Overloading . 52 3.2.2 Ad Hoc by Coercion . 53 3.2.3 Ad Hoc by Overloading & Coercion . 54 3.3 Abstractness & Concreteness . 54 3.3.1 Abstract Types . 55 v 3.3.2 Concrete Types . 55 3.3.3 Abstract Data Types . 56 3.3.4 Fully Generic Programming . 56 3.4 Totality . 57 3.4.1 Non-Dependent Domain Change . 57 3.4.2 Non-Dependent Codomain Change . 58 3.4.3 Dependent Domain Change . 58 3.4.4 Dependent Codomain Change . 59 3.4.5 Domain Predicates versus Domain Supplements . 60 Chapter 4 Closed Type Theory 62 4.1 Closed Vector Universe . 63 4.1.1 Closed Vector Types . 63 4.1.2 Fully Generic Functions . 65 4.2 Closed Algebraic Universe . 69 4.2.1 Closed Well-Order Types . 70 4.2.2 Open Well-Order Types . 71 4.2.3 Inadequacy of Well-Orders . 73 Part II Open Type Theory 76 Chapter 5 Open Algebraic Universes 77 5.1 Open Non-Dependent Types . 79 5.1.1 Categorical Model . 79 5.1.2 Formal Model . 81 5.1.3 Examples . 86 5.2 Open Infinitary Types . 91 5.2.1 Categorical Model . 91 5.2.2 Formal Model . 93 5.2.3 Examples . 96 5.3 Open Dependent Types . 99 5.3.1 Categorical Model . 99 5.3.2 Formal Model . 102 5.3.3 Examples . 106 5.4 Open Inductive-Recursive Types . 111 5.4.1 Categorical Model . 112 vi 5.4.2 Formal Model . 117 5.4.3 Examples . 122 5.4.4 Agda Model . 131 Part III Closed Type Theory 133 Chapter 6 Closed Algebraic Universe 134 6.1 Open Inductive-Recursive Types . 135 6.1.1 Formal Model . 136 6.1.2 Source of Openness . 137 6.2 Closed Inductive-Recursive Types . 139 6.2.1 Formal Model . 139 6.2.2 Examples . 142 6.2.3 Kind-Generalized Universes . 150 6.3 How to Close a Universe . 152 6.3.1 Procedure . 152 6.3.2 Example Procedure Run . 153 6.4 Types versus Kinds . 157 6.4.1 Open Types and Kinds . 157 6.4.2 Gratuitous Kinds . 160 6.4.3 Types versus Descriptions . 161 6.4.4 Kind-Parameterized Types . 162 Chapter 7 Fully Generic Functions 167 7.1 Fully Generic Count . 169 7.1.1 Generic Types . 169 7.1.2 Counting All Values . 172 7.1.3 Counting Algebraic Arguments . 173 7.1.4 Examples . 176 7.2 Fully Generic Lookup . 185 7.2.1 Generic Types . ..
Recommended publications
  • Countability of Inductive Types Formalized in the Object-Logic Level

    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.
  • The Pros of Cons: Programming with Pairs and Lists

    The Pros of Cons: Programming with Pairs and Lists

    The Pros of cons: Programming with Pairs and Lists CS251 Programming Languages Spring 2016, Lyn Turbak Department of Computer Science Wellesley College Racket Values • booleans: #t, #f • numbers: – integers: 42, 0, -273 – raonals: 2/3, -251/17 – floang point (including scien3fic notaon): 98.6, -6.125, 3.141592653589793, 6.023e23 – complex: 3+2i, 17-23i, 4.5-1.4142i Note: some are exact, the rest are inexact. See docs. • strings: "cat", "CS251", "αβγ", "To be\nor not\nto be" • characters: #\a, #\A, #\5, #\space, #\tab, #\newline • anonymous func3ons: (lambda (a b) (+ a (* b c))) What about compound data? 5-2 cons Glues Two Values into a Pair A new kind of value: • pairs (a.k.a. cons cells): (cons v1 v2) e.g., In Racket, - (cons 17 42) type Command-\ to get λ char - (cons 3.14159 #t) - (cons "CS251" (λ (x) (* 2 x)) - (cons (cons 3 4.5) (cons #f #\a)) Can glue any number of values into a cons tree! 5-3 Box-and-pointer diagrams for cons trees (cons v1 v2) v1 v2 Conven3on: put “small” values (numbers, booleans, characters) inside a box, and draw a pointers to “large” values (func3ons, strings, pairs) outside a box. (cons (cons 17 (cons "cat" #\a)) (cons #t (λ (x) (* 2 x)))) 17 #t #\a (λ (x) (* 2 x)) "cat" 5-4 Evaluaon Rules for cons Big step seman3cs: e1 ↓ v1 e2 ↓ v2 (cons) (cons e1 e2) ↓ (cons v1 v2) Small-step seman3cs: (cons e1 e2) ⇒* (cons v1 e2); first evaluate e1 to v1 step-by-step ⇒* (cons v1 v2); then evaluate e2 to v2 step-by-step 5-5 cons evaluaon example (cons (cons (+ 1 2) (< 3 4)) (cons (> 5 6) (* 7 8))) ⇒ (cons (cons 3 (< 3 4))
  • Dotty Phantom Types (Technical Report)

    Dotty Phantom Types (Technical Report)

    Dotty Phantom Types (Technical Report) Nicolas Stucki Aggelos Biboudis Martin Odersky École Polytechnique Fédérale de Lausanne Switzerland Abstract 2006] and even a lightweight form of dependent types [Kise- Phantom types are a well-known type-level, design pattern lyov and Shan 2007]. which is commonly used to express constraints encoded in There are two ways of using phantoms as a design pattern: types. We observe that in modern, multi-paradigm program- a) relying solely on type unication and b) relying on term- ming languages, these encodings are too restrictive or do level evidences. According to the rst way, phantoms are not provide the guarantees that phantom types try to en- encoded with type parameters which must be satised at the force. Furthermore, in some cases they introduce unwanted use-site. The declaration of turnOn expresses the following runtime overhead. constraint: if the state of the machine, S, is Off then T can be We propose a new design for phantom types as a language instantiated, otherwise the bounds of T are not satisable. feature that: (a) solves the aforementioned issues and (b) makes the rst step towards new programming paradigms type State; type On <: State; type Off <: State class Machine[S <: State] { such as proof-carrying code and static capabilities. This pa- def turnOn[T >: S <: Off] = new Machine[On] per presents the design of phantom types for Scala, as im- } new Machine[Off].turnOn plemented in the Dotty compiler. An alternative way to encode the same constraint is by 1 Introduction using an implicit evidence term of type =:=, which is globally Parametric polymorphism has been one of the most popu- available.
  • The Use of UML for Software Requirements Expression and Management

    The Use of UML for Software Requirements Expression and Management

    The Use of UML for Software Requirements Expression and Management Alex Murray Ken Clark Jet Propulsion Laboratory Jet Propulsion Laboratory California Institute of Technology California Institute of Technology Pasadena, CA 91109 Pasadena, CA 91109 818-354-0111 818-393-6258 [email protected] [email protected] Abstract— It is common practice to write English-language 1. INTRODUCTION ”shall” statements to embody detailed software requirements in aerospace software applications. This paper explores the This work is being performed as part of the engineering of use of the UML language as a replacement for the English the flight software for the Laser Ranging Interferometer (LRI) language for this purpose. Among the advantages offered by the of the Gravity Recovery and Climate Experiment (GRACE) Unified Modeling Language (UML) is a high degree of clarity Follow-On (F-O) mission. However, rather than use the real and precision in the expression of domain concepts as well as project’s model to illustrate our approach in this paper, we architecture and design. Can this quality of UML be exploited have developed a separate, ”toy” model for use here, because for the definition of software requirements? this makes it easier to avoid getting bogged down in project details, and instead to focus on the technical approach to While expressing logical behavior, interface characteristics, requirements expression and management that is the subject timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achiev- of this paper. ing the additional aspects of the expression and management of software requirements that stakeholders expect, especially There is one exception to this choice: we will describe our traceability, is far less so.
  • Certification of a Tool Chain for Deductive Program Verification Paolo Herms

    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.
  • Inductive Types an Proof Assistants

    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.
  • The Strength of Some Martin–Löf Type Theories

    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.
  • Java for Scientific Computing, Pros and Cons

    Java for Scientific Computing, Pros and Cons

    Journal of Universal Computer Science, vol. 4, no. 1 (1998), 11-15 submitted: 25/9/97, accepted: 1/11/97, appeared: 28/1/98 Springer Pub. Co. Java for Scienti c Computing, Pros and Cons Jurgen Wol v. Gudenb erg Institut fur Informatik, Universitat Wurzburg wol @informatik.uni-wuerzburg.de Abstract: In this article we brie y discuss the advantages and disadvantages of the language Java for scienti c computing. We concentrate on Java's typ e system, investi- gate its supp ort for hierarchical and generic programming and then discuss the features of its oating-p oint arithmetic. Having found the weak p oints of the language we pro- p ose workarounds using Java itself as long as p ossible. 1 Typ e System Java distinguishes b etween primitive and reference typ es. Whereas this distinc- tion seems to b e very natural and helpful { so the primitives which comprise all standard numerical data typ es have the usual value semantics and expression concept, and the reference semantics of the others allows to avoid p ointers at all{ it also causes some problems. For the reference typ es, i.e. arrays, classes and interfaces no op erators are available or may b e de ned and expressions can only b e built by metho d calls. Several variables may simultaneously denote the same ob ject. This is certainly strange in a numerical setting, but not to avoid, since classes have to b e used to intro duce higher data typ es. On the other hand, the simple hierarchy of classes with the ro ot Object clearly b elongs to the advantages of the language.
  • A Metaobject Protocol for Fault-Tolerant CORBA Applications

    A Metaobject Protocol for Fault-Tolerant CORBA Applications

    A Metaobject Protocol for Fault-Tolerant CORBA Applications Marc-Olivier Killijian*, Jean-Charles Fabre*, Juan-Carlos Ruiz-Garcia*, Shigeru Chiba** *LAAS-CNRS, 7 Avenue du Colonel Roche **Institute of Information Science and 31077 Toulouse cedex, France Electronics, University of Tsukuba, Tennodai, Tsukuba, Ibaraki 305-8573, Japan Abstract The corner stone of a fault-tolerant reflective The use of metalevel architectures for the architecture is the MOP. We thus propose a special implementation of fault-tolerant systems is today very purpose MOP to address the problems of general-purpose appealing. Nevertheless, all such fault-tolerant systems ones. We show that compile-time reflection is a good have used a general-purpose metaobject protocol (MOP) approach for developing a specialized runtime MOP. or are based on restricted reflective features of some The definition and the implementation of an object-oriented language. According to our past appropriate runtime metaobject protocol for implementing experience, we define in this paper a suitable metaobject fault tolerance into CORBA applications is the main protocol, called FT-MOP for building fault-tolerant contribution of the work reported in this paper. This systems. We explain how to realize a specialized runtime MOP, called FT-MOP (Fault Tolerance - MetaObject MOP using compile-time reflection. This MOP is CORBA Protocol), is sufficiently general to be used for other aims compliant: it enables the execution and the state evolution (mobility, adaptability, migration, security). FT-MOP of CORBA objects to be controlled and enables the fault provides a mean to attach dynamically fault tolerance tolerance metalevel to be developed as CORBA software. strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as 1 .
  • Webassembly Specification

    Webassembly Specification

    WebAssembly Specification Release 1.1 WebAssembly Community Group Andreas Rossberg (editor) Mar 11, 2021 Contents 1 Introduction 1 1.1 Introduction.............................................1 1.2 Overview...............................................3 2 Structure 5 2.1 Conventions.............................................5 2.2 Values................................................7 2.3 Types.................................................8 2.4 Instructions.............................................. 11 2.5 Modules............................................... 15 3 Validation 21 3.1 Conventions............................................. 21 3.2 Types................................................. 24 3.3 Instructions.............................................. 27 3.4 Modules............................................... 39 4 Execution 47 4.1 Conventions............................................. 47 4.2 Runtime Structure.......................................... 49 4.3 Numerics............................................... 56 4.4 Instructions.............................................. 76 4.5 Modules............................................... 98 5 Binary Format 109 5.1 Conventions............................................. 109 5.2 Values................................................ 111 5.3 Types................................................. 112 5.4 Instructions.............................................. 114 5.5 Modules............................................... 120 6 Text Format 127 6.1 Conventions............................................
  • Chapter 15 Functional Programming

    Chapter 15 Functional Programming

    Topics Chapter 15 Numbers n Natural numbers n Haskell numbers Functional Programming Lists n List notation n Lists as a data type n List operations Chapter 15: Functional Programming 2 Numbers Natural Numbers The natural numbers are the numbers 0, 1, Haskell provides a sophisticated 2, and so on, used for counting. hierarchy of type classes for describing various kinds of numbers. Introduced by the declaration data Nat = Zero | Succ Nat Although (some) numbers are provided n The constructor Succ (short for ‘successor’) as primitives data types, it is has type Nat à Nat. theoretically possible to introduce them n Example: as an element of Nat the number 7 through suitable data type declarations. would be represented by Succ(Succ(Succ(Succ(Succ(Succ(Succ Zero)))))) Chapter 15: Functional Programming 3 Chapter 15: Functional Programming 4 Natural Numbers Natural Numbers Every natural number is represented by a Multiplication ca be defined by unique value of Nat. (x) :: Nat à Nat à Nat m x Zero = Zero On the other hand, not every value of Nat m x Succ n = (m x n) + m represents a well-defined natural number. n Example: ^, Succ ^, Succ(Succ ^) Nat can be a member of the type class Eq Addition ca be defined by instance Eq Nat where Zero == Zero = True (+) :: Nat à Nat à Nat Zero == Succ n = False m + Zero = m Succ m == Zero = False m + Succ n = Succ(m + n) Succ m == Succ n = (m == n) Chapter 15: Functional Programming 5 Chapter 15: Functional Programming 6 1 Natural Numbers Haskell Numbers Nat can be a member of the type class Ord instance
  • 1 Intro to ML

    1 Intro to ML

    1 Intro to ML 1.1 Basic types Need ; after expression - 42 = ; val it = 42: int -7+1; val it =8: int Can reference it - it+2; val it = 10: int - if it > 100 then "big" else "small"; val it = "small": string Different types for each branch. What will happen? if it > 100 then "big" else 0; The type checker will complain that the two branches have different types, one is string and the other is int If with then but no else. What will happen? if 100>1 then "big"; There is not if-then in ML; must use if-then-else instead. Mixing types. What will happen? What is this called? 10+ 2.5 In many programming languages, the int will be promoted to a float before the addition is performed, and the result is 12.5. In ML, this type coercion (or type promotion) does not happen. Instead, the type checker will reject this expression. div for integers, ‘/ for reals - 10 div2; val it =5: int - 10.0/ 2.0; val it = 5.0: real 1 1.1.1 Booleans 1=1; val it = true : bool 1=2; val it = false : bool Checking for equality on reals. What will happen? 1.0=1.0; Cannot check equality of reals in ML. Boolean connectives are a bit weird - false andalso 10>1; val it = false : bool - false orelse 10>1; val it = true : bool 1.1.2 Strings String concatenation "University "^ "of"^ " Oslo" 1.1.3 Unit or Singleton type • What does the type unit mean? • What is it used for? • What is its relation to the zero or bottom type? - (); val it = () : unit https://en.wikipedia.org/wiki/Unit_type https://en.wikipedia.org/wiki/Bottom_type The boolean type is inhabited by two values: true and false.