DOCSLIB.ORG

Lambda-Calculus Types and Models

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Lambda-Calculus Types and Models Jean-Louis Krivine LAMBDA-CALCULUS TYPES AND MODELS Translated from french by René Cori To my daughter Contents Introduction5 1 Substitution and beta-conversion7 Simple substitution ..............................8 Alpha-equivalence and substitution ..................... 12 Beta-conversion ................................ 18 Eta-conversion ................................. 24 2 Representation of recursive functions 29 Head normal forms .............................. 29 Representable functions ............................ 31 Fixed point combinators ........................... 34 The second fixed point theorem ....................... 37 3 Intersection type systems 41 System D­ ................................... 41 System D .................................... 50 Typings for normal terms ........................... 54 4 Normalization and standardization 61 Typings for normalizable terms ........................ 61 Strong normalization ............................. 68 ¯I-reduction ................................. 70 The ¸I-calculus ................................ 72 ¯´-reduction ................................. 74 The finite developments theorem ....................... 77 The standardization theorem ......................... 81 5 The Böhm theorem 87 3 4 CONTENTS 6 Combinatory logic 95 Combinatory algebras ............................. 95 Extensionality axioms ............................. 98 Curry’s equations ............................... 101 Translation of ¸-calculus ........................... 105 7 Models of lambda-calculus 111 Functional models ............................... 111 Spaces of continuous increasing functions .................. 116 Spaces of initial segments ........................... 117 Applications .................................. 125 Retractions ................................... 130 Qualitative domains and stable functions .................. 134 8 System F 145 Definition of system F types ......................... 145 Typing rules for system F ........................... 146 The strong normalization theorem ...................... 150 Data types in system F ............................ 153 Positive second order quantifiers ....................... 159 9 Second order functional arithmetic 165 Second order predicate calculus ....................... 165 System FA2 ................................... 172 Realizability .................................. 179 Data types ................................... 182 Programming in FA2 .............................. 185 10 Representable functions in system F 193 Gödel’s -translation ............................. 196 : Undecidability of strong normalization .................... 199 Bibliography 203 INTRODUCTION The lambda-calculus was invented in the early 1930’s, by A. Church, and has been considerably developed since then. This book is an introduction to some aspects of the theory today : pure lambda-calculus, combinatory logic, seman- tics (models) of lambda-calculus, type systems. All these areas will be dealt with, only partially, of course, but in such a way, I think, as to illustrate their interdependence, and the essential unity of the subject. No specific knowledge is required from the reader, but some familiarity with mathematical logic is expected ; in chapter 2, the concept of recursive function is used ; parts of chapters 6 and 7, as well as chapter 9, involve elementary topics in predicate calculus and model theory. For about fifteen years, the typed lambda-calculus has provoked a great deal of interest, because of its close connections with programming languages, and of the link that it establishes between the concept of program and that of in- tuitionistic proof : this is known as the “ Curry-Howard correspondence ”. Af- ter the first type system, which was Curry’s, many others appeared : for ex- ample, de Bruijn’s Automath system, Girard’s system F , Martin-Löf’s theory of intuitionistic types, Coquand-Huet’s theory of constructions, Constable’s Nuprl system... This book will first introduce Coppo and Dezani’s intersection type system. Here it will be called “ system D­ ”, and will be used to prove some fundamen- tal theorems of pure lambda-calculus. It is also connected with denotational semantics : in Engeler and Scott’s models, the interpretation of a term is essen- tially the set of its types. Next, Girard’s system F of second order types will be considered, together with a simple extension, denoted by FA2 (second order functional arithmetic). These types have a very transparent logical structure, and a great expressive power. They allow the Curry-Howard correspondence to be seen clearly, as well as the possibilities, and the difficulties, of using these systems as programming languages. A programming language is a tool for writing a program in machine lan- guage (which is called the object code), in such a way as to keep control, as far as possible, on what will be done during its execution. To do so, the primi- 5 6 Lambda-calculus, types and models tive method would be to write directly, in one column, machine language, and, alongside, comments indicating what the corresponding instructions are sup- posed to do. The result of this is called a “ source program ”. Here, the aim of the “ compilation ”, which transforms the source program into an object code, will be to get rid of the comments. Such a language is said to be primitive, or “ low level ”, because the com- puter does not deal with the comments at all ; they are entirely intended for the programmer. In a higher level language, part of these comments would be checked by the computer, and the remainder left for the programmer ; the “ mechanized ” part of the comments is then called a “ typing ”. A language is considered high level if the type system is rich. In such a case, the aim of the compilation would be, first of all, to check the types, then, as before, to get rid of them, along with the rest of the comments. The typed lambda-calculus can be used as a mathematical model for this situation ; the role of the machine language is played by the pure lambda- calculus. The type systems that are then considered are, in general, much more rich than those of the actual programming languages ; in fact, the types could almost be complete specifications of the programs, while the type checking (compilation) would be a “ program proof ”. These remarks are sufficient to ex- plain the great interest there would be in constructing a programming language based on typed lambda-calculus ; but the problems, theoretical and practical, of such an enterprise are far from being fully resolved. This book is the product of a D.E.A. (postgraduate) course at the University of Paris 7. I would like to thank the students and researchers of the “ Equipe de Logique ” of Paris 7, for their comments and their contributions to the early versions of the manuscript, in particular Marouan Ajlani, René Cori, Jean-Yves Girard and Michel Parigot. Finally, it gives me much pleasure to dedicate this book to my daughter Sonia. Paris, 1990 I want to thank also Darij Grinberg and Robert Solovay, who have corrected errors in the proofs of corollary 1.3 and theorem 7.16. Paris, 2011 Chapter 1 Substitution and beta-conversion The terms of the ¸-calculus (also called ¸-terms) are finite sequences formed with the following symbols : variables x, y,... (the set of variables is assumed to be countable), left and right parenthesis, and the letter ¸. They are obtained by applying, a finite number of times, the following rules : any variable x is a ¸-term ; ² whenever t and u are ¸-terms, then so is (t)u ; ² whenever t is a ¸-term and x is a variable, then ¸x t is a ¸-term. ² The set of all terms of the ¸-calculus will be denoted by L. The term (t)u should be thought of as “ t applied to u ” ; it will also be denoted by tu if there is no ambiguity ; the term (...(((t)u1)u2)...)uk will also be written (t)u1u2 ...uk or tu1u2 ...uk . Thus, for example, (t)uv,(tu)v and tuv denote the same term. By convention, when k 0, (t)u u ...u will denote the term t. Æ 1 2 k The free occurrences of a variable x in a term t are defined, by induction, as follows : if t is the variable x, then the occurrence of x in t is free ; if t (u)v, then the free occurrences of x in t are those of x in u and Æ v ; if t ¸y u, the free occurrences of x in t are those of x in u, except Æ if x y ; in that case, no occurrence of x in t is free. Æ A free variable in t is a variable which has at least one free occurrence in t. A term which has no free variable is called a closed term. A bound variable in t is a variable which occurs in t just after the symbol ¸. 7 8 Lambda-calculus, types and models 1. Simple substitution Let t,t1,...,tk be terms and x1,...,xk distinct variables ; we define the term t t /x ,...,t /x as the result of the replacement of every free occurrence of Ç 1 1 k k È x in t by t (1 i k). The definition is by induction on t, as follows : i i · · if t x (1 i k), then t t /x ,...,t /x t ; Æ i · · Ç 1 1 k k ÈÆ i if t is a variable x ,...,x , then t t /x ,...,t /x t ; 6Æ 1 k Ç 1 1 k k ÈÆ if t (u)v, then Æ t t /x ,...,t /x (u t /x ,...,t /x )v t /x ,...,t /x ; Ç 1 1 k k ÈÆ Ç 1 1 k k È Ç 1 1 k k È if t ¸x u (1 i k), then Æ i · · t t1/x1,...,tk /xk ¸xi u t1/x1,...,ti 1/xi 1,ti 1/xi 1,...,tk /xk ; Ç ÈÆ Ç ¡ ¡ Å Å È if t ¸x u, with x x ,...,x , then Æ 6Æ 1 k t t /x ,...,t /x ¸x u t /x ,...,t /x . Ç 1 1 k k ÈÆ Ç 1 1 k k È Such a substitution will be called a simple one, in order to distinguish it from the substitution defined further on, which needs a change of bound variables. Simple substitution corresponds, in computer science, to the notion of macro- instruction. It is also called substitution with capture of variables. With the notation t t /x ,...,t /x , it is understood that x ,...,x are distinct Ç 1 1 k k È 1 k variables. Moreover, their order does not matter ; in other words : t t /x ,...,t /x t t /x ,...,t /x for any permutation σ of {1,...,k}.
Load more

Recommended publications
  • Lecture Notes on the Lambda Calculus 2.4 Introduction to Β-Reduction
    2.2 Free and bound variables, α-equivalence. 8 2.3 Substitution ............................. 10 Lecture Notes on the Lambda Calculus 2.4 Introduction to β-reduction..................... 12 2.5 Formal definitions of β-reduction and β-equivalence . 13 Peter Selinger 3 Programming in the untyped lambda calculus 14 3.1 Booleans .............................. 14 Department of Mathematics and Statistics 3.2 Naturalnumbers........................... 15 Dalhousie University, Halifax, Canada 3.3 Fixedpointsandrecursivefunctions . 17 3.4 Other data types: pairs, tuples, lists, trees, etc. ....... 20 Abstract This is a set of lecture notes that developed out of courses on the lambda 4 The Church-Rosser Theorem 22 calculus that I taught at the University of Ottawa in 2001 and at Dalhousie 4.1 Extensionality, η-equivalence, and η-reduction. 22 University in 2007 and 2013. Topics covered in these notes include the un- typed lambda calculus, the Church-Rosser theorem, combinatory algebras, 4.2 Statement of the Church-Rosser Theorem, and some consequences 23 the simply-typed lambda calculus, the Curry-Howard isomorphism, weak 4.3 Preliminary remarks on the proof of the Church-Rosser Theorem . 25 and strong normalization, polymorphism, type inference, denotational se- mantics, complete partial orders, and the language PCF. 4.4 ProofoftheChurch-RosserTheorem. 27 4.5 Exercises .............................. 32 Contents 5 Combinatory algebras 34 5.1 Applicativestructures. 34 1 Introduction 1 5.2 Combinatorycompleteness . 35 1.1 Extensionalvs. intensionalviewoffunctions . ... 1 5.3 Combinatoryalgebras. 37 1.2 Thelambdacalculus ........................ 2 5.4 The failure of soundnessforcombinatoryalgebras . .... 38 1.3 Untypedvs.typedlambda-calculi . 3 5.5 Lambdaalgebras .......................... 40 1.4 Lambdacalculusandcomputability . 4 5.6 Extensionalcombinatoryalgebras . 44 1.5 Connectionstocomputerscience .
    [Show full text]
  • A Call-By-Need Lambda Calculus
    A CallByNeed Lamb da Calculus Zena M Ariola Matthias Fel leisen Computer Information Science Department Department of Computer Science University of Oregon Rice University Eugene Oregon Houston Texas John Maraist and Martin Odersky Philip Wad ler Institut fur Programmstrukturen Department of Computing Science Universitat Karlsruhe UniversityofGlasgow Karlsruhe Germany Glasgow Scotland Abstract arguments value when it is rst evaluated More pre cisely lazy languages only reduce an argument if the The mismatchbetween the op erational semantics of the value of the corresp onding formal parameter is needed lamb da calculus and the actual b ehavior of implemen for the evaluation of the pro cedure b o dy Moreover af tations is a ma jor obstacle for compiler writers They ter reducing the argument the evaluator will remember cannot explain the b ehavior of their evaluator in terms the resulting value for future references to that formal of source level syntax and they cannot easily com parameter This technique of evaluating pro cedure pa pare distinct implementations of dierent lazy strate rameters is called cal lbyneed or lazy evaluation gies In this pap er we derive an equational characteri A simple observation justies callbyneed the re zation of callbyneed and prove it correct with resp ect sult of reducing an expression if any is indistinguish to the original lamb da calculus The theory is a strictly able from the expression itself in all p ossible contexts smaller theory than the lamb da calculus Immediate Some implementations attempt
    [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 2016 A. M. Pitts Contents Learning Guide i 1 Introduction 1 2 ML Polymorphism 6 2.1 Mini-ML type system . 6 2.2 Examples of type inference, by hand . 14 2.3 Principal type schemes . 16 2.4 A type inference algorithm . 18 3 Polymorphic Reference Types 25 3.1 The problem . 25 3.2 Restoring type soundness . 30 4 Polymorphic Lambda Calculus 33 4.1 From type schemes to polymorphic types . 33 4.2 The Polymorphic Lambda Calculus (PLC) type system . 37 4.3 PLC type inference . 42 4.4 Datatypes in PLC . 43 4.5 Existential types . 50 5 Dependent Types 53 5.1 Dependent functions . 53 5.2 Pure Type Systems . 57 5.3 System Fw .............................................. 63 6 Propositions as Types 67 6.1 Intuitionistic logics . 67 6.2 Curry-Howard correspondence . 69 6.3 Calculus of Constructions, lC ................................... 73 6.4 Inductive types . 76 7 Further Topics 81 References 84 Learning Guide These notes and slides are designed to accompany 12 lectures on type systems for Part II of the Cambridge University Computer Science Tripos. The course builds on the techniques intro- duced in the Part IB course on Semantics of Programming Languages for specifying type systems for programming languages and reasoning about their properties. The emphasis here is on type systems for functional languages and their connection to constructive logic. We pay par- ticular attention to the notion of parametric polymorphism (also known as generics), both because it has proven useful in practice and because its theory is quite subtle.
    [Show full text]
  • NU-Prolog Reference Manual
    NU-Prolog Reference Manual Version 1.5.24 edited by James A. Thom & Justin Zobel Technical Report 86/10 Machine Intelligence Project Department of Computer Science University of Melbourne (Revised November 1990) Copyright 1986, 1987, 1988, Machine Intelligence Project, The University of Melbourne. All rights reserved. The Technical Report edition of this publication is given away free subject to the condition that it shall not, by the way of trade or otherwise, be lent, resold, hired out, or otherwise circulated, without the prior consent of the Machine Intelligence Project at the University of Melbourne, in any form or cover other than that in which it is published and without a similar condition including this condition being imposed on the subsequent user. The Machine Intelligence Project makes no representations or warranties with respect to the contents of this document and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, the Machine Intelligence Project reserves the right to revise this document and to make changes from time to time in its content without being obligated to notify any person or body of such revisions or changes. The usual codicil that no part of this publication may be reproduced, stored in a retrieval system, used for wrapping fish, or transmitted, in any form or by any means, electronic, mechanical, photocopying, paper dart, recording, or otherwise, without someone's express permission, is not imposed. Enquiries relating to the acquisition of NU-Prolog should be made to NU-Prolog Distribution Manager Machine Intelligence Project Department of Computer Science The University of Melbourne Parkville, Victoria 3052 Australia Telephone: (03) 344 5229.
    [Show full text]
  • Category Theory and Lambda Calculus
    Category Theory and Lambda Calculus Mario Román García Trabajo Fin de Grado Doble Grado en Ingeniería Informática y Matemáticas Tutores Pedro A. García-Sánchez Manuel Bullejos Lorenzo Facultad de Ciencias E.T.S. Ingenierías Informática y de Telecomunicación Granada, a 18 de junio de 2018 Contents 1 Lambda calculus 13 1.1 Untyped λ-calculus . 13 1.1.1 Untyped λ-calculus . 14 1.1.2 Free and bound variables, substitution . 14 1.1.3 Alpha equivalence . 16 1.1.4 Beta reduction . 16 1.1.5 Eta reduction . 17 1.1.6 Confluence . 17 1.1.7 The Church-Rosser theorem . 18 1.1.8 Normalization . 20 1.1.9 Standardization and evaluation strategies . 21 1.1.10 SKI combinators . 22 1.1.11 Turing completeness . 24 1.2 Simply typed λ-calculus . 24 1.2.1 Simple types . 25 1.2.2 Typing rules for simply typed λ-calculus . 25 1.2.3 Curry-style types . 26 1.2.4 Unification and type inference . 27 1.2.5 Subject reduction and normalization . 29 1.3 The Curry-Howard correspondence . 31 1.3.1 Extending the simply typed λ-calculus . 31 1.3.2 Natural deduction . 32 1.3.3 Propositions as types . 34 1.4 Other type systems . 35 1.4.1 λ-cube..................................... 35 2 Mikrokosmos 38 2.1 Implementation of λ-expressions . 38 2.1.1 The Haskell programming language . 38 2.1.2 De Bruijn indexes . 40 2.1.3 Substitution . 41 2.1.4 De Bruijn-terms and λ-terms . 42 2.1.5 Evaluation .
    [Show full text]
  • Variable-Arity Generic Interfaces
    Variable-Arity Generic Interfaces T. Stephen Strickland, Richard Cobbe, and Matthias Felleisen College of Computer and Information Science Northeastern University Boston, MA 02115 [email protected] Abstract. Many programming languages provide variable-arity func- tions. Such functions consume a fixed number of required arguments plus an unspecified number of \rest arguments." The C++ standardiza- tion committee has recently lifted this flexibility from terms to types with the adoption of a proposal for variable-arity templates. In this paper we propose an extension of Java with variable-arity interfaces. We present some programming examples that can benefit from variable-arity generic interfaces in Java; a type-safe model of such a language; and a reduction to the core language. 1 Introduction In April of 2007 the C++ standardization committee adopted Gregor and J¨arvi's proposal [1] for variable-length type arguments in class templates, which pre- sented the idea and its implementation but did not include a formal model or soundness proof. As a result, the relevant constructs will appear in the upcom- ing C++09 draft. Demand for this feature is not limited to C++, however. David Hall submitted a request for variable-arity type parameters for classes to Sun in 2005 [2]. For an illustration of the idea, consider the remarks on first-class functions in Scala [3] from the language's homepage. There it says that \every function is a value. Scala provides a lightweight syntax for defining anonymous functions, it supports higher-order functions, it allows functions to be nested, and supports currying." To achieve this integration of objects and closures, Scala's standard library pre-defines ten interfaces (traits) for function types, which we show here in Java-like syntax: interface Function0<Result> { Result apply(); } interface Function1<Arg1,Result> { Result apply(Arg1 a1); } interface Function2<Arg1,Arg2,Result> { Result apply(Arg1 a1, Arg2 a2); } ..
    [Show full text]
  • Small Hitting-Sets for Tiny Arithmetic Circuits Or: How to Turn Bad Designs Into Good
    Electronic Colloquium on Computational Complexity, Report No. 35 (2017) Small hitting-sets for tiny arithmetic circuits or: How to turn bad designs into good Manindra Agrawal ∗ Michael Forbes† Sumanta Ghosh ‡ Nitin Saxena § Abstract Research in the last decade has shown that to prove lower bounds or to derandomize polynomial identity testing (PIT) for general arithmetic circuits it suffices to solve these questions for restricted circuits. In this work, we study the smallest possibly restricted class of circuits, in particular depth-4 circuits, which would yield such results for general circuits (that is, the complexity class VP). We show that if we can design poly(s)-time hitting-sets for Σ ∧a ΣΠO(log s) circuits of size s, where a = ω(1) is arbitrarily small and the number of variables, or arity n, is O(log s), then we can derandomize blackbox PIT for general circuits in quasipolynomial time. Further, this establishes that either E6⊆#P/poly or that VP6=VNP. We call the former model tiny diagonal depth-4. Note that these are merely polynomials with arity O(log s) and degree ω(log s). In fact, we show that one only needs a poly(s)-time hitting-set against individual-degree a′ = ω(1) polynomials that are computable by a size-s arity-(log s) ΣΠΣ circuit (note: Π fanin may be s). Alternatively, we claim that, to understand VP one only needs to find hitting-sets, for depth-3, that have a small parameterized complexity. Another tiny family of interest is when we restrict the arity n = ω(1) to be arbitrarily small.
    [Show full text]
  • Making a Faster Curry with Extensional Types
    Making a Faster Curry with Extensional Types Paul Downen Simon Peyton Jones Zachary Sullivan Microsoft Research Zena M. Ariola Cambridge, UK University of Oregon [email protected] Eugene, Oregon, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Curried functions apparently take one argument at a time, Consider these two function definitions: which is slow. So optimizing compilers for higher-order lan- guages invariably have some mechanism for working around f1 = λx: let z = h x x in λy:e y z currying by passing several arguments at once, as many as f = λx:λy: let z = h x x in e y z the function can handle, which is known as its arity. But 2 such mechanisms are often ad-hoc, and do not work at all in higher-order functions. We show how extensional, call- It is highly desirable for an optimizing compiler to η ex- by-name functions have the correct behavior for directly pand f1 into f2. The function f1 takes only a single argu- expressing the arity of curried functions. And these exten- ment before returning a heap-allocated function closure; sional functions can stand side-by-side with functions native then that closure must subsequently be called by passing the to practical programming languages, which do not use call- second argument. In contrast, f2 can take both arguments by-name evaluation. Integrating call-by-name with other at once, without constructing an intermediate closure, and evaluation strategies in the same intermediate language ex- this can make a huge difference to run-time performance in presses the arity of a function in its type and gives a princi- practice [Marlow and Peyton Jones 2004].
    [Show full text]
  • 1 Simply-Typed Lambda Calculus
    CS 4110 – Programming Languages and Logics Lecture #18: Simply Typed λ-calculus A type is a collection of computational entities that share some common property. For example, the type int represents all expressions that evaluate to an integer, and the type int ! int represents all functions from integers to integers. The Pascal subrange type [1..100] represents all integers between 1 and 100. You can see types as a static approximation of the dynamic behaviors of terms and programs. Type systems are a lightweight formal method for reasoning about behavior of a program. Uses of type systems include: naming and organizing useful concepts; providing information (to the compiler or programmer) about data manipulated by a program; and ensuring that the run-time behavior of programs meet certain criteria. In this lecture, we’ll consider a type system for the lambda calculus that ensures that values are used correctly; for example, that a program never tries to add an integer to a function. The resulting language (lambda calculus plus the type system) is called the simply-typed lambda calculus (STLC). 1 Simply-typed lambda calculus The syntax of the simply-typed lambda calculus is similar to that of untyped lambda calculus, with the exception of abstractions. Since abstractions define functions tht take an argument, in the simply-typed lambda calculus, we explicitly state what the type of the argument is. That is, in an abstraction λx : τ: e, the τ is the expected type of the argument. The syntax of the simply-typed lambda calculus is as follows. It includes integer literals n, addition e1 + e2, and the unit value ¹º.
    [Show full text]
  • The Lambda Calculus Bharat Jayaraman Department of Computer Science and Engineering University at Buffalo (SUNY) January 2010
    The Lambda Calculus Bharat Jayaraman Department of Computer Science and Engineering University at Buffalo (SUNY) January 2010 The lambda-calculus is of fundamental importance in the study of programming languages. It was founded by Alonzo Church in the 1930s well before programming languages or even electronic computers were invented. Church's thesis is that the computable functions are precisely those that are definable in the lambda-calculus. This is quite amazing, since the entire syntax of the lambda-calculus can be defined in just one line: T ::= V j λV:T j (TT ) The syntactic category T defines the set of well-formed expressions of the lambda-calculus, also referred to as lambda-terms. The syntactic category V stands for a variable; λV:T is called an abstraction, and (TT ) is called an application. We will examine these terms in more detail a little later, but, at the outset, it is remarkable that the lambda-calculus is capable of defining recursive functions even though there is no provision for writing recursive definitions. Indeed, there is no provision for writing named procedures or functions as we know them in conventional languages. Also absent are other familiar programming constructs such as control and data structures. We will therefore examine how the lambda-calculus can encode such constructs, and thereby gain some insight into the power of this little language. In the field of programming languages, John McCarthy was probably the first to rec- ognize the importance of the lambda-calculus, which inspired him in the 1950s to develop the Lisp programming language.
    [Show full text]
  • Brief Notes on the Category Theoretic Semantics of Simply Typed Lambda Calculus
    University of Cambridge 2017 MPhil ACS / CST Part III Category Theory and Logic (L108) Brief Notes on the Category Theoretic Semantics of Simply Typed Lambda Calculus Andrew Pitts Notation: comma-separated snoc lists When presenting logical systems and type theories, it is common to write finite lists of things using a comma to indicate the cons-operation and with the head of the list at the right. With this convention there is no common notation for the empty list; we will use the symbol “”. Thus ML-style list notation nil a :: nil b :: a :: nil etc becomes , a , a, b etc For non-empty lists, it is very common to leave the initial part “,” of the above notation implicit, for example just writing a, b instead of , a, b. Write X∗ for the set of such finite lists with elements from the set X. 1 Syntax of the simply typed l-calculus Fix a countably infinite set V whose elements are called variables and are typically written x, y, z,... The simple types (with product types) A over a set Gnd of ground types are given by the following grammar, where G ranges over Gnd: A ::= G j unit j A x A j A -> A Write ST(Gnd) for the set of simple types over Gnd. The syntax trees t of the simply typed l-calculus (STLC) over Gnd with constants drawn from a set Con are given by the following grammar, where c ranges over Con, x over V and A over ST(Gnd): t ::= c j x j () j (t , t) j fst t j snd t j lx : A.
    [Show full text]
  • Simply-Typed Lambda Calculus Static Semantics of F1 •Syntax: Notice :Τ • the Typing Judgment Λ Τ Terms E ::= X | X
    Homework Five Is Alive Simply-Typed • Ocaml now installed on dept Lambda Calculus linux/solaris machines in /usr/cs (e.g., /usr/cs/bin/ocamlc) • There will be no Number Six #1 #2 Back to School Lecture Schedule •Thu Oct 13 –Today • What is operational semantics? When would • Tue Oct 14 – Monomorphic Type Systems you use contextual (small-step) semantics? • Thu Oct 12 – Exceptions, Continuations, Rec Types • What is denotational semantics? • Tue Oct 17 – Subtyping – Homework 5 Due • What is axiomatic semantics? What is a •Thu Oct 19 –No Class verification condition? •Tue Oct 24 –2nd Order Types | Dependent Types – Double Lecture – Food? – Project Status Update Due •Thu Oct 26 –No Class • Tue Oct 31 – Theorem Proving, Proof Checking #3 #4 Today’s (Short?) Cunning Plan Why Typed Languages? • Type System Overview • Development • First-Order Type Systems – Type checking catches early many mistakes •Typing Rules – Reduced debugging time •Typing Derivations – Typed signatures are a powerful basis for design – Typed signatures enable separate compilation • Type Safety • Maintenance – Types act as checked specifications – Types can enforce abstraction •Execution – Static checking reduces the need for dynamic checking – Safe languages are easier to analyze statically • the compiler can generate better code #5 #6 1 Why Not Typed Languages? Safe Languages • There are typed languages that are not safe • Static type checking imposes constraints on the (“weakly typed languages”) programmer – Some valid programs might be rejected • All safe languages use types (static or dynamic) – But often they can be made well-typed easily Typed Untyped – Hard to step outside the language (e.g. OO programming Static Dynamic in a non-OO language, but cf.
    [Show full text]