DOCSLIB.ORG

Subtyping and Parametricity

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Subtyping and Parametricity Subtyping and Parametricity Gordon Plotkin∗ Mart´ınAbadiy Luca Cardelliy Abstract in previous work [ACC93, PA93]. In this paper we extend the formalization of [PA93] to a programming In this paper we study the interaction of subtyping language with subtyping. and parametricity. We describe a logic for a program- A logic serves as the setting for this study. This ming language with parametric polymorphism and sub- logic can be viewed as an analogue of Scott’s LCF, that typing. The logic supports the formal definition and is, as a fairly general system for proving properties of use of relational parametricity. We give two models programs. Here the programs are those of System F , for it, and compare it with other formal systems for the which is an extension of Girard’s System F [Gir72]≤ same language. In particular, we examine the “Penn with subtyping, abstracted from work of Cardelli and interpretation” of subtyping as implicit coercion. Wegner [CW85] by Curien and Ghelli [CG92, CG94]. Without subtyping, parametricity yields, for exam- Our logic for F is an extension of the logic for F pre- ple, an encoding of abstract types and of initial alge- sented in [PA93].≤ Beyond its possible use in program bras, with the corresponding proof principles of simu- verification, the logic provides a language for stating lation and induction. With subtyping, we obtain par- parametricity assumptions and rules for deriving their tially abstract types and certain initial order-sorted al- consequences, formally and without reference to par- gebras, and may derive proof principles for them. ticular models. While it remains to consider what might be the ap- propriate general form for parametric models of F 1 Introduction and of our logic, we do construct particular models—≤ indeed two such. The first is a parametric per model A function is polymorphic if it works on inputs combining the idea of Bruce and Longo [BL90] of of several types. We may distinguish various no- treating subtypes as subpers with that of Bainbridge tions of polymorphism, particularly parametric poly- et al. [BFSS90] of forcing parametricity into per mod- morphism (e.g. [Rey83]) and subtype polymorphism els of System F. The second is a closed-term model, (e.g. [CW85]). These may exist in isolation, as in following an idea of Moggi for System F [Mog86]. Hav- ML [MTH90] or in Amber [Car86], but they can also ing at least one non-trivial model, it follows that if interact, with useful results. For example, a theory two terms of the same type can be proved equal in of object-oriented programming has been based on a our logic, then they are observationally equivalent. certain kind of bounded polymorphism (e.g. [CHC90, A variant F<: of F was given by Cardelli et Bru93]). al. [CMMS94]. A weakened≤ version is derivable within In this paper we study the interaction of subtyp- our logic. Both this version and the full F<: yield some ing and parametricity. A polymorphic function may of the results associated with parametricity, frequently be said to be parametric in Strachey’s sense [Str67, with a limitation to closed terms. Our logic gives these Rey83, PA93] if it can be given by a uniform algo- and other results in full generality, for terms with free rithm or program, independently of the type of its variables. We conjecture that in fact F<: itself is deriv- arguments. A semantic definition of parametricity is able within our logic. Indeed we formulate a stronger due to Reynolds [Rey83], who requires instead that theory, which may be said to embody Strachey’s view instances of the polymorphic function at related types of parametric polymorphism for F , and conjecture be related. Reynolds’ definition has been formalized that it is derivable. ≤ ∗Department of Computer Science, University of Edinburgh, We also examine the “Penn interpretation” of King’s Buildings, Edinburgh EH9 3JZ, UK. Part of this work F [BCGS91], with its view of subtyping as implicit was completed while at Digital Equipment Corporation, Sys- coercion.≤ This interpretation is based on a transla- tems Research Center. Digital Equipment Corporation, Systems Research Center, tion from F to F. We show that this translation y ≤ 130 Lytton Avenue, Palo Alto, California 94301, USA. can be extended to formulae; theorems of the logic for F are translated into theorems of the logic for F from quantifiers to bounded quantifiers. The terms are given≤ in [PA93]. We consider full-abstraction issues extended similarly, with a constant (top) and bounded and show that the translation is not conservative. type abstractions. Type expressions and terms are Parametricity conditions play an important role in given by the grammar: the study of F and of similar languages (e.g. [Rey83, Types: A ::= X A B Top X B: A BFSS90, Wad89]). They appear in semantic construc- j ! j j 8 ≤ tions. They yield useful properties of types, for ex- Terms: t ::= x λx:A: t u(t) top ΛXj B: t tj(A) j j ample that Int = X: ((X X) (X X)), the ≤ j type of Church integers,8 is isomorphic! ! to the! standard Here X ranges over type variables and x over ordinary natural numbers. And they can be exploited in prov- variables. We use notations such as A[X] to indicate ing properties of polymorphic programs, for example possible occurrences of variables in expressions, and that all functions of type X: (X Int) are constant. then may write, for example, A[B] to represent the These results have interesting8 analogues! for F . Just ≤ result of substituting B for X in A (avoiding capture of as the logic for F offers abstract types, initial algebras, bound variables). Unbounded binders abbreviate the and final co-algebras, the logic for F offers partially ≤ corresponding binders with bound Top; so for example abstract types, certain initial order-sorted algebras, X:A stands for X Top:A. Throughout, expressions and certain final order-sorted co-algebras, with corre- are8 understood up8 to≤ α-equivalence. sponding proof principles. Further, we can apply the We build formulae from equations and binary rela- logic to prove theorems about programs from their tions between terms. types, or “theorems for free,” as Wadler calls them. Some of these have an object-oriented flavor, in line Formulae: φ ::= (t =A u) R(t; u) φ ψ with one of the intended applications of F . x:A: φ Xj B: φ j R⊃ A j B: φ ≤ There has been much related work for languages 8 φ ψj 8φ ≤ψ j 8 ⊂ × j without subtyping. However, the combination of para- ?jx:A:^ φ j X_ B:j φ R A B: φ metricity and subtyping has been little considered. As 9 j 9 ≤ j 9 ⊂ × mentioned above, System F<: of Cardelli et al. incor- Here R ranges over relation variables. The equality porates a modest notion of parametricity (partly mo- symbol is subscripted with a type expression, the type tivated by dinaturality considerations). Ma [Ma92] of the terms being equated. In F, this expression is expresses parametricity for F via a translation into a unique, and so can be left implicit, but it proves nec- language with subtyping and intersection types. Ma essary in treating subtyping, as we see below. The focuses on parametricity in F, not on parametricity in basic constructs are implication ( ) and three sorts of ⊃ his target language with subtyping. universal quantification: over values, over types, and The next section introduces our logic and some fun- over relations between types (where R A B is read ⊂ × damental results about it. Discussion of its seman- as “R is a relation between A and B”). The other con- tics appears in section 3. Section 4 treats other theo- structs are useful but not altogether necessary. When ries for F , including one induced by the Penn inter- writing formulae we often make use of evident abbre- pretation.≤ Section 5 provides encodings of extensible viations. While there are primitive notions of subtype records, partially abstract types, and order-sorted al- and of bounded type quantification, there is no need gebras. for a corresponding primitive notion for relations. A second-order environment E is a finite sequence of type variables with bounds X A or typings x : A ≤ 2 Basic logic in which no variable is introduced twice. The typing judgment E t : A and the subtyping judgment E ` ` This section defines the logic. In this paper we A B are defined as in [CG92, CG94]. ≤ sometimes reference or borrow from [PA93] for the To specify the well-formed formulae, we also need fragment that corresponds to F. We emphasize the relation environments, which are finite sequences of novelties, which concern subtyping. relational typings R A B with no relation variable repeated. We define⊂ a judgment× E G REnv to as- ` 2.1 Well-formed formulae sert that G is a well-formed relation environment given E; the judgment holds if whenever R A B appears The type expressions and terms are those of F . in G then A and B are well-formed⊂ type× expressions The type expressions of F are like those of F, with≤ given E. We define a judgment E; G φ Prop to as- the addition of a largest type≤ Top and a generalization sert that φ is a well-formed formula` given E and G. The rules for atomic formulae are: Next, for ρ C D and ρ0 A B, we define ⊂ × ⊂ × ( (Y C; Z D; R ρ): ρ0) ( Y C: A) ( Z D: B) E t:AE u:AE G REnv 8 ≤ ≤ ≤ ⊂ 8 ≤ × 8 ≤ ` ` ` to be: E; G t = u Prop ` A (y :( Y C: A); z :( Z D: B)): E t:AE u:BE G REnv R A B in G 8 ≤ 8 ≤ ` ` ` ⊂ × Y C Z D R Y Z: (R ρ (yY )ρ0(zZ)) E; G R(t; u) Prop 8 ≤ 8 ≤ 8 ⊂ × ≤ ⊃ ` Among the other rules we have, for example: where ρ ρ stands for x : C y : D : (ρ (x; y) 1 ≤ 2 8 18 1 1 ⊃ ρ2(x; y)), for ρ1 C1 D1 and ρ2 C2 D2.
Load more

Recommended publications
  • An Extended Theory of Primitive Objects: First Order System Luigi Liquori
    An extended Theory of Primitive Objects: First order system Luigi Liquori To cite this version: Luigi Liquori. An extended Theory of Primitive Objects: First order system. ECOOP, Jun 1997, Jyvaskyla, Finland. pp.146-169, 10.1007/BFb0053378. hal-01154568 HAL Id: hal-01154568 https://hal.inria.fr/hal-01154568 Submitted on 22 May 2015 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. An Extended Theory of Primitive Objects: First Order System Luigi Liquori ? Dip. Informatica, Universit`adi Torino, C.so Svizzera 185, I-10149 Torino, Italy e-mail: [email protected] Abstract. We investigate a first-order extension of the Theory of Prim- itive Objects of [5] that supports method extension in presence of object subsumption. Extension is the ability of modifying the behavior of an ob- ject by adding new methods (and inheriting the existing ones). Object subsumption allows to use objects with a bigger interface in a context expecting another object with a smaller interface. This extended calcu- lus has a sound type system which allows static detection of run-time errors such as message-not-understood, \width" subtyping and a typed equational theory on objects.
    [Show full text]
  • Metaobject Protocols: Why We Want Them and What Else They Can Do
    Metaobject protocols: Why we want them and what else they can do Gregor Kiczales, J.Michael Ashley, Luis Rodriguez, Amin Vahdat, and Daniel G. Bobrow Published in A. Paepcke, editor, Object-Oriented Programming: The CLOS Perspective, pages 101 ¾ 118. The MIT Press, Cambridge, MA, 1993. © Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. Metaob ject Proto cols WhyWeWant Them and What Else They Can Do App ears in Object OrientedProgramming: The CLOS Perspective c Copyright 1993 MIT Press Gregor Kiczales, J. Michael Ashley, Luis Ro driguez, Amin Vahdat and Daniel G. Bobrow Original ly conceivedasaneat idea that could help solve problems in the design and implementation of CLOS, the metaobject protocol framework now appears to have applicability to a wide range of problems that come up in high-level languages. This chapter sketches this wider potential, by drawing an analogy to ordinary language design, by presenting some early design principles, and by presenting an overview of three new metaobject protcols we have designed that, respectively, control the semantics of Scheme, the compilation of Scheme, and the static paral lelization of Scheme programs. Intro duction The CLOS Metaob ject Proto col MOP was motivated by the tension b etween, what at the time, seemed liketwo con icting desires. The rst was to have a relatively small but p owerful language for doing ob ject-oriented programming in Lisp. The second was to satisfy what seemed to b e a large numb er of user demands, including: compatibility with previous languages, p erformance compara- ble to or b etter than previous implementations and extensibility to allow further exp erimentation with ob ject-oriented concepts see Chapter 2 for examples of directions in which ob ject-oriented techniques might b e pushed.
    [Show full text]
  • On Model Subtyping Cl´Ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´Ez´Equel
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by HAL-Rennes 1 On Model Subtyping Cl´ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´ez´equel To cite this version: Cl´ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´ez´equel.On Model Subtyping. ECMFA - 8th European Conference on Modelling Foundations and Applications, Jul 2012, Kgs. Lyngby, Denmark. 2012. <hal-00695034> HAL Id: hal-00695034 https://hal.inria.fr/hal-00695034 Submitted on 7 May 2012 HAL is a multi-disciplinary open access L'archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´eeau d´ep^otet `ala diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publi´esou non, lished or not. The documents may come from ´emanant des ´etablissements d'enseignement et de teaching and research institutions in France or recherche fran¸caisou ´etrangers,des laboratoires abroad, or from public or private research centers. publics ou priv´es. On Model Subtyping Clément Guy1, Benoit Combemale1, Steven Derrien1, Jim R. H. Steel2, and Jean-Marc Jézéquel1 1 University of Rennes1, IRISA/INRIA, France 2 University of Queensland, Australia Abstract. Various approaches have recently been proposed to ease the manipu- lation of models for specific purposes (e.g., automatic model adaptation or reuse of model transformations). Such approaches raise the need for a unified theory that would ease their combination, but would also outline the scope of what can be expected in terms of engineering to put model manipulation into action.
    [Show full text]
  • Chapter 2 Basics of Scanning And
    Chapter 2 Basics of Scanning and Conventional Programming in Java In this chapter, we will introduce you to an initial set of Java features, the equivalent of which you should have seen in your CS-1 class; the separation of problem, representation, algorithm and program – four concepts you have probably seen in your CS-1 class; style rules with which you are probably familiar, and scanning - a general class of problems we see in both computer science and other fields. Each chapter is associated with an animating recorded PowerPoint presentation and a YouTube video created from the presentation. It is meant to be a transcript of the associated presentation that contains little graphics and thus can be read even on a small device. You should refer to the associated material if you feel the need for a different instruction medium. Also associated with each chapter is hyperlinked code examples presented here. References to previously presented code modules are links that can be traversed to remind you of the details. The resources for this chapter are: PowerPoint Presentation YouTube Video Code Examples Algorithms and Representation Four concepts we explicitly or implicitly encounter while programming are problems, representations, algorithms and programs. Programs, of course, are instructions executed by the computer. Problems are what we try to solve when we write programs. Usually we do not go directly from problems to programs. Two intermediate steps are creating algorithms and identifying representations. Algorithms are sequences of steps to solve problems. So are programs. Thus, all programs are algorithms but the reverse is not true.
    [Show full text]
  • Lecture 2: Variables and Primitive Data Types
    Lecture 2: Variables and Primitive Data Types MIT-AITI Kenya 2005 1 In this lecture, you will learn… • What a variable is – Types of variables – Naming of variables – Variable assignment • What a primitive data type is • Other data types (ex. String) MIT-Africa Internet Technology Initiative 2 ©2005 What is a Variable? • In basic algebra, variables are symbols that can represent values in formulas. • For example the variable x in the formula f(x)=x2+2 can represent any number value. • Similarly, variables in computer program are symbols for arbitrary data. MIT-Africa Internet Technology Initiative 3 ©2005 A Variable Analogy • Think of variables as an empty box that you can put values in. • We can label the box with a name like “Box X” and re-use it many times. • Can perform tasks on the box without caring about what’s inside: – “Move Box X to Shelf A” – “Put item Z in box” – “Open Box X” – “Remove contents from Box X” MIT-Africa Internet Technology Initiative 4 ©2005 Variables Types in Java • Variables in Java have a type. • The type defines what kinds of values a variable is allowed to store. • Think of a variable’s type as the size or shape of the empty box. • The variable x in f(x)=x2+2 is implicitly a number. • If x is a symbol representing the word “Fish”, the formula doesn’t make sense. MIT-Africa Internet Technology Initiative 5 ©2005 Java Types • Integer Types: – int: Most numbers you’ll deal with. – long: Big integers; science, finance, computing. – short: Small integers.
    [Show full text]
  • Design and Implementation of Generics for the .NET Common Language Runtime
    Design and Implementation of Generics for the .NET Common Language Runtime Andrew Kennedy Don Syme Microsoft Research, Cambridge, U.K. fakeÒÒ¸d×ÝÑeg@ÑicÖÓ×ÓfغcÓÑ Abstract cally through an interface definition language, or IDL) that is nec- essary for language interoperation. The Microsoft .NET Common Language Runtime provides a This paper describes the design and implementation of support shared type system, intermediate language and dynamic execution for parametric polymorphism in the CLR. In its initial release, the environment for the implementation and inter-operation of multiple CLR has no support for polymorphism, an omission shared by the source languages. In this paper we extend it with direct support for JVM. Of course, it is always possible to “compile away” polymor- parametric polymorphism (also known as generics), describing the phism by translation, as has been demonstrated in a number of ex- design through examples written in an extended version of the C# tensions to Java [14, 4, 6, 13, 2, 16] that require no change to the programming language, and explaining aspects of implementation JVM, and in compilers for polymorphic languages that target the by reference to a prototype extension to the runtime. JVM or CLR (MLj [3], Haskell, Eiffel, Mercury). However, such Our design is very expressive, supporting parameterized types, systems inevitably suffer drawbacks of some kind, whether through polymorphic static, instance and virtual methods, “F-bounded” source language restrictions (disallowing primitive type instanti- type parameters, instantiation at pointer and value types, polymor- ations to enable a simple erasure-based translation, as in GJ and phic recursion, and exact run-time types.
    [Show full text]
  • Subtyping Recursive Types
    ACM Transactions on Programming Languages and Systems, 15(4), pp. 575-631, 1993. Subtyping Recursive Types Roberto M. Amadio1 Luca Cardelli CNRS-CRIN, Nancy DEC, Systems Research Center Abstract We investigate the interactions of subtyping and recursive types, in a simply typed λ-calculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equivalence and subtyping that are induced by a model, an ordering on infinite trees, an algorithm, and a set of type rules. We show soundness and completeness between the rules, the algorithm, and the tree semantics. We also prove soundness and a restricted form of completeness for the model. To address the second question, we show that to every pair of types in the subtype relation we can associate a term whose denotation is the uniquely determined coercion map between the two types. Moreover, we derive an algorithm that, when given a term with implicit coercions, can infer its least type whenever possible. 1This author's work has been supported in part by Digital Equipment Corporation and in part by the Stanford-CNR Collaboration Project. Page 1 Contents 1. Introduction 1.1 Types 1.2 Subtypes 1.3 Equality of Recursive Types 1.4 Subtyping of Recursive Types 1.5 Algorithm outline 1.6 Formal development 2. A Simply Typed λ-calculus with Recursive Types 2.1 Types 2.2 Terms 2.3 Equations 3. Tree Ordering 3.1 Subtyping Non-recursive Types 3.2 Folding and Unfolding 3.3 Tree Expansion 3.4 Finite Approximations 4.
    [Show full text]
  • Parametric Polymorphism Parametric Polymorphism
    Parametric Polymorphism Parametric Polymorphism • is a way to make a language more expressive, while still maintaining full static type-safety (every Haskell expression has a type, and types are all checked at compile-time; programs with type errors will not even compile) • using parametric polymorphism, a function or a data type can be written generically so that it can handle values identically without depending on their type • such functions and data types are called generic functions and generic datatypes Polymorphism in Haskell • Two kinds of polymorphism in Haskell – parametric and ad hoc (coming later!) • Both kinds involve type variables, standing for arbitrary types. • Easy to spot because they start with lower case letters • Usually we just use one letter on its own, e.g. a, b, c • When we use a polymorphic function we will usually do so at a specific type, called an instance. The process is called instantiation. Identity function Consider the identity function: id x = x Prelude> :t id id :: a -> a It does not do anything with the input other than returning it, therefore it places no constraints on the input's type. Prelude> :t id id :: a -> a Prelude> id 3 3 Prelude> id "hello" "hello" Prelude> id 'c' 'c' Polymorphic datatypes • The identity function is the simplest possible polymorphic function but not very interesting • Most useful polymorphic functions involve polymorphic types • Notation – write the name(s) of the type variable(s) used to the left of the = symbol Maybe data Maybe a = Nothing | Just a • a is the type variable • When we instantiate a to something, e.g.
    [Show full text]
  • CSE 307: Principles of Programming Languages Classes and Inheritance
    OOP Introduction Type & Subtype Inheritance Overloading and Overriding CSE 307: Principles of Programming Languages Classes and Inheritance R. Sekar 1 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Topics 1. OOP Introduction 3. Inheritance 2. Type & Subtype 4. Overloading and Overriding 2 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Section 1 OOP Introduction 3 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding OOP (Object Oriented Programming) So far the languages that we encountered treat data and computation separately. In OOP, the data and computation are combined into an “object”. 4 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP more convenient: collects related information together, rather than distributing it. Example: C++ iostream class collects all I/O related operations together into one central place. Contrast with C I/O library, which consists of many distinct functions such as getchar, printf, scanf, sscanf, etc. centralizes and regulates access to data. If there is an error that corrupts object data, we need to look for the error only within its class Contrast with C programs, where access/modification code is distributed throughout the program 5 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP (Continued) Promotes reuse. by separating interface from implementation. We can replace the implementation of an object without changing client code. Contrast with C, where the implementation of a data structure such as a linked list is integrated into the client code by permitting extension of new objects via inheritance. Inheritance allows a new class to reuse the features of an existing class.
    [Show full text]
  • INF 102 CONCEPTS of PROG. LANGS Type Systems
    INF 102 CONCEPTS OF PROG. LANGS Type Systems Instructors: James Jones Copyright © Instructors. What is a Data Type? • A type is a collection of computational entities that share some common property • Programming languages are designed to help programmers organize computational constructs and use them correctly. Many programming languages organize data and computations into collections called types. • Some examples of types are: o the type Int of integers o the type (Int→Int) of functions from integers to integers Why do we need them? • Consider “untyped” universes: • Bit string in computer memory • λ-expressions in λ calculus • Sets in set theory • “untyped” = there’s only 1 type • Types arise naturally to categorize objects according to patterns of use • E.g. all integer numbers have same set of applicable operations Use of Types • Identifying and preventing meaningless errors in the program o Compile-time checking o Run-time checking • Program Organization and documentation o Separate types for separate concepts o Indicates intended use declared identifiers • Supports Optimization o Short integers require fewer bits o Access record component by known offset Type Errors • A type error occurs when a computational entity, such as a function or a data value, is used in a manner that is inconsistent with the concept it represents • Languages represent values as sequences of bits. A "type error" occurs when a bit sequence written for one type is used as a bit sequence for another type • A simple example can be assigning a string to an integer
    [Show full text]
  • 13 Templates-Generics.Pdf
    CS 242 2012 Generic programming in OO Languages Reading Text: Sections 9.4.1 and 9.4.3 J Koskinen, Metaprogramming in C++, Sections 2 – 5 Gilad Bracha, Generics in the Java Programming Language Questions • If subtyping and inheritance are so great, why do we need type parameterization in object- oriented languages? • The great polymorphism debate – Subtype polymorphism • Apply f(Object x) to any y : C <: Object – Parametric polymorphism • Apply generic <T> f(T x) to any y : C Do these serve similar or different purposes? Outline • C++ Templates – Polymorphism vs Overloading – C++ Template specialization – Example: Standard Template Library (STL) – C++ Template metaprogramming • Java Generics – Subtyping versus generics – Static type checking for generics – Implementation of Java generics Polymorphism vs Overloading • Parametric polymorphism – Single algorithm may be given many types – Type variable may be replaced by any type – f :: tt => f :: IntInt, f :: BoolBool, ... • Overloading – A single symbol may refer to more than one algorithm – Each algorithm may have different type – Choice of algorithm determined by type context – Types of symbol may be arbitrarily different – + has types int*intint, real*realreal, ... Polymorphism: Haskell vs C++ • Haskell polymorphic function – Declarations (generally) require no type information – Type inference uses type variables – Type inference substitutes for variables as needed to instantiate polymorphic code • C++ function template – Programmer declares argument, result types of fctns – Programmers
    [Show full text]
  • Concepts and Paradigms of Object-Oriented Programming Expansion of Oct 400PSLA-89 Keynote Talk Peter Wegner, Brown University
    Concepts and Paradigms of Object-Oriented Programming Expansion of Oct 400PSLA-89 Keynote Talk Peter Wegner, Brown University 1. What Is It? 8 1.1. Objects 8 1.2. Classes 10 1.3. Inheritance 11 1.4. Object-Oriented Systems 12 2. What Are Its Goals? 13 2.1. Software Components 13 2.2. Object-Oriented Libraries 14 2.3. Reusability and Capital-intensive Software Technology 16 2.4. Object-Oriented Programming in the Very Large 18 3. What Are Its Origins? 19 3.1. Programming Language Evolution 19 3.2. Programming Language Paradigms 21 4. What Are Its Paradigms? 22 4.1. The State Partitioning Paradigm 23 4.2. State Transition, Communication, and Classification Paradigms 24 4.3. Subparadigms of Object-Based Programming 26 5. What Are Its Design Alternatives? 28 5.1. Objects 28 5.2. Types 33 5.3. Inheritance 36 5.4. Strongly Typed Object-Oriented Languages 43 5.5. Interesting Language Classes 45 5.6. Object-Oriented Concept Hierarchies 46 6. what Are Its Models of Concurrency? 49 6.1. Process Structure 50 6.2. Internal Process Concurrency 55 6.3. Design Alternatives for Synchronization 56 6.4. Asynchronous Messages, Futures, and Promises 57 6.5. Inter-Process Communication 58 6.6. Abstraction, Distribution, and Synchronization Boundaries 59 6.7. Persistence and Transactions 60 7. What Are Its Formal Computational Models? 62 7.1. Automata as Models of Object Behavior 62 7.2. Mathematical Models of Types and Classes 65 7.3. The Essence of Inheritance 74 7.4. Reflection in Object-Oriented Systems 78 8.
    [Show full text]