DOCSLIB.ORG

The Adventures of a Pythonista in Schemeland Release 0.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

The Adventures of a Pythonista in Schemeland Release 0.1 Michele Simionato August 05, 2009 CONTENTS 1 A bit of history3 1.1 My target.....................................3 1.2 A bit of history: Fortran and Lisp........................4 1.3 The algorithmic language Scheme........................5 2 About Scheme implementations7 2.1 About Scheme implementations.........................7 2.2 About the library problem............................8 2.3 Additional difficulties.............................. 10 3 Of parentheses and indentation 13 3.1 Of parens and indentation............................ 13 3.2 About the prefix syntax............................. 15 4 Scheme bibliography (and a first program) 17 4.1 Scheme resources for beginners......................... 17 4.2 A simple Scheme program............................ 18 5 About tail call optimization (and the module system) 21 5.1 There are no for loops in Scheme....................... 21 5.2 There is no portable module system....................... 23 5.3 A simple benchmark............................... 25 6 The danger of benchmarks 29 6.1 Beware of wasted cycles............................. 29 6.2 Beware of cheats................................. 31 6.3 Beware of naive optimization.......................... 32 6.4 Recursion vs iteration.............................. 33 7 Symbols and lists 35 7.1 Symbols..................................... 35 7.2 Lists....................................... 37 7.3 Some example.................................. 38 8 Quoting and quasi-quoting 41 8.1 Quoting...................................... 41 i 8.2 Quasi-quoting.................................. 42 8.3 Programs writing programs........................... 44 8.4 Appendix: solution of the exercises....................... 46 9 Introduction to (sweet-)macros 47 9.1 A minimal introduction to Scheme macros................... 47 9.2 Which macrology should I teach?........................ 48 9.3 Enter sweet-macros............................... 49 9.4 An example: multi-define ......................... 51 10 Features of (sweet-)macros 53 10.1 syntax-match and introspection features of sweet-macros......... 53 10.2 A couple of common mistakes.......................... 54 10.3 Guarded patterns................................. 55 10.4 Literal identifiers................................. 57 11 The multiple evaluation problem (and easy-test) 59 11.1 The problem of multiple evaluation....................... 59 11.2 Taking advantage of multiple evaluation..................... 61 11.3 A micro-framework for unit tests........................ 62 12 Are macros really useful? 67 12.1 Are macros “just syntactic sugar”?........................ 67 12.2 About the usefulness of macros for application programmers.......... 69 12.3 Appendix: a Pythonic for loop......................... 70 13 Micro-introduction to functional programming 73 13.1 A minimal introduction to functional programming............... 73 13.2 Functional data structures: pairs and lists.................... 74 13.3 Functional update................................ 75 14 Currying, partial application, and fold 79 14.1 Higher order functions and curried functions.................. 79 14.2 Partial application: cut and cute......................... 81 14.3 fold-left and fold-right.............................. 82 15 List destructuring 85 15.1 About pattern matching............................. 85 15.2 A list destructuring binding form (let+)..................... 87 16 Multiple values (and opt-lambda) 91 16.1 list destructuring versus let-values........................ 91 16.2 Variadic functions from unary functions..................... 93 16.3 Further examples of destructuring: opt-lambda................. 94 17 List comprehension 97 17.1 The APS library................................. 97 17.2 Implementing list comprehension........................ 99 17.3 A tricky point................................... 101 ii 18 Streams 103 18.1 The eight queens puzzle............................. 103 18.2 Iterators and streams............................... 104 18.3 Lazyness is a virtue............................... 106 19 The R6RS module system 109 19.1 Modules are not first class objects........................ 110 19.2 Compiling Scheme modules vs compiling Python modules........... 111 19.3 Compiling is not the same than executing.................... 112 20 The compilation and evaluation strategy of Scheme programs 115 20.1 Interpreter semantics vs compiler semantics................... 115 20.2 Macros and helper functions........................... 117 20.3 A note about incremental compilers and interpreters.............. 118 20.4 Discussion.................................... 119 21 The different meanings of phase separation 121 21.1 Compile-time, run-time and optimization-time................. 121 21.2 Strong vs weak phase separation......................... 123 21.3 A note about politics............................... 125 22 The Dark Tower of Meta-levels 127 22.1 An easy-looking macro with a deep portability issue.............. 127 22.2 Negative meta-levels............................... 130 22.3 Meta-levels greater than one........................... 131 22.4 Discussion.................................... 132 23 Separate compilation and import semantics 135 23.1 The mysterious import semantics........................ 136 23.2 More implementation-dependent details..................... 138 24 Mutating variables across modules 141 24.1 Mutating internal variables............................ 141 24.2 Mutating variables across phases........................ 142 24.3 Cross-phase side effects and separate compilation................ 143 24.4 Conclusion.................................... 146 25 Back to macros 147 25.1 Writing your own programming language.................... 148 25.2 Recursive macros with accumulators...................... 149 25.3 A trick to avoid auxiliary macros........................ 150 26 Macros taking macros as arguments 153 26.1 Scheme as an unfinished language........................ 153 26.2 Two second order macros to reduce parentheses................. 155 26.3 The case for parentheses............................. 156 27 Syntax objects 159 27.1 What syntax-match really is......................... 161 27.2 What macros really are.............................. 162 iii 27.3 A nicer syntax for association lists........................ 163 28 Hygienic macros 165 28.1 syntax-match vs syntax-rules ..................... 165 28.2 syntax-match vs syntax-case ...................... 166 28.3 syntax-match versus define-macro ................... 166 28.4 The hygiene problem............................... 167 29 Breaking hygiene 171 29.1 datum->syntax revisited........................... 171 29.2 Playing with the lexical context......................... 173 29.3 Hygienic vs non-hygienic macro systems.................... 174 30 Comparing identifiers 177 30.1 symbol-identifier=? ........................... 177 30.2 bound-identifier=? ............................ 178 30.3 free-identifier=? ............................ 180 30.4 Literal identifiers and auxiliary syntax...................... 180 31 Indices and tables 183 iv The Adventures of a Pythonista in Schemeland, Release 0.1 Contents: CONTENTS 1 The Adventures of a Pythonista in Schemeland, Release 0.1 2 CONTENTS CHAPTER ONE A BIT OF HISTORY This is the first episode of a long running series of articles about Scheme. Currently I have published the first 11 episodes of it on Stacktrace. This episode is a revised translation of http://stacktrace.it/2008/02/le-avventure-di-un-pythonista-schemeland-1/ 1.1 My target As you can imagine from the title, this series has been written from the point of view of a Python programmer. Nevertheless, it should be easy to follow for any programmer familiar with any dynamic language such as Perl, Ruby, PHP, Tcl, etc. In general all those languages (let me call them mainstream dynamic languages) are similar: interpreted, very dynamic, with a strong support for scripting (ok, maybe PHP does not fit the last point, but you get the idea ;) Scheme is different. Even if it is very dynamic and well suited for scripting, very often it is also compiled (both to native code or to a target language such as C, Java or the CLR) and can work at C speed. Moreover Scheme is a functional language and it makes use of a set of functional idioms which are unknown in the mainstream languages. Finally, Scheme offers to its user an extremely advanced macrology (actually it has the most advanced macro system I know) and extremely powerful features (such as continuations) without equivalent in other languages. That means that learning Scheme is not trivial: actually it takes of lot of effort and motivation to master it. If you see a programming language just as a tool to perform a given job in the smallest possible time, and your job is not programming language research, then you should not learn Scheme. Scheme is for people who want to know the many possible ways of performing the same job, who want to understand the advantages and the disadvantages of the different approaches, who want to explore programming paradigms. I do not think that the first kind of programmers (let say the engineers) is inferior to the second kind (let say the explorers) or viceversa. It all depends on where your interest lies. If you are doing bioinformatics and you researching a cure for a genetic sickness I expect you to solve your problem in the smallest possible amount of time with a specialized library without
Recommended publications
  • Structured Recursion for Non-Uniform Data-Types

    Structured Recursion for Non-Uniform Data-Types

    Structured recursion for non-uniform data-types by Paul Alexander Blampied, B.Sc. Thesis submitted to the University of Nottingham for the degree of Doctor of Philosophy, March 2000 Contents Acknowledgements .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 1 Chapter 1. Introduction .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2 1.1. Non-uniform data-types .. .. .. .. .. .. .. .. .. .. .. .. 3 1.2. Program calculation .. .. .. .. .. .. .. .. .. .. .. .. .. 10 1.3. Maps and folds in Squiggol .. .. .. .. .. .. .. .. .. .. .. 11 1.4. Related work .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 14 1.5. Purpose and contributions of this thesis .. .. .. .. .. .. .. 15 Chapter 2. Categorical data-types .. .. .. .. .. .. .. .. .. .. .. .. 18 2.1. Notation .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 19 2.2. Data-types as initial algebras .. .. .. .. .. .. .. .. .. .. 21 2.3. Parameterized data-types .. .. .. .. .. .. .. .. .. .. .. 29 2.4. Calculation properties of catamorphisms .. .. .. .. .. .. .. 33 2.5. Existence of initial algebras .. .. .. .. .. .. .. .. .. .. .. 37 2.6. Algebraic data-types in functional programming .. .. .. .. 57 2.7. Chapter summary .. .. .. .. .. .. .. .. .. .. .. .. .. 61 Chapter 3. Folding in functor categories .. .. .. .. .. .. .. .. .. .. 62 3.1. Natural transformations and functor categories .. .. .. .. .. 63 3.2. Initial algebras in functor categories .. .. .. .. .. .. .. .. 68 3.3. Examples and non-examples .. .. .. .. .. .. .. .. .. .. 77 3.4. Existence of initial algebras in functor categories .. .. .. .. 82 3.5.
  • Introduction to Programming in Lisp

    Introduction to Programming in Lisp

    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
  • The Machine That Builds Itself: How the Strengths of Lisp Family

    The Machine That Builds Itself: How the Strengths of Lisp Family

    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
  • Binary Search Trees

    Binary Search Trees

    Introduction Recursive data types Binary Trees Binary Search Trees Organizing information Sum-of-Product data types Theory of Programming Languages Computer Science Department Wellesley College Introduction Recursive data types Binary Trees Binary Search Trees Table of contents Introduction Recursive data types Binary Trees Binary Search Trees Introduction Recursive data types Binary Trees Binary Search Trees Sum-of-product data types Every general-purpose programming language must allow the • processing of values with different structure that are nevertheless considered to have the same “type”. For example, in the processing of simple geometric figures, we • want a notion of a “figure type” that includes circles with a radius, rectangles with a width and height, and triangles with three sides: The name in the oval is a tag that indicates which kind of • figure the value is, and the branches leading down from the oval indicate the components of the value. Such types are known as sum-of-product data types because they consist of a sum of tagged types, each of which holds on to a product of components. Introduction Recursive data types Binary Trees Binary Search Trees Declaring the new figure type in Ocaml In Ocaml we can declare a new figure type that represents these sorts of geometric figures as follows: type figure = Circ of float (* radius *) | Rect of float * float (* width, height *) | Tri of float * float * float (* side1, side2, side3 *) Such a declaration is known as a data type declaration. It consists of a series of |-separated clauses of the form constructor-name of component-types, where constructor-name must be capitalized.
  • An Optimized R5RS Macro Expander

    An Optimized R5RS Macro Expander

    An Optimized R5RS Macro Expander Sean Reque A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Jay McCarthy, Chair Eric Mercer Quinn Snell Department of Computer Science Brigham Young University February 2013 Copyright c 2013 Sean Reque All Rights Reserved ABSTRACT An Optimized R5RS Macro Expander Sean Reque Department of Computer Science, BYU Master of Science Macro systems allow programmers abstractions over the syntax of a programming language. This gives the programmer some of the same power posessed by a programming language designer, namely, the ability to extend the programming language to fit the needs of the programmer. The value of such systems has been demonstrated by their continued adoption in more languages and platforms. However, several barriers to widespread adoption of macro systems still exist. The language Racket [6] defines a small core of primitive language constructs, including a powerful macro system, upon which all other features are built. Because of this design, many features of other programming languages can be implemented through libraries, keeping the core language simple without sacrificing power or flexibility. However, slow macro expansion remains a lingering problem in the language's primary implementation, and in fact macro expansion currently dominates compile times for Racket modules and programs. Besides the typical problems associated with slow compile times, such as slower testing feedback, increased mental disruption during the programming process, and unscalable build times for large projects, slow macro expansion carries its own unique problems, such as poorer performance for IDEs and other software analysis tools.
  • Towards a Portable and Mobile Scheme Interpreter

    Towards a Portable and Mobile Scheme Interpreter

    Towards a Portable and Mobile Scheme Interpreter Adrien Pi´erard Marc Feeley Universit´eParis 6 Universit´ede Montr´eal [email protected] [email protected] Abstract guage. Because Mobit implements R4RS Scheme [6], we must also The transfer of program data between the nodes of a distributed address the serialization of continuations. Our main contribution is system is a fundamental operation. It usually requires some form the demonstration of how this can be done while preserving the in- of data serialization. For a functional language such as Scheme it is terpreter’s maintainability and with local changes to the original in- clearly desirable to also allow the unrestricted transfer of functions terpreter’s structure, mainly through the use of unhygienic macros. between nodes. With the goal of developing a portable implemen- We start by giving an overview of the pertinent features of the tation of the Termite system we have designed the Mobit Scheme Termite dialect of Scheme. In Section 3 we explain the structure interpreter which supports unrestricted serialization of Scheme ob- of the interpreter on which Mobit is based. Object serialization is jects, including procedures and continuations. Mobit is derived discussed in Section 4. Section 5 compares Mobit’s performance from an existing Scheme in Scheme fast interpreter. We demon- with other interpreters. We conclude with related and future work. strate how macros were valuable in transforming the interpreter while preserving its structure and maintainability. Our performance 2. Termite evaluation shows that the run time speed of Mobit is comparable to Termite is a Scheme adaptation of the Erlang concurrency model.
  • An Evaluation of Go and Clojure

    An Evaluation of Go and Clojure

    An evaluation of Go and Clojure A thesis submitted in partial satisfaction of the requirements for the degree Bachelors of Science in Computer Science Fall 2010 Robert Stimpfling Department of Computer Science University of Colorado, Boulder Advisor: Kenneth M. Anderson, PhD Department of Computer Science University of Colorado, Boulder 1. Introduction Concurrent programming languages are not new, but they have been getting a lot of attention more recently due to their potential with multiple processors. Processors have gone from growing exponentially in terms of speed, to growing in terms of quantity. This means processes that are completely serial in execution will soon be seeing a plateau in performance gains since they can only rely on one processor. A popular approach to using these extra processors is to make programs multi-threaded. The threads can execute in parallel and use shared memory to speed up execution times. These multithreaded processes can significantly speed up performance, as long as the number of dependencies remains low. Amdahl‘s law states that these performance gains can only be relative to the amount of processing that can be parallelized [1]. However, the performance gains are significant enough to be looked into. These gains not only come from the processing being divvied up into sections that run in parallel, but from the inherent gains from sharing memory and data structures. Passing new threads a copy of a data structure can be demanding on the processor because it requires the processor to delve into memory and make an exact copy in a new location in memory. Indeed some studies have shown that the problem with optimizing concurrent threads is not in utilizing the processors optimally, but in the need for technical improvements in memory performance [2].
  • Recursive Type Generativity

    Recursive Type Generativity

    Recursive Type Generativity Derek Dreyer Toyota Technological Institute at Chicago [email protected] Abstract 1. Introduction Existential types provide a simple and elegant foundation for un- Recursive modules are one of the most frequently requested exten- derstanding generative abstract data types, of the kind supported by sions to the ML languages. After all, the ability to have cyclic de- the Standard ML module system. However, in attempting to extend pendencies between different files is a feature that is commonplace ML with support for recursive modules, we have found that the tra- in mainstream languages like C and Java. To the novice program- ditional existential account of type generativity does not work well mer especially, it seems very strange that the ML module system in the presence of mutually recursive module definitions. The key should provide such powerful mechanisms for data abstraction and problem is that, in recursive modules, one may wish to define an code reuse as functors and translucent signatures, and yet not allow abstract type in a context where a name for the type already exists, mutually recursive functions and data types to be broken into sepa- but the existential type mechanism does not allow one to do so. rate modules. Certainly, for simple examples of recursive modules, We propose a novel account of recursive type generativity that it is difficult to convincingly argue why ML could not be extended resolves this problem. The basic idea is to separate the act of gener- in some ad hoc way to allow them. However, when one considers ating a name for an abstract type from the act of defining its under- the semantics of a general recursive module mechanism, one runs lying representation.
  • Clojure, Given the Pun on Closure, Representing Anything Specific

    Clojure, Given the Pun on Closure, Representing Anything Specific

    dynamic, functional programming for the JVM “It (the logo) was designed by my brother, Tom Hickey. “It I wanted to involve c (c#), l (lisp) and j (java). I don't think we ever really discussed the colors Once I came up with Clojure, given the pun on closure, representing anything specific. I always vaguely the available domains and vast emptiness of the thought of them as earth and sky.” - Rich Hickey googlespace, it was an easy decision..” - Rich Hickey Mark Volkmann [email protected] Functional Programming (FP) In the spirit of saying OO is is ... encapsulation, inheritance and polymorphism ... • Pure Functions • produce results that only depend on inputs, not any global state • do not have side effects such as Real applications need some changing global state, file I/O or database updates side effects, but they should be clearly identified and isolated. • First Class Functions • can be held in variables • can be passed to and returned from other functions • Higher Order Functions • functions that do one or both of these: • accept other functions as arguments and execute them zero or more times • return another function 2 ... FP is ... Closures • main use is to pass • special functions that retain access to variables a block of code that were in their scope when the closure was created to a function • Partial Application • ability to create new functions from existing ones that take fewer arguments • Currying • transforming a function of n arguments into a chain of n one argument functions • Continuations ability to save execution state and return to it later think browser • back button 3 ..
  • Hy Documentation Release 0.12.1+64.G5eb9283

    Hy Documentation Release 0.12.1+64.G5eb9283

    hy Documentation Release 0.12.1+64.g5eb9283 Paul Tagliamonte Apr 14, 2017 Contents 1 Documentation Index 3 1.1 Quickstart................................................4 1.2 Tutorial..................................................5 1.2.1 Basic intro to Lisp for Pythonistas...............................5 1.2.2 Hy is a Lisp-flavored Python..................................7 1.2.3 Macros............................................. 12 1.2.4 Hy <-> Python interop..................................... 13 1.2.5 Protips!............................................. 14 1.3 Hy Style Guide.............................................. 14 1.3.1 Prelude............................................. 15 1.3.2 Layout & Indentation...................................... 15 1.3.3 Coding Style.......................................... 16 1.3.4 Conclusion........................................... 17 1.3.5 Thanks............................................. 17 1.4 Documentation Index.......................................... 18 1.4.1 Command Line Interface.................................... 18 1.4.2 Hy <-> Python interop..................................... 19 1.4.3 Hy (the language)........................................ 21 1.4.4 Hy Core............................................. 47 1.4.5 Reader Macros......................................... 65 1.4.6 Internal Hy Documentation................................... 66 1.5 Extra Modules Index........................................... 72 1.5.1 Anaphoric Macros....................................... 72 1.5.2
  • PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63P

    PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63P

    DOCUMENT RESUME ED 290 438 IR 012 986 AUTHOR Cunningham, Robert E.; And Others TITLE Chips: A Tool for Developing Software Interfaces Interactively. INSTITUTION Pittsburgh Univ., Pa. Learning Research and Development Center. SPANS AGENCY Office of Naval Research, Arlington, Va. REPORT NO TR-LEP-4 PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63p. PUB TYPE Reports - Research/Technical (143) EDRS PRICE MF01/PC03 Plus Postage. DESCRIPTORS *Computer Graphics; *Man Machine Systems; Menu Driven Software; Programing; *Programing Languages IDENTIF7ERS Direct Manipulation Interface' Interface Design Theory; *Learning Research and Development Center; LISP Programing Language; Object Oriented Programing ABSTRACT This report provides a detailed description of Chips, an interactive tool for developing software employing graphical/computer interfaces on Xerox Lisp machines. It is noted that Chips, which is implemented as a collection of customizable classes, provides the programmer with a rich graphical interface for the creation of rich graphical interfaces, and the end-user with classes for modeling the graphical relationships of objects on the screen and maintaining constraints between them. This description of the system is divided into five main sections: () the introduction, which provides background material and a general description of the system; (2) a brief overview of the report; (3) detailed explanations of the major features of Chips;(4) an in-depth discussion of the interactive aspects of the Chips development environment; and (5) an example session using Chips to develop and modify a small portion of an interface. Appended materials include descriptions of four programming techniques that have been sound useful in the development of Chips; descriptions of several systems developed at the Learning Research and Development Centel tsing Chips; and a glossary of key terms used in the report.
  • The Evolution of Lisp

    The Evolution of Lisp

    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.