DOCSLIB.ORG

2018-04-17 Let Arguments Go First

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
2018-04-17 Let Arguments Go First Let Arguments Go First Ningning Xie, Bruno C. d. S. Oliveira The University of Hong Kong ESOP 2018, Thessaloniki, Greece 2018-04-17 1 Background 2 Bi-Directional Type Checking • Well known in the folklore of type system for a long time • Popularized by Pierce and Turner’s work* • Can support many type system features: refinements, indexed types, intersections and unions, contextual modal types, object-oriented subtyping, … * Benjamin C Pierce and David N Turner. Local type inference. TOPLAS, 22(1):1–44, 2000. 3 Bi-Directional Type Checking Two Modes in type-checking • Inference (synthesis): e synthesizes A Γ e A ` ) • Checked: check e against A Γ e A ` ( • Which constructs should be in which mode? 4 Let Arguments Go First Ningning Xie and Bruno C. d. S. Oliveira The University of Hong Kong nnxie,bruno @cs.hku.hk { } Abstract. Bi-directional type checking has proved to be an extremely useful and versatile tool for type checking and type inference. The con- ventional presentation of bi-directional type checking consists of two modes: inference mode and checked mode. In traditional bi-directional type-checking, type annotations are used to guide (via the checked mode) the type inference/checking procedure to determine the type of an ex- pression, and type information flows from functions to arguments. 21 This paper presents a variant of bi-directional type checking where the type information5.1 flows Combining from arguments Application to functions. and This Checkedvariant retains Modes the inference mode, but adds a so-called application mode. Such design can remove annotationsAlthough that the basicapplication bi-directional mode type provides checking us cannot, with alternative design choices in and is useful whena bi-directional type information type from system, arguments a checked is required mode to type- can still be easily added. One check the functionsmotivation being applied. for the We checked present mode two applications would be annotated and de- expressions e : A,where velop the meta-theorythe type (mostly of expressions verified in is Coq) known of the and application is therefore mode. used to check expressions. Consider adding e : A for introducing the third checked mode for the lan- 1 Introductionguage in Section 3. Notice that, since the checked mode is stronger than appli- cation mode, when entering checked mode the application context is no longer Bi-directional typeuseful. checking Instead has been we use known application in the folklore subtyping of type to satisfy systems the application context for a long time. Itrequirements. was popularized A possible by Pierce typing and Turner’s rule for work annotation on local expressions type is: inference [29]. Local type inference was introduced as an alternative to Hindley- Milner (henceforth HM system) type systems A [11<, 17: ],B whichΓ coulde easilyA deal ` ` ( T-Ann with polymorphic languages with subtyping. Bi-directionalΓ p (e : A type) checkingB is one component of local type inference that, aided by some` type) annotations, en- ables type inferenceHere, in ane expressiveis checked language using its with annotation polymorphismA, and and then subtyp- we instantiate A to B using ing. Since Pierce andBisubtyping Turner’s-Directional with work, application various other context authorsType . have provedChecking the ef- fectiveness of bi-directionalNow we type can checking have a in rule several set of other the settings, checked including mode for all expressions. For many di↵erent systemsexample, with one subtyping useful rule [12, for15, abstractions14], systems in with checked dependent mode could be Abs-Chk, * types [37, 10• ,A2 ,recipe21,where3], and thefrom various parameter Dunfield other works typeandA [1,serves 13Pfenning, 28, as7, the22]. typeFurthermore, of x, and typing checks the bi-directional typebody checking with hasB. also Also, been combined combined with with the HM-style information techniques flow, the checked rule for for providing type• Introduction inferenceapplication in the checks presencerules the function of higher-ranked with the types full type. [27, 14]. The key idea in bi-directional type checking( is simple. In its basic form typing is split into inferenceΓ and,x: Acheckede modes.B The mostΓ saliente2 featureA ofΓ a bi-e1 A B directional type-checker is when` information( Abs-Chk deduced from` inference) mode` is ( ! App-Chk Γ λx. e A B Γ e e B used to guide checking` of an expression( ! in checked mode. One of such interactions` 1 2 ( between modes• happensEliminationNote in the that typing addingrules rule expression for function annotations applications: might bring convenience for pro- grammers, since annotations) can be moreNotice freely placed here inhow a program. type For exam- Γ e1 A B Γ e2 A ple,` (λf). f 1)! : (Int `Int) ( Int APPbecomesinformation valid. However flows this from does not add Γ e1 e2 !B ! expressive power,` since) programs that are typeablefunctions under to expression arguments annotations, * Joshua Dunfieldwouldand remain Frank Pfenning typeable. Tridirectional aftertypechecking moving. POPL’04, the annotations 2004. to bindings. For example 5 the previous program is equivalent to (λf :(Int Int). f 1). ! This discussion is a sketch. We have not defined the corresponding declarative system nor algorithm. However we believe that the addition of a checked mode will not bring surprises to the meta-theory. 5.2 Additional Constructs In this section, we show that the application mode is compatible with other constructs, by discussing how to add support for pairs in the language given in Section 3. A similar methodology would apply to other constructs like sum types, data types, if-then-else expressions and so on. The introduction rule for pairs must be in the inference mode with an empty application context. Also, the subtyping rule for pairs is as expected. Γ e1 A Γ e2 B A1 <: B1 A2 <: B2 ` ) ` ) T-Pair S-Pair Γ (e ,e ) (A, B) (A ,A ) <: (B ,B ) ` 1 2 ) 1 2 1 2 33 –– AA new new design design for for type type inference inference of of higher-ranked higher-ranked types types whichwhich gen- gen- eralizeseralizes the the HM HM type type system, system, supports supports a a polymorphic polymorphic letlet asas syntactic syntactic sugar, sugar, andand infers infers higher higher rank rank types. types. We We present present a a syntax-directed syntax-directed specification, specification, an an elaborationelaboration semantics semantics to to System System F, F, some some meta-theory meta-theory in in Coq, Coq, and and an an algo- algo- rithmicrithmic type type system system with with completeness completeness and and soundness soundness proofs. proofs. –– AA System-F-like System-F-like calculus calculusasas a a theoretical theoretical response response to to the the challenge challenge noted noted byby Pierce Pierce and and Turner Turner [ [2929].]. It It shows shows that that the the application application mode mode is is compatible compatible withwith type type applications, applications, which which also also enables enables encoding encoding type type declarations. declarations. We We presentpresent a a type type system system and and meta-theory, meta-theory, including including proofs proofs of of type type safety safety and and uniquenessuniqueness of of typing typing in in Coq. Coq. 2Overview2Overview 2.12.1 Background: Background: Bi-Directional Bi-Directional Type Type Checking Checking TraditionalTraditional type type checking checking rules rules can can be be heavyweight heavyweight on on annotations, annotations, in in the the sense sense thatthat lambda-bound lambda-bound variables variables always always need need explicit explicit annotations. annotations. Bi-directional Bi-directional typetype checking checking [ [2929]] provides provides an an alternative, alternative, which which allows allows types types to to propagate propagate down- down- wardward the the syntax syntax tree. tree. For For example, example, in in the the expression expression ((λλff::IntInt IntInt.. ff)()(λλyy.. !! yy)),, the the type type of of yy isis provided provided by by the the type type annotation annotation on on ff.. This This is is supported supported by by thethe bi-directional bi-directional typing typing rule rule for for applications: applications: ΓΓ ee11 AA BB ΓΓ ee22 AA `` )) !! `` (( APPAPP ΓΓ ee ee BB `` 11 22 )) Specifically,Specifically, if if we we know know that that the the type type of ofee11 isis a a function function from from AA BB,, we we can can check check !! thatthat ee22 hashas type type AA.. Notice Notice that that here here the the type type information information flows flows from from functions functions toto arguments. arguments. OneOne guideline guideline for for designing designing bi-directional bi-directional type type checking checking rules rules [ [1515]istodis-]istodis- tinguishtinguishBi introduction introduction-Directional rules rules from from elimination eliminationType rules. rules. Constructs ConstructsChecking which which correspond correspond toto introduction introduction forms forms are are checkedchecked againstagainst a a given given type, type, while while constructs constructs cor- cor- respondingresponding to to elimination elimination forms forms inferinfer (or(or synthesize) synthesize) their their types. types. For For instance, instance, • Considerunderunder this this design designdesigning principle, principle, rules the the introduction introduction for pairs rule rule for for pairs pairs is is supposed supposed to to be be in in checkedchecked
Load more

Recommended publications
  • Revised5report on the Algorithmic Language Scheme
    Revised5 Report on the Algorithmic Language Scheme RICHARD KELSEY, WILLIAM CLINGER, AND JONATHAN REES (Editors) H. ABELSON R. K. DYBVIG C. T. HAYNES G. J. ROZAS N. I. ADAMS IV D. P. FRIEDMAN E. KOHLBECKER G. L. STEELE JR. D. H. BARTLEY R. HALSTEAD D. OXLEY G. J. SUSSMAN G. BROOKS C. HANSON K. M. PITMAN M. WAND Dedicated to the Memory of Robert Hieb 20 February 1998 CONTENTS Introduction . 2 SUMMARY 1 Overview of Scheme . 3 1.1 Semantics . 3 The report gives a defining description of the program- 1.2 Syntax . 3 ming language Scheme. Scheme is a statically scoped and 1.3 Notation and terminology . 3 properly tail-recursive dialect of the Lisp programming 2 Lexical conventions . 5 language invented by Guy Lewis Steele Jr. and Gerald 2.1 Identifiers . 5 Jay Sussman. It was designed to have an exceptionally 2.2 Whitespace and comments . 5 clear and simple semantics and few different ways to form 2.3 Other notations . 5 expressions. A wide variety of programming paradigms, in- 3 Basic concepts . 6 3.1 Variables, syntactic keywords, and regions . 6 cluding imperative, functional, and message passing styles, 3.2 Disjointness of types . 6 find convenient expression in Scheme. 3.3 External representations . 6 The introduction offers a brief history of the language and 3.4 Storage model . 7 of the report. 3.5 Proper tail recursion . 7 4 Expressions . 8 The first three chapters present the fundamental ideas of 4.1 Primitive expression types . 8 the language and describe the notational conventions used 4.2 Derived expression types .
    [Show full text]
  • CSE341: Programming Languages Spring 2014 Unit 5 Summary Contents Switching from ML to Racket
    CSE341: Programming Languages Spring 2014 Unit 5 Summary Standard Description: This summary covers roughly the same material as class and recitation section. It can help to read about the material in a narrative style and to have the material for an entire unit of the course in a single document, especially when reviewing the material later. Please report errors in these notes, even typos. This summary is not a sufficient substitute for attending class, reading the associated code, etc. Contents Switching from ML to Racket ...................................... 1 Racket vs. Scheme ............................................. 2 Getting Started: Definitions, Functions, Lists (and if) ...................... 2 Syntax and Parentheses .......................................... 5 Dynamic Typing (and cond) ....................................... 6 Local bindings: let, let*, letrec, local define ............................ 7 Top-Level Definitions ............................................ 9 Bindings are Generally Mutable: set! Exists ............................ 9 The Truth about cons ........................................... 11 Cons cells are immutable, but there is mcons ............................. 11 Introduction to Delayed Evaluation and Thunks .......................... 12 Lazy Evaluation with Delay and Force ................................. 13 Streams .................................................... 14 Memoization ................................................. 15 Macros: The Key Points .........................................
    [Show full text]
  • Lecture Notes on Types for Part II of the Computer Science Tripos
    Q Lecture Notes on Types for Part II of the Computer Science Tripos Prof. Andrew M. Pitts University of Cambridge Computer Laboratory c 2012 A. M. Pitts Contents Learning Guide ii 1 Introduction 1 2 ML Polymorphism 7 2.1 AnMLtypesystem............................... 8 2.2 Examplesoftypeinference,byhand . .... 17 2.3 Principaltypeschemes . .. .. .. .. .. .. .. .. 22 2.4 Atypeinferencealgorithm . .. 24 3 Polymorphic Reference Types 31 3.1 Theproblem................................... 31 3.2 Restoringtypesoundness . .. 36 4 Polymorphic Lambda Calculus 39 4.1 Fromtypeschemestopolymorphictypes . .... 39 4.2 ThePLCtypesystem .............................. 42 4.3 PLCtypeinference ............................... 50 4.4 DatatypesinPLC ................................ 52 5 Further Topics 61 5.1 Dependenttypes................................. 61 5.2 Curry-Howardcorrespondence . ... 64 References 70 Exercise Sheet 71 i Learning Guide These notes and slides are designed to accompany eight lectures on type systems for Part II of the Cambridge University Computer Science Tripos. The aim of this course is to show by example how type systems for programming languages can be defined and their properties developed, using techniques that were introduced in the Part IB course on Semantics of Programming Languages. We apply these techniques to a few selected topics centred mainly around the notion of “polymorphism” (or “generics” as it is known in the Java and C# communities). Formal systems and mathematical proof play an important role in this subject—a fact
    [Show full text]
  • Principles of Programming Languages
    David Liu Principles of Programming Languages Lecture Notes for CSC324 (Version 1.2) Department of Computer Science University of Toronto principles of programming languages 3 Many thanks to Alexander Biggs, Peter Chen, Rohan Das, Ozan Erdem, Itai David Hass, Hengwei Guo, Kasra Kyanzadeh, Jasmin Lantos, Jason Mai, Ian Stewart-Binks, Anthony Vandikas, and many anonymous students for their helpful comments and error-spotting in earlier versions of these notes. Contents Prelude: The Lambda Calculus 7 Alonzo Church 8 The Lambda Calculus 8 A Paradigm Shift in You 10 Course Overview 11 Racket: Functional Programming 13 Quick Introduction 13 Function Application 14 Special Forms: and, or, if, cond 20 Lists 23 Higher-Order Functions 28 Lexical Closures 33 Summary 40 6 david liu Macros, Objects, and Backtracking 43 Basic Objects 44 Macros 48 Macros with ellipses 52 Objects revisited 55 Non-deterministic choice 60 Continuations 64 Back to -< 68 Multiple choices 69 Predicates and Backtracking 73 Haskell and Types 79 Quick Introduction 79 Folding and Laziness 85 Lazy to Infinity and Beyond! 87 Types in programming 88 Types in Haskell 91 Type Inference 92 Multi-Parameter Functions and Currying 94 Type Variables and Polymorphism 96 User-Defined Types 100 principles of programming languages 7 Type classes 103 State in a Pure World 111 Haskell Input/Output 117 Purity through types 120 One more abstraction 121 In Which We Say Goodbye 125 Appendix A: Prolog and Logic Programming 127 Getting Started 127 Facts and Simple Queries 128 Rules 132 Recursion 133 Prolog Implementation 137 Tracing Recursion 144 Cuts 147 Prelude: The Lambda Calculus It seems to me that there have been two really clean, consistent models of programming so far: the C model and the Lisp model.
    [Show full text]
  • A Functional Abstraction of Typed Contexts
    Draft 4.2 – July 22nd, 1989 Introduction In most people’s minds, continuations reflect the imperative aspects of control in programming lan- guages because they have been introduced for handling full jumps [Strachey & Wadsworth 74]. They abstract an evaluation context C[ ] up to the final domain of Answers and leave aside all its applicative 1 AFunctionalAbstractionofTypedContexts aspects: when provided as a first-class object ,acontinuationisafunctionk that cannot be composed freely, as in f ◦ k. This report investigates viewing a continuation as a lexical abstraction of a delimited context [C[ ]] by means of a function whose codomain is not the final domain of Answers. Such functions can Olivier Danvy & Andrzej Filinski thus be composed. Our approach continues the one from [Felleisen et al. 87] and [Felleisen 88], where DIKU – Computer Science Department, University of Copenhagen an extended λ-calculus and a new SECD-like machine were defined, and [Felleisen et al. 88] which Universitetsparken 1, 2100 Copenhagen Ø, Denmark presents an algebraic framework where continuations are defined as a sequence of frames and their uucp: [email protected] & [email protected] composition as the dynamic concatenation of these sequences. The present paper describes a more lexical vision of composable continuations, that can be given statically a type. We describe a simple expression language using denotational semantics where the local context is represented with a local continuation κ and an extra parameter γ represents the surroundings, i.e.,theoutercontexts.That Abstract parameter γ maps values to final answers like traditional (non-composable) continuations, and the local continuation κ is defined as a surroundings transformer.
    [Show full text]
  • Lambda-Dropping: Transforming Recursive Equations Into Programs with Block Structure Basic Research in Computer Science
    BRICS Basic Research in Computer Science BRICS RS-97-6 Danvy & Schultz: Lambda Dropping Lambda-Dropping: Transforming Recursive Equations into Programs with Block Structure Olivier Danvy Ulrik P. Schultz BRICS Report Series RS-97-6 ISSN 0909-0878 March 1997 Copyright c 1997, BRICS, Department of Computer Science University of Aarhus. All rights reserved. Reproduction of all or part of this work is permitted for educational or research use on condition that this copyright notice is included in any copy. See back inner page for a list of recent BRICS Report Series publications. Copies may be obtained by contacting: BRICS Department of Computer Science University of Aarhus Ny Munkegade, building 540 DK–8000 Aarhus C Denmark Telephone: +45 8942 3360 Telefax: +45 8942 3255 Internet: [email protected] BRICS publications are in general accessible through the World Wide Web and anonymous FTP through these URLs: http://www.brics.dk ftp://ftp.brics.dk This document in subdirectory RS/97/6/ Lambda-Dropping: Transforming Recursive Equations into Programs with Block Structure ∗ Olivier Danvy and Ulrik P. Schultz BRICS † Department of Computer Science University of Aarhus ‡ March 1997 Abstract Lambda-lifting a functional program transforms it into a set of re- cursive equations. We present the symmetric transformation: lambda- dropping. Lambda-dropping a set of recursive equations restores block structure and lexical scope. For lack of scope, recursive equations must carry around all the parameters that any of their callees might possibly need. Both lambda- lifting and lambda-dropping thus require one to compute a transitive closure over the call graph: • for lambda-lifting: to establish the Def/Use path of each free variable (these free variables are then added as parameters to each of the functions in the call path); ∗Extended version of an article to appear in the 1997 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation (PEPM’97), Amsterdam, The Netherlands, June 1997.
    [Show full text]
  • Monadification of Functional Programs
    Monadification of Functional Programs Martin Erwig a and Deling Ren a aSchool of EECS, Oregon State University, Corvallis, OR 97331, USA Abstract The structure of monadic functional programs allows the integration of many dif- ferent features by just changing the definition of the monad and not the rest of the program, which is a desirable feature from a software engineering and software maintenance point of view. We describe an algorithm for the automatic transforma- tion of a group of functions into such a monadic form. We identify two correctness criteria and argue that the proposed transformation is at least correct in the sense that transformed programs yield the same results as the original programs modulo monad constructors. The translation of a set of functions into monadic form is in most cases only a first step toward an extension of a program by new features. The extended behavior can be realized by choosing an appropriate monad type and by inserting monadic actions into the functions that have been transformed into monadic form. We demonstrate an approach to the integration of monadic actions that is based on the idea of specifying context-dependent rewritings. 1 Introduction Monads can be used to structure and modularize functional programs. The monadic form of a functional program can be exploited for quite different purposes, such as compilation or integration of imperative features. Despite the usefulness of monads, many functional programs are not given in monadic form because writing monadic code is not as convenient as writing other functional code. It would therefore be useful to have tools for converting non-monadic programs into monadic form, a process that we like to call monadification.
    [Show full text]
  • Promoting Functions to Type Families in Haskell
    Edinburgh Research Explorer Promoting Functions to Type Families in Haskell Citation for published version: Eisenberg, RA & Stolarek, J 2014, Promoting Functions to Type Families in Haskell. in Proceedings of the 2014 ACM SIGPLAN Symposium on Haskell. Haskell '14, ACM, New York, NY, USA, pp. 95-106. https://doi.org/10.1145/2633357.2633361 Digital Object Identifier (DOI): 10.1145/2633357.2633361 Link: Link to publication record in Edinburgh Research Explorer Document Version: Peer reviewed version Published In: Proceedings of the 2014 ACM SIGPLAN Symposium on Haskell General rights Copyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s) and / or other copyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associated with these rights. Take down policy The University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorer content complies with UK legislation. If you believe that the public display of this file breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim. Download date: 23. Sep. 2021 Final draft submitted for publication at Haskell Symposium 2014 Promoting Functions to Type Families in Haskell Richard A. Eisenberg Jan Stolarek University of Pennsylvania Politechnika Łodzka´ [email protected] [email protected] Abstract In other words, is type-level programming expressive enough? Haskell, as implemented in the Glasgow Haskell Compiler (GHC), To begin to answer this question, we must define “enough.” In this is enriched with many extensions that support type-level program- paper, we choose to interpret “enough” as meaning that type-level ming, such as promoted datatypes, kind polymorphism, and type programming is at least as expressive as term-level programming.
    [Show full text]
  • Essentials of Programming Languages Third Edition Daniel P
    computer science/programming languages PROGRAMMING LANGUAGES ESSENTIALS OF Essentials of Programming Languages third edition Daniel P. Friedman and Mitchell Wand ESSENTIALS OF This book provides students with a deep, working understanding of the essential concepts of program- ming languages. Most of these essentials relate to the semantics, or meaning, of program elements, and the text uses interpreters (short programs that directly analyze an abstract representation of the THIRD EDITION program text) to express the semantics of many essential language elements in a way that is both clear PROGRAMMING and executable. The approach is both analytical and hands-on. The book provides views of program- ming languages using widely varying levels of abstraction, maintaining a clear connection between the high-level and low-level views. Exercises are a vital part of the text and are scattered throughout; the text explains the key concepts, and the exercises explore alternative designs and other issues. The complete LANGUAGES Scheme code for all the interpreters and analyzers in the book can be found online through The MIT Press website. For this new edition, each chapter has been revised and many new exercises have been added. Significant additions have been made to the text, including completely new chapters on modules and continuation-passing style. Essentials of Programming Languages can be used for both graduate and un- dergraduate courses, and for continuing education courses for programmers. Daniel P. Friedman is Professor of Computer Science at Indiana University and is the author of many books published by The MIT Press, including The Little Schemer (fourth edition, 1995), The Seasoned Schemer (1995), A Little Java, A Few Patterns (1997), each of these coauthored with Matthias Felleisen, and The Reasoned Schemer (2005), coauthored with William E.
    [Show full text]
  • Overview of the Revised7algorithmic Language Scheme
    Overview of the Revised7 Algorithmic Language Scheme ALEX SHINN,JOHN COWAN, AND ARTHUR A. GLECKLER (Editors) STEVEN GANZ ALEXEY RADUL OLIN SHIVERS AARON W. HSU JEFFREY T. READ ALARIC SNELL-PYM BRADLEY LUCIER DAVID RUSH GERALD J. SUSSMAN EMMANUEL MEDERNACH BENJAMIN L. RUSSEL RICHARD KELSEY,WILLIAM CLINGER, AND JONATHAN REES (Editors, Revised5 Report on the Algorithmic Language Scheme) MICHAEL SPERBER, R. KENT DYBVIG,MATTHEW FLATT, AND ANTON VAN STRAATEN (Editors, Revised6 Report on the Algorithmic Language Scheme) Dedicated to the memory of John McCarthy and Daniel Weinreb *** EDITOR'S DRAFT *** April 15, 2013 2 Revised7 Scheme OVERVIEW OF SCHEME the procedure needs the result of the evaluation or not. C, C#, Common Lisp, Python, Ruby, and Smalltalk are This paper gives an overview of the small language of other languages that always evaluate argument expressions R7RS. The purpose of this overview is to explain enough before invoking a procedure. This is distinct from the lazy- about the basic concepts of the language to facilitate un- evaluation semantics of Haskell, or the call-by-name se- derstanding of the R7RS report, which is organized as a mantics of Algol 60, where an argument expression is not reference manual. Consequently, this overview is not a evaluated unless its value is needed by the procedure. complete introduction to the language, nor is it precise in all respects or normative in any way. Scheme's model of arithmetic provides a rich set of numer- ical types and operations on them. Furthermore, it distin- Following Algol, Scheme is a statically scoped program- guishes exact and inexact numbers: Essentially, an exact ming language.
    [Show full text]
  • MIT/GNU Scheme Reference Manual
    MIT/GNU Scheme Reference Manual for release 11.2 2020-06-16 by Chris Hanson the MIT Scheme Team and a cast of thousands This manual documents MIT/GNU Scheme 11.2. Copyright c 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Massachusetts Institute of Technology Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License." i Short Contents Acknowledgements :::::::::::::::::::::::::::::::::::::::: 1 1 Overview :::::::::::::::::::::::::::::::::::::::::::: 3 2 Special Forms:::::::::::::::::::::::::::::::::::::::: 15 3 Equivalence Predicates :::::::::::::::::::::::::::::::: 57 4 Numbers:::::::::::::::::::::::::::::::::::::::::::: 63 5 Characters :::::::::::::::::::::::::::::::::::::::::: 99 6 Strings :::::::::::::::::::::::::::::::::::::::::::: 107 7 Lists :::::::::::::::::::::::::::::::::::::::::::::: 129 8 Vectors :::::::::::::::::::::::::::::::::::::::::::: 147 9 Bit Strings ::::::::::::::::::::::::::::::::::::::::: 151 10 Miscellaneous Datatypes :::::::::::::::::::::::::::::: 155 11 Associations :::::::::::::::::::::::::::::::::::::::: 169 12 Procedures :::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Principles of Programming Languages
    David Liu Principles of Programming Languages Lecture Notes for CSC324 (Version 1.1) Department of Computer Science University of Toronto principles of programming languages 3 Many thanks to Peter Chen, Rohan Das, Ozan Erdem, Itai David Hass, Hengwei Guo, and many anonymous students for pointing out errors in earlier versions of these notes. Contents Prelude: The Lambda Calculus 9 Alonzo Church 9 The Lambda Calculus 10 A Paradigm Shift in You 11 Course Overview 11 Racket: Functional Programming 13 Quick Introduction 13 Function Application 14 Special Forms: and, or, if, cond 17 Lists 20 Higher-Order Functions 25 Scope and Closures 28 Basic Objects 37 Macros 38 6 david liu Macros with ellipses 42 Summary 45 Haskell: Types 47 Quick Introduction 47 Folding and Laziness 52 Lazy to Infinity and Beyond! 54 Static and Dynamic Typing 55 Types in Haskell 57 Type Inference 59 Multi-Parameter Functions and Currying 60 Type Variables and Polymorphism 62 User-Defined Types 66 Typeclasses 69 State in a Pure World 77 Haskell Input/Output 83 Purity through types 85 Types as abstractions 85 Prolog: Logic Programming 87 Getting Started 87 principles of programming languages 7 Facts and Simple Queries 88 Rules 91 Recursion 92 Prolog Implementation 96 Tracing Recursion 103 Cuts 106 Prelude: The Lambda Calculus It was in the 1930s, years before the invention of the first electronic com- puting devices, that a young mathematician named Alan Turing created Alan Turing, 1912-1954 modern computer science as we know it. Incredibly, this came about almost by accident; he had been trying to solve a problem from math- The Entscheidungsproblem (“decision ematical logic! To answer this question, Turing developed an abstract problem”) asked whether an algorithm could decide if a logical statement is model of mechanical, procedural computation: a machine that could provable from a given set of axioms.
    [Show full text]