============================= -*- Mode: view -*- ============================== =============================================================================== +----------------------------------+ | | | Guy L. Steele Jr. | | | | C O M M O N | | | | ## ###### #### ##### | | ## ## ## ## ## ## | | ## ## ## ## ## | | ## ## ## ##### | | ## ## ## ## | | ## ## ## ## ## | | ###### ###### #### ## | | | | +-----------------+ | | | Text Version by | | | | | | | | Eli Barzilay: | | | | | | | | Maze is Life! | | | | | | | | eli@barzilay.org| | | | 11/9/95| | | +-----------------+ | | | | THE LANGUAGE | | ------------- | | SECOND EDITION | | | +----------------------------------+ This is a text version of the book, it was made manually and therefore should not suffer from automatic conversions limitations - it should all be readable, including mathematical equations which were written to be understood and not to be printed. There are no fonts notations, its all simple text (which could be read or searched) - there are probably places where understanding is harder due to this - it isn't a replacement for the textbook. Use Emacs for best results (and for fun) - there are very uniform patterns that you can use - like functions headers, chapter/section headers, implementation notes, figures, X3J13 votes etc. This file is too big for some editors, splitting it should not be much trouble. Bugs, comments & requests are welcome - eli@barzilay.org. Eli Barzilay: Maze is Life! =============================================================================== C o m m o n L i s p T h e L a n g u a g e Second Edition Guy L. Steele Jr. -- Thinking Machines Corporation with contributions by Scott E. Fahlman -- Carnegie-Mellon University Richard P. Gabriel -- Lucid, Inc., Stanford University David A. Moon -- Symbolics, Incorporated Daniel L. Weinreb -- Symbolics, Incorporated and with contributions to the second edition by Kent M. Pitman -- Symbolics, Incorporated Richard C. Waters -- Massachusetts Institute of Technology Jon L White -- Lucid, Inc. copyright 1984, 1989 Guy L. Steele Jr. All rights reserved. To be published by Digital Press. Would it be wonderful if, under the pressure of all these difficulties, the Convention should have been forced into some deviations from that artificial structure and regular symmetry which an abstract view of the subject might lead an ingenious theorist to bestow on a constitution planned in his closet or in his imagination? -- James Madison, The Federalist No. 37, January 11, 1788 =============================================================================== <#### Preface (Second Edition) ####> <#### Acknowledgments (Second Edition) ####> <#### Acknowledgments (First Edition) ####> 1. <#### Introduction ####> 1.1. <### Purpose ###> 1.2. <### Notational Conventions ###> 1.2.1. <## Decimal Numbers ##> 1.2.2. <## Nil, False, and the Empty List ##> 1.2.3. <## Evaluation, Expansion, and Equivalence ##> 1.2.4. <## Errors ##> 1.2.5. <## Descriptions of Functions and Other Entities ##> 1.2.6. <## The Lisp Reader ##> 1.2.7. <## Overview of Syntax ##> 2. <#### Data Types ####> 2.1. <### Numbers ###> 2.1.1. <## Integers ##> 2.1.2. <## Ratios ##> 2.1.3. <## Floating-Point Numbers ##> 2.1.4. <## Complex Numbers ##> 2.2. <### Characters ###> 2.2.1. <## Standard Characters ##> 2.2.2. <## Line Divisions ##> 2.2.3. <## Non-standard Characters ##> 2.2.4. <## Character Attributes ##> 2.2.5. <## String Characters ##> 2.3. <### Symbols ###> 2.4. <### Lists and Conses ###> 2.5. <### Arrays ###> 2.5.1. <## Vectors ##> 2.5.2. <## Strings ##> 2.5.3. <## Bit-Vectors ##> 2.6. <### Hash Tables ###> 2.7. <### Readtables ###> 2.8. <### Packages ###> 2.9. <### Pathnames ###> 2.10. <### Streams ###> 2.11. <### Random-States ###> 2.12. <### Structures ###> 2.13. <### Functions ###> 2.14. <### Unreadable Data Objects ###> 2.15. <### Overlap, Inclusion, and Disjointness of Types ###> 3. <#### Scope and Extent ####> 4. <#### Type Specifiers ####> 4.1. <### Type Specifier Symbols ###> 4.2. <### Type Specifier Lists ###> 4.3. <### Predicating Type Specifiers ###> 4.4. <### Type Specifiers That Combine ###> 4.5. <### Type Specifiers That Specialize ###> 4.6. <### Type Specifiers That Abbreviate ###> 4.7. <### Defining New Type Specifiers ###> 4.8. <### Type Conversion Function ###> 4.9. <### Determining the Type of an Object ###> 4.10. <### Type Upgrading ###> 5. <#### Program Structure ####> 5.1. <### Forms ###> 5.1.1. <## Self-Evaluating Forms ##> 5.1.2. <## Variables ##> 5.1.3. <## Special Forms ##> 5.1.4. <## Macros ##> 5.1.5. <## Function Calls ##> 5.2. <### Functions ###> 5.2.1. <## Named Functions ##> 5.2.2. <## Lambda-Expressions ##> 5.3. <### Top-Level Forms ###> 5.3.1. <## Defining Named Functions ##> 5.3.2. <## Declaring Global Variables and Named Constants ##> 5.3.3. <## Control of Time of Evaluation ##> 6. <#### Predicates ####> 6.1. <### Logical Values ###> 6.2. <### Data Type Predicates ###> 6.2.1. <## General Type Predicates ##> 6.2.2. <## Specific Data Type Predicates ##> 6.3. <### Equality Predicates ###> 6.3. <### Logical Operators ###> 7. <#### Control Structure ####> 7.1. <### Constants and Variables ###> 7.1.1. <## Reference ##> 7.1.2. <## Assignment ##> 7.2. <### Generalized Variables ###> 7.3. <### Function Invocation ###> 7.4. <### Simple Sequencing ###> 7.5. <### Establishing New Variable Bindings ###> 7.6. <### Conditionals ###> 7.7. <### Blocks and Exits ###> 7.8. <### Iteration ###> 7.8.1. <## Indefinite Iteration ##> 7.8.2. <## General Iteration ##> 7.8.3. <## Simple Iteration Constructs ##> 7.8.4. <## Mapping ##> 7.8.5. <## The "Program Feature" ##> 7.9. <### Structure Traversal and Side Effects ###> 7.10. <### Multiple Values ###> 7.10.1. <## Constructs for Handling Multiple Values ##> 7.10.2. <## Rules Governing the Passing of Multiple Values ##> 7.11. <### Dynamic Non-Local Exits ###> 8. <#### Macros ####> 8.1. <### Macro Definition ###> 8.2. <### Macro Expansion ###> 8.3. <### Destructuring ###> 8.4. <### Compiler Macros ###> 8.5. <### Environments ###> 9. <#### Declarations ####> 9.1. <### Declaration Syntax ###> 9.2. <### Declaration Specifiers ###> 9.3. <### Type Declaration for Forms ###> 10. <#### Symbols ####> 10.1. <### The Property List ###> 10.2. <### The Print Name ###> 10.3. <### Creating Symbols ###> 11. <#### Packages ####> 11.1. <### Consistency Rules ###> 11.2. <### Package Names ###> 11.3. <### Translating Strings to Symbols ###> 11.4. <### Exporting and Importing Symbols ###> 11.5. <### Name Conflicts ###> 11.6. <### Built-in Packages ###> 11.7. <### Package System Functions and Variables ###> 11.8. <### Modules ###> 11.9. <### An Example ###> 12. <#### Numbers ####> 12.1. <### Precision, Contagion, and Coercion ###> 12.2. <### Predicates on Numbers ###> 12.3. <### Comparisons on Numbers ###> 12.4. <### Arithmetic Operations ###> 12.5. <### Irrational and Transcendental Functions ###> 12.5.1. <## Exponential and Logarithmic Functions ##> 12.5.2. <## Trigonometric and Related Functions ##> 12.5.3. <## Branch Cuts, Principal Values, and Boundary Conditions in the Complex Plane ##> 12.6. <### Type Conversions and Component Extractions on Numbers ###> 12.7. <### Logical Operations on Numbers ###> 12.8. <### Byte Manipulation Functions ###> 12.9. <### Random Numbers ###> 12.10. <### Implementation Parameters ###> 13. <#### Characters ####> 13.1. <### Character Attributes ###> 13.2. <### Predicates on Characters ###> 13.3. <### Character Construction and Selection ###> 13.4. <### Character Conversions ###> 13.5. <### Character Control-Bit Functions ###> 14. <#### Sequences ####> 14.1. <### Simple Sequence Functions ###> 14.2. <### Concatenating, Mapping, and Reducing Sequences ###> 14.3. <### Modifying Sequences ###> 14.4. <### Searching Sequences for Items ###> 14.5. <### Sorting and Merging ###> 15. <#### Lists ####> 15.1. <### Conses ###> 15.2. <### Lists ###> 15.3. <### Alteration of List Structure ###> 15.4. <### Substitution of Expressions ###> 15.5. <### Using Lists as Sets ###> 15.6. <### Association Lists ###> 16. <#### Hash Tables ####> 16.1. <### Hash Table Functions ###> 16.2. <### Primitive Hash Function ###> 17. <#### Arrays ####> 17.1. <### Array Creation ###> 17.2. <### Array Access ###> 17.3. <### Array Information ###> 17.4. <### Functions on Arrays of Bits ###> 17.5. <### Fill Pointers ###> 17.6. <### Changing the Dimensions of an Array ###> 18. <#### Strings ####> 18.1. <### String Access ###> 18.2. <### String Comparison ###> 18.3. <### String Construction and Manipulation ###> 19. <#### Structures ####> 19.1. <### Introduction to Structures ###> 19.2. <### How to Use Defstruct ###> 19.3. <### Using the Automatically Defined Constructor Function ###> 19.4. <### Defstruct Slot-Options ###> 19.5. <### Defstruct Options ###> 19.6. <### By-Position Constructor Functions ###> 19.7. <### Structures of Explicitly Specified Representational Type ###> 19.7.1. <## Unnamed Structures ##> 19.7.2. <## Named Structures ##> 19.7.3. <## Other Aspects of Explicitly Specified Structures ##> 20. <#### The Evaluator ####> 20.1. <### Run-Time Evaluation of Forms ###> 20.2. <### The Top-Level Loop ###> 21. <#### Streams ####> 21.1. <### Standard Streams ###> 21.2. <### Creating New Streams ###> 21.3. <### Operations on Streams ###> 22. <#### Input/Output ####> 22.1. <### Printed Representation of Lisp Objects ###> 22.1.1. <## What the Read Function Accepts ##> 22.1.2. <## Parsing of Numbers and Symbols ##> 22.1.3. <## Macro Characters ##> 22.1.4. <## Standard Dispatching Macro Character Syntax ##> 22.1.5. <## The Readtable ##> 22.1.6. <## What the Print Function Produces ##> 22.2. <### Input Functions ###> 22.2.1. <## Input from Character Streams ##> 22.2.2. <## Input from Binary Streams ##> 22.3. <### Output Functions ###> 22.3.1. <## Output to Character Streams ##> 22.3.2. <## Output to Binary Streams ##> 22.3.3. <## Formatted Output to Character Streams ##> 22.4. <### Querying the User ###> 23. <#### File System Interface ####> 23.1. <### File Names ###> 23.1.1. <## Pathnames ##> 23.1.2. <## Case Conventions ##> 23.1.3. <## Structured Directories ##> 23.1.4. <## Extended Wildcards ##> 23.1.5. <## Logical Pathnames ##> 23.1.5.1. <# Syntax of Logical Pathname Namestrings #> 23.1.5.2. <# Parsing of Logical Pathname Namestrings #> 23.1.5.3. <# Using Logical Pathnames #> 23.1.5.4. <# Examples of the Use of Logical Pathnames #> 23.1.5.5. <# Discussion of Logical Pathnames #> 23.1.6. <## Pathname Functions ##> 23.2. <### Opening and Closing Files ###> 23.3. <### Renaming, Deleting, and Other File Operations ###> 23.4. <### Loading Files ###> 23.5. <### Accessing Directories ###> 24. <#### Errors ####> 24.1. <### General Error-Signaling Functions ###> 24.2. <### Specialized Error-Signaling Forms and Macros ###> 24.3. <### Special Forms for Exhaustive Case Analysis ###> 25. <#### Miscellaneous Features ####> 25.1. <### The Compiler ###> 25.1.1. <## Compiler Diagnostics ##> 25.1.2. <## Compiled Functions ##> 25.1.3. <## Compilation Environment ##> 25.1.4. <## Similarity of Constants ##> 25.2. <### Documentation ###> 25.3. <### Debugging Tools ###> 25.4. <### Environment Inquiries ###> 25.4.1. <## Time Functions ##> 25.4.2. <## Other Environment Inquiries ##> 25.5. <### Identity Function ###> 26. <#### Loop ####> 26.1. <### Introduction ###> 26.2. <### How the Loop Facility Works ###> 26.3. <### Parsing Loop Clauses ###> 26.3.1. <## Order of Execution ##> 26.3.2. <## Kinds of Loop Clauses ##> 26.3.3. <## Loop Syntax ##> 26.4. <### User Extensibility ###> 26.5. <### Loop Constructs ###> 26.6. <### Iteration Control ###> 26.7. <### End-Test Control ###> 26.8. <### Value Accumulation ###> 26.9. <### Variable Initializations ###> 26.10. <### Conditional Execution ###> 26.11. <### Unconditional Execution ###> 26.12. <### Miscellaneous Features ###> 26.12.1. <## Data Types ##> 26.12.2. <## Destructuring ##> 27. <#### Pretty Printing ####> 27.1. <### Introduction ###> 27.2. <### Pretty Printing Control Variables ###> 27.3. <### Dynamic Control of the Arrangement of Output ###> 27.4. <### Format Directive Interface ###> 27.5. <### Compiling Format Control Strings ###> 27.6. <### Pretty Printing Dispatch Tables ###> 28. <#### Common Lisp Object System ####> 28.1. <### Programmer Interface Concepts ###> 28.1.1. <## Error Terminology ##> 28.1.2. <## Classes ##> 28.1.2.1. <# Defining Classes #> 28.1.2.2. <# Creating Instances of Classes #> 28.1.2.3. <# Slots #> 28.1.2.4. <# Accessing Slots #> 28.1.3. <## Inheritance ##> 28.1.3.1. <# Inheritance of Methods #> 28.1.3.2. <# Inheritance of Slots and Slot Options #> 28.1.3.3. <# Inheritance of Class Options #> 28.1.3.4. <# Examples #> 28.1.4. <## Integrating Types and Classes ##> 28.1.5. <## Determining the Class Precedence List ##> 28.1.5.1. <# Topological Sorting #> 28.1.5.2. <# Examples #> 28.1.6. <## Generic Functions and Methods ##> 28.1.6.1. <# Introduction to Generic Functions #> 28.1.6.2. <# Introduction to Methods #> 28.1.6.3. <# Agreement on Parameter Specializers and Qualifiers #> 28.1.6.4. <# Congruent Lambda-Lists for All Methods of a Generic Function #> 28.1.6.5. <# Keyword Arguments in Generic Functions and Methods #> 28.1.7. <## Method Selection and Combination ##> 28.1.7.1. <# Determining the Effective Method #> 28.1.7.2. <# Standard Method Combination #> 28.1.7.3. <# Declarative Method Combination #> 28.1.7.4. <# Built-in Method Combination Types #> 28.1.8. <## Meta-objects ##> 28.1.8.1. <# Metaclasses #> 28.1.8.2. <# Standard Metaclasses #> 28.1.8.3. <# Standard Meta-objects #> 28.1.9. <## Object Creation and Initialization ##> 28.1.9.1. <# Initialization Arguments #> 28.1.9.2. <# Declaring the Validity of Initialization Arguments #> 28.1.9.3. <# Defaulting of Initialization Arguments #> 28.1.9.4. <# Rules for Initialization Arguments #> 28.1.9.5. <# Shared-Initialize #> 28.1.9.6. <# Initialize-Instance #> 28.1.9.7. <# Definitions of Make-Instance and Initialize-Instance #> 28.1.10. <## Redefining Classes ##> 28.1.10.1. <# Modifying the Structure of Instances #> 28.1.10.2. <# Initializing Newly Added Local Slots #> 28.1.10.3. <# Customizing Class Redefinition #> 28.1.10.4. <# Extensions #> 28.1.11. <## Changing the Class of an Instance ##> 28.1.11.1. <# Modifying the Structure of an Instance #> 28.1.11.2. <# Initializing Newly Added Local Slots #> 28.1.11.3. <# Customizing the Change of Class of an Instance #> 28.1.12. <## Reinitializing an Instance ##> 28.1.12.1. <# Customizing Reinitialization #> 28.2. <### Functions in the Programmer Interface ###> 29. <#### Conditions ####> 29.1. <### Introduction ###> 29.2. <### Changes in Terminology ###> 29.3. <### Survey of Concepts ###> 29.3.1. <## Signaling Errors ##> 29.3.2. <## Trapping Errors ##> 29.3.3. <## Handling Conditions ##> 29.3.4. <## Object-Oriented Basis of Condition Handling ##> 29.3.5. <## Restarts ##> 29.3.6. <## Anonymous Restarts ##> 29.3.7. <## Named Restarts ##> 29.3.8. <## Restart Functions ##> 29.3.9. <## Comparison of Restarts and Catch/Throw ##> 29.3.10. <## Generalized Restarts ##> 29.3.11. <## Interactive Condition Handling ##> 29.3.12. <## Serious Conditions ##> 29.3.13. <## Non-Serious Conditions ##> 29.3.14. <## Condition Types ##> 29.3.15. <## Signaling Conditions ##> 29.3.16. <## Resignaling Conditions ##> 29.3.17. <## Condition Handlers ##> 29.3.18. <## Printing Conditions ##> 29.4. <### Program Interface to the Condition System ###> 29.4.1. <## Signaling Conditions ##> 29.4.2. <## Assertions ##> 29.4.3. <## Exhaustive Case Analysis ##> 29.4.4. <## Handling Conditions ##> 29.4.5. <## Defining Conditions ##> 29.4.6. <## Creating Conditions ##> 29.4.7. <## Establishing Restarts ##> 29.4.8. <## Finding and Manipulating Restarts ##> 29.4.9. <## Warnings ##> 29.4.10. <## Restart Functions ##> 29.4.11. <## Debugging Utilities ##> 29.5. <### Predefined Condition Types ###> Appendix A. <#### Series ####> A.1. <### Introduction ###> A.2. <### Series Functions ###> A.2.1. <## Scanners ##> A.2.2. <## Mapping ##> A.2.3. <## Truncation and Other Simple Transducers ##> A.2.4. <## Conditional and Other Complex Transducers ##> A.2.5. <## Collectors ##> A.2.6. <## Alteration of Series ##> A.3. <### Optimization ###> A.3.1. <## Basic Restrictions ##> A.3.2. <## Constraint Cycles ##> A.3.3. <## Defining New Series Functions ##> A.3.4. <## Declarations ##> A.4. <### Primitives ###> Appendix B. <#### Generators and Gatherers ####> B.1. <### Introduction ###> B.2. <### Generators ###> B.3. <### Gatherers ###> B.4. <### Discussion ###> Appendix C. <#### Backquote ####> <#### References ####> <#### Index of X3J13 Votes ####> =============================================================================== <#### Preface (Second Edition) ####> Common Lisp has succeeded. Since publication of the first edition of this book in 1984, many implementors have used it as a de facto standard for Lisp implementation. As a result, it is now much easier to port large Lisp programs from one implementation to another. Common Lisp has proved to be a useful and stable platform for rapid prototyping and systems delivery in artificial intelligence and other areas. With experience gained in using Common Lisp for so many applications, implementors found no shortage of opportunities for innovation. One of the important characteristics of Lisp is its good support for experimental extension of the language; while Common Lisp has been stable, it has not stagnated. The 1984 definition of Common Lisp was imperfect and incomplete. In some cases this was inadvertent: some odd boundary situation was overlooked and its consequences not specified, or different passages in were conflict, or some property of Lisp was so well-known and traditionally relied upon that I forgot to write it down. In other cases the informal committee that was defining Common Lisp could not settle on a solution, and therefore agreed to leave some important aspect of the language unspecified rather than choose a less than satisfactory definition. An example is error handling; 1984 Common Lisp had plenty of ways to signal errors but no way for a program to trap or process them. Over the next year I collected reports of errors in the book and gaps in the language. In December 1985, a group of implementors and users met in Boston to discuss the state of Common Lisp. I prepared two lists for this meeting, one of errata and clarifications that I thought would be relatively uncontroversial (boy, was I wrong!) and one of more substantial changes I thought should be considered and perhaps voted upon. Others also brought proposals to discuss. It became clear to everyone that there was now enough interest in Common Lisp, and dependence on its stability, that a more formal mechanism was needed for managing changes to the language. This realization led to the formation of X3J13, a subcommittee of ANSI committee X3, to produce a formal American National Standard for Common Lisp. That process is nearing completion. X3J13 has completed the bulk of its technical work in rectifying the 1984 definition and codifying extensions to that definition that have received widespread use and approval. A draft standard is now being prepared; it will probably be available in 1990. There will then be a period (required by ANSI) for public review. X3J13 must then consider the comments it receives and respond appropriately. If the comments result in substantial changes to the draft standard, multiple public review periods may be required before the draft can be approved as an American National Standard. Fortunately, X3J13 has done an outstanding job of documenting its work. For every change that came to a formal vote, a document was prepared that described the problem to be solved and one or more solutions. For each solution there is a detailed proposal for changing the language; a rationale; test cases that distinguish the proposal from the status quo or from other proposals for solving that problem; discussions of current practice, cost to implementors, cost to users, cost of not adopting the proposal, benefits of adoption, aesthetic criteria; and any relevant informal discussion that may have preceded creation of the formal proposal. All of these proposal documents were made available on-line as well as in paper form. By my count, by June 1989 some 186 such proposals were approved as language changes. (This count does not include many proposals that came before the committee but were rejected.) The purpose of this second edition is to bridge the gap between the first edition and the forthcoming ANSI standard for Common Lisp. Because of the requirement for formal public review, it will be some time yet before the ANSI standard is final. This book in no way resembles the forthcoming standard (which is being written independently by Kathy Chapman of Digital Equipment Corporation with assistance from the X3J13 Drafting Subcommittee). I have incorporated into this second edition a great deal of material based on the votes of X3J13, in order to give the reader a picture of where the language is heading. My purpose here is not simply to quote the X3J13 documents verbatim but to paraphrase them and relate them to the structure of the first edition. A single vote by X3J13 may be discussed in many parts of this book, and a single passage of this book may be affected by many of the votes. I wish to be very clear: this book is not an official document of X3J13, though it is based on publicly available material produced by X3J13. In no way does this book constitute a definitive description of the forthcoming ANSI standard. The committee's decisions have been remarkably stable (it has rescinded earlier decisions only two or three times), and I do not expect radical changes in direction. Nevertheless, it is quite probable that the draft standard will be substantively revised in response to editorial review or public comment. I have therefore reported here on the actions of X3J13 not to inscribe them in stone, but to make clear how the language of the first edition is likely to change. I have tried to be careful in my wording to avoid saying "the language has been changed" and to state simply that "X3J13 voted at such- and-so time to make the following change." Until the day when an official ANSI Common Lisp standard emerges, it is likely that the 1984 definition of Common Lisp will continue to be used widely. This book has been designed to be used as a reference both to the 1984 definition and to the language as modified by the actions of X3J13. It contains the entire text of the first edition of "Common Lisp: The Language", with corrections and minor editorial changes; however, more than half of the material in this edition is new. All new material is identified by solid lines in the left margin. Dotted lines in the left margin indicate material from the first edition that applies to the 1984 definition but that has been modified by a vote of X3J13. Modifications to these outmoded passages are explained by preceding or following text (which will have a solid line in the margin). In summary: * To use the 1984 language definition, read all material that does not have a solid line in the margin. * To use the updated language definition, read everything, but be wary of material with a dotted line in the margin. At the end of the book is an index of the X3J13 votes, ordered by the committee's internal code names (included to ease cross-reference to the X3J13 documents, which may be useful during the public review periods). References to this list of votes appear as numbers in angle brackets; thus "<14>" refers to the vote on issue number 14, whereas "[14]" refers to reference 14 in the bibliography. I have kept changes to the wording of the first-edition material to a minimum. Obvious spelling and typographical errors have been corrected, and the entire text has been edited to a uniform style of spelling and punctuation. (Note in particular that the first edition used the spelling "signalling" but this edition, in deference to the style decision of the X3J13 Drafting Subcommittee, uses "signaling.") A few minor changes were made to accommodate typographical or layout constraints. (For example, the word "also" has been deleted from the first sentence of chapter 1, partly to make that paragraph look better and partly to allow a better page break at the bottom of page 2.) In a very few cases the first edition contained substantive errors that I could not in good conscience correct silently; these have been flagged by paragraphs beginning with the phrase "Notice of correction". The chapter and section numbering of this edition matches that of the first edition, with the exception that a new section 7.9 has been interpolated. Four new chapters (26--29) describe substantial changes approved by X3J13: an extended loop macro, a pretty printer interface, the Common Lisp Object System, and the Common Lisp Condition System. X3J13, in the course of its work, formed a subcommittee to study whether additional means of iteration should be standardized for use in Common Lisp, for a great deal of existing practice in this area was not included in the first edition because of lack of agreement in 1984. The X3J13 Iteration Subcommittee produced reports on three possible facilities. One (loop) was approved for inclusion in the forthcoming draft standard and is described in chapter 26. X3J13 expressed interest in the other two approaches (series and generators), but the consensus as of January 1989 was that these other approaches were not yet sufficiently mature or in sufficiently widespread use to warrant inclusion in the draft Common Lisp standard at that time. However, the subcommittee was directed to continue work on these approaches and X3J13 is open to the possibility of standardizing them at a later date. Please note that I do not wish the prejudge the question of whether X3J13 will ever choose to make the other two proposals the subject of standardization. Nevertheless, I have chosen to include them in the second edition, in cooperation with Dr. Richard C. Waters, as appendices A and B, in order to make these ideas available to the Lisp community. In my judgement these proposals address an area of language design not otherwise covered by Common Lisp and are likely to have practical value even if they are never adopted as part of a formal standard. Some new material in this book has nothing to do with the work of X3J13. In many places I have added explanations, clarifications, new examples, warnings, and tips on writing portable code. Appendix C contains a piece of code that may help in understanding the backquote syntax. This second edition, unlike the first edition, also includes a few diagrams to pep up the text. However, there are absolutely no new jokes, and very few outright lies. =============================================================================== <#### Acknowledgments (Second Edition) ####> First and foremost, I must thank the many people in the Lisp community who have worked so hard to specify, implement, and use Common Lisp. Some of these have volunteered many hours of effort as members of ANSI committee X3J13. Others have made presentations or proposals to X3J13, and yet others have sent suggestions and corrections to the first edition directly to me. This book builds on their efforts as well as mine. An early draft of this book was made available to all members of X3J13 for their criticism. I have also worked with the many public documents that have been written during the course of the committee's work (which is not over yet). It is my hope that this book is an accurate reflection of the committee's actions as of October 1989. Nevertheless, any errors or inconsistencies are my responsibility. The fact that I have made a draft available to certain persons, received feedback from them, or thanked them in these acknowledgments does not necessarily imply that any one of them or any of the institutions with which they are affiliated endorse this book or anything of its contents. Digital Press and I gave permission to X3J13 to use any or all parts of the first edition in the production of an ANSI Common Lisp standard. Conversely, in writing this book I have worked with publicly available documents produced by X3J13 in the course of its work, and in some cases as a courtesy have obtained the consent of the authors of those documents to quote them extensively. This common ancestry will result in similarities between this book and the emerging ANSI Common Lisp standard (that is the purpose, after all). Nevertheless, this second edition has no official connection whatsoever with X3J13 or ANSI, nor is it endorsed by either of those institutions. The following persons have been members of X3J13 or involved in its activities at one time or another: Jim Allard, Dave Andre, Jim Antonisse, William Arbaugh, John Aspinall, Bob Balzer, Gerald Barber, Richard Barber, Kim Barrett, David Bartley, Roger Bate, Alan Bawden, Michael Beckerle, Paul Beiser, Eric Benson, Daniel Bobrow, Mary Boelk, Skona Brittain, Gary Brown, Tom Bucken, Robert Buckley, Gary Byers, Dan Carnese, Bob Cassels, Jerome Chailloux, Kathy Chapman, Thomas Christaller, Will Clinger, Peter Coffee, John Cugini, Pavel Curtis, Doug Cutting, Christopher Dabrowski, Jeff Dalton, Linda DeMichiel, Fred Discenzo, Jerry Duggan, Patrick Dussud, Susan Ennis, Scott Fahlman, Jogn Fitch, John Foderaro, Richard Gabriel, Steven Gadol, Nick Gall, Oscar Garcia, Robert Giansiracusa, Brad Goldstein, David Gray, Richard Greenblatt, George Hadden, Steve Haflich, Dave Henderson, Carl Hewitt, Carl Hoffman, Cheng Hu, Masayuki Ida, Takayasu Ito, Sonya Keene, James Kempf, Gregory Jennings, Robert Kerns, Gregor Kiczales, Kerry Kimbrough, Dieter Kolb, Timothy Koschmann, Ed Krall, Fritz Kunze, Aaron Larson, Joachim Laubsch, Kevin Layer, Michael Levin, Ray Lim, Thom Linden, David Loeffler, Sandra Loosemore, Barry Margolin, Larry Masinter, David Matthews, Robert Mathis, John McCarthy, Chris McConnell, Rob McLachlan, Jay Mendelsohn, Martin Mikelsons, Tracey Miles, Richard Mlyarnik, David Moon, Jarl Nilsson, Leo Noordhulsen, Ronald Ohlander, Julian Padget, Jeff Peck, Jan Pedersen, Bob Pellegrino, Crispin Perdue, Dan Pierson, Kent Pitman, Dexter Pratt, Christian Quiennec, B. Raghavan, Douglas Rand, Jonathan Rees, Chris Richardson, Jeff Rininger, Walter van Roggen, Jeffrey Rosenking, Don Sakahara, William Scherlis, David Slater, James Smith, Alan Snyder, Angela Sodan, Richard Soley, S. Sridhar, Bill St. Clair, Philip Stanhope, Guy Steele, Herbert Stoyan, Hiroshi Torii, Dave Touretzky, Paul Tucker, Rick Tucker, Thomas Turba, David Unietis, Mary Van Deusen, Ellen Waldrum, Richard Waters, Allen Wechsler, Mark Wegman, Jon L White, Skef Wholey, Alexis Wieland, Martin Yonke, Bill York, Taiichi Yuasa, Gail Zacharias, and Jan Zubkoff. I must express particular gratitude and appreciation to a number of people for their exceptional efforts: Larry Masinter, chairman of the X3J13 Cleanup Subcommittee, developed the standard format for documenting all proposals to be voted upon. The result has been an outstanding technical and historical record of all the actions taken by X3J13 to rectify and improve Common Lisp. Sandra Loosemore, chairwoman of the X3J13 Compiler Subcommittee, produced many proposals for clarifying the semantics of the compilation process. She has been a diligent stickler for detail and has helped to clarify many parts of Common Lisp left vague in the first edition. Jon L White, chairman of the X3J13 Iteration Subcommittee, supervised the consideration of several controversial proposals, one of which (loop) was eventually adopted by X3J13. Thom Linden, chairman of the X3J13 Character Subcommittee, led a team in grappling with the difficult problem of accommodating various character sets in Common Lisp. One result is that Common Lisp will be more attractive for international use. Kent Pitman, chairman of the X3J13 Error Handling Subcommittee, plugged the biggest outstanding hole in Common Lisp as described by the first edition. Kathy Chapman, chairwoman of the X3J13 Drafting Subcommittee, and principal author of the draft standard, has not only written a great deal of text but also insisted on coherent and consistent terminology and pushed the rest of the committee forward when necessary. Robert Mathis, chairman of X3J13, has kept administrative matters flowing smoothly during technical controversies. Mary Van Deusen, secretary of X3J13, kept excellent minutes that were a tremendous aid to me in tracing the history of a number of complex discussions. Jan Zubkoff, X3J13 meeting and mailing organizer, knows what's going on, as always. She is a master of organization and of physical arrangements. Moreover, she once again pulled me out of the fire at the last minute. Dick Gabriel, international representative for X3J13, has kept information flowing smoothly between Europe, Japan, and the United States. He provided a great deal of the energy and drive for the completion of the Common Lisp Object System specification. He has also provided me with a great deal of valuable advice and has been on call for last-minute consultation at all hours during the final stages of preparation for this book. David Moon has consistently been a source of reason, expert knowledge, and careful scrutiny. He has read the first edition and the X3J13 proposals perhaps more carefully than anyone else. David Moon, Jon L White, Gregor Kiczales, Robert Mathis, Mary Boelk provided extensive feedback on an early draft of this book. I thank them as well as the many others who commented in one way or another on the draft. I wish to thank the authors of large proposals to X3J13 that have made material available for more or less wholesale inclusion in this book as distinct chapters. This material was produced primarily for the use of X3J13 in its work. It has been included here on a non-exclusive basis with the consent of the authors. The author of the chapter on loop (Jon L White) notes that the chapter is based on documentation written at Lucid, Inc., by Molly M. Miller, Sonia Orin Lyris, and Kris Dinkel. Glenn Burke, Scott Fahlman, Colin Meldrum, David Moon, Cris Perdue, and Dick Waters contributed to the design of the loop macro. The authors of the Common Lisp Object System specification (Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon) wish to thank Patrick Dussud, Kenneth Kahn, Jim Kempf, Larry Masinter, Mark Stefik, Daniel L. Weinreb, and Jon L White for their contributions. The author of the chapter on Conditions (Kent M. Pitman) notes that there is a paper [38] containing background information about the design of the condition system, which is based on the condition system of the Symbolics Lisp Machines [49]. The members of the X3J13 Error Handling Subcommittee were Andy Daniels and Kent Pitman. Richard Mlynarik and David A. Moon made major design contributions. Useful comments, questions, suggestions, and criticisms were provided by Paul Anagnostopoulos, Alan Bawden, William Chiles, Pavel Curtis, Mary Fontana, Dick Gabriel, Dick King, Susan Lander, David D. Loeffler, Ken Olum, David C. Plummer, Alan Snyder, Eric Weaver, and Daniel L. Weinreb. The Condition System was designed specifically to accommodate the needs of Common Lisp. The design is, however, most directly based on the "New Error System" (NES) developed at Symbolics by David L. Andre, Bernard S. Greenberg, Mike McMahon, David A. Moon, and Daniel L. Weinreb. The NES was in turn based on experiences with the original Lisp Machine error system (developed at MIT), which was found to be inadequate for the needs of the modern Lisp Machine environments. Many aspects of the NES were inspired by the (PL/I) condition system used by the Honeywell Multics operating system. Henry Lieberman provided conceptual guidance and encouragement in the design of the NES. A reimplementation of the NES for non-Symbolics Lisp Machine dialects (MIT, LMI, and TI) was done at MIT by Richard M. Stallman. During the process of that reimplementation, some conceptual changes were made which have significantly influenced the Common Lisp Condition System. As for the smaller but no less important proposals, Larry Masinter deserves recognition as an author of over half of them. He has worked indefatigably to write up proposals and to polish drafts by other authors. Kent Pitman, David Moon, and Sandra Loosemore have also been notably prolific, as well as Jon L White, Dan Pierson, Walter van Roggen, Skona Brittain, Scott Fahlman, and myself. Other authors of proposals include David Andre, John Aspinall, Kim Barrett, Eric Benson, Daniel Bobrow, Bob Cassels, Kathy Chapman, WIlliam Clinger, Pavel Curtis, Doug Cutting, Jeff Dalton, Linda DiMichiel, Richard Gabriel, Steven Haflich, Sonya Keene, James Kempf, Gregor Kiczales, Dieter Kolb, Barry Margolin, Chris McConnell, Jeff Peck, Jan Pedersen, Crispin Perdue, Jonathan Rees, Don Sakahara, David Touretzky, Richard Waters, and Gail Zacharias. I am grateful to Donald E. Knuth and his colleagues for producing the TeX text formatting system [28], which was used to produce and typeset the manuscript. Knuth did an especially good job of publishing the program for TeX [29]; I had to consult the code about eight times while debugging particularly complicated macros. Thanks to the extensive indexing and cross- references, in each case it took me less than five minutes to find the relevant fragment of that 500-page program. I also owe a debt to Leslie Lamport, author of the LaTeX macro package [30] for TeX, within which I implemented the document style for this book. Blue Sky Research sells and supports Textures, an implementation of TeX for Apple Macintosh computers; Gayla Groom and Barry Smith of Blue Sky Research provided excellent technical support when I needed it. Other software tools that were invaluable in preparing this book were QuicKeys (sold by CE Software, Inc.), which provides keyboard macros; Gofer (sold by Microlytics, Inc.), which performs rapid text searches in multiple files; Symantec Utilities for Macintosh (sold by Symantec Corporation), which saved me from more than one disk crash; and the PostScript language and compatible fonts (sold by Adobe Systems Incorporated). Some of this software (such as LaTeX) I obtained for free and some I bought, but all have proved to be useful tools of excellent quality. I am grateful to these developers for creating them. Electronic mail has been indispensible to the writing of this book, as well to as the work of X3J13. (It is a humbling experience to publish a book and then for the next five years to receive at least one electronic mail message a week, if not twenty, pointing out some mistake or defect.) Kudos to those develop and maintain the Internet, which arose from the Arpanet and other networks. Chase Duffy, George Horesta, and Will Buddenhagen of Digital Press have given me much encouragement and support. David Ford designed the book and provided specifications that I could code into TeX. Alice Cheyer and Kate Schmit edited the copy for style and puzzled over the more obscure jokes with great patience. Marilyn Rowland created the index; Tim Evans and I did some polishing. Laura Fillmore and her colleagues at Editorial, Inc., have tirelessly and meticulously checked one draft after another and has kept the paperwork flowing smoothly during the last hectic weeks of proofreading, page makeup, and typesetting. Thinking Machines Corporation has supported all my work with X3J13. I thank all my colleagues there for their encouragement and help. Others who provided indispensible encouragement and support include Guy and Nalora Steele; David Steele; Cordon and Ruth Kerns; David, Patricia, Tavis, Jacob, Nicholas, and Daniel Auwerda; Donald and Denise Kerns; and David, Joyce, and Christine Kerns. Most of the writing of this book took place between 10 P.M. and 3 A.M. (I'm not as young as I used to be). I am grateful to Barbara, Julia, Peter, and Matthew for putting up with it, and for their love. Guy L. Steele Jr. Lexington, Massachusetts All Saints' Day, 1989 =============================================================================== <#### Acknowledgments (First Edition) ####> Common Lisp was designed by a diverse group of people affiliated with many institutions. Contributors to the design and implementation of Common Lisp and to the polishing of this book are hereby gratefully acknowledged: Paul Anagnostopoulos Digital Equipment Corporation Dan Aronson Carnegie-Mellon University Alan Bawden Massachusetts Institute of Technology Eric Benson University of Utah, Stanford University, and Symbolics, Incorporated Jon Bentley Carnegie-Mellon University and Bell Laboratories Jerry Boetje Digital Equipment Corporation Gary Brooks Texas Instruments Rodney A. Brooks Stanford University Gary L. Brown Digital Equipment Corporation Richard L. Bryan Symbolics, Incorporated Glenn S. Burke Massachusetts Institute of Technology Howard I. Cannon Symbolics, Incorporated George J. Carrette Massachusetts Institute of Technology Robert Cassels Symbolics, Incorporated Monica Cellio Carnegie-Mellon University David Dill Carnegie-Mellon University Scott E. Fahlman Carnegie-Mellon University Richard J. Fateman University of California, Berkeley Neal Feinberg Carnegie-Mellon University Ron Fischer Rutgers University John Foderaro University of California, Berkeley Steve Ford Texas Instruments Richard P. Gabriel Stanford University and Lawrence Livermore National Laboratory Joseph Ginder Carnegie-Mellon University and Perq Systems Corp. Bernard S. Greenberg Symbolics, Incorporated Richard Greenblatt Lisp Machines Incorporated (LMI) Martin L. Griss University of Utah and Hewlett-Packard Incorporated Steven Handerson Carnegie-Mellon University Charles L. Hedrick Rutgers University Gail Kaiser Carnegie-Mellon University Earl A. Killian Lawrence Livermore National Laboratory Steve Krueger Texas Instruments John L. Kulp Symbolics, Incorporated Jim Large Carnegie-Mellon University Rob Maclachlan Carnegie-Mellon University William Maddox Carnegie-Mellon University Larry M. Masinter Xerox Corporation, Palo Alto Research Center John McCarthy Stanford University Michael E. McMahon Symbolics, Incorporated Brian Milnes Carnegie-Mellon University David A. Moon Symbolics, Incorporated Beryl Morrison Digital Equipment Corporation Don Morrison University of Utah Dan Pierson Digital Equipment Corporation Kent M. Pitman Massachusetts Institute of Technology Jonathan Rees Yale University Walter van Roggen Digital Equipment Corporation Susan Rosenbaum Texas Instruments William L. Scherlis Carnegie-Mellon University Lee Schumacher Carnegie-Mellon University Richard M. Stallman Massachusetts Institute of Technology Barbara K. Steele Carnegie-Mellon University Guy L. Steele Jr. Carnegie-Mellon University and Tartan Laboratories Incorporated Peter Szolovits Massachusetts Institute of Technology William vanMelle Xerox Corporation, Palo Alto Research Center Ellen Waldrum Texas Instruments Allan C. Wechsler Symbolics, Incorporated Daniel L. Weinreb Symbolics, Incorporated Jon L White Xerox Corporation, Palo Alto Research Center Skef Wholey Carnegie-Mellon University Richard Zippel Massachusetts Institute of Technology Leonard Zubkoff Carnegie-Mellon University and Tartan Laboratories Incorporated Some contributions were relatively small; others involved enormous expenditures of effort and great dedication. A few of the contributors served more as worthy adversaries than as benefactors (and do not necessarily endorse the final design reported here), but their pointed criticisms were just as important to the polishing of Common Lisp as all the positively phrased suggestions. All of the people named above were helpful in one way or another, and I am grateful for the interest and spirit of cooperation that allowed most decisions to be made by consensus after due discussion. Considerable encouragement and moral support were also provided by: Norma Abel Digital Equipment Corporation Roger Bate Texas Instruments Harvey Cragon Texas Instruments Dennis Duncan Digital Equipment Corporation Sam Fuller Digital Equipment Corporation A. Nico Habermann Carnegie-Mellon University Berthold K. P. Horn Massachusetts Institute of Technology Gene Kromer Texas Instruments Gene Matthews Texas Instruments Allan Newell Carnegie-Mellon University Dana Scott Carnegie-Mellon University Harry Tennant Texas Instruments Patrick H. Winston Massachusetts Institute of Technology Lowell Wood Lawrence Livermore National Laboratory William A. Wulf Carnegie-Mellon University and Tartan Laboratories Incorporated I am very grateful to each of them. Jan Zubkoff of Carnegie-Mellon University provided a great deal of organization, secretarial support, and unfailing good cheer in the face of adversity. The development of Common Lisp would most probably not have been possible without the electronic message system provided by the ARPANET. Design decisions were made on several hundred distinct points, for the most part by consensus, and by simple majority vote when necessary. Except for two one-day face-to-face meetings, all of the language design and discussion was done through the ARPANET message system, which permitted effortless dissemination of messages to dozens of people, and several interchanges per day. The message system also provided automatic archiving of the entire discussion, which has proved invaluable in the preparation of this reference manual. Over the course of thirty months, approximately 3000 messages were sent (an average of three per day), ranging in length from one line to twenty pages. Assuming 5000 characters per printed page of text, the entire discussion totaled about 1100 pages. It would have been substantially more difficult to have conducted this discussion by any other means, and would have required much more time. The ideas in Common Lisp have come from many sources and been polished by much discussion. I am responsible for the form of this book, and for any errors or inconsistencies that may remain; but the credit for the design and support of Common Lisp lies with the individuals named above, each of whom has made significant contributions. The organization and content of this book were inspired in large part by the "MacLISP Reference Manual" by David A. Moon and others [33], and by the "LISP Machine Manual" (fourth edition) by Daniel Weinreb and David Moon [55], which in turn acknowledges the efforts of Richard Stallman, Mike McMahon, Alan Bawden, Glenn Burke, and "many people too numerous to list." I thank Phyllis Keenan, Chase Duffy, Virginia Anderson, John Osborn, and Jonathan Baker of Digital Press for their help in preparing this book for publication. Jane Blake did an admirable job of copy-editing. James Gibson and Katherine Downs of Waldman Graphics were most cooperative in typesetting this book from my on-line manuscript files. I am grateful to Carnegie-Mellon University and to Tartan Laboratories Incorporated for supporting me in the writing of this book over the last three years. Part of the work on this book was done in conjunction with the Carnegie- Mellon University Spice Project, an effort to construct an advanced scientific software development environment for personal computers. The Spice Project is supported by the Defense Advanced Research Projects Agency, Department of Defense, ARPA Order 3597, monitored by the Air Force Avionics Laboratory under contract F33615-78-C-1551. The views and conclusions contained in this book are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S. Government. Most of the writing of this book took place between midnight and 5 A.M. I am grateful to Barbara, Julia, and Peter for putting up with it, and for their love. Guy L. Steele Jr. Pittsburgh, Pennsylvania March 1984 =============================================================================== 1. <#### Introduction ####> Common Lisp is a new dialect of Lisp, a successor to MacLisp [33,37], influenced strongly by Zetalisp [55,34] and to some extent by Scheme [46] and Interlisp [50]. ------------------------------------------------------------------------------- 1.1. <### Purpose ###> Common Lisp is intended to meet these goals: __Commonality__ Common Lisp originated in an attempt to focus the work of several implementation groups, each of which was constructing successor implementations of MacLisp for different computers. These implementations had begun to diverge because of the differences in the implementation environments: microcoded personal computers (Zetalisp, Spice Lisp), commercial timeshared computers (NIL--the "New Implementation of Lisp"), and supercomputers (S-1 Lisp). While the differences among the several implementation environments of necessity will continue to force certain incompatibilities among the implementations, Common Lisp serves as a common dialect to which each implementation makes any necessary extensions. __Portability__ Common Lisp intentionally excludes features that cannot be implemented easily on a broad class of machines. On the one hand, features that are difficult or expensive to implement on hardware without special microcode are avoided or provided in a more abstract and efficiently implementable form. (Examples of this are the invisible forwarding pointers and locatives of Zetalisp. Some of the problems that they solve are addressed in different ways in Common Lisp.) On the other hand, features that are useful only on certain "ordinary" or "commercial" processors are avoided or made optional. (An example of this is the type declaration facility, which is useful in some implementations and completely ignored in others. Type declarations are completely optional and for correct programs affect only efficiency, not semantics.) Common Lisp is designed to make it easy to write programs that depend as little as possible on machine-specific characteristics, such as word length, while allowing some variety of implementation techniques. __Consistency__ Most Lisp implementations are internally inconsistent in that by default the interpreter and compiler may assign different semantics to correct programs. This semantic difference stems primarily from the fact that the interpreter assumes all variables to be dynamically scoped, whereas the compiler assumes all variables to be local unless explicitly directed otherwise. This difference has been the usual practice in Lisp for the sake of convenience and efficiency but can lead to very subtle bugs. The definition of Common Lisp avoids such anomalies by explicitly requiring the interpreter and compiler to impose identical semantics on correct programs so far as possible. __Expressiveness__ Common Lisp culls what experience has shown to be the most useful and understandable constructs from not only MacLisp but also Interlisp, other Lisp dialects, and other programming languages. Constructs judged to be awkward or less useful have been excluded. (An example is the store construct of MacLisp.) __Compatibility__ Unless there is a good reason to the contrary, Common Lisp strives to be compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly in that order. __Efficiency__ Common Lisp has a number of features designed to facilitate the production of high-quality compiled code in those implementations whose developers care to invest effort in an optimizing compiler. One implementation of Common Lisp, namely S-1 Lisp, already has a compiler that produces code for numerical computations that is competitive in execution speed to that produced by a Fortran compiler [11]. The S-1 Lisp compiler extends the work done in MacLisp to produce extremely efficient numerical code [19]. __Power__ Common Lisp is a descendant of MacLisp, which has traditionally placed emphasis on providing system-building tools. Such tools may in turn be used to build the user-level packages such as Interlisp provides; these packages are not, however, part of the Common Lisp core specification. It is expected such packages will be built on top of the Common Lisp core. __Stability__ It is intended that Common Lisp will change only slowly and with due deliberation. The various dialects that are supersets of Common Lisp may serve as laboratories within which to test language extensions, but such extensions will be added to Common Lisp only after careful examination and experimentation. The goals of Common Lisp are thus very close to those of Standard Lisp [51] and Portable Standard Lisp [51]. Common Lisp differs from Standard Lisp primarily in incorporating more features, including a richer and more complicated set of data types and more complex control structures. This book is intended to be a language specification rather than an implementation specification (although implementation notes are scattered throughout the text). It defines a set of standard language concepts and constructs that may be used for communication of data structures and algorithms in the Common Lisp dialect. This set of concepts and constructs is sometimes referred to as the "core Common Lisp language" because it contains conceptually necessary or important features. It is not necessarily implementationally minimal. While many features could be defined in terms of others by writing Lisp code, and indeed may be implemented that way, it was felt that these features should be conceptually primitive so that there might be agreement among all users as to their usage. (For example, bignums and rational numbers could be implemented as Lisp code given operations on fixnums. However, it is important to the conceptual integrity of the language that they be regarded by the user as primitive, and they are useful enough to warrant a standard definition.) For the most part, this book defines a programming language, not a programming environment. A few interfaces are defined for invoking such standard programming tools as a compiler, an editor, a program trace facility, and a debugger, but very little is said about their nature or operation. It is expected that one or more extensive programming environments will be built using Common Lisp as a foundation, and will be documented separately. There are now many implementations of Common Lisp, some programmed by | research groups in universities and some by companies that sell them | commercially, and a number of useful programming environments have indeed grown| up around these implementations. What is more, all the goals stated above have| been achieved, most notably that of portability. Moving large bodies of Lisp | code from one computer to another is now routine. | ------------------------------------------------------------------------------- 1.2. <### Notational Conventions ###> A number of special notational conventions are used throughout this book for the sake of conciseness. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.2.1. <## Decimal Numbers ##> All numbers in this book are in decimal notation unless there is an explicit indication to the contrary. (Decimal notation is normally taken for granted, of course. Unfortunately, for certain other dialects of Lisp, MacLisp in particular, the default notation for numbers is octal (base 8) rather than decimal, and so the use of decimal notation for describing Common Lisp is, taken in its historical context, a bit unusual!) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.2.2. <## Nil, False, and the Empty List ##> In Common Lisp, as in most Lisp dialects, the symbol nil is used to represent both the empty list and the "false" value for Boolean tests. An empty list may, of course, also be written (); this normally denotes the same object as nil. (It is possible, by extremely perverse manipulation of the package system, to cause the sequence of letters nil to be recognized not as the symbol that represents the empty list but as another symbol with the same name. This obscure possibility will be ignored in this book.) These two notations may be used interchangeably as far as the Lisp system is concerned. However, as a matter of style, this book uses the notation "()" when it is desirable to emphasize the use of an empty list, and uses the notation "nil" when it is desirable to emphasize the use of the Boolean "false". The notation 'nil (note the explicit quotation mark) is used to emphasize the use of a symbol. For example: (defun three () 3) ;Emphasize empty parameter list (append '() '()) ==> () ;Emphasize use of empty lists (not nil) ==> t ;Emphasize use as Boolean "false" (get 'nil 'color) ;Emphasize use as a symbol Any data object other than nil is construed to be Boolean "not false", that is, "true". The symbol t is conventionally used to mean "true" when no other value is more appropriate. When a function is said to "return false" or to "be false" in some circumstance, this means that it returns nil. However, when a function is said to "return true" or to "be true" in some circumstance, this means that it returns some value other than nil, but not necessarily t. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.2.3. <## Evaluation, Expansion, and Equivalence ##> Execution of code in Lisp is called evaluation because executing a piece of code normally results in a data object called the "value" produced by the code. The symbol "==>" is used in examples to indicate evaluation. For example, (+ 4 5) ==> 9 means "the result of evaluating the code (+ 4 5) is (or would be, or would have been) 9." The symbol --> is used in examples to indicate macro expansion. For example, (push x v) --> (setf v (cons x v)) means "the result of expanding the macro-call form (push x v) is (setf v (cons x v))." This implies that the two pieces of code do the same thing; the second piece of code is the definition of what the first does. The symbol == is used in examples to indicate code equivalence. For example, (gcd x (gcd y z)) == (gcd (gcd x y) z) means "the value and effects of evaluating the form (gcd x (gcd y z)) are always the same as the value and effects of (gcd (gcd x y) z) for any values of the variables x, y, and z." This implies that the two pieces of code do the same thing; however, neither directly defines the other in the way macro expansion does. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.2.4. <## Errors ##> When this book specifies that it "is an error" for some situation to occur, this means that: * No valid Common Lisp program should cause this situation to occur. * If this situation occurs, the effects and results are completely undefined as far as adherence to the Common Lisp specification is concerned. * No Common Lisp implementation is required to detect such an error. Of course, implementors are encouraged to provide for detection of such errors wherever reasonable. This is not to say that some particular implementation might not define the effects and results for such a situation; the point is that no program conforming to the Common Lisp specification may correctly depend on such effects or results. On the other hand, if it is specified in this book that in some situation "an error is signaled," this means that: * If this situation occurs, an error will be signaled (see error and cerror). * Valid Common Lisp programs may rely on the fact that an error will be signaled. * Every Common Lisp implementation is required to detect such an error. In places where it is stated that so-and-so "must" or "must not" or "may not" be the case, then it "is an error" if the stated requirement is not met. For example, if an argument "must be a symbol," then it "is an error" if the argument is not a symbol. In all cases where an error is to be signaled, the word "signaled" is always used explicitly in this book. X3J13 has adopted a more elaborate terminology for errors, and has made some | effort to specify the type of error to be signaled in situations where | signaling is appropriate. This effort was not complete as of September 1989, | and I have made little attempt to incorporate the new error terminology or | error type specifications in this book. However, the new terminology is | described and used in the specification of the Common Lisp Object System | appearing in chapter 28; this gives the flavor of how erroneous situations will| be described, and appropriate actions prescribed, in the forthcoming ANSI | Common Lisp standard. | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.2.5. <## Descriptions of Functions and Other Entities ##> Functions, variables, named constants, special forms, and macros are described using a distinctive typographical format. Table 1-1 illustrates the manner in which Common Lisp functions are documented. The first line specifies the name of the function, the manner in which it accepts arguments, and the fact that it is a function. If the function takes many arguments, then the names of the arguments may spill across two or three lines. The paragraphs following this standard header explain the definition and uses of the function and often present examples or related functions. Sometimes two or more related functions are explained in a single combined description. In this situation the headers for all the functions appear together, followed by the combined description. In general, actual code (including actual names of functions) appears in this typeface: (cons a b). Names that stand for pieces of code (metavariables) are written in italics. In a function description, the names of the parameters appear in italics for expository purposes. The word &optional in the list of parameters indicates that all arguments past that point are optional; the default values for the parameters are described in the text. Parameter lists may also contain &rest, indicating that an indefinite number of arguments may appear, or &key, indicating that keyword arguments are accepted. (The &optional &rest &key syntax is actually used in Common Lisp function definitions for these purposes.) ............................................................................... Table 1-1: Sample Function Description ---------<<>> sample-function sample-function arg1 arg2 &optional arg3 arg4 The function sample-function adds together arg1 and arg2, and then multiplies the result by arg3. If arg3 is not provided or is nil, the multiplication isn't done. sample-function then returns a list whose first element is this result and whose second element is arg4 (which defaults to the symbol foo). For example: (sample-function 3 4) ==> (7 foo) (sample-function 1 2 2 'bar) ==> (6 bar) In general, (sample-function x y) == (list (+ x y) 'foo). ............................................................................... Table 1-2: Sample Variable Description ---------<<>> *sample-variable* *sample-variable* The variable *sample-variable* specifies how many times the special form sample-special-form should iterate. The value should always be a non-negative integer or nil (which means iterate indefinitely many times). The initial value is 0 (meaning no iterations). ............................................................................... Table 1-3: Sample Constant Description ---------<<>> sample-constant sample-constant The named constant sample-constant has as its value the height of the terminal screen in furlongs times the base-2 logarithm of the implementation's total disk capacity in bytes, as a floating-point number. ............................................................................... Table 1-2 illustrates the manner in which a global variable is documented. The first line specifies the name of the variable and the fact that it is a variable. Purely as a matter of convention, all global variables used by Common Lisp have names beginning and ending with an asterisk. Table 1-3 illustrates the manner in which a named constant is documented. The first line specifies the name of the constant and the fact that it is a constant. (A constant is just like a global variable, except that it is an error ever to alter its value or to bind it to a new value.) ............................................................................... Table 1-4: Sample Special Form Description ---------<<>> sample-special-form sample-special-form [name] ({var}*) {form}+ This evaluates each form in sequence as an implicit progn, and does this as many times as specified by the global variable *sample-variable*. Each variable var is bound and initialized to 43 before the first iteration, and unbound after the last iteration. The name name, if supplied, may be used in a return-from form to exit from the loop prematurely. If the loop ends normally, sample-special-form returns nil. For example: (setq *sample-variable* 3) (sample-special-form () form1 form2) This evaluates form1, form2, form1, form2, form1, form2 in that order. ............................................................................... Table 1-5: Sample Macro Description ---------<<>> sample-macro sample-macro var [[declaration* | doc-string]] {tag | statement}* This evaluates the statements as a prog body, with the variable var bound to 43. (sample-macro x (return (+ x x))) ==> 86 (sample-macro var . body) --> (prog ((var 43)) . body) ............................................................................... Tables 1-4 and 1-5 illustrate the documentation of special forms and macros, which are closely related in purpose. These are very different from functions. Functions are called according to a single, specific, consistent syntax; the &optional/&rest/&key syntax specifies how the function uses its arguments internally but does not affect the syntax of a call. In contrast, each special form or macro can have its own idiosyncratic syntax. It is by special forms and macros that the syntax of Common Lisp is defined and extended. In the description of a special form or macro, an italicized word names a corresponding part of the form that invokes the special form or macro. Parentheses stand for themselves and should be written as such when invoking the special form or macro. Brackets, braces, stars, plus signs, and vertical bars are metasyntactic marks. Brackets, [ and ], indicate that what they enclose is optional (may appear zero times or one time in that place); the square brackets should not be written in code. Braces, { and }, simply parenthesize what they enclose but may be followed by a star, *, or a plus sign, +; a star indicates that what the braces enclose may appear any number of times (including zero, that is, not at all), whereas a plus sign indicates that what the braces enclose may appear any non-zero number of times (that is, must appear at least once). Within braces or brackets, a vertical bar, |, separates mutually exclusive choices. In summary, the notation {x}* means zero or more occurrences of x, the notation {x}+ means one or more occurrences of x, and the notation [x] means zero or one occurrence of x. These notations are also used for syntactic descriptions expressed as BNF-like productions, as in table 22-2. Double brackets, [[ and ]], indicate that any number of the alternatives | enclosed may be used, and those used may occur in any order, but each | alternative may be used at most once unless followed by a star. For example, | p [[ x | {y}* | z ]] q | means that at most one x, any number of y's, and at most one z may appear | between the mandatory occurrences of p and q, and those that appear may be in | any order. | | A downward arrow, /, indicates a form of syntactic indirection that helps to | make [[ ]] notation more readable. If X is some non-terminal symbol occurring | on the left-hand side of some BNF production, then the right-hand side of that | production is to be textually substituted for any occurrence of X/. Thus the | two fragments | p [[ xyz-mixture/ ]] q | xyz-mixture ::= x | {y}* | z | are together equivalent to the previous example. | In the last example in table 1-5, notice the use of dot notation. The dot appearing in the expression (sample-macro var . body) means that the name body stands for a list of forms, not just a single form, at the end of a list. This notation is often used in examples. In the heading line in table 1-5, notice the use of [[ ]] notation to | indicate that any number of declarations may appear but at most one | documentation string (which may appear before, after, or somewhere in the | middle of any declarations). | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.2.6. <## The Lisp Reader ##> The term "Lisp reader" refers not to you, the reader of this book, nor to some person reading Lisp code, but specifically to a Lisp procedure, namely the function read, which reads characters from an input stream and interprets them by parsing as representations of Lisp objects. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.2.7. <## Overview of Syntax ##> Certain characters are used in special ways in the syntax of Common Lisp. The complete syntax is explained in detail in chapter 22, but a quick summary here may be useful: " ( " A left parenthesis begins a list of items. The list may contain any number of items, including zero. Lists may be nested. For example, (cons (car x) (cdr y)) is a list of three things, of which the last two are themselves lists. " ) " A right parenthesis ends a list of items. " ' " An acute accent (also called single quote or apostrophe) followed by an expression form is an abbreviation for (quote form). Thus 'foo means (quote foo) and '(cons 'a 'b) means (quote (cons (quote a) (quote b))). " ; " Semicolon is the comment character. It and all characters up to the end of the line are discarded. " " " Double quotes surround character strings: "This is a thirty-nine-character string." " \ " Backslash is an escape character. It causes the next character to be treated as a letter rather than for its usual syntactic purpose. For example, A\(B denotes a symbol whose name consists of the three characters A, (, and B. Similarly, "\"" denotes a character string containing one character, a double quote, because the first and third double quotes serve to delimit the string, and the second double quote serves as the contents of the string. The backslash causes the second double quote to be taken literally and prevents it from being interpreted as the terminating delimiter of the string. " | " Vertical bars are used in pairs to surround the name (or part of the name) of a symbol that has many special characters in it. It is roughly equivalent to putting a backslash in front of every character so surrounded. For example, |A(B)|, A|(|B|)|, and A\(B\) all mean the symbol whose name consists of the four characters A, (, B, ). " # " The number sign signals the beginning of a complicated syntactic structure. The next character designates the precise syntax to follow. For example, #o105 means 105[8] (105 in octal notation); #x105 means 105[16] (105 in hexadecimal notation); #b1011 means 1011[2] (1011 in binary notation); #\L denotes a character object for the character L; and #(a b c) denotes a vector of three elements a, b, and c. A particularly important case is that #'fn means (function fn), in a manner analogous to 'form meaning (quote form). " ` " Grave accent ("backquote") signals that the next expression is a template that may contain commas. The backquote syntax represents a program that will construct a data structure according to the template. " , " Commas are used within the backquote syntax. " : " Colon is used to indicate which package a symbol belongs to. For example, network:reset denotes the symbol named reset in the package named network. A leading colon indicates a keyword, a symbol that always evaluates to itself. The colon character is not actually part of the print name of the symbol. This is all explained in chapter 11; until you read that, just keep in mind that a symbol notated with a leading colon is in effect a constant that evaluates to itself. __Notice of correction.__ | In the first edition, the characters "," and ":" at the left margin above | were inadvertently omitted. | Brackets, braces, question mark, and exclamation point (that is, [, ], {, }, ?, and !) are not used for any purpose in standard Common Lisp syntax. These characters are explicitly reserved to the user, primarily for use as macro characters for user-defined lexical syntax extensions (see section 22.3). All code in this book is written using lowercase letters. Common Lisp is : generally insensitive to the case in which code is written. Internally, names : of symbols are ordinarily converted to and stored in uppercase form. There are: ways to force case conversion on output if desired; see *print-case*. In this : book, wherever an interactive exchange between a user and the Lisp system is : shown, the input is exhibited with lowercase letters and the output with : uppercase letters. X3J13 voted in June 1989 <150> to introduce readtable-case. Certain settings| allow the names of symbols to be case-sensitive. The default behavior, | however, is as described in the previous paragraph. In any event, only | uppercase letters appear in the internal print names of symbols naming the | standard Common Lisp facilities described in this book. =============================================================================== 2. <#### Data Types ####> Common Lisp provides a variety of types of data objects. It is important to note that in Lisp it is data objects that are typed, not variables. Any variable can have any Lisp object as its value. (It is possible to make an explicit declaration that a variable will in fact take on one of only a limited set of values. However, such a declaration may always be omitted, and the program will still run correctly. Such a declaration merely constitutes advice from the user that may be useful in gaining efficiency. See declare.) In Common Lisp, a data type is a (possibly infinite) set of Lisp objects. Many Lisp objects belong to more than one such set, and so it doesn't always make sense to ask what is the type of an object; instead, one usually asks only whether an object belongs to a given type. The predicate typep may be used to ask whether an object belongs to a given type, and the function type-of returns a type to which a given object belongs. The data types defined in Common Lisp are arranged into a hierarchy (actually a partial order) defined by the subset relationship. Certain sets of objects, such as the set of numbers or the set of strings, are interesting enough to deserve labels. Symbols are used for most such labels (here, and throughout this book, the word "symbol" refers to atomic symbols, one kind of Lisp object, elsewhere known as literal atoms). See chapter 4 for a complete description of type specifiers. The set of all objects is specified by the symbol t. The empty data type, which contains no objects, is denoted by nil. A type called common encompasses all the data objects required by the Common : Lisp language. A Common Lisp implementation is free to provide other data : types that are not subtypes of common. : X3J13 voted in March 1989 <17> to remove the type common (and the predicate | commonp) from the language, on the grounds that it has not proved to be useful | in practice and that it could be difficult to redefine in the face of other | changes to the Common Lisp type system (such as the introduction of CLOS | classes). | The following categories of Common Lisp objects are of particular interest: numbers, characters, symbols, lists, arrays, structures, and functions. There are others as well. Some of these categories have many subdivisions. There are also standard types defined to be the union of two or more of these categories. The categories listed above, while they are data types, are neither more nor less "real" than other data types; they simply constitute a particularly useful slice across the type hierarchy for expository purposes. Here are brief descriptions of various Common Lisp data types. The remaining sections of this chapter go into more detail and also describe notations for objects of each type. Descriptions of Lisp functions that operate on data objects of each type appear in later chapters. * Numbers are provided in various forms and representations. Common Lisp provides a true integer data type: any integer, positive or negative, has in principle a representation as a Common Lisp data object, subject only to total memory limitations (rather than machine word width). A true rational data type is provided: the quotient of two integers, if not an integer, is a ratio. Floating-point numbers of various ranges and precisions are also provided, as well as Cartesian complex numbers. * Characters represent printed glyphs such as letters or text formatting operations. Strings are one-dimensional arrays of characters. Common Lisp provides for a rich character set, including ways to represent characters of various type styles. * Symbols (sometimes called atomic symbols for emphasis or clarity) are named data objects. Lisp provides machinery for locating a symbol object, given its name (in the form of a string). Symbols have property lists, which in effect allow symbols to be treated as record structures with an extensible set of named components, each of which may be any Lisp object. Symbols also serve to name functions and variables within programs. * Lists are sequences represented in the form of linked cells called conses. There is a special object (the symbol nil) that is the empty list. All other lists are built recursively by adding a new element to the front of an existing list. This is done by creating a new cons, which is an object having two components called the car and the cdr. The car may hold anything, and the cdr is made to point to the previously existing list. (Conses may actually be used completely generally as two-element record structures, but their most important use is to represent lists.) * Arrays are dimensioned collections of objects. An array can have any non- negative number of dimensions and is indexed by a sequence of integers. A general array can have any Lisp object as a component; other types of arrays are specialized for efficiency and can hold only certain types of Lisp objects. It is possible for two arrays, possibly with differing dimension information, to share the same set of elements (such that modifying one array modifies the other also) by causing one to be displaced to the other. One- dimensional arrays of any kind are called vectors. One-dimensional arrays of characters are called strings. One-dimensional arrays of bits (that is, of integers whose values are 0 or 1) are called bit-vectors. * Hash tables provide an efficient way of mapping any Lisp object (a key) to an associated object. * Readtables are used to control the built-in expression parser read. * Packages are collections of symbols that serve as name spaces. The parser recognizes symbols by looking up character sequences in the current package. * Pathnames represent names of files in a fairly implementation-independent manner. They are used to interface to the external file system. * Streams represent sources or sinks of data, typically characters or bytes. They are used to perform I/O, as well as for internal purposes such as parsing strings. * Random-states are data structures used to encapsulate the state of the built- in random-number generator. * Structures are user-defined record structures, objects that have named components. The defstruct facility is used to define new structure types. Some Common Lisp implementations may choose to implement certain system- supplied data types, such as bignums, readtables, streams, hash tables, and pathnames, as structures, but this fact will be invisible to the user. * Functions are objects that can be invoked as procedures; these may take : arguments and return values. (All Lisp procedures can be construed to return: values and therefore every procedure is a function.) Such objects include : compiled-functions (compiled code objects). Some functions are represented : as a list whose car is a particular symbol such as lambda. Symbols may also : be used as functions. : X3J13 voted in June 1988 <90> to specify that symbols are not of type | function, but are automatically coerced to functions in certain situations (see| section 2.13). | X3J13 voted in June 1988 <30> to adopt the Common Lisp Condition System, | thereby introducing a new category of data objects: | | * Conditions are objects used to affect control flow in certain conventional | ways by means of signals and handlers that intercept those signals. In | particular, errors are signaled by raising particular conditions, and errors | may be trapped by establishing handlers for those conditions. | X3J13 voted in June 1988 <12> to adopt the Common Lisp Object System, thereby| introducing additional categories of data objects: | | * Classes determine the structure and behavior of other objects, their | instances. Every Common Lisp data object belongs to some class. (In some | ways the CLOS class system is a generalization of the system of type | specifiers of the first edition of this book, but the class system augments | the type system rather than supplanting it.) | | * Methods are chunks of code that operate on arguments satisfying a particular | pattern of classes. Methods are not functions; they are not invoked directly| on arguments but instead are bundled into generic functions. | | * Generic functions are functions that contain, among other information, a set | of methods. When invoked, a generic function executes a subset of its | methods. The subset chosen for execution depends in a specific way on the | classes or identities of the arguments to which it is applied. | These categories are not always mutually exclusive. The required relationships among the various data types are explained in more detail in section 2.15. ------------------------------------------------------------------------------- 2.1. <### Numbers ###> Several kinds of numbers are defined in Common Lisp. They are divided into integers; ratios; floating-point numbers, with names provided for up to four different floating-point representations; and complex numbers. X3J13 voted in March 1989 <151> to add the type real. | | The number data type encompasses all kinds of numbers. For convenience, | there are names for some subclasses of numbers as well. Integers and ratios | are of type rational. Rational numbers and floating-point numbers are of type | real. Real numbers and complex numbers are of type number. | | Although the names of these types were chosen with the terminology of | mathematics in mind, the correspondences are not always exact. Integers and | ratios model the corresponding mathematical concepts directly. Numbers of type| float may be used to approximate real numbers, both rational and irrational. | The real type includes all Common Lisp numbers that represent mathematical real| numbers, though there are mathematical real numbers (irrational numbers) that | do not have an exact Common Lisp representation. Only real numbers may be | ordered using the <, >, <=, and >= functions. | | . . . . . . . . . . . . . . . . . . . . | Compatibility note: The Fortran 77 standard defines the term real datum to mean| "a processor approximation to the value of a real number." In practice the | Fortran basic real type is the floating-point data type that Common Lisp | calls single-float. The Fortran double precision type is Common Lisp's | double-float. The Pascal real data type is an "implementation-defined subset| of the real numbers." In practice this is usually a floating-point type, | often what Common Lisp calls double-float. | A translation of an algorithm written in Fortran or Pascal that uses real | data usually will use some appropriate precision of Common Lisp's float type.| Some algorithms may gain accuracy or flexibility by using Common Lisp's | rational or real type instead. | . . . . . . . . . . . . . . . . . . . . | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.1.1. <## Integers ##> The integer data type is intended to represent mathematical integers. Unlike most programming languages, Common Lisp in principle imposes no limit on the magnitude of an integer; storage is automatically allocated as necessary to represent large integers. In every Common Lisp implementation there is a range of integers that are represented more efficiently than others; each such integer is called a fixnum, and an integer that is not a fixnum is called a bignum. Common Lisp is designed to hide this distinction as much as possible; the distinction between fixnums and bignums is visible to the user in only a few places where the fficiency of representation is important. Exactly which integers are fixnums is implementation-dependent; typically they will be those integers in the range (-2^n) to ((2^n) - 1), inclusive, for some n not less than 15. See most-positive-fixnum and most-negative-fixnum. X3J13 voted in January 1989 <76> to specify that fixnum must be a supertype | of the type (signed-byte 16), and additionally that the value of | array-dimension-limit must be a fixnum (implying that the implementor should | choose the range of fixnums to be large enough to accommodate the largest size | of array to be supported). | | . . . . . . . . . . . . . . . . . . . . | Rationale: This specification allows programmers to declare variables in | portable code to be of type fixnum for efficiency. Fixnums are guaranteed to| encompass at least the set of 16-bit signed integers (compare this to the | data type short int in the C programming language). In addition, any valid | array index must be a fixnum, and therefore variables used to hold array | indices (such as a dotimes variable) may be declared fixnum in portable code.| . . . . . . . . . . . . . . . . . . . . | Integers are ordinarily written in decimal notation, as a sequence of decimal digits, optionally preceded by a sign and optionally followed by a decimal point. For example: 0 ; Zero -0 ; This always means the same as 0 +6 ; The first perfect number 28 ; The second perfect number 1024. ; Two to the tenth power -1 ; e^(pi*i) 15511210043330985984000000. ; 25 factorial (25!), probably a bignum . . . . . . . . . . . . . . . . . . . . Compatibility note: MacLisp and Lisp Machine Lisp normally assume that integers are written in octal (radix-8) notation unless a decimal point is present. Interlisp assumes integers are written in decimal notation and uses a trailing Q to indicate octal radix; however, a decimal point, even in trailing position, always indicates a floating-point number. This is of course consistent with Fortran. Ada does not permit trailing decimal points but instead requires them to be embedded. In Common Lisp, integers written as described above are always construed to be in decimal notation, whether or not the decimal point is present; allowing the decimal point to be present permits compatibility with MacLisp. . . . . . . . . . . . . . . . . . . . . Integers may be notated in radices other than ten. The notation #nnrddddd or #nnRddddd means the integer in radix-nn notation denoted by the digits ddddd. More precisely, one may write #, a non-empty sequence of decimal digits representing an unsigned decimal integer n, r (or R), an optional sign, and a sequence of radix-n digits, to indicate an integer written in radix n (which must be between 2 and 36, inclusive). Only legal digits for the specified radix may be used; for example, an octal number may contain only the digits 0 through 7. For digits above 9, letters of the alphabet of either case may be used in order. Binary, octal, and hexadecimal radices are useful enough to warrant the special abbreviations #b for #2r, #o for #8r, and #x for #16r. For example: #2r11010101 ; Another way of writing 213 decimal #b11010101 ; Ditto #b+11010101 ; Ditto #o325 ; Ditto, in octal radix #xD5 ; Ditto, in hexadecimal radix #16r+D5 ; Ditto #o-300 ; Decimal -192, written in base 8 #3r-21010 ; Same thing in base 3 #25R-7H ; Same thing in base 25 #xACCEDED ; 181202413, in hexadecimal radix - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.1.2. <## Ratios ##> A ratio is a number representing the mathematical ratio of two integers. Integers and ratios collectively constitute the type rational. The canonical representation of a rational number is as an integer if its value is integral, and otherwise as the ratio of two integers, the numerator and denominator, whose greatest common divisor is 1, and of which the denominator is positive (and in fact greater than 1, or else the value would be integral). A ratio is notated with / as a separator, thus: 3/5. It is possible to notate ratios in non-canonical (unreduced) forms, such as 4/6, but the Lisp function prin1 always prints the canonical form for a ratio. If any computation produces a result that is a ratio of two integers such that the denominator evenly divides the numerator, then the result is immediately converted to the equivalent integer. This is called the rule of rational canonicalization. Rational numbers may be written as the possibly signed quotient of decimal numerals: an optional sign followed by two non-empty sequences of digits separated by a /. This syntax may be described as follows: ratio ::= [sign] {digit}+ / {digit}+ The second sequence may not consist entirely of zeros. For example: 2/3 ; This is in canonical form 4/6 ; A non-canonical form for the same number -17/23 ; A not very interesting ratio -30517578125/32768 ; This is (-5/2)^15 10/5 ; The canonical form for this is 2 To notate rational numbers in radices other than ten, one uses the same radix specifiers (one of #nnR, #O, #B, or #X) as for integers. For example: #o-101/75 ; Octal notation for -65/61 #3r120/21 ; Ternary notation for 15/7 #Xbc/ad ; Hexadecimal notation for 188/173 #xFADED/FACADE ; Hexadecimal notation for 1027565/16435934 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.1.3. <## Floating-Point Numbers ##> Common Lisp allows an implementation to provide one or more kinds of floating-point number, which collectively make up the type float. Now a floating-point number is a (mathematical) rational number of the form s * f * b^(ep), where s is +1 or -1, the sign; b is an integer greater than 1, the base or radix of the representation; p is a positive integer, the precision (in base-b digits) of the floating-point number; f is a positive integer between b^(p-1) and (b^p)-1 (inclusive), the significand; and e is an integer, the exponent. The value of p and the range of e depends on the implementation and on the type of floating-point number within that implementation. In addition, there is a floating-point zero; depending on the implementation, there may also be a "minus zero." If there is no minus zero, then 0.0 and -0.0 are both interpreted as simply a floating-point zero. . . . . . . . . . . . . . . . . . . . . Implementation note: The form of the above description should not be construed to require the internal representation to be in sign-magnitude form. Two's- complement and other representations are also acceptable. Note that the radix of the internal representation may be other than 2, as on the IBM 360 and 370, which use radix 16; see float-radix. . . . . . . . . . . . . . . . . . . . . Floating-point numbers may be provided in a variety of precisions and sizes, depending on the implementation. High-quality floating-point software tends to depend critically on the precise nature of the floating-point arithmetic and so may not always be completely portable. As an aid in writing programs that are moderately portable, however, certain definitions are made here: * A short floating-point number (type short-float) is of the representation of smallest fixed precision provided by an implementation. * A long floating-point number (type long-float) is of the representation of the largest fixed precision provided by an implementation. * Intermediate between short and long formats are two others, arbitrarily called single and double (types single-float and double-float). The precise definition of these categories is implementation-dependent. However, the rough intent is that short floating-point numbers be precise to at least four decimal places (but also have a space-efficient representation); single floating-point numbers, to at least seven decimal places; and double floating-point numbers, to at least fourteen decimal places. It is suggested that the precision (measured in bits, computed as p * (log2 b) and the exponent size (also measured in bits, computed as the base-2 logarithm of 1 plus the maximum exponent value) be at least as great as the values in table 2-1. ............................................................................... Table 2-1: Recommended Minimum Floating-Point Precision and Exponent Size Format Minimum Precision Minimum Exponent Size ---------------------------------------------------- Short 13 bits 5 bits Single 24 bits 8 bits Double 50 bits 8 bits Long 50 bits 8 bits ---------------------------------------------------- ............................................................................... Floating-point numbers are written in either decimal fraction or computerized scientific notation: an optional sign, then a non-empty sequence of digits with an embedded decimal point, then an optional decimal exponent specification. If there is no exponent specifier, then the decimal point is required, and there must be digits after it. The exponent specifier consists of an exponent marker, an optional sign, and a non-empty sequence of digits. For preciseness, here is a modified-BNF description of floating-point notation. floating-point-number ::= [sign] {digit}* decimal-point {digit}+ [exponent] | [sign] {digit}+ [decimal-point {digit}*] exponent sign ::= + | - decimal-point ::= . digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 exponent ::= exponent-marker [sign] {digit}+ exponent-marker ::= e | s | f | d | l | E | S | F | D | L If no exponent specifier is present, or if the exponent marker e (or E) is used, then the precise format to be used is not specified. When such a representation is read and converted to an internal floating-point data object, the format specified by the variable *read-default-float-format* is used; the initial value of this variable is single-float. The letters s, f, d, and l (or their respective uppercase equivalents) explicitly specify the use of short, single, double, and long format, respectively. Examples of floating-point numbers: 0.0 ; Floating-point zero in default format 0E0 ; Also floating-point zero in default format -.0 ; This may be a zero or a minus zero, ; depending on the implementation 0. ; The integer zero, not a floating-point zero! 0.0s0 ; A floating-point zero in short format 0s0 ; Also a floating-point zero in short format 3.1415926535897932384d0 ; A double-format approximation to pi 6.02E+23 ; Avogadro's number, in default format 602E+21 ; Also Avogadro's number, in default format 3.010299957f-1 ; log10(2), in single format -0.000000001s9 ; e^(pi*i) in short format, the hard way __Notice of correction.__ | The first edition unfortunately listed an incorrect value (3.1010299957f-1) | for the base-10 logarithm of 2. | The internal format used for an external representation depends only on the exponent marker and not on the number of decimal digits in the external representation. While Common Lisp provides terminology and notation sufficient to accommodate four distinct floating-point formats, not all implementations will have the means to support that many distinct formats. An implementation is therefore permitted to provide fewer than four distinct internal floating-point formats, in which case at least one of them will be "shared" by more than one of the external format names short, single, double, and long according to the following rules: * If one internal format is provided, then it is considered to be single, but serves also as short, double, and long. The data types short-float, single- float, double-float, and long-float are considered to be identical. An expression such as (eql 1.0s0 1.0d0) will be true in such an implementation because the two numbers 1.0s0 and 1.0d0 will be converted into the same internal format and therefore be considered to have the same data type, despite the differing external syntax. Similarly, (typep 1.0L0 'short-float) will be true in such an implementation. For output purposes all floating-point numbers are assumed to be of single format and thus will print using the exponent letter E or F. * If two internal formats are provided, then either of two correspondences may be used, depending on which is the more appropriate: - One format is short; the other is single and serves also as double and long. The data types single-float, double-float, and long-float are considered to be identical, but short-float is distinct. An expression such as (eql 1.0s0 1.0d0) will be false, but (eql 1.0f0 1.0d0) will be true. Similarly, (typep 1.0L0 'short-float) will be false, but (typep 1.0L0 'single-float) will be true. For output purposes all floating-point numbers are assumed to be of short or single format. - One format is single and serves also as short; the other is double and serves also as long. The data types short-float and single-float are considered to be identical, and the data types double-float and long-float are considered to be identical. An expression such as (eql 1.0s0 1.0d0) will be false, as will (eql 1.0f0 1.0d0); but (eql 1.0d0 1.0L0) will be true. Similarly, (typep 1.0L0 'short-float) will be false, but (typep 1.0L0 'double-float) will be true. For output purposes all floating-point numbers are assumed to be of single or double format. * If three internal formats are provided, then either of two correspondences may be used, depending on which is the more appropriate: - One format is short; another format is single; and the third format is double and serves also as long. Similar constraints apply. - One format is single and serves also as short; another is double; and the third format is long. . . . . . . . . . . . . . . . . . . . . Implementation note: It is recommended that an implementation provide as many distinct floating-point formats as feasible, using table 2-1 as a guideline. Ideally, short-format floating-point numbers should have an "immediate" representation that does not require heap allocation; single-format floating-point numbers should approximate IEEE proposed standard single- format floating-point numbers; and double-format floating-point numbers should approximate IEEE proposed standard double-format floating-point numbers [23,17,16]. . . . . . . . . . . . . . . . . . . . . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.1.4. <## Complex Numbers ##> Complex numbers (type complex) are represented in Cartesian form, with a real part and an imaginary part, each of which is a non-complex number (integer, ratio, or floating-point number). It should be emphasized that the parts of a complex number are not necessarily floating-point numbers; in this, Common Lisp is like PL/I and differs from Fortran. However, both parts must be of the same type: either both are rational, or both are of the same floating-point format. Complex numbers may be notated by writing the characters #C followed by a list of the real and imaginary parts. If the two parts as notated are not of the same type, then they are converted according to the rules of floating-point contagion as described in chapter 12. (Indeed, #C(a b) is equivalent to #,(complex a b); see the description of the function complex.) For example: #C(3.0s1 2.0s-1) ; Real and imaginary parts are short format #C(5 -3) ; A Gaussian integer #C(5/3 7.0) ; Will be converted internally to #C(1.66666 7.0) #C(0 1) ; The imaginary unit, that is, i The type of a specific complex number is indicated by a list of the word complex and the type of the components; for example, a specialized representation for complex numbers with short floating-point parts would be of type (complex short-float). The type complex encompasses all complex representations. A complex number of type (complex rational), that is, one whose components are rational, can never have a zero imaginary part. If the result of a computation would be a complex rational with a zero imaginary part, the result is immediately converted to a non-complex rational number by taking the real part. This is called the rule of complex canonicalization. This rule does not apply to floating-point complex numbers; #C(5.0 0.0) and 5.0 are different. ------------------------------------------------------------------------------- 2.2. <### Characters ###> Characters are represented as data objects of type character. There are two subtypes of interest, called standard-char and string-char. : X3J13 voted in March 1989 <11> to remove the type string-char. | A character object can be notated by writing #\ followed by the character itself. For example, #\g means the character object for a lowercase g. This works well enough for printing characters. Non-printing characters have names, and can be notated by writing #\ and then the name; for example, #\Space (or #\SPACE or #\space or #\sPaCE) means the space character. The syntax for character names after #\ is the same as that for symbols. However, only character names that are known to the particular implementation may be used. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.2.1. <## Standard Characters ##> Common Lisp defines a standard character set (subtype standard-char) for two purposes. Common Lisp programs that are written in the standard character set can be read by any Common Lisp implementation; and Common Lisp programs that use only standard characters as data objects are most likely to be portable. The Common Lisp character set consists of a space character #\Space, a newline character #\Newline, and the following ninety-four non-blank printing characters or their equivalents: ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~ The Common Lisp standard character set is apparently equivalent to the ninety-five standard ASCII printing characters plus a newline character. Nevertheless, Common Lisp is designed to be relatively independent of the ASCII character encoding. For example, the collating sequence is not specified except to say that digits must be properly ordered, the uppercase letters must be properly ordered, and the lowercase letters must be properly ordered (see char< for a precise specification). Other character encodings, particularly EBCDIC, should be easily accommodated (with a suitable mapping of printing characters). Of the ninety-four non-blank printing characters, the following are used in only limited ways in the syntax of Common Lisp programs: [ ] { } ? ! ^ _ ~ $ % All of these characters except ! and _ are used within format strings as : formatting directives. Except for this, [, ], {, }, ?, and ! are not used in : Common Lisp and are reserved to the user for syntactic extensions; ^ and _ are : not yet used in Common Lisp but are part of the syntax of reserved tokens and : are reserved to implementors; ~ is not yet used in Common Lisp and is reserved : to implementors; and $ and % are normally regarded as alphabetic characters but: are not used in the names of any standard Common Lisp functions, variables, or : other entities. : X3J13 voted in June 1989 <139> to add a format directive ~_ (see chapter 27).| The following characters are called semi-standard: #\Backspace #\Tab #\Linefeed #\Page #\Return #\Rubout Not all implementations of Common Lisp need to support them; but those implementations that use the standard ASCII character set should support them, treating them as corresponding respectively to the ASCII characters BS (octal code 010), HT (011), LF (012), FF (014), CR (015), and DEL (177). These characters are not members of the subtype standard-char unless synonymous with one of the standard characters specified above. For example, in a given implementation it might be sensible for the implementor to define #\Linefeed or #\Return to be synonymous with #\Newline, or #\Tab to be synonymous with #\Space. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.2.2. <## Line Divisions ##> The treatment of line divisions is one of the most difficult issues in designing portable software, simply because there is so little agreement among operating systems. Some use a single character to delimit lines; the recommended ASCII character for this purpose is the line feed character LF (also called the new line character, NL), but some systems use the carriage return character CR. Much more common is the two-character sequence CR followed by LF. Frequently line divisions have no representation as a character but are implicit in the structuring of a file into records, each record containing a line of text. A deck of punched cards has this structure, for example. Common Lisp provides an abstract interface by requiring that there be a single character, #\Newline, that within the language serves as a line delimiter. (The language C has a similar requirement.) An implementation of Common Lisp must translate between this internal single-character representation and whatever external representation(s) may be used. . . . . . . . . . . . . . . . . . . . . Implementation note: How the character called #\Newline is represented internally is not specified here, but it is strongly suggested that the ASCII LF character be used in Common Lisp implementations that use the ASCII character encoding. The ASCII CR character is a workable, but in most cases inferior, alternative. . . . . . . . . . . . . . . . . . . . . When the first edition was written it was not yet clear that UNIX would become so widely accepted. The decision to represent the line delimiter as a single character has proved to be a good one. The requirement that a line division be represented as a single character has certain consequences. A character string written in the middle of a program in such a way as to span more than one line must contain exactly one character to represent each line division. Consider this code fragment: (setq a-string "This string contains forty-two characters.") Between g and c there must be exactly one character, #\Newline; a two-character sequence, such as #\Return and then #\Newline, is not acceptable, nor is the absence of a character. The same is true between s and f. When the character #\Newline is written to an output file, the Common Lisp implementation must take the appropriate action to produce a line division. This might involve writing out a record or translating #\Newline to a CR/LF sequence. . . . . . . . . . . . . . . . . . . . . Implementation note: If an implementation uses the ASCII character encoding, uses the CR/LF sequence externally to delimit lines, uses LF to represent #\Newline internally, and supports #\Return as a data object corresponding to the ASCII character CR, the question arises as to what action to take when the program writes out #\Return followed by #\Newline. It should first be noted that #\Return is not a standard Common Lisp character, and the action to be taken when #\Return is written out is therefore not defined by the Common Lisp language. A plausible approach is to buffer the #\Return character and suppress it if and only if the next character is #\Newline (the net effect is to generate a CR/LF sequence). Another plausible approach is simply to ignore the difficulty and declare that writing #\Return and then #\Newline results in the sequence CR/CR/LF in the output. . . . . . . . . . . . . . . . . . . . . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.2.3. <## Non-standard Characters ##> Any implementation may provide additional characters, whether printing characters or named characters. Some plausible examples: #\pi #\alpha #\Break #\Home-Up #\Escape The use of such characters may render Common Lisp programs non-portable. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : 2.2.4. <## Character Attributes ##> : : Every object of type character has three attributes: code, bits, and font. : The code attribute is intended to distinguish among the printed glyphs and : formatting functions for characters; it is a numerical encoding of the : character proper. The bits attribute allows extra flags to be associated with : a character. The font attribute permits a specification of the style of the : glyphs (such as italics). Each of these attributes may be understood to be a : non-negative integer. : : The font attribute may be notated in unsigned decimal notation between the # : and the \. For example, #3\a means the letter a in font 3. This might mean : the same thing as #\alpha if font 3 were used to represent Greek letters. Note: that not all Common Lisp implementations provide for non-zero font attributes; : see char-font-limit. : : The bits attribute may be notated by preceding the name of the character by : the names or initials of the bits, separated by hyphens. The character itself : may be written instead of the name, preceded if necessary by \. For example: : : #\Control-Meta-Return #\Meta-Control-Q : #\Hyper-Space #\Meta-a : #\Control-A #\Meta-Hyper-\: : #\C-M-Return #\Hyper-\pi : : Note that not all Common Lisp implementations provide for non-zero bits : attributes; see char-bits-limit. : X3J13 voted in March 1989 <11> to replace the notion of bits and font | attributes with that of implementation-defined attributes. | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.2.5. <## String Characters ##> Any character whose bits and font attributes are zero may be contained in : strings. All such characters together constitute a subtype of the characters; : this subtype is called string-char. : X3J13 voted in March 1989 <11> to eliminate the type string-char. Two new | subtypes of character are base-character, defined to be equivalent to the | result of the function call | (upgraded-array-element-type 'standard-char) | and extended-character, defined to be equivalent to the type specifier | (and character (not base-character)) | | An implementation may support additional subtypes of character that may or | may not be supertypes of base-character. In addition, an implementation may | define base-character to be equivalent to character. The choice of any base | characters that are not standard characters is implementation-defined. Only | base characters can be elements of a base string. No upper bound is specified | for the number of distinct characters of type base-character -- that is | implementation-dependent -- but the lower bound is 96, the number of standard | Common Lisp characters. | ------------------------------------------------------------------------------- 2.3. <### Symbols ###> Symbols are Lisp data objects that serve several purposes and have several interesting characteristics. Every object of type symbol has a name, called its print name. Given a symbol, one can obtain its name in the form of a string. Conversely, given the name of a symbol as a string, one can obtain the symbol itself. (More precisely, symbols are organized into packages, and all the symbols in a package are uniquely identified by name. See chapter 11.) Symbols have a component called the property list, or plist. By convention this is always a list whose even-numbered components (calling the first component zero) are symbols, here functioning as property names, and whose odd-numbered components are associated property values. Functions are provided for manipulating this property list; in effect, these allow a symbol to be treated as an extensible record structure. Symbols are also used to represent certain kinds of variables in Lisp programs, and there are functions for dealing with the values associated with symbols in this role. A symbol can be notated simply by writing its name. If its name is not empty, and if the name consists only of uppercase alphabetic, numeric, or certain pseudo-alphabetic special characters (but not delimiter characters such as parentheses or space), and if the name of the symbol cannot be mistaken for a number, then the symbol can be notated by the sequence of characters in its name. Any uppercase letters that appear in the (internal) name may be written in either case in the external notation (more on this below). For example: FROBBOZ ; The symbol whose name is FROBBOZ frobboz ; Another way to notate the same symbol fRObBoz ; Yet another way to notate it unwind-protect ; A symbol with a - in its name +$ ; The symbol named +$ 1+ ; The symbol named 1+ +1 ; This is the integer 1, not a symbol pascal_style ; This symbol has an underscore in its name b^2-4*a*c ; This is a single symbol! ; It has several special characters in its name file.rel.43 ; This symbol has periods in its name /usr/games/zork ; This symbol has slashes in its name In addition to letters and numbers, the following characters are normally considered to be alphabetic for the purposes of notating symbols: + - * / @ $ % ^ & _ = < > ~ . Some of these characters have conventional purposes for naming things; for example, symbols that name special variables generally have names beginning and ending with *. The last character listed above, the period, is considered alphabetic provided that a token does not consist entirely of periods. A single period standing by itself is used in the notation of conses and dotted lists; a token consisting of two or more periods is syntactically illegal. (The period also serves as the decimal point in the notation of numbers.) The following characters are also alphabetic by default but are explicitly reserved to the user for definition as reader macro characters (see section 22.1.3) or any other desired purpose and therefore should not be used routinely in names of symbols: ? ! [ ] { } A symbol may have uppercase letters, lowercase letters, or both in its print name. However, the Lisp reader normally converts lowercase letters to the corresponding uppercase letters when reading symbols. The net effect is that most of the time case makes no difference when notating symbols. Case does make a difference internally and when printing a symbol. Internally the symbols that name all standard Common Lisp functions, variables, and keywords have uppercase names; their names appear in lowercase in this book for readability. Typing such names with lowercase letters works because the function read will convert lowercase letters to the equivalent uppercase letters. X3J13 voted in June 1989 <150> to introduce readtable-case, which controls | whether read will alter the case of letters read as part of the name of a | symbol. | If a symbol cannot be simply notated by the characters of its name because the (internal) name contains special characters or lowercase letters, then there are two "escape" conventions for notating them. Writing a \ character before any character causes the character to be treated itself as an ordinary character for use in a symbol name; in particular, it suppresses internal conversion of lowercase letters to their uppercase equivalents. If any character in a notation is preceded by \, then that notation can never be interpreted as a number. For example: \( ; The symbol whose name is ( \+1 ; The symbol whose name is +1 +\1 ; Also the symbol whose name is +1 \frobboz ; The symbol whose name is fROBBOZ 3.14159265\s0 ; The symbol whose name is 3.14159265s0 3.14159265\S0 ; A different symbol, whose name is 3.14159265S0 3.14159265s0 ; A short-format floating-point approximation to pi APL\\360 ; The symbol whose name is APL\360 apl\\360 ; Also the symbol whose name is APL\360 \(b^2\)\ -\ 4*a*c ; The name is (B^2) - 4*A*C; ; it has parentheses and two spaces in it \(\b^2\)\ -\ 4*\a*\c ; The name is (b^2) - 4*a*c; ; the letters are explicitly lowercase It may be tedious to insert a \ before every delimiter character in the name of a symbol if there are many of them. An alternative convention is to surround the name of a symbol with vertical bars; these cause every character between them to be taken as part of the symbol's name, as if \ had been written before each one, excepting only | itself and \, which must nevertheless be preceded by \. For example: |"| ; The same as writing \" |(b^2) - 4*a*c| ; The name is (b^2) - 4*a*c |frobboz| ; The name is frobboz, not FROBBOZ |APL\360| ; The name is APL360, because the \ quotes the 3 |APL\\360| ; The name is APL\360 |apl\\360| ; The name is apl\360 |\|\|| ; Same as \|\|: the name is || |(B^2) - 4*A*C| ; The name is (B^2) - 4*A*C; ; it has parentheses and two spaces in it |(b^2) - 4*a*c| ; The name is (b^2) - 4*a*c ------------------------------------------------------------------------------- 2.4. <### Lists and Conses ###> A cons is a record structure containing two components called the car and the cdr. Conses are used primarily to represent lists. A list is recursively defined to be either the empty list or a cons whose cdr component is a list. A list is therefore a chain of conses linked by their cdr components and terminated by nil, the empty list. The car components of the conses are called the elements of the list. For each element of the list there is a cons. The empty list has no elements at all. A list is notated by writing the elements of the list in order, separated by blank space (space, tab, or return characters) and surrounded by parentheses. (a b c) ; A list of three symbols (2.0s0 (a 1) #\*) ; A list of three things: a short floating-point ; number, another list, and a character object The empty list nil therefore can be written as (), because it is a list with no elements. A dotted list is one whose last cons does not have nil for its cdr, rather some other data object (which is also not a cons, or the first-mentioned cons would not be the last cons of the list). Such a list is called "dotted" because of the special notation used for it: the elements of the list are written between parentheses as before, but after the last element and before the right parenthesis are written a dot (surrounded by blank space) and then the cdr of the last cons. As a special case, a single cons is notated by writing t