Revised3report on the Algorithmic Language Scheme

Total Page:16

File Type:pdf, Size:1020Kb

Revised3report on the Algorithmic Language Scheme Revised Rep ort on the Algorithmic Language Scheme JONATHAN REES AND WILLIAM CLINGER Editors H ABELSON R K DYBVIG C T HAYNES G J ROZAS N I ADAMS IV D P FRIEDMAN E KOHLBECKER G J SUSSMAN D H BARTLEY R HALSTEAD D OXLEY M WAND G BROOKS C HANSON K M PITMAN Dedicated to the Memory of ALGOL CONTENTS SUMMARY Introduction The rep ort gives a dening description of the program Overview of Scheme ming language Scheme Scheme is a statically scop ed and Semantics prop erly tailrecursive dialect of the Lisp programming Syntax language invented by Guy Lewis Steele Jr and Gerald Notation and terminology Jay Sussman It was designed to have an exceptionally Lexical conventions clear and simple semantics and few dierent ways to form Identiers expressions A wide variety of programming paradigms in Whitespace and comments cluding imp erative functional and message passing styles Other notations nd convenient expression in Scheme Basic concepts The introduction oers a brief history of the language and Variables and regions of the rep ort True and false External representations The rst three chapters present the fundamental ideas of Expressions the language and describ e the notational conventions used Primitive expression types for describing the language and for writing programs in the Derived expression types language Program structure Chapters and describ e the syntax and semantics of Programs expressions programs and denitions Denitions Standard pro cedures Chapter describ es Schemes builtin pro cedures which Bo oleans include all of the languages data manipulation and in Equivalence predicates putoutput primitives Pairs and lists Chapter provides a formal syntax for Scheme written in Symbols extended BNF along with a formal denotational semantics Numbers The rep ort concludes with an example of the use of the Characters language and an alphab etic index Strings Vectors Control features Input and output Formal syntax and semantics Formal syntax Formal semantics Derived expression types Notes Example Bibliography and references Alphab etic index of denitions of concepts keywords and pro cedures Revised Scheme INTRODUCTION Programming languages should b e designed not by piling agenda for the workshop but was unable to attend the ses feature on top of feature but by removing the weaknesses sions and restrictions that make additional features app ear nec Subsequent electronic mail discussions and committee work essary Scheme demonstrates that a very small number of completed the denition of the language Gerry Sussman rules for forming expressions with no restrictions on how drafted the section on numbers Chris Hanson drafted the they are comp osed suce to form a practical and ecient sections on characters and strings and Gary Bro oks and programming language that is exible enough to supp ort William Clinger drafted the sections on input and output most of the ma jor programming paradigms in use to day William Clinger recorded the decisions of the workshop and compiled the pieces into a coherent do cument The Re Scheme has inuenced the evolution of Lisp Scheme was vised revised rep ort on Scheme was published at MIT one of the rst programming languages to incorp orate rst and Indiana University in the summer of Another class pro cedures as in the lambda calculus thereby proving round of revision in the spring of again accomplished the usefulness of static scop e rules and blo ck structure in almost entirely by electronic mail resulted in the present a dynamically typed language Scheme was the rst ma jor rep ort dialect of Lisp to distinguish pro cedures from lambda ex pressions and symbols to use a single lexical environment We intend this rep ort to b elong to the entire Scheme com for all variables and to evaluate the op erator p osition of munity and so we grant p ermission to copy it in whole or in a pro cedure call in the same way as an op erand p osition part without fee In particular we encourage implementors By relying entirely on pro cedure calls to express iteration of Scheme to use this rep ort as a starting p oint for manuals Scheme emphasized the fact that tailrecursive pro cedure and other do cumentation mo difying it as necessary calls are essentially gotos that pass arguments Scheme was the rst widely used programming language to em Acknowledgements brace rst class escap e pro cedures from which all known sequential control structures can b e synthesized A few We would like to thank the following p eople for their of these innovations have recently b een incorp orated into comments and criticisms Alan Bawden George Carrette Common Lisp while others remain to b e adopted Andy Cromarty Andy Freeman Richard Gabriel Yekta Gursel Ken Haase Paul Hudak Richard Kelsey Chris Lindblad Mark Meyer Jim Miller Jim Philbin John Background Ramsdell Guy Lewis Steele Jr Julie Sussman Perry Wa The rst description of Scheme was written in A gle Daniel Weise and Henry Wu We thank Carol Fes revised rep ort app eared in which describ ed the senden Daniel Friedman and Christopher Haynes for p er evolution of the language as its MIT implementation was mission to use text from the Scheme version reference upgraded to supp ort an innovative compiler Three manual We thank Texas Instruments Inc for p ermission distinct pro jects b egan in and to use variants to use text from the TI Scheme Language Reference Man of Scheme for courses at MIT Yale and Indiana Univer ual We gladly acknowledge the inuence of manuals for sity An introductory computer science text MIT Scheme T Scheme Common Lisp and Algol b o ok using Scheme was published in We also thank Betty Dexter for the extreme eort she put As might b e exp ected of a language used primarily for ed into setting this rep ort in T X and Donald Knuth for de E ucation and research Scheme has always evolved rapidly signing the program that caused her troubles This was no problem when Scheme was used only within The Articial Intelligence Lab oratory of the Massachusetts MIT but as Scheme b ecame more widespread lo cal di Institute of Technology and the Computer Science Depart alects b egan to diverge until students and researchers o c ment of Indiana University supp orted the preparation of casionally found it dicult to understand co de written at this rep ort Supp ort for the MIT work was provided in other sites part by the Advanced Research Pro jects Agency of the Fifteen representatives of the ma jor implementations of Department of Defense under Oce of Naval Research con Scheme therefore met in Octob er to work toward tract NC Supp ort for the Indiana Univer a b etter and more widely accepted standard for Scheme sity work was provided by NSF grants NCS and Participating in this workshop were Hal Ab elson Nor NCS man Adams David Bartley Gary Bro oks William Clinger Daniel Friedman Rob ert Halstead Chris Hanson Christo pher Haynes Eugene Kohlb ecker Don Oxley Jonathan Rees Guillermo Rozas Gerald Jay Sussman and Mitchell Wand Kent Pitman made valuable contributions to the Overview of Scheme DESCRIPTION OF THE LANGUAGE Overview of Scheme ML C and APL are three other languages that always pass arguments by value This is distinct from the lazy evaluation semantics of SASL or the callbyname seman Semantics tics of Algol where an argument expression is not eval This section gives an overview of Schemes semantics A uated unless its value is needed by the pro cedure detailed informal semantics is the sub ject of chapters through For reference purp oses section provides a Syntax formal semantics of Scheme Scheme employs a parenthesizedlist Polish notation to de Following Algol Scheme is a statically scop ed program scrib e programs and other data The syntax of Scheme ming language Each use of a variable is asso ciated with a like that of most Lisp dialects provides for great expressive lexically apparent binding of that variable p ower largely due to its simplicity An imp ortant conse Scheme has latent as opp osed to manifest types Types quence of this simplicity is the susceptibility of Scheme are asso ciated with values also called ob jects rather than programs and data to uniform treatment by other Scheme with variables Some authors refer to languages with programs As with other Lisp dialects the read primitive latent types as weakly typed or dynamically typed lan parses its input that is it p erforms syntactic as well as guages Other languages with latent types are APL lexical decomp osition of what it reads Snob ol and other dialects of Lisp Languages with mani fest types sometimes referred to as strongly typed or stat ically typed languages include Algol Pascal and C Notation and terminology All ob jects created in the course of a Scheme computation Essential and nonessential features including pro cedures and continuations have unlimited ex It is required that every implementation
Recommended publications
  • Praise for Practical Common Lisp
    Praise for Practical Common Lisp “Finally, a Lisp book for the rest of us. If you want to learn how to write a factorial function, this is not your book. Seibel writes for the practical programmer, emphasizing the engineer/artist over the scientist and subtly and gracefully implying the power of the language while solving understandable real-world problems. “In most chapters, the reading of the chapter feels just like the experience of writing a program, starting with a little understanding and then having that understanding grow, like building the shoulders upon which you can then stand. When Seibel introduced macros as an aside while building a test frame- work, I was shocked at how such a simple example made me really ‘get’ them. Narrative context is extremely powerful, and the technical books that use it are a cut above. Congrats!” —Keith Irwin, Lisp programmer “While learning Lisp, one is often referred to the CL HyperSpec if they do not know what a particular function does; however, I found that I often did not ‘get it’ just by reading the HyperSpec. When I had a problem of this manner, I turned to Practical Common Lisp every single time—it is by far the most readable source on the subject that shows you how to program, not just tells you.” —Philip Haddad, Lisp programmer “With the IT world evolving at an ever-increasing pace, professionals need the most powerful tools available. This is why Common Lisp—the most powerful, flexible, and stable programming language ever—is seeing such a rise in popu- larity.
    [Show full text]
  • 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.
    [Show full text]
  • Why Rapid Prototyping? the Use of Rapid Prototyping Enables Early Review and Earlier Discovery of Problems
    Accelerating Hindsight Lisp as a Vehicle for Rapid Prototyping From time to time, I meet people who really like Lisp but who ,~,~,,~-'~r~7 e" find themselves at a loss for words when trying to articulate to -'~,, others the various reasons why. For example, many people agree that good support for rapid prototyping is a key strength of Lisp. But what is rapid prototyping and how exactly is it that Lisp supports it better than other languages? In this article, I will survey the various reasons that I think Lisp--particularly Common Lisp--is good for rapid prototyping. I hope to show that there is a sound reason for the warm feeling many show toward Lisp, even when the words of explanation don't flow readily off the tongue. I also hope this is information you can use to strengthen the case for new or continued use of Lisp at your workplace. Although the focus in this paper is Common Lisp, many of the issues raised are general to the entire Lisp family of languages. Why Rapid Prototyping? The use of rapid prototyping enables early review and earlier discovery of problems. The sooner you get feedback, the more time you have to fix things and the higher the quality of the final product. Hindsight is 20-20 "As soon as I finished the project, I knew what I shouldhave done instead." This familiar refrain is the genesis of the desire to build prototypes. If there's one thing that's certain, it's that hindsight is always better than foresight.
    [Show full text]
  • Knee-Jerk Anti-Loopism and Other E-Mail Phenomena: Oral, Written, and Electronic Patterns in Computer-Mediated Communication
    Knee-jerk Anti-LOOPism and other E-mail Phenomena: Oral, Written, and Electronic Patterns in Computer-Mediated Communication by JoAnne Yates Wanda J. Orlikowski WP #3578-93 June 1993 Knee-jerk Anti-LOOPism and other E-mail Phenomena: Oral, Written, and Electronic Patterns in Computer-Mediated Communication JoAnne Yates Sloan School of Management Massachusetts Institute of Technology 50 Memorial Drive (E52-545) Cambridge, MA 02139 (617) 253-7157 [email protected] Wanda J. Orlikowski Sloan School of Management Massachusetts Institute of Technology 50 Memorial Drive (E53-329) Cambridge, MA 02139 (617) 253-0443 [email protected] June 1993 To be presented at the 53rd Annual Meeting of the Academy of Management, Atlanta, GA: August 1993. ACKNOWLEDGMENTS The authors would like to thank Miriam Oh for her dedicated research assistance, and Craig Murphy for his generous advice. Thanks are also due to the Common LISP members who participated in our study, to Jim Hollan who helped us locate the Common LISP archive, and to Kent Pitman who provided helpful comments on an earlier version of this paper. The research support of the Center for Coordination Science at the Massachusetts Institute of Technology is gratefully acknowledged. Both authors contributed equally to this paper. III Knee-jerk Anti-LOOPism and other E-mail Phenomena: Oral, Written, and Electronic Patterns in Computer-Mediated Communication Abstract This paper reports on an empirical investigation into the on-going electronic interaction of a natural distributed group. Prior organizational research into use of electronic media has focused primarily on usage patterns and only occasionally on a few linguistic features, while linguistics researchers have looked more closely at certain technical aspects of language use in electronic communication.
    [Show full text]
  • Tutorial on Good Lisp Programming Style
    Lisp Users and Vendors Conference August Tutorial on Go o d Lisp Programming Style Peter Norvig Sun Microsystems Labs Inc Kent Pitman Harlequin Inc c Portions copyright Peter Norvig c Portions copyright Kent M Pitman All Rights Reserved Outline What is Go o d Style Tips on BuiltIn Functionality Tips on NearStandard Tools Kinds of Abstraction Programming in the Large Miscellaneous What is Go o d Style Good Lisp Programming Style Elegance is not optional Richard A OKeefe Good style in any language leads to programs that are Understandable Reusable Extensible Ecient Easy to developdebug It also helps correctness robustness compatibility Our maxims of go o d style are Be explicit Be sp ecic Be concise Be consistent Be helpful anticipate the readers needs Be conventional dont b e obscure Build abstractions at a usable level Allow to ols to interact referential transparency Good style is the underware that supp ortsaprogram Where do es go o d style come from What To Believe Dont b elieve everything we tell you Just most Worry less ab out what to b elieve and more ab out why Know where your Style Rules come from Religion Go o d vs Evil This way is b etter Philosophy This is consistent with other things Robustness Liability Safety Ethics Ill put in redundant checks to avoid something horrible Legality Our lawyers say do it this way Personality Opinion I like it this way Compatibility Another to ol exp ects this way Portability Other compilers prefer this way Co op eration Convention It has to be done some
    [Show full text]
  • The Renderx Tribune
    The RenderX Tribune RenderX News Lisp, the Programming Language W3C News 2006-05-15 2006-07-14 XEP 4.6 with AFP output Semantic Web Activity released. RenderX has re- "Lisp is a programmable program- A paper titled Common Lisp: Myths Grows to Include GRD- leased XEP 4.6, a new ver- ming language." -John Foderaro and Legends tries to confront and DL, Deployment Work- sion of its XSL processor dispel some of the myths and mistak- ing Groups W3C is and accompanying tools. en impressions associated with Lisp. pleased to announce the re- The new version intro- The paper promotes Xanalys©s Lisp newal of the Semantic duces AFP backend (avail- What is Lisp? products, but most of the arguments Web Activity. "W3C con- able with a special li- ISP is an acronym for LISt Pro- apply to other Common Lisp imple- tinues to support the ad- cense), improved line- Lcessing. Its development history mentations as well. vancement of universal breaking algorithm confor- has often been associated with sym- Kent Pitman©s More Than Just sharing and automatic pro- mant to the Unicode Stan- bolic processing and with both com- Words: Lambda, the Ultimate Politi- cessing of data in the dard Annex #14, and a puterandhumanlanguages.Ahetero- cal Party argues that Lisp is better World Wide Web," said new implementation of geneous list data type has always defined as its community than as its Ivan Herman (W3C). Se- XSL 1.1 change bars. been built into the language in order various specifications. mantic Web technologies XEPwin 2.0 has also been to efficiently deal with arbitrary and Lisp may be combined with other allow data to be shared and updated and includes XEP changing models.
    [Show full text]
  • Abcl-1.5.0-Rc-0.Pdf
    Armed Bear Common Lisp User Manual Mark Evenson Erik H¨ulsmann Rudolf Schlatte Alessio Stalla Ville Voutilainen Version 1.5.0-rc-0 June 2017 2 Contents 0.0.1 Preface to the Sixth Edition...........................4 0.0.2 Preface to the Fifth Edition...........................4 0.0.3 Preface to the Fourth Edition..........................4 0.0.4 Preface to the Third Edition..........................4 0.0.5 Preface to the Second Edition..........................5 1 Introduction 7 1.1 Conformance.......................................7 1.1.1 ANSI Common Lisp...............................7 1.1.2 Contemporary Common Lisp..........................8 1.2 License...........................................8 1.3 Contributors.......................................8 2 Running ABCL9 2.1 Options..........................................9 2.2 Initialization....................................... 10 3 Interaction with the Hosting JVM 11 3.1 Lisp to Java........................................ 11 3.1.1 Low-level Java API................................ 11 3.2 Java to Lisp........................................ 13 3.2.1 Calling Lisp from Java.............................. 13 3.3 Java Scripting API (JSR-223).............................. 15 3.3.1 Conversions.................................... 16 3.3.2 Implemented JSR-223 interfaces........................ 16 3.3.3 Start-up and configuration file......................... 16 3.3.4 Evaluation.................................... 17 3.3.5 Compilation.................................... 17 3.3.6 Invocation of
    [Show full text]
  • Graduate Catalog Lindenwood University•Saint Charles, Missouri Established 1827 Graduate Academic Programs
    2010/2011 Graduate Catalog Lindenwood University•Saint Charles, Missouri Established 1827 Graduate Academic Programs Listed By Program Graduate Degrees Listed By Degree Semester Schedule American Studies — American Studies, M.A. Master of Arts in American Studies Business — Accounting, M.B.A., M.S. Master of Arts in Arts Management (Art, Theatre) Business — Entrepreneurial Studies, M.B.A. Master of Arts in Education Business — Finance, M.B.A., M.S. Master of Arts in Education with Character Education Emphasis Business — Human Resource Management, M.B.A., M.S. Master of Arts in Education with Business — International Business, M.B.A., M.S. Educational Technology Emphasis Business — Management, M.B.A. Master of Arts in Education with Interpretation Emphasis Business — Marketing, M.B.A., M.S. Master of Arts in Education with Library Media Certification Business — Management Information Systems, M.B.A., M.S. Master of Arts in School Administration Business — Sport Management, M.A. Master of Arts in Studio Art Communications — Communications, M.A. Master of Arts in Teaching Education — Counseling, M..A. Master of Arts in Theatre Education — Education, M.A. Master of Fine Arts in Studio Art Education — Education with Character Educ. Emphasis, M.A. Master of Arts in Communication Education—Education with Educational Technology Master of Fine Arts in Theatre Emphasis, M.A. Master of Arts in Counseling Education — Education with Interpretation Emphasis, M.A. Master of Science in Human Performance Education — Education with Library Media Cert., M.A. School Psychological Examiner Certification Education —School Administration, M.A. Ed.S. in Instructional Leadership Education — School Administration, Ed.S, Ed.S.
    [Show full text]
  • 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.
    [Show full text]
  • A Pattern of Language Evolution
    A Pattern of Language Evolution Richard P. Gabriel IBM Research Guy L. Steele Jr. Sun Laboratories Preface ization, either formal or informal. Consolidation, when most successful, results in a stable development platform. In 1992 when we completed our first draft of the History The cycle is not inexorable: the process can break down, of Programming Languages II paper, The Evolution of Lisp stop and start, and cycles can be skipped. But it is possible [1], it included sections on a theory or model of how com- to view the process of evolution at any point as being within plex language families like Lisp grew and evolved, and in one of these stages of the cycle, with the goal of moving to particular, how and when diversity would bloom and con- the next stage. solidation would prune. The historian who worked with all Each stage can be characterized by the conditions that the HOPL II authors, Michael S. Mahoney, did not believe allow it to be entered. our theory was substantiated properly, so he recommend- ed removing the material and sticking with the narrative Conditions for Acceptance of Lisp’s evolution. We stopped working on those sections, but they remained in the original text sources but removed The most critical stage is acceptance. This stage determines with conditionals. which language features and paradigms will be part of the Although the uncut version of the paper is published on- next stage of stable development. The conditions for ac- line [2], the theory was never officially published. This short ceptance are being on the right machines, fitting into local paper is the publication of that material.
    [Show full text]
  • Hygiene for the Unhygienic Hygiene-Compatible Macros in an Unhygienic Macro System
    Hygiene for the Unhygienic Hygiene-Compatible Macros in an Unhygienic Macro System Pascal Costanza and Theo D'Hondt (Vrije Universiteit Brussel [email protected] and Theo.D'[email protected]) Abstract: It is known that the essential ingredients of a Lisp-style unhygienic macro system can be expressed in terms of advanced hygienic macro systems. We show that the reverse is also true: We present a model of a core unhygienic macro system, on top of which a hygiene-compatible macro system can be built, without changing the internals of the core macro system and without using a code walker. To achieve this, the internal representation of source code as Lisp s-expressions does not need to be changed. The major discovery is the fact that symbol macros can be used in conjunction with local macro environments to bootstrap a hygiene-compatible macro system. We also discuss a proof-of-concept implementation in Common Lisp and give some historical notes. 1 Introduction Macros are local program transformations triggered explicitly in the source code of a program. Since their introduction into Lisp in 1963 [Hart 63], they have found their way into many Lisp dialects, since Lisp is especially attractive for macros due to its homoiconic nature: The source code of Lisp programs is con- structed from s-expressions, that is lists, symbols and (literal) values, which are all core data types of Lisp itself [Kay 69, McIlroy 60]. Lisp macros can therefore simply be expressed as functions that map s-expressions to s-expressions. Since the initial macro systems for Lisp have operated on \raw" s-expressions, variable names that are introduced and/or referenced in the result of a macroex- pansion are susceptible to inadvertent capture by introductions and/or references in the surrounding code of the macro invocation.
    [Show full text]
  • Revised6report on the Algorithmic Language Scheme
    Revised6 Report on the Algorithmic Language Scheme MICHAEL SPERBER R. KENT DYBVIG,MATTHEW FLATT,ANTON VAN STRAATEN (Editors) RICHARD KELSEY,WILLIAM CLINGER,JONATHAN REES (Editors, Revised 5 Report on the Algorithmic Language Scheme) ROBERT BRUCE FINDLER,JACOB MATTHEWS (Authors, formal semantics) 26 September 2007 SUMMARY The report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have an exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including functional, imperative, and message passing styles, find convenient expression in Scheme. This report is accompanied by a report describing standard libraries [24]; references to this document are identified by designations such as “library section” or “library chapter”. It is also accompanied by a report containing non-normative appendices [22]. A fourth report gives some historical background and rationales for many aspects of the language and its libraries [23]. The individuals listed above are not the sole authors of the text of the report. Over the years, the following individuals were involved in discussions contributing to the design of the Scheme language, and were listed as authors of prior reports: Hal Abelson, Norman Adams, David Bartley, Gary Brooks, William Clinger, R. Kent Dybvig, Daniel Friedman, Robert Halstead, Chris Hanson, Christopher Haynes, Eugene Kohlbecker, Don Oxley, Kent Pitman, Jonathan Rees, Guillermo Rozas, Guy L. Steele Jr., Gerald Jay Sussman, and Mitchell Wand. In order to highlight recent contributions, they are not listed as authors of this version of the report.
    [Show full text]