DOCSLIB.ORG

How Much Non-Strictness Do Lenient Programs Require?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
How Much Non-Strictness Do Lenient Programs Require? How Much Nonstrictness do Lenient Programs Require Klaus E Schauser Seth C Goldstein Department of Computer Science Computer Science Division University of California Santa Barbara University of California Berkeley Santa Barbara CA Berkeley CA schausercsucsbedu sethgcsb erkeleyedu contribute to the result thus decreasing parallelism How Abstract ever nonstrictness can also b e combined with eager evalu Lenient languages such as Id have b een touted as among ation This combination called lenient evaluation Tra the b est functional languages for massively parallel machines exhibits more parallelism than lazy evaluation while retain AHN Lenient evaluation combines nonstrict semantics ing much of the latters expressive p ower with eager evaluation Tra Nonstrictness gives these Unfortunately nonstrictness comes at a high implemen languages more expressive p ower than strict semantics while tation cost since it requires negrained dynamic schedul eager evaluation ensures the highest degree of parallelism ing and synchronization Nonstrict semantics can make it Unfortunately nonstrictness incurs a large overhead as it imp ossible to statically determine the order in which ar requires dynamic scheduling and synchronization As a re guments are evaluated and op erations execute Expressions sult many p owerful program analysis techniques have b een can b e evaluated only after all of the arguments they dep end develop ed to statically determine when nonstrictness is not on are available This dynamic scheduling is exp ensive on required CPJ Tra Sch commo dity micropro cessors which eciently supp ort only This pap er studies a large set of lenient programs and a single thread of control and incur a high cost for context quanties the degree of nonstrictness they require We switching identify several forms of nonstrictness including functional Much research has b een devoted to analysis techniques conditional and data structure nonstrictness Surprisingly that determine when the full generality of nonstrictness most Id programs require neither functional nor condi is not required These techniques include strictness anal tional nonstrictness Many b enchmark programs however ysis Pey backwards analysis Hugb path analysis make use of a limited form of data structure nonstrictness BH and partitioning Tra SCvE HDGS For The pap er refutes the myth that lenient programs require lenient languages the compilation approach is to schedule extensive nonstrictness instructions statically into sequential threads and have dy namic scheduling only b etween threads The task of identi fying p ortions of the program that can b e scheduled stati Intro duction cally and ordered into threads is called partitioning Tra Two op erations can b e placed into the same thread only Nonstrict functional languages have b een widely regarded if the compiler can statically determine the order in which as an attractive basis for parallel computing Unlike sequen they execute tial languages they exp ose all the parallelism in a program In Sch we presented a new thread partitioning al In sideeectfree functional languages the arguments to a gorithm separation constraint partitioning which improves function call can b e evaluated in parallel Further nonstrict substantially on previous work Tra HDGS SCvE execution can substantially enhance parallelism since func To evaluate our partitioning algorithm we compared b ench tions can start executing b efore all of their arguments have mark programs compiled using our algorithm and using strict b een provided In a language with nonstrict semantics it partitioning Strict partitioning ignores p ossible nonstrict is p ossible to dene functions which return a result even if ness and compiles functions and conditionals strictly thus one of the arguments diverges Among other things this representing the b est p ossible partitioning Obviously strict makes it p ossible to create recursively dened and cyclic partitioning pro duces an incorrect partitioning ie leading data structures since p ortions of the result of a function to a deadlo ck for programs which require nonstrictness call can b e used as arguments to that call Nonstrictness Surprisingly almost all of our b enchmark programs still ran increases the expressiveness of the language but requires a correctly an indication that nonstrictness is rarely used in more exible strategy than strict evaluation which evalu lenient programs ates all arguments b efore calling a function This observation led us to pursue a more detailed study Nonstrictness is usually combined with lazy evaluation of how much nonstrictness lenient programs use and to which delays evaluation of an expression until it is known to fo cus on a larger set of programs In this pap er we eval uate the strictness prop erties of a large collection of pro grams written in Id a nonstrict functional language that To app ear in th Annual ACM SIGPLANSIGARCH uses lenient evaluation We dene three catagories of non Conference on Functional Programming Languages and strictness functional conditional and datastructure non Computer Architecture FPCA strictness We nd that functional and conditional non strictness are rarely used in lenient programs On the other hand data structure nonstrictness is used extensively We more expressive power catagorize datastructure nonstrictness into circu further M-structures recursive and dynamically scheduled nonstrictness and lar I-structures e see that the exp ensive dynamically scheduled nonstrict w determinate is seldom required ness Functional core referentially transparent this study our fo cus is on whether nonstrictness is In determinate required and if it is what kind is required for executing simpler semantics lenient programs correctly Therefore the study is not af fected by whether the programs are executed in parallel or sequentially We chose to study the sequential execution Figure The three layers of Id from Nik b ehavior However evaluating functions even strict func tions nonstrictly can increase parallelism We nd that nonstrictness is rarely used suggesting that future work on elements Like functional arrays Istructures provide e lenient languages should fo cus less on techniques for deter cient indexed access to the individual elements In addi mining when nonstrictness is not used and more on when tion Istructures provide elementbyelement synchroniza strict functions and conditionals should b e evaluated non tion b etween the pro ducer and consumer Istructures are strictly not purely functional since they lose referential transpar The remainder of the pap er is structured as follows Sec ency Any function obtaining a p ointer to an Istructure tion summarizes the dierent evaluation strategies for func may store into it On the other hand determinacy is pre tional languages strict lenient and lazy and previous ar served b ecause each lo cation can b e stored into at most once guments for lenient evaluation as the most suitable way to Nondeterministic computation can b e expressed with M write programs for massively parallel machines Section structures mutable data structures that provide supp ort for identies and illustrates three kinds of nonstrictness con atomic up dates ditional functional and data structure nonstrictness Sec tion describ es the metho dology and the b enchmark pro Evaluation Strategies grams which were used for this study and presents the re The two most widely used evaluation strategies for func sults which show the typ e of nonstrictness each program tional languages are strict and lazy evaluation We com requires Section discusses related work and Section pare them to lenient evaluation the strategy used in Id suggests directions for future work The three strategies dier in how they handle the evalua tion of typ e constructors and function calls As presented Lenient Evaluation in Tra to evaluate a function call f e e 1 n This section summarizes dierent evaluation strategies for Strict evaluation rst evaluates all of the argument ex functional languages strict lenient and lazy The three pressions e to e and then evaluates the function 1 n evaluation strategies dier in their expressiveness paral b o dy passing in the evaluated arguments lelism and eciency Many arguments have b een made Lenient evaluation starts the evaluation of the function in favor of lenient evaluation as emb o died in the language 1 b o dy f in parallel with the evaluation of all the argu Id as the b est choice for massively parallel machines ment expressions e to e evaluating each only as far 1 n AHN Nik Being nonstrict lenient evaluation retains as the data dep endencies p ermit much of the expressive p ower of lazy evaluation at a much lower overhead while exhibiting more parallelism than b oth Lazy evaluation starts the evaluation of the function b o dy strict and lazy evaluation Tra passing the arguments in an unevaluated form The evaluation rules for constants arithmetic primitives The Lenient Language Id and conditionals are the same for the three strategies The Id is a functional language augmented with synchronizing evaluation of a constant yields that constant Arithmetic data structures It consists of three layers as shown in Fig op erators are strict in their arguments so they evaluate the ure The functional core has all of the prop erties of purely arguments b efore p erforming the op eration The evaluation functional languages including referential transparency and of a conditional if e then e else e rst evaluates the pred 1 2 3 determinacy Id provides
Load more

Recommended publications
  • 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]
  • 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]
  • Parametric Polymorphism and Operational Improvement
    Parametric Polymorphism and Operational Improvement JENNIFER HACKETT, University of Nottingham, UK GRAHAM HUTTON, University of Nottingham, UK Parametricity, in both operational and denotational forms, has long been a useful tool for reasoning about program correctness. However, there is as yet no comparable technique for reasoning about program improve- ment, that is, when one program uses fewer resources than another. Existing theories of parametricity cannot be used to address this problem as they are agnostic with regard to resource usage. This article addresses this problem by presenting a new operational theory of parametricity that is sensitive to time costs, which can be used to reason about time improvement properties. We demonstrate the applicability of our theory by showing how it can be used to prove that a number of well-known program fusion techniques are time improvements, including fixed point fusion, map fusion and short cut fusion. CCS Concepts: • Software and its engineering → Functional languages; Polymorphism; • Theory of computation → Operational semantics; Additional Key Words and Phrases: parametricity, improvement theory ACM Reference Format: Jennifer Hackett and Graham Hutton. 2018. Parametric Polymorphism and Operational Improvement. Proc. ACM Program. Lang. 2, ICFP, Article 68 (September 2018), 24 pages. https://doi.org/10.1145/3236763 68 1 INTRODUCTION Parametric polymorphism is everywhere. In typed functional languages, many if not most of the built-in and user-defined functions are parametric. Because of this ubiquity, we must carefully study the properties of parametric functions. Chief among these properties is the abstraction theorem [Reynolds 1983], which shows that any well-typed term must satisfy a property that can be derived uniformly from its type.
    [Show full text]
  • Haskell Communities and Activities Report
    Haskell Communities and Activities Report http://tinyurl.com/haskcar Thirty Fourth Edition — May 2018 Mihai Maruseac (ed.) Chris Allen Christopher Anand Moritz Angermann Francesco Ariis Heinrich Apfelmus Gershom Bazerman Doug Beardsley Jost Berthold Ingo Blechschmidt Sasa Bogicevic Emanuel Borsboom Jan Bracker Jeroen Bransen Joachim Breitner Rudy Braquehais Björn Buckwalter Erik de Castro Lopo Manuel M. T. Chakravarty Eitan Chatav Olaf Chitil Alberto Gómez Corona Nils Dallmeyer Tobias Dammers Kei Davis Dimitri DeFigueiredo Richard Eisenberg Maarten Faddegon Dennis Felsing Olle Fredriksson Phil Freeman Marc Fontaine PÁLI Gábor János Michał J. Gajda Ben Gamari Michael Georgoulopoulos Andrew Gill Mikhail Glushenkov Mark Grebe Gabor Greif Adam Gundry Jennifer Hackett Jurriaan Hage Martin Handley Bastiaan Heeren Sylvain Henry Joey Hess Kei Hibino Guillaume Hoffmann Graham Hutton Nicu Ionita Judah Jacobson Patrik Jansson Wanqiang Jiang Dzianis Kabanau Nikos Karagiannidis Anton Kholomiov Oleg Kiselyov Ivan Krišto Yasuaki Kudo Harendra Kumar Rob Leslie David Lettier Ben Lippmeier Andres Löh Rita Loogen Tim Matthews Simon Michael Andrey Mokhov Dino Morelli Damian Nadales Henrik Nilsson Wisnu Adi Nurcahyo Ulf Norell Ivan Perez Jens Petersen Sibi Prabakaran Bryan Richter Herbert Valerio Riedel Alexey Radkov Vaibhav Sagar Kareem Salah Michael Schröder Christian Höner zu Siederdissen Ben Sima Jeremy Singer Gideon Sireling Erik Sjöström Chris Smith Michael Snoyman David Sorokin Lennart Spitzner Yuriy Syrovetskiy Jonathan Thaler Henk-Jan van Tuyl Tillmann Vogt Michael Walker Li-yao Xia Kazu Yamamoto Yuji Yamamoto Brent Yorgey Christina Zeller Marco Zocca Preface This is the 34th edition of the Haskell Communities and Activities Report. This report has 148 entries, 5 more than in the previous edition.
    [Show full text]
  • Pure Quick Reference
    Pure Quick Reference Albert Graf¨ April 15, 2018 Abstract This is a quick reference guide to the Pure programming language for the impa- tient. It briefly summarizes all important language constructs and gives a few basic examples, so that seasoned programmers can pick up the language at a glance and start hacking away as quickly as possible. Copyright © 2009-2018 Albert Gräf. Permission is granted to copy, distribute and/or modify this docu- ment under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. See http://www.gnu.org/copyleft/fdl.html. The latest version of this document can be found at https://agraef.github.io/pure-lang/quickref/pure-quickref.pdf. Contents 1 Introduction 3 1.1 Background and Recommended Reading . 3 1.2 Getting Started . 4 2 Lexical Matters 5 3 Expressions 6 3.1 Primary Expressions . 7 3.2 Function Applications . 9 3.3 Operators . 11 3.4 Predefined Operators . 13 3.5 Patterns . 15 3.6 Conditional Expressions . 18 3.7 Block Expressions . 19 3.8 Lexical Scoping . 21 3.9 Comprehensions . 22 3.10 Special Forms . 23 1 4 Definitions 26 4.1 The Global Scope . 26 4.2 Rule Syntax . 27 4.3 Function Definitions . 29 4.4 Variable Definitions . 33 4.5 Constant Definitions . 33 4.6 Type Definitions . 34 4.7 Macro Definitions . 37 5 Programs and Modules 38 5.1 Modules . 38 5.2 Namespaces . 39 5.3 Private Symbols . 42 5.4 Hierarchical Namespaces . 42 6 C Interface 43 7 The Interpreter 45 7.1 Running the Interpreter .
    [Show full text]
  • Rxjs in Action
    Paul P. Daniels Luis Atencio FOREWORD BY Ben Lesh MANNING www.allitebooks.com RxJS in Action www.allitebooks.com www.allitebooks.com RxJS in Action COVERS RXJS 5 PAUL P. DANIELS LUIS ATENCIO FOREWORD BY BEN LESH MANNING SHELTER ISLAND www.allitebooks.com 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. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: [email protected] ©2017 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 percent recycled and processed without the use of elemental chlorine. Manning Publications Co. Development
    [Show full text]
  • Functional Programming and the Lambda Calculus
    Functional Programming and the Lambda Calculus Stephen A. Edwards Columbia University Fall 2008 Functional vs. Imperative Imperative programming concerned with “how.” Functional programming concerned with “what.” Based on the mathematics of the lambda calculus (Church as opposed to Turing). “Programming without variables” It is elegant and a difficult setting in which to create subtle bugs. It’s a cult: once you catch the functional bug, you never escape. Referential transparency The main (good) property of functional programming is referential transparency. Every expression denotes a single value. The value cannot be changed by evaluating an expression or by sharing it between different parts of the program. No references to global data; there is no global data. There are no side-effects, unlike in referentially opaque languages. The Lambda Calculus Fancy name for rules about how to represent and evaluate expressions with unnamed functions. Theoretical underpinning of functional languages. Side-effect free. Very different from the Turing model of a store with evolving state. O’Caml: The Lambda Calculus: fun x ­> 2 * x λx . ∗ 2 x English: The function of x that returns the product of two and x Grammar of Lambda Expressions expr → constant | variable-name | expr expr | (expr) | λ variable-name . expr Constants are numbers; variable names are identifiers and operators. Somebody asked, “does a language needs to have a large syntax to be powerful?” Bound and Unbound Variables In λx . ∗ 2 x, x is a bound variable. Think of it as a formal parameter to a function. “∗ 2 x” is the body. The body can be any valid lambda expression, including another unnnamed function.
    [Show full text]
  • Brno University of Technology Just-In-Time
    BRNO UNIVERSITY OF TECHNOLOGY VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FACULTY OF INFORMATION TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ DEPARTMENT OF INTELLIGENT SYSTEMS ÚSTAV INTELIGENTNÍCH SYSTÉMŮ JUST-IN-TIME COMPILATION OF THE DEPENDENTLY-TYPED LAMBDA CALCULUS JUST-IN-TIME PŘEKLAD ZÁVISLE TYPOVANÉHO LAMBDA KALKULU MASTER’S THESIS DIPLOMOVÁ PRÁCE AUTHOR Bc. JAKUB ZÁRYBNICKÝ AUTOR PRÁCE SUPERVISOR Ing. ONDŘEJ LENGÁL, Ph.D. VEDOUCÍ PRÁCE BRNO 2021 Brno University of Technology Faculty of Information Technology Department of Intelligent Systems (DITS) Academic year 2020/2021 Master's Thesis Specification Student: Zárybnický Jakub, Bc. Programme: Information Technology Field of Intelligent Systems study: Title: Just-in-Time Compilation of Dependently-Typed Lambda Calculus Category: Compiler Construction Assignment: 1. Investigate dependent types, simply-typed and dependently-typed lambda calculus, and their evaluation models (push/enter, eval/apply). 2. Get familiar with the Graal virtual machine and the Truffle language implementation framework. 3. Create a parser and an interpreter for a selected language based on dependently-typed lambda calculus. 4. Propose a method of normalization-by-evaluation for dependent types and implement it for the selected language. 5. Create a just-in-time (JIT) compiler for the language using the Truffle API. 6. Compare the runtime characteristics of the interpreter and the JIT compiler, evaluate the results. Recommended literature: https://www.graalvm.org/ Löh, Andres, Conor McBride, and Wouter Swierstra. "A tutorial implementation of a dependently typed lambda calculus." Fundamenta Informaticae 21 (2001): 1001-1031. Marlow, Simon, and Simon Peyton Jones. "Making a fast curry: push/enter vs. eval/apply for higher-order languages." Journal of Functional Programming 16.4-5 (2006): 415-449.
    [Show full text]
  • Projections for Strictness Analysis
    Projections for Strictness Analysis Philip Wadler Programming Research Group, Oxford University and Programming Methodology Group, Chalmers University, GSteborg R.J.M. Hughes Department of Computer Science, University of Glasgow Abstract Contexts have been proposed as a means of performing strictness analysis on non-flat do- mains. Roughly speaking, a eontezt describes how much a sub-expression will be evaluated by the surrounding program. This paper shows how contexts can be represented using the notion of projection from domain theory. This is clearer than the previous explanation of contexts in terms of continuations. In addition, this paper describes finite dornaine of contexts over the non-flat list domain. This means that recursive context equations can be solved using standard fixpoint techniques, instead of the algebraic manipulation previously used. Praises of lazy functional languages have been widely sung, and so have some curses. One reason for praise is that laziness supports programming styles that are inconvenient or impossible otherwise [Joh87,Hug84,Wad85a]. One reason for cursing is that laziness hinders efficient implementation. Still, acceptable efficiency for lazy languages is at last being achieved. This is done by means of graph reduction [Pey87], as found in the G-machine [Aug84,Joh84] and the Ponder implementation [FW86], among others. The essential trick is to evaluate an expression immediately, when this is safe, rather than to construct a graph. Strictness analysis can reveal more places where this optimisation is safe. In the Ponder implementation, strictness analysis speeds up some programs by a factor of two or more. In addition, strictness analysis may enable other optimisations, such as destructive updating of arrays [HB85].
    [Show full text]
  • An Introduction to Probabilistic Programming Arxiv:1809.10756V1
    An Introduction to Probabilistic Programming Jan-Willem van de Meent College of Computer and Information Science Northeastern University [email protected] Brooks Paige Alan Turing Institute University of Cambridge [email protected] Hongseok Yang School of Computing KAIST [email protected] Frank Wood Department of Computer Science University of British Columbia [email protected] arXiv:1809.10756v1 [stat.ML] 27 Sep 2018 Contents Abstract1 Acknowledgements3 1 Introduction8 1.1 Model-based Reasoning . 10 1.2 Probabilistic Programming . 21 1.3 Example Applications . 26 1.4 A First Probabilistic Program . 29 2 A Probabilistic Programming Language Without Recursion 31 2.1 Syntax . 32 2.2 Syntactic Sugar . 37 2.3 Examples . 42 2.4 A Simple Purely Deterministic Language . 48 3 Graph-Based Inference 51 3.1 Compilation to a Graphical Model . 51 3.2 Evaluating the Density . 66 3.3 Gibbs Sampling . 74 3.4 Hamiltonian Monte Carlo . 80 3.5 Compilation to a Factor Graph . 89 3.6 Expectation Propagation . 94 4 Evaluation-Based Inference I 102 4.1 Likelihood Weighting . 105 4.2 Metropolis-Hastings . 116 4.3 Sequential Monte Carlo . 125 4.4 Black Box Variational Inference . 131 5 A Probabilistic Programming Language With Recursion 138 5.1 Syntax . 142 5.2 Syntactic sugar . 143 5.3 Examples . 144 6 Evaluation-Based Inference II 155 6.1 Explicit separation of model and inference code . 156 6.2 Addressing Transformation . 161 6.3 Continuation-Passing-Style Transformation . 165 6.4 Message Interface Implementation . 171 6.5 Likelihood Weighting . 175 6.6 Metropolis-Hastings .
    [Show full text]
  • Foundations of Functional Programming
    Foundations of Functional Programming Computer Science Tripos Part IB Easter Term Lawrence C Paulson Computer Laboratory University of Cambridge [email protected] Copyright © 2021 by Lawrence C. Paulson Contents 1 Introduction 1 2 Equality and Normalization 6 3 Encoding Data in the λ-Calculus 11 4 Writing Recursive Functions in the λ-calculus 16 5 The λ-Calculus and Computation Theory 23 6 ISWIM: The λ-calculus as a Programming Language 29 7 Lazy Evaluation via Combinators 39 8 Compiling Methods Using Combinators 45 i ii 1 1 Introduction This course is concerned with the λ-calculus and its close relative, combinatory logic. The λ-calculus is important to functional programming and to computer science generally: 1. Variable binding and scoping in block-structured languages can be mod- elled. 2. Several function calling mechanisms — call-by-name, call-by-value, and call-by-need — can be modelled. The latter two are also known as strict evaluation and lazy evaluation. 3. The λ-calculus is Turing universal, and is probably the most natural model of computation. Church’s Thesis asserts that the ‘computable’ functions are precisely those that can be represented in the λ-calculus. 4. All the usual data structures of functional programming, including infinite lists, can be represented. Computation on infinite objects can be defined formally in the λ-calculus. 5. Its notions of confluence (Church-Rosser property), termination, and nor- mal form apply generally in rewriting theory. 6. Lisp, one of the first major programming languages, was inspired by the λ-calculus. Many functional languages, such as ML, consist of little more than the λ-calculus with additional syntax.
    [Show full text]
  • Department of Computer Science and Engineering 19600 N.W
    What is an Abstract Machine? Richard B. Kieburtz, Borislav Agapiev Oregon Graduate Institute Department of Computer Science and Engineering 19600 N.W. von Neumann Drive Beaverton. OR 97006-1999 USA Technical Report No. CS/E 91-01 1 August, 1991 What is an Abstract Machine? Richard B. Kieburtz Borislav Agapiev Oregon Graduate Institute 19600 N.W. von Neumann Dr. Beaverton, Oregon 97006 USA Technical Report CSE-091-011 August, 1991 Abstract The thesis of this paper is that categorical models provide an appropriate frame- work for the high-level specification of computer architectures. As an example of this approach, we specify a categorical abstract machine capable of normal-order reduction of lambda calculus expressions to weak head-normal form. The paper includes substan- tial theoretical development of the appropriate categories and monads, including an account of involution, analogous to negation in intuitionistic logic. An abstract machine is defined as a composite monad, a technique that emphasizes modularity of structure. In order to make control explicit in the machine model, the monad structure models continuations. This supports a formal specification of stored-program control. The categorical model is shown to be cartesian-closed. Finally, an implementation of (weak) lambda-calculus reduction by the categorical abstract machine is proved coherent with the syntactic reduction rule (B) of the cal- culus. Abstract Machines What is an Abstract Machine? Richard B. Kieburtz Borislau Agapiev Oregon Graduate Institute 19600 N.W. von Neumann Dr. Beaverton, Oregon 97006 1. Abstract machines Implementations of programming languages are often based upon an evaluation model called an 'abstract machine' [6,12,13,15,24,27].
    [Show full text]