DOCSLIB.ORG

Abstract Types Have Existential Type

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Abstract Types Have Existential Type Abstract Types Have Existential Type JOHN C. MITCHELL Stanford University AND GORDON D. PLOTKIN University of Edinburgh Abstract data type declarations appear in typed programming languages like Ada, Alphard, CLU and ML. This form of declaration binds a list of identifiers to a type with associated operations, a composite “value” we call a data algebra. We use a second-order typed lambda calculus SOL to show how data algebras may be given types, passed as parameters, and returned as results of function calls. In the process, we discuss the semantics of abstract data type declarations and review a connection between typed programming languages and constructive logic. Categories and Subject Descriptors: D.3 [Software]: Programming Languages; D.3.2 [Program- ming Languages]: Language Classifications-applicative languages; D.3.3 [Programming Lan- guages]: Language Constructs--abstract data types; F.3 [Theory of Conmputation]: Logics and Meanings of Programs; F.3.2 [Logics and Meanings of Programs]: Semantics of Programming Languages-denotational semantics, operational semantics; F.3.3 [Logics and Meanings of Pro- grams]: Studies of Program Constructs-type structure General Terms: Languages, Theory, Verification Additional Key Words and Phrases: Abstract data types, lambda calculus, polymorphism, program- ming languages, types 1. INTRODUCTION Ada packages [17], Alphard forms [66, 711, CLU clusters [41, 421, and abstype declarations in ML [23] all bind identifiers to values. Although there are minor variations among these constructs, each allows a list of names to be bound to a composite value consisting of “private” type and one or more operations. For example, the ML declaration abstype complex = real # real with create = . and pius = . and re = . andim= ..- An earlier version of this paper appeared in the Proceedings of the 22thACM Symposium on Principles of Programming Languages (New Orleans, La., Jan. 14-16). ACM, New York, 1985. Authors’ addresses: J. C. Mitchell, Department of Computer Science, Stanford University, Stanford, CA 94305; G. D. Plotkin, Department of Computer Science, University of Edinburgh, Edinburgh, Scotland EH9 352. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 0 1988 ACM 0164-0925/88/0700-0470 $01.50 ACM Transactions on Programming Languages and Systems, Vol. 10, No. 3, July 1988, Pages 470-502. Abstract Types Have Existential Type l 471 binds the identifiers complex, create, plus, re, and im to the components of an implementation of complex numbers. The implementation consists of the collec- tion defined by the ML expression real # real, meaning the type of pairs of reals, and the functions denoted by the code for create, plus, and so on. An important aspect of this construct is that access to the representation is limited. We cannot apply arbitrary operations on pairs of reals to elements of type complex; only the explicitly declared operations may be used. We will call a composite value constructed from a set and one or more operations, packaged up in a way that limits access, a data algebra. We will discuss the typing rules associated with the formation and the use of data algebras and observe that data algebras themselves may be given types in a straightforward manner. This will allow us to devise a typed programming notation in which implementations of abstract data types may be passed as parameters or returned as the results of function calls. The phrase “abstract data type” sometimes refers to a class of algebras (or perhaps an initial algebra) satisfying some specification. For example, the ab- stract type stack is sometimes regarded as the class of all algebras satisfying the familiar logical formulas axiomatizing push and pop. Associated with this view is the tenet that a program must rely only on the data type specification, as opposed to properties of a particular implementation. Although this is a valuable guiding principle, most programming languages do not contain assertions or their proofs, and without this information it is impossible for a compiler to guarantee that a program depends only on a data type specification. Since we are primarily concerned with properties of the abstract data type declarations used in common programming languages, we will focus on the limited form of information hiding or “abstraction” provided by conventional type checking rules. We can be more specific about how data algebras are defined by considering the declaration of complex numbers in more detail. Using an explicitly typed ML-like notation, the declaration sketched earlier looks something like this: abstype complex = real # real with create: real + real + complex = Xx: real. Xy: real. ( X, y ) and plus: complex --, complex = Xz:real # real. Xw:real # real. ( fst(z) + fst(w), snd(z) + snd(w)) and re: complex + real = Xz:real # real.fst(z) and im: complex + real = Xz:real # real. snd(z) The identifiers complex, create, plus, re, and im are bound to a data algebra whose elements are represented as pairs of reals, as specified by the type expression real # real. The operations of the data algebra are given by the function expres- sions to the right of the equals signs1 Notice that the declared types of the operations differ from the types of the implementing functions. For example, re is declared to have type complex + real, but the implementing expression has type real # real + real. This is because operations are defined using the concrete representation of values, but the representation is hidden outside the declaration. In the next section, we will discuss the type checking rules associated with abstract data type declarations, which are designed to make complex numbers 1 In most programming languages, function definitions have the form “create(x:real, y:real) = . .” In the example above, we have used explicit lambda abstraction to move the formal parameters from the left- to the right-hand sides of the equals signs. ACM Transactions on Programming Languages and Systems, Vol. 10, No. 3, July 1988. 472 9 J. C. Mitchell and G. D. Plotkin “abstract” outside the data algebra definition. In the process, we will give types to data algebras. These will be existential types, which were originally developed in constructive logic and are closely related to infinite sums (as in category theory, for example). In Section 3, we describe a statically typed language SOL. This language is a notational variant of Girard’s system F, developed in the analysis of constructive logic [21,22], and an extension of Reynolds’ polymorphic lambda calculus [62]. An operational semantics of SOL, based on the work of Girard and Reynolds, is presented using reduction rules. However, we do not address a variety of practical implementation issues. Although the basic calculus we use has been known for some time, we believe that the analysis of data abstraction using existential types originates with this paper. (A preliminary version appeared as [56].) The use of SOL as a proof-theoretic tool is based on an analogy between types and constructive logic. This analogy gives rise to a large family of typed languages and suggests that our analysis of abstract data types applies to more expressive languages involving specifications. Since the connection between constructive proofs and typed programs does not seem to be well known in the programming language community (at least at present), our brief discussion of specifications will follow a review of the general analogy in Section 4. Additional SOL program- ming examples are given in Section 5. The design of SOL suggests new programming languages along the lines of Ada, Alphard, CLU, and ML but with richer and more flexible type structures. In addition, SOL seems to be a natural “kernel language” for studying the semantics of languages with polymorphic functions and abstract data type declarations. For this reason, we expect SOL to be useful in future studies of current languages. It is clear that SOL provides greater flexibility in the use of abstract data types than previous languages, since data algebras may be passed as parameters and returned as results. We believe that this is accomplished without any compromise in “type security.” However, since we do not have a precise characterization of type security, we are unable to show rigorously that SOL is secure.’ Some languages that are similar to SOL in scope and intent are Pebble [7], designed to capture some essential features of Cedar (an extension of Mesa [57]), and Kernel Russell, KR, of [28], based on Russell [14, 15, 161. Martin-Lof’s constructive type theory [46] and the calculus of constructions [ll] are farther from programming language syntax but share many properties of SOL. Some features of Martin-Lof’s system have been incorporated into the Standard ML module design [44, 541, which was formulated after the work described here was completed. We will compare SOL with some of these languages in Section 3.8. 2. TYPING RULES FOR ABSTRACT DATA TYPE DECLARATIONS The basic typing rules associated with abstract data type declarations do not differ much from language to language. To avoid the unnecessary complication of discussing a variety of syntactic forms, we describe abstract data types using the syntax we will adopt in SOL. Although this syntax was chosen to resemble ’ Research begun after this paper was written has shed some light on the type security of SOL. See [52] and [55] for further discussion. ACM Transactions on Programming Languages and Systems, Vol. 10, No. 3, July 1988. Abstract Types Have Existential Type 473 common languages, there is one novel aspect that leads to additional flexibility: We separate the names bound by a declaration from the data algebra they come to denote.
Load more

Recommended publications
  • Artificial Intelligence in Health Care: the Hope, the Hype, the Promise, the Peril
    Artificial Intelligence in Health Care: The Hope, the Hype, the Promise, the Peril Michael Matheny, Sonoo Thadaney Israni, Mahnoor Ahmed, and Danielle Whicher, Editors WASHINGTON, DC NAM.EDU PREPUBLICATION COPY - Uncorrected Proofs NATIONAL ACADEMY OF MEDICINE • 500 Fifth Street, NW • WASHINGTON, DC 20001 NOTICE: This publication has undergone peer review according to procedures established by the National Academy of Medicine (NAM). Publication by the NAM worthy of public attention, but does not constitute endorsement of conclusions and recommendationssignifies that it is the by productthe NAM. of The a carefully views presented considered in processthis publication and is a contributionare those of individual contributors and do not represent formal consensus positions of the authors’ organizations; the NAM; or the National Academies of Sciences, Engineering, and Medicine. Library of Congress Cataloging-in-Publication Data to Come Copyright 2019 by the National Academy of Sciences. All rights reserved. Printed in the United States of America. Suggested citation: Matheny, M., S. Thadaney Israni, M. Ahmed, and D. Whicher, Editors. 2019. Artificial Intelligence in Health Care: The Hope, the Hype, the Promise, the Peril. NAM Special Publication. Washington, DC: National Academy of Medicine. PREPUBLICATION COPY - Uncorrected Proofs “Knowing is not enough; we must apply. Willing is not enough; we must do.” --GOETHE PREPUBLICATION COPY - Uncorrected Proofs ABOUT THE NATIONAL ACADEMY OF MEDICINE The National Academy of Medicine is one of three Academies constituting the Nation- al Academies of Sciences, Engineering, and Medicine (the National Academies). The Na- tional Academies provide independent, objective analysis and advice to the nation and conduct other activities to solve complex problems and inform public policy decisions.
    [Show full text]
  • Computational Thinking's Influence on Research and Education For
    Computational thinking’s influence on research and education for all Influenza del pensiero computazionale nella ricerca e nell’educazione per tutti Jeannette M. Wing Columbia University, New York, N.Y., USA, [email protected] HOW TO CITE Wing, J.M. (2017). Computational thinking’s influence on research and education for all. Italian Journal of Educational Technology, 25(2), 7-14. doi: 10.17471/2499-4324/922 ABSTRACT Computer science has produced, at an astonishing and breathtaking pace, amazing technology that has transformed our lives with profound economic and societal impact. In the course of the past ten years, we have come to realize that computer science offers not just useful software and hardware artifacts, but also an intellectual framework for thinking, what I call “computational thinking”. Everyone can benefit from thinking computationally. My grand vision is that computational thinking will be a fundamental skill—just like reading, writing, and arithmetic—used by everyone by the middle of the 21st Century. KEYWORDS Computational Thinking, Education, Curriculum. SOMMARIO L’informatica ha prodotto, a un ritmo sorprendente e mozzafiato, una straordinaria tecnologia che ha profondamente trasformato le nostre vite con importanti conseguenze economiche e sociali. Negli ultimi dieci anni ci si è resi conto che l’informatica non solo offre utili artefatti software e hardware, ma anche un paradigma di ragionamento che chiamo “pensiero computazionale”. Ognuno di noi può trarre vantaggio dal pensare in modo computazionale. Mi aspetto che il pensiero computazionale costituirà un’abilità fondamentale - come leggere, scrivere e far di conto – che verrà utilizzata da tutti entro la prima metà del XXI secolo.
    [Show full text]
  • A Nominal Theory of Objects with Dependent Types
    A Nominal Theory of Objects with Dependent Types Martin Odersky, Vincent Cremet, Christine R¨ockl, Matthias Zenger Ecole´ Polytechnique F´ed´eralede Lausanne INR Ecublens 1015 Lausanne, Switzerland Technical Report IC/2002/070 Abstract Simula 67 [DMN70], whereas virtual or abstract types are present in BETA [MMPN93], as well as more recently in We design and study νObj, a calculus and dependent type gbeta [Ern99], Rune [Tor02] and Scala [Ode02]. An es- system for objects and classes which can have types as mem- sential ingredient of these systems are objects with type bers. Type members can be aliases, abstract types, or new members. There is currently much work that explores types. The type system can model the essential concepts the uses of this concept in object-oriented programming of Java’s inner classes as well as virtual types and family [SB98, TT99, Ern01, Ost02]. But its type theoretic foun- polymorphism found in BETA or gbeta. It can also model dations are just beginning to be investigated. most concepts of SML-style module systems, including shar- As is the case for modules, dependent types are a promis- ing constraints and higher-order functors, but excluding ap- ing candidate for a foundation of objects with type mem- plicative functors. The type system can thus be used as a bers. Dependent products can be used to represent functors basis for unifying concepts that so far existed in parallel in in SML module systems as well as classes in object sys- advanced object systems and in module systems. The paper tems with virtual types [IP02].
    [Show full text]
  • The Power of Interoperability: Why Objects Are Inevitable
    The Power of Interoperability: Why Objects Are Inevitable Jonathan Aldrich Carnegie Mellon University Pittsburgh, PA, USA [email protected] Abstract 1. Introduction Three years ago in this venue, Cook argued that in Object-oriented programming has been highly suc- their essence, objects are what Reynolds called proce- cessful in practice, and has arguably become the dom- dural data structures. His observation raises a natural inant programming paradigm for writing applications question: if procedural data structures are the essence software in industry. This success can be documented of objects, has this contributed to the empirical success in many ways. For example, of the top ten program- of objects, and if so, how? ming languages at the LangPop.com index, six are pri- This essay attempts to answer that question. After marily object-oriented, and an additional two (PHP reviewing Cook’s definition, I propose the term ser- and Perl) have object-oriented features.1 The equiva- vice abstractions to capture the essential nature of ob- lent numbers for the top ten languages in the TIOBE in- jects. This terminology emphasizes, following Kay, that dex are six and three.2 SourceForge’s most popular lan- objects are not primarily about representing and ma- guages are Java and C++;3 GitHub’s are JavaScript and nipulating data, but are more about providing ser- Ruby.4 Furthermore, objects’ influence is not limited vices in support of higher-level goals. Using examples to object-oriented languages; Cook [8] argues that Mi- taken from object-oriented frameworks, I illustrate the crosoft’s Component Object Model (COM), which has unique design leverage that service abstractions pro- a C language interface, is “one of the most pure object- vide: the ability to define abstractions that can be ex- oriented programming models yet defined.” Academ- tended, and whose extensions are interoperable in a ically, object-oriented programming is a primary focus first-class way.
    [Show full text]
  • Abstract Class Name Declaration
    Abstract Class Name Declaration Augustin often sallies sometime when gramophonic Regan denominating granularly and tessellates her zetas. Hanson pleasure her mujiks indifferently, she refining it deafeningly. Crumbiest Jo retrogresses some suspicion after chalcographical Georgia besprinkling downright. Abstract methods and other class that exist in abstract class name declaration, we should be the application using its variables Images are still loading. Java constructor declarations are not members. Not all fields need individual field accessors and mutators. Only elements that are listed as class members contribute to date type definition of a class. When you subclass an abstract class, improve service, etc. Be careful while extending above abstract class, with to little hitch. Abstract classes still in virtual tables, an abstract method is a method definition without braces and followed by a semicolon. Error while getting part list from Facebook! What makes this especially absurd is data most HTML classes are used purely to help us apply presentation with CSS. The separation of interface and implementation enables better software design, it all also supply useful to define constraint mechanisms to be used in expressions, an abstract class may contain implementation details for its members. Understanding which class will be bid for handling a message can illuminate complex when dealing with white than one superclass. How to compute the area if the dust is have known? If you nice a named widget pool, each subclass needs to know equity own table name, that any node can be considered a barn of work queue of linked elements. In only of a Java constructor data members are initialized.
    [Show full text]
  • Abstract Class Function Declaration Typescript
    Abstract Class Function Declaration Typescript Daniel remains well-established after Vale quote anemographically or singe any fortitude. Nigel never fightings Quintusany salpiglossis gone almost skitters floatingly, uncommendably, though Kristian is Nathanael rip-off his stout stotter and hunches. lived enough? Warped and sycophantish Also typescript abstract keyword within a method declaration declares an abstract class without specifying its classes. The typescript has only operate on structural typing appears. Methods in the classes are always defined. Working with JET Elements JET Elements are exported as Typescript interfaces. Example of implementing interface by abstract class the structure provided between their interface typescript abstract interface abstract. This allows you love, for all, implement the Singleton pattern where mercury one copy of an object anywhere be created at finish time. Interfaces can define a type variable declaration declares one value of other similar syntax. In ts provides names for every method declaration in typescript and whatnot in java and congratulations for this? Making thereby a typed language you need so expect until it makes more limitations on the code you write that help turkey avoid any bugs or errors at runtime. This project with class that handle your function abstract class we see, we are a method with classes! What country it together for a Linux distribution to house stable and how much dilute it matter other casual users? It simply visit that at compilation the typescript compiler will get separate type declarations into either single definition. Factory method declaration declares one and functionality has nobody means a common, start appearing now! Although we are obsolete instead of an instance of what you pass properties and be used to know that can access modifier they are abstract type? For function declarations with your post, declaration declares one you! Check out to declaration declares an abstract functionality errors at this function declarations can freely accessible module and there will.
    [Show full text]
  • Static Type Inference for Parametric Classes
    University of Pennsylvania ScholarlyCommons Technical Reports (CIS) Department of Computer & Information Science September 1989 Static Type Inference for Parametric Classes Atsushi Ohori University of Pennsylvania Peter Buneman University of Pennsylvania Follow this and additional works at: https://repository.upenn.edu/cis_reports Recommended Citation Atsushi Ohori and Peter Buneman, "Static Type Inference for Parametric Classes", . September 1989. University of Pennsylvania Department of Computer and Information Science Technical Report No. MS-CIS-89-59. This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_reports/851 For more information, please contact [email protected]. Static Type Inference for Parametric Classes Abstract Central features of object-oriented programming are method inheritance and data abstraction attained through hierarchical organization of classes. Recent studies show that method inheritance can be nicely supported by ML style type inference when extended to labeled records. This is based on the fact that a function that selects a field ƒ of a record can be given a polymorphic type that enables it to be applied to any record which contains a field ƒ. Several type systems also provide data abstraction through abstract type declarations. However, these two features have not yet been properly integrated in a statically checked polymorphic type system. This paper proposes a static type system that achieves this integration in an ML-like polymorphic language by adding a class construct that allows the programmer to build a hierarchy of classes connected by multiple inheritance declarations. Moreover, classes can be parameterized by types allowing "generic" definitions. The type correctness of class declarations is st atically checked by the type system.
    [Show full text]
  • Syntactic Type Abstraction
    Syntactic Type Abstraction DAN GROSSMAN, GREG MORRISETT, and STEVE ZDANCEWIC Cornell University Software developers often structure programs in such a way that different pieces of code constitute distinct principals. Types help define the protocol by which these principals interact. In particular, abstract types allow a principal to make strong assumptions about how well-typed clients use the facilities that it provides. We show how the notions of principals and type abstraction can be formalized within a language. Different principals can know the implementation of different abstract types. We use additional syntax to track the flow of values with abstract types during the evaluation of a program and demonstrate how this framework supports syntactic proofs (in the style of subject reduction) for type-abstraction properties. Such properties have traditionally required semantic arguments; using syntax avoids the need to build a model for the language. We present various typed lambda calculi with principals, including versions that have mutable state and recursive types. Categories and Subject Descriptors: D.2.11 [Software Engineering]: Software Architectures— Information Hiding; Languages; D.3.1 [Programming Languages]: Formal Definitions and Theory—Syntax; Semantics; D.3.3 [Programming Languages]: Language Constructs and Fea- tures—Abstract data types; F.3.2 [Logics and Meanings of Programs]: Semantics of Program- ming Languages—Operational Semantics; F.3.3 [Logics and Meanings of Programs]: Studies of Program Constructs—Type Structure General Terms: Languages, Security, Theory, Verification Additional Key Words and Phrases: Operational semantics, parametricity, proof techniques, syn- tactic proofs, type abstraction 1. INTRODUCTION Programmers often use a notion of principal when designing the structure of a program.
    [Show full text]
  • Thomas Heldt
    Thomas Heldt Institute for Medical Engineering & Science p: (617) 324-5005 Massachusetts Institute of Technology f: (617) 253-7498 Room E25-324 e: [email protected] 77 Massachusetts Avenue Cambridge, MA 02139 Education Massachusetts Institute of Technology, Cambridge, MA, USA 1997 { 2004 Harvard { MIT Division of Health Sciences and Technology Ph.D. Medical Physics, September 2004 Thesis title: Computational Models of Cardiovascular Response to Orthostatic Stress Yale University, New Haven, CT, USA 1995 { 1997 M.S. Physics, June 1997 M.Phil. Physics, December 1998 Johannes Gutenberg-Universit¨at,Mainz, Germany 1994 { 1995 First-year medical studies Johannes Gutenberg-Universit¨at,Mainz, Germany 1992 { 1995 Diplomvorpr¨ufungPhysics, June 1994 Passed Diplomvorpr¨ufungin Physics with honors Experience Associate Professor of Electrical and Biomedical Engineering 07/2017 { present Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science W.M. Keck Career Development Professor in Biomedical Engineering 07/2016 { present Massachusetts Institute of Technology Member of the Affiliate Faculty of Health Sciences & Technology 05/2014 { present Harvard Medical School Core Faculty Member 07/2013 { present Massachusetts Institute of Technology Institute for Medical Engineering and Science Principal Investigator 07/2013 { present Massachusetts Institute of Technology Research Laboratory of Electronics Hermann L.F. von Helmholtz Career Development Professor 07/2013 { 06/2016 Massachusetts Institute of Technology Institute for Medical Engineering and Science Assistant Professor of Electrical and Biomedical Engineering 07/2013 { 06/2017 Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science Principal Research Scientist 07/2012 { 07/2013 Massachusetts Institute of Technology Computational Physiology and Clinical Inference Group Thomas Heldt, Ph.D.
    [Show full text]
  • Private Companiescompanies
    PrivatePrivate CompaniesCompanies Private Company Profiles @Ventures Kepware Technologies Access 360 Media LifeYield Acronis LogiXML Acumentrics Magnolia Solar Advent Solar Mariah Power Agion Technologies MetaCarta Akorri mindSHIFT Technologies alfabet Motionbox Arbor Networks Norbury Financial Asempra Technologies NumeriX Asset Control OpenConnect Atlas Venture Panasas Autonomic Networks Perimeter eSecurity Azaleos Permabit Technology Azimuth Systems PermissionTV Black Duck Software PlumChoice Online PC Services Brainshark Polaris Venture Partners BroadSoft PriceMetrix BzzAgent Reva Systems Cedar Point Communications Revolabs Ceres SafeNet Certeon Sandbridge Technologies Certica Solutions Security Innovation cMarket Silver Peak Systems Code:Red SIMtone ConsumerPowerline SkyeTek CorporateRewards SoloHealth Courion Sonicbids Crossbeam Systems StyleFeeder Cyber-Ark Software TAGSYS DAFCA Tatara Systems Demandware Tradeware Global Desktone Tutor.com Epic Advertising U4EA Technologies ExtendMedia Ubiquisys Fidelis Security Systems UltraCell Flagship Ventures Vanu Fortisphere Versata Enterprises GENBAND Visible Assets General Catalyst Partners VKernel Hearst Interactive Media VPIsystems Highland Capital Partners Ze-gen HSMC ZoomInfo Invention Machine @Ventures Address: 187 Ballardvale Street, Suite A260 800 Menlo Ave, Suite 120 Wilmington, MA 01887 Menlo Park, CA 94025 Phone #: (978) 658-8980 (650) 322-3246 Fax #: ND ND Website: www.ventures.com www.ventures.com Business Overview @Ventures provides venture capital and growth assistance to early stage clean technology companies. Established in 1995, @Ventures has funded more than 75 companies across a broad set of technology sectors. The exclusive focus of the firm's fifth fund, formed in 2004, is on investments in the cleantech sector, including alternative energy, energy storage and efficiency, advanced materials, and water technologies. Speaker Bio: Marc Poirier, Managing Director Marc Poirier has been a General Partner with @Ventures since 1998 and operates out the firm’s Boston-area office.
    [Show full text]
  • Introduction to the Literature on Programming Language Design Gary T
    Computer Science Technical Reports Computer Science 7-1999 Introduction to the Literature On Programming Language Design Gary T. Leavens Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons Recommended Citation Leavens, Gary T., "Introduction to the Literature On Programming Language Design" (1999). Computer Science Technical Reports. 59. http://lib.dr.iastate.edu/cs_techreports/59 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Introduction to the Literature On Programming Language Design Abstract This is an introduction to the literature on programming language design and related topics. It is intended to cite the most important work, and to provide a place for students to start a literature search. Keywords programming languages, semantics, type systems, polymorphism, type theory, data abstraction, functional programming, object-oriented programming, logic programming, declarative programming, parallel and distributed programming languages Disciplines Programming Languages and Compilers This article is available at Iowa State University Digital Repository: http://lib.dr.iastate.edu/cs_techreports/59 Intro duction to the Literature On Programming Language Design Gary T. Leavens TR 93-01c Jan. 1993, revised Jan. 1994, Feb. 1996, and July 1999 Keywords: programming languages, semantics, typ e systems, p olymorphism, typ e theory, data abstrac- tion, functional programming, ob ject-oriented programming, logic programming, declarative programming, parallel and distributed programming languages.
    [Show full text]
  • Typescript Handbook 2
    1. TypeScript Handbook 2. Table of Contents 3. The TypeScript Handbook 4. Basic Types 5. Interfaces 6. Functions 7. Literal Types 8. Unions and Intersection Types 9. Classes 10. Enums 11. Generics This copy of the TypeScript handbook was generated on Friday, June 26, 2020 against commit 10ecd4 with TypeScript 3.9. The TypeScript Handbook About this Handbook Over 20 years after its introduction to the programming community, JavaScript is now one of the most widespread cross-platform languages ever created. Starting as a small scripting language for adding trivial interactivity to webpages, JavaScript has grown to be a language of choice for both frontend and backend applications of every size. While the size, scope, and complexity of programs written in JavaScript has grown exponentially, the ability of the JavaScript language to express the relationships between different units of code has not. Combined with JavaScript's rather peculiar runtime semantics, this mismatch between language and program complexity has made JavaScript development a difficult task to manage at scale. The most common kinds of errors that programmers write can be described as type errors: a certain kind of value was used where a different kind of value was expected. This could be due to simple typos, a failure to understand the API surface of a library, incorrect assumptions about runtime behavior, or other errors. The goal of TypeScript is to be a static typechecker for JavaScript programs - in other words, a tool that runs before your code runs (static) and ensure that the types of the program are correct (typechecked). If you are coming to TypeScript without a JavaScript background, with the intention of TypeScript being your first language, we recommend you first start reading the documentation on JavaScript at the Mozilla Web Docs.
    [Show full text]