DOCSLIB.ORG

Programming Languages and Lambda Calculi (Utah CS7520 Version)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Programming Languages and Lambda Calculi (Utah CS7520 Version) Programming Languages and Lambda Calculi (Utah CS7520 Version) Matthias Felleisen Matthew Flatt Draft: March 8, 2006 Copyright c 1989, 2003 Felleisen, Flatt 2 Contents I Models of Languages 7 Chapter 1: Computing with Text 9 1.1 Defining Sets ...................................... 9 1.2 Relations ........................................ 10 1.3 Relations as Evaluation ................................ 11 1.4 Directed Evaluation .................................. 11 1.5 Evaluation in Context ................................. 12 1.6 Evaluation Function .................................. 13 1.7 Notation Summary ................................... 13 Chapter 2: Structural Induction 15 2.1 Detecting the Need for Structural Induction ..................... 15 2.2 Definitions with Ellipses ................................ 17 2.3 Induction on Proof Trees ................................ 17 2.4 Multiple Structures ................................... 18 2.5 More Definitions and More Proofs .......................... 19 Chapter 3: Consistency of Evaluation 21 Chapter 4: The λ-Calculus 25 4.1 Functions in the λ-Calculus .............................. 25 4.2 λ-Calculus Grammar and Reductions ......................... 26 4.3 Encoding Booleans ................................... 28 4.4 Encoding Pairs ..................................... 29 4.5 Encoding Numbers ................................... 30 4.6 Recursion ........................................ 31 4.6.1 Recursion via Self-Application ........................ 32 4.6.2 Lifting Out Self-Application .......................... 33 4.6.3 Fixed Points and the Y Combinator ..................... 34 4.7 Facts About the λ-Calculus .............................. 35 4.8 History ......................................... 37 II Models of Realistic Languages 39 Chapter 5: ISWIM 41 5.1 ISWIM Expressions .................................. 41 5.2 ISWIM Reductions ................................... 42 5.3 The Yv Combinator .................................. 43 5.4 Evaluation ........................................ 45 5.5 Consistency ....................................... 45 3 4 5.6 Observational Equivalence ............................... 49 5.7 History ......................................... 51 Chapter 6: Standard Reduction 53 6.1 Standard Reductions .................................. 53 6.2 Proving the Standard Reduction Theorem ...................... 56 6.3 Observational Equivalence ............................... 63 6.4 Uniform Evaluation .................................. 66 Chapter 7: Machines 69 7.1 CC Machine ....................................... 69 7.2 SCC Machine ...................................... 72 7.3 CK Machine ....................................... 75 7.4 CEK Machine ...................................... 77 7.5 Machine Summary ................................... 81 Chapter 8: SECD, Tail Calls, and Safe for Space 83 8.1 SECD machine ..................................... 83 8.2 Context Space ..................................... 84 8.3 Environment Space ................................... 86 8.4 History ......................................... 87 Chapter 9: Continuations 89 9.1 Saving Contexts .................................... 89 9.2 Revised Texual Machine ................................ 90 9.3 Revised CEK Machine ................................. 91 Chapter 10: Errors and Exceptions 93 10.1 Errors .......................................... 93 10.1.1 Calculating with Error ISWIM ........................ 93 10.1.2 Consistency for Error ISWIM ......................... 95 10.1.3 Standard Reduction for Error ISWIM .................... 98 10.1.4 Relating ISWIM and Error ISWIM ...................... 99 10.2 Exceptions and Handlers ................................ 102 10.2.1 Calculating with Handler ISWIM ....................... 103 10.2.2 Consistency for Handler ISWIM ....................... 104 10.2.3 Standard Reduction for Handler ISWIM ................... 105 10.2.4 Observational Equivalence of Handler ISWIM ................ 106 10.3 Machines for Exceptions ................................ 107 10.3.1 The Handler-Extended CC Machine ..................... 107 10.3.2 The CCH Machine ............................... 108 Chapter 11: Imperative Assignment 111 11.1 Evaluation with State ................................. 111 11.2 Garbage Collection ................................... 114 11.3 CEKS Machine ..................................... 116 11.4 Implementing Garbage Collection ........................... 117 11.5 History ......................................... 118 5 III Models of Typed Languages 119 Chapter 12: Types 121 12.1 Numbers and Booleans ................................. 122 12.2 Soundness ........................................ 124 Chapter 13: Simply Typed ISWIM 127 13.1 Function Types ..................................... 127 13.2 Type Rules for Simply Typed ISWIM ........................ 128 13.3 Soundness ........................................ 130 13.4 Normalization ...................................... 131 Chapter 14: Variations on Simply Typed ISWIM 135 14.1 Conditionals ....................................... 135 14.2 Pairs ........................................... 136 14.3 Variants ......................................... 137 14.4 Recursion ........................................ 138 Chapter 15: Polymorphism 141 15.1 Polymorphic ISWIM .................................. 141 Chapter 16: Type Inference 145 16.1 Type-Inferred ISWIM ................................. 145 16.1.1 Constraint Generation ............................. 146 16.1.2 Unification ................................... 147 16.2 Inferring Polymorphism ................................ 149 Chapter 17: Recursive Types 151 17.1 Fixed-points of Type Abstractions .......................... 151 17.2 Equality Between Recursive Types .......................... 152 17.3 Isomorphisms Between Recursive Types ....................... 153 17.4 Using Iso-Recursive Types ............................... 154 Chapter 18: Data Abstraction and Existential Types 157 18.1 Data Abstraction in Clients .............................. 157 18.2 Libraries that Enforce Abstraction .......................... 158 18.3 Existential ISWIM ................................... 159 18.4 Modules and Existential Types ............................ 161 Chapter 19: Subtyping 163 19.1 Records and Subtypes ................................. 163 19.2 Subtypes and Functions ................................ 165 19.3 Subtypes and Fields .................................. 166 19.4 From Records to Objects ............................... 166 Chapter 20: Objects and Classes 169 20.1 MiniJava Syntax .................................... 169 20.2 MiniJava Evaluation .................................. 172 20.3 MiniJava Type Checking ................................ 173 20.4 MiniJava Soundness .................................. 175 20.5 MiniJava Summary ................................... 181 6 Part I Models of Languages 7 9 Chapter 1: Computing with Text In this book, we study how a programming language can be defined in a way that is easily understood by people, and also amenable to formal analysis—where the formal analysis should be easily understood by people, too. One way of defining a language is to write prose paragraphs that explain the kinds of expressions that are allowed in the language and how they are evaluated. This technique has an advantage that a reader can quickly absorb general ideas about the language, but details about the language are typically difficult to extract from prose. Worse, prose does not lend itself to formal analysis. Another way of defining a language is to implement an interpreter for it in some meta- language. Assuming that a reader is familiar with the meta-language, this technique has the advantage of clearly and completely specifying the details of the language. Assuming that the meta-language has a formal specification, then the interpreter has a formal meaning in that language, and it can be analyzed. The meta-language used to define another language need not execute efficiently, since its primary purpose is to explain the other language to humans. The meta-language’s primitive data constructs need not be defined in terms of bits and bytes. Indeed, for the meta-language we can directly use logic and set theory over a universe of program text. In the same way that computation on physical machines can be described, ultimately, in terms of shuffling bits among memory locations, computation in the abstract can be described in terms of relations on text. 1.1 Defining Sets When we write a BNF grammar, such as B = t | f | (B • B) then we actually define a set B of textual strings. The above definition can be expanded to the following constraints on B: t ∈ B f ∈ B a ∈ B and b ∈ B ⇒ (a • b) ∈ B Technically, the set B that we mean is the smallest set that obeys the above constraints. Notation: we’ll sometimes use “B” to mean “the set B”, but sometimes “B” will mean “an arbitrary element of B”. The meaning is always clear from the context. Sometimes, we use a subscript or a prime on the name of the set to indicate an arbitrary element of the set, such as 0 “B1” or “B ”. Thus, the above constraints might be written as t ∈ B [a] f ∈ B [b] (B1 • B2) ∈ B [c] Whether expressed in BNF shorthand or expanded as a set of constraints, set B is defined recursively. Enumerating all of the elements of B in finite space is clearly impossible in this case: B = {t, f, (t • t), (t • f),...} 10 Chapter 1: Computing with Text Given a particular bit of text
Load more

Recommended publications
  • Ironpython in Action
    IronPytho IN ACTION Michael J. Foord Christian Muirhead FOREWORD BY JIM HUGUNIN MANNING IronPython in Action Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> IronPython in Action MICHAEL J. FOORD CHRISTIAN MUIRHEAD MANNING Greenwich (74° w. long.) Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. Sound View Court 3B fax: (609) 877-8256 Greenwich, CT 06830 email: [email protected] ©2009 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15% recycled and processed without the use of elemental chlorine.
    [Show full text]
  • Functional Programming Is Style of Programming in Which the Basic Method of Computation Is the Application of Functions to Arguments;
    PROGRAMMING IN HASKELL Chapter 1 - Introduction 0 What is a Functional Language? Opinions differ, and it is difficult to give a precise definition, but generally speaking: • Functional programming is style of programming in which the basic method of computation is the application of functions to arguments; • A functional language is one that supports and encourages the functional style. 1 Example Summing the integers 1 to 10 in Java: int total = 0; for (int i = 1; i 10; i++) total = total + i; The computation method is variable assignment. 2 Example Summing the integers 1 to 10 in Haskell: sum [1..10] The computation method is function application. 3 Historical Background 1930s: Alonzo Church develops the lambda calculus, a simple but powerful theory of functions. 4 Historical Background 1950s: John McCarthy develops Lisp, the first functional language, with some influences from the lambda calculus, but retaining variable assignments. 5 Historical Background 1960s: Peter Landin develops ISWIM, the first pure functional language, based strongly on the lambda calculus, with no assignments. 6 Historical Background 1970s: John Backus develops FP, a functional language that emphasizes higher-order functions and reasoning about programs. 7 Historical Background 1970s: Robin Milner and others develop ML, the first modern functional language, which introduced type inference and polymorphic types. 8 Historical Background 1970s - 1980s: David Turner develops a number of lazy functional languages, culminating in the Miranda system. 9 Historical Background 1987: An international committee starts the development of Haskell, a standard lazy functional language. 10 Historical Background 1990s: Phil Wadler and others develop type classes and monads, two of the main innovations of Haskell.
    [Show full text]
  • Thriving in a Crowded and Changing World: C++ 2006–2020
    Thriving in a Crowded and Changing World: C++ 2006–2020 BJARNE STROUSTRUP, Morgan Stanley and Columbia University, USA Shepherd: Yannis Smaragdakis, University of Athens, Greece By 2006, C++ had been in widespread industrial use for 20 years. It contained parts that had survived unchanged since introduced into C in the early 1970s as well as features that were novel in the early 2000s. From 2006 to 2020, the C++ developer community grew from about 3 million to about 4.5 million. It was a period where new programming models emerged, hardware architectures evolved, new application domains gained massive importance, and quite a few well-financed and professionally marketed languages fought for dominance. How did C++ ś an older language without serious commercial backing ś manage to thrive in the face of all that? This paper focuses on the major changes to the ISO C++ standard for the 2011, 2014, 2017, and 2020 revisions. The standard library is about 3/4 of the C++20 standard, but this paper’s primary focus is on language features and the programming techniques they support. The paper contains long lists of features documenting the growth of C++. Significant technical points are discussed and illustrated with short code fragments. In addition, it presents some failed proposals and the discussions that led to their failure. It offers a perspective on the bewildering flow of facts and features across the years. The emphasis is on the ideas, people, and processes that shaped the language. Themes include efforts to preserve the essence of C++ through evolutionary changes, to simplify itsuse,to improve support for generic programming, to better support compile-time programming, to extend support for concurrency and parallel programming, and to maintain stable support for decades’ old code.
    [Show full text]
  • Cornell CS6480 Lecture 3 Dafny Robbert Van Renesse Review All States
    Cornell CS6480 Lecture 3 Dafny Robbert van Renesse Review All states Reachable Ini2al states states Target states Review • Behavior: infinite sequence of states • Specificaon: characterizes all possible/desired behaviors • Consists of conjunc2on of • State predicate for the inial states • Acon predicate characterizing steps • Fairness formula for liveness • TLA+ formulas are temporal formulas invariant to stuering • Allows TLA+ specs to be part of an overall system Introduction to Dafny What’s Dafny? • An imperave programming language • A (mostly funconal) specificaon language • A compiler • A verifier Dafny programs rule out • Run2me errors: • Divide by zero • Array index out of bounds • Null reference • Infinite loops or recursion • Implementa2ons that do not sa2sfy the specifica2ons • But it’s up to you to get the laFer correct Example 1a: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 { x' := if x < 0 then -x else x; } method Main() { var x := Abs(-3); assert x >= 0; print x, "\n"; } Example 1b: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 { x' := 10; } method Main() { var x := Abs(-3); assert x >= 0; print x, "\n"; } Example 1c: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 ensures if x < 0 then x' == -x else x' == x { x' := 10; } method Main() { var x := Abs(-3); print x, "\n"; } Example 1d: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 ensures if x < 0 then x' == -x else x' == x { if x < 0 { x' := -x; } else { x' := x; } } Example 1e: Abs() method Abs(x: int) returns (x': int) ensures
    [Show full text]
  • Think Python
    Think Python How to Think Like a Computer Scientist 2nd Edition, Version 2.2.18 Think Python How to Think Like a Computer Scientist 2nd Edition, Version 2.2.18 Allen Downey Green Tea Press Needham, Massachusetts Copyright © 2015 Allen Downey. Green Tea Press 9 Washburn Ave Needham MA 02492 Permission is granted to copy, distribute, and/or modify this document under the terms of the Creative Commons Attribution-NonCommercial 3.0 Unported License, which is available at http: //creativecommons.org/licenses/by-nc/3.0/. The original form of this book is LATEX source code. Compiling this LATEX source has the effect of gen- erating a device-independent representation of a textbook, which can be converted to other formats and printed. http://www.thinkpython2.com The LATEX source for this book is available from Preface The strange history of this book In January 1999 I was preparing to teach an introductory programming class in Java. I had taught it three times and I was getting frustrated. The failure rate in the class was too high and, even for students who succeeded, the overall level of achievement was too low. One of the problems I saw was the books. They were too big, with too much unnecessary detail about Java, and not enough high-level guidance about how to program. And they all suffered from the trap door effect: they would start out easy, proceed gradually, and then somewhere around Chapter 5 the bottom would fall out. The students would get too much new material, too fast, and I would spend the rest of the semester picking up the pieces.
    [Show full text]
  • Biorthogonality, Step-Indexing and Compiler Correctness
    Biorthogonality, Step-Indexing and Compiler Correctness Nick Benton Chung-Kil Hur Microsoft Research University of Cambridge [email protected] [email protected] Abstract to a deeper semantic one (‘does the observable behaviour of the We define logical relations between the denotational semantics of code satisfy this desirable property?’). In previous work (Benton a simply typed functional language with recursion and the opera- 2006; Benton and Zarfaty 2007; Benton and Tabareau 2009), we tional behaviour of low-level programs in a variant SECD machine. have looked at establishing type-safety in the latter, more semantic, The relations, which are defined using biorthogonality and step- sense. Our key notion is that a high-level type translates to a low- indexing, capture what it means for a piece of low-level code to level specification that should be satisfied by any code compiled implement a mathematical, domain-theoretic function and are used from a source language phrase of that type. These specifications are to prove correctness of a simple compiler. The results have been inherently relational, in the usual style of PER semantics, capturing formalized in the Coq proof assistant. the meaning of a type A as a predicate on low-level heaps, values or code fragments together with a notion of A-equality thereon. These Categories and Subject Descriptors F.3.1 [Logics and Mean- relations express what it means for a source-level abstractions (e.g. ings of Programs]: Specifying and Verifying and Reasoning about functions of type A ! B) to be respected by low-level code (e.g. Programs—Mechanical verification, Specification techniques; F.3.2 ‘taking A-equal arguments to B-equal results’).
    [Show full text]
  • Natural Domain of a Function • Range Calculations Table of Contents (Continued)
    ~ THE UNIVERSITY OF AKRON w Mathematics and Computer Science calculus Article: Functions menu Directory • Table of Contents • Begin tutorial on Functions • Index Copyright c 1995{1998 D. P. Story Last Revision Date: 11/6/1998 Functions Table of Contents 1. Introduction 2. The Concept of a Function 2.1. Constructing Functions • The Use of Algebraic Expressions • Piecewise Definitions • Descriptive or Conceptual Methods 2.2. Evaluation Issues • Numerical Evaluation • Symbolic Evalulation 2.3. What's in a Name • The \Standard" Way • Functions Named by the Depen- dent Variable • Descriptive Naming • Famous Functions 2.4. Models for Functions • A Function as a Mapping • Venn Diagram of a Function • A Function as a Black Box 2.5. Calculating the Domain and Range • The Natural Domain of a Function • Range Calculations Table of Contents (continued) 2.6. Recognizing Functions • Interpreting the Terminology • The Vertical Line Test 3. Graphing: First Principles 4. Methods of Combining Functions 4.1. The Algebra of Functions 4.2. The Composition of Functions 4.3. Shifting and Rescaling • Horizontal Shifting • Vertical Shifting • Rescaling 5. Classification of Functions • Polynomial Functions • Rational Functions • Algebraic Functions 1. Introduction In the world of Mathematics one of the most common creatures en- countered is the function. It is important to understand the idea of a function if you want to gain a thorough understanding of Calculus. Science concerns itself with the discovery of physical or scientific truth. In a portion of these investigations, researchers (or engineers) attempt to discern relationships between physical quantities of interest. There are many ways of interpreting the meaning of the word \relation- ships," but in Calculus we are most often concerned with functional relationships.
    [Show full text]
  • False Dilemma Wikipedia Contents
    False dilemma Wikipedia Contents 1 False dilemma 1 1.1 Examples ............................................... 1 1.1.1 Morton's fork ......................................... 1 1.1.2 False choice .......................................... 2 1.1.3 Black-and-white thinking ................................... 2 1.2 See also ................................................ 2 1.3 References ............................................... 3 1.4 External links ............................................. 3 2 Affirmative action 4 2.1 Origins ................................................. 4 2.2 Women ................................................ 4 2.3 Quotas ................................................. 5 2.4 National approaches .......................................... 5 2.4.1 Africa ............................................ 5 2.4.2 Asia .............................................. 7 2.4.3 Europe ............................................ 8 2.4.4 North America ........................................ 10 2.4.5 Oceania ............................................ 11 2.4.6 South America ........................................ 11 2.5 International organizations ...................................... 11 2.5.1 United Nations ........................................ 12 2.6 Support ................................................ 12 2.6.1 Polls .............................................. 12 2.7 Criticism ............................................... 12 2.7.1 Mismatching ......................................... 13 2.8 See also
    [Show full text]
  • Pivotal Decompositions of Functions
    PIVOTAL DECOMPOSITIONS OF FUNCTIONS JEAN-LUC MARICHAL AND BRUNO TEHEUX Abstract. We extend the well-known Shannon decomposition of Boolean functions to more general classes of functions. Such decompositions, which we call pivotal decompositions, express the fact that every unary section of a function only depends upon its values at two given elements. Pivotal decom- positions appear to hold for various function classes, such as the class of lattice polynomial functions or the class of multilinear polynomial functions. We also define function classes characterized by pivotal decompositions and function classes characterized by their unary members and investigate links between these two concepts. 1. Introduction A remarkable (though immediate) property of Boolean functions is the so-called Shannon decomposition, or Shannon expansion (see [20]), also called pivotal decom- position [2]. This property states that, for every Boolean function f : {0, 1}n → {0, 1} and every k ∈ [n]= {1,...,n}, the following decomposition formula holds: 1 0 n (1) f(x) = xk f(xk)+ xk f(xk) , x = (x1,...,xn) ∈{0, 1} , a where xk = 1 − xk and xk is the n-tuple whose i-th coordinate is a, if i = k, and xi, otherwise. Here the ‘+’ sign represents the classical addition for real numbers. Decomposition formula (1) means that we can precompute the function values for xk = 0 and xk = 1 and then select the appropriate value depending on the value of xk. By analogy with the cofactor expansion formula for determinants, here 1 0 f(xk) (resp. f(xk)) is called the cofactor of xk (resp. xk) for f and is derived by setting xk = 1 (resp.
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Forms of Semantic Speci Cation
    THE LOGIC IN COMPUTER SCIENCE COLUMN by Yuri GUREVICH Electrical Engineering and Computer Science Department University of Michigan Ann Arb or MI USA Forms of Semantic Sp ecication Carl A Gunter UniversityofPennsylvania The way to sp ecify a programming language has b een a topic of heated debate for some decades and at present there is no consensus on how this is b est done Real languages are almost always sp ecied informally nevertheless precision is often enough lacking that more formal approaches could b enet b oth programmers and language implementors My purp ose in this column is to lo ok at a few of these formal approaches in hop e of establishing some distinctions or at least stirring some discussion Perhaps the crudest form of semantics for a programming language could b e given by providing a compiler for the language on a sp ecic physical machine If the machine archi tecture is easy to understand then this could b e viewed as a way of explaining the meaning of a program in terms of a translation into a simple mo del This view has the advantage that every higherlevel programming language of any use has a compiler for at least one machine and this sp ecication is entirely formal Moreover the sp ecication makes it known to the programmer how eciency is b est achieved when writing programs in the language and compiling on that machine On the other hand there are several problems with this technique and I do not knowofany programming language that is really sp ecied in this way although Im told that such sp ecications do exist
    [Show full text]
  • Application and Interpretation
    Programming Languages: Application and Interpretation Shriram Krishnamurthi Brown University Copyright c 2003, Shriram Krishnamurthi This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License. If you create a derivative work, please include the version information below in your attribution. This book is available free-of-cost from the author’s Web site. This version was generated on 2007-04-26. ii Preface The book is the textbook for the programming languages course at Brown University, which is taken pri- marily by third and fourth year undergraduates and beginning graduate (both MS and PhD) students. It seems very accessible to smart second year students too, and indeed those are some of my most successful students. The book has been used at over a dozen other universities as a primary or secondary text. The book’s material is worth one undergraduate course worth of credit. This book is the fruit of a vision for teaching programming languages by integrating the “two cultures” that have evolved in its pedagogy. One culture is based on interpreters, while the other emphasizes a survey of languages. Each approach has significant advantages but also huge drawbacks. The interpreter method writes programs to learn concepts, and has its heart the fundamental belief that by teaching the computer to execute a concept we more thoroughly learn it ourselves. While this reasoning is internally consistent, it fails to recognize that understanding definitions does not imply we understand consequences of those definitions. For instance, the difference between strict and lazy evaluation, or between static and dynamic scope, is only a few lines of interpreter code, but the consequences of these choices is enormous.
    [Show full text]