Initial checkin for dpans

All-Symbols.lisp

@@ -0,0 +1,145 @@
+;;; -*- Mode: LISP; Syntax: ANSI-Common-Lisp; Package: CL-USER -*-
+;;; As of October 5, 1993, these are believed to be the 978 external symbols 
+;;; of the ANSI-CL package COMMON-LISP.
+
+(&ALLOW-OTHER-KEYS &AUX &BODY &ENVIRONMENT &KEY &OPTIONAL &REST &WHOLE * ** ***
+ *BREAK-ON-SIGNALS* *COMPILE-FILE-PATHNAME* *COMPILE-FILE-TRUENAME* *COMPILE-PRINT*
+ *COMPILE-VERBOSE* *DEBUG-IO* *DEBUGGER-HOOK* *DEFAULT-PATHNAME-DEFAULTS* *ERROR-OUTPUT*
+ *FEATURES* *GENSYM-COUNTER* *LOAD-PATHNAME* *LOAD-PRINT* *LOAD-TRUENAME* *LOAD-VERBOSE*
+ *MACROEXPAND-HOOK* *MODULES* *PACKAGE* *PRINT-ARRAY* *PRINT-BASE* *PRINT-CASE* *PRINT-CIRCLE*
+ *PRINT-ESCAPE* *PRINT-GENSYM* *PRINT-LENGTH* *PRINT-LEVEL* *PRINT-LINES* *PRINT-MISER-WIDTH*
+ *PRINT-PPRINT-DISPATCH* *PRINT-PRETTY* *PRINT-RADIX* *PRINT-READABLY* *PRINT-RIGHT-MARGIN*
+ *QUERY-IO* *RANDOM-STATE* *READ-BASE* *READ-DEFAULT-FLOAT-FORMAT* *READ-EVAL* *READ-SUPPRESS*
+ *READTABLE* *STANDARD-INPUT* *STANDARD-OUTPUT* *TERMINAL-IO* *TRACE-OUTPUT* + ++ +++ - / //
+ /// /= 1+ 1- < <= = > >= ABORT ABS ACONS ACOS ACOSH ADD-METHOD ADJOIN ADJUST-ARRAY
+ ADJUSTABLE-ARRAY-P ALLOCATE-INSTANCE ALPHA-CHAR-P ALPHANUMERICP AND APPEND APPLY APROPOS
+ APROPOS-LIST AREF ARITHMETIC-ERROR ARITHMETIC-ERROR-OPERANDS ARITHMETIC-ERROR-OPERATION ARRAY
+ ARRAY-DIMENSION ARRAY-DIMENSION-LIMIT ARRAY-DIMENSIONS ARRAY-DISPLACEMENT ARRAY-ELEMENT-TYPE
+ ARRAY-HAS-FILL-POINTER-P ARRAY-IN-BOUNDS-P ARRAY-RANK ARRAY-RANK-LIMIT ARRAY-ROW-MAJOR-INDEX
+ ARRAY-TOTAL-SIZE ARRAY-TOTAL-SIZE-LIMIT ARRAYP ASH ASIN ASINH ASSERT ASSOC ASSOC-IF
+ ASSOC-IF-NOT ATAN ATANH ATOM BASE-CHAR BASE-STRING BIGNUM BIT BIT-AND BIT-ANDC1 BIT-ANDC2
+ BIT-EQV BIT-IOR BIT-NAND BIT-NOR BIT-NOT BIT-ORC1 BIT-ORC2 BIT-VECTOR BIT-VECTOR-P BIT-XOR
+ BLOCK BOOLE BOOLE-1 BOOLE-2 BOOLE-AND BOOLE-ANDC1 BOOLE-ANDC2 BOOLE-C1 BOOLE-C2 BOOLE-CLR
+ BOOLE-EQV BOOLE-IOR BOOLE-NAND BOOLE-NOR BOOLE-ORC1 BOOLE-ORC2 BOOLE-SET BOOLE-XOR BOOLEAN
+ BOTH-CASE-P BOUNDP BREAK BROADCAST-STREAM BROADCAST-STREAM-STREAMS BUILT-IN-CLASS BUTLAST
+ BYTE BYTE-POSITION BYTE-SIZE CAAAAR CAAADR CAAAR CAADAR CAADDR CAADR CAAR CADAAR CADADR CADAR
+ CADDAR CADDDR CADDR CADR CALL-ARGUMENTS-LIMIT CALL-METHOD CALL-NEXT-METHOD CAR CASE CATCH
+ CCASE CDAAAR CDAADR CDAAR CDADAR CDADDR CDADR CDAR CDDAAR CDDADR CDDAR CDDDAR CDDDDR CDDDR
+ CDDR CDR CEILING CELL-ERROR CELL-ERROR-NAME CERROR CHANGE-CLASS CHAR CHAR-CODE
+ CHAR-CODE-LIMIT CHAR-DOWNCASE CHAR-EQUAL CHAR-GREATERP CHAR-INT CHAR-LESSP CHAR-NAME
+ CHAR-NOT-EQUAL CHAR-NOT-GREATERP CHAR-NOT-LESSP CHAR-UPCASE CHAR/= CHAR< CHAR<= CHAR= CHAR>
+ CHAR>= CHARACTER CHARACTERP CHECK-TYPE CIS CLASS CLASS-NAME CLASS-OF CLEAR-INPUT CLEAR-OUTPUT
+ CLOSE CLRHASH CODE-CHAR COERCE COMPILATION-SPEED COMPILE COMPILE-FILE COMPILE-FILE-PATHNAME
+ COMPILED-FUNCTION COMPILED-FUNCTION-P COMPILER-MACRO COMPILER-MACRO-FUNCTION COMPLEMENT
+ COMPLEX COMPLEXP COMPUTE-APPLICABLE-METHODS COMPUTE-RESTARTS CONCATENATE CONCATENATED-STREAM
+ CONCATENATED-STREAM-STREAMS COND CONDITION CONJUGATE CONS CONSP CONSTANTLY CONSTANTP CONTINUE
+ CONTROL-ERROR COPY-ALIST COPY-LIST COPY-PPRINT-DISPATCH COPY-READTABLE COPY-SEQ
+ COPY-STRUCTURE COPY-SYMBOL COPY-TREE COS COSH COUNT COUNT-IF COUNT-IF-NOT CTYPECASE DEBUG
+ DECF DECLAIM DECLARATION DECLARE DECODE-FLOAT DECODE-UNIVERSAL-TIME DEFCLASS DEFCONSTANT
+ DEFGENERIC DEFINE-COMPILER-MACRO DEFINE-CONDITION DEFINE-METHOD-COMBINATION
+ DEFINE-MODIFY-MACRO DEFINE-SETF-EXPANDER DEFINE-SYMBOL-MACRO DEFMACRO DEFMETHOD DEFPACKAGE
+ DEFPARAMETER DEFSETF DEFSTRUCT DEFTYPE DEFUN DEFVAR DELETE DELETE-DUPLICATES DELETE-FILE
+ DELETE-IF DELETE-IF-NOT DELETE-PACKAGE DENOMINATOR DEPOSIT-FIELD DESCRIBE DESCRIBE-OBJECT
+ DESTRUCTURING-BIND DIGIT-CHAR DIGIT-CHAR-P DIRECTORY DIRECTORY-NAMESTRING DISASSEMBLE
+ DIVISION-BY-ZERO DO DO* DO-ALL-SYMBOLS DO-EXTERNAL-SYMBOLS DO-SYMBOLS DOCUMENTATION DOLIST
+ DOTIMES DOUBLE-FLOAT DOUBLE-FLOAT-EPSILON DOUBLE-FLOAT-NEGATIVE-EPSILON DPB DRIBBLE
+ DYNAMIC-EXTENT ECASE ECHO-STREAM ECHO-STREAM-INPUT-STREAM ECHO-STREAM-OUTPUT-STREAM ED EIGHTH
+ ELT ENCODE-UNIVERSAL-TIME END-OF-FILE ENDP ENOUGH-NAMESTRING ENSURE-DIRECTORIES-EXIST
+ ENSURE-GENERIC-FUNCTION EQ EQL EQUAL EQUALP ERROR ETYPECASE EVAL EVAL-WHEN EVENP EVERY EXP
+ EXPORT EXPT EXTENDED-CHAR FBOUNDP FCEILING FDEFINITION FFLOOR FIFTH FILE-AUTHOR FILE-ERROR
+ FILE-ERROR-PATHNAME FILE-LENGTH FILE-NAMESTRING FILE-POSITION FILE-STREAM FILE-STRING-LENGTH
+ FILE-WRITE-DATE FILL FILL-POINTER FIND FIND-ALL-SYMBOLS FIND-CLASS FIND-IF FIND-IF-NOT
+ FIND-METHOD FIND-PACKAGE FIND-RESTART FIND-SYMBOL FINISH-OUTPUT FIRST FIXNUM FLET FLOAT
+ FLOAT-DIGITS FLOAT-PRECISION FLOAT-RADIX FLOAT-SIGN FLOATING-POINT-INEXACT
+ FLOATING-POINT-INVALID-OPERATION FLOATING-POINT-OVERFLOW FLOATING-POINT-UNDERFLOW FLOATP
+ FLOOR FMAKUNBOUND FORCE-OUTPUT FORMAT FORMATTER FOURTH FRESH-LINE FROUND FTRUNCATE FTYPE
+ FUNCALL FUNCTION FUNCTION-KEYWORDS FUNCTION-LAMBDA-EXPRESSION FUNCTIONP GCD GENERIC-FUNCTION
+ GENSYM GENTEMP GET GET-DECODED-TIME GET-DISPATCH-MACRO-CHARACTER GET-INTERNAL-REAL-TIME
+ GET-INTERNAL-RUN-TIME GET-MACRO-CHARACTER GET-OUTPUT-STREAM-STRING GET-PROPERTIES
+ GET-SETF-EXPANSION GET-UNIVERSAL-TIME GETF GETHASH GO GRAPHIC-CHAR-P HANDLER-BIND
+ HANDLER-CASE HASH-TABLE HASH-TABLE-COUNT HASH-TABLE-P HASH-TABLE-REHASH-SIZE
+ HASH-TABLE-REHASH-THRESHOLD HASH-TABLE-SIZE HASH-TABLE-TEST HOST-NAMESTRING IDENTITY IF
+ IGNORABLE IGNORE IGNORE-ERRORS IMAGPART IMPORT IN-PACKAGE INCF INITIALIZE-INSTANCE INLINE
+ INPUT-STREAM-P INSPECT INTEGER INTEGER-DECODE-FLOAT INTEGER-LENGTH INTEGERP
+ INTERACTIVE-STREAM-P INTERN INTERNAL-TIME-UNITS-PER-SECOND INTERSECTION INVALID-METHOD-ERROR
+ INVOKE-DEBUGGER INVOKE-RESTART INVOKE-RESTART-INTERACTIVELY ISQRT KEYWORD KEYWORDP LABELS
+ LAMBDA LAMBDA-LIST-KEYWORDS LAMBDA-PARAMETERS-LIMIT LAST LCM LDB LDB-TEST LDIFF
+ LEAST-NEGATIVE-DOUBLE-FLOAT LEAST-NEGATIVE-LONG-FLOAT LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT
+ LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT
+ LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT LEAST-NEGATIVE-SHORT-FLOAT LEAST-NEGATIVE-SINGLE-FLOAT
+ LEAST-POSITIVE-DOUBLE-FLOAT LEAST-POSITIVE-LONG-FLOAT LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT
+ LEAST-POSITIVE-NORMALIZED-LONG-FLOAT LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT
+ LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT LEAST-POSITIVE-SHORT-FLOAT LEAST-POSITIVE-SINGLE-FLOAT
+ LENGTH LET LET* LISP-IMPLEMENTATION-TYPE LISP-IMPLEMENTATION-VERSION LIST LIST*
+ LIST-ALL-PACKAGES LIST-LENGTH LISTEN LISTP LOAD LOAD-LOGICAL-PATHNAME-TRANSLATIONS
+ LOAD-TIME-VALUE LOCALLY LOG LOGAND LOGANDC1 LOGANDC2 LOGBITP LOGCOUNT LOGEQV LOGICAL-PATHNAME
+ LOGICAL-PATHNAME-TRANSLATIONS LOGIOR LOGNAND LOGNOR LOGNOT LOGORC1 LOGORC2 LOGTEST LOGXOR
+ LONG-FLOAT LONG-FLOAT-EPSILON LONG-FLOAT-NEGATIVE-EPSILON LONG-SITE-NAME LOOP LOOP-FINISH
+ LOWER-CASE-P MACHINE-INSTANCE MACHINE-TYPE MACHINE-VERSION MACRO-FUNCTION MACROEXPAND
+ MACROEXPAND-1 MACROLET MAKE-ARRAY MAKE-BROADCAST-STREAM MAKE-CONCATENATED-STREAM
+ MAKE-CONDITION MAKE-DISPATCH-MACRO-CHARACTER MAKE-ECHO-STREAM MAKE-HASH-TABLE MAKE-INSTANCE
+ MAKE-INSTANCES-OBSOLETE MAKE-LIST MAKE-LOAD-FORM MAKE-LOAD-FORM-SAVING-SLOTS MAKE-METHOD
+ MAKE-PACKAGE MAKE-PATHNAME MAKE-RANDOM-STATE MAKE-SEQUENCE MAKE-STRING
+ MAKE-STRING-INPUT-STREAM MAKE-STRING-OUTPUT-STREAM MAKE-SYMBOL MAKE-SYNONYM-STREAM
+ MAKE-TWO-WAY-STREAM MAKUNBOUND MAP MAP-INTO MAPC MAPCAN MAPCAR MAPCON MAPHASH MAPL MAPLIST
+ MASK-FIELD MAX MEMBER MEMBER-IF MEMBER-IF-NOT MERGE MERGE-PATHNAMES METHOD METHOD-COMBINATION
+ METHOD-COMBINATION-ERROR METHOD-QUALIFIERS MIN MINUSP MISMATCH MOD MOST-NEGATIVE-DOUBLE-FLOAT
+ MOST-NEGATIVE-FIXNUM MOST-NEGATIVE-LONG-FLOAT MOST-NEGATIVE-SHORT-FLOAT
+ MOST-NEGATIVE-SINGLE-FLOAT MOST-POSITIVE-DOUBLE-FLOAT MOST-POSITIVE-FIXNUM
+ MOST-POSITIVE-LONG-FLOAT MOST-POSITIVE-SHORT-FLOAT MOST-POSITIVE-SINGLE-FLOAT MUFFLE-WARNING
+ MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL MULTIPLE-VALUE-LIST MULTIPLE-VALUE-PROG1
+ MULTIPLE-VALUE-SETQ MULTIPLE-VALUES-LIMIT NAME-CHAR NAMESTRING NBUTLAST NCONC NEXT-METHOD-P
+ NIL NINTERSECTION NINTH NO-APPLICABLE-METHOD NO-NEXT-METHOD NOT NOTANY NOTEVERY NOTINLINE
+ NRECONC NREVERSE NSET-DIFFERENCE NSET-EXCLUSIVE-OR NSTRING-CAPITALIZE NSTRING-DOWNCASE
+ NSTRING-UPCASE NSUBLIS NSUBST NSUBST-IF NSUBST-IF-NOT NSUBSTITUTE NSUBSTITUTE-IF
+ NSUBSTITUTE-IF-NOT NTH NTH-VALUE NTHCDR NULL NUMBER NUMBERP NUMERATOR NUNION ODDP OPEN
+ OPEN-STREAM-P OPTIMIZE OR OTHERWISE OUTPUT-STREAM-P PACKAGE PACKAGE-ERROR
+ PACKAGE-ERROR-PACKAGE PACKAGE-NAME PACKAGE-NICKNAMES PACKAGE-SHADOWING-SYMBOLS
+ PACKAGE-USE-LIST PACKAGE-USED-BY-LIST PACKAGEP PAIRLIS PARSE-ERROR PARSE-INTEGER
+ PARSE-NAMESTRING PATHNAME PATHNAME-DEVICE PATHNAME-DIRECTORY PATHNAME-HOST PATHNAME-MATCH-P
+ PATHNAME-NAME PATHNAME-TYPE PATHNAME-VERSION PATHNAMEP PEEK-CHAR PHASE PI PLUSP POP POSITION
+ POSITION-IF POSITION-IF-NOT PPRINT PPRINT-DISPATCH PPRINT-EXIT-IF-LIST-EXHAUSTED PPRINT-FILL
+ PPRINT-INDENT PPRINT-LINEAR PPRINT-LOGICAL-BLOCK PPRINT-NEWLINE PPRINT-POP PPRINT-TAB
+ PPRINT-TABULAR PRIN1 PRIN1-TO-STRING PRINC PRINC-TO-STRING PRINT PRINT-NOT-READABLE
+ PRINT-NOT-READABLE-OBJECT PRINT-OBJECT PRINT-UNREADABLE-OBJECT PROBE-FILE PROCLAIM PROG PROG*
+ PROG1 PROG2 PROGN PROGRAM-ERROR PROGV PROVIDE PSETF PSETQ PUSH PUSHNEW QUOTE RANDOM
+ RANDOM-STATE RANDOM-STATE-P RASSOC RASSOC-IF RASSOC-IF-NOT RATIO RATIONAL RATIONALIZE
+ RATIONALP READ READ-BYTE READ-CHAR READ-CHAR-NO-HANG READ-DELIMITED-LIST READ-FROM-STRING
+ READ-LINE READ-PRESERVING-WHITESPACE READ-SEQUENCE READER-ERROR READTABLE READTABLE-CASE
+ READTABLEP REAL REALP REALPART REDUCE REINITIALIZE-INSTANCE REM REMF REMHASH REMOVE
+ REMOVE-DUPLICATES REMOVE-IF REMOVE-IF-NOT REMOVE-METHOD REMPROP RENAME-FILE RENAME-PACKAGE
+ REPLACE REQUIRE REST RESTART RESTART-BIND RESTART-CASE RESTART-NAME RETURN RETURN-FROM
+ REVAPPEND REVERSE ROOM ROTATEF ROUND ROW-MAJOR-AREF RPLACA RPLACD SAFETY SATISFIES SBIT
+ SCALE-FLOAT SCHAR SEARCH SECOND SEQUENCE SERIOUS-CONDITION SET SET-DIFFERENCE
+ SET-DISPATCH-MACRO-CHARACTER SET-EXCLUSIVE-OR SET-MACRO-CHARACTER SET-PPRINT-DISPATCH
+ SET-SYNTAX-FROM-CHAR SETF SETQ SEVENTH SHADOW SHADOWING-IMPORT SHARED-INITIALIZE SHIFTF
+ SHORT-FLOAT SHORT-FLOAT-EPSILON SHORT-FLOAT-NEGATIVE-EPSILON SHORT-SITE-NAME SIGNAL
+ SIGNED-BYTE SIGNUM SIMPLE-ARRAY SIMPLE-BASE-STRING SIMPLE-BIT-VECTOR SIMPLE-BIT-VECTOR-P
+ SIMPLE-CONDITION SIMPLE-CONDITION-FORMAT-ARGUMENTS SIMPLE-CONDITION-FORMAT-CONTROL
+ SIMPLE-ERROR SIMPLE-STRING SIMPLE-STRING-P SIMPLE-TYPE-ERROR SIMPLE-VECTOR SIMPLE-VECTOR-P
+ SIMPLE-WARNING SIN SINGLE-FLOAT SINGLE-FLOAT-EPSILON SINGLE-FLOAT-NEGATIVE-EPSILON SINH SIXTH
+ SLEEP SLOT-BOUNDP SLOT-EXISTS-P SLOT-MAKUNBOUND SLOT-MISSING SLOT-UNBOUND SLOT-VALUE
+ SOFTWARE-TYPE SOFTWARE-VERSION SOME SORT SPACE SPECIAL SPECIAL-OPERATOR-P SPEED SQRT
+ STABLE-SORT STANDARD STANDARD-CHAR STANDARD-CHAR-P STANDARD-CLASS STANDARD-GENERIC-FUNCTION
+ STANDARD-METHOD STANDARD-OBJECT STEP STORAGE-CONDITION STORE-VALUE STREAM STREAM-ELEMENT-TYPE
+ STREAM-ERROR STREAM-ERROR-STREAM STREAM-EXTERNAL-FORMAT STREAMP STRING STRING-CAPITALIZE
+ STRING-DOWNCASE STRING-EQUAL STRING-GREATERP STRING-LEFT-TRIM STRING-LESSP STRING-NOT-EQUAL
+ STRING-NOT-GREATERP STRING-NOT-LESSP STRING-RIGHT-TRIM STRING-STREAM STRING-TRIM
+ STRING-UPCASE STRING/= STRING< STRING<= STRING= STRING> STRING>= STRINGP STRUCTURE
+ STRUCTURE-CLASS STRUCTURE-OBJECT STYLE-WARNING SUBLIS SUBSEQ SUBSETP SUBST SUBST-IF
+ SUBST-IF-NOT SUBSTITUTE SUBSTITUTE-IF SUBSTITUTE-IF-NOT SUBTYPEP SVREF SXHASH SYMBOL
+ SYMBOL-FUNCTION SYMBOL-MACROLET SYMBOL-NAME SYMBOL-PACKAGE SYMBOL-PLIST SYMBOL-VALUE SYMBOLP
+ SYNONYM-STREAM SYNONYM-STREAM-SYMBOL T TAGBODY TAILP TAN TANH TENTH TERPRI THE THIRD THROW
+ TIME TRACE TRANSLATE-LOGICAL-PATHNAME TRANSLATE-PATHNAME TREE-EQUAL TRUENAME TRUNCATE
+ TWO-WAY-STREAM TWO-WAY-STREAM-INPUT-STREAM TWO-WAY-STREAM-OUTPUT-STREAM TYPE TYPE-ERROR
+ TYPE-ERROR-DATUM TYPE-ERROR-EXPECTED-TYPE TYPE-OF TYPECASE TYPEP UNBOUND-SLOT
+ UNBOUND-SLOT-INSTANCE UNBOUND-VARIABLE UNDEFINED-FUNCTION UNEXPORT UNINTERN UNION UNLESS
+ UNREAD-CHAR UNSIGNED-BYTE UNTRACE UNUSE-PACKAGE UNWIND-PROTECT
+ UPDATE-INSTANCE-FOR-DIFFERENT-CLASS UPDATE-INSTANCE-FOR-REDEFINED-CLASS
+ UPGRADED-ARRAY-ELEMENT-TYPE UPGRADED-COMPLEX-PART-TYPE UPPER-CASE-P USE-PACKAGE USE-VALUE
+ USER-HOMEDIR-PATHNAME VALUES VALUES-LIST VARIABLE VECTOR VECTOR-POP VECTOR-PUSH
+ VECTOR-PUSH-EXTEND VECTORP WARN WARNING WHEN WILD-PATHNAME-P WITH-ACCESSORS
+ WITH-COMPILATION-UNIT WITH-CONDITION-RESTARTS WITH-HASH-TABLE-ITERATOR WITH-INPUT-FROM-STRING
+ WITH-OPEN-FILE WITH-OPEN-STREAM WITH-OUTPUT-TO-STRING WITH-PACKAGE-ITERATOR
+ WITH-SIMPLE-RESTART WITH-SLOTS WITH-STANDARD-IO-SYNTAX WRITE WRITE-BYTE WRITE-CHAR WRITE-LINE
+ WRITE-SEQUENCE WRITE-STRING WRITE-TO-STRING Y-OR-N-P YES-OR-NO-P ZEROP)

Change-Log.text

@@ -0,0 +1,1517 @@
+Comparing Draft 14.10 with Draft 15.17 ...
+============================================================
+           File: chap-0-edit-history.tex
+============================================================
+Source compare made by kmp on 5/11/94 23:03:14		-*-Mode:Fundamental-*-
+of File B:>ansi-cl>spec>source>chap-0-edit-history.tex.82
+with File B:>ansi-cl>spec>source>chap-0-edit-history.tex.89
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.82, Line #134:
+ 09-Sep-92 & Samson    & Public Review Comments (\#1).\cr
+ 22-Oct-92 & Rose, Yen & Public Review Comments (\#2).\cr
+ 23-Oct-92 & Staley    & Public Review Comments (\#3).\cr
+ 09-Nov-92 & Barrett   & Public Review Comments (\#4).\cr
+ 11-Nov-92 & Moon      & Public Review Comments (\#5).\cr
+ 17-Nov-92 & Loosemore & Public Review Comments (\#6).\cr
+ 23-Nov-92 & Margolin  & Public Review Comments (\#7).\cr
+ 23-Nov-92 & Withington & Public Review Comments (\#8a).\cr
+ 23-Nov-92 & Feinberg   & Public Review Comments (\#8b).\cr
+ 23-Nov-92 & Wechsler   & Public Review Comments (\#8c).\cr
+ 23-Nov-92 & Moore     & Public Review Comments (\#9).\cr
+ 23-Nov-92 & Flanagan  & Public Review Comments (\#10).\cr
+ 23-Nov-92 & Dalton    & Public Review Comments (\#11).\cr
+ 23-Nov-92 & Gallagher & Public Review Comments (\#12).\cr
+ 23-Nov-92 & Norvig    & Public Review Comments (\#13).\cr
+ 24-Nov-92 & Robertson & Public Review Comments (\#14).\cr
+ 23-Nov-92 & Kawabe    & Public Review Comments (\#15).\cr
+ 23-Nov-92 & Barrett   & Public Review Comments (\#16).\cr
+ 23-Nov-92 & Wertheimer & Public Review Comments (\#17).\cr
+ 24-Nov-92 & Pitman    & Public Review Comments (\#18).\cr
+ 24-Nov-92 & Mato Mira & Public Review Comments (\#19).\cr
+ 24-Nov-92 & Philpot   & Public Review Comments (\#20).\cr
+ 30-Aug-93 & Pitman    & Draft 13.65 (for X3J13 consideration). Document X3J13/93-101.\cr
+ 04-Oct-93 & X3J13     & Minor fixes to Draft 13.65 before sending to X3.\cr
+ 05-Oct-93 & Pitman    & Draft {\rev} (for X3 consideration). Document {\DocumentNumber}.\cr
+%??-???-?? & Pitman    & Draft {\rev} (???).\cr
+} $$
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.89, Line #134:
+ 09-Sep-92 & Samson    & Public Review Comments (\#1). Documents X3J13/92-1001 to 92-1003.\cr
+ 22-Oct-92 & Rose, Yen & Public Review Comments (\#2). Documents X3J13/92-1101 to 92-1103.\cr
+ 23-Oct-92 & Staley    & Public Review Comments (\#3). Documents X3J13/92-1201 to 92-1204.\cr
+ 09-Nov-92 & Barrett   & Public Review Comments (\#4). Documents X3J13/92-3101 to 92-3110.\cr
+ 11-Nov-92 & Moon      & Public Review Comments (\#5). Documents X3J13/92-3201 to 92-3248.\cr
+ 17-Nov-92 & Loosemore & Public Review Comments (\#6). Documents X3J13/92-1301 to 92-1335.\cr
+ 23-Nov-92 & Margolin  & Public Review Comments (\#7). Documents X3J13/92-1401 to 92-1419.\cr
+ 23-Nov-92 & Withington & Public Review Comments (\#8a). Documents X3J13/92-1501 to 92-1512.\cr\cr
+ 23-Nov-92 & Feinberg   & Public Review Comments (\#8b). Documents X3J13/92-1601 to 92-1603.\cr
+ 23-Nov-92 & Wechsler   & Public Review Comments (\#8c). Documents X3J13/92-1701 to 92-1703.\cr
+ 23-Nov-92 & Moore     & Public Review Comments (\#9). Documents X3J13/92-1801 to 92-1802.\cr
+ 23-Nov-92 & Flanagan  & Public Review Comments (\#10). Documents X3J13/92-1901 to 92-1910.\cr
+ 23-Nov-92 & Dalton    & Public Review Comments (\#11). Documents X3J13/92-2001 to 92-2012.\cr
+ 23-Nov-92 & Gallagher & Public Review Comments (\#12). Documents X3J13/92-2101 to 92-2103.\cr
+ 23-Nov-92 & Norvig    & Public Review Comments (\#13). Documents X3J13/92-2201 to 92-2208.\cr
+ 24-Nov-92 & Robertson & Public Review Comments (\#14). Document X3J13/92-2301.\cr
+ 23-Nov-92 & Kawabe    & Public Review Comments (\#15). Documents X3J13/92-2401 to 92-2403.\cr
+ 23-Nov-92 & Barrett   & Public Review Comments (\#16). Documents X3J13/92-2511 to X3J13/92-2531.\cr
+ 23-Nov-92 & Wertheimer & Public Review Comments (\#17). Document X3J13/92-2601.\cr
+ 24-Nov-92 & Pitman    & Public Review Comments (\#18). Documents X3J13/92-2701 to 92-2742.\cr
+ 24-Nov-92 & Mato Mira & Public Review Comments (\#19). Documents X3J13/92-2801 to 92-2805.\cr
+ 24-Nov-92 & Philpot   & Public Review Comments (\#20). Document X3J13/92-2901.\cr
+ 23-Nov-92 & Cerys     & Public Review Comments (\#21). Document X3J13/92-3001.\cr
+ 30-Aug-93 & Pitman    & Draft 13.65 (for X3J13 consideration). Document X3J13/93-101.\cr
+ 04-Oct-93 & X3J13     & Minor fixes to Draft 13.65 before sending to X3.\cr
+ 05-Oct-93 & Pitman    & Draft 14.10 (for X3 consideration). Document X3J13/93-102.\cr
+ 08-Nov-93 & Dalton    & ``reply to reply to pr comments''.  Document X3J13/94-311.\cr
+ 04-Apr-94 & Boyer,    & \cr
+           & Kaufmann, & \cr
+           & Moore     & Public Review Comments (\#1).  Document X3J13/94-305.\cr
+ 05-Apr-94 & Pitman    & Public Review Comments (\#2).  Document X3J13/94-306.\cr
+ 14-Mar-94 & Schulenburg & Public Review Comments (\#3).  Document X3J13/94-307.\cr
+ 04-Apr-94 & Shepard   & Late commentary.  Document X3J13/94-309.\cr
+ 05-May-94 & X3J13     & Editorial-only changes to Draft 14.10 in response to comments.\cr
+ 10-May-94 & Pitman    & Draft {\rev} (for X3 consideration). Document {\DocumentNumber}.\cr
+} $$
+***************
+
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.82, Line #175:
+Committee Chairs:&\cr
+\noalign{\vskip 8pt}
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.89, Line #184:
+%Committee Chairs:&\cr
+Ad Hoc Group Chairs:&\cr
+\noalign{\vskip 8pt}
+***************
+
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.82, Line #180:
+			    & Fahlman, Scott	  \cr
+  Compiler                  & Haflich, Steve      \cr
+			    & Loosemore, Sandra   \cr
+  Conditions                & Pitman, Kent M.     \cr
+                            & Daniels, Andy       \cr
+  Editorial                 & Chapman, Kathy      \cr
+% Graphics \& Windows       & ???                 \cr
+  Iteration                 & White, JonL         \cr
+                            & Waters, Richard C.  \cr
+			    & Perdue, Crispin     \cr
+  Lisp$\sub1$/Lisp$\sub2$   & Gabriel, Richard P. \cr
+			    & Pitman, Kent M.     \cr
+  Macros                    & Haflich, Steve      \cr
+			    & Pitman, Kent M.     \cr
+  Objects                   & Bobrow, Daniel G.   \cr
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.89, Line #190:
+                            & Fahlman, Scott      \cr
+  Compiler                  & Haflich, Steve      \cr
+                            & Loosemore, Sandra   \cr
+  Conditions                & Pitman, Kent M.     \cr
+%% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+%                           & Daniels, Andy       \cr
+  Editorial                 & Chapman, Kathy      \cr
+%% Added per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+  Graphics \& Windows       & Douglas Rand        \cr
+  Iteration                 & White, JonL         \cr
+%% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+%                           & Waters, Richard C.  \cr
+%                           & Perdue, Crispin     \cr
+  Lisp$\sub1$/Lisp$\sub2$   & Gabriel, Richard P. \cr
+%% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+%                           & Pitman, Kent M.     \cr
+  Macros                    & Haflich, Steve      \cr
+                            & Pitman, Kent M.     \cr
+  Objects                   & Bobrow, Daniel G.   \cr
+***************
+
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.82, Line #209:
+Mathis, Robert&               % Convenor; Chairman; Interfacing to X3, etc.
+Barrett, Kim\cr               % Administration of Cleanup
+Steele, Guy L., Jr.&          % Interfacing to X3, etc.; Vice-Chairman; Roberts Rules expert 
+Brown, Gary\cr                % Secretary, Funding administration for DEC's editorship
+Zubkoff, Jan L.&  	      % Meeting organization, Secretary, Funding administration for Lucid
+Eiron, Hanoch\cr              % Funding administration for Franz, Help finding other funding
+Gabriel, Richard P.&          % Interfacing to ISO, etc.
+Haflich, Steve\cr             % Establishment of second-generation CL Editorship
+Masinter, Larry&              % Administration of Cleanup, agenda setting
+Whittemore, Susan\cr          % Funding administration for Apple
+Loosemore, Sandra&            % Administration of Cleanup & Compiler, agenda setting
+Woodyatt, Anne\cr             % Funding administration for Harlequin
+Pitman, Kent M.&              % Administration of Cleanup, agenda setting
+Ida, Masayuki\cr	      % International Liaison to Japan
+}
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.89, Line #223:
+%% Added "Loeffler" and "Tyson" per Pitman #3 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+Mathis, Robert&               % Convenor; Chairman; Interfacing to X3, etc.
+Brown, Gary\cr                % Secretary, Funding administration for DEC's editorship
+Steele, Guy L., Jr.&          % Interfacing to X3, etc.; Vice-Chairman; Roberts Rules expert 
+Eiron, Hanoch\cr              % Funding administration for Franz, Help finding other funding
+Zubkoff, Jan L.&  	      % Meeting organization, Secretary, Funding administration for Lucid
+Haflich, Steve\cr             % Establishment of second-generation CL Editorship
+Gabriel, Richard P.&          % Interfacing to ISO, etc.
+Ida, Masayuki\cr	      % International Liaison to Japan
+Masinter, Larry&              % Administration of Cleanup, agenda setting
+Loeffler, David D.\cr	      % Mailing lists at MCC
+Loosemore, Sandra&            % Administration of Cleanup & Compiler, agenda setting
+Tyson, Mabry\cr		      % Mailing lists at SRI
+Pitman, Kent M.&              % Administration of Cleanup, agenda setting
+Whittemore, Susan\cr          % Funding administration for Apple
+Barrett, Kim&                 % Administration of Cleanup
+Woodyatt, Anne\cr             % Funding administration for Harlequin
+}
+***************
+
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.82, Line #235:
+DeMichiel, Linda G. &         % CLOS
+Moon, David A.      \cr       % Review, CLOS, Conditions
+Dussud, Patrick H.  &         % CLOS
+Pitman, Kent M.     \cr       % Review, Conditions, Cleanup, Editor
+Gabriel, Richard P. &         % Review, Editing, CLOS
+Steele, Guy L., Jr. \cr       % Review, CLtL
+Ida, Masayuki       &  	      % Administration of Public Review work
+Waters, Richard C.  \cr       % Pretty Printer
+Kiczales, Gregor    &         % CLOS
+**** File B:>ansi-cl>spec>source>chap-0-edit-history.tex.89, Line #253:
+Daniels, Andy       &         % Conditions
+Moon, David A.      \cr       % Review, CLOS, Conditions
+DeMichiel, Linda G.  &        % CLOS
+Pitman, Kent M.     \cr       % Review, Conditions, Cleanup, Editor, Lisp1/Lisp2
+Dussud, Patrick H.  &         % CLOS
+Perdue, Crispin     \cr       % Iteration
+Gabriel, Richard P. &         % Review, Editing, CLOS
+Steele, Guy L., Jr. \cr       % Review, CLtL
+Ida, Masayuki       &  	      % Administration of Public Review work
+Waters, Richard C.  \cr       % Pretty Printer, Iteration
+Kiczales, Gregor    &         % CLOS
+***************
+
+Done.
+============================================================
+           File: concept-arrays.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:14
+of File B:>ansi-cl>spec>source>concept-arrays.tex.19
+with File B:>ansi-cl>spec>source>concept-arrays.tex.20
+**** File B:>ansi-cl>spec>source>concept-arrays.tex.19, Line #130:
+\displaythree{General Purpose Array-Related Defined Names}{
+adjust-array&array-in-bounds-p&svref\cr
+adjustable-array-p&array-rank&upgraded-array-element-type\cr
+aref&array-rank-limit&upgraded-complex-part-type\cr
+array-dimension&array-row-major-index&vector\cr
+array-dimension-limit&array-total-size&vector-pop\cr
+array-dimensions&array-total-size-limit&vector-push\cr
+array-element-type&fill-pointer&vector-push-extend\cr
+array-has-fill-pointer-p&make-array&\cr
+}
+**** File B:>ansi-cl>spec>source>concept-arrays.tex.20, Line #130:
+%% Added ARRAY-DISPLACEMENT per Tom Shepard.  (X3J13 approved: May 4-5, 1994)
+%% -kmp 9-May-94
+\displaythree{General Purpose Array-Related Defined Names}{
+adjust-array&array-has-fill-pointer-p&make-array\cr
+adjustable-array-p&array-in-bounds-p&svref\cr
+aref&array-rank&upgraded-array-element-type\cr
+array-dimension&array-rank-limit&upgraded-complex-part-type\cr
+array-dimension-limit&array-row-major-index&vector\cr
+array-dimensions&array-total-size&vector-pop\cr
+array-displacement&array-total-size-limit&vector-push\cr
+array-element-type&fill-pointer&vector-push-extend\cr
+}
+***************
+
+Done.
+============================================================
+           File: concept-conformance.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:15
+of File B:>ansi-cl>spec>source>concept-conformance.tex.66
+with File B:>ansi-cl>spec>source>concept-conformance.tex.68
+**** File B:>ansi-cl>spec>source>concept-conformance.tex.66:
+\itemitem{2.} \term{Conforming code} shall not rely on any particular
+              interpretation of \term{implementation-dependent} features.
+
+**** File B:>ansi-cl>spec>source>concept-conformance.tex.68, Line #130:
+
+%% Rewritten per X3J13 and Boyer/Kaufmann/Moore #2 (second public review).
+%% -kmp 9-May-94
+% \itemitem{2.} \term{Conforming code} shall not rely on any particular
+%               interpretation of \term{implementation-dependent} features.
+\itemitem{2.} \term{Conforming code} may use
+	      \term{implementation-dependent} features and values, 
+	      but shall not rely upon
+	      any particular interpretation of these features and values 
+	      other than those that are discovered by the execution of \term{code}.
+
+***************
+
+**** File B:>ansi-cl>spec>source>concept-conformance.tex.66, Line #191:
+ 
+%!!! Barmar wonders if this is really the right place for the next sentence.
+\term{Portable code} is written using only \term{standard characters}.
+
+**** File B:>ansi-cl>spec>source>concept-conformance.tex.68, Line #199:
+
+%% Moved to its own section (see below) per Dalton #1 (1st Public Review) 
+%% by X3J13 vote May 4-5, 1994 (after 2nd public review).
+%% -kmp 9-May-94
+% %!!! Barmar wonders if this is really the right place for the next sentence.
+% \term{Portable code} is written using only \term{standard characters}.
+
+***************
+
+**** File B:>ansi-cl>spec>source>concept-conformance.tex.66, Line #257:
+\endsubSection%{Conforming Programs}
+**** File B:>ansi-cl>spec>source>concept-conformance.tex.68, Line #268:
+\beginsubsubsection{Character Set for Portable Code}
+
+\term{Portable code} is written using only \term{standard characters}.
+
+\endsubsubsection%{Character Set for Portable Code}
+
+\endsubSection%{Conforming Programs}
+***************
+
+Done.
+============================================================
+           File: concept-definitions.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:16
+of File B:>ansi-cl>spec>source>concept-definitions.tex.174
+with File B:>ansi-cl>spec>source>concept-definitions.tex.177
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.174, Line #596:
+\beginsubSection{Error Terminology}\idxterm{error terminology}
+\DefineSection{ErrorTerms}
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.177, Line #596:
+\beginsubSection{Error Terminology}\idxtext{error terminology}
+\DefineSection{ErrorTerms}
+***************
+
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.174, Line #885:
+\endsubsubsection%{The ``Arguments and Values'' Section of a Dictionary Entry}
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.177, Line #885:
+%% I added the first part of this sentence as editorial discretion 
+%% since I believe we strongly feel that this is not specified otherwise,
+%% but we want to avoid an unexpected conflict in case it is. -kmp 9-May-94
+Except as explicitly specified otherwise,
+%% Added per X3J13 at May 4-5, 1994 meeting.  -kmp 9-May-94
+the consequences are undefined if these type restrictions are violated.
+
+\endsubsubsection%{The ``Arguments and Values'' Section of a Dictionary Entry}
+***************
+
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.174, Line #1042:
+This information describes the argument precedence order.
+If it is omitted, the argument precedence order is the default (left to right).
+
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.177, Line #1049:
+%% Added italic font for "argument precedence order" per Boyer/Kaufmann/Moore #3.
+%% -kmp 9-May-94
+This information describes the \term{argument precedence order}.
+If it is omitted, the \term{argument precedence order} is the default (left to right).
+
+***************
+
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.174, Line #1382:
+\endsubsubsection%{The ``Value Type'' Section of a Dictionary Entry}
+**** File B:>ansi-cl>spec>source>concept-definitions.tex.177, Line #1391:
+%% I added the first part of this sentence as editorial discretion 
+%% since I believe we strongly feel that this is not specified otherwise,
+%% but we want to avoid an unexpected conflict in case it is. -kmp 9-May-94
+Except as explicitly specified otherwise,
+%% Added per X3J13 at May 4-5, 1994 meeting.  -kmp 9-May-94
+the consequences are undefined if this type restriction is violated.
+
+\endsubsubsection%{The ``Value Type'' Section of a Dictionary Entry}
+***************
+
+Done.
+============================================================
+           File: concept-format.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:18
+of File B:>ansi-cl>spec>source>concept-format.tex.41
+with File B:>ansi-cl>spec>source>concept-format.tex.44
+**** Section "Tilde C: Character"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #137:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #137:
+\idxtext{C (format directive)}\idxtext{Tilde C (format directive)}
+
+
+***************
+
+**** Section "Tilde Percent: Newline"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #207:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #209:
+\idxtext{Percent (format directive)}\idxtext{Tilde Percent (format directive)}
+
+***************
+
+**** Section "Tilde Ampersand: Fresh-Line"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #218:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #221:
+\idxtext{Ampersand (format directive)}\idxtext{Tilde Ampersand (format directive)}
+
+***************
+
+**** Section "Tilde Vertical-Bar: Page"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #231:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #235:
+\idxtext{Vertical-Bar (format directive)}\idxtext{Tilde Vertical-Bar (format directive)}
+
+***************
+
+**** Section "Tilde Tilde: Tilde"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #242:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #247:
+\idxtext{Tilde (format directive)}\idxtext{Tilde Tilde (format directive)}
+
+***************
+
+**** Section "Tilde R: Radix"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #252:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #258:
+\idxtext{R (format directive)}\idxtext{Tilde R (format directive)}
+
+***************
+
+**** Section "Tilde D: Decimal"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #314:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #321:
+\idxtext{D (format directive)}\idxtext{Tilde D (format directive)}
+
+***************
+
+**** Section "Tilde B: Binary"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #365:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #373:
+\idxtext{B (format directive)}\idxtext{Tilde B (format directive)}
+
+***************
+
+**** Section "Tilde O: Octal"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #385:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #394:
+\idxtext{O (format directive)}\idxtext{Tilde O (format directive)}
+
+***************
+
+**** Section "Tilde X: Hexadecimal"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #405:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #415:
+\idxtext{X (format directive)}\idxtext{Tilde X (format directive)}
+
+***************
+
+**** Section "Tilde F: Fixed-Format Floating-Point"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #429:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #440:
+\idxtext{F (format directive)}\idxtext{Tilde F (format directive)}
+
+***************
+
+**** Section "Tilde E: Exponential Floating-Point"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #534:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #546:
+\idxtext{E (format directive)}\idxtext{Tilde E (format directive)}
+
+***************
+
+**** Section "Tilde G: General Floating-Point"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #667:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #680:
+\idxtext{G (format directive)}\idxtext{Tilde G (format directive)}
+
+***************
+
+**** Section "Tilde Dollarsign: Monetary Floating-Point"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #716:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #730:
+\idxtext{Dollarsign (format directive)}\idxtext{Tilde Dollarsign (format directive)}
+
+***************
+
+**** Section "Tilde A: Aesthetic"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #787:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #802:
+\idxtext{A (format directive)}\idxtext{Tilde A (format directive)}
+
+***************
+
+**** Section "Tilde S: Standard"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #830:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #846:
+\idxtext{S (format directive)}\idxtext{Tilde S (format directive)}
+
+***************
+
+**** Section "Tilde W: Write"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #850:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #867:
+\idxtext{W (format directive)}\idxtext{Tilde W (format directive)}
+
+***************
+
+**** Section "Tilde Underscore: Conditional Newline"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #876:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #894:
+\idxtext{Underscore (format directive)}\idxtext{Tilde Underscore (format directive)}
+
+***************
+
+**** Section "Tilde Less-Than-Sign: Logical Block"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #886:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #905:
+\idxtext{Less-Than-Sign (format directive)}\idxtext{Tilde Less-Than-Sign (format directive)}
+
+***************
+
+**** Section "Tilde I: Indent"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #955:
+ 
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #975:
+\idxtext{I (format directive)}\idxtext{Tilde I (format directive)}
+ 
+***************
+
+**** Section "Tilde Slash: Call Function"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #964:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #985:
+\idxtext{Slash (format directive)}\idxtext{Tilde Slash (format directive)}
+
+***************
+
+**** Section "Tilde T: Tabulate"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1012:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1034:
+\idxtext{T (format directive)}\idxtext{Tilde T (format directive)}
+
+***************
+
+**** Section "Tilde Less-Than-Sign: Justification"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1068:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1091:
+\idxtext{Less-Than-Sign (format directive)}\idxtext{Tilde Less-Than-Sign (format directive)}
+
+***************
+
+**** Section "Tilde Greater-Than-Sign: End of Justification"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1151:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1175:
+\idxtext{Greater-Than-Sign (format directive)}\idxtext{Tilde Greater-Than-Sign (format directive)}
+
+***************
+
+**** Section "Tilde Asterisk: Go-To"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1164:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1189:
+\idxtext{Asterisk (format directive)}\idxtext{Tilde Asterisk (format directive)}
+
+***************
+
+**** Section "Tilde Left-Bracket: Conditional Expression"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1192:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1218:
+\idxtext{Left-Bracket (format directive)}\idxtext{Tilde Left-Bracket (format directive)}
+
+***************
+
+**** Section "Tilde Right-Bracket: End of Conditional Expression"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1271:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1298:
+\idxtext{Right-Bracket (format directive)}\idxtext{Tilde Right-Bracket (format directive)}
+
+***************
+
+**** Section "Tilde Left-Brace: Iteration"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1280:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1308:
+\idxtext{Left-Brace (format directive)}\idxtext{Tilde Left-Brace (format directive)}
+
+***************
+
+**** Section "Tilde Right-Brace: End of Iteration"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1390:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1419:
+\idxtext{Right-Brace (format directive)}\idxtext{Tilde Right-Brace (format directive)}
+
+***************
+
+**** Section "Tilde Question-Mark: Recursive Processing"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1399:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1429:
+\idxtext{Question-Mark (format directive)}\idxtext{Tilde Question-Mark (format directive)}
+
+***************
+
+**** Section "Tilde Left-Paren: Case Conversion"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1443:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1474:
+\idxtext{Left-Paren (format directive)}\idxtext{Tilde Left-Paren (format directive)}
+
+***************
+
+**** Section "Tilde Right-Paren: End of Case Conversion"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1492:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1524:
+\idxtext{Right-Paren (format directive)}\idxtext{Tilde Right-Paren (format directive)}
+
+***************
+
+**** Section "Tilde P: Plural"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1501:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1534:
+\idxtext{P (format directive)}\idxtext{Tilde P (format directive)}
+
+***************
+
+**** Section "Tilde Semicolon: Clause Separator"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1534:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1568:
+\idxtext{Semicolon (format directive)}\idxtext{Tilde Semicolon (format directive)}
+
+***************
+
+**** Section "Tilde Circumflex: Escape Upward"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1543:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1578:
+\idxtext{Circumflex (format directive)}\idxtext{Tilde Circumflex (format directive)}
+
+***************
+
+**** Section "Tilde Newline: Ignored Newline"
+**** File B:>ansi-cl>spec>source>concept-format.tex.41, Line #1648:
+
+**** File B:>ansi-cl>spec>source>concept-format.tex.44, Line #1684:
+\idxtext{Newline (format directive)}\idxtext{Tilde Newline (format directive)}
+
+***************
+
+Done.
+============================================================
+           File: concept-glossary.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:21
+of File B:>ansi-cl>spec>source>concept-glossary.tex.210
+with File B:>ansi-cl>spec>source>concept-glossary.tex.212
+**** Glossary entry "binding"
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.210, Line #488:
+ 
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.212, Line #488:
+%% Added per Boyer/Kaufmann/Moore #5 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+  When the term \term{binding} is qualified by the name of a \term{namespace},
+  such as ``variable'' or ``function,'' 
+  it restricts the binding to the indicated namespace, as in:
+  \gexample{\specref{let} establishes variable bindings.}
+  or 
+  \gexample{\specref{let} establishes bindings of variables.}
+ 
+***************
+
+**** Glossary entry "function name"
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.210, Line #2189:
+\gentry{function name} \Noun\ (in an \term{environment})
+  A \term{symbol} or a \term{list} \f{(setf \i{symbol})} 
+  that is the \term{name} of a \term{function} in that \term{environment}.
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.212, Line #2197:
+\gentry{function name} \Noun\ 
+  1. (in an \term{environment})
+     A \term{symbol} or a \term{list} \f{(setf \i{symbol})} 
+     that is the \term{name} of a \term{function} in that \term{environment}.
+***************
+
+**** Glossary entry "function name"
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.210, Line #2198:
+
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.212, Line #2207:
+%% Added per Boyer/Kaufmann/Moore #8,#9 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+  2. A \term{symbol} or a \term{list} \f{(setf \i{symbol})}.
+
+***************
+
+**** Glossary entry "variable"
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.210, Line #5003:
+%!!! Moon: This is certainly no valid definition, especially when contrasting
+%          the variable namespace with the function namespace.
+\gentry{variable} \Noun\ 
+  a \term{binding} in which a \term{symbol} is the \term{name}
+  used to refer to an \term{object}.
+ 
+**** File B:>ansi-cl>spec>source>concept-glossary.tex.212, Line #5015:
+\gentry{variable} \Noun\ 
+%% Rewritten per Boyer/Kaufmann/Moore #5 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+%   %!!! Moon: This is certainly no valid definition, especially when contrasting
+%   %          the variable namespace with the function namespace.
+%   a \term{binding} in which a \term{symbol} is the \term{name}
+%   used to refer to an \term{object}.
+  a \term{binding} in the ``variable'' \term{namespace}.
+  \Seesection\SymbolsAsForms.
+ 
+***************
+
+Done.
+============================================================
+           File: concept-macro-chars.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:27
+of File B:>ansi-cl>spec>source>concept-macro-chars.tex.140
+with File B:>ansi-cl>spec>source>concept-macro-chars.tex.152
+**** Section "Left-Parenthesis"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #18:
+\DefineSection{LeftParen}
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #18:
+\DefineSection{LeftParen}\idxcode{(}\idxtext{Left-Parenthesis (reader macro)}\idxref{list}
+
+***************
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #52:
+If a \term{token} that is just a dot
+not immediately preceded by an escape character
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #52
+If a \term{token} that is just a dot\idxterm{dot}\idxcode{.}
+not immediately preceded by an escape character
+***************
+
+**** Section "Right-Parenthesis"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #88:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #88:
+\idxcode{)}\idxtext{Right-Parenthesis (reader macro)}
+
+***************
+
+**** Section "Single-Quote"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #99:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #100:
+\idxcode{'}\idxtext{Single-Quote (reader macro)}\idxtext{quotation (of forms)}\idxref{quote}
+
+***************
+
+**** Section "Semicolon"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #123:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #125:
+\idxcode{;}\idxtext{Semicolon (reader macro)}\idxtext{comment}
+
+***************
+
+**** Section "Double-Quote"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #231:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #234:
+\idxtext{Double-Quote (reader macro)}\idxtext{quotation (of strings)}\idxref{string}
+
+***************
+
+**** Section "Backquote"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #281:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #285:
+\idxcode{`}\idxtext{Backquote (reader macro)}\idxtext{quotation (of forms)}
+\idxref{quote}\idxref{list}\idxref{cons}
+
+***************
+
+**** Section "Comma"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #466:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #472:
+\idxcode{,}\idxtext{Comma (reader macro)}\idxtext{quotation (of forms)}
+\idxref{quote}\idxref{list}\idxref{cons}
+
+***************
+
+**** Section "Sharpsign"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #476:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #484:
+\idxcode{\#}\idxtext{Sharpsign (reader macro)}
+
+***************
+
+**** Section "Sharpsign Backslash"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #615:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #624:
+\idxtext{Sharpsign Backslash (reader macro)}\idxtext{Backslash (sharpsign reader macro)}\idxref{character}
+
+***************
+
+**** Section "Sharpsign Single-Quote"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #670:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #680:
+\idxtext{Sharpsign Single-Quote (reader macro)}\idxtext{Single-Quote (sharpsign reader macro)}\idxref{function}
+
+***************
+
+**** Section "Sharpsign Left-Parenthesis"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #694:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #705:
+\idxtext{Sharpsign Left-Parenthesis (reader macro)}\idxtext{Left-Parenthesis (sharpsign reader macro)}\idxref{vector}\idxref{simple-vector}
+
+***************
+
+**** Section "Sharpsign Asterisk"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #746:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #758:
+\idxtext{Sharpsign Asterisk (reader macro)}\idxtext{Asterisk (sharpsign reader macro)}\idxref{bit-vector}\idxref{simple-bit-vector}
+
+***************
+
+**** Section "Sharpsign Colon"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #806:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #819:
+\idxtext{Sharpsign Colon (reader macro)}\idxtext{Colon (sharpsign reader macro)}\idxref{symbol}
+
+***************
+
+**** Section "Sharpsign Dot"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #833:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #847:
+\idxtext{Sharpsign Dot (reader macro)}\idxtext{Dot (sharpsign reader macro)}\idxref{eval}\idxref{*read-eval*}
+
+***************
+
+**** Section "Sharpsign B"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #873:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #888:
+\idxtext{Sharpsign B (reader macro)}\idxtext{B (sharpsign reader macro)}\idxref{*read-base*}
+
+***************
+
+**** Section "Sharpsign O"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #893:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #909:
+\idxtext{Sharpsign O (reader macro)}\idxtext{O (sharpsign reader macro)}\idxref{*read-base*}
+
+***************
+
+**** Section "Sharpsign X"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #914:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #931:
+\idxtext{Sharpsign X (reader macro)}\idxtext{X (sharpsign reader macro)}\idxref{*read-base*}
+
+***************
+
+**** Section "Sharpsign R"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #935:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #953:
+\idxtext{Sharpsign R (reader macro)}\idxtext{R (sharpsign reader macro)}\idxref{*read-base*}
+
+***************
+
+**** Section "Sharpsign C"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #980:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #999:
+\idxtext{Sharpsign C (reader macro)}\idxtext{C (sharpsign reader macro)}\idxref{complex}
+
+***************
+
+**** Section "Sharpsign A"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1017:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1037:
+\idxtext{Sharpsign A (reader macro)}\idxtext{A (sharpsign reader macro)}\idxref{array}
+
+***************
+
+**** Section "Sharpsign S"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1067:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1088:
+\idxtext{Sharpsign S (reader macro)}\idxtext{S (sharpsign reader macro)}\idxref{structure}
+
+***************
+
+**** Section "Sharpsign P"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1105:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1127:
+\idxtext{Sharpsign P (reader macro)}\idxtext{P (sharpsign reader macro)}\idxref{pathname}
+
+***************
+
+**** Section "Sharpsign Equal-Sign"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1125:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1148:
+\idxtext{Sharpsign Equal-Sign (reader macro)}\idxtext{Equal-Sign (sharpsign reader macro)}\idxref{*print-circle*}
+
+***************
+
+**** Section "Sharpsign Sharpsign"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1140:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1164:
+\idxtext{Sharpsign Sharpsign (reader macro)}\idxtext{Sharpsign (sharpsign reader macro)}\idxref{*print-circle*}
+
+***************
+
+**** Section "Sharpsign Plus"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1178:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1203:
+\idxtext{Sharpsign Plus (reader macro)}\idxtext{Plus (sharpsign reader macro)}\idxref{*features*}
+
+***************
+
+**** Section "Sharpsign Minus"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1209:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1235:
+\idxtext{Sharpsign Minus (reader macro)}\idxtext{Minus (sharpsign reader macro)}\idxref{*features*}
+
+***************
+
+**** Section "Sharpsign Vertical-Bar"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1225:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1252:
+\idxtext{Sharpsign Vertical-Bar (reader macro)}\idxtext{Vertical-Bar (sharpsign reader macro)}\idxtext{comment}
+
+***************
+
+**** Section "Sharpsign Less-Than-Sign"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1323:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1351:
+\idxtext{Sharpsign Less-Than-Sign (reader macro)}\idxtext{Less-Than-Sign (sharpsign reader macro)}
+
+***************
+
+**** Section "Sharpsign Whitespace"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1338:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1367:
+\idxtext{Sharpsign Whitespace}
+
+***************
+
+**** Section "Sharpsign Right-Parenthesis"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1351:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1381:
+\idxtext{Sharpsign Right-Parenthesis}
+
+***************
+
+**** Section "Re-Reading Abbreviated Expressions"
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.140, Line #1369:
+
+**** File B:>ansi-cl>spec>source>concept-macro-chars.tex.152, Line #1400:
+\idxtext{Dot Dot}\idxcode{..}
+\idxtext{Dot Dot Dot}\idxcode{...}
+\idxtext{Sharpsign Whitespace}\idxtext{Sharpsign Right-Parenthesis}
+
+***************
+
+Done.
+============================================================
+           File: concept-numbers.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:31
+of File B:>ansi-cl>spec>source>concept-numbers.tex.34
+with File B:>ansi-cl>spec>source>concept-numbers.tex.35
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.34, Line #267:
+If the arguments to a mathematical \term{function} are all of type
+  \f{(or rational (complex rational))} 
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.35, Line #267:
+If the arguments to 
+%% Added "irrational" per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+%a
+an irrational
+mathematical \term{function} are all of type
+  \f{(or rational (complex rational))} 
+***************
+
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.34, Line #286:
+\tablefigtwo{Functions Affected by Rule of Float Substitutability}%
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.35, Line #291:
+%% Added per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+Float substitutability applies neither to the rational \term{functions} 
+      \funref{+},
+      \funref{-},
+      \funref{*},
+  and \funref{/} 
+nor to the related \term{operators} 
+      \funref{1+},
+      \funref{1-},
+      \macref{incf},
+      \macref{decf},
+  and \funref{conjugate}.
+For rational \term{functions},
+  if all arguments are \term{rational},
+    then the result is \term{rational}; 
+  if all arguments are of type \f{(or rational (complex rational))},
+    then the result is of type \f{(or rational (complex rational))}.
+
+\tablefigtwo{Functions Affected by Rule of Float Substitutability}%
+***************
+
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.34, Line #295:
+\funref{cis}    & \f{(cis 0) \EV\ \#c(1 0) \i{or} \#c(1.0 0.0)} \cr
+\funref{cos}    & \f{(cos 0) \EV\ 1 \i{or} 1.0} \cr
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.35, Line #319:
+%% #c(1 0) => 1 per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+\funref{cis}    & \f{(cis 0) \EV\ 1 \i{or} \#c(1.0 0.0)} \cr
+\funref{cos}    & \f{(cos 0) \EV\ 1 \i{or} 1.0} \cr
+***************
+
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.34, Line #574:
+in \thenextfigure\ permit the user to specify an interval on the real number line
+which describe a \term{subtype} of the \term{type} which would be described by the
+**** File B:>ansi-cl>spec>source>concept-numbers.tex.35, Line #600:
+%% Removed per Boyer/Kaufmann/Moore #15 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+%in \thenextfigure\ 
+permit the user to specify an interval on the real number line
+which describe a \term{subtype} of the \term{type} which would be described by the
+***************
+
+Done.
+============================================================
+           File: concept-syntax.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:33
+of File B:>ansi-cl>spec>source>concept-syntax.tex.92
+with File B:>ansi-cl>spec>source>concept-syntax.tex.93
+**** File B:>ansi-cl>spec>source>concept-syntax.tex.92, Line #572:
+\term{Slash} is a \term{single escape} \term{character}
+in \term{standard syntax}.
+
+**** File B:>ansi-cl>spec>source>concept-syntax.tex.93, Line #572:
+%% "slash" => "backslash" as an editorial change per Boyer/Kaufmann/Moore #4.
+%% This was right everywhere else in the manual--shame for it to be wrong here.
+%% -kmp 9-May-94
+\term{Backslash} is a \term{single escape} \term{character} in \term{standard syntax}.
+
+***************
+
+Done.
+============================================================
+           File: dict-conses.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:34
+of File B:>ansi-cl>spec>source>dict-conses.tex.195
+with File B:>ansi-cl>spec>source>dict-conses.tex.196
+**** File B:>ansi-cl>spec>source>dict-conses.tex.195, Line #948:
+\code
+ (defun subst (old new tree &rest x &key test test-not key)
+   (cond ((satisfies-the-test old tree :test test
+                                 :test-not test-not :key key)
+         new)
+        ((atom tree) tree)
+        (t (let ((a (apply #'subst old new (car tree) x))
+                 (d (apply #'subst old new (cdr tree) x)))
+             (if (and (eql a (car tree))
+                      (eql d (cdr tree)))
+                 tree
+                 (cons a d))))))
+\endcode
+**** File B:>ansi-cl>spec>source>dict-conses.tex.196, Line #948:
+%% Indentation fixed per Boyer/Kaufmann/Moore #13 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+\code
+ (defun subst (old new tree &rest x &key test test-not key)
+   (cond ((satisfies-the-test old tree :test test
+                              :test-not test-not :key key)
+          new)
+         ((atom tree) tree)
+         (t (let ((a (apply #'subst old new (car tree) x))
+                  (d (apply #'subst old new (cdr tree) x)))
+              (if (and (eql a (car tree))
+                       (eql d (cdr tree)))
+                  tree
+                  (cons a d))))))
+\endcode
+***************
+
+Done.
+============================================================
+           File: dict-flow.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:39
+of File B:>ansi-cl>spec>source>dict-flow.tex.322
+with File B:>ansi-cl>spec>source>dict-flow.tex.323
+**** File B:>ansi-cl>spec>source>dict-flow.tex.322, Line #4228:
+\funref{not}
+
+**** File B:>ansi-cl>spec>source>dict-flow.tex.323, Line #4228:
+%% "not" => "identity" per Boyer/Kaufmann/Moore #10 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+\funref{identity}
+
+***************
+
+Done.
+============================================================
+           File: dict-numbers.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:48
+of File B:>ansi-cl>spec>source>dict-numbers.tex.207
+with File B:>ansi-cl>spec>source>dict-numbers.tex.208
+**** File B:>ansi-cl>spec>source>dict-numbers.tex.207, Line #3357:
+\funref{realpart}, \funref{imagpart}
+
+\label Notes::
+
+\code
+ #c(a b) \EQ #.(complex a b)
+\endcode
+\endcom
+**** File B:>ansi-cl>spec>source>dict-numbers.tex.208, Line #3357:
+\funref{realpart},
+\funref{imagpart},
+%% Added per Boyer/Kaufmann/Moore #15 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+{\secref\SharpsignC}
+
+\label Notes:\None.
+
+%% Removed per Boyer/Kaufmann/Moore #15 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+% \code
+%  #c(a b) \EQ #.(complex a b)
+% \endcode
+
+\endcom
+***************
+
+Done.
+============================================================
+           File: dict-packages.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:55
+of File B:>ansi-cl>spec>source>dict-packages.tex.167
+with File B:>ansi-cl>spec>source>dict-packages.tex.169
+**** File B:>ansi-cl>spec>source>dict-packages.tex.167, Line #1486:
+  \Thepackage{keyword} cannot be supplied.
+  \Default{the \term{current package}}
+\endissue{PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE}
+**** File B:>ansi-cl>spec>source>dict-packages.tex.169, Line #1486:
+  \Default{the \term{current package}}
+%% Next sentence reworded and moved per Boyer/Kaufmann/Moore #12
+%% (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+% \Thepackage{keyword} cannot be supplied.
+  The \param{package} cannot be \thepackage{keyword}.
+\endissue{PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE}
+***************
+
+**** File B:>ansi-cl>spec>source>dict-packages.tex.167, Line #1585:
+\auxbnf{symbol-name}{(\term{symbol} | \term{string})}
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+**** File B:>ansi-cl>spec>source>dict-packages.tex.169, Line #1589:
+%% Removed per Pitman #2 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+%\auxbnf{symbol-name}{(\term{symbol} | \term{string})}
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+***************
+
+Done.
+============================================================
+           File: dict-printer.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:45:57
+of File B:>ansi-cl>spec>source>dict-printer.tex.192
+with File B:>ansi-cl>spec>source>dict-printer.tex.195
+**** File B:>ansi-cl>spec>source>dict-printer.tex.192, Line #844:
+    ``\f{. }'' is printed followed by the remaining `list.' 
+    (This makes it easier to write printing functions that 
+**** File B:>ansi-cl>spec>source>dict-printer.tex.195, Line #844:
+    ``\f{. }''\idxterm{dot} is printed followed by the remaining `list.' 
+    (This makes it easier to write printing functions that 
+***************
+
+**** File B:>ansi-cl>spec>source>dict-printer.tex.192, Line #852:
+    ``\f{...}'' is printed.
+    (This makes it easy to write printing functions that properly handle
+**** File B:>ansi-cl>spec>source>dict-printer.tex.195, Line #852:
+    ``\f{...}''\idxtext{Dot Dot Dot}\idxcode{...} is printed.
+    (This makes it easy to write printing functions that properly handle
+***************
+
+**** File B:>ansi-cl>spec>source>dict-printer.tex.192, Line #860:
+    ``\f{\#\i{n}\#}'' marker.
+    (This catches instances of \term{cdr} circularity and sharing in lists.)
+**** File B:>ansi-cl>spec>source>dict-printer.tex.195, Line #860:
+    ``\f{\#\i{n}\#}''\idxtext{Sharpsign Sharpsign (reader macro)} marker.
+    (This catches instances of \term{cdr} circularity and sharing in lists.)
+***************
+
+**** File B:>ansi-cl>spec>source>dict-printer.tex.192, Line #2183:
+``\f{..}'' is printed at the end of the last line followed by all of the
+suffixes (closing delimiters) that are pending to be printed.
+**** File B:>ansi-cl>spec>source>dict-printer.tex.195, Line #2183:
+``\f{..}''\idxtext{Dot Dot}\idxcode{..}
+is printed at the end of the last line followed by all of the
+suffixes (closing delimiters) that are pending to be printed.
+***************
+
+Done.
+============================================================
+           File: dict-sequences.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:46:00
+of File B:>ansi-cl>spec>source>dict-sequences.tex.139
+with File B:>ansi-cl>spec>source>dict-sequences.tex.140
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #1023:
+The result might or might not be simple, 
+and might or might not be \term{identical} to \param{sequence}.
+%% Another possible interpretation:
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #1023:
+%% Moved to notes per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+% The result might or might not be simple, 
+% and might or might not be \term{identical} to \param{sequence}.
+%% Another possible interpretation:
+***************
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #1152:
+\label Notes:\None.
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #1154:
+\label Notes::
+
+%% Moved from Description per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+If \param{sequence} is a \term{vector},
+the result might or might not be simple, 
+and might or might not be \term{identical} to \param{sequence}.
+
+***************
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #1745:
+The result might or might not be simple, and 
+might or might not be \term{identical}
+to \param{sequence}.
+%% Another possible interpretation:
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #1753:
+%% Moved to notes per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+% The result might or might not be simple, 
+% and might or might not be \term{identical} to \param{sequence}.
+%% Another possible interpretation:
+***************
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #1851:
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #1860:
+%% Moved from Description per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+If \param{sequence} is a \term{vector},
+the result might or might not be simple, 
+and might or might not be \term{identical} to \param{sequence}.
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+***************
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #2208:
+The result might or might not be simple, and 
+might or might not be \term{identical}
+to \param{sequence}.
+%% Another possible interpretation:
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #2223:
+%% Moved to notes per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+% The result might or might not be simple, 
+% and might or might not be \term{identical} to \param{sequence}.
+%% Another possible interpretation:
+***************
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #2354:
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #2370:
+%% Moved from Description per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+If \param{sequence} is a \term{vector},
+the result might or might not be simple, 
+and might or might not be \term{identical} to \param{sequence}.
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+***************
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #2419:
+The result might or might not be simple, and 
+might or might not be \term{identical}
+to \param{sequence}.
+%% Another possible interpretation:
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #2441:
+%% Moved to notes per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+% The result might or might not be simple,
+% and might or might not be \term{identical} to \param{sequence}.
+%% Another possible interpretation:
+***************
+
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.139, Line #2498:
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+**** File B:>ansi-cl>spec>source>dict-sequences.tex.140, Line #2521:
+%% Moved from Description per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+If \param{sequence} is a \term{vector},
+the result might or might not be simple, 
+and might or might not be \term{identical} to \param{sequence}.
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+***************
+
+Done.
+============================================================
+           File: dict-symbols.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:46:03
+of File B:>ansi-cl>spec>source>dict-symbols.tex.136
+with File B:>ansi-cl>spec>source>dict-symbols.tex.137
+**** File B:>ansi-cl>spec>source>dict-symbols.tex.136, Line #55:
+\term{Symbols} have the following attributes. For historically reasons,
+these are sometimes referred to as \term{cells}, although the actual
+**** File B:>ansi-cl>spec>source>dict-symbols.tex.137, Line #55:
+\term{Symbols} have the following attributes. 
+%% "historically" => "historical" per Boyer/Kaufmann/Moore #11 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+For historical reasons,
+these are sometimes referred to as \term{cells}, although the actual
+***************
+
+Done.
+============================================================
+           File: dict-types.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:46:05
+of File B:>ansi-cl>spec>source>dict-types.tex.161
+with File B:>ansi-cl>spec>source>dict-types.tex.163
+**** File B:>ansi-cl>spec>source>dict-types.tex.161, Line #910:
+Represents the \term{type} whose only \term{element} is \param{object}.
+
+**** File B:>ansi-cl>spec>source>dict-types.tex.163, Line #910:
+Represents the \term{type} 
+%% Replaced per Boyer/Kaufmann/Moore #6 (by X3J13 vote at May 4-5, 1994 meeting).
+%whose only \term{element} is \param{object}.
+of all \param{x} for which \f{(eql \param{object} \param{x})} is true.
+
+***************
+
+**** File B:>ansi-cl>spec>source>dict-types.tex.161, Line #1005:
+and the \term{object} is a \term{number},
+then the \param{result} is obtained by constructing a \term{complex}
+**** File B:>ansi-cl>spec>source>dict-types.tex.163, Line #1008:
+%% "number" => "real" per Boyer/Kaufmann/Moore #7 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+and the \term{object} is a \term{real},
+then the \param{result} is obtained by constructing a \term{complex}
+***************
+
+Done.
+============================================================
+           File: setup-aux.tex
+============================================================
+Source compare made by kmp on 5/11/94 23:04:05		-*-Mode:Fundamental-*-
+of File B:>ansi-cl>spec>source>setup-aux.tex.411
+with File B:>ansi-cl>spec>source>setup-aux.tex.412
+**** File B:>ansi-cl>spec>source>setup-aux.tex.411, Line #264:
+\hbox{\prmeleven Draft \rev\thedraftcomment}\hbox{\prmeleven \timestamp}
+\vskip 2pc}
+**** File B:>ansi-cl>spec>source>setup-aux.tex.412, Line #264:
+\hbox{\prmeleven Version \rev\thedraftcomment}\hbox{\prmeleven \timestamp}
+\vskip 2pc}
+***************
+
+**** File B:>ansi-cl>spec>source>setup-aux.tex.411, Line #300:
+\hbox{\prmeleven Draft \rev\thedraftcomment}\hbox{\prmeleven \timestamp}
+\vskip 2pc}
+**** File B:>ansi-cl>spec>source>setup-aux.tex.412, Line #300:
+\hbox{\prmeleven Version \rev\thedraftcomment}\hbox{\prmeleven \timestamp}
+\vskip 2pc}
+***************
+
+Done.
+============================================================
+           File: setup-title.tex
+============================================================
+Source compare made by kmp on 5/11/94 13:46:10
+of File B:>ansi-cl>spec>source>setup-title.tex.10
+with File B:>ansi-cl>spec>source>setup-title.tex.11
+**** File B:>ansi-cl>spec>source>setup-title.tex.10, Line #26:
+\def\DocumentNumber{X3J13/93-102}
+**** File B:>ansi-cl>spec>source>setup-title.tex.11, Line #26:
+\def\DocumentNumber{X3J13/94-101}
+***************
+
+Done.
+============================================================
+           File: setup-version.tex
+============================================================
+Source compare made by kmp on 5/11/94 23:04:09		-*-Mode:Fundamental-*-
+of File B:>ansi-cl>spec>source>setup-version.tex.641
+with File B:>ansi-cl>spec>source>setup-version.tex.660
+**** File B:>ansi-cl>spec>source>setup-version.tex.641, Line #4:
+\def\rev{{14.10}}
+
+\def\timestamp{{Tue 5-Oct-1993 5:00pm EDT}}
+**** File B:>ansi-cl>spec>source>setup-version.tex.660, Line #4:
+\def\rev{{15.17}}
+
+\def\timestamp{{Wed 11-May-1994 6:57pm EDT}}
+***************
+
+Done.
+These files have the same source in Draft 14.10 and Draft 15.17:
+  B:>ansi-cl>spec>source>setup-terms.tex.40
+  B:>ansi-cl>spec>source>setup-tables.tex.5
+  B:>ansi-cl>spec>source>setup-options.tex.32
+  B:>ansi-cl>spec>source>setup-for-toc.tex.2
+  B:>ansi-cl>spec>source>setup-document.tex.105
+  B:>ansi-cl>spec>source>setup-cmfont.tex.3
+  B:>ansi-cl>spec>source>setup-boxfig.tex.5
+  B:>ansi-cl>spec>source>setup-amfont.tex.7
+  B:>ansi-cl>spec>source>setup.tex.250
+  B:>ansi-cl>spec>source>dict-system-construction.tex.132
+  B:>ansi-cl>spec>source>dict-structures.tex.102
+  B:>ansi-cl>spec>source>dict-strings.tex.33
+  B:>ansi-cl>spec>source>dict-streams.tex.208
+  B:>ansi-cl>spec>source>dict-reader.tex.141
+  B:>ansi-cl>spec>source>dict-pathnames.tex.125
+  B:>ansi-cl>spec>source>dict-objects.tex.192
+  B:>ansi-cl>spec>source>dict-iteration.tex.43
+  B:>ansi-cl>spec>source>dict-hash-tables.tex.106
+  B:>ansi-cl>spec>source>dict-files.tex.93
+  B:>ansi-cl>spec>source>dict-eval-compile.tex.275
+  B:>ansi-cl>spec>source>dict-environment.tex.164
+  B:>ansi-cl>spec>source>dict-conditions.tex.215
+  B:>ansi-cl>spec>source>dict-characters.tex.131
+  B:>ansi-cl>spec>source>dict-arrays.tex.158
+  B:>ansi-cl>spec>source>concept-types.tex.397
+  B:>ANSI-CL>spec>source>concept-type-intro.tex.59
+  B:>ANSI-CL>spec>source>concept-traversal.tex.4
+  B:>ansi-cl>spec>source>concept-tokens.tex.101
+  B:>ansi-cl>spec>source>concept-tests.tex.18
+  B:>ansi-cl>spec>source>concept-systems.tex.10
+  B:>ansi-cl>spec>source>concept-symbols.tex.2
+  B:>ANSI-CL>spec>source>concept-subsets.tex.4
+  B:>ANSI-CL>spec>source>concept-strings.tex.2
+  B:>ansi-cl>spec>source>concept-streams.tex.24
+  B:>ansi-cl>spec>source>concept-slots.tex.32
+  B:>ansi-cl>spec>source>concept-sequences.tex.13
+  B:>ANSI-CL>spec>source>concept-reinit.tex.1
+  B:>ansi-cl>spec>source>concept-references.tex.39
+  B:>ANSI-CL>spec>source>concept-reader-algorithm.tex.46
+  B:>ANSI-CL>spec>source>concept-reader.tex.19
+  B:>ansi-cl>spec>source>concept-print.tex.71
+  B:>ansi-cl>spec>source>concept-pprint.tex.45
+  B:>ansi-cl>spec>source>concept-places.tex.43
+  B:>ansi-cl>spec>source>concept-pathnames.tex.47
+  B:>ansi-cl>spec>source>concept-packages.tex.37
+  B:>ANSI-CL>spec>source>concept-organization.tex.26
+  B:>ansi-cl>spec>source>concept-objects.tex.55
+  B:>ANSI-CL>spec>source>concept-meta-objects.tex.2
+  B:>ansi-cl>spec>source>concept-loop.tex.115
+  B:>ansi-cl>spec>source>concept-logical-pathnames.tex.17
+  B:>ansi-cl>spec>source>concept-history.tex.31
+  B:>ANSI-CL>spec>source>concept-hash-tables.tex.18
+  B:>ansi-cl>spec>source>concept-gfs-and-methods.tex.13
+  B:>ansi-cl>spec>source>concept-files.tex.17
+  B:>ansi-cl>spec>source>concept-filenames.tex.16
+  B:>ANSI-CL>spec>source>concept-extensions.tex.29
+  B:>ANSI-CL>spec>source>concept-exits.tex.2
+  B:>ansi-cl>spec>source>concept-eval.tex.177
+  B:>ansi-cl>spec>source>concept-environment.tex.15
+  B:>ansi-cl>spec>source>concept-destruction.tex.8
+  B:>ansi-cl>spec>source>concept-deprecated.tex.10
+  B:>ansi-cl>spec>source>concept-decls.tex.29
+  B:>ansi-cl>spec>source>concept-conses.tex.8
+  B:>ansi-cl>spec>source>concept-conditions.tex.45
+  B:>ansi-cl>spec>source>concept-compile.tex.144
+  B:>ansi-cl>spec>source>concept-classes.tex.69
+  B:>ansi-cl>spec>source>concept-cl-symbols.tex.18
+  B:>ANSI-CL>spec>source>concept-characters.tex.20
+  B:>ansi-cl>spec>source>concept-change-class.tex.3
+  B:>ansi-cl>spec>source>concept-bvl.tex.84
+  B:>ansi-cl>spec>source>concept-args.tex.19
+  B:>ANSI-CL>spec>source>chap-a.tex.17
+  B:>ANSI-CL>spec>source>chap-9.tex.4
+  B:>ANSI-CL>spec>source>chap-8.tex.23
+  B:>ANSI-CL>spec>source>chap-7.tex.25
+  B:>ansi-cl>spec>source>chap-6.tex.15
+  B:>ANSI-CL>spec>source>chap-5.tex.43
+  B:>ANSI-CL>spec>source>chap-4.tex.31
+  B:>ANSI-CL>spec>source>chap-3.tex.29
+  B:>ANSI-CL>spec>source>chap-26.tex.6
+  B:>ANSI-CL>spec>source>chap-25.tex.6
+  B:>ANSI-CL>spec>source>chap-24.tex.4
+  B:>ANSI-CL>spec>source>chap-23.tex.4
+  B:>ANSI-CL>spec>source>chap-22.tex.9
+  B:>ANSI-CL>spec>source>chap-21.tex.3
+  B:>ANSI-CL>spec>source>chap-20.tex.7
+  B:>ANSI-CL>spec>source>chap-2.tex.46
+  B:>ANSI-CL>spec>source>chap-19.tex.6
+  B:>ANSI-CL>spec>source>chap-18.tex.5
+  B:>ANSI-CL>spec>source>chap-17.tex.4
+  B:>ANSI-CL>spec>source>chap-16.tex.6
+  B:>ANSI-CL>spec>source>chap-15.tex.5
+  B:>ANSI-CL>spec>source>chap-14.tex.5
+  B:>ANSI-CL>spec>source>chap-13.tex.4
+  B:>ANSI-CL>spec>source>chap-12.tex.5
+  B:>ANSI-CL>spec>source>chap-11.tex.3
+  B:>ANSI-CL>spec>source>chap-10.tex.6
+  B:>ansi-cl>spec>source>chap-1.tex.46
+  B:>ansi-cl>spec>source>chap-0.tex.28
+  B:>ansi-cl>spec>source>appendix-removed.tex.31
+  B:>ansi-cl>spec>source>appendix-portability.tex.16
+  B:>ANSI-CL>spec>source>appendix-implem-defined.tex.55
+These files have the same source in Draft 14.10 and Draft 15.17:
+  B:>ansi-cl>spec>source>setup-sections-for-toc.tex.8, .tex.10
+  B:>ansi-cl>spec>source>setup-sections.tex.116, .tex.125
+  B:>ansi-cl>spec>source>setup-figures.tex.37, .tex.43
+Done comparing files.
+
+(The file index.idx is separately maintained from this set, 
+ and has changed as a result of the above changes.  This index 
+ is compiled under program control and the nature of the indexing
+ program has not materially changed.)

Change-Summary.text

@@ -0,0 +1,698 @@
+This file contains a `by-topic' summary of comments and actions taken 
+between version 14.10 (the second dpANS CL) and version 15.17.
+
+This document is NOT nor does it contain the official X3J13 responses
+to reviewers.   It is just the editor's working notes.
+ -kmp (12-May-94)
+
+=====[ Shepard #1 ]========================================
+
+ACTION:  X3J13 voted to ACCEPT the proposed change.
+
+IMPACT:  EDITORIAL.  No aspect of the language is believed to rely upon
+         the content of this table.  It is for cross-reference purposes 
+         only.
+
+EFFECT:
+
+  Old definition was:
+
+     \displaythree{General Purpose Array-Related Defined Names}{
+     adjust-array&array-in-bounds-p&svref\cr
+     adjustable-array-p&array-rank&upgraded-array-element-type\cr
+     aref&array-rank-limit&upgraded-complex-part-type\cr
+     array-dimension&array-row-major-index&vector\cr
+     array-dimension-limit&array-total-size&vector-pop\cr
+     array-dimensions&array-total-size-limit&vector-push\cr
+     array-element-type&fill-pointer&vector-push-extend\cr
+     array-has-fill-pointer-p&make-array&\cr
+     }
+
+  New table definition is:
+
+     %% Added ARRAY-DISPLACEMENT per Tom Shepard.  (X3J13 approved: May 4-5, 1994)
+     %% -kmp 9-May-94
+     \displaythree{General Purpose Array-Related Defined Names}{
+     adjust-array&array-has-fill-pointer-p&make-array\cr
+     adjustable-array-p&array-in-bounds-p&svref\cr
+     aref&array-rank&upgraded-array-element-type\cr
+     array-dimension&array-rank-limit&upgraded-complex-part-type\cr
+     array-dimension-limit&array-row-major-index&vector\cr
+     array-dimensions&array-total-size&vector-pop\cr
+     array-displacement&array-total-size-limit&vector-push\cr
+     array-element-type&fill-pointer&vector-push-extend\cr
+     }
+
+=====[ Boyer #1 ]========================================
+
+ACTION:  X3J13 voted to REJECT this proposal.
+
+IMPACT:  NONE.
+
+EFFECT:  NONE.
+
+=====[ Boyer #2 ]========================================
+
+ACTION:  X3J13 voted to clarify its wording.
+
+IMPACT:  EDITORIAL.  This change is believed to cause the document to say more
+         clearly what it had already said.
+
+EFFECT:
+
+  In 1.5.2 (Conforming Programs) on page 1-29:
+
+     %% Rewritten per X3J13 and Boyer/Kaufmann/Moore #2 (second public review).
+     %% -kmp 9-May-94
+     % \itemitem{2.} \term{Conforming code} shall not rely on any particular
+     %               interpretation of \term{implementation-dependent} features.
+     \itemitem{2.} \term{Conforming code} may use
+                   \term{implementation-dependent} features and values, 
+                   but shall not rely upon
+                   any particular interpretation of these features and values 
+                   other than those that are discovered by the execution of \term{code}.
+
+=====[ Boyer #3 ]========================================
+
+ACTION:  X3J13 voted to ACCEPT proposed change as an editorial clarification.
+
+IMPACT:  EDITORIAL.  This change just makes glossary cross-references from text
+         which obviously already means what the glossary says the words mean.
+
+EFFECT:
+
+  In 1.4.4.12 on page 1-22:
+
+     %% Added italic font for "argument precedence order" per Boyer/Kaufmann/Moore #3.
+     %% -kmp 9-May-94
+     This information describes the \term{argument precedence order}.
+     If it is omitted, the \term{argument precedence order} is the default (left to right).
+
+=====[ Boyer #4 ]========================================
+
+ACTION:  X3J13 voted to ACCEPT proposed change as an editorial clarification.
+
+IMPACT:  EDITORIAL.  This change makes the document consistent throughout.  
+         (There were numerous other references to the correct usage.)
+
+EFFECT:  
+
+  In 2.1.4.6, page 2-9:
+
+     %% "slash" => "backslash" as an editorial change per Boyer/Kaufmann/Moore #4.
+     %% This was right everywhere else in the manual--shame for it to be wrong here.
+     %% -kmp 9-May-94
+     \term{Backslash} is a \term{single escape} \term{character} in \term{standard syntax}.
+
+=====[ Boyer #5 ]========================================
+
+ACTION:  X3J13 voted to make several wording clarifications that we hope
+         will clear up this confusion.
+
+IMPACT:  EDITORIAL.  This just says differently what we all agree it meant to say
+         before, but hopefully in a less confusing way.
+
+EFFECT:
+
+  Changed the definition of "variable" in the glossary to the following.
+  Note that section SymbolsAsForms is 3.1.2.1.1 (Symbols as Forms).
+
+  \gentry{variable} \Noun\ 
+  %% Rewritten per Boyer/Kaufmann/Moore #5 (by X3J13 vote at May 4-5, 1994 meeting).
+  %% -kmp 9-May-94
+  %   %!!! Moon: This is certainly no valid definition, especially when contrasting
+  %   %          the variable namespace with the function namespace.
+  %   a \term{binding} in which a \term{symbol} is the \term{name}
+  %   used to refer to an \term{object}.
+    a \term{binding} in the ``variable'' \term{namespace}.
+    \Seesection\SymbolsAsForms.
+
+  \gentry{binding} \Noun\ 
+    an association between a \term{name} and that which the \term{name} 
+    denotes.  
+    \gexample{A lexical binding is a lexical association between a 
+              name and its value.}
+  %% Added per Boyer/Kaufmann/Moore #5 (by X3J13 vote at May 4-5, 1994 meeting).
+  %% -kmp 9-May-94
+    When the term \term{binding} is qualified by the name of a \term{namespace},
+    such as ``variable'' or ``function,'' 
+    it restricts the binding to the indicated namespace, as in:
+    \gexample{\specref{let} establishes variable bindings.}
+    or 
+    \gexample{\specref{let} establishes bindings of variables.}
+
+=====[ Boyer #6 ]========================================
+
+ACTION: X3J13 voted to ACCEPT the suggestion.
+
+IMPACT: EDITORIAL.  This just clarifies a situation that is implied in a number
+        of places but not said explicitly.
+
+EFFECT:
+
+  Represents the \term{type} 
+  %% Replaced per Boyer/Kaufmann/Moore #6 (by X3J13 vote at May 4-5, 1994 meeting).
+  %whose only \term{element} is \param{object}.
+  of all \param{x} for which \f{(eql \param{object} \param{x})} is true.
+
+=====[ Boyer #7 ]========================================
+
+ACTION: X3J13 voted to ACCEPT the suggestion.
+
+IMPACT: EDITORIAL.  This restricts the set of things over which COERCE is
+        defined to the set of things which were meaningfully covered under
+        the old, confusing wording.
+
+EFFECT: 
+   
+   \itemitem{\typeref{complex}}
+   
+   %% 4.8.0 7
+   If the \param{result-type} is \typeref{complex} 
+   %% "number" => "real" per Boyer/Kaufmann/Moore #7 (by X3J13 vote at May 4-5, 1994 meeting)
+   %% -kmp 9-May-94
+   and the \term{object} is a \term{real},
+   then the \param{result} is obtained by constructing a \term{complex}
+   whose real part is the \term{object} and
+   whose imaginary part is the result of \term{coercing} an \term{integer} zero
+   to the \term{type} of the \term{object} (using \funref{coerce}).
+   (If the real part is a \term{rational}, however, 
+   then the result must be represented as a \term{rational} rather
+   than a \term{complex}; \seesection\RuleOfCanonRepForComplexRationals.
+   So, for example, \f{(coerce 3 'complex)} is permissible,
+   but will return \f{3}, which is not a \term{complex}.)
+
+=====[ Boyer #8, #9 ]========================================
+
+ACTION: X3J13 voted to make a change to the glossary definition of "function name".
+
+IMPACT: EDTIORIAL.  It was plain from the uses in the text throughout the document
+        that there was an ambiguity of meaning that was widespread.  Since the
+        ambiguity can be pragmatically resolved, we decided to merely make the 
+        ambiguity explicit rather than making a technical change.
+
+EFFECT:
+
+  \gentry{function name} \Noun\ 
+    1. (in an \term{environment})
+       A \term{symbol} or a \term{list} \f{(setf \i{symbol})} 
+       that is the \term{name} of a \term{function} in that \term{environment}.
+  %   \editornote{KMP: I think that in many (but obviously not all) cases where
+  %                `function name' is used, `operator name' might be intended.
+  %                I'll be looking for such cases later, but if readers happen
+  %                to notice any of these, they should feel free to mark them.}%!!!
+  % !!! Moon: Not always with respect to an environment, see e.g., function block name.
+  %           Also, can sometimes name a macro or special operator or be fbound.
+  %% Added per Boyer/Kaufmann/Moore #8,#9 (by X3J13 vote at May 4-5, 1994 meeting)
+  %% -kmp 9-May-94
+    2. A \term{symbol} or a \term{list} \f{(setf \i{symbol})}.
+
+=====[ Boyer #10 ]========================================
+
+ACTION: X3J13 voted to cross-reference something else.
+
+IMPACT: EDITORIAL.  This is just cross-reference information.
+
+EFFECT:
+
+  In CONSTANTLY (on page 5-66):
+
+     \label See Also::
+     
+     %% "not" => "identity" per Boyer/Kaufmann/Moore #10 (by X3J13 vote at May 4-5, 1994 meeting)
+     %% -kmp 9-May-94
+     \funref{identity}
+
+=====[ Boyer #11 ]========================================
+
+ACTION: X3J13 voted to ACCEPT the proposed change.
+
+IMPACT: EDITORIAL.  Simple typo.
+
+EFFECT:
+
+  In SYMBOL (on page 10-2):
+
+     %% "historically" => "historical" per Boyer/Kaufmann/Moore #11 (by X3J13 vote at May 4-5, 1994 meeting)
+     %% -kmp 9-May-94
+
+=====[ Boyer #12 ]========================================
+
+Boyer #12:
+
+ACTION: X3J13 voted to make an editorial clarification.
+
+IMPACT: EDITORIAL.  This situation could not happen in practice because of
+        implications elsewhere in the document.
+
+EFFECT:
+
+  In USE-PACKAGE (on page 11-28):
+
+  Old Wording:
+
+    \param{package}---a \term{package designator}.
+       \Thepackage{keyword} cannot be supplied.
+       \Default{the \term{current package}}
+
+  New Wording:
+
+    \param{package}---a \term{package designator}.
+       \Default{the \term{current package}}
+     %% Next sentence reworded and moved per Boyer/Kaufmann/Moore #12
+     %% (by X3J13 vote at May 4-5, 1994 meeting)
+     %% -kmp 9-May-94
+     % \Thepackage{keyword} cannot be supplied.
+       The \param{package} cannot be \thepackage{keyword}.
+
+=====[ Boyer #13 ]========================================
+
+ACTION: X3J13 voted to ACCEPT the proposed change.
+
+IMPACT: EDITORIAL.  A change to indentation in a coding example,
+        not affecting correct execution -- only presentation.
+
+EFFECT:
+
+  The following indentation will be used in the Notes on page 14-17:
+    
+    %% Indentation fixed per Boyer/Kaufmann/Moore #13 (by X3J13 vote at May 4-5, 1994 meeting)
+    %% -kmp 9-May-94
+    \code
+     (defun subst (old new tree &rest x &key test test-not key)
+       (cond ((satisfies-the-test old tree :test test
+                                  :test-not test-not :key key)
+              new)
+             ((atom tree) tree)
+             (t (let ((a (apply #'subst old new (car tree) x))
+                      (d (apply #'subst old new (cdr tree) x)))
+                  (if (and (eql a (car tree))
+                           (eql d (cdr tree)))
+                      tree
+                      (cons a d))))))
+    \endcode
+
+=====[ Boyer #14 ]========================================
+
+ACTION: X3J13 voted to make changes to the text to clarify the status quo.
+
+IMPACT: EDITORIAL.  These issues were already implied by other passages, but
+        needed to be made less difficult to fish out.
+
+EFFECT:
+
+ 1. In 12.1.3.3 (on page 12-5), second paragraph, inserted "irrational" before 
+    "mathematical function":
+
+      If the arguments to 
+      %% Added "irrational" per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+      %% -kmp 9-May-94
+      %a
+      an irrational
+      mathematical \term{function} are all of type
+      ...
+
+ 2. Inserted a third paragraph:
+
+     %% Added per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+     %% -kmp 9-May-94
+     Float substitutability applies neither to the rational \term{functions} 
+           \funref{+},
+           \funref{-},
+           \funref{*},
+       and \funref{/} 
+     nor to the related \term{operators} 
+           \funref{1+},
+           \funref{1-},
+           \macref{incf},
+           \macref{decf},
+       and \funref{conjugate}.
+     For rational \term{functions},
+       if all arguments are \term{rational},
+         then the result is \term{rational}; 
+       if all arguments are of type \f{(or rational (complex rational))},
+         then the result is of type \f{(or rational (complex rational))}.
+
+ 3. In table 12-8, changed #c(1 0) to 1:
+
+     %% #c(1 0) => 1 per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+     %% -kmp 9-May-94
+     \funref{cis}    & \f{(cis 0) \EV\ 1 \i{or} \#c(1.0 0.0)} \cr
+
+=====[ Boyer #15 ]========================================
+
+ACTION: X3J13 voted to ACCEPT the proposed change.
+
+IMPACT: EDITORIAL.   This was just a typo.  The strange cross-reference was really
+        a cross-reference to a table that had long since gone away.
+
+EFFECT:
+
+  In the text of 12.1.6. (Interval Designators) at bottom of p12-9:
+
+     The \term{compound type specifier} form of the numeric \term{type specifiers}
+     %% Removed per Boyer/Kaufmann/Moore #15 (by X3J13 vote at May 4-5, 1994 meeting)
+     %% -kmp 9-May-94
+     %in \thenextfigure\ 
+     permit the user to specify an interval on the real number line
+
+=====[ Boyer #16 ]========================================
+
+ACTION: X3J13 voted to make a slightly different change.
+
+IMPACT: EDITORIAL.  This is just in the Notes (not a binding part anyway) and
+        only affects cross-reference information.
+
+EFFECT:
+
+  Old text:
+
+     \label See Also::
+     
+     \funref{realpart}, \funref{imagpart}
+     
+     \label Notes::
+     
+     \code
+      #c(a b) \EQ #.(complex a b)
+     \endcode
+
+  New text:
+
+    \label See Also::
+    
+    \funref{realpart},
+    \funref{imagpart},
+    %% Added per Boyer/Kaufmann/Moore #15 (by X3J13 vote at May 4-5, 1994 meeting)
+    %% -kmp 9-May-94
+    {\secref\SharpsignC}
+    
+    \label Notes:\None.
+    
+    %% Removed per Boyer/Kaufmann/Moore #15 (by X3J13 vote at May 4-5, 1994 meeting)
+    %% -kmp 9-May-94
+    % \code
+    %  #c(a b) \EQ #.(complex a b)
+    % \endcode
+
+=====[ Pitman #1 ]========================================
+
+ACTION: X3J13 noted this comment.
+
+IMPACT: NONE.
+
+EFFECT: Moral support.
+
+=====[ Pitman #2 ]========================================
+
+ACTION: X3J13 voted to ACCEPT the proposed action.
+
+IMPACT: EDITORIAL.  Removed an ill-formed and confusing fragment having no
+        useful meaning.
+
+EFFECT:
+
+  %% Removed per Pitman #2 (by X3J13 vote at May 4-5, 1994 meeting)
+  %% -kmp 9-May-94
+  %\auxbnf{symbol-name}{(\term{symbol} | \term{string})}
+
+
+=====[ Pitman #3 ]========================================
+
+ACTION: X3J13 voted to ACCEPT the proposed action.
+
+IMPACT: EDITORIAL. This is just frontmatter.
+
+EFFECT: 
+
+  On page "Credits v" in the front matter, added to 
+  Major Administrative Contributions the following:
+
+     Tyson, Mabry\cr               % Mailing lists at SRI
+
+=====[ Schulenburg #1 ]========================================
+
+
+ In the descriptions of SORT, REMOVE, REMOVE-DUPLICATES and SUBSTITUTE 
+ (and all friends) move the sentence "The result might or might not be simple
+ and might or might not be identical to sequence." to the Notes section
+ and prepend "If sequence is a vector, ...".
+
+ In Description for each of SORT, REMOVE, REMOVE-DUPLICATES, and SUBSTITUTE:
+
+     %% Moved to notes per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+     %% -kmp 9-May-94
+     % The result might or might not be simple, 
+     % and might or might not be \term{identical} to \param{sequence}.
+
+ In Notes for each of SORT, REMOVE, REMOVE-DUPLICATES, and SUBSTITUTE:
+
+     %% Moved from Description per Schulenburg #1 (by X3J13 vote at May 4-5, 1994 meeting).
+     %% -kmp 9-May-94
+     If \param{sequence} is a \term{vector},
+     the result might or might not be simple, 
+     and might or might not be \term{identical} to \param{sequence}.
+
+=====[ Misc #1 ]========================================
+
+ACTION: X3J13 voted to add Loeffler to major contributions list.
+
+IMPACT: EDITORIAL.  This is just frontmatter.
+
+EFFECT:
+
+  On page "Credits v" in the front matter, added to 
+  Major Administrative Contributions the following:
+
+     Loeffler, David D.\cr         % Mailing lists at MCC
+
+=====[ Dalton #1 (First Public Review) ]========================================
+
+ACTION: X3J13 reviewed follow-up comments on this matter and voted
+        to make a minor presentational change.
+
+IMPACT: EDITORIAL.  Just moving text from one place to another.
+
+EFFECT:
+
+  Created new section 1.5.2.2 (Character Set for Portable Code) and moved
+  the sentence "Portable code is written ..." from 1.5.2.1 to this new section.
+
+  In 1.5.2.1:
+
+    %% Moved to its own section (see below) per Dalton #1 (1st Public Review) 
+    %% by X3J13 vote May 4-5, 1994 (after 2nd public review).
+    %% -kmp 9-May-94
+    % %!!! Barmar wonders if this is really the right place for the next sentence.
+    % \term{Portable code} is written using only \term{standard characters}.
+
+  After 1.5.2.1 (to create 1.5.2.2:
+
+    \beginsubsubsection{Character Set for Portable Code}
+    
+    \term{Portable code} is written using only \term{standard characters}.
+    
+    \endsubsubsection%{Character Set for Portable Code}
+
+=====[ Dalton #6 (First Public Review) ]========================================
+
+ACTION: X3J13 reaffirmed its vote to REJECT this proposal.
+
+IMPACT: NONE.
+
+EFFECT: NONE.
+
+=====[ Dalton #7 (First Public Review) ]========================================
+
+ACTION: X3J13 reaffirmed its vote to REJECT this proposal.
+
+IMPACT: NONE.
+
+EFFECT: NONE.
+
+=====[ Dalton #8 (First Public Review) ]========================================
+
+ACTION: X3J13 reaffirmed its vote to REJECT this proposal.
+
+IMPACT: NONE.
+
+EFFECT: NONE.
+
+=====[ Dalton #10 (First Public Review) ]========================================
+
+ACTION: X3J13 reaffirmed its vote to REJECT this proposal.
+
+IMPACT: NONE.
+
+EFFECT: NONE.
+
+=====[ Misc #2 ]========================================
+
+ACTION: X3J13 voted to make detailed changes to the chairmanships.
+
+IMPACT: EDITORIAL.  This is just frontmatter.
+
+EFFECT: 
+
+  1. Change the erroneous title "Committee Chair" to "Ad Hoc Group Chairs":
+      
+	In the credits, on page "Credits v":
+      
+	  %Committee Chairs:&\cr
+	  Ad Hoc Group Chairs:&\cr
+
+  2. Remove Daniels, Waters (iteration), Purdue, and Pitman (Lisp1/Lisp2).
+
+     %% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+     %                           & Daniels, Andy       \cr
+     ...
+     %% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+     %                           & Waters, Richard C.  \cr
+     %                           & Perdue, Crispin     \cr
+     ...
+     %% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+     %                           & Pitman, Kent M.     \cr
+
+  3. Add "Graphics and Windows: Doug Rand."
+
+     %% Added per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+       Graphics \& Windows       & Douglas Rand        \cr
+
+  4. Add Daniels, Purdue to significant technical.  [Also added comments
+     to Pitman, Waters even though they were already in list.]
+
+      Barrett, Kim A.     &         % Review, Cleanups
+      Loosemore, Sandra   \cr       % Review, Compiler
+      Bobrow, Daniel G.   &         % CLOS
+      Margolin, Barry     \cr       % Review
+      Daniels, Andy       &         % Conditions
+      Moon, David A.      \cr       % Review, CLOS, Conditions
+      DeMichiel, Linda G.  &        % CLOS
+      Pitman, Kent M.     \cr       % Review, Conditions, Cleanup, Editor, Lisp1/Lisp2
+      Dussud, Patrick H.  &         % CLOS
+      Perdue, Crispin     \cr       % Iteration
+      Gabriel, Richard P. &         % Review, Editing, CLOS
+      Steele, Guy L., Jr. \cr       % Review, CLtL
+      Ida, Masayuki       &         % Administration of Public Review work
+      Waters, Richard C.  \cr       % Pretty Printer, Iteration
+      Kiczales, Gregor    &         % CLOS
+      White, JonL         \cr       % Review, LOOP
+
+=====[ Misc #3 ]========================================
+
+ACTION: X3J13 voted to clarify in 1.4.4.3 that the consequences are undefined
+        if these type restrictions are violated.
+
+IMPACT: EDITORIAL.  This is implied by other things, but it makes it more clear
+	to say it.
+
+EFFECT:
+
+  In 1.4.4.3 (The ``Arguments and Values'' Section of a Dictionary Entry):
+
+     %% I added the first part of this sentence as editorial discretion 
+     %% since I believe we strongly feel that this is not specified otherwise,
+     %% but we want to avoid an unexpected conflict in case it is. -kmp 9-May-94
+     Except as explicitly specified otherwise,
+     %% Added per X3J13 at May 4-5, 1994 meeting.  -kmp 9-May-94
+     the consequences are undefined if these type restrictions are violated.
+
+  In 1.4.4.22 (The ``Value Type'' Section of a Dictionary Entry):
+  
+     %% I added the first part of this sentence as editorial discretion 
+     %% since I believe we strongly feel that this is not specified otherwise,
+     %% but we want to avoid an unexpected conflict in case it is. -kmp 9-May-94
+     Except as explicitly specified otherwise,
+     %% Added per X3J13 at May 4-5, 1994 meeting.  -kmp 9-May-94
+     the consequences are undefined if this type restriction is violated.
+
+=====[ Editor #1 ]========================================
+
+ACTION: Even though we didn't vote it, I made a number of mechanical changes
+        (version number bumping, modification of change history, etc.)
+        necessary to the mechanics of producing a new draft.
+
+IMPACT: EDITORIAL.  This is just frontmatter.
+
+EFFECT:
+
+ 1. a. Add document numbers of public review comments for reference.
+    b. Correct lost reference to Cerys public review comment #21 in first review.
+    c. Add mention of 3 second public review comments, and Shepard's late comment.
+
+ 09-Sep-92 & Samson    & Public Review Comments (\#1). Documents X3J13/92-1001 to 92-1003.\cr
+ 22-Oct-92 & Rose, Yen & Public Review Comments (\#2). Documents X3J13/92-1101 to 92-1103.\cr
+ 23-Oct-92 & Staley    & Public Review Comments (\#3). Documents X3J13/92-1201 to 92-1204.\cr
+ 09-Nov-92 & Barrett   & Public Review Comments (\#4). Documents X3J13/92-3101 to 92-3110.\cr
+ 11-Nov-92 & Moon      & Public Review Comments (\#5). Documents X3J13/92-3201 to 92-3248.\cr
+ 17-Nov-92 & Loosemore & Public Review Comments (\#6). Documents X3J13/92-1301 to 92-1335.\cr
+ 23-Nov-92 & Margolin  & Public Review Comments (\#7). Documents X3J13/92-1401 to 92-1419.\cr
+ 23-Nov-92 & Withington & Public Review Comments (\#8a). Documents X3J13/92-1501 to 92-1512.\cr\cr
+ 23-Nov-92 & Feinberg   & Public Review Comments (\#8b). Documents X3J13/92-1601 to 92-1603.\cr
+ 23-Nov-92 & Wechsler   & Public Review Comments (\#8c). Documents X3J13/92-1701 to 92-1703.\cr
+ 23-Nov-92 & Moore     & Public Review Comments (\#9). Documents X3J13/92-1801 to 92-1802.\cr
+ 23-Nov-92 & Flanagan  & Public Review Comments (\#10). Documents X3J13/92-1901 to 92-1910.\cr
+ 23-Nov-92 & Dalton    & Public Review Comments (\#11). Documents X3J13/92-2001 to 92-2012.\cr
+ 23-Nov-92 & Gallagher & Public Review Comments (\#12). Documents X3J13/92-2101 to 92-2103.\cr
+ 23-Nov-92 & Norvig    & Public Review Comments (\#13). Documents X3J13/92-2201 to 92-2208.\cr
+ 24-Nov-92 & Robertson & Public Review Comments (\#14). Document X3J13/92-2301.\cr
+ 23-Nov-92 & Kawabe    & Public Review Comments (\#15). Documents X3J13/92-2401 to 92-2403.\cr
+ 23-Nov-92 & Barrett   & Public Review Comments (\#16). Documents X3J13/92-2511 to X3J13/92-2531.\cr
+ 23-Nov-92 & Wertheimer & Public Review Comments (\#17). Document X3J13/92-2601.\cr
+ 24-Nov-92 & Pitman    & Public Review Comments (\#18). Documents X3J13/92-2701 to 92-2742.\cr
+ 24-Nov-92 & Mato Mira & Public Review Comments (\#19). Documents X3J13/92-2801 to 92-2805.\cr
+ 24-Nov-92 & Philpot   & Public Review Comments (\#20). Document X3J13/92-2901.\cr
+ 23-Nov-92 & Cerys     & Public Review Comments (\#21). Document X3J13/92-3001.\cr
+ 30-Aug-93 & Pitman    & Draft 13.65 (for X3J13 consideration). Document X3J13/93-101.\cr
+ 04-Oct-93 & X3J13     & Minor fixes to Draft 13.65 before sending to X3.\cr
+ 05-Oct-93 & Pitman    & Draft 14.10 (for X3 consideration). Document X3J13/93-102.\cr
+ 08-Nov-93 & Dalton    & ``reply to reply to pr comments''.  Document X3J13/94-311.\cr
+ 04-Apr-94 & Boyer,    & \cr
+           & Kaufmann, & \cr
+           & Moore     & Public Review Comments (\#1).  Document X3J13/94-305.\cr
+ 05-Apr-94 & Pitman    & Public Review Comments (\#2).  Document X3J13/94-306.\cr
+ 14-Mar-94 & Schulenburg & Public Review Comments (\#3).  Document X3J13/94-307.\cr
+ 04-Apr-94 & Shepard   & Late commentary.  Document X3J13/94-309.\cr
+ 05-May-94 & X3J13     & Editorial-only changes to Draft 14.10 in response to comments.\cr
+ 10-May-94 & Pitman    & Draft {\rev} (for X3 consideration). Document {\DocumentNumber}.\cr
+
+ 2. Assigned new document number:
+
+    \def\DocumentNumber{X3J13/94-101}
+
+ 3. Document version with be 15.nn.  Date will be assigned automatically 
+    my by checkpoint facility.
+
+ 4. Changed the word "Draft" to "Version" in the banner on each page, 
+    so that when final approvals are made and this is no longer a 
+    "draft proposed" American National Standard, the word "Draft" on 
+    every page won't confuse people.
+
+=====[ Editor #2 ]========================================
+
+ACTION: In both cases in MISC #3, I prepended the phrase
+	  "Except as explicitly specified otherwise,"
+	just to make sure we are not accidentally creating an apparent attempt
+        to override some preexisting text.  [GLS and KAB concurred with me that 
+ 	this was reasonable to do under the heading of "editorial discretion".]
+
+IMPACT: EDITORIAL.  This assures that an editorial change we made in the 
+	meeting is really just that and doesn't have any unexpected surprises.
+
+EFFECT: See Misc #3 above.
+
+=====[ Editor #3 ]========================================
+
+Action: I added index cross-references for the format operations and many
+	readmacros, which were omitted in the previous pass due to
+	lack of time.  (In some cases, it was painful to do the necessary 
+	superquoting to make both TeX and my indexing program happy; 
+        in those cases, I just gave up, figuring some indexing was better 
+	than no indexing.)
+
+IMPACT: EDITORIAL.  This only affects indexing, which is really frontmatter
+        (or backmatter), but in any case is not a formal part of the spec.
+
+EFFECT: Numerous changes to the source files concept-macro-chars.tex, 
+        concept-format.tex, and dict-printer.tex.  See the detailed 
+	Change-Log.text file which accompanies this file.

Issue-Index.text

@@ -0,0 +1,1747 @@
+====================[ CL Specification Issue Index ]====================
+&ENVIRONMENT-BINDING-ORDER:FIRST  3-42
+ACCESS-ERROR-NAME  9-2, 9-14
+ADJUST-ARRAY-DISPLACEMENT  15-15..15-16
+ADJUST-ARRAY-FILL-POINTER  15-15
+ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY  15-12, 15-14, 15-16, 15-18
+ALLOCATE-INSTANCE:ADD  7-30..7-31
+ALLOW-LOCAL-INLINE:INLINE-NOTINLINE  3-93..3-94
+ALLOW-OTHER-KEYS-NIL:PERMIT  3-36
+AREF-1D  5-5..5-6, 15-28..15-29
+ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT  3-35, 3-42, 3-52
+ARGUMENT-MISMATCH-ERROR-MOON:FIX  3-50, 3-51, 3-52
+ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS  3-50..3-52
+ARGUMENTS-UNDERSPECIFIED:SPECIFY  10-22, 12-73, 14-37, 16-13, 17-8, 18-4, 
+ 21-15, 21-17, 21-18, 21-19, 21-24, 23-5, 23-6, 23-10, 23-16
+ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM  15-5, 15-6, 15-7, 15-8, 15-9, 15-10, 
+ 16-2, 16-3, 16-4
+ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM  15-1, 15-15, 15-18, 15-28, 
+ 15-30, 15-31, 26-61, 26-61..26-62, 26-62, 26-63
+ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING  4-3, 4-35..4-36, 
+ 4-36..4-37, 4-37, 4-39..4-40, 4-40, 12-12, 12-56, 12-60, 15-3, 15-5, 15-7, 
+ 15-8, 15-21, 15-29..15-30
+ASSERT-ERROR-TYPE:ERROR  9-15
+ASSOC-RASSOC-IF-KEY  14-44, 14-44..14-45, 14-48
+ASSOC-RASSOC-IF-KEY:YES  14-43..14-44, 14-47
+BOA-AUX-INITIALIZATION:ERROR-ON-READ  3-46
+BREAK-ON-WARNINGS-OBSOLETE:REMOVE  9-30, 9-37, A-1
+BROADCAST-STREAM-RETURN-VALUES:CLARIFY-MINIMALLY  21-7..21-8
+BUTLAST-NEGATIVE:SHOULD-SIGNAL  14-33, 14-34
+CHANGE-CLASS-INITARGS:PERMIT  7-9, 7-38, 7-39
+CHAR-NAME-CASE:X3J13-MAR-91  13-24
+CHARACTER-LOOSE-ENDS:FIX  2-31, 4-31
+CHARACTER-PROPOSAL:2  16-1
+CHARACTER-PROPOSAL:2-1-1  2-20, 2-26, 2-31, 5-7, A-1, 13-2, 13-3, 13-5, 13-7, 
+ 13-9, 13-10, 13-11, 13-11..13-12, 13-12, 13-16, 13-19, 13-22..13-23, 16-6, 
+ 23-4, 26-10
+CHARACTER-PROPOSAL:2-1-2  13-22
+CHARACTER-PROPOSAL:2-2-1  2-2..2-4
+CHARACTER-PROPOSAL:2-3-1  13-8, 13-9
+CHARACTER-PROPOSAL:2-3-2  15-3, 16-2
+CHARACTER-PROPOSAL:2-3-3  16-2, 16-2..16-3
+CHARACTER-PROPOSAL:2-3-4  16-3
+CHARACTER-PROPOSAL:2-3-5  16-3..16-4
+CHARACTER-PROPOSAL:2-3-6  16-13, 21-56
+CHARACTER-PROPOSAL:2-4-1  13-2
+CHARACTER-PROPOSAL:2-4-2  13-7
+CHARACTER-PROPOSAL:2-4-3  13-2
+CHARACTER-PROPOSAL:2-5-2  21-32, 21-34..21-35, 21-35
+CHARACTER-PROPOSAL:2-5-6  21-53, 21-54, 21-56
+CHARACTER-PROPOSAL:2-5-7  21-31
+CHARACTER-PROPOSAL:2-6-1  13-1
+CHARACTER-PROPOSAL:2-6-2  10-2
+CHARACTER-PROPOSAL:2-6-3  10-2
+CHARACTER-PROPOSAL:2-6-5  17-9
+CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT  4-3..4-4, 13-8, 13-8..13-9, 13-9, 
+ 15-29, 16-2, 16-4, 26-6, 26-23
+CLASS-OBJECT-SPECIALIZER:AFFIRM  7-19, 26-43
+CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET  9-11
+CLOS-CONDITIONS:INTEGRATE  4-2, 9-11, 9-43..9-44, 9-44, 9-44..9-45
+CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST  7-22
+CLOS-MACRO-COMPILATION:MINIMAL  3-22
+CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY  21-39, 21-52
+CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY  19-15..19-16, 19-27, 19-35, 19-39, 
+ 20-1..20-2, 20-4, 20-5, 21-14, 21-39, 24-5, 26-55..26-56
+COERCING-SETF-NAME-TO-FUNCTION:ALL-FUNCTION-NAMES  4-31
+COLON-NUMBER  2-14
+COMMON-FEATURES:SPECIFY  24-10..24-11
+COMMON-TYPE:REMOVE  4-2, 4-26, A-1
+COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX  3-58
+COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY  3-22, 3-71, 4-33..4-34, 
+ 5-16, 5-31, 5-34, 5-92, 5-94, 5-97, 7-64, 7-68, 7-71, 7-85, 8-14, 9-46, 
+ 11-31
+COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE  19-39, 24-3, 24-5
+COMPILE-FILE-PACKAGE  24-4
+COMPILE-FILE-PATHNAME-ARGUMENTS:MAKE-CONSISTENT  24-5
+COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY  3-24, 3-27..3-28
+COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN  3-57, 4-22, 24-4, 26-12
+COMPILER-DIAGNOSTICS:USE-HANDLER  3-28, 3-58, 9-2, 9-12, 24-3, 24-4
+COMPILER-LET-CONFUSION:ELIMINATE  3-6, A-1
+COMPILER-VERBOSITY:LIKE-LOAD  24-3, 24-4, 24-13..24-14, 24-14
+COMPILER-WARNING-STREAM  3-28, 3-58, 24-4
+COMPLEX-ATAN-BRANCH-CUT:TWEAK  12-29, 12-30, 12-31
+COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE  12-29, 12-30, 12-33, 12-34
+COMPLEX-RATIONAL-RESULT:EXTEND  12-5, 12-39..12-40, 12-41, 12-42, 12-46
+COMPUTE-APPLICABLE-METHODS:GENERIC  7-76
+CONCATENATE-SEQUENCE:SIGNAL-ERROR  4-31, 17-8, 17-8..17-9, 17-10, 17-11, 
+ 17-29, 17-29..17-30, 17-30, 17-31, 17-32
+CONDITION-ACCESSORS-SETFABLE:NO  5-5..5-6
+CONDITION-RESTARTS:BUGGY  9-11
+CONDITION-RESTARTS:PERMIT-ASSOCIATION  9-8, 9-9, 9-10, 9-49, 9-50, 9-51, 
+ 9-55, 9-56, 9-58, 9-61, 9-62..9-63, 9-68, 9-69, 26-4, 26-15
+CONDITION-SLOTS:HIDDEN  4-17, 9-11
+CONS-TYPE-SPECIFIER:ADD  14-5
+CONSTANT-CIRCULAR-COMPILATION:YES  3-26
+CONSTANT-COLLAPSING:GENERALIZE  3-26
+CONSTANT-COMPILABLE-TYPES:SPECIFY  3-23..3-24
+CONSTANT-FUNCTION-COMPILATION:NO  3-26
+CONSTANT-MODIFICATION:DISALLOW  3-66, 14-15, 14-17, 14-53, 14-58, 14-59, 
+ 14-62, 15-19, 15-32, 15-37, 16-6, 17-6, 17-20, 17-28, 17-32, 17-35, 17-36
+CONSTANTP-DEFINITION:INTENTIONAL  3-104..3-105
+CONSTANTP-ENVIRONMENT:ADD-ARG  3-104..3-105
+CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE  12-6..12-7
+COPY-SYMBOL-COPY-PLIST:COPY-LIST  10-7
+COPY-SYMBOL-PRINT-NAME:EQUAL  10-7
+DATA-IO:ADD-SUPPORT  9-2, 9-3, 22-58, 22-59..22-60, 22-76..22-78, 22-79, 
+ 22-79..22-80, 23-20
+DATA-TYPES-HIERARCHY-UNDERSPECIFIED  4-2, 4-25, 8-17
+DEBUGGER-HOOK-VS-BREAK:CLARIFY  9-33
+DECLARATION-SCOPE:NO-HOISTING  3-30..3-32, 5-21
+DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE  3-91, 3-91..3-92
+DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION  3-29..3-30, 3-82, 3-84, 
+ 3-95
+DECLARE-MACROS:FLUSH  3-82..3-83, 3-84
+DECLARE-TYPE-FREE:LEXICAL  3-90..3-91
+DECLS-AND-DOC  3-56, 3-67..3-70, 3-70..3-73, 3-79..3-80, 3-83..3-84, 
+ 3-100..3-102, 4-33..4-34, 5-15..5-17, 5-20..5-24, 5-35..5-36, 5-36..5-38, 
+ 5-79..5-80, 5-87..5-89, 5-93..5-96, 5-96..5-98, 6-31..6-35, 6-35..6-36, 
+ 6-37..6-38, 7-56..7-58, 7-58..7-60, 7-65..7-68, 7-69..7-71, 7-76..7-85, 
+ 9-38..9-41, 9-56..9-61, 11-21..11-24, 11-33..11-35, 18-13..18-14, 
+ 21-37..21-39, 21-40..21-41, 21-54..21-55, 21-55..21-57, 22-51..22-53
+DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE  25-5
+DEFCONSTANT-SPECIAL:NO  5-31
+DEFGENERIC-DECLARE:ALLOW-MULTIPLE  7-66, 7-67
+DEFINE-COMPILER-MACRO:X3J13-NOV89  3-1, 3-15..3-17, 3-20, 3-22, 3-42, 
+ 3-66..3-67, 3-73, 11-5, 26-12, 26-53
+DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY  
+ 9-42..9-47
+DEFINE-METHOD-COMBINATION:CLARIFY  7-82
+DEFINING-MACROS-NON-TOP-LEVEL:ALLOW  3-60, 3-71, 4-33, 5-21, 5-31, 5-32, 
+ 5-94, 5-97
+DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS  3-71, 4-33, 5-15, 5-20, 5-97
+DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION  3-42, 3-44, 3-72..3-73
+DEFMETHOD-DECLARATION-SCOPE:CORRESPONDS-TO-BINDINGS  7-70..7-71
+DEFPACKAGE:ADDITION  11-29..11-33
+DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY  3-46, 3-46..3-47
+DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT  8-6
+DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND  8-3
+DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT  8-6
+DEFSTRUCT-COPIER:ARGUMENT-TYPE  8-6, 8-18, 26-15
+DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED  8-3
+DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED  8-2
+DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93  8-1, 8-2, 8-11..8-12, 8-12, 
+ 22-2, 22-12, 22-16, 22-22, 22-57, 22-58, 22-59, 22-70
+DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES  8-12
+DEFSTRUCT-REDEFINITION:ERROR  8-13
+DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR  8-17
+DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER  8-3..8-4
+DEFTYPE-DESTRUCTURING:YES  3-48, 26-17
+DEFTYPE-KEY:ALLOW  3-48, 26-17
+DEFVAR-DOCUMENTATION:UNEVALUATED  5-31, 5-32
+DEFVAR-INIT-TIME:NOT-DELAYED  5-32
+DEFVAR-INITIALIZATION:CONSERVATIVE  5-32
+DEPRECATION-POSITION:LIMITED  A-1
+DESCRIBE-INTERACTIVE:NO  25-10
+DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT  25-9, 25-9..25-10, 25-10..25-11
+DESTRUCTIVE-OPERATIONS:SPECIFY  3-54..3-55
+DESTRUCTURING-BIND:NEW-MACRO  5-35..5-36
+DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL  25-17
+DISPLACED-ARRAY-PREDICATE:ADD  15-22..15-23
+DO-SYMBOLS-BLOCK-SCOPE:ENTIRE-FORM  11-34
+DO-SYMBOLS-DUPLICATES  11-34
+DOCUMENTATION-FUNCTION-BUGS:FIX  3-68, 3-71, 5-15, 5-92, 5-96..5-97, 7-64, 
+ 7-71, 7-81, 8-2..8-3, 11-29, 11-29..11-30, 25-18..25-19, 25-19, 25-20, 
+ 25-21
+DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT  1-22, 25-17..25-21
+DOTIMES-IGNORE:X3J13-MAR91  3-85..3-86, 26-32..26-33
+DOTTED-LIST-ARGUMENTS:CLARIFY  14-1, 14-11, 14-12..14-13, 14-13, 14-16, 
+ 14-18..14-19, 14-23, 14-24, 14-25, 14-27, 14-28, 14-29, 14-30, 14-31..14-33, 
+ 14-33, 14-34, 14-35, 14-36..14-37, 14-37, 14-38, 14-41
+DOTTED-MACRO-FORMS:ALLOW  3-43
+DRIBBLE-TECHNIQUE  25-24
+DYNAMIC-EXTENT-FUNCTION:EXTEND  3-86
+DYNAMIC-EXTENT:NEW-DECLARATION  3-82, 3-84, 3-86..3-89
+EQUAL-STRUCTURE:MAYBE-STATUS-QUO  5-60, 5-60..5-61, 5-61..5-62, 5-62..5-63, 
+ 5-63, 5-64
+ERROR-TERMINOLOGY-WARNING:MIGHT  1-18
+EVAL-OTHER:SELF-EVALUATE  3-9
+EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE  24-6
+EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS  1-33, 3-60, 3-62..3-63
+EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993  1-33, 3-60
+EVALHOOK-STEP-CONFUSION:FIX  3-60
+EVALHOOK-STEP-CONFUSION:X3J13-NOV-89  3-59, 25-13, 25-14
+EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS  5-51
+EXIT-EXTENT:MINIMAL  5-13, 5-45, 5-45..5-47, 5-50, 5-52..5-54
+EXPT-RATIO:P.211  12-42
+EXTENSIONS-POSITION:DOCUMENTATION  1-31
+EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM  24-3, 24-3..24-4, 24-6, 
+ 24-7
+EXTRA-RETURN-VALUES:NO  1-31
+FILE-OPEN-ERROR:SIGNAL-FILE-ERROR  19-2, 19-16..19-17, 19-19, 19-22, 19-27, 
+ 19-30, 19-32, 19-33, 19-34, 19-36, 19-38, 19-40, 20-3, 20-4, 20-5, 20-6, 
+ 20-7, 20-8, 20-9, 20-10, 21-36, 21-38, 21-39, 24-4, 24-5, 24-6, 24-8, 24-16, 
+ 25-22, 25-24
+FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION  12-17, 12-20, 12-82, 15-30
+FLET-DECLARATIONS  5-20..5-21, 5-23
+FLET-DECLARATIONS:ALLOW  5-20
+FLET-IMPLICIT-BLOCK:YES  3-71, 4-33, 5-20, 5-94, 5-97
+FLOAT-UNDERFLOW:ADD-VARIABLES  12-87..12-88
+FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89  9-2, 12-90, 12-91
+FORMAT-ATSIGN-COLON  22-23
+FORMAT-COLON-UPARROW-SCOPE  22-41
+FORMAT-COMMA-INTERVAL  22-26
+FORMAT-E-EXPONENT-SIGN:FORCE-SIGN  22-29
+FORMAT-OP-C  22-24
+FORMAT-PRETTY-PRINT:YES  22-24, 22-25, 22-26, 22-27, 22-28, 22-29..22-30, 
+ 22-30, 22-31, 22-76
+FORMAT-STRING-ARGUMENTS:SPECIFY  4-42, 9-3, 9-3..9-4, 9-4, 9-15, 9-19, 9-25, 
+ 9-26, 9-28, 9-29, 9-31, 9-33, 9-34, 9-36, 9-48, 9-63, 9-65, 21-44, 22-16, 
+ 22-45, 22-80, 26-4, 26-26
+FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED  3-8
+FUNCTION-COMPOSITION:JAN89-X3J13  5-65..5-66, 5-66
+FUNCTION-DEFINITION:JAN89-X3J13  5-26..5-27
+FUNCTION-NAME:LARGE  3-57, 3-93, 3-94, 3-95, 5-5..5-6, 5-6, 5-10, 5-10..5-11, 
+ 5-15..5-17, 5-17, 5-18, 5-19, 5-20, 5-25..5-26, 7-29, 7-30, 7-66, 25-12, 
+ 25-17, 25-22
+FUNCTION-TYPE  4-39
+FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE  4-21
+FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD  4-20, 4-20..4-21
+FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE  4-20
+FUNCTION-TYPE:X3J13-MARCH-88  3-75, 3-80..3-81, 4-2, 4-20..4-21, 4-22, 4-31, 
+ 5-14, 5-17, 5-24, 5-25, 5-28, 10-11, 14-41, 17-10
+GENERALIZE-PRETTY-PRINTER:UNIFY  22-16, 22-47, 22-49, 22-51, 22-52, 22-53, 
+ 22-57, 22-58, 22-75
+GENERIC-FLET-POORLY-DESIGNED:DELETE  3-6, 3-8, 3-30, 3-40, 3-50, 3-83..3-84, 
+ 3-94, 3-95, 4-23, 4-25, 7-12, 7-17, 7-18, 7-49
+GENERIC-FUNCTION-POORLY-DESIGNED:DELETE  7-68
+GENSYM-NAME-STICKINESS:LIKE-TEFLON  1-33, 10-8, 10-9..10-10
+GENTEMP-BAD-IDEA:DEPRECATE  1-33
+GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD  23-13, 23-15
+GET-SETF-METHOD-ENVIRONMENT:ADD-ARG  3-42, 5-21, 5-92, 5-98, 5-99
+HASH-TABLE-ACCESS:X3J13-MAR-89  18-7..18-8, 18-8, 18-9, 18-9..18-10
+HASH-TABLE-KEY-MODIFICATION:SPECIFY  18-2..18-3
+HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER  11-21..11-24, 18-13..18-14
+HASH-TABLE-REHASH-SIZE-INTEGER  18-5, 18-7..18-8
+HASH-TABLE-SIZE:INTENDED-ENTRIES  18-1, 18-4, 18-5, 18-8
+HASH-TABLE-TESTS:ADD-EQUALP  18-1, 18-4
+IEEE-ATAN-BRANCH-CUT:SPLIT  12-31, 12-46, 12-49, 12-58
+IGNORE-USE-TERMINOLOGY:VALUE-ONLY  3-85..3-86, 26-26, 26-47, 26-63
+IMPORT-SETF-SYMBOL-PACKAGE  11-13
+IN-PACKAGE-FUNCTIONALITY:MAR89-X3J13  11-26
+IN-SYNTAX:MINIMAL  24-4, 24-7
+INITIALIZATION-FUNCTION-KEYWORD-CHECKING  7-2, 7-3, 7-30, 7-31, 7-32, 7-34, 
+ 7-35, 7-49, 7-88
+ISO-COMPATIBILITY:ADD-SUBSTRATE  3-3, 3-56..3-57, 3-77..3-79
+JUN90-TRIVIAL-ISSUES:11  6-1
+JUN90-TRIVIAL-ISSUES:14  9-8
+JUN90-TRIVIAL-ISSUES:24  16-2..16-3, 16-4
+JUN90-TRIVIAL-ISSUES:25  25-24
+JUN90-TRIVIAL-ISSUES:27  3-102, 5-9..5-10
+JUN90-TRIVIAL-ISSUES:3  22-68
+JUN90-TRIVIAL-ISSUES:4  5-2
+JUN90-TRIVIAL-ISSUES:5  19-37
+JUN90-TRIVIAL-ISSUES:9  4-22, 4-23, 4-24, 4-25
+KEYWORD-ARGUMENT-NAME-PACKAGE:ANY  3-36, 4-20
+KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92  3-18, 3-42, 3-66, 3-67, 3-73, 
+ 3-74, 3-86, 3-94, 5-36..5-37, 5-37, 5-94, 5-99, 5-100, 24-3, 24-6, 26-31, 
+ 26-55
+LAST-N  14-34, 14-34..14-35, 14-35
+LCM-NO-ARGUMENTS:1  12-44
+LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED  6-43, 7-73, 7-75, 22-48, 
+ 22-56
+LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92  13-2, 13-5
+LISP-PACKAGE-NAME:COMMON-LISP  11-4, 11-4..11-6
+LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES  11-5, 11-6, 26-51
+LISP-SYMBOL-REDEFINITION:MAR89-X3J13  3-80, 5-22, 10-2, 10-13, 11-5..11-6
+LOAD-OBJECTS:MAKE-LOAD-FORM  3-26, 3-27, 7-51..7-55, 7-55..7-56, 24-4
+LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM  3-6
+LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM  3-63..3-65
+LOAD-TRUENAME:NEW-PATHNAME-VARIABLES  24-4, 24-7, 24-7..24-8, 24-12, 24-13
+LOCALLY-TOP-LEVEL:SPECIAL-FORM  3-100, 3-101, 3-102
+LOOP-AND-DISCREPANCY:NO-REITERATION  6-7
+LOOP-FOR-AS-ON-TYPO:FIX-TYPO  6-12
+LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE  6-2
+LOOP-MISCELLANEOUS-REPAIRS:FIX  1-8, 1-8..1-9, 6-2, 6-4, 6-5, 6-9, 
+ 6-11..6-12, 6-16, 6-24, 6-25, 6-27, 6-30, 6-40
+LOOP-NAMED-BLOCK-NIL:OVERRIDE  6-3, 6-21, 6-22, 6-27
+LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS  6-14, 6-15
+LOOP-SYNTAX-OVERHAUL:REPAIR  6-38..6-40
+MACRO-AS-FUNCTION:DISALLOW  1-31
+MACRO-DECLARATIONS:MAKE-EXPLICIT  3-87, 3-94, 3-95
+MACRO-ENVIRONMENT-EXTENT:DYNAMIC  3-42, 3-81, 7-72
+MACRO-FUNCTION-ENVIRONMENT  3-73, 3-74
+MACRO-FUNCTION-ENVIRONMENT:YES  3-42
+MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS  3-23
+MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE  3-80
+MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT  3-80, 3-81
+MACROEXPAND-RETURN-VALUE:TRUE  3-75
+MAKE-LOAD-FORM-CONFUSION:REWRITE  3-27, 7-51..7-55, 7-55..7-56
+MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS  7-55..7-56, 7-56
+MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT  11-20, 11-30
+MAP-INTO:ADD-FUNCTION  17-12..17-13
+MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE  3-53, 5-68, 6-8, 6-38, 
+ 11-24, 11-35, 14-15, 14-17, 14-18, 14-40, 14-42, 14-45, 14-48, 14-53, 14-54, 
+ 14-58, 14-59, 14-60, 14-62, 17-11, 17-14, 17-16, 17-20, 17-21, 17-22, 17-24, 
+ 17-25, 17-28, 17-32, 17-35, 17-36, 18-13, 18-14, 21-55, 21-57
+METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED  4-17
+METHOD-COMBINATION-ARGUMENTS:CLARIFY  7-81
+METHOD-INITFORM:FORBID-CALL-NEXT-METHOD  7-73, 7-74
+MUFFLE-WARNING-CONDITION-ARGUMENT  9-69
+MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES  5-83
+MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED  5-86
+NINTERSECTION-DESTRUCTION  14-53
+NINTERSECTION-DESTRUCTION:REVERT  14-52
+NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93  5-55, 14-28..14-29
+NTH-VALUE:ADD  5-86..5-87
+OPTIMIZE-DEBUG-INFO:NEW-QUALITY  3-97, 26-41
+PACKAGE-CLUTTER:REDUCE  11-4, 11-4..11-5, 11-5, 11-7
+PACKAGE-DELETION:NEW-FUNCTION  11-12, 11-14, 11-17..11-20, 11-36
+PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE  11-8, 11-9, 11-11, 11-12, 
+ 11-14, 11-15, 11-16, 11-17, 11-20, 11-24, 11-25, 11-27, 11-28, 11-29, 11-33, 
+ 11-35, 11-36, 11-36..11-37, 11-37, 11-38, 11-39
+PARSE-ERROR-STREAM:SPLIT-TYPES  2-33, 2-39, 2-40, 9-2, 9-14, 23-23
+PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT  19-4..19-5, 19-17, 19-20, 19-37, 
+ 19-40
+PATHNAME-COMPONENT-VALUE:SPECIFY  19-4, 19-5, 19-6..19-10
+PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES  19-1, 19-2, 19-17, 19-31, 
+ 19-39, 21-36, 21-39, 24-5, 24-6, 24-8, 25-22, 25-24, 26-25, 26-39, 26-43
+PATHNAME-LOGICAL:ADD  5-5..5-6, 19-12..19-14, 19-16, 19-17, 19-19, 19-22, 
+ 19-22..19-23, 19-23..19-27, 19-27, 19-30, 19-31, 19-32, 19-33, 19-34, 
+ 19-35..19-36, 19-38, 19-39, 19-40, 20-3, 20-3..20-4, 20-4, 20-5, 20-6, 20-7, 
+ 20-8, 20-8..20-9, 20-9, 20-10, 21-36, 21-39, 24-3, 24-5, 24-5..24-6, 24-6, 
+ 24-8, 25-22, 25-24, 26-43
+PATHNAME-PRINT-READ:SHARPSIGN-P  2-36, 19-32, 22-11, 22-45
+PATHNAME-STREAM  19-15, 19-20, 19-27, 19-29, 19-31, 19-33, 19-34, 19-35, 
+ 19-38, 24-5
+PATHNAME-STREAM:FILES-OR-SYNONYM  26-55..26-56
+PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION  19-5, 19-7..19-8, 
+ 19-17..19-18, 19-20, 19-20..19-22, 19-39..19-40, 26-62
+PATHNAME-SYMBOL  19-29, 19-30, 19-31
+PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE  19-2
+PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN  19-5..19-6, 19-6, 19-17, 19-20, 
+ 19-30, 19-38, 25-32, 26-62
+PATHNAME-WILD:NEW-FUNCTIONS  19-20..19-22, 19-29..19-30, 19-33..19-34, 19-34, 
+ 19-36..19-38, 20-4, 20-6, 20-7, 20-8, 20-9, 20-10, 21-35, 24-4, 24-8
+PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR  21-17, 21-18, 21-22
+PLIST-DUPLICATES:ALLOW  3-35..3-36, 7-2, 10-17, 10-18, 10-19, 14-48..14-49, 
+ 14-50, 14-51, 26-31, 26-33, 26-46
+PRETTY-PRINT-INTERFACE  22-14..22-22, 22-23, 22-31..22-32, 22-32..22-34, 
+ 22-46, 22-46..22-47, 22-47..22-48, 22-48, 22-49..22-50, 22-50..22-51, 
+ 22-51..22-53, 22-53..22-55, 22-55..22-56, 22-57, 22-60..22-61, 22-63, 22-74, 
+ 22-75, 22-78..22-79
+PRINC-READABLY:X3J13-DEC-91  22-26, 22-27, 22-28, 22-30, 22-31, 22-63, 22-64, 
+ 22-65
+PRINT-CASE-BEHAVIOR:CLARIFY  22-4, 22-6, 22-68
+PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE  22-68
+PRINT-CIRCLE-SHARED:RESPECT-PRINT-CIRCLE  22-69..22-70
+PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK  8-12, 22-59, 22-69..22-70
+PRINT-READABLY-BEHAVIOR:CLARIFY  22-2, 22-4, 22-5, 22-6, 22-8, 22-9, 22-10, 
+ 22-11, 22-77, 22-78, 26-45
+PRINT-WHITESPACE:JUST-ONE-SPACE  22-8, 22-8..22-9
+PRINTER-WHITESPACE:JUST-ONE-SPACE  22-1, 22-10, 22-75
+PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO  3-22, 3-83, 11-6
+PUSH-EVALUATION-ORDER:FIRST-ITEM  5-92, 5-101, 5-103, 9-16, 12-44, 12-79, 
+ 14-24, 14-24..14-25, 14-51, 14-55, 14-56
+PUSH-EVALUATION-ORDER:ITEM-FIRST  5-1..5-3
+PUSHNEW-STORE-REQUIRED:UNSPECIFIED  14-55..14-56
+QUOTE-SEMANTICS:NO-COPYING  3-58, 3-59
+RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER  17-27, 17-33
+RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL  12-66, 16-7, 
+ 16-10, 17-7, 17-9, 17-13, 17-15, 17-20, 17-22, 17-23, 17-24, 17-25, 17-27, 
+ 17-33, 17-35, 19-30..19-31, 21-25, 21-53, 23-10
+READ-AND-WRITE-BYTES:NEW-FUNCTIONS  21-15, 21-16, 21-19, 21-23, 21-26..21-28
+READ-CASE-SENSITIVITY:READTABLE-KEYWORDS  23-4, 23-11..23-12
+READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES  5-11..5-12
+READ-SUPPRESS-CONFUSING:GENERALIZE  2-34, 23-21, 23-22
+READER-ERROR:NEW-TYPE  9-2, 9-14
+REAL-NUMBER-TYPE:X3J13-MAR-89  2-18, 4-5, 4-17..4-18, 4-31, 12-8, 12-11, 
+ 12-12, 12-12..12-13, 12-13, 12-14, 12-16, 12-17, 12-18, 12-19, 12-20, 12-29, 
+ 12-39, 12-46, 12-48, 12-57, 12-58, 12-59, 12-60..12-61, 12-62, 12-85
+RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE  3-71, 4-33
+REDUCE-ARGUMENT-EXTRACTION  8-7, 17-13, 17-13..17-14
+REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89  10-19, 14-29, 14-30, 14-32, 14-50, 
+ 14-51, 14-52, 14-53, 14-53..14-54, 14-59, 14-62, 17-17, 17-28, 17-33..17-34, 
+ 17-34, 17-36
+REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91  1-33, 1-34, A-1, 24-14..24-15, 
+ 24-15..24-16
+REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT  A-1, 24-15, 
+ 24-15..24-16
+REQUIRE-PATHNAME-DEFAULTS:ELIMINATE  A-1, 11-1
+REST-LIST-ALLOCATION:MAY-SHARE  5-14
+RESULT-LISTS-SHARED:SPECIFY  11-14, 20-3
+RETURN-VALUES-UNSPECIFIED:SPECIFY  3-101, 11-14, 21-39, 23-16, 25-23
+ROOM-DEFAULT-ARGUMENT:NEW-VALUE  25-21
+SELF-MODIFYING-CODE:FORBID  3-7
+SEQUENCE-TYPE-LENGTH:MUST-MATCH  4-32, 17-8, 17-9, 17-11, 17-30, 17-32
+SETF-APPLY-EXPANSION:IGNORE-EXPANDER  5-9..5-10
+SETF-FIND-CLASS:ALLOW-NIL  7-72
+SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES  5-4, 5-19, 8-4, 26-24
+SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED  10-18, 14-50, 18-10
+SETF-MACRO-EXPANSION:LAST  5-10
+SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS  3-22, 3-42, 3-83..3-84, 5-1, 
+ 5-2, 5-3, 5-4, 5-4..5-5, 5-7, 5-10, 5-21, 5-92, 5-93, 5-96, 5-96..5-98, 
+ 5-97, 5-97..5-98, 5-98..5-99, 25-20, 26-51
+SETF-MULTIPLE-STORE-VARIABLES:ALLOW  5-7, 5-8, 5-94, 5-96, 5-101, 5-103, 
+ 9-16
+SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS  5-9..5-10
+SETF-OF-VALUES:ADD  5-9, 5-84
+SETF-SUB-METHODS:DELAYED-ACCESS-STORES  5-6..5-9
+SHADOW-ALREADY-PRESENT  11-15..11-16
+SHADOW-ALREADY-PRESENT:WORKS  11-15
+SHARP-COMMA-CONFUSION:REMOVE  2-33
+SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED  2-33, 2-34
+SHARP-STAR-DELIMITER:NORMAL-DELIMITER  2-32
+SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD  2-37, 24-10..24-11, 24-11
+SLOT-MISSING-VALUES:SPECIFY  7-13, 7-40, 7-42, 7-43..7-44, 7-44, 7-46
+SLOT-VALUE-METACLASSES:LESS-MINIMAL  7-40..7-41, 7-41, 7-42, 7-46
+SPECIAL-FORM-P-MISNOMER:RENAME  3-74, 3-103..3-104, 5-17, 10-12
+SPECIAL-TYPE-SHADOWING:CLARIFY  3-91
+STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS  21-57, 21-59
+STANDARD-REPERTOIRE-GRATUITOUS:RENAME  13-9
+STEP-ENVIRONMENT:CURRENT  25-13..25-14, 25-14
+STEP-MINIMAL:PERMIT-PROGN  25-14
+STREAM-ACCESS:ADD-TYPES-ACCESSORS  4-3..4-4, 21-7..21-8, 21-8..21-9, 21-9, 
+ 21-10, 21-11, 21-12..21-13, 21-32, 21-37, 21-46, 21-46..21-47, 21-47, 21-48, 
+ 21-49, 21-50, 21-50..21-51, 21-51, 21-53, 21-54, 21-56
+STREAM-CAPABILITIES:INTERACTIVE-STREAM-P  21-12
+STRING-COERCION:MAKE-CONSISTENT  16-6, 16-7, 16-9, 16-10, 26-56
+STRING-OUTPUT-STREAM-BASHING:UNDEFINED  21-52, 21-57, 22-80
+STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS  1-34, 2-36, 22-12
+SUBSEQ-OUT-OF-BOUNDS  12-66, 16-7, 16-10, 17-7, 17-9, 17-13, 17-15, 17-20, 
+ 17-22, 17-23, 17-24, 17-25, 17-27, 17-33, 17-35, 19-30..19-31, 21-25, 23-10
+SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR  21-54
+SUBSETTING-POSITION:NONE  1-32
+SUBTYPEP-ENVIRONMENT:ADD-ARG  4-34..4-37, 4-39..4-41, 12-60, 15-29..15-30
+SUBTYPEP-TOO-VAGUE:CLARIFY-MORE  4-35
+SXHASH-DEFINITION:SIMILAR-FOR-SXHASH  18-15..18-16
+SYMBOL-MACROLET-DECLARE:ALLOW  3-79, 3-83..3-84, 3-90
+SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM  3-79, 3-79..3-80, 5-10, 5-39, 
+ 5-40..5-41, 5-83
+SYMBOL-MACROLET-TYPE-DECLARATION:NO  3-90
+SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR  3-80
+SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY  22-4
+SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91  3-17, 3-42, 3-50, 3-105, 4-20, 
+ 26-16
+TAGBODY-TAG-EXPANSION:NO  5-48
+TAILP-NIL:T  14-36, 14-37, 26-58
+TEST-NOT-IF-NOT:FLUSH-ALL  1-33, 14-15, 14-17, 14-18, 14-40, 14-45, 14-48, 
+ 14-53, 14-55, 14-58, 14-59, 14-60, 14-62, 17-16, 17-21, 17-22, 17-24, 17-25, 
+ 17-29, 17-35, 17-37
+THE-AMBIGUITY:FOR-DECLARATION  3-102
+THE-VALUES:RETURN-NUMBER-RECEIVED  3-102, 3-102..3-103
+TIME-ZONE-NON-INTEGER:ALLOW  25-5, 26-58..26-59
+TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL  3-91, 3-92
+TYPE-OF-AND-PREDEFINED-CLASSES:TYPE-OF-HANDLES-FLOATS  4-38
+TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND  4-2, 4-2..4-3, 4-23, 4-24, 
+ 4-25, 4-38, 4-42, 9-14, 9-25, 9-31, 19-15, 21-7, 21-7..21-8, 21-8..21-9, 
+ 21-9, 21-10, 21-11
+TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS  4-37..4-38, 4-38..4-39, 4-39
+TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS  4-26..4-27, 4-27, 4-28, 4-29, 
+ 4-30, 12-19
+UNDEFINED-FUNCTIONS-AND-VARIABLES:COMPROMISE  9-2
+UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE  7-44, 7-45, 7-90, 7-91
+UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED  15-11, 15-16
+UNITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED  8-3
+UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW  21-22
+UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS  1-31
+VARIABLE-LIST-ASYMMETRY:SYMMETRIZE  5-36, 6-31
+WITH-ADDED-METHODS:DELETE  3-6, 3-8, 3-30, 3-83..3-84, 3-94, 3-95, 4-23, 
+ 4-25, 7-12, 7-17, 7-18
+WITH-COMPILATION-UNIT:NEW-MACRO  24-8..24-9
+WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL  21-37, 21-38
+WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE  21-38, 21-40, 21-55, 21-56
+WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT  21-37, 21-40, 21-55, 21-56
+WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND  21-56
+WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91  26-31, 26-55
+
+====================[ CL Specification Page Index ]====================
+1-8          LOOP-MISCELLANEOUS-REPAIRS:FIX
+1-8..1-9     LOOP-MISCELLANEOUS-REPAIRS:FIX
+1-18         ERROR-TERMINOLOGY-WARNING:MIGHT
+1-22         DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT
+1-31         EXTENSIONS-POSITION:DOCUMENTATION, EXTRA-RETURN-VALUES:NO, 
+              MACRO-AS-FUNCTION:DISALLOW, 
+              UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
+1-32         SUBSETTING-POSITION:NONE
+1-33         EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS, 
+              EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993, 
+              GENSYM-NAME-STICKINESS:LIKE-TEFLON, 
+              GENTEMP-BAD-IDEA:DEPRECATE, 
+              REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+1-34         REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91, 
+              STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS
+2-2..2-4     CHARACTER-PROPOSAL:2-2-1
+2-14         COLON-NUMBER
+2-18         REAL-NUMBER-TYPE:X3J13-MAR-89
+2-20         CHARACTER-PROPOSAL:2-1-1
+2-26         CHARACTER-PROPOSAL:2-1-1
+2-31         CHARACTER-LOOSE-ENDS:FIX, CHARACTER-PROPOSAL:2-1-1
+2-32         SHARP-STAR-DELIMITER:NORMAL-DELIMITER
+2-33         PARSE-ERROR-STREAM:SPLIT-TYPES, SHARP-COMMA-CONFUSION:REMOVE, 
+              SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED
+2-34         READ-SUPPRESS-CONFUSING:GENERALIZE, 
+              SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED
+2-36         PATHNAME-PRINT-READ:SHARPSIGN-P, 
+              STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS
+2-37         SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD
+2-39         PARSE-ERROR-STREAM:SPLIT-TYPES
+2-40         PARSE-ERROR-STREAM:SPLIT-TYPES
+3-1          DEFINE-COMPILER-MACRO:X3J13-NOV89
+3-3          ISO-COMPATIBILITY:ADD-SUBSTRATE
+3-6          COMPILER-LET-CONFUSION:ELIMINATE, 
+              GENERIC-FLET-POORLY-DESIGNED:DELETE, 
+              LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM, 
+              WITH-ADDED-METHODS:DELETE
+3-7          SELF-MODIFYING-CODE:FORBID
+3-8          FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED, 
+              GENERIC-FLET-POORLY-DESIGNED:DELETE, 
+              WITH-ADDED-METHODS:DELETE
+3-9          EVAL-OTHER:SELF-EVALUATE
+3-15..3-17   DEFINE-COMPILER-MACRO:X3J13-NOV89
+3-17         SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91
+3-18         KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+3-20         DEFINE-COMPILER-MACRO:X3J13-NOV89
+3-22         CLOS-MACRO-COMPILATION:MINIMAL, 
+              COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DEFINE-COMPILER-MACRO:X3J13-NOV89, 
+              PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+3-23         MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS
+3-23..3-24   CONSTANT-COMPILABLE-TYPES:SPECIFY
+3-24         COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY
+3-26         CONSTANT-CIRCULAR-COMPILATION:YES, 
+              CONSTANT-COLLAPSING:GENERALIZE, 
+              CONSTANT-FUNCTION-COMPILATION:NO, LOAD-OBJECTS:MAKE-LOAD-FORM
+3-27         LOAD-OBJECTS:MAKE-LOAD-FORM, MAKE-LOAD-FORM-CONFUSION:REWRITE
+3-27..3-28   COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY
+3-28         COMPILER-DIAGNOSTICS:USE-HANDLER, COMPILER-WARNING-STREAM
+3-29..3-30   DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
+3-30         GENERIC-FLET-POORLY-DESIGNED:DELETE, WITH-ADDED-METHODS:DELETE
+3-30..3-32   DECLARATION-SCOPE:NO-HOISTING
+3-35         ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT
+3-35..3-36   PLIST-DUPLICATES:ALLOW
+3-36         ALLOW-OTHER-KEYS-NIL:PERMIT, KEYWORD-ARGUMENT-NAME-PACKAGE:ANY
+3-40         GENERIC-FLET-POORLY-DESIGNED:DELETE
+3-42         &ENVIRONMENT-BINDING-ORDER:FIRST, 
+              ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT, 
+              DEFINE-COMPILER-MACRO:X3J13-NOV89, 
+              DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION, 
+              GET-SETF-METHOD-ENVIRONMENT:ADD-ARG, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              MACRO-ENVIRONMENT-EXTENT:DYNAMIC, 
+              MACRO-FUNCTION-ENVIRONMENT:YES, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS, 
+              SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91
+3-43         DOTTED-MACRO-FORMS:ALLOW
+3-44         DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION
+3-46         BOA-AUX-INITIALIZATION:ERROR-ON-READ, 
+              DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
+3-46..3-47   DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
+3-48         DEFTYPE-DESTRUCTURING:YES, DEFTYPE-KEY:ALLOW
+3-50         ARGUMENT-MISMATCH-ERROR-MOON:FIX, 
+              GENERIC-FLET-POORLY-DESIGNED:DELETE, 
+              SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91
+3-50..3-52   ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS
+3-51         ARGUMENT-MISMATCH-ERROR-MOON:FIX
+3-52         ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT, 
+              ARGUMENT-MISMATCH-ERROR-MOON:FIX
+3-53         MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+3-54..3-55   DESTRUCTIVE-OPERATIONS:SPECIFY
+3-56         DECLS-AND-DOC
+3-56..3-57   ISO-COMPATIBILITY:ADD-SUBSTRATE
+3-57         COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN, FUNCTION-NAME:LARGE
+3-58         COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX, 
+              COMPILER-DIAGNOSTICS:USE-HANDLER, COMPILER-WARNING-STREAM, 
+              QUOTE-SEMANTICS:NO-COPYING
+3-59         EVALHOOK-STEP-CONFUSION:X3J13-NOV-89, 
+              QUOTE-SEMANTICS:NO-COPYING
+3-60         DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, 
+              EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS, 
+              EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993, 
+              EVALHOOK-STEP-CONFUSION:FIX
+3-62..3-63   EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS
+3-63..3-65   LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM
+3-66         CONSTANT-MODIFICATION:DISALLOW, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+3-66..3-67   DEFINE-COMPILER-MACRO:X3J13-NOV89
+3-67         KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+3-67..3-70   DECLS-AND-DOC
+3-68         DOCUMENTATION-FUNCTION-BUGS:FIX
+3-70..3-73   DECLS-AND-DOC
+3-71         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, 
+              DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS, 
+              DOCUMENTATION-FUNCTION-BUGS:FIX, FLET-IMPLICIT-BLOCK:YES, 
+              RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE
+3-72..3-73   DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION
+3-73         DEFINE-COMPILER-MACRO:X3J13-NOV89, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              MACRO-FUNCTION-ENVIRONMENT
+3-74         KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              MACRO-FUNCTION-ENVIRONMENT, SPECIAL-FORM-P-MISNOMER:RENAME
+3-75         FUNCTION-TYPE:X3J13-MARCH-88, MACROEXPAND-RETURN-VALUE:TRUE
+3-77..3-79   ISO-COMPATIBILITY:ADD-SUBSTRATE
+3-79         SYMBOL-MACROLET-DECLARE:ALLOW, 
+              SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
+3-79..3-80   DECLS-AND-DOC, SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
+3-80         LISP-SYMBOL-REDEFINITION:MAR89-X3J13, 
+              MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE, 
+              MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT, 
+              SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR
+3-80..3-81   FUNCTION-TYPE:X3J13-MARCH-88
+3-81         MACRO-ENVIRONMENT-EXTENT:DYNAMIC, 
+              MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT
+3-82         DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION, 
+              DYNAMIC-EXTENT:NEW-DECLARATION
+3-82..3-83   DECLARE-MACROS:FLUSH
+3-83         PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO
+3-83..3-84   DECLS-AND-DOC, GENERIC-FLET-POORLY-DESIGNED:DELETE, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS, 
+              SYMBOL-MACROLET-DECLARE:ALLOW, WITH-ADDED-METHODS:DELETE
+3-84         DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION, 
+              DECLARE-MACROS:FLUSH, DYNAMIC-EXTENT:NEW-DECLARATION
+3-85..3-86   DOTIMES-IGNORE:X3J13-MAR91, IGNORE-USE-TERMINOLOGY:VALUE-ONLY
+3-86         DYNAMIC-EXTENT-FUNCTION:EXTEND, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+3-86..3-89   DYNAMIC-EXTENT:NEW-DECLARATION
+3-87         MACRO-DECLARATIONS:MAKE-EXPLICIT
+3-90         SYMBOL-MACROLET-DECLARE:ALLOW, 
+              SYMBOL-MACROLET-TYPE-DECLARATION:NO
+3-90..3-91   DECLARE-TYPE-FREE:LEXICAL
+3-91         DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE, 
+              SPECIAL-TYPE-SHADOWING:CLARIFY, 
+              TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL
+3-91..3-92   DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE
+3-92         TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL
+3-93         FUNCTION-NAME:LARGE
+3-93..3-94   ALLOW-LOCAL-INLINE:INLINE-NOTINLINE
+3-94         FUNCTION-NAME:LARGE, GENERIC-FLET-POORLY-DESIGNED:DELETE, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              MACRO-DECLARATIONS:MAKE-EXPLICIT, WITH-ADDED-METHODS:DELETE
+3-95         DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION, 
+              FUNCTION-NAME:LARGE, GENERIC-FLET-POORLY-DESIGNED:DELETE, 
+              MACRO-DECLARATIONS:MAKE-EXPLICIT, WITH-ADDED-METHODS:DELETE
+3-97         OPTIMIZE-DEBUG-INFO:NEW-QUALITY
+3-100        LOCALLY-TOP-LEVEL:SPECIAL-FORM
+3-100..3-102 DECLS-AND-DOC
+3-101        LOCALLY-TOP-LEVEL:SPECIAL-FORM, 
+              RETURN-VALUES-UNSPECIFIED:SPECIFY
+3-102        JUN90-TRIVIAL-ISSUES:27, LOCALLY-TOP-LEVEL:SPECIAL-FORM, 
+              THE-AMBIGUITY:FOR-DECLARATION, 
+              THE-VALUES:RETURN-NUMBER-RECEIVED
+3-102..3-103 THE-VALUES:RETURN-NUMBER-RECEIVED
+3-103..3-104 SPECIAL-FORM-P-MISNOMER:RENAME
+3-104..3-105 CONSTANTP-DEFINITION:INTENTIONAL, 
+              CONSTANTP-ENVIRONMENT:ADD-ARG
+3-105        SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91
+4-2          CLOS-CONDITIONS:INTEGRATE, COMMON-TYPE:REMOVE, 
+              DATA-TYPES-HIERARCHY-UNDERSPECIFIED, 
+              FUNCTION-TYPE:X3J13-MARCH-88, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+4-2..4-3     TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+4-3          ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+4-3..4-4     CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT, 
+              STREAM-ACCESS:ADD-TYPES-ACCESSORS
+4-5          REAL-NUMBER-TYPE:X3J13-MAR-89
+4-17         CONDITION-SLOTS:HIDDEN, METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED
+4-17..4-18   REAL-NUMBER-TYPE:X3J13-MAR-89
+4-20         FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD, 
+              FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE, 
+              KEYWORD-ARGUMENT-NAME-PACKAGE:ANY, 
+              SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91
+4-20..4-21   FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD, 
+              FUNCTION-TYPE:X3J13-MARCH-88
+4-21         FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
+4-22         COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN, 
+              FUNCTION-TYPE:X3J13-MARCH-88, JUN90-TRIVIAL-ISSUES:9
+4-23         GENERIC-FLET-POORLY-DESIGNED:DELETE, JUN90-TRIVIAL-ISSUES:9, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND, 
+              WITH-ADDED-METHODS:DELETE
+4-24         JUN90-TRIVIAL-ISSUES:9, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+4-25         DATA-TYPES-HIERARCHY-UNDERSPECIFIED, 
+              GENERIC-FLET-POORLY-DESIGNED:DELETE, JUN90-TRIVIAL-ISSUES:9, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND, 
+              WITH-ADDED-METHODS:DELETE
+4-26         COMMON-TYPE:REMOVE
+4-26..4-27   TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS
+4-27         TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS
+4-28         TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS
+4-29         TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS
+4-30         TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS
+4-31         CHARACTER-LOOSE-ENDS:FIX, 
+              COERCING-SETF-NAME-TO-FUNCTION:ALL-FUNCTION-NAMES, 
+              CONCATENATE-SEQUENCE:SIGNAL-ERROR, 
+              FUNCTION-TYPE:X3J13-MARCH-88, REAL-NUMBER-TYPE:X3J13-MAR-89
+4-32         SEQUENCE-TYPE-LENGTH:MUST-MATCH
+4-33         DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, 
+              DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS, 
+              FLET-IMPLICIT-BLOCK:YES, RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE
+4-33..4-34   COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DECLS-AND-DOC
+4-34..4-37   SUBTYPEP-ENVIRONMENT:ADD-ARG
+4-35         SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
+4-35..4-36   ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+4-36..4-37   ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+4-37         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+4-37..4-38   TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
+4-38         TYPE-OF-AND-PREDEFINED-CLASSES:TYPE-OF-HANDLES-FLOATS, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+4-38..4-39   TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
+4-39         FUNCTION-TYPE, TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
+4-39..4-40   ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+4-39..4-41   SUBTYPEP-ENVIRONMENT:ADD-ARG
+4-40         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+4-42         FORMAT-STRING-ARGUMENTS:SPECIFY, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+5-1          SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-1..5-3     PUSH-EVALUATION-ORDER:ITEM-FIRST
+5-2          JUN90-TRIVIAL-ISSUES:4, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-3          SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-4          SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-4..5-5     SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-5..5-6     AREF-1D, CONDITION-ACCESSORS-SETFABLE:NO, FUNCTION-NAME:LARGE, 
+              PATHNAME-LOGICAL:ADD
+5-6          FUNCTION-NAME:LARGE
+5-6..5-9     SETF-SUB-METHODS:DELAYED-ACCESS-STORES
+5-7          CHARACTER-PROPOSAL:2-1-1, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS, 
+              SETF-MULTIPLE-STORE-VARIABLES:ALLOW
+5-8          SETF-MULTIPLE-STORE-VARIABLES:ALLOW
+5-9          SETF-OF-VALUES:ADD
+5-9..5-10    JUN90-TRIVIAL-ISSUES:27, SETF-APPLY-EXPANSION:IGNORE-EXPANDER, 
+              SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS
+5-10         FUNCTION-NAME:LARGE, SETF-MACRO-EXPANSION:LAST, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS, 
+              SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
+5-10..5-11   FUNCTION-NAME:LARGE
+5-11..5-12   READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES
+5-13         EXIT-EXTENT:MINIMAL
+5-14         FUNCTION-TYPE:X3J13-MARCH-88, REST-LIST-ALLOCATION:MAY-SHARE
+5-15         DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS, 
+              DOCUMENTATION-FUNCTION-BUGS:FIX
+5-15..5-17   DECLS-AND-DOC, FUNCTION-NAME:LARGE
+5-16         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
+5-17         FUNCTION-NAME:LARGE, FUNCTION-TYPE:X3J13-MARCH-88, 
+              SPECIAL-FORM-P-MISNOMER:RENAME
+5-18         FUNCTION-NAME:LARGE
+5-19         FUNCTION-NAME:LARGE, SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES
+5-20         DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS, 
+              FLET-DECLARATIONS:ALLOW, FLET-IMPLICIT-BLOCK:YES, 
+              FUNCTION-NAME:LARGE
+5-20..5-21   FLET-DECLARATIONS
+5-20..5-24   DECLS-AND-DOC
+5-21         DECLARATION-SCOPE:NO-HOISTING, 
+              DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, 
+              GET-SETF-METHOD-ENVIRONMENT:ADD-ARG, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-22         LISP-SYMBOL-REDEFINITION:MAR89-X3J13
+5-23         FLET-DECLARATIONS
+5-24         FUNCTION-TYPE:X3J13-MARCH-88
+5-25         FUNCTION-TYPE:X3J13-MARCH-88
+5-25..5-26   FUNCTION-NAME:LARGE
+5-26..5-27   FUNCTION-DEFINITION:JAN89-X3J13
+5-28         FUNCTION-TYPE:X3J13-MARCH-88
+5-31         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DEFCONSTANT-SPECIAL:NO, DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, 
+              DEFVAR-DOCUMENTATION:UNEVALUATED
+5-32         DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, 
+              DEFVAR-DOCUMENTATION:UNEVALUATED, 
+              DEFVAR-INIT-TIME:NOT-DELAYED, 
+              DEFVAR-INITIALIZATION:CONSERVATIVE
+5-34         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
+5-35..5-36   DECLS-AND-DOC, DESTRUCTURING-BIND:NEW-MACRO
+5-36         VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
+5-36..5-37   KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+5-36..5-38   DECLS-AND-DOC
+5-37         KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+5-39         SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
+5-40..5-41   SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
+5-45         EXIT-EXTENT:MINIMAL
+5-45..5-47   EXIT-EXTENT:MINIMAL
+5-48         TAGBODY-TAG-EXPANSION:NO
+5-50         EXIT-EXTENT:MINIMAL
+5-51         EXIT-EXTENT-AND-CONDITION-SYSTEM:LIKE-DYNAMIC-BINDINGS
+5-52..5-54   EXIT-EXTENT:MINIMAL
+5-55         NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93
+5-60         EQUAL-STRUCTURE:MAYBE-STATUS-QUO
+5-60..5-61   EQUAL-STRUCTURE:MAYBE-STATUS-QUO
+5-61..5-62   EQUAL-STRUCTURE:MAYBE-STATUS-QUO
+5-62..5-63   EQUAL-STRUCTURE:MAYBE-STATUS-QUO
+5-63         EQUAL-STRUCTURE:MAYBE-STATUS-QUO
+5-64         EQUAL-STRUCTURE:MAYBE-STATUS-QUO
+5-65..5-66   FUNCTION-COMPOSITION:JAN89-X3J13
+5-66         FUNCTION-COMPOSITION:JAN89-X3J13
+5-68         MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+5-79..5-80   DECLS-AND-DOC
+5-83         MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES, 
+              SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
+5-84         SETF-OF-VALUES:ADD
+5-86         MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED
+5-86..5-87   NTH-VALUE:ADD
+5-87..5-89   DECLS-AND-DOC
+5-92         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DOCUMENTATION-FUNCTION-BUGS:FIX, 
+              GET-SETF-METHOD-ENVIRONMENT:ADD-ARG, 
+              PUSH-EVALUATION-ORDER:FIRST-ITEM, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-93         SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-93..5-96   DECLS-AND-DOC
+5-94         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, FLET-IMPLICIT-BLOCK:YES, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              SETF-MULTIPLE-STORE-VARIABLES:ALLOW
+5-96         SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS, 
+              SETF-MULTIPLE-STORE-VARIABLES:ALLOW
+5-96..5-97   DOCUMENTATION-FUNCTION-BUGS:FIX
+5-96..5-98   DECLS-AND-DOC, SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-97         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DEFINING-MACROS-NON-TOP-LEVEL:ALLOW, 
+              DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS, 
+              FLET-IMPLICIT-BLOCK:YES, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-97..5-98   SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-98         GET-SETF-METHOD-ENVIRONMENT:ADD-ARG
+5-98..5-99   SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+5-99         GET-SETF-METHOD-ENVIRONMENT:ADD-ARG, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+5-100        KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92
+5-101        PUSH-EVALUATION-ORDER:FIRST-ITEM, 
+              SETF-MULTIPLE-STORE-VARIABLES:ALLOW
+5-103        PUSH-EVALUATION-ORDER:FIRST-ITEM, 
+              SETF-MULTIPLE-STORE-VARIABLES:ALLOW
+6-1          JUN90-TRIVIAL-ISSUES:11
+6-2          LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE, 
+              LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-3          LOOP-NAMED-BLOCK-NIL:OVERRIDE
+6-4          LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-5          LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-7          LOOP-AND-DISCREPANCY:NO-REITERATION
+6-8          MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+6-9          LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-11..6-12   LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-12         LOOP-FOR-AS-ON-TYPO:FIX-TYPO
+6-14         LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS
+6-15         LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS
+6-16         LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-21         LOOP-NAMED-BLOCK-NIL:OVERRIDE
+6-22         LOOP-NAMED-BLOCK-NIL:OVERRIDE
+6-24         LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-25         LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-27         LOOP-MISCELLANEOUS-REPAIRS:FIX, LOOP-NAMED-BLOCK-NIL:OVERRIDE
+6-30         LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-31         VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
+6-31..6-35   DECLS-AND-DOC
+6-35..6-36   DECLS-AND-DOC
+6-37..6-38   DECLS-AND-DOC
+6-38         MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+6-38..6-40   LOOP-SYNTAX-OVERHAUL:REPAIR
+6-40         LOOP-MISCELLANEOUS-REPAIRS:FIX
+6-43         LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED
+7-2          INITIALIZATION-FUNCTION-KEYWORD-CHECKING, 
+              PLIST-DUPLICATES:ALLOW
+7-3          INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-9          CHANGE-CLASS-INITARGS:PERMIT
+7-12         GENERIC-FLET-POORLY-DESIGNED:DELETE, WITH-ADDED-METHODS:DELETE
+7-13         SLOT-MISSING-VALUES:SPECIFY
+7-17         GENERIC-FLET-POORLY-DESIGNED:DELETE, WITH-ADDED-METHODS:DELETE
+7-18         GENERIC-FLET-POORLY-DESIGNED:DELETE, WITH-ADDED-METHODS:DELETE
+7-19         CLASS-OBJECT-SPECIALIZER:AFFIRM
+7-22         CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST
+7-29         FUNCTION-NAME:LARGE
+7-30         FUNCTION-NAME:LARGE, INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-30..7-31   ALLOCATE-INSTANCE:ADD
+7-31         INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-32         INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-34         INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-35         INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-38         CHANGE-CLASS-INITARGS:PERMIT
+7-39         CHANGE-CLASS-INITARGS:PERMIT
+7-40         SLOT-MISSING-VALUES:SPECIFY
+7-40..7-41   SLOT-VALUE-METACLASSES:LESS-MINIMAL
+7-41         SLOT-VALUE-METACLASSES:LESS-MINIMAL
+7-42         SLOT-MISSING-VALUES:SPECIFY, 
+              SLOT-VALUE-METACLASSES:LESS-MINIMAL
+7-43..7-44   SLOT-MISSING-VALUES:SPECIFY
+7-44         SLOT-MISSING-VALUES:SPECIFY, 
+              UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE
+7-45         UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE
+7-46         SLOT-MISSING-VALUES:SPECIFY, 
+              SLOT-VALUE-METACLASSES:LESS-MINIMAL
+7-49         GENERIC-FLET-POORLY-DESIGNED:DELETE, 
+              INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-51..7-55   LOAD-OBJECTS:MAKE-LOAD-FORM, MAKE-LOAD-FORM-CONFUSION:REWRITE
+7-55..7-56   LOAD-OBJECTS:MAKE-LOAD-FORM, MAKE-LOAD-FORM-CONFUSION:REWRITE, 
+              MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS
+7-56         MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS
+7-56..7-58   DECLS-AND-DOC
+7-58..7-60   DECLS-AND-DOC
+7-64         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DOCUMENTATION-FUNCTION-BUGS:FIX
+7-65..7-68   DECLS-AND-DOC
+7-66         DEFGENERIC-DECLARE:ALLOW-MULTIPLE, FUNCTION-NAME:LARGE
+7-67         DEFGENERIC-DECLARE:ALLOW-MULTIPLE
+7-68         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              GENERIC-FUNCTION-POORLY-DESIGNED:DELETE
+7-69..7-71   DECLS-AND-DOC
+7-70..7-71   DEFMETHOD-DECLARATION-SCOPE:CORRESPONDS-TO-BINDINGS
+7-71         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, 
+              DOCUMENTATION-FUNCTION-BUGS:FIX
+7-72         MACRO-ENVIRONMENT-EXTENT:DYNAMIC, SETF-FIND-CLASS:ALLOW-NIL
+7-73         LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED, 
+              METHOD-INITFORM:FORBID-CALL-NEXT-METHOD
+7-74         METHOD-INITFORM:FORBID-CALL-NEXT-METHOD
+7-75         LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED
+7-76         COMPUTE-APPLICABLE-METHODS:GENERIC
+7-76..7-85   DECLS-AND-DOC
+7-81         DOCUMENTATION-FUNCTION-BUGS:FIX, 
+              METHOD-COMBINATION-ARGUMENTS:CLARIFY
+7-82         DEFINE-METHOD-COMBINATION:CLARIFY
+7-85         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
+7-88         INITIALIZATION-FUNCTION-KEYWORD-CHECKING
+7-90         UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE
+7-91         UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE
+8-1          DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93
+8-2          DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED, 
+              DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93
+8-2..8-3     DOCUMENTATION-FUNCTION-BUGS:FIX
+8-3          DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND, 
+              DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED, 
+              UNITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED
+8-3..8-4     DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
+8-4          SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES
+8-6          DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT, 
+              DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT, 
+              DEFSTRUCT-COPIER:ARGUMENT-TYPE
+8-7          REDUCE-ARGUMENT-EXTRACTION
+8-11..8-12   DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93
+8-12         DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93, 
+              DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES, 
+              PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
+8-13         DEFSTRUCT-REDEFINITION:ERROR
+8-14         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
+8-17         DATA-TYPES-HIERARCHY-UNDERSPECIFIED, 
+              DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
+8-18         DEFSTRUCT-COPIER:ARGUMENT-TYPE
+9-2          ACCESS-ERROR-NAME, COMPILER-DIAGNOSTICS:USE-HANDLER, 
+              DATA-IO:ADD-SUPPORT, 
+              FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89, 
+              PARSE-ERROR-STREAM:SPLIT-TYPES, READER-ERROR:NEW-TYPE, 
+              UNDEFINED-FUNCTIONS-AND-VARIABLES:COMPROMISE
+9-3          DATA-IO:ADD-SUPPORT, FORMAT-STRING-ARGUMENTS:SPECIFY
+9-3..9-4     FORMAT-STRING-ARGUMENTS:SPECIFY
+9-4          FORMAT-STRING-ARGUMENTS:SPECIFY
+9-8          CONDITION-RESTARTS:PERMIT-ASSOCIATION, JUN90-TRIVIAL-ISSUES:14
+9-9          CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-10         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-11         CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET, CLOS-CONDITIONS:INTEGRATE, 
+              CONDITION-RESTARTS:BUGGY, CONDITION-SLOTS:HIDDEN
+9-12         COMPILER-DIAGNOSTICS:USE-HANDLER
+9-14         ACCESS-ERROR-NAME, PARSE-ERROR-STREAM:SPLIT-TYPES, 
+              READER-ERROR:NEW-TYPE, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+9-15         ASSERT-ERROR-TYPE:ERROR, FORMAT-STRING-ARGUMENTS:SPECIFY
+9-16         PUSH-EVALUATION-ORDER:FIRST-ITEM, 
+              SETF-MULTIPLE-STORE-VARIABLES:ALLOW
+9-19         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-25         FORMAT-STRING-ARGUMENTS:SPECIFY, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+9-26         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-28         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-29         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-30         BREAK-ON-WARNINGS-OBSOLETE:REMOVE
+9-31         FORMAT-STRING-ARGUMENTS:SPECIFY, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+9-33         DEBUGGER-HOOK-VS-BREAK:CLARIFY, 
+              FORMAT-STRING-ARGUMENTS:SPECIFY
+9-34         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-36         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-37         BREAK-ON-WARNINGS-OBSOLETE:REMOVE
+9-38..9-41   DECLS-AND-DOC
+9-42..9-47    DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY
+9-43..9-44   CLOS-CONDITIONS:INTEGRATE
+9-44         CLOS-CONDITIONS:INTEGRATE
+9-44..9-45   CLOS-CONDITIONS:INTEGRATE
+9-46         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
+9-48         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-49         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-50         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-51         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-55         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-56         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-56..9-61   DECLS-AND-DOC
+9-58         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-61         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-62..9-63   CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-63         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-65         FORMAT-STRING-ARGUMENTS:SPECIFY
+9-68         CONDITION-RESTARTS:PERMIT-ASSOCIATION
+9-69         CONDITION-RESTARTS:PERMIT-ASSOCIATION, 
+              MUFFLE-WARNING-CONDITION-ARGUMENT
+A-1          BREAK-ON-WARNINGS-OBSOLETE:REMOVE, CHARACTER-PROPOSAL:2-1-1, 
+              COMMON-TYPE:REMOVE, COMPILER-LET-CONFUSION:ELIMINATE, 
+              DEPRECATION-POSITION:LIMITED, 
+              REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91, 
+              REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT, 
+              REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
+10-2         CHARACTER-PROPOSAL:2-6-2, CHARACTER-PROPOSAL:2-6-3, 
+              LISP-SYMBOL-REDEFINITION:MAR89-X3J13
+10-7         COPY-SYMBOL-COPY-PLIST:COPY-LIST, COPY-SYMBOL-PRINT-NAME:EQUAL
+10-8         GENSYM-NAME-STICKINESS:LIKE-TEFLON
+10-9..10-10  GENSYM-NAME-STICKINESS:LIKE-TEFLON
+10-11        FUNCTION-TYPE:X3J13-MARCH-88
+10-12        SPECIAL-FORM-P-MISNOMER:RENAME
+10-13        LISP-SYMBOL-REDEFINITION:MAR89-X3J13
+10-17        PLIST-DUPLICATES:ALLOW
+10-18        PLIST-DUPLICATES:ALLOW, SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED
+10-19        PLIST-DUPLICATES:ALLOW, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+10-22        ARGUMENTS-UNDERSPECIFIED:SPECIFY
+11-1         REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
+11-4         LISP-PACKAGE-NAME:COMMON-LISP, PACKAGE-CLUTTER:REDUCE
+11-4..11-5   PACKAGE-CLUTTER:REDUCE
+11-4..11-6   LISP-PACKAGE-NAME:COMMON-LISP
+11-5         DEFINE-COMPILER-MACRO:X3J13-NOV89, 
+              LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES, 
+              PACKAGE-CLUTTER:REDUCE
+11-5..11-6   LISP-SYMBOL-REDEFINITION:MAR89-X3J13
+11-6         LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES, 
+              PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO
+11-7         PACKAGE-CLUTTER:REDUCE
+11-8         PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-9         PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-11        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-12        PACKAGE-DELETION:NEW-FUNCTION, 
+              PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-13        IMPORT-SETF-SYMBOL-PACKAGE
+11-14        PACKAGE-DELETION:NEW-FUNCTION, 
+              PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE, 
+              RESULT-LISTS-SHARED:SPECIFY, 
+              RETURN-VALUES-UNSPECIFIED:SPECIFY
+11-15        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE, 
+              SHADOW-ALREADY-PRESENT:WORKS
+11-15..11-16 SHADOW-ALREADY-PRESENT
+11-16        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-17        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-17..11-20 PACKAGE-DELETION:NEW-FUNCTION
+11-20        MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT, 
+              PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-21..11-24 DECLS-AND-DOC, HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
+11-24        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-25        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-26        IN-PACKAGE-FUNCTIONALITY:MAR89-X3J13
+11-27        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-28        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-29        DOCUMENTATION-FUNCTION-BUGS:FIX, 
+              PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-29..11-30 DOCUMENTATION-FUNCTION-BUGS:FIX
+11-29..11-33 DEFPACKAGE:ADDITION
+11-30        MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
+11-31        COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
+11-33        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-33..11-35 DECLS-AND-DOC
+11-34        DO-SYMBOLS-BLOCK-SCOPE:ENTIRE-FORM, DO-SYMBOLS-DUPLICATES
+11-35        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-36        PACKAGE-DELETION:NEW-FUNCTION, 
+              PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-36..11-37 PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-37        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-38        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+11-39        PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE
+12-5         COMPLEX-RATIONAL-RESULT:EXTEND
+12-6..12-7   CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
+12-8         REAL-NUMBER-TYPE:X3J13-MAR-89
+12-11        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-12        ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING, 
+              REAL-NUMBER-TYPE:X3J13-MAR-89
+12-12..12-13 REAL-NUMBER-TYPE:X3J13-MAR-89
+12-13        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-14        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-16        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-17        FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION, 
+              REAL-NUMBER-TYPE:X3J13-MAR-89
+12-18        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-19        REAL-NUMBER-TYPE:X3J13-MAR-89, 
+              TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS
+12-20        FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION, 
+              REAL-NUMBER-TYPE:X3J13-MAR-89
+12-29        COMPLEX-ATAN-BRANCH-CUT:TWEAK, 
+              COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE, 
+              REAL-NUMBER-TYPE:X3J13-MAR-89
+12-30        COMPLEX-ATAN-BRANCH-CUT:TWEAK, 
+              COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE
+12-31        COMPLEX-ATAN-BRANCH-CUT:TWEAK, IEEE-ATAN-BRANCH-CUT:SPLIT
+12-33        COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE
+12-34        COMPLEX-ATANH-BOGUS-FORMULA:TWEAK-MORE
+12-39        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-39..12-40 COMPLEX-RATIONAL-RESULT:EXTEND
+12-41        COMPLEX-RATIONAL-RESULT:EXTEND
+12-42        COMPLEX-RATIONAL-RESULT:EXTEND, EXPT-RATIO:P.211
+12-44        LCM-NO-ARGUMENTS:1, PUSH-EVALUATION-ORDER:FIRST-ITEM
+12-46        COMPLEX-RATIONAL-RESULT:EXTEND, IEEE-ATAN-BRANCH-CUT:SPLIT, 
+              REAL-NUMBER-TYPE:X3J13-MAR-89
+12-48        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-49        IEEE-ATAN-BRANCH-CUT:SPLIT
+12-56        ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+12-57        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-58        IEEE-ATAN-BRANCH-CUT:SPLIT, REAL-NUMBER-TYPE:X3J13-MAR-89
+12-59        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-60        ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING, 
+              SUBTYPEP-ENVIRONMENT:ADD-ARG
+12-60..12-61 REAL-NUMBER-TYPE:X3J13-MAR-89
+12-62        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-66        RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+12-73        ARGUMENTS-UNDERSPECIFIED:SPECIFY
+12-79        PUSH-EVALUATION-ORDER:FIRST-ITEM
+12-82        FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
+12-85        REAL-NUMBER-TYPE:X3J13-MAR-89
+12-87..12-88 FLOAT-UNDERFLOW:ADD-VARIABLES
+12-90        FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89
+12-91        FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89
+13-1         CHARACTER-PROPOSAL:2-6-1
+13-2         CHARACTER-PROPOSAL:2-1-1, CHARACTER-PROPOSAL:2-4-1, 
+              CHARACTER-PROPOSAL:2-4-3, 
+              LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92
+13-3         CHARACTER-PROPOSAL:2-1-1
+13-5         CHARACTER-PROPOSAL:2-1-1, 
+              LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92
+13-7         CHARACTER-PROPOSAL:2-1-1, CHARACTER-PROPOSAL:2-4-2
+13-8         CHARACTER-PROPOSAL:2-3-1, 
+              CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT
+13-8..13-9   CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT
+13-9         CHARACTER-PROPOSAL:2-1-1, CHARACTER-PROPOSAL:2-3-1, 
+              CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT, 
+              STANDARD-REPERTOIRE-GRATUITOUS:RENAME
+13-10        CHARACTER-PROPOSAL:2-1-1
+13-11        CHARACTER-PROPOSAL:2-1-1
+13-11..13-12 CHARACTER-PROPOSAL:2-1-1
+13-12        CHARACTER-PROPOSAL:2-1-1
+13-16        CHARACTER-PROPOSAL:2-1-1
+13-19        CHARACTER-PROPOSAL:2-1-1
+13-22        CHARACTER-PROPOSAL:2-1-2
+13-22..13-23 CHARACTER-PROPOSAL:2-1-1
+13-24        CHAR-NAME-CASE:X3J13-MAR-91
+14-1         DOTTED-LIST-ARGUMENTS:CLARIFY
+14-5         CONS-TYPE-SPECIFIER:ADD
+14-11        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-12..14-13 DOTTED-LIST-ARGUMENTS:CLARIFY
+14-13        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-15        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-16        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-17        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-18        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-18..14-19 DOTTED-LIST-ARGUMENTS:CLARIFY
+14-23        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-24        DOTTED-LIST-ARGUMENTS:CLARIFY, 
+              PUSH-EVALUATION-ORDER:FIRST-ITEM
+14-24..14-25 PUSH-EVALUATION-ORDER:FIRST-ITEM
+14-25        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-27        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-28        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-28..14-29 NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93
+14-29        DOTTED-LIST-ARGUMENTS:CLARIFY, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+14-30        DOTTED-LIST-ARGUMENTS:CLARIFY, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+14-31..14-33 DOTTED-LIST-ARGUMENTS:CLARIFY
+14-32        REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+14-33        BUTLAST-NEGATIVE:SHOULD-SIGNAL, DOTTED-LIST-ARGUMENTS:CLARIFY
+14-34        BUTLAST-NEGATIVE:SHOULD-SIGNAL, DOTTED-LIST-ARGUMENTS:CLARIFY, 
+              LAST-N
+14-34..14-35 LAST-N
+14-35        DOTTED-LIST-ARGUMENTS:CLARIFY, LAST-N
+14-36        TAILP-NIL:T
+14-36..14-37 DOTTED-LIST-ARGUMENTS:CLARIFY
+14-37        ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              DOTTED-LIST-ARGUMENTS:CLARIFY, TAILP-NIL:T
+14-38        DOTTED-LIST-ARGUMENTS:CLARIFY
+14-40        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-41        DOTTED-LIST-ARGUMENTS:CLARIFY, FUNCTION-TYPE:X3J13-MARCH-88
+14-42        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+14-43..14-44 ASSOC-RASSOC-IF-KEY:YES
+14-44        ASSOC-RASSOC-IF-KEY
+14-44..14-45 ASSOC-RASSOC-IF-KEY
+14-45        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-47        ASSOC-RASSOC-IF-KEY:YES
+14-48        ASSOC-RASSOC-IF-KEY, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-48..14-49 PLIST-DUPLICATES:ALLOW
+14-50        PLIST-DUPLICATES:ALLOW, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, 
+              SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED
+14-51        PLIST-DUPLICATES:ALLOW, PUSH-EVALUATION-ORDER:FIRST-ITEM, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+14-52        NINTERSECTION-DESTRUCTION:REVERT, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+14-53        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              NINTERSECTION-DESTRUCTION, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-53..14-54 REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+14-54        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+14-55        PUSH-EVALUATION-ORDER:FIRST-ITEM, TEST-NOT-IF-NOT:FLUSH-ALL
+14-55..14-56 PUSHNEW-STORE-REQUIRED:UNSPECIFIED
+14-56        PUSH-EVALUATION-ORDER:FIRST-ITEM
+14-58        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-59        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-60        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+14-62        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+15-1         ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM
+15-3         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING, 
+              CHARACTER-PROPOSAL:2-3-2
+15-5         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM, 
+              ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+15-6         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM
+15-7         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM, 
+              ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+15-8         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM, 
+              ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+15-9         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM
+15-10        ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM
+15-11        UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED
+15-12        ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY
+15-14        ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY
+15-15        ADJUST-ARRAY-FILL-POINTER, 
+              ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM
+15-15..15-16 ADJUST-ARRAY-DISPLACEMENT
+15-16        ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY, 
+              UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED
+15-18        ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY, 
+              ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM
+15-19        CONSTANT-MODIFICATION:DISALLOW
+15-21        ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
+15-22..15-23 DISPLACED-ARRAY-PREDICATE:ADD
+15-28        ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM
+15-28..15-29 AREF-1D
+15-29        CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT
+15-29..15-30 ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING, 
+              SUBTYPEP-ENVIRONMENT:ADD-ARG
+15-30        ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM, 
+              FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
+15-31        ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM
+15-32        CONSTANT-MODIFICATION:DISALLOW
+15-37        CONSTANT-MODIFICATION:DISALLOW
+16-1         CHARACTER-PROPOSAL:2
+16-2         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM, 
+              CHARACTER-PROPOSAL:2-3-2, CHARACTER-PROPOSAL:2-3-3, 
+              CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT
+16-2..16-3   CHARACTER-PROPOSAL:2-3-3, JUN90-TRIVIAL-ISSUES:24
+16-3         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM, 
+              CHARACTER-PROPOSAL:2-3-4
+16-3..16-4   CHARACTER-PROPOSAL:2-3-5
+16-4         ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM, 
+              CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT, 
+              JUN90-TRIVIAL-ISSUES:24
+16-6         CHARACTER-PROPOSAL:2-1-1, CONSTANT-MODIFICATION:DISALLOW, 
+              STRING-COERCION:MAKE-CONSISTENT
+16-7         RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              STRING-COERCION:MAKE-CONSISTENT, SUBSEQ-OUT-OF-BOUNDS
+16-9         STRING-COERCION:MAKE-CONSISTENT
+16-10        RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              STRING-COERCION:MAKE-CONSISTENT, SUBSEQ-OUT-OF-BOUNDS
+16-13        ARGUMENTS-UNDERSPECIFIED:SPECIFY, CHARACTER-PROPOSAL:2-3-6
+17-6         CONSTANT-MODIFICATION:DISALLOW
+17-7         RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+17-8         ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              CONCATENATE-SEQUENCE:SIGNAL-ERROR, 
+              SEQUENCE-TYPE-LENGTH:MUST-MATCH
+17-8..17-9   CONCATENATE-SEQUENCE:SIGNAL-ERROR
+17-9         CHARACTER-PROPOSAL:2-6-5, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SEQUENCE-TYPE-LENGTH:MUST-MATCH, SUBSEQ-OUT-OF-BOUNDS
+17-10        CONCATENATE-SEQUENCE:SIGNAL-ERROR, 
+              FUNCTION-TYPE:X3J13-MARCH-88
+17-11        CONCATENATE-SEQUENCE:SIGNAL-ERROR, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              SEQUENCE-TYPE-LENGTH:MUST-MATCH
+17-12..17-13 MAP-INTO:ADD-FUNCTION
+17-13        RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              REDUCE-ARGUMENT-EXTRACTION, SUBSEQ-OUT-OF-BOUNDS
+17-13..17-14 REDUCE-ARGUMENT-EXTRACTION
+17-14        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+17-15        RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+17-16        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+17-17        REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+17-20        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+17-21        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              TEST-NOT-IF-NOT:FLUSH-ALL
+17-22        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS, TEST-NOT-IF-NOT:FLUSH-ALL
+17-23        RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+17-24        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS, TEST-NOT-IF-NOT:FLUSH-ALL
+17-25        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS, TEST-NOT-IF-NOT:FLUSH-ALL
+17-27        RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+17-28        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+17-29        CONCATENATE-SEQUENCE:SIGNAL-ERROR, TEST-NOT-IF-NOT:FLUSH-ALL
+17-29..17-30 CONCATENATE-SEQUENCE:SIGNAL-ERROR
+17-30        CONCATENATE-SEQUENCE:SIGNAL-ERROR, 
+              SEQUENCE-TYPE-LENGTH:MUST-MATCH
+17-31        CONCATENATE-SEQUENCE:SIGNAL-ERROR
+17-32        CONCATENATE-SEQUENCE:SIGNAL-ERROR, 
+              CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              SEQUENCE-TYPE-LENGTH:MUST-MATCH
+17-33        RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+17-33..17-34 REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+17-34        REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+17-35        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS, TEST-NOT-IF-NOT:FLUSH-ALL
+17-36        CONSTANT-MODIFICATION:DISALLOW, 
+              MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89
+17-37        TEST-NOT-IF-NOT:FLUSH-ALL
+18-1         HASH-TABLE-SIZE:INTENDED-ENTRIES, HASH-TABLE-TESTS:ADD-EQUALP
+18-2..18-3   HASH-TABLE-KEY-MODIFICATION:SPECIFY
+18-4         ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              HASH-TABLE-SIZE:INTENDED-ENTRIES, HASH-TABLE-TESTS:ADD-EQUALP
+18-5         HASH-TABLE-REHASH-SIZE-INTEGER, 
+              HASH-TABLE-SIZE:INTENDED-ENTRIES
+18-7..18-8   HASH-TABLE-ACCESS:X3J13-MAR-89, HASH-TABLE-REHASH-SIZE-INTEGER
+18-8         HASH-TABLE-ACCESS:X3J13-MAR-89, 
+              HASH-TABLE-SIZE:INTENDED-ENTRIES
+18-9         HASH-TABLE-ACCESS:X3J13-MAR-89
+18-9..18-10  HASH-TABLE-ACCESS:X3J13-MAR-89
+18-10        SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED
+18-13        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+18-13..18-14 DECLS-AND-DOC, HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
+18-14        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
+18-15..18-16 SXHASH-DEFINITION:SIMILAR-FOR-SXHASH
+19-1         PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES
+19-2         FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE
+19-4         PATHNAME-COMPONENT-VALUE:SPECIFY
+19-4..19-5   PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT
+19-5         PATHNAME-COMPONENT-VALUE:SPECIFY, 
+              PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION
+19-5..19-6   PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+19-6         PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+19-6..19-10  PATHNAME-COMPONENT-VALUE:SPECIFY
+19-7..19-8   PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION
+19-12..19-14 PATHNAME-LOGICAL:ADD
+19-15        PATHNAME-STREAM, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+19-15..19-16 CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY
+19-16        PATHNAME-LOGICAL:ADD
+19-16..19-17 FILE-OPEN-ERROR:SIGNAL-FILE-ERROR
+19-17        PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD, PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+19-17..19-18 PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION
+19-19        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD
+19-20        PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT, PATHNAME-STREAM, 
+              PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION, 
+              PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+19-20..19-22 PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+19-22        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD
+19-22..19-23 PATHNAME-LOGICAL:ADD
+19-23..19-27 PATHNAME-LOGICAL:ADD
+19-27        CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, 
+              FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-STREAM
+19-29        PATHNAME-STREAM, PATHNAME-SYMBOL
+19-29..19-30 PATHNAME-WILD:NEW-FUNCTIONS
+19-30        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-SYMBOL, PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+19-30..19-31 RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+19-31        PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD, PATHNAME-STREAM, PATHNAME-SYMBOL
+19-32        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-PRINT-READ:SHARPSIGN-P
+19-33        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-STREAM
+19-33..19-34 PATHNAME-WILD:NEW-FUNCTIONS
+19-34        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-STREAM, PATHNAME-WILD:NEW-FUNCTIONS
+19-35        CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, PATHNAME-STREAM
+19-35..19-36 PATHNAME-LOGICAL:ADD
+19-36        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR
+19-36..19-38 PATHNAME-WILD:NEW-FUNCTIONS
+19-37        JUN90-TRIVIAL-ISSUES:5, 
+              PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT
+19-38        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-STREAM, PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+19-39        CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, 
+              COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD
+19-39..19-40 PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION
+19-40        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT, 
+              PATHNAME-LOGICAL:ADD
+20-1..20-2   CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY
+20-3         FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              RESULT-LISTS-SHARED:SPECIFY
+20-3..20-4   PATHNAME-LOGICAL:ADD
+20-4         CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, 
+              FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+20-5         CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, 
+              FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD
+20-6         FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+20-7         FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+20-8         FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+20-8..20-9   PATHNAME-LOGICAL:ADD
+20-9         FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+20-10        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, PATHNAME-LOGICAL:ADD, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+21-7         TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+21-7..21-8   BROADCAST-STREAM-RETURN-VALUES:CLARIFY-MINIMALLY, 
+              STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+21-8..21-9   STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+21-9         STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+21-10        STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+21-11        STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND
+21-12        STREAM-CAPABILITIES:INTERACTIVE-STREAM-P
+21-12..21-13 STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-14        CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY
+21-15        ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              READ-AND-WRITE-BYTES:NEW-FUNCTIONS
+21-16        READ-AND-WRITE-BYTES:NEW-FUNCTIONS
+21-17        ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
+21-18        ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
+21-19        ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              READ-AND-WRITE-BYTES:NEW-FUNCTIONS
+21-22        PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR, 
+              UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
+21-23        READ-AND-WRITE-BYTES:NEW-FUNCTIONS
+21-24        ARGUMENTS-UNDERSPECIFIED:SPECIFY
+21-25        RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+21-26..21-28 READ-AND-WRITE-BYTES:NEW-FUNCTIONS
+21-31        CHARACTER-PROPOSAL:2-5-7
+21-32        CHARACTER-PROPOSAL:2-5-2, STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-34..21-35 CHARACTER-PROPOSAL:2-5-2
+21-35        CHARACTER-PROPOSAL:2-5-2, PATHNAME-WILD:NEW-FUNCTIONS
+21-36        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD
+21-37        STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL, 
+              WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT
+21-37..21-39 DECLS-AND-DOC
+21-38        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL, 
+              WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE
+21-39        CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY, 
+              CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, 
+              FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD, RETURN-VALUES-UNSPECIFIED:SPECIFY
+21-40        WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE, 
+              WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT
+21-40..21-41 DECLS-AND-DOC
+21-44        FORMAT-STRING-ARGUMENTS:SPECIFY
+21-46        STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-46..21-47 STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-47        STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-48        STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-49        STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-50        STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-50..21-51 STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-51        STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-52        CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY, 
+              STRING-OUTPUT-STREAM-BASHING:UNDEFINED
+21-53        CHARACTER-PROPOSAL:2-5-6, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              STREAM-ACCESS:ADD-TYPES-ACCESSORS
+21-54        CHARACTER-PROPOSAL:2-5-6, STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR
+21-54..21-55 DECLS-AND-DOC
+21-55        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE, 
+              WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT
+21-55..21-57 DECLS-AND-DOC
+21-56        CHARACTER-PROPOSAL:2-3-6, CHARACTER-PROPOSAL:2-5-6, 
+              STREAM-ACCESS:ADD-TYPES-ACCESSORS, 
+              WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE, 
+              WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT, 
+              WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND
+21-57        MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, 
+              STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS, 
+              STRING-OUTPUT-STREAM-BASHING:UNDEFINED
+21-59        STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
+22-1         PRINTER-WHITESPACE:JUST-ONE-SPACE
+22-2         DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93, 
+              PRINT-READABLY-BEHAVIOR:CLARIFY
+22-4         PRINT-CASE-BEHAVIOR:CLARIFY, PRINT-READABLY-BEHAVIOR:CLARIFY, 
+              SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY
+22-5         PRINT-READABLY-BEHAVIOR:CLARIFY
+22-6         PRINT-CASE-BEHAVIOR:CLARIFY, PRINT-READABLY-BEHAVIOR:CLARIFY
+22-8         PRINT-READABLY-BEHAVIOR:CLARIFY, 
+              PRINT-WHITESPACE:JUST-ONE-SPACE
+22-8..22-9   PRINT-WHITESPACE:JUST-ONE-SPACE
+22-9         PRINT-READABLY-BEHAVIOR:CLARIFY
+22-10        PRINT-READABLY-BEHAVIOR:CLARIFY, 
+              PRINTER-WHITESPACE:JUST-ONE-SPACE
+22-11        PATHNAME-PRINT-READ:SHARPSIGN-P, 
+              PRINT-READABLY-BEHAVIOR:CLARIFY
+22-12        DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93, 
+              STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS
+22-14..22-22 PRETTY-PRINT-INTERFACE
+22-16        DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93, 
+              FORMAT-STRING-ARGUMENTS:SPECIFY, 
+              GENERALIZE-PRETTY-PRINTER:UNIFY
+22-22        DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93
+22-23        FORMAT-ATSIGN-COLON, PRETTY-PRINT-INTERFACE
+22-24        FORMAT-OP-C, FORMAT-PRETTY-PRINT:YES
+22-25        FORMAT-PRETTY-PRINT:YES
+22-26        FORMAT-COMMA-INTERVAL, FORMAT-PRETTY-PRINT:YES, 
+              PRINC-READABLY:X3J13-DEC-91
+22-27        FORMAT-PRETTY-PRINT:YES, PRINC-READABLY:X3J13-DEC-91
+22-28        FORMAT-PRETTY-PRINT:YES, PRINC-READABLY:X3J13-DEC-91
+22-29        FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
+22-29..22-30 FORMAT-PRETTY-PRINT:YES
+22-30        FORMAT-PRETTY-PRINT:YES, PRINC-READABLY:X3J13-DEC-91
+22-31        FORMAT-PRETTY-PRINT:YES, PRINC-READABLY:X3J13-DEC-91
+22-31..22-32 PRETTY-PRINT-INTERFACE
+22-32..22-34 PRETTY-PRINT-INTERFACE
+22-41        FORMAT-COLON-UPARROW-SCOPE
+22-45        FORMAT-STRING-ARGUMENTS:SPECIFY, 
+              PATHNAME-PRINT-READ:SHARPSIGN-P
+22-46        PRETTY-PRINT-INTERFACE
+22-46..22-47 PRETTY-PRINT-INTERFACE
+22-47        GENERALIZE-PRETTY-PRINTER:UNIFY
+22-47..22-48 PRETTY-PRINT-INTERFACE
+22-48        LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED, 
+              PRETTY-PRINT-INTERFACE
+22-49        GENERALIZE-PRETTY-PRINTER:UNIFY
+22-49..22-50 PRETTY-PRINT-INTERFACE
+22-50..22-51 PRETTY-PRINT-INTERFACE
+22-51        GENERALIZE-PRETTY-PRINTER:UNIFY
+22-51..22-53 DECLS-AND-DOC, PRETTY-PRINT-INTERFACE
+22-52        GENERALIZE-PRETTY-PRINTER:UNIFY
+22-53        GENERALIZE-PRETTY-PRINTER:UNIFY
+22-53..22-55 PRETTY-PRINT-INTERFACE
+22-55..22-56 PRETTY-PRINT-INTERFACE
+22-56        LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED
+22-57        DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93, 
+              GENERALIZE-PRETTY-PRINTER:UNIFY, PRETTY-PRINT-INTERFACE
+22-58        DATA-IO:ADD-SUPPORT, 
+              DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93, 
+              GENERALIZE-PRETTY-PRINTER:UNIFY
+22-59        DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93, 
+              PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
+22-59..22-60 DATA-IO:ADD-SUPPORT
+22-60..22-61 PRETTY-PRINT-INTERFACE
+22-63        PRETTY-PRINT-INTERFACE, PRINC-READABLY:X3J13-DEC-91
+22-64        PRINC-READABLY:X3J13-DEC-91
+22-65        PRINC-READABLY:X3J13-DEC-91
+22-68        JUN90-TRIVIAL-ISSUES:3, PRINT-CASE-BEHAVIOR:CLARIFY, 
+              PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE
+22-69..22-70 PRINT-CIRCLE-SHARED:RESPECT-PRINT-CIRCLE, 
+              PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
+22-70        DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93
+22-74        PRETTY-PRINT-INTERFACE
+22-75        GENERALIZE-PRETTY-PRINTER:UNIFY, PRETTY-PRINT-INTERFACE, 
+              PRINTER-WHITESPACE:JUST-ONE-SPACE
+22-76        FORMAT-PRETTY-PRINT:YES
+22-76..22-78 DATA-IO:ADD-SUPPORT
+22-77        PRINT-READABLY-BEHAVIOR:CLARIFY
+22-78        PRINT-READABLY-BEHAVIOR:CLARIFY
+22-78..22-79 PRETTY-PRINT-INTERFACE
+22-79        DATA-IO:ADD-SUPPORT
+22-79..22-80 DATA-IO:ADD-SUPPORT
+22-80        FORMAT-STRING-ARGUMENTS:SPECIFY, 
+              STRING-OUTPUT-STREAM-BASHING:UNDEFINED
+23-4         CHARACTER-PROPOSAL:2-1-1, 
+              READ-CASE-SENSITIVITY:READTABLE-KEYWORDS
+23-5         ARGUMENTS-UNDERSPECIFIED:SPECIFY
+23-6         ARGUMENTS-UNDERSPECIFIED:SPECIFY
+23-10        ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL, 
+              SUBSEQ-OUT-OF-BOUNDS
+23-11..23-12 READ-CASE-SENSITIVITY:READTABLE-KEYWORDS
+23-13        GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
+23-15        GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
+23-16        ARGUMENTS-UNDERSPECIFIED:SPECIFY, 
+              RETURN-VALUES-UNSPECIFIED:SPECIFY
+23-20        DATA-IO:ADD-SUPPORT
+23-21        READ-SUPPRESS-CONFUSING:GENERALIZE
+23-22        READ-SUPPRESS-CONFUSING:GENERALIZE
+23-23        PARSE-ERROR-STREAM:SPLIT-TYPES
+24-3         COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE, 
+              COMPILER-DIAGNOSTICS:USE-HANDLER, 
+              COMPILER-VERBOSITY:LIKE-LOAD, 
+              EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              PATHNAME-LOGICAL:ADD
+24-3..24-4   EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM
+24-4         COMPILE-FILE-PACKAGE, COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN, 
+              COMPILER-DIAGNOSTICS:USE-HANDLER, 
+              COMPILER-VERBOSITY:LIKE-LOAD, COMPILER-WARNING-STREAM, 
+              FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, IN-SYNTAX:MINIMAL, 
+              LOAD-OBJECTS:MAKE-LOAD-FORM, 
+              LOAD-TRUENAME:NEW-PATHNAME-VARIABLES, 
+              PATHNAME-WILD:NEW-FUNCTIONS
+24-5         CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, 
+              COMPILE-FILE-OUTPUT-FILE-DEFAULTS:INPUT-FILE, 
+              COMPILE-FILE-PATHNAME-ARGUMENTS:MAKE-CONSISTENT, 
+              FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD, PATHNAME-STREAM
+24-5..24-6   PATHNAME-LOGICAL:ADD
+24-6         EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE, 
+              EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM, 
+              FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD
+24-7         EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM, 
+              IN-SYNTAX:MINIMAL, LOAD-TRUENAME:NEW-PATHNAME-VARIABLES
+24-7..24-8   LOAD-TRUENAME:NEW-PATHNAME-VARIABLES
+24-8         FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD, PATHNAME-WILD:NEW-FUNCTIONS
+24-8..24-9   WITH-COMPILATION-UNIT:NEW-MACRO
+24-10..24-11 COMMON-FEATURES:SPECIFY, SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD
+24-11        SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD
+24-12        LOAD-TRUENAME:NEW-PATHNAME-VARIABLES
+24-13        LOAD-TRUENAME:NEW-PATHNAME-VARIABLES
+24-13..24-14 COMPILER-VERBOSITY:LIKE-LOAD
+24-14        COMPILER-VERBOSITY:LIKE-LOAD
+24-14..24-15 REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91
+24-15        REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT
+24-15..24-16 REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91, 
+              REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT
+24-16        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR
+25-5         DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE, 
+              TIME-ZONE-NON-INTEGER:ALLOW
+25-9         DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT
+25-9..25-10  DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT
+25-10        DESCRIBE-INTERACTIVE:NO
+25-10..25-11 DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT
+25-12        FUNCTION-NAME:LARGE
+25-13        EVALHOOK-STEP-CONFUSION:X3J13-NOV-89
+25-13..25-14 STEP-ENVIRONMENT:CURRENT
+25-14        EVALHOOK-STEP-CONFUSION:X3J13-NOV-89, STEP-ENVIRONMENT:CURRENT, 
+              STEP-MINIMAL:PERMIT-PROGN
+25-17        DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL, FUNCTION-NAME:LARGE
+25-17..25-21 DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT
+25-18..25-19 DOCUMENTATION-FUNCTION-BUGS:FIX
+25-19        DOCUMENTATION-FUNCTION-BUGS:FIX
+25-20        DOCUMENTATION-FUNCTION-BUGS:FIX, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+25-21        DOCUMENTATION-FUNCTION-BUGS:FIX, 
+              ROOM-DEFAULT-ARGUMENT:NEW-VALUE
+25-22        FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, FUNCTION-NAME:LARGE, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD
+25-23        RETURN-VALUES-UNSPECIFIED:SPECIFY
+25-24        DRIBBLE-TECHNIQUE, FILE-OPEN-ERROR:SIGNAL-FILE-ERROR, 
+              JUN90-TRIVIAL-ISSUES:25, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD
+25-32        PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+26-4         CONDITION-RESTARTS:PERMIT-ASSOCIATION, 
+              FORMAT-STRING-ARGUMENTS:SPECIFY
+26-6         CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT
+26-10        CHARACTER-PROPOSAL:2-1-1
+26-12        COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN, 
+              DEFINE-COMPILER-MACRO:X3J13-NOV89
+26-15        CONDITION-RESTARTS:PERMIT-ASSOCIATION, 
+              DEFSTRUCT-COPIER:ARGUMENT-TYPE
+26-16        SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91
+26-17        DEFTYPE-DESTRUCTURING:YES, DEFTYPE-KEY:ALLOW
+26-23        CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT
+26-24        SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES
+26-25        PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES
+26-26        FORMAT-STRING-ARGUMENTS:SPECIFY, 
+              IGNORE-USE-TERMINOLOGY:VALUE-ONLY
+26-31        KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              PLIST-DUPLICATES:ALLOW, 
+              WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91
+26-32..26-33 DOTIMES-IGNORE:X3J13-MAR91
+26-33        PLIST-DUPLICATES:ALLOW
+26-39        PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES
+26-41        OPTIMIZE-DEBUG-INFO:NEW-QUALITY
+26-43        CLASS-OBJECT-SPECIALIZER:AFFIRM, 
+              PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES, 
+              PATHNAME-LOGICAL:ADD
+26-45        PRINT-READABLY-BEHAVIOR:CLARIFY
+26-46        PLIST-DUPLICATES:ALLOW
+26-47        IGNORE-USE-TERMINOLOGY:VALUE-ONLY
+26-51        LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES, 
+              SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS
+26-53        DEFINE-COMPILER-MACRO:X3J13-NOV89
+26-55        KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92, 
+              WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91
+26-55..26-56 CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY, 
+              PATHNAME-STREAM:FILES-OR-SYNONYM
+26-56        STRING-COERCION:MAKE-CONSISTENT
+26-58        TAILP-NIL:T
+26-58..26-59 TIME-ZONE-NON-INTEGER:ALLOW
+26-61        ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM
+26-61..26-62 ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM
+26-62        ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM, 
+              PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION, 
+              PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN
+26-63        ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM, 
+              IGNORE-USE-TERMINOLOGY:VALUE-ONLY

Reviewer-Notes.text

@@ -0,0 +1,130 @@
+                                                11 May 94
+Dear Reader,
+
+At the present time, pending X3J13 vote, this draft (version 15.17,
+document X3J13/94-101) is an internal draft of the X3J13 committee.
+In spite of the cover page that we have optimistically placed on this
+document, this is NOT yet a "draft proposed American National Standard".
+
+Since version 14.10 (document X3J13/93-102), ONLY EDITORIAL CHANGES have
+been made.  A detailing of these changes can be found in the files
+Change-Log.text and Change-Summary.text.
+
+X3J13 will be asked by letter ballot whether it would like this version
+forwarded to X3 and OMC for approval.  It is hoped that X3J13 will vote
+YES, but we will not know for sure until the letter ballot occurs.
+
+When the status changes, this document will be updated.
+
+If you have procedural questions, you can address them to me at
+
+     Mail          Kent M. Pitman
+                   X3J13 Technical Editor
+                   Harlequin, Inc.
+                   One Cambridge Center, Suite 904
+                   Cambridge, MA  02142
+     Internet      KMP@Harlequin.COM
+     Phone         +1-617-252-0052
+     FAX           +1-617-252-6505
+   
+or to Guy Steele (X3J13 chairman) at
+
+     Mail          Guy L. Steele Jr.
+                   X3J13 Chairman
+                   Thinking Machines Corporation
+                   245 First Street
+                   Cambridge, MA  02142-1214
+     Internet      GLS@Think.COM
+     Phone         +1-617-234-1000
+     FAX           +1-617-234-4444
+
+or to Dan Arnold (X3 Secretariat) at
+
+     Mail          Dan Arnold
+                   X3 Secretariat
+                   Computer and Business Equipment Manufacturer's 
+                    Association (CBEMA)
+                   1250 Eye Street, NW, Suite 200
+                   Washington, D.C.  20005-3922
+     Internet      75300.2354@CompuServe.COM
+     Phone         +1-202-626-5747
+
+Thank you for your interest in Lisp, and in the standardization process.
+ Sincerely,
+ Kent M. Pitman
+
+==============================================================================
+
+Notes about the attached files:
+
+ Files                    Notes
+ -----                    -----
+
+ *.dvi                    These files comprise the typeset document.
+
+ *.tex                    The TeX sources.
+ index.idx
+
+ issue-index.text         A mapping from technical issues to document 
+                          page numbers.
+
+ Change-Log.text          By-file differences between this version and 14.10.
+
+ Change-Summary.text      By-topic summary of comments and actions taken 
+			  since 14.10.
+
+ Reviewer-Notes.text      This file.
+
+ Verification-Notes.text  Information about how to verify the correctness
+                          of the information you have using md5-signatures.
+
+ *.Z                      These files comprise compressed variants of 
+		    	  any of the above.  If some file foo.bar that you
+			  are looking for is not present, but foo.bar.Z is,
+			  you should transfer the file in binary mode and
+			  then use the unix "uncompress" program to expand
+			  the file back into foo.bar.
+
+================================================================================
+
+Version 15.17
+
+ Chap  Description                              Pages
+  0. Cover          2
+     Contents      18
+     Figures        6
+     Credits        8
+     Index         22
+     Total ......			        56
+  1. Scope, Organization, References, Defs, 
+     Compliance, Extensions, ALL CL Symbols     48
+  2. Syntax                                     42
+  3. Evaluation and Compilation                108
+  4. Types and Classes                          44
+  5. Flow of Control                           106
+  6. Iteration                                  46
+  7. Objects                                    94
+  8. Structures                                 20
+  9. Condition                                  74
+ 10. Structures                                 26
+ 11. Packages                                   44
+ 12. Numbers                                    94
+ 13. Characters                                 28
+ 14. Conses                                     64
+ 15. Arrays                                     42
+ 16. Strings                                    16
+ 17. Sequences                                  40
+ 18. Hash Tables                                18
+ 19. Filenames                                  42
+ 20. Files                                      14
+ 21. Streams                                    64
+ 22. Printer                                    82
+ 23. Reader                                     26
+ 24. System Construction                        18
+ 25. Environment                                34
+ 26. Glossary                                   66
+  A. Appendix                                    4
+
+ 1360 total pages.
+
+(Chapter and total page counts unchanged since version 14.10.)

Verification-Notes.text

@@ -0,0 +1,389 @@
+In order to provide a degree of confidence about the online copies of
+the ANSI specification, we have computed the MD5 message-digest
+signature for each of the files in this directory.   Independent
+computation of the signature of each transferred file and verification
+against these signatures may be used to claim a substantially higher
+confidence level that the transfer has been done correctly, but it is 
+not an absolute guarantee of correctness.
+
+For further information on the MD5 message-digest signature and the
+algorithm for computing it, consult RFC 3121.
+
+MD5 Signature                    Filename
+------------------------------------------------------------------------------
+cfd81cc81411e42a531da1755f95ef00 All-Symbols.lisp
+d4a4f6404150936c9e358b92aa885ddb Change-Log.text
+f6023825834e55b7a923c62f9f25be7a Change-Summary.text
+4c4f25b3ff1c2ce6dd674e25c64fa197 Issue-Index.text
+1c79fc1352492caa09f0048fffcbad44 Reviewer-Notes.text
+34103df64ea2ce1c84c3206578119a09 appendix-implem-defined.tex
+ad1e75e25060662daf96788dec80e2cd appendix-portability.tex
+1ce2e6d246c276d012c6c91b57eca5ff appendix-removed.tex
+64e5247c74216007f060c93f52969d9a chap-0-edit-history.tex
+6d915b4ebce9d9e89075eb6c915607fb chap-0.dvi
+950a55d9bec1d4836ceb6093c4785167 chap-0.log
+771abb1f802f7fdb4be05a07837ac297 chap-0.tex
+d410c4247907a7ea8c7c5c81e946cacc chap-1.dvi
+95b044996739e458097fc590e70e6463 chap-1.fig
+e9867fc5232854d2ee4853b4e18dac71 chap-1.idx
+04d03bdc51a4e29045b0ccf0d8e3bc27 chap-1.iss
+2faed6330710441141052fa2e5fef965 chap-1.log
+d41d8cd98f00b204e9800998ecf8427e chap-1.ref
+f8af7a080b13527310901cc0ba05a4f1 chap-1.sec
+50080f83aa3c0c4768a154ed65f0bca7 chap-1.tc
+4c3a7f8e052130443585b3c4e0b158b7 chap-1.tex
+74063eb5151bd69dca7ace519aa9eddc chap-1.toc
+6264e59ec183a0fbe3a0db419d8142a9 chap-10.dvi
+702fa8da114c82dd928da434b7321033 chap-10.fig
+3b928ae65b3df5e00a328b0fe183b65f chap-10.idx
+dd4b5851acaa8136691af73af5093b4d chap-10.iss
+0d0ca117fb52c53bcda8080e07ee21ba chap-10.log
+d41d8cd98f00b204e9800998ecf8427e chap-10.ref
+05e0b63ccc3b154a1784e4a357504428 chap-10.sec
+d523211e433d0cdcddd794b6779ac0e3 chap-10.tc
+f8feca0d67468bbe8a387fbcc8eb84d3 chap-10.tex
+d523211e433d0cdcddd794b6779ac0e3 chap-10.toc
+4af06e088d76a8752596b261e4179a24 chap-11.dvi
+eca108dbb585abc2044bc24339fc1b11 chap-11.fig
+05aeb62ccf995229ec82418f9fe3847e chap-11.idx
+aa655af959e763b80d752a04b0213904 chap-11.iss
+a88f2b86a1662ead93d11fc0c9baa43d chap-11.log
+d41d8cd98f00b204e9800998ecf8427e chap-11.ref
+904924326625391d43d6b814c61bf883 chap-11.sec
+7ae11815daa6f2010c4fb16f34a1120a chap-11.tc
+f4a7b016601fa64e3838e79fa8a6ce79 chap-11.tex
+7ae11815daa6f2010c4fb16f34a1120a chap-11.toc
+c0112415b8c40b520dc4d1ab00e9539b chap-12.dvi
+b15ea8376e62a249aac3319e71a2b7a4 chap-12.fig
+9e748b310ce23bc971d2b5efe1d7fc45 chap-12.idx
+c9349a36e90998c7a47bd7db14bf0bbc chap-12.iss
+7a8ee0e68e41b84f9dd6fd953d303a56 chap-12.log
+d41d8cd98f00b204e9800998ecf8427e chap-12.ref
+90f1bb98a452b561007ee98ad7cc1fe1 chap-12.sec
+e854af933807d470a513fed26f19c385 chap-12.tc
+7d20c664251bb8f351865710bb423395 chap-12.tex
+739940c48a55cceef6c82d174d02c6c7 chap-12.toc
+550a2bae7db3ec893737f676bae5d62c chap-13.dvi
+2db096db5f6ad4f4727ef2aa4a6564e0 chap-13.fig
+183dc9401aee370f9841b598bcc01539 chap-13.idx
+8c04083bc8be2f456ff968084dd94497 chap-13.iss
+8965ac0a8d3a5d8a702824f28ce2c260 chap-13.log
+d41d8cd98f00b204e9800998ecf8427e chap-13.ref
+d1db91e92a87aab3dc7a33b61e983755 chap-13.sec
+a243a9bd490a2c21bc1ac3dac4099b7d chap-13.tc
+64249ea1370eec7eb4167aaf5c36585f chap-13.tex
+a243a9bd490a2c21bc1ac3dac4099b7d chap-13.toc
+ef72465b97e691f7b58a949e1041f92f chap-14.dvi
+d6287afc3eebb44311a4d297b8ba2065 chap-14.fig
+3f597a4b455442e2594809a0fa74e971 chap-14.idx
+425452c84f8bc586e425896fb8db2ab7 chap-14.iss
+36b3d29ba2ae2b871a82f63242ff95cc chap-14.log
+d41d8cd98f00b204e9800998ecf8427e chap-14.ref
+c1ab9d98ca6056920bf7550a25d83496 chap-14.sec
+03196b2f34365c9de0f2c261914c0267 chap-14.tc
+362a0001fcba45b11ded38d89b43a780 chap-14.tex
+03196b2f34365c9de0f2c261914c0267 chap-14.toc
+bdf2838d8774a5c62eea9b07595f81c7 chap-15.dvi
+fd024b3672d832669129b25d862e1821 chap-15.fig
+625eec9243248d099fa325546decf563 chap-15.idx
+794d20bbd41eb944fd9aab7ade96740a chap-15.iss
+f4fcc5e4d1138902bf9a0b3053ebb5d0 chap-15.log
+d41d8cd98f00b204e9800998ecf8427e chap-15.ref
+41b1fcc7e3be0cbdfb6c1d6ba6e2c5ee chap-15.sec
+2eab50b445770552de5bfcc8cd5a0652 chap-15.tc
+8710905a7e78a757750224346d5e3fde chap-15.tex
+2eab50b445770552de5bfcc8cd5a0652 chap-15.toc
+af888b243d93f21c25ab23ef5c5ac442 chap-16.dvi
+d41d8cd98f00b204e9800998ecf8427e chap-16.fig
+d0b5fdd4bde1251fcdeb0cbfa6746844 chap-16.idx
+245096fbc91f3c75377812197e8f9e04 chap-16.iss
+312402f3d1dd798d67a4f3e6dacd826e chap-16.log
+d41d8cd98f00b204e9800998ecf8427e chap-16.ref
+a6dfd8c4fd43c653405d8caed0052a43 chap-16.sec
+b11c9e4a0658a8f8221e7e6fcae7fdc2 chap-16.tc
+53a9f62d268039143d571853f8964bb8 chap-16.tex
+b11c9e4a0658a8f8221e7e6fcae7fdc2 chap-16.toc
+ca97fc23c4e81cc487eb41f03e9f4360 chap-17.dvi
+7ad8be3be60814e07f6d45a549db7fbe chap-17.fig
+cfdce701b4a19b53e7500d7890816749 chap-17.idx
+3b7a94386bc788c6f67a12084146e58c chap-17.iss
+26fd044b363a7991e7b0828e09bb6cb4 chap-17.log
+6c2a956e9574417061ebc503c841c6d6 chap-17.ref
+9ecb1cb7a6c1a66f1e1e055a4169eee9 chap-17.sec
+c7a51239a7e7c8f9402c878c163428e9 chap-17.tc
+6d94c32bc9d486a173c4ab49ad47ae70 chap-17.tex
+6d2a7636b3c56541d34a54e6b9156acf chap-17.toc
+33f9e228905d4df367d8e8a829d03c96 chap-18.dvi
+2c6f7e2218a04fb17872c7f5b028aa9b chap-18.fig
+60d0e0657882cea89f831acbb3d5bffe chap-18.idx
+ddf2462653e0a77641ef3b8f69cec802 chap-18.iss
+6a53b15f6be5952ec29ec90f98c3e281 chap-18.log
+d41d8cd98f00b204e9800998ecf8427e chap-18.ref
+cbb2807e7ff1a945f544742da3c0a2a6 chap-18.sec
+fd354ff3671b4c4a5d1b60d9a886a4ef chap-18.tc
+fb636b68277a1e546d0e49ce765b9a37 chap-18.tex
+fd354ff3671b4c4a5d1b60d9a886a4ef chap-18.toc
+a4ea28aaf84c2bf4f49510c2f96bd06d chap-19.dvi
+ac75352b97cf81a9c8fbb953d0529e98 chap-19.fig
+9fd1f7ae1b5b25e65c80cb72f09672bc chap-19.idx
+dc739485d58ade991f1e5b2b270c40c7 chap-19.iss
+812a497b743ebb60e574d7c933f79c04 chap-19.log
+4dd3fc27e164e5d861b3c25e861f3a7a chap-19.ref
+cd04c7fd256dab9c9ada02e17388155d chap-19.sec
+2460e3148aa86844a25230c7bc5a0f18 chap-19.tc
+e06bdcf58316e8ea82d052bc85f69ff0 chap-19.tex
+f8bb1f32c4236062df504854a23b44c5 chap-19.toc
+3e5855dc516da4b9900be32d44ebad50 chap-2.dvi
+7a8292eb0ab13780a5ca5038e2f048c6 chap-2.fig
+ef769dc88ca7de98637cb538e800e8ad chap-2.idx
+f82da514d81e9289400ede57070dd6b8 chap-2.iss
+61a64f40bd122b24bdeae6b6011561c6 chap-2.log
+2080ad30b5d538d1430e2dd12bcb7646 chap-2.ref
+2f07736323c868a47485c35e3804b4f3 chap-2.sec
+b245409b29cf66985af1421e0ce0fbec chap-2.tc
+c107593a7bec6973711bf6cdb94b966c chap-2.tex
+97cda4a95fe6067c92fcf98c2024ce16 chap-2.toc
+dc465a2b2c19d394c6801d3990853db0 chap-20.dvi
+1883a84dc7b3c210e0561dd8ad94ab38 chap-20.fig
+03554cdc2e134f667636832cdc0add0e chap-20.idx
+d6f81fbb883320b01b3dd04b20124fa6 chap-20.iss
+df4c21725524106fad0f08921b82eae4 chap-20.log
+d41d8cd98f00b204e9800998ecf8427e chap-20.ref
+8b95ae481794957e1ef2ea550741ca1c chap-20.sec
+5ab0641eac678db9ae55d42bcccd3f67 chap-20.tc
+65f37fa3edeabf8e210d8e7bc306e745 chap-20.tex
+5ab0641eac678db9ae55d42bcccd3f67 chap-20.toc
+6fd4e6f6c6b5d5fad5eaa40efc9a03a2 chap-21.dvi
+9cbafcac6272624e8c9f70a8615ab1e6 chap-21.fig
+cd68fdfb1bde56a0c277935c65cc0c35 chap-21.idx
+4f85ffcaf46231bd6a1e32b2c4c63d10 chap-21.iss
+89e911f3682cc2945779341f596994e8 chap-21.log
+7082416c0dbe0d400ca468789781c450 chap-21.ref
+70cf766b6c1521017a8243a11994e591 chap-21.sec
+31879d995cb2be1cfdb4300b03a84af8 chap-21.tc
+1575655faef6197b490e9164d8c09d12 chap-21.tex
+31879d995cb2be1cfdb4300b03a84af8 chap-21.toc
+a8c19553047499f7df962998f1ea71fe chap-22.dvi
+67f0cad1afded5b84bd601f90f3b5d7b chap-22.fig
+8aacea40385068858c872b05a279028c chap-22.idx
+62702bb5cfe223cc676179b356faf079 chap-22.iss
+a6d800776616391e772be09cdf683245 chap-22.log
+66ef9f52a5cd8c73186ac967fe5ef8b4 chap-22.ref
+ad54fbce80975cdd90ea3dfd6dc86675 chap-22.sec
+be440872172238c9273e1d2e103bbf0c chap-22.tc
+4a62a4f12da7175cc3f4c14221714233 chap-22.tex
+c842dc866497597f065a2ae816dc2a73 chap-22.toc
+07663502faeb46dadd25da8ac9847941 chap-23.dvi
+ddedcacbb8edee86eda0b1c9169110e4 chap-23.fig
+228522f46292e773aba2fec71f6f03f4 chap-23.idx
+bcda377e4be08081405146db59a581ba chap-23.iss
+eba363e136a04a4e9cb925461fec1751 chap-23.log
+d41d8cd98f00b204e9800998ecf8427e chap-23.ref
+42ec6b58a3a46bbf5dd3c1161b631524 chap-23.sec
+bd84721a5c3009fcdb131512b90be95d chap-23.tc
+87b898786c00428760d666f643ddfcb9 chap-23.tex
+f1e90bdf39c47a2d487b02bea0ec88e2 chap-23.toc
+fd9cc625ec8c32d546f14486d44fce8f chap-24.dvi
+15329cb9a3c35ae7973c092c0ca9f91f chap-24.fig
+d5ce7225812695bda142408e8e0e6fa9 chap-24.idx
+e2834c131b5c1aad36ce0fcabcc268d5 chap-24.iss
+9cbc2f2622e774f6f2628e2375bf1398 chap-24.log
+d41d8cd98f00b204e9800998ecf8427e chap-24.ref
+2355079c394c19b11a18de4e71d99ba9 chap-24.sec
+892c269501322b03d74c364db596e0b7 chap-24.tc
+be86bae8086cd1b5871f65c9ebd11974 chap-24.tex
+892c269501322b03d74c364db596e0b7 chap-24.toc
+3c067c668278bf7d0fdf478ef7186207 chap-25.dvi
+e7cedcb2fa82400436867bbaf8569d51 chap-25.fig
+1926f34da738b624912c0a62ad10ce51 chap-25.idx
+3ba36817e3b93e5c1b0319f94e553048 chap-25.iss
+936bc5750c01a513730feeaa796db3ea chap-25.log
+d41d8cd98f00b204e9800998ecf8427e chap-25.ref
+2b9ecf51faaa6107aae2299afeb240ec chap-25.sec
+cd68cf54e820c3c358443fcd3238c570 chap-25.tc
+af4fcb7c941f969c0081e47721bce1ae chap-25.tex
+cd68cf54e820c3c358443fcd3238c570 chap-25.toc
+4c93ef86c2bf67a1e7a4502244d8f9f1 chap-26.dvi
+e1065c830e6cd13155ea6c652f285970 chap-26.fig
+03bc0aaa046f0eb77ad2dce70c221fbc chap-26.idx
+0c0138df61eb3a7a7c9a165adbfe8af6 chap-26.iss
+5566c0c6a5c5799b19cadc52132be567 chap-26.log
+d41d8cd98f00b204e9800998ecf8427e chap-26.ref
+0df83ae10c3859e0adfb07ac629ba110 chap-26.sec
+3970e8a35c2989bab1e484729385485e chap-26.tc
+a2ad0f0ad4a2c37a40a7c993110da2f3 chap-26.tex
+3970e8a35c2989bab1e484729385485e chap-26.toc
+39bd96fa4dce90c44c39e2819012d82c chap-3.dvi
+ea26428d4ade1072ba77bc447746c4b8 chap-3.fig
+e07b8ce8bd774f09bd363f2ae820b10d chap-3.idx
+69940824bb66875e806022c66d699619 chap-3.iss
+f4832878a802ac9f39c9b6219ce2279d chap-3.log
+031c85ca23cc11afce76de19d67c10e5 chap-3.ref
+13edbc86e50d98dab570b9ef7abae309 chap-3.sec
+20fa11da21adad0922e39b2fa0ffd894 chap-3.tc
+3c9f34e74334237100be5cf48cccd27a chap-3.tex
+8a492c888e575df8ee6a7956bed8c47d chap-3.toc
+feeef9a0c4ad371f360865ddb50d31bd chap-4.dvi
+e7429b43708c8f72ba34c1be9c798e42 chap-4.fig
+1905b69ca1329a8afb603787e21667a8 chap-4.idx
+f4d3ceb948a1e0caa5739dabb9f30611 chap-4.iss
+9c5dab175ee086bf6e4a547f332f212e chap-4.log
+82d7a6ae4c8bb77278009f801f4c5d79 chap-4.ref
+b8810eade682706a435c18acb4c47e91 chap-4.sec
+769bfd535d2203c86cf64d8ca7c8fa12 chap-4.tc
+48fdb96ac5250248f6b2b6f2e4970d2d chap-4.tex
+769bfd535d2203c86cf64d8ca7c8fa12 chap-4.toc
+d6ae29f10b58ecc7810d13fe674c7b33 chap-5.dvi
+178261d4386914fe3ad28bca9282715c chap-5.fig
+de4e160af71a97eedc25e91cd970d004 chap-5.idx
+484506ccb35b0cb0427901b9808a545a chap-5.iss
+3266130bea93c08dcc6317d4d4c8ddd5 chap-5.log
+d41d8cd98f00b204e9800998ecf8427e chap-5.ref
+ee33b203aa01c5b483add50ebe73fa11 chap-5.sec
+5f741b14a9ee0e168c1a6dc1315089ca chap-5.tc
+109ed445d84ba52f006f53fead51dc4e chap-5.tex
+b649b2d4c7de7f246428fb752d632b50 chap-5.toc
+2cc7c9a9b554fcec25db004297e501f3 chap-6.dvi
+d41d8cd98f00b204e9800998ecf8427e chap-6.fig
+9c93d561532d3016b348e07f19c6836b chap-6.idx
+d8cb44354b1c88b5f0c0ebdec1e1b486 chap-6.iss
+d76397d02e82d00e4fa10918f542231c chap-6.log
+d41d8cd98f00b204e9800998ecf8427e chap-6.ref
+c22e6bb8de82eeaaea48b434a0f0d145 chap-6.sec
+89f7540e1531b736c3b3d65ef0fce99e chap-6.tc
+ddbc5ac1bc1309f090bd00f35cdd7c87 chap-6.tex
+a4b0f07a2f664a644766c52059afab78 chap-6.toc
+df370cd1c1109407ceaf9eeb45f3056f chap-7.dvi
+081f58395b441f8173800735ef113ca3 chap-7.fig
+edfbd41b06bdf8d7971ba31c5464a2c1 chap-7.idx
+d134f7309475be2a4abc47a8c57cb52d chap-7.iss
+8ad5f5e999c75996cf6fa3ca17af5a9a chap-7.log
+d9e03626313ad97a91ff95db9181f25c chap-7.ref
+8be3d5d7a3a85d4529c9b26433bd99cf chap-7.sec
+94c44ff6979f51ac1ef15af7e5aafaac chap-7.tc
+95d6b75819be2b5c4e5474ac5aabad4e chap-7.tex
+16541eae9c8321f17157064ef668c250 chap-7.toc
+c0ae3a75a8d0d5fbfc238eda8b208d46 chap-8.dvi
+d41d8cd98f00b204e9800998ecf8427e chap-8.fig
+401aa6e5c1a0777e7a48b83f1dbd309a chap-8.idx
+bb6150c15e96b174ef04d7c368ac028d chap-8.iss
+6a6f2e80a3d0a99bc3c6a39aeb4181d3 chap-8.log
+d41d8cd98f00b204e9800998ecf8427e chap-8.ref
+fe3667cab61b006faebff65e3911448c chap-8.sec
+8b25c3afef0a6c08e0ba595b2837336d chap-8.tc
+c2d1ff818b3509e7efe922386fe67c10 chap-8.tex
+8b25c3afef0a6c08e0ba595b2837336d chap-8.toc
+089d4f90c2fbd3713b857078317d739b chap-9.dvi
+df8f7ce1ced382c1e0fbcca5aadf7cde chap-9.fig
+21a53afc44c656a02f5ddb076fcbd525 chap-9.idx
+e4f554f1dd0e47b28df5b360b6774906 chap-9.iss
+6d82d00a7b369e0a6c94505feb1194ce chap-9.log
+546e51063a2d3ebec1fe77768dfa0cde chap-9.ref
+64a7966440911d4b760bb0de95420a94 chap-9.sec
+bc2fd7f26df693e9007c330917d44e31 chap-9.tc
+05bc659ac9c516f4b553aba23ea5a230 chap-9.tex
+1331af1342c3d425dede7dcb56736ff8 chap-9.toc
+8ef380b2764e1ea2927906b50ab6ab04 chap-a.dvi
+d41d8cd98f00b204e9800998ecf8427e chap-a.fig
+379882e59172056603125b32779215ec chap-a.idx
+d513b2b4f6ed317c01f2319117775f34 chap-a.iss
+6c3a683725ab0ff5737cd41faa113a95 chap-a.log
+d41d8cd98f00b204e9800998ecf8427e chap-a.ref
+c0af446da2ac9503452796b1148a686b chap-a.sec
+2fb2792ddbf9255dcd4d9a696a3449eb chap-a.tc
+56904843c2bc99bf6089539c19d59ac2 chap-a.tex
+2fb2792ddbf9255dcd4d9a696a3449eb chap-a.toc
+e821ae1d3a70b63435d0131ac83d2326 concept-args.tex
+dd8ac3fa2b2519c236f57638c3d2ab2a concept-arrays.tex
+52f2e580a0a3598b5eedb62731c22f71 concept-bvl.tex
+9eaa11b07cad16df31f2f39617093cb6 concept-change-class.tex
+3939344d0315dcd6fb9a5a4dd9465775 concept-characters.tex
+753120f1ee1516a8e4471fbf2040a6e7 concept-cl-symbols.tex
+78fac4c46507904b1433f36e82555dff concept-classes.tex
+c3057138932b12d0dfcb680460a4a340 concept-compile.tex
+a43bf93fad396ebb8d6a4b760dfb8f92 concept-conditions.tex
+266634d0b61b9a5ac952a7380530565d concept-conformance.tex
+c310ea5aa26104d6a39c3d45090ed450 concept-conses.tex
+99ccd79aa436d6a9f55e743c2405204a concept-decls.tex
+b5656762c1e893996153ab5b1be3a9e8 concept-definitions.tex
+0907bbefb6242ee30c41b6b423e632be concept-deprecated.tex
+922ebe4989f17700d8f2a691054aa61f concept-destruction.tex
+0f023e3db0a12e774a342b499f6be799 concept-environment.tex
+74a9f6295e8c36ceb4ff3505c7c11f16 concept-eval.tex
+08675fbb289c57be078df457dc03d678 concept-exits.tex
+b921dcd2a33be8c5226edb41dcd9fe83 concept-extensions.tex
+c0eb0ce7746da88ca0a2bea41eb003be concept-filenames.tex
+281e8b2dde9ca6968e9b0abf1e90cb2c concept-files.tex
+44061f0919273e9d24d50c1cefe7dff8 concept-format.tex
+9c78db65a71138ba25f3eb142a3c0e8a concept-gfs-and-methods.tex
+2deb65ae32ccc6f38a8b95158ec0880f concept-glossary.tex
+30c00a6e8ac3d3db95153e26c17be46c concept-hash-tables.tex
+20db3a10b1675852600877fe0f640d9b concept-history.tex
+2493fe8f77f2cd8d36a4a530a4ec20d5 concept-logical-pathnames.tex
+5df7a2eca8ee95f25ea47f821c110033 concept-loop.tex
+9eebc739f1d0e948657795884a662c5a concept-macro-chars.tex
+a9cdcc8644678df1f5c5094d64665671 concept-meta-objects.tex
+c69665c27d2ac86c5abbea387c675475 concept-numbers.tex
+9024b9972dcc7449adf2a1a4ec1f6624 concept-objects.tex
+d400d5363fbb5906dee0a0c06bfe8005 concept-organization.tex
+d32674a564e1595a7a51a027e70ee9ad concept-packages.tex
+3713e31d9589d1b4010b6f83ef2c6f52 concept-pathnames.tex
+b7e1b1c573791cc502fc47ffe52ee5dd concept-places.tex
+795708f76d0cc268e043afebbfa5eab2 concept-pprint.tex
+6212290d80bb7a1321e37598add0eb26 concept-print.tex
+243cdc83d55dad23b8f2a90ec7a6d5dc concept-reader-algorithm.tex
+edf1c038c4c43c29a42c5d916c9e6e06 concept-reader.tex
+27690c0df2158d3da4bf2ef4e252d96a concept-references.tex
+fb948c900ac354a58ac80950fae3b9a8 concept-reinit.tex
+eab2fb2df47427c0d62c9fb074c5270a concept-sequences.tex
+e87c71da9b366699a6c251d0c62af1ab concept-slots.tex
+3bd74e1bafbf2e0f0defc5d41bd76a79 concept-streams.tex
+058edd82507f788171db4236cecd89d1 concept-strings.tex
+95698531dd09b7c0159cae87b82b3c45 concept-subsets.tex
+c69c9cc4ff9c1c8cee90d48e454ee085 concept-symbols.tex
+89bb66f6a3d9140fb17845dbd0eeeede concept-syntax.tex
+64c2646a9c906ffdcb198f2b97677010 concept-systems.tex
+94201c8bcb6442f9c2a5878453ca06f0 concept-tests.tex
+a3307102f4169bdf20e62a31e69f240f concept-tokens.tex
+99522a55abf3b6bab1a2d02307e74086 concept-traversal.tex
+8d99591e5d5101902d48403dc2149d47 concept-type-intro.tex
+9d6dc510b6c00501748ca6f3fb76aa8f concept-types.tex
+a548cf343a7e70656e744a801d9a43f0 dict-arrays.tex
+ee9ad3cc77c8fa6191049194d8c1e709 dict-characters.tex
+f000107f959b5e33cce051ff18c25290 dict-conditions.tex
+ef4cff2044e4854c0845a64c3330065c dict-conses.tex
+27af81631961e359efbd7484671d92d6 dict-environment.tex
+5e895f1ea94a4def454cb2cc50eacbdd dict-eval-compile.tex
+3a2305924c6bcff81b17527a32319563 dict-files.tex
+00fac528a2dcf3f2c0baa3fcc5438064 dict-flow.tex
+556049fff061479039e2b53578536b7a dict-hash-tables.tex
+ddcb41a305db0abf30a01eb828d1dc48 dict-iteration.tex
+f0f1755f38aa5e0a89348311c9e28d44 dict-numbers.tex
+2edfc1e84275f1251f2905205d0a66c8 dict-objects.tex
+e384c4d2f72303d5bdee60ca732e15c4 dict-packages.tex
+d6f9302a08065366603a94bd9d3f8565 dict-pathnames.tex
+e8ff02fe3fbb56dea252a9abf32591d8 dict-printer.tex
+b953cfc32de16d5c6ec98a249bf8691c dict-reader.tex
+8d4c9106735250166044bdba398d765d dict-sequences.tex
+6bbcacfe0175c14120b4dde8eb6edc2f dict-streams.tex
+78ff664030e1399f4db4543bd69ff433 dict-strings.tex
+df81cf3c4142e03fbec6fa29e4c24a3c dict-structures.tex
+0bdd0311718f462c925c2d109f2409d3 dict-symbols.tex
+325fff3cf290566c4eeac576e91bd982 dict-system-construction.tex
+652e10175c951fc9ebfc6fc83d6131d6 dict-types.tex
+76ecf941892a14ba5119af0c4aa40cdc index.idx
+0bc4acfbb61635f73213658ae453b7cd setup-amfont.tex
+ef7bb9d84093bff7646a7a201d604291 setup-aux.tex
+0e21048123e26d3d4dd44aa2b3c243ea setup-boxfig.tex
+e1a2f11d6f598d55f9edb89d00cdd95e setup-cmfont.tex
+727863f91c3c88e87228b0963d582458 setup-document.tex
+6b60e438f3388a2a997329f2a04cdbc9 setup-figures.tex
+bf737add0644ee77ba8741d6d1dbc872 setup-for-toc.tex
+3e4d28ed1b44de6fca40c41cecdd9510 setup-options.tex
+159debd272627ed3db537d4fc44e2b7c setup-sections-for-toc.tex
+dacde1c4a0389de8d53685b37e637394 setup-sections.tex
+ddff52463239b83176331b08fbfca16b setup-tables.tex
+d0649d810bf04938215e847320cd370b setup-terms.tex
+6764350332025bd1fd17f821c642cc2b setup-title.tex
+7dffcefdb69af9c7454b4ca1c0d94957 setup-version.tex
+bb1751e7451cc27b0fb5494a82541ea5 setup.tex

appendix-implem-defined.tex

@@ -0,0 +1,634 @@
+% -*- Mode: TeX -*-
+%%Implementation-defined Features
+
+\editornote{KMP: I have made no effort to keep this up to date.
+		 When the document is nearly complete, I'll search for
+		 occurrences of ``implementation-defined'' and
+		 ``implementation-dependent'' and bring this up to date.
+		 Don't worry about consistency issues here for now; the main document
+		 takes precedence.   But do feel free
+		 to comment on things which are mentioned in the running text
+		 of the main document that are not marked as implementation-defined
+		 but should not be, etc.}
+
+The following sections contain lists of \term{implementation-dependent} 
+language characteristics.
+For more
+information about each of these implementation dependencies, 
+see the dictionary entries for the description of the \term{defined name} being qualified.
+
+\beginsubSection{Values}
+%%\item{2.}
+\beginlist
+\item{1.}
+An implementation determines the initial values of the \term{defined names}
+in \thenextfigure.
+
+\displaytwo{Implementation-defined values}{
+boole-1&boole-nand\cr
+boole-2&boole-nor\cr
+boole-and&boole-orc1\cr
+boole-c1&boole-orc2\cr
+boole-c2&boole-set\cr
+boole-clr&boole-xor\cr
+boole-eqv&\cr
+&\cr
+*features*&char-code-limit\cr
+array-dimension-limit&internal-time-units-per-second\cr
+array-rank-limit&lambda-parameters-limit\cr
+array-total-size-limit&multiple-values-limit\cr
+call-arguments-limit&\cr
+&\cr
+double-float-negative-epsilon&most-negative-fixnum\cr
+least-negative-double-float&most-negative-long-float\cr
+least-negative-long-float&most-negative-short-float\cr
+least-negative-short-float&most-negative-single-float\cr
+least-negative-single-float&most-positive-double-float\cr
+least-positive-double-float&most-positive-fixnum\cr
+least-positive-long-float&most-positive-long-float\cr
+least-positive-short-float&most-positive-short-float\cr
+least-positive-single-float&most-positive-single-float\cr
+long-float-negative-epsilon&short-float-negative-epsilon\cr
+most-negative-double-float&single-float-negative-epsilon\cr
+&\cr
+*load-verbose*&*random-state*\cr
+*print-array*&*read-default-float-format*\cr
+*print-pretty*&\cr
+}
+      
+%%\item{42.}        
+\item{2.} The implementation determines the defaults for the arguments
+to the keywords
+\kwd{rehash-size} and 
+\kwd{rehash-threshold} 
+for \funref{make-hash-table}.
+
+%%\item{44.} 
+\item{3.} The implementation determines the way in which a 
+\term{sequence} is initialized if an \kwd{initial-element} 
+argument is not supplied. See \funref{make-sequence}.
+The implementation determines the way in which a 
+\term{string} is initialized if an \kwd{initial-element} 
+argument is not supplied. See \funref{make-string}.
+Also, the implementation determines the way in which an
+\term{array} is initialized if \kwd{initial-element},
+\kwd{initial-contents}, or \kwd{displaced-to}
+arguments are not supplied. See \funref{make-array}.
+
+%%\item{58.} 
+%\item{4.} Valid values for the argument to
+%\funref{char-bit} and \funref{set-char-bit}
+%are \term{implementation-dependent}.
+
+\endlist
+\endsubSection%{Values}
+
+\beginsubSection{Results}
+\beginlist
+\item{1.}
+%%12.5.2 7
+An implementation may return the result of the absolute value of 
+a \term{complex} number composed of \term{integer} real
+and imaginary parts as either a \term{float} 
+or an \term{integer}. See \funref{abs}.
+
+%%\item{7.}
+\item{2.}
+An implementation determines the result returned from 
+\funref{lisp-implementation-type},
+\funref{type-of},
+ \funref{lisp-implementation-version}, and \funref{software-version}.
+
+%%\item{18.} 
+\item{3.} An implementation determines the result of \funref{digit-char}
+when more than one character object can encode the supplied weight in
+the given radix.
+
+%%\item{20.} 
+\item{4.} An implementation may determine the consequences in 
+\macref{do} and
+\macref{do*} when the index variable is changed within the iteration
+loop.
+
+%%\item{30.} 
+\item{5.}
+The result of \funref{file-position} for a character file
+is \term{implementation-dependent}.
+
+%%\item{34.} 
+\item{6.}
+An implementation determines the order of elements in the results 
+of \funref{intersection},  \funref{set-difference}, and \funref{union}
+%!!! derivatives?? gads. maybe make that a glossary word?  functions dependent
+%   on that function, i guess it means. -kmp 3-Jan-91
+and derivatives of those functions.
+\editornote{KMP: ``derivatives??'' terminology to be worked on.}
+Some element-processing aspects of sorting are \term{implementation-dependent}.
+See \funref{sort}.
+
+%%\item{36.} 
+\item{7.}  
+Whether or not \funref{length} or any sequence operation returns when given 
+a \term{circular list} is \term{implementation-dependent}.
+
+%%\item{39.} 
+\item{8.}
+The implementation determines the \term{type} of the result of \funref{log}
+(\typeref{integer} or \typeref{float}) when its arguments are both
+\term{integers} and the result is a whole number.
+ 
+%%\item{41.} 
+%\item{9.} The implementation determines the result of \funref{make-char}.
+
+%%\item{46.} 
+\item{9.} An implementation determines the result of 
+{\tt (eq (symbol-name (make-symbol x)) x)}.
+                                       
+%%\item{47.} 
+\item{10.} 
+An implementation determines the \term{type} 
+of the result of \funref{max} and \funref{min} in the following cases.
+\beginlist
+\itemitem{a.}
+If the arguments are a mixture of \term{rationals} and \term{floats}
+and the largest argument is a \term{rational}.
+\itemitem{b.} If the largest argument is a \term{float} number of a smaller format
+than the largest format of any \term{float} argument.
+\endlist
+In addition, if one or more of the arguments are equal, then any one
+of them may be chosen as the value to return.
+%%\item{62.} 
+%\issue{SPECIAL-FORM-P-MISNOMER:RENAME}
+%\item{12.} \funref{special-operator-p} can return a \term{non-nil} value,
+%the identity of which is \term{implementation-dependent}.
+%\endissue{SPECIAL-FORM-P-MISNOMER:RENAME}
+
+%%\item{63.} 
+\item{11.} If the argument to \funref{sqrt} is an \term{integer},
+the result may be either an \term{integer} or a \term{float} depending on the
+\term{implementation}.  Also, if the argument to \funref{sqrt}
+is a negative \term{integer}, the result may be either
+a \term{complex} with \term{integer} components or
+a \term{complex} with \term{float} components.
+
+%%\item{64.} 
+\item{12.} If no characters in the argument to \funref{string-trim},
+\funref{string-left-trim}, \funref{string-right-trim}, 
+\funref{string-upcase}, \funref{string-downcase}, and
+\funref{string-capitalize} need to be changed, then the implementation can
+either return the argument itself or a copy of it.
+This is true for all destructive \term{sequence functions}.
+
+%%\item{71.} 
+\item{13.} When the arguments to the mathematical \term{functions}
+in \thenextfigure\ are all \term{rational} and the true mathematical result
+is also (mathematically) rational, then unless otherwise noted
+an implementation is free to return either an accurate result \oftype{rational}
+or a \term{single float} approximation.
+If the arguments are all \term{rational} 
+but the result cannot be expressed
+as a \term{rational} number, then a \term{single float} 
+approximation is always returned.
+
+\displaythree{Irrational and transcendental functions}{
+abs&cis&phase\cr
+acos&cos&signum\cr
+acosh&cosh&sin\cr
+asin&exp&sinh\cr
+asinh&expt&sqrt\cr
+atan&isqrt&tan\cr
+atanh&log&tanh\cr
+}
+
+\endlist
+\endsubSection%{Results}
+
+
+\beginsubSection{Data Representation and Typing}
+\beginlist
+%%\item{5.}
+\item{1.}
+An implementation determines the representation of a byte specifier.
+
+%%\item{9.}
+\item{2.}
+Type upgrading may occur when \funref{coerce} is used.
+%\Seesection\TypeUpgrading.
+%%\item{27.} 
+\item{3.} An implementation determines the structure of the 
+\term{environment}
+object.     
+%%\item{75.} 
+%\item{4.} The existence of 
+%\term{types} that are not \term{subtypes} of \typeref{common}
+%is \term{implementation-dependent}.
+
+\item{4.} Whether or not \thetypes{short-float}, \typeref{long-float},
+\typeref{single-float}, and \typeref{double-float} are
+\term{disjoint} is \term{implementation-dependent}.
+%!!! But subject to certain constraints, no? -kmp 9-May-91
+%\Seesection\TypeUpgrading.
+
+\endlist
+\endsubSection%{Data Representation and Typing}
+
+\beginsubSection{Program and Control Structure}
+\beginlist
+
+%%\item{13.}
+%\item{1.}
+%An implementation 
+%might or might not check for any dynamic \term{bindings}
+%of the first argument to \macref{defconstant} at the time 
+%\macref{defconstant} is executed.
+
+
+
+%%\item{14.}
+\item{1.}
+An implementation determines the way that \macref{defmacro}
+actually installs a macro function.
+
+%%\item{15.}
+\item{2.}
+An implementation determines the code generated by \macref{defsetf}.
+
+%%\item{16.}
+\item{3.}
+The following are \term{implementation-dependent} features of \macref{defstruct}:
+\beginlist
+\itemitem{a.} The initial contents of a slot, when they have not been provided,
+are specified by the implementation.
+\itemitem{b.} The \term{access} \term{functions} may be declared \declref{inline}.
+\itemitem{c.} The incorrect use of \term{access} \term{functions} might or might not be checked
+by an implementation.
+\itemitem{d.} %For included slots, 
+An implementation might or might not enforce the declared \term{type} information
+for a slot.
+%!!! Is this still true under CLOS?? -kmp 9-May-91
+\itemitem{e.} If the \kwd{type} option is not supplied,
+the implementation determines the representation of the \term{structure}. 
+%%(see clean-up issue)
+\endlist
+
+%%\item{35.} 
+\item{4.} The permissibility of non-standard lambda-list
+keywords is \term{implementation-dependent}.
+
+%%\item{40.} 
+\item{5.} 
+An implementation is free to implement as a \term{special operator}
+any \term{operator} described in this standard as a \term{macro},
+if an equivalent macro definition is also provided.
+See \funref{macro-function}.
+
+%%\item{60.} 
+\item{6.} 
+The exact expansion for any particular form given to \macref{setf} 
+may be \term{implementation-dependent}.
+
+%%\item{76.} 
+\item{7.} The internal representation of 
+a backquoted \term{form} is \term{implementation-dependent}.
+
+\endlist
+\endsubSection%{Program and Control Structure}
+
+\beginsubSection{Comparisons}
+%\beginlist
+%%\item{6.}
+%\item{1.}
+%An implementation determines the way font information is compared in the
+%functions \funref{char-equal}, 
+%\funref{char-not-equal}, \funref{char-lessp}, 
+%\funref{char-greaterp},
+%\funref{char-not-greaterp}, and \funref{char-not-lessp}. Where not
+%specified by this standard, the ordering of 
+%characters is \term{implementation-dependent}.
+%\endlist
+\endsubSection%{Comparisons}
+
+
+
+
+\beginsubSection{Numerical Calculations}
+\beginlist
+%%\item{8.} 
+\item{1.} 
+  \funref{minusp}, \funref{eql}, \funref{float-sign}, and \funref{zerop}
+  are affected by the presence of {\tt $-0.0$} in an implementation.
+
+%%\item{24.} 
+\item{2.}
+  Whether or not two \term{numbers} or \term{characters}
+  that are \funref{eql} are \funref{eq} depends on the implementation.
+
+%%%\item{29.} 
+%\item{3.} An implementation may use different algorithms
+%for the cases of a \term{rational} second 
+%argument and a \term{float}
+%second argument to \funref{expt}.
+
+%%\item{55.} 
+\item{3.} Random number generation is \term{implementation-dependent}.
+
+
+%%\item{70.} 
+\item{4.} For the \term{operators} in \thenextfigure,
+an implementation may process the arguments in any manner consistent
+with associative (and possibly commutative) rearrangement.
+
+\displaythree{Mathematically associative operators}{
+*&boole&lognand\cr
++&gcd&lognor\cr
+/=&lcm&logorc1\cr
+<&logand&logorc2\cr
+<=&logandc1&logxor\cr
+=&logandc2&max\cr
+>&logeqv&min\cr
+>=&logior&\cr
+}
+
+Implementations may differ in 
+which automatic coercions are applied because of differing
+orders of argument processing. 
+
+%%\item{72.} 
+\item{5.} 
+The precise definitions of \typeref{short-float},
+\typeref{long-float}, \typeref{single-float}, and 
+\typeref{double-float} are \term{implementation-dependent}
+(but subject to certain constraints imposed by this specification).
+
+\endlist
+\endsubSection%{Numerical Calculations}
+
+
+\beginsubSection{User Interface}
+\beginlist
+%%\item{.}
+\item{1.}
+\Thenextfigure\ shows the names of \term{operators} which have
+an \term{implementation-dependent} user interface.
+
+\displaythree{Operators with Implementation-Dependent User Interfaces}{
+break&ctypecase&step\cr
+ccase&describe&warn\cr
+ccase&disassemble&y-or-n-p\cr
+cerror&error&yes-or-no-p\cr
+check-type&inspect&\cr
+}
+%I removed "Anything that uses CERROR" as unnecessary. In general you don't
+%know what really uses CERROR and what doesn't anyway. -kmp 13-Feb-91
+
+\endlist
+\endsubSection%{User Interface}
+
+
+\beginsubSection{Input/Output}
+\beginlist
+
+%%\item{17.} 
+\item{1.} An implementation determines whether an attempt by 
+\funref{delete-file} to delete a non-existent file is considered to be successful.
+
+%%\item{19.} 
+\item{2.} An implementation may define keywords to be used with
+\funref{directory}.
+
+%%\item{31.} 
+\item{3.} An implementation determines the precise actions of
+\funref{finish-output}, \funref{clear-output}, and
+\funref{force-output}. 
+
+%%\item{31a.} 
+\item{4.} \term{Streams} 
+may be implemented in an asynchronous or buffered manner.
+
+%%\item{32.} 
+\item{5.} \funref{format} has the following \term{implementation-defined}
+features:
+\beginlist
+%% CLean-up item on this
+\itemitem{a.} \f{~C} prints a character in an \term{implementation-dependent}
+abbreviated format.  
+
+\itemitem{b.} The precise output for \f{~:@C} depends 
+on the implementation.
+\itemitem{c.} When rounding up and rounding down would produce printed values
+equidistant from the scaled value of the argument, then the implementation
+is free to use either one.  
+\itemitem{d.} For the \f{~\$} operation, if the magnitude of the argument is so large or small 
+that more than 100 digits would have to
+be printed, then an implementation is free, at its discretion, to print
+the number using exponential notation.
+\itemitem{e.} For the \f{~\$} operation, if 
+the argument is a \term{rational} number, 
+then it is coerced to be a \term{single float}
+or processed by any other method that has essentially the
+same behavior. 
+Only a finite number of digits may be printed.
+\itemitem{f.} The range of numbers and the font of the printed output
+for the \f{~R} operation are \term{implementation-dependent}. 
+The English words printed as a result of the \f{~R} operation are
+\term{implementation-dependent}. 
+\endlist
+%%\item{37.} 
+\item{6.} The means by which a text (character file) 
+is distinguished from an object (binary) file by \funref{load} is
+\term{implementation-dependent}. 
+
+%%\item{38.} 
+\item{7.} The selection by \funref{load} of a file type when there
+is a choice is \term{implementation-dependent}.
+
+%%\item{43.} 
+\item{8.} The implementation determines the internal representation
+of a \term{pathname}. See \funref{make-pathname}.
+
+%%\item{48.} 
+\item{9.} The following aspects of \funref{open}
+are \term{implementation-dependent}:
+\beginlist
+\itemitem{a.} The meaning of the keyword \kwd{supersede}.
+%\itemitem{b.} An implementation is required to recognize all of 
+%the following \kwd{if-exists} keywords
+%and to do something reasonable in the context of the host operating
+%system:
+%\kwd{error},
+%\kwd{new-version},
+%\kwd{rename},
+%\kwd{rename-and-delete},
+%\kwd{overwrite},
+%\kwd{append},
+%\kwd{supersede}, or
+%\nil.       
+
+\itemitem{b.} If it is impossible for an implementation to handle some option
+in a manner close to what is specified in this manual, an error may be
+signaled.
+\endlist                                             
+
+%%\item{50.} 
+\item{10.} \funref{parse-namestring}
+might or might not signal an error if
+the representation of a \term{pathname} 
+is surrounded on either side by
+\term{whitespace}\meaning{1} characters, depending on the \term{implementation}.
+Whether or not \funref{parse-namestring} supplies 
+the
+standard default device as the device component
+of the resulting \term{pathname} depends on the implementation.
+
+%%\item{51.} 
+\item{11.} The \term{pathname} namestring
+syntax is \term{implementation-dependent}.
+The printed representation of a pathname
+typically designates \kwd{wild} by an asterisk; however, this is
+\term{implementation-dependent}.    
+
+%%\item{52.} 
+\item{12.} A \term{character} name or a \term{pathname} that is printed
+is acceptable as input in only the implementation which typed it.  
+Which names for characters are chosen to print is
+\term{implementation-dependent}, although standard names are
+chosen over non-standard names. See \funref{write}.
+        
+%%\item{53.} 
+%\item{13.} The printed representation of a
+%\term{random state} \term{object} is \term{implementation-dependent}.
+
+%%\item{54.} 
+\item{13.} \term{Objects} which do not have a specific syntax
+specified in this manual are printed in an \term{implementation-dependent} manner.  
+
+%%\item{68.} 
+\item{14.} The \param{host} argument to \funref{user-homedir-pathname}
+defaults in an \term{implementation-dependent} manner.
+
+%% Following two are affected by the character set proposal.
+%%\item{77.} 
+\item{15.} Whether the following 
+character names are supported is \term{implementation-dependent}:
+\f{rubout}, \f{page}, \f{tab}, \f{backspace}, \f{return}, and \f{linefeed}.
+%%\item{78.} 
+%\item{17.} Whether 
+%characters with non-zero \param{bits} and \param{font} \term{attributes}
+%syntax
+%descriptions are in the \term{readtable} is \term{implementation-dependent}.
+
+\endlist
+\endsubSection%{Input/Output}
+                           
+
+\beginsubSection{Compiling}
+\beginlist
+%%\item{10.}
+\item{1.}
+An implementation determines the following for \funref{compile-file}:
+\beginlist
+\itemitem{a.} The contents of the file created by \funref{compile-file}.
+\itemitem{b.} The file 
+specification (if one is not supplied)
+for the file created by \funref{compile-file}.
+\endlist
+%%\item{12.}
+\item{2.}
+An implementation's compiler can ignore declaration specifiers
+except for \declref{declaration}, \declref{special}, and \declref{notinline}.
+
+%%\item{25.} 
+\item{3.} An implementation may coalesce constants or portions of constants
+in code to be compiled if they appear to be \funref{eq}
+or \funref{eql} and are \funref{equal}.
+\Seesection\Compilation.
+
+\endlist
+\endsubSection%{Compiling}
+
+
+\beginsubSection{Miscellaneous}
+\beginlist
+%%\item{4.}
+\item{1.}
+An implementation determines the specifics of the
+debugger that \funref{break} enters.
+
+%%\item{74.} 
+\item{2.} Although functions that manipulate \term{packages}
+generally signal
+name conflict errors before making any change to the package structure, an
+implementation may \funref{export} 
+each of a given list of \term{symbols} separately.
+
+%%\item{49.} 
+%\item{3.} The contents of \thepackage{system} are determined by
+%the implementation.
+
+%%\item{57.} 
+\item{3.} 
+ The frequency of execution of \param{test} and \param{key}
+ functions for all \term{sequence functions} is \term{implementation-dependent}. 
+ The implementation of \funref{search} may choose to search the \term{sequence} 
+ in any order.
+\reviewer{Is the order of other things specified??}
+
+%%\item{65.} 
+\item{4.} The manner in which a 
+hash code is computed by \funref{sxhash}
+is \term{implementation-dependent}. 
+
+%% clean-up pending for this
+%%\item{69.} 
+\item{5.} The optional argument \param{extension}
+for \funref{vector-push-extend}
+defaults to a ``reasonable'' \term{implementation-dependent}
+value.
+
+%%\item{73.} 
+\item{6.} A \term{symbol}'s \term{property list} may have defined components.
+
+%%\item{11.}
+\item{7.}
+An implementation can define declaration specifiers other than the ones
+given in the description of \misc{declare}.
+
+\endlist
+\endsubSection%{Miscellaneous}
+
+
+\beginsubSection{Programming Environment}
+\beginlist
+%%\item{22.} 
+\item{1.} An implementation might or might not provide a resident editor.
+See \funref{ed}.
+
+%%\item{23.} 
+\item{2.} An implementation determines the means by which
+function text is obtained when \f{(ed \i{symbol})} is invoked.
+
+%%\item{33.} 
+\item{3.} An implementation determines the units used in representing
+Internal Time.
+See \funref{get-internal-run-time}.
+
+%%\item{56.} 
+\item{4.} The information \funref{room} prints is
+\term{implementation-dependent}.  
+%%\item{66.} 
+\item{5.} The nature and
+format of the information printed by \funref{time} 
+is \term{implementation-dependent}.  
+           
+%%\item{67.} 
+\item{6.} The following are implementation dependencies of
+tracing.
+\beginlist
+\itemitem{a.} \macref{trace} and \macref{untrace} may accept 
+\term{implementation-dependent} argument formats.  
+\itemitem{b.} The format of the \macref{trace}
+output is \term{implementation-dependent}.
+\endlist        
+\endlist        
+\endsubSection%{Programming Environment}
+

appendix-portability.tex

@@ -0,0 +1,48 @@
+% -*- Mode: TeX -*-
+%%Portability Issues
+
+Following is a list of situations which are known to cause portability
+problems between \term{implementations}:
+
+\beginlist                                           
+%% 5.1.4 3
+\item{\bull}
+  \term{Macros} provided by an implementation might expand
+  into code that is not portable among differing \term{implementations}.
+\item{\bull} 
+  The precision and range of \term{floats} might vary between \term{implementations}.
+\item{\bull}
+  Sizes of \term{numbers} might vary between \term{implementations}.
+  \Seesection\ImplemDefFeatures.
+\item{\bull}
+  \term{Implementations} might support additional pre-defined \term{condition} types.
+\item{\bull}
+  \term{Implementations} might support additional \term{type specifiers}.
+\item{\bull}
+  \term{Implementations} might vary with respect to their treatment of
+  \term{pathnames}, the native syntax of file names, 
+  and the determination of the actual files present.
+\item{\bull}
+  \term{Implementations} might vary with respect to the the capabilities
+  and power of their file system operations.
+\item{\bull}
+  \term{Implementations} might differ in their treatment of \term{packages}.
+\item{\bull}
+  The {\tt #+}, {\tt #-} notations institute deliberate non-portability.
+%\item{\bull}
+%  \term{implementations} may extend the syntax for some  
+%  \term{macros} and \term{special forms} (\eg \specref{if}).
+\item{\bull} 
+  \term{Implementations} might extend the number of arguments for some
+  \term{functions} (\eg non-standard \funref{open} keywords).
+\item{\bull}
+  \term{Implementations} might extend the functionality of certain \term{operators}
+  by permitting arguments not required by the standard 
+  (\eg a \term{pathname} as an \term{argument} to \funref{string} 
+   or a \term{string} as a second \term{argument} to \term{intern}).
+\item{\bull}
+  \term{Implementations} might extend \funref{format} operations.
+\item{\bull} 
+  \term{Implementations} may vary with respect to how they handle aspects of
+  terminal input/output such as buffering and input editing.
+\endlist

appendix-removed.tex

@@ -0,0 +1,121 @@
+% -*- Mode: TeX -*-
+
+\beginsubSection{Requirements for removed and deprecated features}
+
+%% Removed defined names
+\issue{DEPRECATION-POSITION:LIMITED}
+For this standard,
+    some features from the language described in \CLtL\ have been removed,
+and others have been deprecated (and will most likely not appear
+in future \clisp\ standards).
+Which features were removed and which were deprecated
+was decided on a case-by-case basis by the X3J13 committee.
+ 
+\term{Conforming implementations} that wish to retain any removed 
+features for compatibility must assure that such compatibility 
+does not interfere with the correct function of \term{conforming programs}.
+For example, symbols corresponding to the names of removed functions
+may not appear in the \thepackage{common-lisp}.
+(Note, however, that this specification has been devised in such a way 
+that there can be a package named \f{LISP} which can contain such symbols.)
+
+\term{Conforming implementations} must implement all deprecated features.
+For a list of deprecated features, \seesection\DeprecatedFeatures.
+\endissue{DEPRECATION-POSITION:LIMITED}
+
+\endsubSection%{Requirements for removed and deprecated features}
+
+\beginsubsection{Removed Types}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+The \term{type} \f{string-char}\idxcode{string-char} was removed.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\endsubsection%{Removed Types}
+
+\beginsubsection{Removed Operators}
+
+The functions
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\f{int-char}\idxcode{int-char},
+\f{char-bits}\idxcode{char-bits},
+\f{char-font}\idxcode{char-font},
+\f{make-char}\idxcode{make-char},
+\f{char-bit}\idxcode{char-bit},
+\f{set-char-bit}\idxcode{set-char-bit},
+\f{string-char-p}\idxcode{string-char-p},
+\endissue{CHARACTER-PROPOSAL:2-1-1}%
+\issue{COMMON-TYPE:REMOVE}
+and
+\f{commonp}\idxcode{commonp}
+\endissue{COMMON-TYPE:REMOVE}%
+\issue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+\issue{REQUIRE-PATHNAME-DEFAULTS:ELIMINATE}
+%\f{provide},
+%and \f{require} 
+\endissue{REQUIRE-PATHNAME-DEFAULTS:ELIMINATE}%
+\endissue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+were removed.
+
+\issue{COMPILER-LET-CONFUSION:ELIMINATE}
+The \term{special operator} \f{compiler-let} was removed.
+\endissue{COMPILER-LET-CONFUSION:ELIMINATE}
+
+\endsubsection%{Removed Operators}
+
+\beginsubsection{Removed Argument Conventions}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+The \param{font} argument to \funref{digit-char}\idxref{digit-char} was removed.
+The \param{bits} and \param{font} arguments to \funref{code-char}\idxref{code-char} 
+were removed.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\issue{REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT}
+\issue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+%The \param{pathname} argument to \funref{require}\idxref{require} was removed.
+\endissue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+\endissue{REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT}
+
+\endsubSection%{Removed Argument Conventions}
+
+\beginsubsection{Removed Variables}
+
+The variables
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\f{char-font-limit}\idxcode{char-font-limit},
+\f{char-bits-limit}\idxcode{char-bits-limit},
+\f{char-control-bit}\idxcode{char-control-bit},
+\f{char-meta-bit}\idxcode{char-meta-bit},
+\f{char-super-bit}\idxcode{char-super-bit},
+\f{char-hyper-bit}\idxcode{char-hyper-bit},
+\endissue{CHARACTER-PROPOSAL:2-1-1}%
+\issue{BREAK-ON-WARNINGS-OBSOLETE:REMOVE}
+and \f{*break-on-warnings*}\idxcode{*break-on-warnings*}
+\endissue{BREAK-ON-WARNINGS-OBSOLETE:REMOVE}
+\issue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+%and
+\issue{REQUIRE-PATHNAME-DEFAULTS:ELIMINATE}
+%\f{*modules*}
+\endissue{REQUIRE-PATHNAME-DEFAULTS:ELIMINATE}
+\endissue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+were removed.
+
+\endsubsection%{Removed Variables}
+
+\beginsubsection{Removed Reader Syntax}
+
+The ``\f{\#,}'' \term{reader macro} in \term{standard syntax} was removed.
+
+\endsubsection%{Removed Reader Syntax}
+
+\beginsubsection{Packages No Longer Required}
+
+The \term{packages} 
+     \packref{lisp}\idxpackref{lisp},
+     \packref{user}\idxpackref{user},
+ and \packref{system}\idxpackref{system}
+are no longer required.  It is valid for \term{packages} with one or more of these
+names to be provided by a \term{conforming implementation} as extensions.
+
+\endsubsection%{Packages No Longer Required}

chap-0-edit-history.tex

@@ -0,0 +1,374 @@
+% -*- Mode: TeX -*-
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\quad&#\hfil\quad&#\hfil\cr
+Principal Technical Editors:\cr
+\noalign{\vskip 8pt}
+\b{Kent M. Pitman}     & Harlequin, Inc. 	       & 1993-present \cr
+		       & Symbolics, Inc. 	       & 1990-1992    \cr
+\b{Kathy Chapman}      & Digital Equipment Corporation & 1987-1989    \cr
+\noalign{\vskip 8pt}
+Occasional Guest Editors:\cr
+\noalign{\vskip 8pt}
+\b{Richard P. Gabriel} & Lucid, Inc.\cr
+\b{Sandra Loosemore}   & self\cr
+}
+$$
+
+\goodbreak
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\cr
+Financial Contributors to the Editing Process:\cr
+\noalign{\vskip 8pt}
+\b{Digital Equipment Corporation}\cr
+\b{Harlequin, Ltd.} and \b{Harlequin, Inc.}\cr
+\b{Symbolics, Inc.}\cr
+\b{Apple, Inc.}\cr
+\b{Franz, Inc.}\cr
+\b{Lucid, Inc.}\cr}
+$$
+
+\goodbreak
+
+Special thanks to Guy L. Steele Jr. and Digital Press for producing {\CLtL},
+and for relaxing copyright restrictions enough to make it possible for that
+document's text to provide an early basis of this work.
+
+\vfill\eject
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\quad&#\hfil\quad&#\hfil\cr
+Edit and Review History:\span\span\cr
+\noalign{\vskip 8pt}
+ 01-Jan-89 & Chapman   & Draft of Chapters 1.1 (scope).\cr
+ 01-Jan-89 & Pitman    & Draft of Chapters 5.1 (conditions).\cr
+ 01-May-89 & Chapman   & Draft of 1.2--1.6. \cr
+ 01-May-89 & Gabriel   & Rewrite of Chapters 1.1 and 5.1.\cr
+ 01-Jun-89 & Loosemore & Review of Chapter 4.2. \cr
+ 01-Jun-89 & Pitman    & Review of Glossary \cr
+ 15-Jun-89 & Gabriel   & Rewrite of Glossary \cr
+ 16-Jun-89 & Margolin  & Comments on Chapters 2.1--2.4 (types, objects).\cr
+ 23-Jun-89 & Gabriel   & Rewrite of 4.2. \cr
+ 07-Jul-89 & Moon      & Review of Chapters 4.1, 4.3 \cr
+ 12-Jul-89 & Gabriel   & Revision of 4.2. \cr
+ 15-Jul-89 & Pitman    & Review of Glossary \cr
+ 18-Jul-89 & Gray      & Comments on 5.1 \cr
+ 25-Jul-89 & Gabriel   & Revision of Chapters 1.2--1.6, 2.2\cr
+ 26-Jul-89 & Gabriel   & Rewrite of 5.1 \cr
+ 26-Jul-89 & Gabriel   & Rewrite of 4.1. \cr
+ 27-Jul-89 & Pitman    & Revision of 5.1 \cr
+ 27-Jul-89 & Gabriel   & Revision of 5.1 \cr
+ 28-Jul-89 & Chapman   & Draft of 2.2, 3.2, 3.3, 5.4 \cr
+ 28-Jul-89 & Gabriel   & Revision of Glossary.\cr
+ 01-Oct-89 & Margolin  & Review of Dictionary from Jun-89 draft.\cr
+ 20-Jan-91 & Pitman    & Draft 8.81 (for X3J13 review). Document X3J13/91-101.\cr
+ 29-Jan-91 & Waters    & Review of 8.81/Chapter 23 (Printer).\cr
+ 01-Mar-91 & Moon      & Review of 8.81/Chapter 4 (Evaluation and Compilation).\cr
+ 01-Mar-91 & Barrett   & Review of 8.81/Chapter 4 (Evaluation and Compilation).\cr
+ 01-Mar-91 & Moon      & Review of 8.81/Glossary.\cr
+ 13-Mar-90 & Wechsler  & Review of 8.81/Glossary.\cr
+ 21-Mar-91 & Kerns     & Review of 8.81/Chapter 1.\cr
+ 26-Apr-91 & Margolin  & Review of 8.81/Chapters 1--12.\cr
+ 15-May-91 & Barrett   & Review of 8.81/Chapters 5 (Misc), 11 (Conditions).\cr
+ 04-Jun-91 & Laddaga   & Review of 9.60/Chapter 20 (Pathnames).\cr
+ 10-Jun-91 & Pitman    & Draft 9.126 (for X3J13 review). Document X3J13/91-102.\cr
+ 02-Sep-91 & Barrett   & Review of 9.28/Chapter 4 (Evaluation and Compilation).\cr
+ 02-Sep-91 & Barrett   & Review of 9.52/Chapter 4 (Evaluation and Compilation).\cr
+ 15-Sep-91 & Barrett   & Review of 9.126/Chapter 4 (Evaluation and Compilation)\cr
+	   &	       & \quad and Chapter 7 (Evaluation/Compilation).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 18-Sep-91 & Wechsler  & Review of 9.126.\cr
+ 21-Sep-91 & Barrett   & Review of 10.16/Chapter 7 (Evaluation/Compilation).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 28-Sep-91 & Barrett   & Review of 10.95/Chapter 25 (Printer).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 13-Oct-91 & Barrett   & Review (and help editing) of 10.104/Chapter 4\cr
+ 	   &	       & \quad(Evaluation and Compilation)\cr
+ 15-Oct-91 & Waters    & Review of 10.95/Chapter 25 (Printer).\cr
+ 24-Oct-91 & Pitman    & Draft 10.156 (for X3J13 review). Document X3J13/91-103.\cr
+ 04-Nov-91 & Moon      & Review of 10.156/Chapter 5 (Data and Control Flow)\cr
+	   &	       & \quad and Chapter 26 (Glossary).\cr
+ 11-Nov-91 & Loosemore & Review of 10.156/Chapter 2 (Syntax),\cr
+	   &	       & \quad Chapter 3 (Evaluation and Compilation),\cr
+	   &	       & \quad Chapter 5 (Data and Control Flow), 
+			       and Chapter 8 (Structures).\cr
+ 02-Dec-91 & Barrett   & Review of 10.156/Chapter 4 (Types and Classes),\cr
+	   &	       & \quad and Chapter 10 (Symbols).\cr
+ 02-Dec-91 & Barrett   & Review of 10.156/Chapter 3 (Evaluation and Compilation),\cr
+	   &	       & \quad Chapter 6 (Iteration), Chapter 9 (Conditions),\cr
+	   &           & \quad and Chapter 14 (Conses).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 09-Dec-91 & Gabriel   & Review of 10.156/Chapter 1 (Introduction),\cr
+           &           & \quad Chapter 2 (Syntax), 
+			   and Chapter 3 (Evaluation and Compilation).\cr
+ 09-Dec-91 & Ida       & Light review of 10.156/Chapters 1-5.\cr
+ 09-Dec-91 & Moon      & Review of 10.156/Chapter 3 (Evaluation and Compilation).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 10-Dec-91 & Loosemore & Review of 10.156/Chapter 10 (Symbols),\cr
+           &           & \quad Chapter 20 (Files), and Chapter 13 (Characters).\cr
+ 10-Dec-91 & Loosemore & Review of 10.156/Chapter 14 (Conses).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 10-Dec-91 & Laubsch   & Review of 10.156/Chapters 1 (Introduction),\cr
+	   &	       & \quad Chapter 2 (Syntax), Chapter 3 (Evaluation and Compilation),\cr
+	   &	       & \quad Chapter 4 (Types and Classes), 
+			       Chapter 5 (Data and Control Flow), \cr
+	   &	       & \quad Chapter 7 (Objects), Chapter 11 (Packages),\cr
+	   &	       & \quad Chapter 19 (Filenames), and Chapter 21 (Streams).\cr
+ 18-Dec-91 & Margolin  & Review of 10.156/Chapter 18 (Hash Tables).\cr
+ 04-Jan-92 & White     & Review of 10.156/Chapter 6 (Iteration),\cr
+	   &	       & \quad Chapter 11 (Packages), Chapter 18 (Hash Tables),\cr
+	   &	       & \quad and Chapter 23 (Reader).\cr
+ 04-Jan-92 & White     & Review of 10.156/Chapter 26 (Glossary).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 04-Jan-92 & Barrett   & Review of 10.156/Chapter 18 (Hash Tables) and Chapter 16 (Strings).\cr
+ 04-Jan-92 & Barrett   & Review of 10.156/Chapter 15 (Arrays) and Chapter 21 (Streams).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 06-Jan-92 & Loosemore & Review of 10.156/Chapter 16 (Strings),\cr
+	   &           & \quad Chapter 17 (Sequences), and Chapter 25 (Environment).\cr
+ 06-Jan-92 & Loosemore & Review of 10.156/Chapter 21 (Streams) and Chapter 23 (Reader).\cr
+	   &	       & \quad(some comments not yet merged)\cr
+ 06-Jan-92 & Margolin  & Review of 10.156/Chapter 2 (Syntax).\cr
+ 07-Jan-92 & Margolin  & Review of 10.156/Chapter 4 (Types and Classes).\cr
+ 03-Feb-92 & Aspinall  & Review of 10.156/Chapter 12 (Numbers).\cr
+ 16-Feb-92 & Pitman    & Draft 11.82 (for X3J13 letter ballot). Document X3J13/92-101.\cr
+ 16-Mar-92 & Loosemore & Review of 11.82/Chapter 1, 3, 4, 5, 7, 8, 9, 10,\cr
+	   &	       & \quad 11, 12, 18, 22, 23, 24, 25, and 26.\cr
+ 16-Feb-92 & Pitman    & Draft 12.24 (for X3 consideration). Document X3J13/92-102.\cr
+ 09-Sep-92 & Samson    & Public Review Comments (\#1). Documents X3J13/92-1001 to 92-1003.\cr
+ 22-Oct-92 & Rose, Yen & Public Review Comments (\#2). Documents X3J13/92-1101 to 92-1103.\cr
+ 23-Oct-92 & Staley    & Public Review Comments (\#3). Documents X3J13/92-1201 to 92-1204.\cr
+ 09-Nov-92 & Barrett   & Public Review Comments (\#4). Documents X3J13/92-3101 to 92-3110.\cr
+ 11-Nov-92 & Moon      & Public Review Comments (\#5). Documents X3J13/92-3201 to 92-3248.\cr
+ 17-Nov-92 & Loosemore & Public Review Comments (\#6). Documents X3J13/92-1301 to 92-1335.\cr
+ 23-Nov-92 & Margolin  & Public Review Comments (\#7). Documents X3J13/92-1401 to 92-1419.\cr
+ 23-Nov-92 & Withington & Public Review Comments (\#8a). Documents X3J13/92-1501 to 92-1512.\cr\cr
+ 23-Nov-92 & Feinberg   & Public Review Comments (\#8b). Documents X3J13/92-1601 to 92-1603.\cr
+ 23-Nov-92 & Wechsler   & Public Review Comments (\#8c). Documents X3J13/92-1701 to 92-1703.\cr
+ 23-Nov-92 & Moore     & Public Review Comments (\#9). Documents X3J13/92-1801 to 92-1802.\cr
+ 23-Nov-92 & Flanagan  & Public Review Comments (\#10). Documents X3J13/92-1901 to 92-1910.\cr
+ 23-Nov-92 & Dalton    & Public Review Comments (\#11). Documents X3J13/92-2001 to 92-2012.\cr
+ 23-Nov-92 & Gallagher & Public Review Comments (\#12). Documents X3J13/92-2101 to 92-2103.\cr
+ 23-Nov-92 & Norvig    & Public Review Comments (\#13). Documents X3J13/92-2201 to 92-2208.\cr
+ 24-Nov-92 & Robertson & Public Review Comments (\#14). Document X3J13/92-2301.\cr
+ 23-Nov-92 & Kawabe    & Public Review Comments (\#15). Documents X3J13/92-2401 to 92-2403.\cr
+ 23-Nov-92 & Barrett   & Public Review Comments (\#16). Documents X3J13/92-2511 to X3J13/92-2531.\cr
+ 23-Nov-92 & Wertheimer & Public Review Comments (\#17). Document X3J13/92-2601.\cr
+ 24-Nov-92 & Pitman    & Public Review Comments (\#18). Documents X3J13/92-2701 to 92-2742.\cr
+ 24-Nov-92 & Mato Mira & Public Review Comments (\#19). Documents X3J13/92-2801 to 92-2805.\cr
+ 24-Nov-92 & Philpot   & Public Review Comments (\#20). Document X3J13/92-2901.\cr
+ 23-Nov-92 & Cerys     & Public Review Comments (\#21). Document X3J13/92-3001.\cr
+ 30-Aug-93 & Pitman    & Draft 13.65 (for X3J13 consideration). Document X3J13/93-101.\cr
+ 04-Oct-93 & X3J13     & Minor fixes to Draft 13.65 before sending to X3.\cr
+ 05-Oct-93 & Pitman    & Draft 14.10 (for X3 consideration). Document X3J13/93-102.\cr
+ 08-Nov-93 & Dalton    & ``reply to reply to pr comments''.  Document X3J13/94-311.\cr
+ 04-Apr-94 & Boyer,    & \cr
+           & Kaufmann, & \cr
+           & Moore     & Public Review Comments (\#1).  Document X3J13/94-305.\cr
+ 05-Apr-94 & Pitman    & Public Review Comments (\#2).  Document X3J13/94-306.\cr
+ 14-Mar-94 & Schulenburg & Public Review Comments (\#3).  Document X3J13/94-307.\cr
+ 04-Apr-94 & Shepard   & Late commentary.  Document X3J13/94-309.\cr
+ 05-May-94 & X3J13     & Editorial-only changes to Draft 14.10 in response to comments.\cr
+ 10-May-94 & Pitman    & Draft {\rev} (for X3 consideration). Document {\DocumentNumber}.\cr
+} $$
+
+\vfill\eject
+
+\goodbreak
+
+The following lists of information are almost certainly incomplete, but
+it was felt that it was better to risk publishing incomplete information
+than to fail to acknowledge important contributions by the many people
+and organizations who have contributed to this effort.
+
+Mention here of any individual or organization does not imply
+endorsement of this document by that individual or organization.
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\quad&#\hfil\cr
+%Committee Chairs:&\cr
+Ad Hoc Group Chairs:&\cr
+\noalign{\vskip 8pt}
+  Characters                & Linden, Thom        \cr
+  Charter                   & Ennis, Susan P.     \cr
+  Cleanup                   & Masinter, Larry     \cr
+                            & Fahlman, Scott      \cr
+  Compiler                  & Haflich, Steve      \cr
+                            & Loosemore, Sandra   \cr
+  Conditions                & Pitman, Kent M.     \cr
+%% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+%                           & Daniels, Andy       \cr
+  Editorial                 & Chapman, Kathy      \cr
+%% Added per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+  Graphics \& Windows       & Douglas Rand        \cr
+  Iteration                 & White, JonL         \cr
+%% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+%                           & Waters, Richard C.  \cr
+%                           & Perdue, Crispin     \cr
+  Lisp$\sub1$/Lisp$\sub2$   & Gabriel, Richard P. \cr
+%% Removed per X3J13 at May 4-5, 1994 meeting. -kmp 9-May-94
+%                           & Pitman, Kent M.     \cr
+  Macros                    & Haflich, Steve      \cr
+                            & Pitman, Kent M.     \cr
+  Objects                   & Bobrow, Daniel G.   \cr
+  Presentation of Standard  & Brown, Gary         \cr
+  Pretty Printer            & Waters, Richard C.  \cr
+  Public Review             & Ida, Masayuki       \cr
+  Types \& Declarations     & Scherlis, William   \cr
+  Validation                & Berman, Richard     \cr
+			    & Balzer, Bob	  \cr
+}
+$$
+
+\goodbreak
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\quad&#\hfil\cr
+Major Administrative Contributions:\cr
+\noalign{\vskip 8pt}
+%% Added "Loeffler" and "Tyson" per Pitman #3 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+Mathis, Robert&               % Convenor; Chairman; Interfacing to X3, etc.
+Brown, Gary\cr                % Secretary, Funding administration for DEC's editorship
+Steele, Guy L., Jr.&          % Interfacing to X3, etc.; Vice-Chairman; Roberts Rules expert 
+Eiron, Hanoch\cr              % Funding administration for Franz, Help finding other funding
+Zubkoff, Jan L.&  	      % Meeting organization, Secretary, Funding administration for Lucid
+Haflich, Steve\cr             % Establishment of second-generation CL Editorship
+Gabriel, Richard P.&          % Interfacing to ISO, etc.
+Ida, Masayuki\cr	      % International Liaison to Japan
+Masinter, Larry&              % Administration of Cleanup, agenda setting
+Loeffler, David D.\cr	      % Mailing lists at MCC
+Loosemore, Sandra&            % Administration of Cleanup & Compiler, agenda setting
+Tyson, Mabry\cr		      % Mailing lists at SRI
+Pitman, Kent M.&              % Administration of Cleanup, agenda setting
+Whittemore, Susan\cr          % Funding administration for Apple
+Barrett, Kim&                 % Administration of Cleanup
+Woodyatt, Anne\cr             % Funding administration for Harlequin
+}
+$$
+
+\goodbreak
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\quad&#\hfil\cr
+Major Technical Contributions:\cr
+\noalign{\vskip 8pt}
+Barrett, Kim A.     &         % Review, Cleanups
+Loosemore, Sandra   \cr       % Review, Compiler
+Bobrow, Daniel G.   &         % CLOS
+Margolin, Barry     \cr       % Review
+Daniels, Andy       &         % Conditions
+Moon, David A.      \cr       % Review, CLOS, Conditions
+DeMichiel, Linda G.  &        % CLOS
+Pitman, Kent M.     \cr       % Review, Conditions, Cleanup, Editor, Lisp1/Lisp2
+Dussud, Patrick H.  &         % CLOS
+Perdue, Crispin     \cr       % Iteration
+Gabriel, Richard P. &         % Review, Editing, CLOS
+Steele, Guy L., Jr. \cr       % Review, CLtL
+Ida, Masayuki       &  	      % Administration of Public Review work
+Waters, Richard C.  \cr       % Pretty Printer, Iteration
+Kiczales, Gregor    &         % CLOS
+White, JonL         \cr       % Review, LOOP
+}
+$$
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\quad&#\hfil\cr
+Organizational Participants:\cr
+\noalign{\vskip 8pt}
+The Aerospace Corporation&
+LMI\cr
+AI Architects&
+Loosemore, Sandra\cr
+Amoco Production Co.&
+Lucid, Inc.\cr
+Aoyama Gakuin University&
+MCC\cr
+Apple Computer&
+MIT\cr
+Barrett, Kim&
+MITRE Corporation\cr
+Boeing Advanced Technology Center&
+MSC\cr
+Carnegie-Mellon University&
+NASA Ames Research Center\cr
+Chestnut Software&
+Nihon Symbolics\cr
+Computer Sciences&
+National Bureau of Standards\cr
+CONTEL&
+Prime Computer\cr
+Digital Equipment Corporation&
+Siemens\cr
+Evans {\ampersand} Sutherland&
+Southern Illinois University\cr
+Encore&
+Sperry\cr
+Franz, Inc.&
+SRI\cr
+Gigamos&
+Sun Microsystems\cr
+GMD&
+Symbolics\cr
+Gold Hill&
+Tektronix\cr
+Greenblatt, Richard&
+Texas Instruments\cr
+Grumman Data Systems Corporation&
+Thinking Machines Corporation\cr
+Harlequin, Ltd.&
+Unisys\cr
+Hewlett-Packard&
+University of Bath\cr
+Honeywell&
+University of Edinburgh\cr
+IBM&
+University of Utah\cr
+Integrated Inference Machines&
+US Army\cr
+International LISP Associates&
+USC/ISI\cr
+Johnson Controls&
+Xerox\cr
+Kerns, Robert W.\cr
+}
+$$
+
+\vfill\eject
+
+$$\halign to \hsize{\leftskip\iskip#\hfil\quad&#\hfil\quad&#\hfil\cr
+Individual Participants:\cr
+\noalign{\vskip 8pt}
+% These are attendees from minutes back through 3/88.  Others to be added
+% per earlier minutes if they can be found.
+Antonisse, Jim&Hewitt, Carl&Perdue, Crispin\cr
+Arbaugh, Bill&Hornig, Charles&Philipp, Christopher\cr
+Balzer, Bob&Ida, Masayuki&Pierson, Dan\cr
+Barrett, Kim&Keene, Sonya&Pitman, Kent M.\cr
+Bartley, David&Keller, Shaun&Raghavan, B.\cr
+Beckerle, Mike&Kempf, James&Rand, Douglas\cr
+Beiser, Paul&Kerns, Robert W.&Rininger, Jeff\cr
+Benson, Eric&Kiczales, Gregor&Rosenking, Jeff\cr
+Berman, Richard&Kolb, Dieter&Scherlis, William\cr
+Bobrow, Daniel G.&Koschmann, Timothy&Shiota, Eiji\cr
+Boelk, Mary&Kosinski, Paul&Sizer, Andy\cr
+Brittain, Skona&Larson, Aaron&Slater, David\cr
+Brown, Gary&Latto, Andy&Sodan, Angela\cr
+Chailloux, Jerome&Laubsch, Joachim&Soley, Richard\cr
+Chapman, Kathy&Layer, Kevin&St. Clair, Bill\cr
+Clinger, Will&Linden, Thom&Stanhope, Philip\cr
+Coffee, Peter C.&Loeffler, David D.&Steele, Guy L., Jr.\cr
+Cugini, John&Loosemore, Sandra&Tucker, Paul\cr
+Curtis, Pavel&Magataca, Mituhiro&Turba, Thomas\cr
+Dabrowski, Christopher&Margolin, Barry&Unietis, Dave\cr
+Daessler, Klaus&Masinter, Larry&van Roggen, Walter\cr
+Dalton, Jeff&Mathis, Robert&van Roggen, Walter\cr
+Daniels, Andy&Matthews, Dave&Waldrum, Ellen\cr
+DeMichiel, Linda G.&McCarthy, John&Waters, Richard C.\cr
+Duggan, Jerry&Mikelsons, Martin&Wechsler, Allan\cr
+Dussud, Patrick H.&Moon, David A.&Wegman, Mark\cr
+Ennis, Susan P.&Moore, Timothy&Weinreb, Daniel\cr
+Fahlman, Scott&Nicoud, Stephen&White, JonL\cr
+Gabriel, Richard P.&Nilsson, Jarl&Wieland, Alexis\cr
+Giansiracusa, Bob&O'Dell, Jim&Withington, P. Tucker\cr
+Gray, David&Ohlander, Ron&Wright, Whitman\cr
+Greenblatt, Richard&Padget, Julian&York, Bill\cr
+Hadden, George D.&Palter, Gary&Zacharias, Gail\cr
+Haflich, Steve&Peck, Jeff&Zubkoff, Jan L.\cr
+Harris, Richard M.&Pellegrino, Bob&\cr
+}
+$$
+

chap-0.tex

@@ -0,0 +1,232 @@
+\input setup-for-toc	      % -*- Mode: TeX -*-
+
+\pageno=0
+\def\chapline{}
+
+\Head {\longbookline}
+
+\HeadI {\DocumentNumber}
+
+\vfill\eject
+\pageno=0
+
+This page intentionally left almost blank.
+
+\vfill\eject
+
+\beginSimpleChapter{Figures}
+{\obeylines\gdef\Ctwo#1\!#2
+{\hangindent1pc\rm #1\dotleader#2\null\par}}
+{\let\0\Czero\let\1\Cone\let\2\Ctwo\let\3\Cthree\let\4\Cfour\let\5\Cfive\let\6\Csix
+\let\par=\endgraf\parskip 0pt\parfillskip 0pt
+\leftskip \normalleftskip\rightskip=0pt
+\hangindent1pc\hangafter0\relax
+\obeylines\catcode`\!=0\relax
+\secref\ChapOne
+\input chap-1.fig
+\vskip 1.5pc
+\secref\ChapTwo
+\input chap-2.fig
+\vskip 1.5pc
+\secref\ChapThree
+\input chap-3.fig
+\vskip 1.5pc
+\secref\ChapFour
+\input chap-4.fig
+\vskip 1.5pc
+\secref\ChapFive
+\input chap-5.fig
+\vskip 1.5pc
+\secref\ChapSix
+\input chap-6.fig
+\vskip 1.5pc
+\secref\ChapSeven
+\input chap-7.fig
+\vskip 1.5pc
+\secref\ChapEight
+\input chap-8.fig
+\vskip 1.5pc
+\secref\ChapNine
+\input chap-9.fig
+\vskip 1.5pc
+\secref\ChapTen
+\input chap-10.fig
+\vskip 1.5pc
+\secref\ChapEleven
+\input chap-11.fig
+\vskip 1.5pc
+\secref\ChapTwelve
+\input chap-12.fig
+\vskip 1.5pc
+\secref\ChapThirteen
+\input chap-13.fig
+\vskip 1.5pc
+\secref\ChapFourteen
+\input chap-14.fig
+\vskip 1.5pc
+\secref\ChapFifteen
+\input chap-15.fig
+\vskip 1.5pc
+\secref\ChapSixteen
+\input chap-16.fig
+\vskip 1.5pc
+\secref\ChapSeventeen
+\input chap-17.fig
+\vskip 1.5pc
+\secref\ChapEighteen
+\input chap-18.fig
+\vskip 1.5pc
+\secref\ChapNineteen
+\input chap-19.fig
+\vskip 1.5pc
+\secref\ChapTwenty
+\input chap-20.fig
+\vskip 1.5pc
+\secref\ChapTwentyOne
+\input chap-21.fig
+\vskip 1.5pc
+\secref\ChapTwentyTwo
+\input chap-22.fig
+\vskip 1.5pc
+\secref\ChapTwentyThree
+\input chap-23.fig
+\vskip 1.5pc
+\secref\ChapTwentyFour
+\input chap-24.fig
+\vskip 1.5pc
+\secref\ChapTwentyFive
+\input chap-25.fig
+\vskip 1.5pc
+\secref\ChapTwentySix
+\input chap-26.fig
+% \secref\ChapTwentySeven
+% \input chap-27.fig
+% \secref\ChapTwentyEight
+% \input chap-28.fig
+% \secref\ChapTwentyNine
+% \input chap-29.fig
+\vskip 1.5pc
+\secref\ChapA
+\input chap-a.fig
+\relax}
+
+\endSimpleChapter%{Figures}
+
+\beginSimpleChapter{Contents}
+
+{\let\0\Pzero\let\1\Pone\let\2\Ptwo\let\3\Pthree\let\4\Pfour\let\5\Pfive\let\6\Psix
+\let\par=\endgraf\parskip 0pt\parfillskip 0pt
+\rightskip 5pc plus 15pc\hangindent1pc
+\obeylines\catcode`\!=0\relax
+\leftskip 0pt\rm
+\secref\ChapOne
+\input chap-1.tc
+\vskip 1.5pc
+\secref\ChapTwo
+\input chap-2.tc
+\vskip 1.5pc
+\secref\ChapThree
+\input chap-3.tc
+\vskip 1.5pc
+\secref\ChapFour
+\input chap-4.tc
+\vskip 1.5pc
+\secref\ChapFive
+\input chap-5.tc
+\vskip 1.5pc
+\secref\ChapSix
+\input chap-6.tc
+\vskip 1.5pc
+\secref\ChapSeven
+\input chap-7.tc
+\vskip 1.5pc
+\secref\ChapEight
+\input chap-8.tc
+\vskip 1.5pc
+\secref\ChapNine
+\input chap-9.tc
+\vskip 1.5pc
+\secref\ChapTen
+\input chap-10.tc
+\vskip 1.5pc
+\secref\ChapEleven
+\input chap-11.tc
+\vskip 1.5pc
+\secref\ChapTwelve
+\input chap-12.tc
+\vskip 1.5pc
+\secref\ChapThirteen
+\input chap-13.tc
+\vskip 1.5pc
+\secref\ChapFourteen
+\input chap-14.tc
+\vskip 1.5pc
+\secref\ChapFifteen
+\input chap-15.tc
+\vskip 1.5pc
+\secref\ChapSixteen
+\input chap-16.tc
+\vskip 1.5pc
+\secref\ChapSeventeen
+\input chap-17.tc
+\vskip 1.5pc
+\secref\ChapEighteen
+\input chap-18.tc
+\vskip 1.5pc
+\secref\ChapNineteen
+\input chap-19.tc
+\vskip 1.5pc
+\secref\ChapTwenty
+\input chap-20.tc
+\vskip 1.5pc
+\secref\ChapTwentyOne
+\input chap-21.tc
+\vskip 1.5pc
+\secref\ChapTwentyTwo
+\input chap-22.tc
+\vskip 1.5pc
+\secref\ChapTwentyThree
+\input chap-23.tc
+\vskip 1.5pc
+\secref\ChapTwentyFour
+\input chap-24.tc
+\vskip 1.5pc
+\secref\ChapTwentyFive
+\input chap-25.tc
+\vskip 1.5pc
+\secref\ChapTwentySix
+\input chap-26.tc
+% \secref\ChapTwentySeven
+% \input chap-27.tc
+% \secref\ChapTwentyEight
+% \input chap-28.tc
+% \secref\ChapTwentyNine
+% \input chap-29.tc
+\vskip 1.5pc
+\secref\ChapA
+\input chap-a.tc
+\relax}
+\endSimpleChapter%{Contents}
+
+\twocolumn
+
+\beginSimpleChapterLeft{Index}
+
+{\let\0\Pzero\let\1\Pone\let\2\Ptwo\let\3\Pthree\let\4\Pfour\let\5\Pfive\let\6\Psix\let\9\Pnine
+\let\par=\endgraf\parskip 0pt\parfillskip 0pt
+\rightskip 5pc plus 15pc\hangindent1pc
+\obeylines\catcode`\!=0\relax
+\input index.idx
+\relax}
+
+\endSimpleChapter%{Index}
+
+\onecolumn
+
+\beginSimpleChapter{Credits}
+
+\input chap-0-edit-history
+
+\endSimpleChapter%{Credits}
+
+\bye

chap-1.tex

@@ -0,0 +1,50 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{1}{Introduction}{ChapOne}{Introduction}
+ 
+\beginSection{Scope, Purpose, and History}
+\input concept-history
+\endSection%{Scope, Purpose, and History}
+
+\beginSection{Organization of the Document}
+\input concept-organization
+\endSection%{Organization of the Document}
+
+\beginSection{Referenced Publications} 
+\input concept-references
+\endSection%{Referenced Publications}
+
+\beginSection{Definitions} 
+\DefineSection{Definitions}
+\input concept-definitions
+\endSection%{Definitions} 
+
+\beginSection{Conformance}
+\DefineSection{Conformance}
+\input concept-conformance
+\endSection%{Conformance}
+
+\beginSection{Language Extensions}
+\DefineSection{LanguageExtensions}
+\input concept-extensions
+\endSection%{Language Extensions}
+
+\beginSection{Language Subsets}
+\DefineSection{LanguageSubsets}
+\input concept-subsets
+\endSection%{Language Subsets}
+
+%Per X3J13. Fixed typo: "beginsubsection" => "beginsection".
+\beginSection{Deprecated Language Features}
+\DefineSection{DeprecatedFeatures}
+\input concept-deprecated
+\endSection%{Deprecated Language Features}
+
+\beginSection{Symbols in the COMMON-LISP Package}
+\DefineSection{CLsymbols}
+\input concept-cl-symbols
+\endSection%{Symbols in the COMMON-LISP Package}
+
+\endchapter
+
+\bye

chap-10.tex

@@ -0,0 +1,13 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{10}{Symbols}{ChapTen}{Symbols}
+                           
+\beginSection{Symbol Concepts}
+\input concept-symbols
+\endSection%{Symbol Concepts}
+
+\includeDictionary{dict-symbols}
+
+\endchapter
+
+\bye

chap-11.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{11}{Packages}{ChapEleven}{Packages}
+
+\beginSection{Package Concepts}
+\DefineSection{PackageConcepts}
+\input concept-packages
+\endSection%{Package Concepts}
+
+\includeDictionary{dict-packages}
+
+\endchapter
+
+\bye

chap-12.tex

@@ -0,0 +1,13 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{12}{Numbers}{ChapTwelve}{Numbers}
+
+\beginSection{Number Concepts}
+\input concept-numbers
+\endSection%{Number Concepts}
+
+\includeDictionary{dict-numbers}
+
+\endchapter
+
+\bye

chap-13.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{13}{Characters}{ChapThirteen}{Characters}
+                           
+\beginSection{Character Concepts}
+\DefineSection{CharacterConcepts}
+\input concept-characters
+\endSection%{Character Concepts}
+
+\includeDictionary{dict-characters}
+
+\endchapter
+
+\bye

chap-14.tex

@@ -0,0 +1,13 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{14}{Conses}{ChapFourteen}{Conses}
+
+\beginSection{Cons Concepts}
+\input concept-conses
+\endSection%{Cons Concepts}
+
+\includeDictionary{dict-conses}
+
+\endchapter
+
+\bye

chap-15.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{15}{Arrays}{ChapFifteen}{Arrays}
+
+\beginSection{Array Concepts}
+\DefineSection{ArrayConcepts}
+\input concept-arrays
+\endSection%{Array Concepts}
+
+\includeDictionary{dict-arrays}
+
+\endchapter
+
+\bye

chap-16.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{16}{Strings}{ChapSixteen}{Strings}
+
+\beginSection{String Concepts}
+\DefineSection{StringConcepts}
+\input concept-strings
+\endSection%{String Concepts}
+
+\includeDictionary{dict-strings}
+
+\endchapter
+
+\bye

chap-17.tex

@@ -0,0 +1,19 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{17}{Sequences}{ChapSeventeen}{Sequences}
+                           
+\beginSection{Sequence Concepts}
+\DefineSection{SequenceConcepts}
+\input concept-sequences
+\endSection%{Sequence Concepts}
+
+\beginSection{Rules about Test Functions}
+\DefineSection{TestFunctionRules}
+\input concept-tests
+\endSection%{Rules about Test Functions}
+
+\includeDictionary{dict-sequences}
+
+\endchapter
+
+\bye

chap-18.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{18}{Hash Tables}{ChapEighteen}{HashTables}
+                           
+\beginSection{Hash Table Concepts}
+\DefineSection{HashTableConcepts}
+\input concept-hash-tables
+\endSection%{Hash Table Concepts}
+
+\includeDictionary{dict-hash-tables}
+
+\endchapter
+
+\bye

chap-19.tex

@@ -0,0 +1,24 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{19}{Filenames}{ChapNineteen}{Filenames}
+                           
+\beginSection{Overview of Filenames}
+\DefineSection{NamingFiles}
+\input concept-filenames
+\endSection%{Overview of Filenames}
+
+\beginSection{Pathnames}
+\DefineSection{PathnameConcepts}
+\input concept-pathnames
+\endSection%{Pathnames}
+
+\beginSection{Logical Pathnames}
+\DefineSection{LogicalPathnames}
+\input concept-logical-pathnames
+\endSection%{Logical Pathnames}
+
+\includeDictionary{dict-pathnames}
+
+\endchapter
+
+\bye

chap-2.tex

@@ -0,0 +1,27 @@
+\input setup		      % -*- Mode: TeX -*-		
+
+\beginchapter{2}{Syntax}{ChapTwo}{Syntax}
+                           
+\beginSection{Character Syntax}
+\DefineSection{CharacterSyntax}
+\input concept-syntax
+\endSection%{Character Syntax}
+
+\beginSection{Reader Algorithm}
+\DefineSection{ReaderAlgorithm}
+\input concept-reader-algorithm
+\endSection%{Reader Algorithm}
+
+\beginSection{Interpretation of Tokens}
+\DefineSection{InterpOfTokens}
+\input concept-tokens
+\endSection%{Interpretation of Tokens}
+
+\beginSection{Standard Macro Characters}
+\DefineSection{StandardMacroChars}
+\input concept-macro-chars
+\endSection%{Standard Macro Characters}
+
+\endchapter
+
+\bye

chap-20.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{20}{Files}{ChapTwenty}{Files}
+
+\beginSection{File System Concepts}
+\DefineSection{FileSystemConcepts}
+\input concept-files
+\endSection%{File System Concepts}
+
+\includeDictionary{dict-files}
+
+\endchapter
+
+\bye

chap-21.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{21}{Streams}{ChapTwentyOne}{Streams}
+
+\beginSection{Stream Concepts}
+\DefineSection{StreamConcepts}
+\input concept-streams
+\endSection%{Stream Concepts}
+
+\includeDictionary{dict-streams}
+
+\endchapter
+
+\bye

chap-22.tex

@@ -0,0 +1,24 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{22}{Printer}{ChapTwentyTwo}{Printer}
+                           
+\beginSection{The Lisp Printer}
+\DefineSection{TheLispPrinter}
+\input concept-print
+\endSection%{The Lisp Printer}
+
+\beginSection{The Lisp Pretty Printer}
+\DefineSection{PPrinter}
+\input concept-pprint
+\endSection%{The Lisp Pretty Printer}
+
+\beginSection{Formatted Output}
+\DefineSection{FormattedOutput}
+\input concept-format
+\endSection%{Formatted Output}
+
+\includeDictionary{dict-printer}
+
+\endchapter
+
+\bye

chap-23.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{23}{Reader}{ChapTwentyThree}{Reader}
+                           
+\beginSection{Reader Concepts}
+\DefineSection{ReaderConcepts}
+\input concept-reader
+\endSection%{Reader Concepts}
+
+\includeDictionary{dict-reader}
+
+\endchapter
+
+\bye

chap-24.tex

@@ -0,0 +1,13 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{24}{System Construction}{ChapTwentyFour}{SystemConstruction}
+                           
+\beginSection{System Construction Concepts}
+\input concept-systems
+\endSection%{System Construction Concepts}
+
+\includeDictionary{dict-system-construction}
+
+\endchapter
+
+\bye

chap-25.tex

@@ -0,0 +1,13 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{25}{Environment}{ChapTwentyFive}{Environment}
+                           
+\beginSection{The External Environment}
+\input concept-environment
+\endSection%{The External Environment}
+
+\includeDictionary{dict-environment}
+
+\endchapter
+
+\bye

chap-26.tex

@@ -0,0 +1,11 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{26}{Glossary}{ChapTwentySix}{Glossary}
+
+\beginSection{Glossary}
+\input concept-glossary
+\endSection%{Glossary}
+
+\endchapter
+
+\bye

chap-3.tex

@@ -0,0 +1,44 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{3}{Evaluation and Compilation}{ChapThree}{EvaluationAndCompilation}
+
+\beginSection{Evaluation}
+\DefineSection{Evaluation}
+\input concept-eval
+\endSection%{Evaluation}
+              
+\beginSection{Compilation}
+\DefineSection{Compilation}
+\input concept-compile
+\endSection%{Compilation}
+
+\beginSection{Declarations}
+\DefineSection{Declarations}
+\input concept-decls
+\endSection%{Declarations}
+
+\beginSection{Lambda Lists}
+\DefineSection{LambdaLists}
+\input concept-bvl
+\endSection%{Lambda Lists}
+
+\beginSection{Error Checking in Function Calls}
+\DefineSection{FuncallErrorChecking}
+\input concept-args
+\endSection%{Error Checking in Function Calls}
+
+\beginSection{Traversal Rules and Side Effects}
+\DefineSection{TraversalRules}
+\input concept-traversal
+\endSection%{Traversal Rules and Side Effects}
+
+\beginSection{Destructive Operations}
+\DefineSection{DestructiveOperations}
+\input concept-destruction
+\endSection%{Destructive Operations}
+
+\includeDictionary{dict-eval-compile}
+
+\endchapter
+
+\bye

chap-4.tex

@@ -0,0 +1,23 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{4}{Types and Classes}{ChapFour}{TypesAndClasses}
+
+\beginSection{Introduction}
+\input concept-type-intro
+\endSection%{Introduction}
+
+\beginSection{Types}
+\DefineSection{Types}
+\input concept-types
+\endSection%{Types}
+
+\beginSection{Classes}
+\DefineSection{Classes}
+\input concept-classes
+\endSection%{Classes}
+
+\includeDictionary{dict-types}
+
+\endchapter
+
+\bye

chap-5.tex

@@ -0,0 +1,19 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{5}{Data and Control Flow}{ChapFive}{DataAndControlFlow}
+
+\beginSection{Generalized Reference}
+\DefineSection{GeneralizedReference}
+\input concept-places
+\endSection%{Generalized Reference}
+
+\beginSection{Transfer of Control to an Exit Point}
+\DefineSection{TransferOfControl}
+\input concept-exits
+\endSection%{Transfer of Control to an Exit Point}
+
+\includeDictionary{dict-flow}
+
+\endchapter
+
+\bye

chap-6.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{6}{Iteration}{ChapSix}{Iteration}
+                           
+\beginSection{The LOOP Facility}
+\DefineSection{LoopFacility}
+\input concept-loop
+\endSection%{The LOOP Facility}
+
+\includeDictionary{dict-iteration}
+
+\endchapter
+
+\bye

chap-7.tex

@@ -0,0 +1,39 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{7}{Objects}{ChapSeven}{Objects}
+
+\beginSection{Object Creation and Initialization}
+\DefineSection{ObjectCreationAndInit}
+\input concept-objects
+\endSection%{Object Creation and Initialization}
+
+\beginSection{Changing the Class of an Instance}
+\DefineSection{ChangingInstanceClass}
+\input concept-change-class
+\endSection%{Changing the Class of an Instance}
+
+\beginSection{Reinitializing an Instance}
+\DefineSection{InstanceReInit}
+\input concept-reinit
+\endSection%{Reinitializing an Instance}
+
+\beginSection{Meta-Objects}
+\DefineSection{MetaObjects}
+\input concept-meta-objects
+\endSection%{Meta-Objects}
+
+\beginSection{Slots}
+\DefineSection{Slots}
+\input concept-slots
+\endSection%{Slots}
+
+\beginSection{Generic Functions and Methods}
+\DefineSection{GFsAndMethods}
+\input concept-gfs-and-methods
+\endSection%{Generic Functions and Methods}
+
+\includeDictionary{dict-objects}
+
+\endchapter
+
+\bye

chap-8.tex

@@ -0,0 +1,9 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{8}{Structures}{ChapEight}{Structures}
+
+\includeDictionary{dict-structures}
+
+\endchapter
+
+\bye

chap-9.tex

@@ -0,0 +1,14 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{9}{Conditions}{ChapNine}{Conditions}
+                           
+\beginSection{Condition System Concepts}
+\DefineSection{ConditionSystemConcepts}
+\input concept-conditions
+\endSection%{Condition System Concepts}
+
+\includeDictionary{dict-conditions}
+
+\endchapter
+
+\bye

chap-a.tex

@@ -0,0 +1,26 @@
+\input setup		      % -*- Mode: TeX -*-
+
+\beginchapter{A}{Appendix}{ChapA}{Appendix}
+ 
+%% These two sections are not well-maintained, and I've decided to just omit them
+%% for now until and unless we can put some more effort into them. -kmp 23-Oct-91
+%
+% \beginSection{Implementation-defined features}
+% \DefineSection{ImplemDefFeatures}
+% \input appendix-implem-defined
+% \endSection%{Implementation-defined features}
+% 
+% \beginSection{Portability Issues}
+% \input appendix-portability
+% \endSection%{Portability Issues}
+
+\beginSection{Removed Language Features}
+\DefineSection{RemovedFeatures}
+\input appendix-removed
+\endSection%{Removed Language Features}
+
+% What about deprecated features? see CHAP-A-4-DEPRECATED? -kmp 27-Sep-90
+
+\endchapter
+
+\bye

concept-args.tex

@@ -0,0 +1,309 @@
+% -*- Mode: TeX -*-
+%% Error Checking in Function Calls
+
+\issue{ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS}
+
+\beginsubSection{Argument Mismatch Detection}
+
+\beginsubsubsection{Safe and Unsafe Calls}
+\DefineSection{SafeAndUnsafeCalls}
+
+A \term{call} is a \newterm{safe call} if each of the following is
+either \term{safe} \term{code} or \term{system code} (other than
+\term{system code} that results from \term{macro expansion} of 
+\term{programmer code}):
+\beginlist
+\itemitem{\bull} the \term{call}.
+\itemitem{\bull} the definition of the \term{function} being \term{called}.
+\itemitem{\bull} the point of \term{functional evaluation} 
+\endlist
+
+The following special cases require some elaboration:
+
+\beginlist
+\itemitem{\bull}
+If the \term{function} being called is a \term{generic function},
+it is considered \term{safe} if all of the following are
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+% "safe" => "safe code or system code" per Moon #12 (first public review).
+\term{safe code} or \term{system code}:
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\beginlist
+\itemitem{--} its definition (if it was defined explicitly).
+\itemitem{--} the \term{method} definitions for all \term{applicable} \term{methods}.
+\itemitem{--} the definition of its \term{method combination}.
+\endlist
+
+\itemitem{\bull}
+For the form \f{(coerce \param{x} 'function)}, 
+where \param{x} is a \term{lambda expression},
+the value of the \term{optimize quality} \declref{safety}
+in the global environment at the time the \funref{coerce}
+is \term{executed} applies to the resulting \term{function}.
+
+\issue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+% \itemitem{\bull}
+% For the form \f{(enclose \param{x} \param{env})}, 
+% where \param{x} is a \term{lambda expression},
+% the value of the \term{optimize quality} \declref{safety}
+% in the \term{environment} \term{object} \param{env} applies
+% to the resulting \term{function}.
+\endissue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% \itemitem{\bull}
+% For     \macref{generic-function},
+%         \specref{generic-flet},
+%     and \specref{generic-labels}
+% \term{forms}, the value of the \term{optimize quality} \declref{safety}
+% in the \term{lexical environment} in which the form appears applies
+% to the resulting \term{generic functions} and \term{method} definitions.
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+   
+\itemitem{\bull}
+For a call to \thefunction{ensure-generic-function}, the value of the
+\term{optimize quality} \declref{safety} in the \term{environment}
+\term{object} passed as the \kwd{environment} \term{argument} applies 
+to the resulting \term{generic function}.
+
+\itemitem{\bull}
+For a call to \funref{compile} with a \term{lambda expression} as the
+\term{argument}, the value of the \term{optimize quality} \funref{safety}
+in the \term{global environment} at the time \funref{compile} is \term{called}
+applies to the resulting \term{compiled function}.
+
+\itemitem{\bull}
+For a call to \funref{compile} with only one argument, if the original definition
+of the \term{function} was \term{safe}, then the resulting \term{compiled function}
+must also be \term{safe}.
+
+\itemitem{\bull}
+A \term{call} to a \term{method} by \funref{call-next-method} must be 
+considered \term{safe} if each of the following is 
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+% "safe" => "safe code or system code" per Moon #12 (first public review).
+\term{safe code} or \term{system code}:
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\beginlist
+%% These first three reworded per RPG for wording consistency with 
+%% another bullet list above.  KAB concurred. -kmp 26-Jan-92
+% \itemitem{--} the \term{generic function}.
+% \itemitem{--} the \term{applicable} \term{methods}.
+% \itemitem{--} the \term{method combination}.
+\itemitem{--} the definition of the \term{generic function} (if it was defined explicitly).
+\itemitem{--} the \term{method} definitions for all \term{applicable} \term{methods}.
+\itemitem{--} the definition of the \term{method combination}.
+\itemitem{--} the point of entry into the body of the \term{method defining form},
+	      where the \term{binding} of \funref{call-next-method} is established.
+\itemitem{--} the point of \term{functional evaluation} of the name \funref{call-next-method}.
+\endlist
+
+\endlist
+
+An \newterm{unsafe call} is a \term{call} that is not a \term{safe call}.
+
+The informal intent is that the \term{programmer} can rely on a \term{call}
+to be \term{safe}, even when \term{system code} is involved, if all reasonable
+steps have been taken to ensure that the \term{call} is \term{safe}.
+For example, if a \term{programmer} calls \funref{mapcar} from \term{safe}
+\term{code} and supplies a \term{function} that was \term{compiled} 
+as \term{safe}, the \term{implementation} is required to ensure that
+\funref{mapcar} makes a \term{safe call} as well.
+
+\beginsubsubsubsection{Error Detection Time in Safe Calls}
+\DefineSection{SafeCallDetectionTime}
+
+If an error is signaled in a \term{safe call},
+the exact point of the \term{signal} is \term{implementation-dependent}.
+In particular, it might be signaled at compile time or at run time,
+and if signaled at run time, 
+it might be prior to, during, or after \term{executing} the \term{call}.
+However, it is always prior to the execution of the body of the \term{function} 
+being \term{called}.
+
+\endsubsubsubsection%{Error Detection Time in Safe Calls}
+
+\endsubsubsection%{Safe and Unsafe Calls}
+
+\beginsubsubsection{Too Few Arguments}
+
+It is not permitted to supply too few \term{arguments} to a \term{function}.
+%For Moon:
+Too few arguments means fewer \term{arguments} than the number of \term{required parameters} 
+for the \term{function}.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Per Moon #12 (first public review). -kmp 8-May-93
+%Otherwise, in a \term{safe call},
+If this \term{situation} occurs in a \term{safe call},
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+an error \oftype{program-error} must be signaled;
+and in an \term{unsafe call} the \term{situation} has undefined consequences.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Commented out as redundant, per Moon #12 (first public review).
+%% I sure hope this doesn't lead to confusion down the road...  -kmp 8-May-93
+%If an error is signaled in a \term{safe call},
+%the exact point of the \term{signal} is \term{implementation-dependent};
+%\seesection\SafeCallDetectionTime.
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\endsubsubsection%{Too Few Arguments}
+% ========================================
+\beginsubsubsection{Too Many Arguments}
+
+It is not permitted to supply too many \term{arguments} to a \term{function}.
+Too many arguments means more \term{arguments} than the number of \term{required parameters}
+plus the number of \term{optional parameters}; however, if the \term{function} 
+uses \keyref{rest} or \keyref{key}, it is not possible for it to receive too many arguments.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Per Moon #12 (first public review). -kmp 8-May-93
+%Otherwise, in a \term{safe call},
+If this \term{situation} occurs in a \term{safe call},
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+an error \oftype{program-error} must be signaled;
+and in an \term{unsafe call} the \term{situation} has undefined consequences.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Commented out as redundant, per Moon #12 (first public review).
+%% I sure hope this doesn't lead to confusion down the road...  -kmp 8-May-93
+%If an error is signaled in a \term{safe call},
+%the exact point of the \term{signal} is \term{implementation-dependent};
+%\seesection\SafeCallDetectionTime.
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\endsubsubsection%{Too Many Arguments}
+% ========================================
+\beginsubsubsection{Unrecognized Keyword Arguments}
+\DefineSection{UnrecognizedKeyArgs}
+
+It is not permitted to supply a keyword argument to a \term{function}
+using a name that is not recognized by that \term{function} 
+unless keyword argument checking is suppressed as described
+in \secref\SuppressingKeyArgChecks.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Per Moon #12 (first public review). -kmp 8-May-93
+%Otherwise, in a \term{safe call},
+If this \term{situation} occurs in a \term{safe call},
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+an error \oftype{program-error} must be signaled;
+and in an \term{unsafe call} the \term{situation} has undefined consequences.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Commented out as redundant, per Moon #12 (first public review).
+%% I sure hope this doesn't lead to confusion down the road...  -kmp 8-May-93
+%If an error is signaled in a \term{safe call},
+%the exact point of the \term{signal} is \term{implementation-dependent};
+%\seesection\SafeCallDetectionTime.
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\endsubsubsection%{Unrecognized Keyword Arguments}
+% ========================================
+\beginsubsubsection{Invalid Keyword Arguments}
+\DefineSection{InvalidKeyArgs}
+
+It is not permitted to supply a keyword argument to a \term{function}
+using a name that is not a \term{symbol}.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Per Moon #12 (first public review). -kmp 8-May-93
+%Otherwise, in a \term{safe call},
+If this \term{situation} occurs in a \term{safe call},
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+an error \oftype{program-error} must be signaled 
+unless keyword argument checking is suppressed as described
+in \secref\SuppressingKeyArgChecks;
+and in an \term{unsafe call} the \term{situation} has undefined consequences.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Commented out as redundant, per Moon #12 (first public review).
+%% I sure hope this doesn't lead to confusion down the road...  -kmp 8-May-93
+%If an error is signaled in a \term{safe call},
+%the exact point of the \term{signal} is \term{implementation-dependent};
+%\seesection\SafeCallDetectionTime.
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\endsubsubsection%{Invalid Keyword Arguments}
+% ========================================
+\beginsubsubsection{Odd Number of Keyword Arguments}
+\DefineSection{OddNumberOfKeyArgs}
+
+\issue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+
+An odd number of \term{arguments} must not be supplied for the \term{keyword parameters}.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Per Moon #12 (first public review). -kmp 8-May-93
+%Otherwise, in a \term{safe call},
+If this \term{situation} occurs in a \term{safe call},
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+an error \oftype{program-error} must be signaled
+unless keyword argument checking is suppressed as described
+in \secref\SuppressingKeyArgChecks;
+and in an \term{unsafe call} the \term{situation} has undefined consequences.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Commented out as redundant, per Moon #12 (first public review).
+%% I sure hope this doesn't lead to confusion down the road...  -kmp 8-May-93
+%If an error is signaled in a \term{safe call},
+%the exact point of the \term{signal} is \term{implementation-dependent};
+%\seesection\SafeCallDetectionTime.
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\endissue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+
+\endsubsubsection%{Odd Number of Keyword Arguments}
+% ========================================
+\beginsubsubsection{Destructuring Mismatch}
+\DefineSection{DestructuringMismatch}
+
+\issue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+
+When matching a \term{destructuring lambda list} against a \term{form},
+the pattern and the \term{form} must have compatible \term{tree structure},
+as described in \secref\ExtraDestructureInfo.
+
+Otherwise, in a \term{safe call},
+an error \oftype{program-error} must be signaled;
+and in an \term{unsafe call} the \term{situation} has undefined consequences.
+
+\issue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+%% Commented out as redundant, per Moon #12 (first public review).
+%% I sure hope this doesn't lead to confusion down the road...  -kmp 8-May-93
+%If an error is signaled in a \term{safe call},
+%the exact point of the \term{signal} is \term{implementation-dependent};
+%\seesection\SafeCallDetectionTime.
+\endissue{ARGUMENT-MISMATCH-ERROR-MOON:FIX}
+
+\endissue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+
+\endsubsubsection%{Destructuring Mismatch}
+% ========================================
+\beginsubsubsection{Errors When Calling a Next Method}
+
+If \funref{call-next-method} is called with \term{arguments}, the ordered
+set of \term{applicable} \term{methods} for the changed set of \term{arguments}
+for \funref{call-next-method} must be the same as the ordered set of 
+\term{applicable} \term{methods} for the original \term{arguments} to the
+\term{generic function}, or else an error should be signaled.
+
+The comparison between the set of methods applicable to the
+new arguments and the set applicable to the original arguments is
+insensitive to order differences among methods with the same
+specializers.
+ 
+If \funref{call-next-method} is called with \term{arguments} that specify
+a different ordered set of \term{applicable} methods and there is no 
+\term{next method} available, the test for different methods and the 
+associated error signaling (when present) takes precedence over calling
+\funref{no-next-method}.
+
+\endsubsubsection%{Errors When Calling a Next Method}
+
+\endsubSection%{Argument Mismatch Detection}
+
+\endissue{ARGUMENT-MISMATCH-ERROR:MORE-CLARIFICATIONS}

concept-arrays.tex

@@ -0,0 +1,244 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Array Elements}
+\DefineSection{ArrayElements}
+
+An \term{array} contains a set of \term{objects} called \term{elements}
+that can be referenced individually according to a rectilinear coordinate system.
+
+\beginsubsubsection{Array Indices}
+
+%% 2.5.0 5
+An \term{array} \term{element} is referred to by a (possibly empty) series of indices.
+The length of the series must equal the \term{rank} of the \term{array}.
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+Each index must be a non-negative \term{fixnum} 
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+%strictly
+less than the corresponding \term{array} \term{dimension}.
+\term{Array} indexing is zero-origin.
+
+\endsubsubsection%{Array Indices}
+
+\beginsubsubsection{Array Dimensions}
+
+An axis of an \term{array} is called a \newterm{dimension}.
+
+Each \term{dimension} is a non-negative 
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\term{fixnum};
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+ if any dimension of an \term{array} is zero, the \term{array} has no elements.
+% Maybe this part isn't in glossary...I just moved it from somewhere else per 
+% suggestion of Barmar.  -kmp 14-Jan-92
+It is permissible for a \term{dimension} to be zero, 
+in which case the \term{array} has no elements, 
+and any attempt to \term{access} an \term{element}
+is an error.  However, other properties of the \term{array},  
+such as the \term{dimensions} themselves, may be used.
+
+\beginsubsubsubsection{Implementation Limits on Individual Array Dimensions}
+
+An \term{implementation} may impose a limit on \term{dimensions} of an \term{array},
+but there is a minimum requirement on that limit.  \Seevar{array-dimension-limit}.
+
+\endsubsubsubsection%{Implementation Limits on Individual Array Dimensions}
+
+\endsubsubsection%{Array Dimensions}
+
+\beginsubsubsection{Array Rank}
+
+%% 2.5.0 3
+%% 2.5.0 4
+
+An \term{array} can have any number of \term{dimensions} (including zero).
+The number of \term{dimensions} is called the \newterm{rank}.
+
+If the rank of an \term{array} is zero then the \term{array} is said to have
+no \term{dimensions}, and the product of the dimensions (see \funref{array-total-size})
+is then 1; a zero-rank \term{array} therefore has a single element.
+
+\beginsubsubsubsection{Vectors}
+
+An \term{array} of \term{rank} one (\ie a one-dimensional \term{array})
+is called a \newterm{vector}.
+
+\beginsubsubsubsubsection{Fill Pointers}
+
+A \newterm{fill pointer} is a non-negative \term{integer} no
+larger than the total number of \term{elements} in a \term{vector}.
+Not all \term{vectors} have \term{fill pointers}.
+\Seefuns{make-array} and \funref{adjust-array}.
+
+An \term{element} of a \term{vector} is said to be \newterm{active} if it has
+an index that is greater than or equal to zero, 
+but less than the \term{fill pointer} (if any).
+For an \term{array} that has no \term{fill pointer},
+all \term{elements} are considered \term{active}.
+
+%% 17.5.0 4
+Only \term{vectors} may have \term{fill pointers}; 
+multidimensional \term{arrays} may not.
+A multidimensional \term{array} that is displaced to a \term{vector} 
+that has a \term{fill pointer} can be created.
+
+\endsubsubsubsubsection%{Fill Pointers}
+
+\endsubsubsubsection%{Vectors}
+
+\beginsubsubsubsection{Multidimensional Arrays}
+
+\beginsubsubsubsubsection{Storage Layout for Multidimensional Arrays}
+
+%% 2.5.0 8
+Multidimensional \term{arrays} store their components in row-major order;
+that is, internally a multidimensional \term{array} is stored as a
+one-dimensional \term{array}, with the multidimensional index sets
+ordered lexicographically, last index varying fastest.  
+ 
+\endsubsubsubsubsection%{Storage Layout for Multidimensional Arrays}
+
+\beginsubsubsubsubsection{Implementation Limits on Array Rank}
+
+An \term{implementation} may impose a limit on the \term{rank} of an \term{array},
+but there is a minimum requirement on that limit.  \Seevar{array-rank-limit}.
+
+\endsubsubsubsubsection%{Implementation Limits on Array Rank}
+
+\endsubsubsubsection%{Multidimensional Arrays}
+
+\endsubsubsection%{Array Rank}
+
+\endsubsection%{Array Elements}
+
+\beginsubsection{Specialized Arrays}
+
+%% 17.0.0 4
+An \term{array} can be a \term{general} \term{array}, 
+    meaning each \term{element} may be any \term{object},
+or it may be a \term{specialized} \term{array},
+    meaning that each \term{element} must be of a restricted \term{type}.
+
+The phrasing ``an \term{array} \term{specialized} to \term{type} \metavar{type}''
+is sometimes used to emphasize the \term{element type} of an \term{array}.
+This phrasing is tolerated even when the \metavar{type} is \typeref{t},
+even though an \term{array} \term{specialized} to \term{type} \term{t}
+is a \term{general} \term{array}, not a \term{specialized} \term{array}.
+
+\Thenextfigure\ lists some \term{defined names} that are applicable to \term{array} 
+creation, \term{access}, and information operations.
+
+%% Added ARRAY-DISPLACEMENT per Tom Shepard.  (X3J13 approved: May 4-5, 1994)
+%% -kmp 9-May-94
+\displaythree{General Purpose Array-Related Defined Names}{
+adjust-array&array-has-fill-pointer-p&make-array\cr
+adjustable-array-p&array-in-bounds-p&svref\cr
+aref&array-rank&upgraded-array-element-type\cr
+array-dimension&array-rank-limit&upgraded-complex-part-type\cr
+array-dimension-limit&array-row-major-index&vector\cr
+array-dimensions&array-total-size&vector-pop\cr
+array-displacement&array-total-size-limit&vector-push\cr
+array-element-type&fill-pointer&vector-push-extend\cr
+}
+
+\beginsubsubsection{Array Upgrading}
+\DefineSection{ArrayUpgrading}
+
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+% Some of the following was transplanted from the description 
+% of UPGRADED-ARRAY-ELEMENT-TYPE.  Consider also stealing from
+% SUBTYPEP and TYPEP.
+
+The \newterm{upgraded array element type} of a \term{type} $T\sub 1$
+is a \term{type} $T\sub 2$ that is a \term{supertype} of $T\sub 1$
+and that is used instead of $T\sub 1$ whenever $T\sub 1$
+is used as an \term{array element type} 
+for object creation or type discrimination.
+
+During creation of an \term{array},
+the \term{element type} that was requested 
+is called the \newterm{expressed array element type}.
+The \term{upgraded array element type} of the \term{expressed array element type}
+becomes the \newterm{actual array element type} of the \term{array} that is created.
+
+%!!! Barmar thinks this should be removed.
+\term{Type} \term{upgrading} implies a movement upwards in the type hierarchy lattice.
+A \term{type} is always a \term{subtype} of its \term{upgraded array element type}.
+Also, if a \term{type} $T\sub x$ is a \term{subtype} of another \term{type} $T\sub y$,
+then
+the \term{upgraded array element type} of $T\sub x$ 
+must be a \term{subtype} of
+the \term{upgraded array element type} of $T\sub y$.
+Two \term{disjoint} \term{types} can be \term{upgraded} to the same \term{type}.
+
+The \term{upgraded array element type} $T\sub 2$ of a \term{type} $T\sub 1$
+is a function only of $T\sub 1$ itself;
+that is, it is independent of any other property of the \term{array} 
+for which $T\sub 2$ will be used,
+such as \term{rank}, \term{adjustability}, \term{fill pointers}, or displacement.
+%% This next sentence is interesting, but is just Rationale, so is omitted.
+% The reason \term{rank} is included is because it would not
+% be consistently possible to displace \term{arrays} to those of differing
+% \term{rank} otherwise.
+\Thefunction{upgraded-array-element-type} 
+can be used by \term{conforming programs} to predict how the \term{implementation}
+will \term{upgrade} a given \term{type}.
+
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+\endsubsubsection%{Array Upgrading}
+
+\beginsubsubsection{Required Kinds of Specialized Arrays}
+\DefineSection{RequiredSpecializedArrays}
+
+%% 17.0.0 5
+\term{Vectors} whose \term{elements} are restricted to \term{type}
+\issue{CHARACTER-PROPOSAL:2-3-2}
+\typeref{character} or a \term{subtype} of \typeref{character}
+\endissue{CHARACTER-PROPOSAL:2-3-2}
+are called \newtermidx{strings}{string}. 
+\term{Strings} are \oftype{string}.
+%% 18.0.0 7
+%% 18.0.0 4
+\Thenextfigure\ lists some \term{defined names} related to \term{strings}.
+
+\term{Strings} are \term{specialized} \term{arrays} 
+and might logically have been included in this chapter.
+However, for purposes of readability
+most information about \term{strings} does not appear in this chapter;
+see instead \chapref\Strings.
+
+%% 18.0.0 5
+%% paragraph duplicated in descriptions of string-equal and string=
+%% 18.0.0 6
+%% paragraph duplicated in description of stringp
+
+\displaythree{Operators that Manipulate Strings}{
+char&string-equal&string-upcase\cr
+make-string&string-greaterp&string{\tt /=}\cr
+nstring-capitalize&string-left-trim&string{\tt <}\cr
+nstring-downcase&string-lessp&string{\tt <=}\cr
+nstring-upcase&string-not-equal&string{\tt =}\cr
+schar&string-not-greaterp&string{\tt >}\cr
+string&string-not-lessp&string{\tt >=}\cr
+string-capitalize&string-right-trim&\cr
+string-downcase&string-trim&\cr
+}
+
+\term{Vectors} whose \term{elements} are restricted to \term{type}
+\typeref{bit} are called \newtermidx{bit vectors}{bit vector}.
+\term{Bit vectors} are \oftype{bit-vector}.
+\Thenextfigure\ lists some \term{defined names} for operations on \term{bit arrays}.
+
+\displaythree{Operators that Manipulate Bit Arrays}{
+bit&bit-ior&bit-orc2\cr
+bit-and&bit-nand&bit-xor\cr
+bit-andc1&bit-nor&sbit\cr
+bit-andc2&bit-not&\cr
+bit-eqv&bit-orc1&\cr
+}
+
+\endsubsubsection%{Required Kinds of Specialized Arrays}
+
+\endsubsection%{Specialized Arrays}

concept-bvl.tex

@@ -0,0 +1,1286 @@
+% -*- Mode: TeX -*-
+
+A \newterm{lambda list} is a \term{list} that
+specifies a set of \term{parameters} (sometimes called \term{lambda variables})
+and a protocol for receiving \term{values} for those \term{parameters}.
+
+% \term{Lambda list keywords} do not belong to \thepackage{keyword};
+% a \term{lambda list keyword} is a \term{symbol} 
+% whose name begins with an \term{ampersand}.
+
+There are several kinds of \term{lambda lists}.
+
+\tablefigtwo{What Kind of Lambda Lists to Use}{Context}{Kind of Lambda List}{
+ \macref{defun} \term{form}                        & \term{ordinary lambda list}         \cr
+ \macref{defmacro} \term{form}                     & \term{macro lambda list}            \cr
+ \term{lambda expression}                          & \term{ordinary lambda list}         \cr
+ \specref{flet} local \term{function} definition   & \term{ordinary lambda list}         \cr
+ \specref{labels} local \term{function} definition & \term{ordinary lambda list}         \cr
+ \specref{handler-case} \param{clause} specification
+						   & \term{ordinary lambda list}         \cr
+ \specref{restart-case} \param{clause} specification
+						   & \term{ordinary lambda list}         \cr
+ \macref{macrolet} local \term{macro} definition   & \term{macro lambda list}            \cr
+ \macref{define-method-combination}		   & \term{ordinary lambda list}	 \cr
+ \macref{define-method-combination} \kwd{arguments} option &
+%Moon thought :arguments for DEFINE-METHOD-COMBINATION took an ordinary lambda list,
+%but Barrett (comment #3, first public review) observes that &whole is permissible.
+%Time to make a new kind of list.
+       \term{define-method-combination arguments lambda list}         \cr
+ \macref{defstruct} \kwd{constructor} option       & \term{boa lambda list}              \cr
+ \macref{defgeneric} \term{form}                   & \term{generic function lambda list} \cr
+ \macref{defgeneric} \term{method} clause          & \term{specialized lambda list}      \cr
+ \macref{defmethod} \term{form}                    & \term{specialized lambda list}      \cr
+ \macref{defsetf} \term{form}                      & \term{defsetf lambda list}          \cr
+ \macref{define-setf-expander} \term{form}	   & \term{macro lambda list}	         \cr
+ \macref{deftype} \term{form}			   & \term{deftype lambda list}		 \cr
+ \macref{destructuring-bind} \term{form}	   & \term{destructuring lambda list}    \cr
+%\specref{generic-flet} \term{form}                & \term{generic function lambda list} \cr
+%\specref{generic-flet} \term{method} clause       & \term{specialized lambda list}      \cr
+%\specref{generic-labels} \term{form}              & \term{generic function lambda list} \cr
+%\specref{generic-labels} \term{method} clause     & \term{specialized lambda list}      \cr
+%\specref{generic-function} \term{form}		   & \term{generic function lambda list} \cr
+%\specref{generic-function} \term{method} clause   & \term{specialized lambda list}      \cr
+% Added define-modify-macro and define-compiler-macro --sjl 5 Mar 92
+ \macref{define-compiler-macro} \term{form}       & \term{macro lambda list}             \cr
+ \macref{define-modify-macro} \term{form}         & \term{define-modify-macro lambda list} \cr
+}
+
+\Thenextfigure\ lists some \term{defined names} that are applicable
+to \term{lambda lists}.
+
+\displaythree{Defined names applicable to lambda lists}{
+lambda-list-keywords&lambda-parameters-limit&\cr
+}
+
+
+\beginsubSection{Ordinary Lambda Lists}
+\DefineSection{OrdinaryLambdaLists}
+
+An \newterm{ordinary lambda list} is used to describe how a set of
+\term{arguments} is received by an \term{ordinary} \term{function}.  
+The \term{defined names} in \thenextfigure\ are those which use
+\term{ordinary lambda lists}:
+
+%!!! This table is just a seed and probably incomplete. -kmp 2-Aug-91
+%Added RESTART-CASE and HANDLER-CASE per Moon #9 (first public review). -kmp 6-May-93
+\displaythree{Standardized Operators that use Ordinary Lambda Lists}{
+define-method-combination&handler-case&restart-case\cr
+defun&labels&\cr
+flet&lambda&\cr
+}
+
+An \term{ordinary lambda list} can contain the \term{lambda list keywords} shown
+in \thenextfigure.
+
+\showthree{Lambda List Keywords used by Ordinary Lambda Lists}{
+\keyref{allow-other-keys}&\keyref{key}&\keyref{rest}\cr
+\keyref{aux}&\keyref{optional}&\cr
+}
+
+Each \term{element} of a \term{lambda list} is either a parameter specifier
+or a \term{lambda list keyword}.
+%%5.2.2 26
+Implementations are free to provide additional \term{lambda list keywords}.
+For a list of all \term{lambda list keywords}
+used by the implementation, see \conref{lambda-list-keywords}.
+
+The syntax for \term{ordinary lambda lists} is as follows: 
+
+\Vskip 1pc!
+\auxbnf{lambda-list}{\lparen\starparam{var}\CR
+		     \ \ttbrac{{\opt} \star{\VarValueSuppliedP}}\CR
+		     \ \ttbrac{{\rest} \param{var}}\CR
+		     \ \f{[}\Vtop{\hbox{{\key} \star{\KeyVarValueSuppliedP}}
+				  \vskip 4pt
+				  \hbox{\brac{\allowotherkeys}\f{]}}}\CR
+		     \ \ttbrac{{\aux} \star{\VarValue}}\rparen\CR}
+
+%% 5.2.2 3
+A \param{var} or \param{supplied-p-parameter} must be a \term{symbol}
+that is not the name of a \term{constant variable}.
+
+An \param{init-form} can be any \term{form}.
+%% 5.2.2 22
+Whenever any \param{init-form} is evaluated for any parameter
+specifier, that \term{form} may refer to any parameter variable to
+the left of the specifier in which the \param{init-form} appears,
+including any \param{supplied-p-parameter} variables, and may rely 
+on the fact that no other parameter variable has yet been bound
+(including its own parameter variable).
+
+A \param{keyword-name} can be any \term{symbol}, 
+but by convention is normally a \term{keyword}\meaning{1};
+all \term{standardized} \term{functions} follow that convention.
+
+%% 5.2.2 4
+An \term{ordinary lambda list} has five parts, any or all of which may be empty.
+For information about the treatment of argument mismatches,
+\seesection\FuncallErrorChecking.
+
+%% 5.2.2 9
+%% 5.2.2 11
+
+\beginsubsubsection{Specifiers for the required parameters}
+     
+These are all the parameter specifiers up to 
+the first \term{lambda list keyword};
+if there are no \term{lambda list keywords}, 
+then all the specifiers are for required parameters.
+Each required parameter is specified by a parameter variable \param{var}.
+\param{var} is bound as a lexical variable unless it is declared \declref{special}.
+
+%!!! Moon: There has been a cleanup that says when an error is signaled.
+If there are \f{n} required parameters (\f{n} may be zero), 
+there must be at least \f{n} passed arguments, and the 
+required parameters are bound to the first \f{n} passed arguments;
+\seesection\FuncallErrorChecking.
+The other parameters are then processed using any remaining arguments.
+
+\endsubsubsection%{Specifiers for the required parameters}
+
+
+%% 5.2.2 12
+\beginsubsubsection{Specifiers for optional parameters}
+\idxkeyref{optional}
+
+If \keyref{optional} is present,
+the optional parameter specifiers are those following 
+\keyref{optional} 
+up to the next \term{lambda list keyword} or the end of the list.
+If optional parameters are specified, then each one is processed as
+follows.  If any unprocessed arguments remain, then the parameter variable
+\param{var} is bound to the next remaining argument, just as for a required
+parameter.  If no arguments remain, however, then \param{init-form} 
+is evaluated, and the parameter variable
+is bound to the resulting value 
+(or to \nil\ if no \param{init-form} appears
+in the parameter specifier).
+If another variable name \param{supplied-p-parameter} 
+appears in the specifier, it is bound
+to \term{true} if an argument had been available, and to \term{false} if no
+argument remained (and therefore \param{init-form} had to be evaluated).
+\param{Supplied-p-parameter}
+is bound not to an argument but to a value indicating whether or not
+an argument had been supplied for the corresponding \param{var}.
+
+\endsubsubsection%{Specifiers for optional parameters}
+
+%% 5.2.2 13
+\beginsubsubsection{A specifier for a rest parameter}
+\idxkeyref{rest}
+
+\keyref{rest}, if present, must be followed by a single \term{rest parameter}
+specifier, which in turn must be followed by another 
+\term{lambda list keyword} or the end of the \term{lambda list}.  After all
+optional parameter specifiers have been processed, then there may or
+may not be a \term{rest parameter}.  If there is a \term{rest parameter}, it is
+bound to a \term{list} of all as-yet-unprocessed arguments.  If
+no unprocessed arguments remain, the \term{rest parameter} is bound to the
+\term{empty list}.  If there is no \term{rest parameter} and there are no 
+\term{keyword parameters}, then an error 
+%% Per Barrett #10 -- the actual type is more specific, and specified elsewhere. -kmp 7-May-93
+%\oftype{error}
+should be signaled if
+any unprocessed arguments remain; \seesection\FuncallErrorChecking.
+The value of a \term{rest parameter}
+is permitted, but not required, to share structure with the
+last argument to \funref{apply}.
+
+\endsubsubsection%{A specifier for a rest parameter}
+\idxkeyref{key}
+\idxkeyref{allow-other-keys}
+
+%% 5.2.2 14
+\beginsubsubsection{Specifiers for keyword parameters}
+                       
+\issue{PLIST-DUPLICATES:ALLOW}
+%!!! I didn't integrate item 5 of PLIST-DUPLICATES because it seemed dangerous
+%    to change this section for very little apparent gain.  There was no technical
+%    change implied by that item. -kmp 14-Jul-93
+If \keyref{key} 
+is present, all specifiers up to the next \term{lambda list keyword}
+or the end of the \term{list} are keyword parameter specifiers.
+When keyword parameters are processed,
+the same arguments are processed that
+would be made into a \term{list} for a \term{rest parameter}.
+It is permitted to specify both \keyref{rest} and \keyref{key}.
+In this case the remaining arguments are used for both purposes;
+that is, all remaining arguments are made into a \term{list} for the
+\term{rest parameter}, and are also processed for the \keyref{key} parameters.
+\issue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+If \keyref{key} is specified, there must remain
+an even number of arguments; \seesection\OddNumberOfKeyArgs.
+\endissue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+These arguments are considered as pairs,
+the first argument in each pair being interpreted as a name
+and the second as the corresponding value.
+The first \term{object} of each pair must be a \term{symbol};
+\seesection\InvalidKeyArgs.
+The keyword parameter specifiers may optionally be followed by the
+\term{lambda list keyword} \keyref{allow-other-keys}.
+
+%% 5.2.2 16
+In each keyword parameter specifier must be a name \param{var} for
+the parameter variable.
+\issue{KEYWORD-ARGUMENT-NAME-PACKAGE:ANY}
+If the \param{var} appears alone or in a \f{(\param{var} \param{init-form})}
+combination, the keyword name used when matching \term{arguments} to \term{parameters}
+is a \term{symbol} in \thepackage{keyword} whose \term{name} is the
+\term{same} (under \funref{string=}) as \param{var}'s.
+If the notation \f{((\param{keyword-name} \param{var}) \param{init-form})} is used,
+then the keyword name used to match \term{arguments} to \term{parameters} is
+\param{keyword-name}, which may be a \term{symbol} in any \term{package}.
+(Of course, if it is not a \term{symbol} in \thepackage{keyword},
+it does not necessarily self-evaluate, so care must be taken when calling the function
+to make sure that normal evaluation still yields the keyword name.)
+\endissue{KEYWORD-ARGUMENT-NAME-PACKAGE:ANY}
+Thus
+
+\code
+ (defun foo (&key radix (type 'integer)) ...)
+\endcode
+means exactly the same as
+
+\code
+ (defun foo (&key ((:radix radix)) ((:type type) 'integer)) ...)
+\endcode
+
+The keyword parameter specifiers are, like all parameter specifiers,
+effectively processed from left to right.  For each keyword parameter
+specifier, if there is an argument pair whose name matches that
+specifier's name (that is, the names are \funref{eq}), then the
+parameter variable for that specifier is bound to the second item (the
+value) of that argument pair.  If more than one such argument pair
+matches, the leftmost argument pair is used.  If no such argument pair
+exists, then the \param{init-form} for that specifier is evaluated and
+the parameter variable is bound to that value (or to \nil\ if no
+\param{init-form} was specified).  \param{supplied-p-parameter} is
+treated as for \keyref{optional} parameters: it is bound to \term{true} if there
+was a matching argument pair, and to \term{false} otherwise.
+
+%% 5.2.2 17
+Unless keyword argument checking is suppressed,
+an argument pair must a name matched by a parameter specifier;
+\seesection\UnrecognizedKeyArgs.
+
+%% 5.2.2 20
+% This makes no sense any more because the text referred to has been
+% rephrased and moved into its own section below.  -- sjl 3 Mar 92
+% If either condition obtains,
+If keyword argument checking is suppressed, 
+then it is permitted for an argument pair
+to match no parameter specifier, and the argument pair is ignored, but
+such an argument pair is accessible through the \term{rest parameter} if
+one was supplied.  The purpose of these mechanisms is to allow sharing
+of argument lists among several \term{lambda expressions} and to
+allow either the caller or the called \term{lambda expression} to
+specify that such sharing may be taking place.
+
+\issue{ALLOW-OTHER-KEYS-NIL:PERMIT}
+Note that if \keyref{key} is present, a keyword argument of \kwd{allow-other-keys}
+is always permitted---regardless of whether the associated value is \term{true}
+or \term{false}.  However, if the value is \term{false}, other non-matching
+keywords are not tolerated (unless \keyref{allow-other-keys} was used).
+
+Furthermore, if the receiving argument list specifies a regular argument which
+would be flagged by \kwd{allow-other-keys}, then \kwd{allow-other-keys} has both
+its special-cased meaning (identifying whether additional keywords are permitted)
+and its normal meaning (data flow into the function in question).
+\endissue{ALLOW-OTHER-KEYS-NIL:PERMIT}
+\endissue{PLIST-DUPLICATES:ALLOW}
+
+\beginsubsubsubsection{Suppressing Keyword Argument Checking}
+\DefineSection{SuppressingKeyArgChecks}
+
+If \keyref{allow-other-keys} was specified in the \term{lambda list} of a \term{function},
+\term{keyword}\meaning{2} \term{argument} checking is suppressed in calls
+to that \term{function}.
+
+If \thekeyarg{allow-other-keys} is \term{true} in a call to a \term{function},
+\term{keyword}\meaning{2} \term{argument} checking is suppressed 
+%% Clarified per Moon #10 (first public review). -kmp 6-May-93
+%in calls to that \term{function}.
+in that call.
+
+\Thekeyarg{allow-other-keys} is permissible in all situations involving
+\term{keyword}\meaning{2} \term{arguments}, even when its associated \term{value}
+is \term{false}.
+
+\beginsubsubsubsubsection{Examples of Suppressing Keyword Argument Checking}
+
+\code
+;;; The caller can supply :ALLOW-OTHER-KEYS T to suppress checking.
+ ((lambda (&key x) x) :x 1 :y 2 :allow-other-keys t) \EV 1
+;;; The callee can use &ALLOW-OTHER-KEYS to suppress checking.
+ ((lambda (&key x &allow-other-keys) x) :x 1 :y 2) \EV 1
+;;; :ALLOW-OTHER-KEYS NIL is always permitted.
+ ((lambda (&key) t) :allow-other-keys nil) \EV T
+;;; As with other keyword arguments, only the left-most pair
+;;; named :ALLOW-OTHER-KEYS has any effect.
+ ((lambda (&key x) x) 
+  :x 1 :y 2 :allow-other-keys t :allow-other-keys nil)
+\EV 1
+;;; Only the left-most pair named :ALLOW-OTHER-KEYS has any effect,
+;;; so in safe code this signals a PROGRAM-ERROR (and might enter the
+;;; debugger).  In unsafe code, the consequences are undefined.
+ ((lambda (&key x) x)                   ;This call is not valid
+  :x 1 :y 2 :allow-other-keys nil :allow-other-keys t)
+\endcode
+
+\endsubsubsubsubsection%{Examples of Suppressing Keyword Argument Checking}
+
+\endsubsubsubsection%{Suppressing Keyword Argument Checking}
+
+\endsubsubsection%{Specifiers for keyword parameters}
+
+%% 5.2.2 21
+\beginsubsubsection{Specifiers for \keyref{aux} variables}
+\idxkeyref{aux}
+
+These are not really parameters.  If the \term{lambda list keyword}
+\keyref{aux} is present, all specifiers after it are auxiliary variable
+specifiers.  After all parameter specifiers have been processed, the
+auxiliary variable specifiers (those following {\aux}) are processed
+from left to right.  For each one, \param{init-form} is evaluated and
+\param{var} is bound to that value (or to \nil\ if no \param{init-form}
+was specified).  \keyref{aux} variable processing is analogous to
+\specref{let*} processing.
+
+\code
+ (lambda (x y &aux (a (car x)) (b 2) c) (list x y a b c))
+    \EQ (lambda (x y) (let* ((a (car x)) (b 2) c) (list x y a b c)))
+\endcode
+
+\endsubsubsection%{Specifiers for \keyref{aux} variables}
+
+\beginsubsubsection{Examples of Ordinary Lambda Lists}
+
+Here are some examples involving \term{optional parameters} and \term{rest parameters}:
+
+\code
+ ((lambda (a b) (+ a (* b 3))) 4 5) \EV 19
+ ((lambda (a &optional (b 2)) (+ a (* b 3))) 4 5) \EV 19
+ ((lambda (a &optional (b 2)) (+ a (* b 3))) 4) \EV 10
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)))
+\EV (2 NIL 3 NIL NIL)
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)) 6)
+\EV (6 T 3 NIL NIL)
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)) 6 3)
+\EV (6 T 3 T NIL)
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x)) 6 3 8)
+\EV (6 T 3 T (8))
+ ((lambda (&optional (a 2 b) (c 3 d) &rest x) (list a b c d x))
+  6 3 8 9 10 11)
+\EV (6 t 3 t (8 9 10 11))
+\endcode
+
+Here are some examples involving \term{keyword parameters}:
+
+\code
+ ((lambda (a b &key c d) (list a b c d)) 1 2) \EV (1 2 NIL NIL)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :c 6) \EV (1 2 6 NIL)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :d 8) \EV (1 2 NIL 8)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :c 6 :d 8) \EV (1 2 6 8)
+ ((lambda (a b &key c d) (list a b c d)) 1 2 :d 8 :c 6) \EV (1 2 6 8)
+ ((lambda (a b &key c d) (list a b c d)) :a 1 :d 8 :c 6) \EV (:a 1 6 8)
+ ((lambda (a b &key c d) (list a b c d)) :a :b :c :d) \EV (:a :b :d NIL)
+ ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6) \EV (1 2 6 NIL)
+ ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6) \EV (1 2 6 NIL)
+\endcode
+
+Here are some examples involving \term{optional parameters}, \term{rest parameters},
+and \term{keyword parameters} together:
+
+\code
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1)   
+\EV (1 3 NIL 1 ()) 
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 2)
+\EV (1 2 NIL 1 ())
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) :c 7)
+\EV (:c 7 NIL :c ())
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 6 :c 7)
+\EV (1 6 7 1 (:c 7))
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 6 :d 8)
+\EV (1 6 NIL 8 (:d 8))
+ ((lambda (a &optional (b 3) &rest x &key c (d a))
+    (list a b c d x)) 1 6 :d 8 :c 9 :d 10)
+\EV (1 6 9 8 (:d 8 :c 9 :d 10))
+\endcode
+
+%% 5.2.2 28
+As an example of the use of \keyref{allow-other-keys} and
+\kwd{allow-other-keys}, consider a \term{function} that takes two named
+arguments of its own and also accepts additional named arguments to be
+passed to \funref{make-array}:
+
+\code
+ (defun array-of-strings (str dims &rest named-pairs
+                          &key (start 0) end &allow-other-keys)
+   (apply #'make-array dims
+          :initial-element (subseq str start end)
+          :allow-other-keys t
+          named-pairs))
+\endcode
+
+This \term{function} takes a \term{string} and dimensioning
+information and returns an \term{array} of the specified
+dimensions, each of whose elements is the specified 
+\term{string}.  However, \kwd{start} and \kwd{end} named
+arguments may be used to specify that a substring of the given
+\term{string} should be used.  In addition, the presence of
+\keyref{allow-other-keys} in the \term{lambda list} indicates that the
+caller may supply additional named arguments; the \term{rest parameter}
+provides access to them.  These additional named arguments are passed
+to \funref{make-array}.  The \term{function} \funref{make-array}
+normally does not allow the named arguments \kwd{start} 
+and \kwd{end} to be used, and an error should be
+signaled if such named arguments are supplied to \funref{make-array}.
+However, the presence in the call to \funref{make-array} 
+of the named argument \kwd{allow-other-keys} with
+a \term{true} value causes any extraneous named arguments, including
+\kwd{start} and \kwd{end}, to be acceptable and ignored.
+
+\endsubsubsection%{Examples of Ordinary Lambda Lists}
+
+\endsubSection%{Ordinary Lambda Lists}
+
+\beginsubSection{Generic Function Lambda Lists}
+\DefineSection{GFLambdaLists}
+
+A \newterm{generic function lambda list} is used to describe the overall shape of
+the argument list to be accepted by a \term{generic function}.
+Individual \term{method} \term{signatures} might contribute additional 
+\term{keyword parameters} to the \term{lambda list} of the \term{effective method}.
+
+%% Might as well not use a table while there's only one. -kmp 15-Feb-92
+A \term{generic function lambda list} is used by \macref{defgeneric}.
+% \Thenextfigure\ lists the \term{operators} that use \term{generic function lambda lists}.
+% 
+% %!!! This table is just a seed and might be incomplete. -kmp 2-Aug-91
+% \issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% \displaythree{Standardized Operators that use Generic Function Lambda Lists}{
+% defgeneric&&\cr
+% % defgeneric&generic-function&\cr
+% % generic-flet&generic-labels&\cr
+% }
+% \endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+A \term{generic function lambda list} has the following syntax:
+
+\Vskip 1pc!
+\auxbnf{lambda-list}{\lparen\starparam{var}\CR
+		     \ \ttbrac{{\opt} \star{\JustVar}}\CR
+		     \ \ttbrac{{\rest} \param{var}}\CR
+		     \ \f{[}\Vtop{\hbox{{\key} \star{\JustKey}}
+				  \vskip 4pt
+				  \hbox{\brac{\allowotherkeys}\f{]}\rparen}}\CR}
+
+A \term{generic function lambda list} can contain the \term{lambda list keywords} shown
+in \thenextfigure.
+
+\showthree{Lambda List Keywords used by Generic Function Lambda Lists}{
+\keyref{allow-other-keys}&\keyref{optional}&\cr
+\keyref{key}&\keyref{rest}&\cr
+}
+
+A \term{generic function lambda list} differs from an \term{ordinary lambda list} 
+in the following ways:
+ 
+\beginlist
+\itemitem{\bf Required arguments}
+
+% %Per Barmar. -kmp 28-Dec-90
+% %At least one
+%% Per Moon. -kmp 16-Feb-92
+Zero or more \term{required parameters} must be specified.
+
+\itemitem{\bf Optional and keyword arguments}
+ 
+\term{Optional parameters} and \term{keyword parameters} may not have 
+default initial value forms nor use supplied-p parameters.
+
+\itemitem{\bf Use of \keyref{aux}}
+
+The use of \keyref{aux} is not allowed. 
+\endlist
+
+\endsubSection%{Generic Function Lambda Lists}
+
+\goodbreak
+\beginsubSection{Specialized Lambda Lists}
+\DefineSection{SpecializedLambdaLists}
+
+A \newterm{specialized lambda list} is used to \term{specialize} a \term{method}
+for a particular \term{signature} and to describe how \term{arguments} matching
+that \term{signature} are received by the \term{method}.  
+The \term{defined names} in \thenextfigure\ use \term{specialized lambda lists}
+in some way; see the dictionary entry for each for information about how.
+
+%!!! This table is just a seed and probably incomplete. -kmp 2-Aug-91
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\displaythree{Standardized Operators that use Specialized Lambda Lists}{
+defmethod&defgeneric&\cr
+}
+% GENERIC-FUNCTION, GENERIC-FLET, and GENERIC-LABELS removed.
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+A \term{specialized lambda list} can contain the \term{lambda list keywords} shown
+in \thenextfigure.
+
+\showthree{Lambda List Keywords used by Specialized Lambda Lists}{
+\keyref{allow-other-keys}&\keyref{key}&\keyref{rest}\cr
+\keyref{aux}&\keyref{optional}&\cr
+}
+
+A \term{specialized lambda list} is syntactically the same as an \term{ordinary lambda list}
+except that each \term{required parameter} may optionally be associated with a \term{class}
+or \term{object} for which that \term{parameter} is \term{specialized}.
+
+\Vskip 1pc!
+\auxbnf{lambda-list}{\lparen\star{\SpecializedVar}\CR
+		     \xparen\ttbrac{{\opt} \star{\VarValueSuppliedP}}\CR
+		     \xparen\ttbrac{{\rest} \param{var}}\CR
+		     \xparen\ttbrac{{\key} \star{\KeyVarValueSuppliedP} \brac{\allowotherkeys}}\CR
+		     \xparen\ttbrac{{\aux} \star{\VarValue}}\rparen\CR}
+
+%!!! Need to write more.
+
+\endsubSection%{Specialized Lambda Lists}
+
+\beginsubSection{Macro Lambda Lists}
+\DefineSection{MacroLambdaLists}
+
+A \newterm{macro lambda list} is used in describing \term{macros} 
+defined by the \term{operators} in \thenextfigure.
+
+%!!! This table is just a seed and probably incomplete. -kmp 2-Aug-91
+% I added define-compiler-macro --sjl 5 Mar 92
+\displaythree{Operators that use Macro Lambda Lists}{
+define-compiler-macro&defmacro&macrolet\cr
+define-setf-expander& &\cr
+}
+
+With the additional restriction that
+an \term{environment parameter} may appear only once
+(at any of the positions indicated),
+a \term{macro lambda list} has the following syntax:
+
+%% Some changes here per X3J13. -kmp 05-Oct-93
+\Vskip 1pc!
+{\def\TVar{\curly{\param{var} | \down{pattern}}}\def\starTVar{\star{\TVar}}
+\auxbnf{reqvars}{\starTVar}
+\auxbnf{optvars}{\ttbrac{{\opt} \star{\VarValueSuppliedP}}}
+\auxbnf{restvar}{\ttbrac{\curly{{\rest} | {\body}} \param{\TVar}}}
+\auxbnf{keyvars}{\lbrac{\key} \star{\KeyVarValueSuppliedP}\CR
+		 \xbrac\brac{\allowotherkeys}\rbrac}
+{\let\TVar=\GTVar\let\starTVar=\GstarTVar%
+\auxbnf{auxvars}{\ttbrac{{\aux} \star{\VarValue}}}}
+\auxbnf{envvar}{\ttbrac{{\environment} \param{var}}}
+%Per X3J13 (05-Oct-93), prohibit destructuring of whole variable. -kmp
+\auxbnf{wholevar}{\ttbrac{{\whole} \param{var}}}
+\auxbnf{lambda-list}%
+{\lparen\down{wholevar} \down{envvar}
+ \xparen\down{reqvars}  \down{envvar}
+ \xparen\down{optvars}  \down{envvar}\CR
+ \xparen\down{restvar}  \down{envvar}
+ \xparen\down{keyvars}  \down{envvar}
+ \xparen\down{auxvars}  \down{envvar}\rparen\ |\CR
+ \lparen\down{wholevar} \down{envvar}
+ \xparen\down{reqvars}  \down{envvar}
+ \xparen\down{optvars}  \down{envvar} \f{.}
+%Per x3j13, "\down{restvar}" => "var"
+ \xparen\param{var}\rparen}
+\auxbnf{pattern}%
+{\paren{\down{wholevar}
+        \down{reqvars}
+        \down{optvars}
+        \down{restvar}
+        \down{keyvars}
+        \down{auxvars}} |\CR
+ \paren{\down{wholevar} \down{reqvars} \down{optvars} \f{.}
+%Per x3j13, "\down{restvar}" => "var"
+        \param{var}}}
+}
+\Vskip 1pc!
+
+A \term{macro lambda list} can contain
+the \term{lambda list keywords} shown in \thenextfigure.
+
+\showthree{Lambda List Keywords used by Macro Lambda Lists}{
+\keyref{allow-other-keys}&\keyref{environment}&\keyref{rest}\cr
+\keyref{aux}&\keyref{key}&\keyref{whole}\cr
+\keyref{body}&\keyref{optional}&\cr
+}
+
+\term{Optional parameters} (introduced by \keyref{optional}) and
+\term{keyword parameters} (introduced by \keyref{key})
+can be supplied in a \term{macro lambda list},
+just as in an \term{ordinary lambda list}.
+Both may contain default initialization forms and \term{supplied-p parameters}.
+ 
+%% 8.1.0 10
+\keyref{body}\idxkeyref{body}
+is identical in function to \keyref{rest},
+but it can be used to inform certain output-formatting 
+and editing functions that the remainder of the \term{form} is
+treated as a body, and should be indented accordingly.
+Only one of \keyref{body} or \keyref{rest} can be used at any particular level; 
+\seesection\DestructuringByLambdaLists.
+\issue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+\keyref{body} can appear at any level of a 
+\term{macro lambda list}; 
+for details, \seesection\DestructuringByLambdaLists.
+\endissue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+ 
+%% 8.1.0 11
+\keyref{whole}\idxkeyref{whole}
+is followed by a single variable that is bound to the
+entire macro-call form; this is the value that the \term{macro function}
+receives as its first argument.
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+%\keyref{whole} and the following variable should appear first in the \term{lambda list},
+If \keyref{whole} and a following variable appear,
+they must appear first in \param{lambda-list},
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+before any other parameter or \term{lambda list keyword}.
+\issue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+\keyref{whole} can appear at any level of a \term{macro lambda list}. 
+At inner levels, the \keyref{whole} variable is bound to
+		the corresponding part of the argument, 
+as with \keyref{rest}, but unlike \keyref{rest}, other arguments are also allowed.
+The use of \keyref{whole} does not affect the pattern of arguments
+     specified.
+%% Per moon
+%by \macref{defmacro}.
+\endissue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+
+%% 8.1.0 12
+\keyref{environment}\idxkeyref{environment}
+is followed by a single variable that is bound
+to an \term{environment} representing the \term{lexical environment} in which the
+% I have clarified the bit about compilation environments below, so this
+% is no longer necessary.  --sjl 5 Mar 92
+% macro call is to be interpreted---this is either the \term{lexical environment}
+% or the compilation \term{environment}.
+macro call is to be interpreted.
+This \term{environment} 
+%%sandra's suggested deletion
+%might not be the
+%complete \term{lexical environment}; it 
+should be used with
+\issue{MACRO-FUNCTION-ENVIRONMENT:YES}
+\funref{macro-function},
+\endissue{MACRO-FUNCTION-ENVIRONMENT:YES}
+\issue{GET-SETF-METHOD-ENVIRONMENT:ADD-ARG}
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\funref{get-setf-expansion},
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\endissue{GET-SETF-METHOD-ENVIRONMENT:ADD-ARG}
+\issue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+% \funref{variable-information}, 
+% \funref{function-information}, \funref{declaration-information},
+% \funref{augment-environment}, \funref{parse-macro}, \funref{enclose}
+\endissue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+\funref{compiler-macro-function}, 
+%\funref{compiler-macroexpand}, \funref{compiler-macroexpand-1},
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+and
+\funref{macroexpand} 
+% !!! Sandra:
+%   This isn't correct.  Environments should also be used with things like
+%   SUBTYPEP and CONSTANTP, and not "only" to make local macro definitions
+%   available.
+% I have reworded this; see replacement text below.  --sjl 5 Mar 92
+% for the sake of any local macro definitions
+% that the \specref{macrolet} \term{form} might have
+% established within that  \term{environment}.  
+(for example) in computing the expansion of the macro, to ensure that any
+\term{lexical bindings} or definitions established in the 
+\term{compilation environment} are taken into account.
+\issue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+\keyref{environment} can only appear at the top level of a
+	\term{macro lambda list}, and can only
+appear once, but can appear anywhere in that list;
+\endissue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+\issue{&ENVIRONMENT-BINDING-ORDER:FIRST}
+the \keyref{environment} \term{parameter} is \term{bound} along with \keyref{whole}
+before any other \term{variables} in the \term{lambda list}, regardless of where
+\keyref{environment} appears in the \term{lambda list}.
+\endissue{&ENVIRONMENT-BINDING-ORDER:FIRST}
+\issue{MACRO-ENVIRONMENT-EXTENT:DYNAMIC}
+The \term{object} that is bound to the
+\term{environment parameter} has \term{dynamic extent}.
+%% Moon: Redundant.
+% the consequences are undefined if 
+% the \term{object} that is bound to the
+% \term{environment parameter} is referred to outside the \term{dynamic extent} 
+% of the macro call.
+\endissue{MACRO-ENVIRONMENT-EXTENT:DYNAMIC}
+ 
+%% 8.1.0 24
+Destructuring allows a \term{macro lambda list} to express
+the structure of a macro call syntax.
+If no \term{lambda list keywords} appear,
+then the \term{macro lambda list} is a \term{tree}
+containing parameter names at the leaves.
+%The following wording revised to be more explicit. -kmp 2-Aug-91
+The pattern and the \term{macro form} must have compatible \term{tree structure}; 
+that is, their \term{tree structure} must be equivalent,
+or it must differ only in that some \term{leaves} of the pattern
+match \term{non-atomic} \term{objects} of the \term{macro form}.
+\issue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+For information about error detection in this \term{situation},
+\seesection\DestructuringMismatch.
+\endissue{ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT}
+
+% I thought it was important to mention that macro lambda lists can be
+% dotted before talking about the restriction about dotted macro forms
+% below.  This paragraph was formerly in its own subsection at the very
+% end.  --sjl 5 Mar 92
+
+\DefineSection{ExtraDestructureInfo}
+%% 8.1.0 15
+%Destructuring specifies that \macref{defmacro} allows any \term{lambda list}
+%% For Moon:
+A destructuring \term{lambda list}
+(whether at top level or embedded) 
+%to
+can
+be dotted, ending
+in a parameter name.  This situation is treated exactly as if the
+parameter name that ends the \term{list} had appeared preceded by \keyref{rest}.
+
+
+%!!! Barmar suggests changing "subexpression" to "subform" here.
+%    He writes:  The point is that the automatic destructuring can only handle
+%     dotted lists when &rest or .var are used, or when the dotted list is a subform
+%     that matches a variable in the lambda list.
+\issue{DOTTED-MACRO-FORMS:ALLOW}
+It is permissible for a \term{macro} \term{form} (or a \term{subexpression} of a
+\term{macro} \term{form})
+to be a \term{dotted list} 
+only  when \f{(... \&rest var)} or \f{(... . var)} is used to match
+ it. It is the responsibility of the \term{macro} to recognize and deal
+ with such situations.
+\editornote{KMP: Apparently the dotted-macro-forms cleanup doesn't allow for
+		 the macro to `manually' notice dotted forms and fix them as well.
+		 It shouldn't be required that this be done only by \&REST or 
+		 a dotted pattern; it should only matter that ultimately the 
+		 non-macro result of a full-macro expansion not contain dots.
+		 Anyway, I plan to address this editorially unless someone
+		 raises an objection.}%!!! 16-Jan-91
+\endissue{DOTTED-MACRO-FORMS:ALLOW}
+
+\beginsubsubsection{Destructuring by Lambda Lists}
+\DefineSection{DestructuringByLambdaLists}
+
+%% 8.1.0 14
+% minor rewording to use new terminology -- sjl 5 Mar 92
+Anywhere in a \term{macro lambda list} where a parameter
+name can appear, and where \term{ordinary lambda list} syntax
+(as described in \secref\OrdinaryLambdaLists) does not 
+otherwise allow a \term{list}, a \term{destructuring lambda list} 
+can appear in place
+of the parameter name.  When this is done, then the argument 
+that would match the parameter is treated as a (possibly dotted) \term{list},
+to be used as an argument list for satisfying the
+parameters in the embedded \term{lambda list}.
+This is known as destructuring.
+ 
+%%% Moon's destructuring wording
+
+%Note that data-directed destructuring
+%is what Common Lisp has, and you would not want to include the parts
+%about program-directed destructuring, which Common Lisp has not adopted.
+%Lambda-list-directed destructuring is what defmacro and destructuring-bind
+%do in Common Lisp.
+
+Destructuring is the process of decomposing a compound \term{object} into
+its component parts, using an abbreviated, declarative syntax, rather
+than writing it out by hand using the primitive component-accessing
+functions.  Each component part is bound to a variable.
+% I don't believe the following two sentences are relevant to the
+% current state of Common Lisp.  --sjl 5 Mar 92
+% The variables
+% can either be \term{assigned} or \term{bound}.  As an extension, some 
+% component parts can be ignored and not assigned to a variable.
+ 
+%% KAB wanted this flushed. -kmp 9-Feb-92
+% Destructuring is most often used to take apart \term{trees}.
+% However it also makes sense to destructure \term{vectors}
+% and \macref{defstruct}-defined structures.  
+% Note that in the latter case an \term{object} is being destructured
+% whose components are identified by name,
+% rather than by position as in the case of 
+% \term{trees} and \term{vectors}.  
+%%Barmar wanted this flushed since it isn't valid. I concur. -kmp 28-Dec-90
+% In fact
+% the idea of destructuring can sensibly be extended to compound objects
+% that are not primitive \term{objects} of Lisp, 
+% but have conceptual components.
+% Thus a \term{rational} number can be destructured into its numerator and
+% denominator, a \term{two-way stream} 
+% into its input and output components, a
+% byte specifier into its position and size, or
+% the multiple values of a \term{function} into the individual values.  The
+% important point is that the conceptual operation of extracting several
+% components of a compound \term{object} is common to all of these applications.
+ 
+%Destructuring of \term{trees} 
+%is especially important in programs such as macros
+%and compilers that manipulate Lisp code, because Lisp code is represented
+%as trees.
+ 
+A destructuring operation requires an \term{object} to be decomposed, 
+a pattern that specifies what components are to be extracted, and the names
+of the variables whose values are to be the components.
+%% KMP: I removed this because I couldn't figure out what the non-SETQ case was.
+%%      Seems like it was probably referring to DESETQ, which isn't in the language.
+% In the non-\specref{setq} case,
+% a destructuring operation requires a body that
+% constitutes the scope of the variables to be bound.
+ 
+\beginsubsubsubsection{Data-directed Destructuring by Lambda Lists}
+
+In data-directed destructuring,
+the pattern is a sample \term{object} of the \term{type} to be decomposed.
+Wherever a component is to be extracted, 
+a \term{symbol} appears in the pattern; 
+this \term{symbol} is the name of the variable whose value will be that component.
+%% This is just rationale, not description. -kmp 2-Aug-91
+% Data-directed destructuring 
+% only works well
+% for \term{trees} and \term{vectors}.  
+% The components to be extracted must be
+% identified by position rather than by name.  Data-directed destructuring
+% cannot be extended to \term{objects} such as 
+% \term{rationals} whose components
+% are not allowed to be \term{symbols}, 
+% and cannot be extended to conceptual
+% \term{objects} such as multiple values, where it is impossible to create a
+% sample \term{object}.
+ 
+\beginsubsubsubsubsection{Examples of Data-directed Destructuring by Lambda Lists}
+
+An example pattern is
+ 
+{\tt 	(a b c)}
+ 
+which destructures a list of three elements.  The variable \f{a} is assigned
+to the first element, \f{b} to the second, etc.  A more complex example
+is
+
+{\tt 	((first . rest) . more)}
+ 
+The important features of data-directed destructuring are its syntactic
+simplicity and the ability to extend it to lambda-list-directed destructuring.
+
+\endsubsubsubsubsection%{Examples of Data-directed Destructuring by Lambda Lists}
+
+\endsubsubsubsection%{Data-directed Destructuring by Lambda Lists}
+
+\beginsubsubsubsection{Lambda-list-directed Destructuring by Lambda Lists}
+
+An extension of data-directed destructuring of \term{trees} is
+lambda-list-directed destructuring.  This derives from the analogy
+between the three-element destructuring pattern
+ 
+{\tt 	(first second third)}
+ 
+and the three-argument \term{lambda list}
+ 
+{\tt	(first second third)}
+ 
+%The \term{lambda list} of a function can be thought of as destructuring the
+%list of arguments to which the function was \term{applied}.
+%In most Lisp
+%implementations this list is only conceptual most of the time, for the
+%sake of efficiency.
+
+Lambda-list-directed destructuring is identical to data-directed destructuring
+if no \term{lambda list keywords} appear in the pattern.  
+Any list in the pattern (whether a sub-list or the whole pattern itself)
+that contains a \term{lambda list keyword} is interpreted specially.
+Elements of the list to the left of the first
+\term{lambda list keyword} are treated as destructuring patterns, as usual, but the
+remaining elements of the list are treated like a function's 
+\term{lambda list}
+except that where a variable would normally be required, an arbitrary
+destructuring pattern is allowed.  Note that in case of ambiguity,
+\term{lambda list} syntax is preferred over destructuring syntax.  Thus, after
+\keyref{optional} a list of elements is a list of a destructuring pattern
+and a default value form.
+ 
+The detailed behavior of each \term{lambda list keyword} in a 
+lambda-list-directed destructuring
+pattern is as follows:
+
+\beginlist
+\itemitem{\keyref{optional}}
+
+Each following element is a variable or a list of a destructuring
+pattern, a default value form, and a supplied-p variable.  The default value and
+the supplied-p variable can be omitted.  
+If the list being destructured ends
+early, so that it does not have an element to match against this destructuring
+(sub)-pattern, the default form is evaluated and destructured instead.  The
+supplied-p variable receives the value 
+\nil\ if the default form is used, \t\ otherwise.
+ 
+\itemitem{\keyref{rest}, \keyref{body}}
+
+The next element is a destructuring pattern that matches the
+rest of the list.  \keyref{body} is identical to \keyref{rest} but declares that what
+is being matched is a list of forms that constitutes the body of \term{form}.
+This next element must be the last unless a \term{lambda list keyword} follows it.
+ 
+\itemitem{\keyref{aux}} 
+
+The remaining elements are not destructuring patterns at all, but are
+auxiliary variable bindings.  
+%This does not make a whole lot of sense when
+%the destructuring is being used to \specref{setq} rather than to bind variables.
+ 
+\itemitem{\keyref{whole}}
+
+The next element is a destructuring pattern that matches the entire
+form in a macro, or the entire \term{subexpression} at inner levels.
+\issue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+%% Take out next sentences due to DEFMACRO-LAMBDA-LIST
+%\keyref{whole} only makes sense in \macref{defmacro} and only at top level.
+%This next element must be the last unless a \term{lambda list keyword} 
+%follows it.
+\endissue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+ 
+\itemitem{\keyref{key}}
+
+Each following element is one of
+\beginlist
+
+\itemitem{}
+ a \term{variable},
+
+\itemitem{or}
+ a list of a variable,
+           an optional initialization form,
+       and an optional supplied-p variable.
+
+\itemitem{or}
+ a list of a list of a keyword and a destructuring pattern,
+           an optional initialization form,
+       and an optional supplied-p variable.
+\endlist
+The rest of the list being destructured
+is taken to be alternating keywords and values and is taken apart appropriately.
+ 
+\itemitem{\keyref{allow-other-keys}}
+
+Stands by itself.
+\endlist 
+%{--- The above has some terminology problems.  The distinction between the
+%list which is a sub-list of the pattern and the corresponding sub-list of
+%the object being destructured is muddled in places.}
+ 
+\endsubsubsubsection%{Lambda-list-directed Destructuring by Lambda Lists}
+
+% \beginsubsubsubsection{Additional Information about Destructuring by Lambda Lists}
+% \DefineSection{ExtraDestructureInfo}
+
+% I moved the text about dotted lambda lists to earlier in this section.
+% -- sjl 5 Mar 92
+
+
+% \endsubsubsubsection%{Additional Information about Destructuring by Lambda Lists}
+
+\endsubsubsection%{Destructuring by Lambda Lists}
+
+\endsubSection%{Macro Lambda Lists}
+
+
+% This entire section is new.  --sjl 5 Mar 92
+\beginsubsection{Destructuring Lambda Lists}
+\DefineSection{DestructuringLambdaLists}
+
+A \newterm{destructuring lambda list} is used by \macref{destructuring-bind}.
+
+\term{Destructuring lambda lists} are closely related to 
+\term{macro lambda lists}; \seesection\MacroLambdaLists.
+A \term{destructuring lambda list} can contain all of the
+\term{lambda list keywords} listed for \term{macro lambda lists}
+except for \keyref{environment}, and supports destructuring in the
+same way.  Inner \term{lambda lists} nested within a \term{macro lambda list}
+have the syntax of \term{destructuring lambda lists}.
+
+A \term{destructuring lambda list} has the following syntax:
+
+\Vskip 1pc!
+{\def\TVar{\curly{\param{var} | \down{lambda-list}}}\def\starTVar{\star{\TVar}}
+\auxbnf{reqvars}{\starTVar}
+\auxbnf{optvars}{\ttbrac{{\opt} \star{\VarValueSuppliedP}}}
+\auxbnf{restvar}{\ttbrac{\curly{{\rest} | {\body}} \param{\TVar}}}
+\auxbnf{keyvars}{\lbrac{\key} \star{\KeyVarValueSuppliedP}\CR
+		 \xbrac\brac{\allowotherkeys}\rbrac}
+{\let\TVar=\GTVar\let\starTVar=\GstarTVar%
+\auxbnf{auxvars}{\ttbrac{{\aux} \star{\VarValue}}}}
+\auxbnf{envvar}{\ttbrac{{\environment} \param{var}}}
+%Per X3J13 (05-Oct-93), prohibit destructuring of whole variable. -kmp
+\auxbnf{wholevar}{\ttbrac{{\whole} \param{var}}}
+\auxbnf{lambda-list}%
+{\paren{\down{wholevar}
+        \down{reqvars}
+        \down{optvars}
+        \down{restvar}
+        \down{keyvars}
+        \down{auxvars}} |\CR
+ \paren{\down{wholevar} \down{reqvars} \down{optvars} \f{.}
+%Per x3j13, "\down{restvar}" => "var"
+	 \param{var}}}
+}
+\Vskip 1pc!
+
+\endsubsection%{Destructuring Lambda Lists}
+
+
+
+\beginsubsection{Boa Lambda Lists}
+\DefineSection{BoaLambdaLists}
+
+A \newterm{boa lambda list} is a \term{lambda list} that is syntactically 
+like an \term{ordinary lambda list}, but that is processed in
+``\b{b}y \b{o}rder of \b{a}rgument'' style.
+
+A \term{boa lambda list} is used only in a \macref{defstruct} \term{form},
+when explicitly specifying the \term{lambda list} 
+of a constructor \term{function} (sometimes called a ``boa constructor'').
+
+%% 19.6.0 2
+The \keyref{optional}, \keyref{rest}, \keyref{aux},
+\issue{DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY}
+\keyref{key}, and \keyref{allow-other-keys}
+\endissue{DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY}
+\term{lambda list keywords} are recognized in a \term{boa lambda list}.
+The way these \term{lambda list keywords} differ from their
+use in an \term{ordinary lambda list} follows.
+
+Consider this example, which describes how \macref{destruct} processes
+its \kwd{constructor} option.
+
+\code
+ (:constructor create-foo
+         (a &optional b (c 'sea) &rest d &aux e (f 'eff)))
+\endcode
+
+This defines \f{create-foo} to be a constructor of one or more arguments.
+The first argument is used to initialize the \f{a} slot.  The second
+argument is used to initialize the \f{b} slot.  If there isn't any
+second argument, then the default value given in the body of the
+\macref{defstruct} (if given) is used instead.  
+The third argument is used to
+initialize the \f{c} slot.  If there isn't any third argument, then the
+symbol \f{sea} is used instead.  Any arguments following the third
+argument are collected into a \term{list} 
+and used to initialize the \f{d}
+slot.  If there are three or fewer arguments, then \nil\ is placed in
+the \f{d} slot.  The \f{e} slot is not initialized; 
+its initial value is \term{implementation-defined}.
+Finally, the \f{f} slot is initialized to contain the symbol \f{eff}.
+\issue{DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY}
+\keyref{key} and \keyref{allow-other-keys} arguments default
+in a manner similar to that of \keyref{optional} arguments: if no default
+is supplied in the \term{lambda list} then the default value 
+given in the body of the \macref{defstruct} (if given) is used instead.
+%% Removed per Moon as redundant.
+% then the slot initform is used;
+% otherwise the slot is not initialized, its initial value is
+% undefined.                                
+For example:
+
+\code
+ (defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
+                                             &key (d 2)
+                                             &aux e (f 'eff))))
+   (a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
+ 
+ (create-foo 10) \EV #S(FOO A 10 B 2 C SEA D 2 E \term{implemention-dependent} F EFF)
+ (create-foo 10 'bee 'see :d 'dee) 
+\EV #S(FOO A 10 B BEE C SEE D DEE E \term{implemention-dependent} F EFF)
+\endcode
+
+If keyword arguments of the form 
+\f{((\i{key} \i{var}) \brac{\i{default} \brac{\i{svar}}})}
+are specified, the \term{slot} \term{name} is matched with \i{var} 
+(not \i{key}).
+
+%% 19.6.0 3
+The actions taken in the \f{b} and \f{e} cases were carefully
+chosen to allow the user to specify all possible behaviors. 
+The \keyref{aux} variables can be used to completely override the default
+initializations given in the body.
+
+\issue{BOA-AUX-INITIALIZATION:ERROR-ON-READ}
+If no default value is supplied for an \term{aux variable} variable,
+the consequences are undefined if an attempt is later made to read
+the corresponding \term{slot}'s value before a value is explicitly assigned.
+If such a \term{slot} has a \kwd{type} option specified,
+this suppressed initialization does not imply a type mismatch situation;
+the declared type is only required to apply when the \term{slot} is finally assigned.
+\endissue{BOA-AUX-INITIALIZATION:ERROR-ON-READ}
+
+%% 19.6.0 4
+With this definition, the following can be written:
+
+\code
+ (create-foo 1 2)
+\endcode
+instead of
+
+\code
+ (make-foo :a 1 :b 2)
+\endcode
+and \f{create-foo} provides defaulting different
+from that of \f{make-foo}.
+
+Additional arguments that do not correspond to slot names but
+are merely present to supply values used in subsequent initialization 
+computations are allowed.
+For example, in the definition
+
+\code
+ (defstruct (frob (:constructor create-frob
+                  (a &key (b 3 have-b) (c-token 'c) 
+                          (c (list c-token (if have-b 7 2))))))
+         a b c)
+\endcode
+ 
+the {\tt c-token} argument is used merely to supply a value used in the 
+initialization of the {\tt c} slot. The \term{supplied-p parameters} 
+associated with \term{optional parameters} and \term{keyword parameters}
+might also be used this way.
+ 
+\endissue{DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY}
+
+\endsubsection%{Boa Lambda Lists}
+
+\beginsubSection{Defsetf Lambda Lists}
+\DefineSection{DefsetfLambdaLists}
+
+A \newterm{defsetf lambda list} is used by \macref{defsetf}.
+
+A \term{defsetf lambda list} has the following syntax:
+
+%I added &allow-other-keys here because it seemed stupid for that to be missing
+%if &key was possible.
+\Vskip 1pc!
+\auxbnf{lambda-list}{\lparen\starparam{var}\CR
+		     \xparen\ttbrac{{\opt} \star{\VarValueSuppliedP}}\CR
+		     \xparen\ttbrac{{\rest} \param{var}}\CR
+		     \xparen\f{[}\Vtop{\hbox{{\key} \star{\KeyVarValueSuppliedP}}
+				  \vskip 4pt
+				  \hbox{\brac{\allowotherkeys}\f{]}}}\CR
+		     \xparen\ttbrac{{\environment} \param{var}}}
+
+A \term{defsetf lambda list} can contain the \term{lambda list keywords} shown
+in \thenextfigure.
+
+%I also added &environment, per discussion with Sandra and Quinquevirate.
+\showthree{Lambda List Keywords used by Defsetf Lambda Lists}{
+\keyref{allow-other-keys}&\keyref{key}&\keyref{rest}\cr
+\keyref{environment}&\keyref{optional}&\cr
+}
+
+A \term{defsetf lambda list} differs from an \term{ordinary lambda list} 
+only in that it does not permit the use of \keyref{aux}, 
+and that it permits use of \keyref{environment}, 
+     which introduces an \term{environment parameter}.
+
+\endsubSection%{Defsetf Lambda Lists}
+
+\beginsubSection{Deftype Lambda Lists}
+\DefineSection{DeftypeLambdaLists}
+
+A \newterm{deftype lambda list} is used by \macref{deftype}.
+
+A \term{deftype lambda list} has the same syntax as a \term{macro lambda list},
+and can therefore contain the \term{lambda list keywords} as a \term{macro lambda list}.
+
+\issue{DEFTYPE-DESTRUCTURING:YES}
+\issue{DEFTYPE-KEY:ALLOW}
+A \term{deftype lambda list} differs from a \term{macro lambda list} 
+only in that if no \param{init-form} is supplied for an \term{optional parameter}
+or \term{keyword parameter} in the \param{lambda-list}, the default \term{value} 
+for that \term{parameter} is the \term{symbol} \misc{*} (rather than \nil).
+\endissue{DEFTYPE-KEY:ALLOW}
+\endissue{DEFTYPE-DESTRUCTURING:YES}
+
+\endsubSection%{Deftype Lambda Lists}
+
+
+% This entire section is new.  Some info paraphrased from the
+% old dictionary entry for define-modify-macro.  --sjl 5 Mar 92
+\beginsubsection{Define-modify-macro Lambda Lists}
+\DefineSection{DefineModifyMacroLambdaLists}
+
+A \newterm{define-modify-macro lambda list} is used by 
+\macref{define-modify-macro}.
+
+A \term{define-modify-macro lambda list} can contain the 
+\term{lambda list keywords} shown in \thenextfigure.
+
+\showtwo{Lambda List Keywords used by Define-modify-macro Lambda Lists}{
+\keyref{optional}&\keyref{rest}\cr
+}
+
+\term{Define-modify-macro lambda lists} are similar to 
+\term{ordinary lambda lists}, but do not support keyword arguments.
+\macref{define-modify-macro} has no need match keyword arguments, and
+a \term{rest parameter} is sufficient.  \term{Aux variables} are also
+not supported, since \macref{define-modify-macro} has no body \term{forms}
+which could refer to such \term{bindings}.  \Seemac{define-modify-macro}.
+
+\endsubsection%{Define-modify-macro Lambda Lists}
+
+% This entire section is new, per Barrett #3 (first public review).
+\beginsubsection{Define-method-combination Arguments Lambda Lists}
+\DefineSection{DefMethCombArgsLambdaLists}
+
+A \newterm{define-method-combination arguments lambda list} is used by 
+the \kwd{arguments} option to \macref{define-method-combination}.
+
+A \term{define-method-combination arguments lambda list} can contain the 
+\term{lambda list keywords} shown in \thenextfigure.
+
+\showthree{Lambda List Keywords used by Define-method-combination arguments Lambda Lists}{
+\keyref{allow-other-keys}&\keyref{key}&\keyref{rest}\cr
+\keyref{aux}&\keyref{optional}&\keyref{whole}\cr
+}
+
+\term{Define-method-combination arguments lambda lists} are similar to 
+\term{ordinary lambda lists}, but also permit the use of \keyref{whole}.
+
+\endsubsection%{Define-Modify-Macro Arguments Lambda Lists}
+
+\beginsubsection{Syntactic Interaction of Documentation Strings and Declarations}
+\DefineSection{DocVsDecls}
+
+%% 8.1.0 8
+
+In a number of situations, a \term{documentation string} can appear amidst a
+series of \misc{declare} \term{expressions} prior to a series of \term{forms}.
+
+In that case, if a \term{string} $S$ appears where a \term{documentation string} is
+permissible and is not followed by 
+  either a \misc{declare} \term{expression} 
+      or a \term{form}
+then $S$ is taken to be a \term{form};
+otherwise, $S$ is taken as a \term{documentation string}.
+The consequences are unspecified if more than one such \term{documentation string} 
+is present.
+
+\endsubsection%{Syntactic Interaction of Documentation Strings and Declarations}

concept-change-class.tex

@@ -0,0 +1,109 @@
+% -*- Mode: TeX -*-
+              
+\Thefunction{change-class} can be used to change the \term{class} 
+of an \term{instance} from its current class, $C\sub {\hbox{{\prmseven from}}}$,
+to a different class, $C\sub {\hbox{{\prmseven to}}}$; it changes the
+structure of the \term{instance} to conform to the definition of the class
+$C\sub {\hbox{{\prmseven to}}}$.
+
+Note that changing the \term{class} of an \term{instance} may cause
+\term{slots} to be added or deleted.  Changing the \term{class} of an
+\term{instance} does not change its identity as defined by the
+\funref{eq} function.
+      
+When \funref{change-class} is invoked on an \term{instance}, a two-step
+updating process takes place.  The first step modifies the structure of
+the \term{instance} by adding new \term{local slots} and discarding 
+\term{local slots} that are not specified in the new version of the \term{instance}.
+The second step initializes the newly added \term{local slots} and performs 
+any other user-defined actions. These two steps are further described in the 
+two following sections.
+
+\beginsubsection{Modifying the Structure of the Instance}
+
+In order to make the \term{instance} conform to the class $C\sub
+{\hbox{{\prmseven to}}}$, \term{local slots} specified by the class $C\sub
+{\hbox{{\prmseven to}}}$ that are not specified by the class $C\sub
+{\hbox{{\prmseven from}}}$ are added, and \term{local slots} not specified by
+the class $C\sub {\hbox{{\prmseven to}}}$ that are specified by the
+class $C\sub {\hbox{{\prmseven from}}}$ are discarded.
+
+The values of \term{local slots} specified by both the class $C\sub
+{\hbox{{\prmseven to}}}$ and the class $C\sub {\hbox{{\prmseven
+from}}}$ are retained. If such a \term{local slot} was unbound, it remains
+unbound.
+
+The values of \term{slots} specified as shared in the class $C\sub
+{\hbox{{\prmseven from}}}$ and as local in the class $C\sub
+{\hbox{{\prmseven to}}}$ are retained.
+
+This first step of the update does not affect the values of any 
+\term{shared slots}.
+
+\endsubsection%{Modifying the Structure of the Instance}
+
+\beginsubsection{Initializing Newly Added Local Slots}
+\DefineSection{InitNewLocalSlots}
+
+The second step of the update initializes the newly added \term{slots} and
+performs any other user-defined actions.  This step is implemented by
+the generic function \funref{update-instance-for-different-class}.  The
+generic function \funref{update-instance-for-different-class} is invoked
+by \funref{change-class} after the first step of the update has been
+completed.
+
+\issue{CHANGE-CLASS-INITARGS:PERMIT}
+The generic function \funref{update-instance-for-different-class} is
+invoked on arguments computed by \funref{change-class}.
+The first argument passed is a copy of the \term{instance} being updated 
+and is an \term{instance} of the class $C\sub {\hbox{{\prmseven from}}}$; 
+this copy has \term{dynamic extent} within the generic function \funref{change-class}.  
+The second argument is the \term{instance} as updated so far by \funref{change-class}
+and is an \term{instance} of the class $C\sub {\hbox{{\prmseven to}}}$.
+The remaining arguments are an \term{initialization argument list}.
+
+% The generic function \funref{update-instance-for-different-class} also
+% takes any number of initialization arguments.  When it is called by
+% \funref{change-class}, no initialization arguments are provided.
+\endissue{CHANGE-CLASS-INITARGS:PERMIT}
+
+There is a system-supplied primary \term{method} for 
+\funref{update-instance-for-different-class} that has two parameter
+specializers, each of which is \theclass{standard-object}.  First
+this \term{method} checks the validity of initialization arguments and
+signals an error if an initialization argument is supplied that is not
+declared as valid.  (For more information, \seesection\DeclaringInitargValidity.)
+Then it calls the
+generic function \funref{shared-initialize} with the following arguments:
+the
+%Barmar suggested we insert the word "new" here.
+new
+\term{instance}, a list of \term{names} of the newly added 
+\term{slots}, and the
+initialization arguments it received.
+
+\endsubsection%{Initializing Newly added Local Slots}
+
+\beginsubsection{Customizing the Change of Class of an Instance}
+             
+\term{Methods} for \funref{update-instance-for-different-class} may be defined
+to specify actions to be taken when an \term{instance} is updated.  If only
+\term{after methods} for \funref{update-instance-for-different-class} are
+defined, they will be run after the system-supplied primary \term{method} for
+initialization and will not interfere with the default behavior of
+\funref{update-instance-for-different-class}.
+%% Removed per X3J13. -kmp 05-Oct-93
+% Because no initialization
+% arguments are passed to \funref{update-instance-for-different-class} when
+% it is called by \funref{change-class}, 
+% the \kwd{initform} forms for \term{slots}
+% that are filled by \term{before methods} for 
+% \funref{update-instance-for-different-class} will not be evaluated by
+% \funref{shared-initialize}.
+
+\term{Methods} 
+for \funref{shared-initialize} may be defined to customize \term{class}
+redefinition.  For more information, \seesection\SharedInitialize.
+  
+\endsubsection%{Customizing the Change of Class of an Instance}
+

concept-characters.tex

@@ -0,0 +1,580 @@
+% -*- Mode: TeX -*-
+
+\beginsubSection{Introduction to Characters}
+\DefineSection{IntroToChars}
+
+A \newterm{character} is an \term{object} that represents a unitary token 
+(\eg a letter, a special symbol, or a ``control character'')
+in an aggregate quantity of text
+(\eg a \term{string} or a text \term{stream}).
+
+\issue{CHARACTER-PROPOSAL:2-6-1}
+\clisp\ allows an implementation to provide support 
+for international language \term{characters} as well
+as \term{characters} used in specialized arenas (\eg mathematics).
+\endissue{CHARACTER-PROPOSAL:2-6-1}
+
+The following figures contain lists of \term{defined names} applicable to 
+\term{characters}.
+
+\Thenextfigure\ lists some \term{defined names} relating to 
+\term{character} \term{attributes} and \term{character} \term{predicates}.
+
+\displaythree{Character defined names -- 1}{
+alpha-char-p&char-not-equal&char>\cr
+alphanumericp&char-not-greaterp&char>=\cr
+both-case-p&char-not-lessp&digit-char-p\cr
+char-code-limit&char/=&graphic-char-p\cr
+char-equal&char<&lower-case-p\cr
+char-greaterp&char<=&standard-char-p\cr
+char-lessp&char=&upper-case-p\cr
+}
+                           
+\Thenextfigure\ lists some \term{character} construction and conversion \term{defined names}.
+
+\displaythree{Character defined names -- 2}{
+char-code&char-name&code-char\cr
+char-downcase&char-upcase&digit-char\cr
+char-int&character&name-char\cr
+}
+
+\endsubSection%{Introduction to Characters}
+
+\beginsubSection{Introduction to Scripts and Repertoires}
+
+\beginsubsubsection{Character Scripts}
+\DefineSection{CharScripts}
+
+A \term{script} is one of possibly several sets that form an \term{exhaustive partition}
+of the type \typeref{character}.
+
+The number of such sets and boundaries between them is \term{implementation-defined}.
+\clisp\ does not require these sets to be \term{types}, but an \term{implementation}
+is permitted to define such \term{types} as an extension.  Since no \term{character}
+from one \term{script} can ever be a member of another \term{script}, it is generally
+more useful to speak about \term{character} \term{repertoires}.
+
+\issue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+% For some examples of \term{repertoires}, see the coded character standards
+% ISO 8859/1, ISO 8859/2, and ISO 6937/2.
+% Note, however, that although
+Although
+the term ``\term{script}'' is chosen for 
+%naming
+definitional 
+compatibility with ISO terminology, no \term{conforming implementation} 
+is required to use any particular \term{scripts} standardized by ISO
+or by any other standards organization.
+\endissue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+
+\issue{CHARACTER-PROPOSAL:2-4-1}
+Whether and how the \term{script} or \term{scripts} used by any given
+\term{implementation} are named is \term{implementation-dependent}.
+\endissue{CHARACTER-PROPOSAL:2-4-1}
+
+\endsubsubsection%{Character Scripts}
+
+\beginsubsubsection{Character Repertoires}
+\DefineSection{CharRepertoires}
+
+\issue{CHARACTER-PROPOSAL:2-4-3}
+A \newterm{repertoire} is a \term{type specifier} for a \subtypeof{character}.
+\endissue{CHARACTER-PROPOSAL:2-4-3}
+This term is generally used when describing a collection of \term{characters}
+independent of their coding.
+\term{Characters} in \term{repertoires} are only identified
+    by name,
+    by \term{glyph}, or
+    by character description.
+
+A \term{repertoire} can contain \term{characters} from several
+\term{scripts}, and a \term{character} can appear in more than
+one \term{repertoire}.
+
+\issue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+For some examples of \term{repertoires}, see the coded character standards
+ISO 8859/1, ISO 8859/2, and ISO 6937/2.
+Note, however, that although
+%Although
+the term ``\term{repertoire}'' is chosen for 
+%naming
+definitional 
+compatibility with ISO terminology, no \term{conforming implementation} 
+is required to use \term{repertoires} standardized by ISO or any other 
+standards organization.
+\endissue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+
+\endsubsubsection%{Character Repertoires}
+
+\endsubSection%{Introduction to Repertoires and Scripts}
+
+\beginsubSection{Character Attributes}
+\DefineSection{CharacterAttributes}
+
+%% 13.1.0 1
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\term{Characters} have only one \term{standardized} \term{attribute}:
+a \term{code}.  A \term{character}'s \term{code} is a non-negative \term{integer}.
+This \term{code} is composed from a character \term{script} and a character label
+in an \term{implementation-dependent} way.  \Seefuns{char-code} and \funref{code-char}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+% %% 13.5.0 1
+% Remarks about the bits and font \term{attributes} removed. -kmp
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+Additional, \term{implementation-defined} \term{attributes} of \term{characters}
+are also permitted
+so that, for example, 
+two \term{characters} with the same \term{code} may differ 
+in some other, \term{implementation-defined} way.
+
+For any \term{implementation-defined} \term{attribute}
+there is a distinguished value
+called the \newterm{null} value for that \term{attribute}. 
+A \term{character} for which each \term{implementation-defined} \term{attribute}
+has the null value for that \term{attribute} is called a \term{simple} \term{character}.
+If the \term{implementation} has no \term{implementation-defined} \term{attributes},
+then all \term{characters} are \term{simple} \term{characters}.
+
+\endSubsection%{Character Attributes}
+
+\beginSubsection{Character Categories}
+
+There are several (overlapping) categories of \term{characters} that have no formally
+associated \term{type} but that are nevertheless useful to name. 
+They include
+     \term{graphic} \term{characters}, 
+     \term{alphabetic}\meaning{1} \term{characters},
+     \term{characters} with \term{case} 
+       (\term{uppercase} and \term{lowercase} \term{characters}),
+     \term{numeric} \term{characters},
+     \term{alphanumeric} \term{characters},
+ and \term{digits} (in a given \term{radix}).
+
+For each \term{implementation-defined} \term{attribute} of a \term{character},
+the documentation for that \term{implementation} must specify whether 
+\term{characters} that differ only in that \term{attribute} are permitted to differ
+in whether are not they are members of one of the aforementioned categories.
+
+Note that these terms are defined independently of any special syntax 
+which might have been enabled in the \term{current readtable}.
+
+\beginsubsubsection{Graphic Characters}
+\DefineSection{GraphicChars}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\term{Characters} that are classified as \newterm{graphic}, or displayable, are each
+associated with a glyph, a visual representation of the \term{character}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+%% 13.2.0 7
+
+A \term{graphic} \term{character} is one that has a standard textual 
+representation as a single \term{glyph}, such as \f{A} or \f{*} or \f{=}.
+\term{Space}, which effectively has a blank \term{glyph}, is defined
+to be a \term{graphic}.
+
+Of the \term{standard characters},
+     \term{newline} is \term{non-graphic} 
+ and all others are \term{graphic}; \seesection\StandardChars.
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\term{Characters} that are not \term{graphic} are called \newterm{non-graphic}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+\term{Non-graphic} \term{characters} are sometimes informally called
+    ``formatting characters'' 
+ or ``control characters.''
+
+\f{\#\\Backspace},
+\f{\#\\Tab},
+\f{\#\\Rubout},
+\f{\#\\Linefeed}, 
+\f{\#\\Return}, and
+\f{\#\\Page},
+if they are supported by the \term{implementation},
+are \term{non-graphic}.
+
+%!!! I'm not completely sure it was proper for whoever removed this to have done so.
+%     -kmp 16-Oct-91
+%% 13.2.0 6
+%\term{Graphic characters} of font 0 are all of the same width when printed.
+%Every implementation of \clisp\ must provide some mode of operation
+%in which font 0 is a fixed-pitch font.
+
+%% 13.2.0 7
+%Any character with a non-zero bits \term{attribute} is \term{non-graphic}.
+
+\endsubsubsection%{Graphic Characters}
+
+\beginsubsubsection{Alphabetic Characters}
+
+%% 13.2.0 10
+The \term{alphabetic}\meaning{1} \term{characters} are
+a subset of the \term{graphic} \term{characters}.
+Of the \term{standard characters}, only these are the \term{alphabetic}\meaning{1} \term{characters}:
+
+\f{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}
+
+\f{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}
+
+%% 13.2.0 16
+Any \term{implementation-defined} \term{character} that has \term{case} 
+must be \term{alphabetic}\meaning{1}.
+For each \term{implementation-defined} \term{graphic} \term{character} 
+that has no \term{case},
+it is \term{implementation-defined} whether 
+that \term{character} is \term{alphabetic}\meaning{1}.
+
+\endsubsubsection%{Alphabetic Characters}
+
+\beginsubsubsection{Characters With Case}
+\DefineSection{CharactersWithCase}
+
+The \term{characters} with \term{case} are 
+a subset of the \term{alphabetic}\meaning{1} \term{characters}.
+A \term{character} with \term{case} has the property of being either
+\term{uppercase} or \term{lowercase}.
+Every \term{character} with \term{case} is in one-to-one correspondence
+with some other \term{character} with the opposite \term{case}.
+
+%% 13.2.0 17
+
+\beginsubsubsubsection{Uppercase Characters}
+
+An uppercase \term{character} is one that has a corresponding
+\term{lowercase} \term{character} that is \term{different} 
+(and can be obtained using \funref{char-downcase}).
+
+Of the \term{standard characters}, only these are \term{uppercase} \term{characters}:
+
+\f{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}
+
+\endsubsubsubsection%{Uppercase Characters}
+
+\beginsubsubsubsection{Lowercase Characters}
+
+A lowercase \term{character} is one that has a corresponding 
+\term{uppercase} \term{character} that is \term{different} 
+(and can be obtained using \funref{char-upcase}).
+
+Of the \term{standard characters}, only these are \term{lowercase} \term{characters}:
+
+\f{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}
+
+\endsubsubsubsection%{Lowercase Characters}
+
+\beginsubsubsubsection{Corresponding Characters in the Other Case}
+
+The \term{uppercase} \term{standard characters} \f{A} through \f{Z} mentioned above
+respectively correspond to
+the \term{lowercase} \term{standard characters} \f{a} through \f{z} mentioned above.
+For example, the \term{uppercase} \term{character} \f{E} 
+corresponds to the \term{lowercase} \term{character} \f{e}, and vice versa.
+
+\endsubsubsubsection%{Corresponding Characters in the Other Case}
+
+\beginsubsubsubsection{Case of Implementation-Defined Characters}
+
+An \term{implementation} may define that other \term{implementation-defined}
+\term{graphic} \term{characters} have \term{case}.  Such definitions must always
+be done in pairs---one \term{uppercase} \term{character} in one-to-one 
+\term{correspondence} with one \term{lowercase} \term{character}.
+
+\endsubsubsubsection%{Case of Implementation-Defined Characters}
+
+\endsubsubsection%{Characters With Case}
+
+\beginsubsubsection{Numeric Characters}
+
+The \term{numeric} \term{characters} are
+a subset of the \term{graphic} \term{characters}.
+Of the \term{standard characters}, only these are \term{numeric} \term{characters}:
+
+\f{0 1 2 3 4 5 6 7 8 9}
+
+For each \term{implementation-defined} \term{graphic} \term{character} 
+that has no \term{case}, the \term{implementation} must define whether
+or not it is a \term{numeric} \term{character}.
+
+\endsubsubsection%{Numeric Characters}
+
+\beginsubsubsection{Alphanumeric Characters}
+
+The set of \term{alphanumeric} \term{characters} is the union of 
+    the set of \term{alphabetic}\meaning{1} \term{characters} 
+and the set of \term{numeric} \term{characters}.
+
+\endsubsubsection%{Alphanumeric Characters}
+
+\beginsubsubsection{Digits in a Radix}
+\DefineSection{Digits}
+
+What qualifies as a \term{digit} depends on the \term{radix} 
+(an \term{integer} between \f{2} and \f{36}, inclusive).
+The potential \term{digits} are:
+
+\f{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}
+
+Their respective weights are \f{0}, \f{1}, \f{2}, $\ldots$ \f{35}.
+In any given radix $n$, only the first $n$ potential \term{digits} 
+are considered to be \term{digits}.
+For example,
+the digits in radix \f{2}  are \f{0} and \f{1}, 
+the digits in radix \f{10} are \f{0} through \f{9}, and
+the digits in radix \f{16} are \f{0} through \f{F}.
+
+\term{Case} is not significant in \term{digits}; 
+for example, in radix \f{16}, both \f{F} and \f{f} 
+are \term{digits} with weight \f{15}.
+
+%!!! KMP: I couldn't figure out whether there can be 
+%         implementation-defined digits.  
+%         It doesn't seem like a good idea because the obvious choices
+%         are things like ``\~n'' which comes in the middle of the Spanish
+%         alphabet, not at the end, and hence might confuse people about
+%         the weight of ``o''.  The answer to this has impact on
+%         \funref{digit-char-p} and \funref{digit-weight}.}
+
+\endsubsubsection%{Digits in a Radix}
+
+\endsubSection%{Character Categories}
+
+\beginsubSection{Identity of Characters}
+
+%% 13.0.0 3
+%% 13.0.0 4
+Two \term{characters} that are \funref{eql}, \funref{char=}, or \funref{char-equal} 
+are not necessarily \funref{eq}.
+
+\endsubSection%{Identity of Characters}
+
+\beginsubSection{Ordering of Characters}
+
+The total ordering on \term{characters} is guaranteed to have 
+the following properties: 
+
+\beginlist
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+
+%% 13.2.0 27
+\itemitem{\bull} 
+If two \term{characters} have the same \term{implementation-defined} \term{attributes},
+then their ordering by \funref{char<} is consistent with the numerical
+ordering by the predicate \funref{<} on their code \term{attributes}.
+
+%% 13.2.0 28
+\itemitem{\bull} If two \term{characters} differ in any \term{attribute}, then they
+%are different.
+are not \funref{char=}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\reviewer{Barmar: I wonder if we should say that the ordering may be dependent on the
+	          \term{implementation-defined} \term{attributes}.}
+
+%% 13.2.0 29
+\itemitem{\bull}
+  The total ordering is not necessarily the same as the total ordering
+  on the \term{integers} produced by applying \funref{char-int} to the
+  \term{characters}.
+
+%% 13.2.0 30
+\issue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+\itemitem{\bull} 
+  While \term{alphabetic}\meaning{1} \term{standard characters} of a given \term{case}
+  must    
+% be properly ordered, 
+  obey a partial ordering,
+  they need not be contiguous; it is permissible for 
+  \term{uppercase} and \term{lowercase} \term{characters} to be interleaved. 
+  Thus \f{(char<= \#\\a x \#\\z)} 
+  is not a valid way of determining whether or not \f{x} is a
+  \term{lowercase} \term{character}.  
+\endissue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+% Discussion omitted about how the ordering might depend on font information.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\endlist
+
+\issue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+%% 13.2.0 25
+%% 13.2.0 26
+%The standard \term{alphanumeric} \term{characters} obey the following partial ordering:
+Of the \term{standard characters}, 
+those which are \term{alphanumeric} obey the following partial ordering:
+\endissue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+
+\code
+ 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
+ 0<1<2<3<4<5<6<7<8<9
+ either 9<A or Z<0
+ either 9<a or z<0                                                      
+\endcode
+\issue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+This implies that, for \term{standard characters}, \term{alphabetic}\meaning{1} 
+ordering holds within each \term{case} (\term{uppercase} and \term{lowercase}), 
+and that the \term{numeric} \term{characters} as a group are not interleaved
+with \term{alphabetic} \term{characters}.
+However, the ordering or possible interleaving of \term{uppercase} \term{characters}
+and \term{lowercase} \term{characters} is \term{implementation-defined}.
+\endissue{LINDEN-COMMENTS-ON-CHARACTERS:X3J13-APR-92}
+
+\endsubSection%{Ordering of Characters}
+
+\beginsubsection{Character Names}
+\DefineSection{CharacterNames}
+
+The following \term{character} \term{names} must be present in all 
+\term{conforming implementations}:
+
+%% 22.1.4 9
+\beginlist
+\itemitem{\f{Newline}}
+
+%% 2.2.2 3
+The character that represents the division between lines.
+An implementation must translate between \f{\#\\Newline}, 
+a single-character representation, and whatever external representation(s)
+may be used.
+
+%% 22.1.4 10
+\itemitem{\f{Space}}
+
+The space or blank character.
+\endlist
+
+The following names are \term{semi-standard}; 
+if an \term{implementation} supports them,
+they should be used for the described \term{characters} and no others.
+
+\beginlist         
+\itemitem{\f{Rubout}}
+
+The rubout or delete character.
+
+%% 22.1.4 11
+\itemitem{\f{Page}}
+
+The form-feed or page-separator character.
+
+%% 22.1.4 12
+\itemitem{\f{Tab}}
+
+The tabulate character.
+
+%% 22.1.4 13
+\itemitem{\f{Backspace}}
+
+The backspace character.
+
+%% 22.1.4 14
+\itemitem{\f{Return}}
+
+The carriage return character.
+
+%% 22.1.4 15
+\itemitem{\f{Linefeed}}
+
+The line-feed character.
+\endlist
+
+In some \term{implementations},
+one or more of these \term{character} \term{names} 
+might denote a \term{standard character}; 
+for example,
+\f{\#\\Linefeed} and \f{\#\\Newline} might be the \term{same} \term{character}
+in some \term{implementations}.
+
+
+\endsubsection%{Character Names}
+
+\beginsubSection{Treatment of Newline during Input and Output}
+\DefineSection{TreatmentOfNewline}
+
+%% 2.2.2 6
+When the character \f{\#\\Newline} is written to an output file,
+the implementation must take the appropriate action
+to produce a line division.  This might involve writing out a
+record or translating \f{\#\\Newline} to a CR/LF sequence.
+When reading, a corresponding reverse transformation must take place.
+
+\endsubSection%{Treatment of Newline during Input and Output}
+
+\beginsubSection{Character Encodings}
+\DefineSection{CharEncodings}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+% \editornote{KMP: This next paragraph is somewhat tentative.
+%  Maybe a glossary term for this would be good if I decide it should stay.
+%  Do reviewers think this concept is worth naming, and is ``encoding'' ok as a name?}%!!!
+A \term{character} is sometimes represented merely by its \term{code}, and sometimes
+by another \term{integer} value which is composed from the \term{code} and all 
+\term{implementation-defined} \term{attributes}
+(in an \term{implementation-defined} way
+that might vary between \term{Lisp images} even in the same \term{implementation}).
+This \term{integer}, returned by the function \funref{char-int}, is called the
+character's ``encoding.''
+There is no corresponding function
+from a character's encoding back to the \term{character}, 
+since its primary intended uses include things like hashing where an inverse operation
+is not really called for.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\endsubSection%{Character Encodings}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+%% 2.2.5 1
+%Discussion of STRING-CHAR deleted.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\beginsubsection{Documentation of Implementation-Defined Scripts}
+\DefineSection{ImplementationDefinedScripts}
+
+\issue{CHARACTER-PROPOSAL:2-4-2} 
+   An \term{implementation} must document the \term{character} \term{scripts} 
+   it supports. For each \term{character} \term{script} supported,
+   the documentation must describe at least the following:
+\beginlist
+\itemitem{\bull}
+   Character labels, glyphs, and descriptions.
+   Character labels must be uniquely named using only Latin capital letters A--Z,
+   hyphen (-), and digits 0--9.
+\itemitem{\bull}
+   Reader canonicalization.
+   Any mechanisms by which \funref{read} treats
+   \term{different} characters as equivalent must be documented.
+\itemitem{\bull}
+   The impact on \funref{char-upcase},
+		 \funref{char-downcase},
+	     and the case-sensitive \term{format directives}.
+   In particular, for each \term{character} with \term{case},
+   whether it is \term{uppercase} or \term{lowercase},
+   and which \term{character} is its equivalent in the opposite case.
+\itemitem{\bull}
+   The behavior of the case-insensitive \term{functions}
+     \funref{char-equal}, \funref{char-not-equal},
+     \funref{char-lessp}, \funref{char-greaterp}, 
+     \funref{char-not-greaterp}, and \funref{char-not-lessp}.
+\itemitem{\bull}
+   The behavior of any \term{character} \term{predicates};
+   in particular, the effects of
+   \funref{alpha-char-p},
+   \funref{lower-case-p},
+   \funref{upper-case-p},
+   \funref{both-case-p},
+   \funref{graphic-char-p}, 
+   and
+   \funref{alphanumericp}.
+\itemitem{\bull}
+   The interaction with file I/O, in particular,
+   the supported coded character sets (for example, ISO8859/1-1987)
+   and external encoding schemes supported are documented.
+\endlist
+\endissue{CHARACTER-PROPOSAL:2-4-2} 
+
+\endsubsection%{Documentation of Implementation-Defined Scripts}

concept-cl-symbols.tex

@@ -0,0 +1,535 @@
+% -*- Mode: TeX -*-  
+% 978 symbols in ANSI package COMMON-LISP,
+% generated by kmp@SONATA.Harlequin.COM on machine BALBOA
+% running Genera 8.3, System 446.21 on 8/29/93 21:30:44,
+% including these symbols added manually:
+%  (BOOLEAN ENSURE-DIRECTORIES-EXIST READ-SEQUENCE WRITE-SEQUENCE DEFINE-SYMBOL-MACRO).
+%
+% *** THIS FILE IS AUTOMATICALLY GENERATED.
+% *** DO NOT MANUALLY EDIT, OR YOUR CHANGES MAY BE LOST!
+% *** SEE "B:>ansi-cl>spec>tools>show-cl-symbols" FOR MORE INFO.
+% ***   --kmp
+
+The figures on the next twelve pages contain a complete enumeration
+of the 978 \term{external} \term{symbols} in \thepackage{common-lisp}.\idxpackref{common-lisp}
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part one of twelve).}{
+\&allow-other-keys&*print-miser-width*\cr
+\&aux&*print-pprint-dispatch*\cr
+\&body&*print-pretty*\cr
+\&environment&*print-radix*\cr
+\&key&*print-readably*\cr
+\&optional&*print-right-margin*\cr
+\&rest&*query-io*\cr
+\&whole&*random-state*\cr
+*&*read-base*\cr
+**&*read-default-float-format*\cr
+***&*read-eval*\cr
+*break-on-signals*&*read-suppress*\cr
+*compile-file-pathname*&*readtable*\cr
+*compile-file-truename*&*standard-input*\cr
+*compile-print*&*standard-output*\cr
+*compile-verbose*&*terminal-io*\cr
+*debug-io*&*trace-output*\cr
+*debugger-hook*&+\cr
+*default-pathname-defaults*&++\cr
+*error-output*&+++\cr
+*features*&-\cr
+*gensym-counter*&/\cr
+*load-pathname*&//\cr
+*load-print*&///\cr
+*load-truename*&/=\cr
+*load-verbose*&1+\cr
+*macroexpand-hook*&1-\cr
+*modules*&<\cr
+*package*&<=\cr
+*print-array*&=\cr
+*print-base*&>\cr
+*print-case*&>=\cr
+*print-circle*&abort\cr
+*print-escape*&abs\cr
+*print-gensym*&acons\cr
+*print-length*&acos\cr
+*print-level*&acosh\cr
+*print-lines*&add-method\cr
+}
+
+\vfill\eject
+
+
+\displaythree{Symbols in the COMMON-LISP package (part two of twelve).}{
+adjoin&atom&boundp\cr
+adjust-array&base-char&break\cr
+adjustable-array-p&base-string&broadcast-stream\cr
+allocate-instance&bignum&broadcast-stream-streams\cr
+alpha-char-p&bit&built-in-class\cr
+alphanumericp&bit-and&butlast\cr
+and&bit-andc1&byte\cr
+append&bit-andc2&byte-position\cr
+apply&bit-eqv&byte-size\cr
+apropos&bit-ior&caaaar\cr
+apropos-list&bit-nand&caaadr\cr
+aref&bit-nor&caaar\cr
+arithmetic-error&bit-not&caadar\cr
+arithmetic-error-operands&bit-orc1&caaddr\cr
+arithmetic-error-operation&bit-orc2&caadr\cr
+array&bit-vector&caar\cr
+array-dimension&bit-vector-p&cadaar\cr
+array-dimension-limit&bit-xor&cadadr\cr
+array-dimensions&block&cadar\cr
+array-displacement&boole&caddar\cr
+array-element-type&boole-1&cadddr\cr
+array-has-fill-pointer-p&boole-2&caddr\cr
+array-in-bounds-p&boole-and&cadr\cr
+array-rank&boole-andc1&call-arguments-limit\cr
+array-rank-limit&boole-andc2&call-method\cr
+array-row-major-index&boole-c1&call-next-method\cr
+array-total-size&boole-c2&car\cr
+array-total-size-limit&boole-clr&case\cr
+arrayp&boole-eqv&catch\cr
+ash&boole-ior&ccase\cr
+asin&boole-nand&cdaaar\cr
+asinh&boole-nor&cdaadr\cr
+assert&boole-orc1&cdaar\cr
+assoc&boole-orc2&cdadar\cr
+assoc-if&boole-set&cdaddr\cr
+assoc-if-not&boole-xor&cdadr\cr
+atan&boolean&cdar\cr
+atanh&both-case-p&cddaar\cr
+}
+
+\vfill\eject
+
+
+\displaythree{Symbols in the COMMON-LISP package (part three of twelve).}{
+cddadr&clear-input&copy-tree\cr
+cddar&clear-output&cos\cr
+cdddar&close&cosh\cr
+cddddr&clrhash&count\cr
+cdddr&code-char&count-if\cr
+cddr&coerce&count-if-not\cr
+cdr&compilation-speed&ctypecase\cr
+ceiling&compile&debug\cr
+cell-error&compile-file&decf\cr
+cell-error-name&compile-file-pathname&declaim\cr
+cerror&compiled-function&declaration\cr
+change-class&compiled-function-p&declare\cr
+char&compiler-macro&decode-float\cr
+char-code&compiler-macro-function&decode-universal-time\cr
+char-code-limit&complement&defclass\cr
+char-downcase&complex&defconstant\cr
+char-equal&complexp&defgeneric\cr
+char-greaterp&compute-applicable-methods&define-compiler-macro\cr
+char-int&compute-restarts&define-condition\cr
+char-lessp&concatenate&define-method-combination\cr
+char-name&concatenated-stream&define-modify-macro\cr
+char-not-equal&concatenated-stream-streams&define-setf-expander\cr
+char-not-greaterp&cond&define-symbol-macro\cr
+char-not-lessp&condition&defmacro\cr
+char-upcase&conjugate&defmethod\cr
+char/=&cons&defpackage\cr
+char<&consp&defparameter\cr
+char<=&constantly&defsetf\cr
+char=&constantp&defstruct\cr
+char>&continue&deftype\cr
+char>=&control-error&defun\cr
+character&copy-alist&defvar\cr
+characterp&copy-list&delete\cr
+check-type&copy-pprint-dispatch&delete-duplicates\cr
+cis&copy-readtable&delete-file\cr
+class&copy-seq&delete-if\cr
+class-name&copy-structure&delete-if-not\cr
+class-of&copy-symbol&delete-package\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part four of twelve).}{
+denominator&eq\cr
+deposit-field&eql\cr
+describe&equal\cr
+describe-object&equalp\cr
+destructuring-bind&error\cr
+digit-char&etypecase\cr
+digit-char-p&eval\cr
+directory&eval-when\cr
+directory-namestring&evenp\cr
+disassemble&every\cr
+division-by-zero&exp\cr
+do&export\cr
+do*&expt\cr
+do-all-symbols&extended-char\cr
+do-external-symbols&fboundp\cr
+do-symbols&fceiling\cr
+documentation&fdefinition\cr
+dolist&ffloor\cr
+dotimes&fifth\cr
+double-float&file-author\cr
+double-float-epsilon&file-error\cr
+double-float-negative-epsilon&file-error-pathname\cr
+dpb&file-length\cr
+dribble&file-namestring\cr
+dynamic-extent&file-position\cr
+ecase&file-stream\cr
+echo-stream&file-string-length\cr
+echo-stream-input-stream&file-write-date\cr
+echo-stream-output-stream&fill\cr
+ed&fill-pointer\cr
+eighth&find\cr
+elt&find-all-symbols\cr
+encode-universal-time&find-class\cr
+end-of-file&find-if\cr
+endp&find-if-not\cr
+enough-namestring&find-method\cr
+ensure-directories-exist&find-package\cr
+ensure-generic-function&find-restart\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part five of twelve).}{
+find-symbol&get-internal-run-time\cr
+finish-output&get-macro-character\cr
+first&get-output-stream-string\cr
+fixnum&get-properties\cr
+flet&get-setf-expansion\cr
+float&get-universal-time\cr
+float-digits&getf\cr
+float-precision&gethash\cr
+float-radix&go\cr
+float-sign&graphic-char-p\cr
+floating-point-inexact&handler-bind\cr
+floating-point-invalid-operation&handler-case\cr
+floating-point-overflow&hash-table\cr
+floating-point-underflow&hash-table-count\cr
+floatp&hash-table-p\cr
+floor&hash-table-rehash-size\cr
+fmakunbound&hash-table-rehash-threshold\cr
+force-output&hash-table-size\cr
+format&hash-table-test\cr
+formatter&host-namestring\cr
+fourth&identity\cr
+fresh-line&if\cr
+fround&ignorable\cr
+ftruncate&ignore\cr
+ftype&ignore-errors\cr
+funcall&imagpart\cr
+function&import\cr
+function-keywords&in-package\cr
+function-lambda-expression&incf\cr
+functionp&initialize-instance\cr
+gcd&inline\cr
+generic-function&input-stream-p\cr
+gensym&inspect\cr
+gentemp&integer\cr
+get&integer-decode-float\cr
+get-decoded-time&integer-length\cr
+get-dispatch-macro-character&integerp\cr
+get-internal-real-time&interactive-stream-p\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part six of twelve).}{
+intern&lisp-implementation-type\cr
+internal-time-units-per-second&lisp-implementation-version\cr
+intersection&list\cr
+invalid-method-error&list*\cr
+invoke-debugger&list-all-packages\cr
+invoke-restart&list-length\cr
+invoke-restart-interactively&listen\cr
+isqrt&listp\cr
+keyword&load\cr
+keywordp&load-logical-pathname-translations\cr
+labels&load-time-value\cr
+lambda&locally\cr
+lambda-list-keywords&log\cr
+lambda-parameters-limit&logand\cr
+last&logandc1\cr
+lcm&logandc2\cr
+ldb&logbitp\cr
+ldb-test&logcount\cr
+ldiff&logeqv\cr
+least-negative-double-float&logical-pathname\cr
+least-negative-long-float&logical-pathname-translations\cr
+least-negative-normalized-double-float&logior\cr
+least-negative-normalized-long-float&lognand\cr
+least-negative-normalized-short-float&lognor\cr
+least-negative-normalized-single-float&lognot\cr
+least-negative-short-float&logorc1\cr
+least-negative-single-float&logorc2\cr
+least-positive-double-float&logtest\cr
+least-positive-long-float&logxor\cr
+least-positive-normalized-double-float&long-float\cr
+least-positive-normalized-long-float&long-float-epsilon\cr
+least-positive-normalized-short-float&long-float-negative-epsilon\cr
+least-positive-normalized-single-float&long-site-name\cr
+least-positive-short-float&loop\cr
+least-positive-single-float&loop-finish\cr
+length&lower-case-p\cr
+let&machine-instance\cr
+let*&machine-type\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part seven of twelve).}{
+machine-version&mask-field\cr
+macro-function&max\cr
+macroexpand&member\cr
+macroexpand-1&member-if\cr
+macrolet&member-if-not\cr
+make-array&merge\cr
+make-broadcast-stream&merge-pathnames\cr
+make-concatenated-stream&method\cr
+make-condition&method-combination\cr
+make-dispatch-macro-character&method-combination-error\cr
+make-echo-stream&method-qualifiers\cr
+make-hash-table&min\cr
+make-instance&minusp\cr
+make-instances-obsolete&mismatch\cr
+make-list&mod\cr
+make-load-form&most-negative-double-float\cr
+make-load-form-saving-slots&most-negative-fixnum\cr
+make-method&most-negative-long-float\cr
+make-package&most-negative-short-float\cr
+make-pathname&most-negative-single-float\cr
+make-random-state&most-positive-double-float\cr
+make-sequence&most-positive-fixnum\cr
+make-string&most-positive-long-float\cr
+make-string-input-stream&most-positive-short-float\cr
+make-string-output-stream&most-positive-single-float\cr
+make-symbol&muffle-warning\cr
+make-synonym-stream&multiple-value-bind\cr
+make-two-way-stream&multiple-value-call\cr
+makunbound&multiple-value-list\cr
+map&multiple-value-prog1\cr
+map-into&multiple-value-setq\cr
+mapc&multiple-values-limit\cr
+mapcan&name-char\cr
+mapcar&namestring\cr
+mapcon&nbutlast\cr
+maphash&nconc\cr
+mapl&next-method-p\cr
+maplist&nil\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part eight of twelve).}{
+nintersection&package-error\cr
+ninth&package-error-package\cr
+no-applicable-method&package-name\cr
+no-next-method&package-nicknames\cr
+not&package-shadowing-symbols\cr
+notany&package-use-list\cr
+notevery&package-used-by-list\cr
+notinline&packagep\cr
+nreconc&pairlis\cr
+nreverse&parse-error\cr
+nset-difference&parse-integer\cr
+nset-exclusive-or&parse-namestring\cr
+nstring-capitalize&pathname\cr
+nstring-downcase&pathname-device\cr
+nstring-upcase&pathname-directory\cr
+nsublis&pathname-host\cr
+nsubst&pathname-match-p\cr
+nsubst-if&pathname-name\cr
+nsubst-if-not&pathname-type\cr
+nsubstitute&pathname-version\cr
+nsubstitute-if&pathnamep\cr
+nsubstitute-if-not&peek-char\cr
+nth&phase\cr
+nth-value&pi\cr
+nthcdr&plusp\cr
+null&pop\cr
+number&position\cr
+numberp&position-if\cr
+numerator&position-if-not\cr
+nunion&pprint\cr
+oddp&pprint-dispatch\cr
+open&pprint-exit-if-list-exhausted\cr
+open-stream-p&pprint-fill\cr
+optimize&pprint-indent\cr
+or&pprint-linear\cr
+otherwise&pprint-logical-block\cr
+output-stream-p&pprint-newline\cr
+package&pprint-pop\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part nine of twelve).}{
+pprint-tab&read-char\cr
+pprint-tabular&read-char-no-hang\cr
+prin1&read-delimited-list\cr
+prin1-to-string&read-from-string\cr
+princ&read-line\cr
+princ-to-string&read-preserving-whitespace\cr
+print&read-sequence\cr
+print-not-readable&reader-error\cr
+print-not-readable-object&readtable\cr
+print-object&readtable-case\cr
+print-unreadable-object&readtablep\cr
+probe-file&real\cr
+proclaim&realp\cr
+prog&realpart\cr
+prog*&reduce\cr
+prog1&reinitialize-instance\cr
+prog2&rem\cr
+progn&remf\cr
+program-error&remhash\cr
+progv&remove\cr
+provide&remove-duplicates\cr
+psetf&remove-if\cr
+psetq&remove-if-not\cr
+push&remove-method\cr
+pushnew&remprop\cr
+quote&rename-file\cr
+random&rename-package\cr
+random-state&replace\cr
+random-state-p&require\cr
+rassoc&rest\cr
+rassoc-if&restart\cr
+rassoc-if-not&restart-bind\cr
+ratio&restart-case\cr
+rational&restart-name\cr
+rationalize&return\cr
+rationalp&return-from\cr
+read&revappend\cr
+read-byte&reverse\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part ten of twelve).}{
+room&simple-bit-vector\cr
+rotatef&simple-bit-vector-p\cr
+round&simple-condition\cr
+row-major-aref&simple-condition-format-arguments\cr
+rplaca&simple-condition-format-control\cr
+rplacd&simple-error\cr
+safety&simple-string\cr
+satisfies&simple-string-p\cr
+sbit&simple-type-error\cr
+scale-float&simple-vector\cr
+schar&simple-vector-p\cr
+search&simple-warning\cr
+second&sin\cr
+sequence&single-float\cr
+serious-condition&single-float-epsilon\cr
+set&single-float-negative-epsilon\cr
+set-difference&sinh\cr
+set-dispatch-macro-character&sixth\cr
+set-exclusive-or&sleep\cr
+set-macro-character&slot-boundp\cr
+set-pprint-dispatch&slot-exists-p\cr
+set-syntax-from-char&slot-makunbound\cr
+setf&slot-missing\cr
+setq&slot-unbound\cr
+seventh&slot-value\cr
+shadow&software-type\cr
+shadowing-import&software-version\cr
+shared-initialize&some\cr
+shiftf&sort\cr
+short-float&space\cr
+short-float-epsilon&special\cr
+short-float-negative-epsilon&special-operator-p\cr
+short-site-name&speed\cr
+signal&sqrt\cr
+signed-byte&stable-sort\cr
+signum&standard\cr
+simple-array&standard-char\cr
+simple-base-string&standard-char-p\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part eleven of twelve).}{
+standard-class&sublis\cr
+standard-generic-function&subseq\cr
+standard-method&subsetp\cr
+standard-object&subst\cr
+step&subst-if\cr
+storage-condition&subst-if-not\cr
+store-value&substitute\cr
+stream&substitute-if\cr
+stream-element-type&substitute-if-not\cr
+stream-error&subtypep\cr
+stream-error-stream&svref\cr
+stream-external-format&sxhash\cr
+streamp&symbol\cr
+string&symbol-function\cr
+string-capitalize&symbol-macrolet\cr
+string-downcase&symbol-name\cr
+string-equal&symbol-package\cr
+string-greaterp&symbol-plist\cr
+string-left-trim&symbol-value\cr
+string-lessp&symbolp\cr
+string-not-equal&synonym-stream\cr
+string-not-greaterp&synonym-stream-symbol\cr
+string-not-lessp&t\cr
+string-right-trim&tagbody\cr
+string-stream&tailp\cr
+string-trim&tan\cr
+string-upcase&tanh\cr
+string/=&tenth\cr
+string<&terpri\cr
+string<=&the\cr
+string=&third\cr
+string>&throw\cr
+string>=&time\cr
+stringp&trace\cr
+structure&translate-logical-pathname\cr
+structure-class&translate-pathname\cr
+structure-object&tree-equal\cr
+style-warning&truename\cr
+}
+
+\vfill\eject
+
+
+\displaytwo{Symbols in the COMMON-LISP package (part twelve of twelve).}{
+truncate&values-list\cr
+two-way-stream&variable\cr
+two-way-stream-input-stream&vector\cr
+two-way-stream-output-stream&vector-pop\cr
+type&vector-push\cr
+type-error&vector-push-extend\cr
+type-error-datum&vectorp\cr
+type-error-expected-type&warn\cr
+type-of&warning\cr
+typecase&when\cr
+typep&wild-pathname-p\cr
+unbound-slot&with-accessors\cr
+unbound-slot-instance&with-compilation-unit\cr
+unbound-variable&with-condition-restarts\cr
+undefined-function&with-hash-table-iterator\cr
+unexport&with-input-from-string\cr
+unintern&with-open-file\cr
+union&with-open-stream\cr
+unless&with-output-to-string\cr
+unread-char&with-package-iterator\cr
+unsigned-byte&with-simple-restart\cr
+untrace&with-slots\cr
+unuse-package&with-standard-io-syntax\cr
+unwind-protect&write\cr
+update-instance-for-different-class&write-byte\cr
+update-instance-for-redefined-class&write-char\cr
+upgraded-array-element-type&write-line\cr
+upgraded-complex-part-type&write-sequence\cr
+upper-case-p&write-string\cr
+use-package&write-to-string\cr
+use-value&y-or-n-p\cr
+user-homedir-pathname&yes-or-no-p\cr
+values&zerop\cr
+}

concept-classes.tex

@@ -0,0 +1,920 @@
+% -*- Mode: TeX -*-
+%% Classes
+
+While the \CLOS\ is general enough to describe all \term{standardized} \term{classes}
+(including, for example, \typeref{number}, \typeref{hash-table}, and
+\typeref{symbol}), \thenextfigure\ contains a list of \term{classes} that are
+especially relevant to understanding the \CLOS.
+
+\DefineFigure{ObjectSystemClasses}
+\displaythree{Object System Classes}{
+built-in-class&method-combination&standard-object\cr
+class&standard-class&structure-class\cr
+generic-function&standard-generic-function&structure-object\cr
+method&standard-method&\cr
+}
+
+\beginsubSection{Introduction to Classes}
+
+A \newterm{class} is an \term{object} that determines the structure and behavior 
+of a set of other \term{objects}, which are called its \newtermidx{instances}{instance}.   
+
+A \term{class} can inherit structure and behavior from other \term{classes}.
+A \term{class} whose definition refers to other \term{classes} for the purpose 
+of inheriting from them is said to be a \term{subclass} of each of
+those \term{classes}. The \term{classes} that are designated for purposes of
+inheritance are said to be \term{superclasses} of the inheriting \term{class}.
+                                              
+A \term{class} can have a \term{name}. The \term{function} \funref{class-name} 
+takes a \term{class} \term{object} and returns its \term{name}. 
+The \term{name} of an anonymous \term{class} is \nil.  A \term{symbol} 
+can \term{name} a \term{class}. The \term{function} \funref{find-class} takes a
+\term{symbol} and returns the \term{class} that the \term{symbol} names.
+A \term{class} has a \term{proper name} if the \term{name} is a \term{symbol}
+and if the \term{name} of the \term{class} names that \term{class}.
+That is, a \term{class}~$C$ has the \term{proper name}~$S$ if $S=$
+\f{(class-name $C$)} and $C=$ \f{(find-class $S$)}.
+Notice that it is possible for 
+\f{(find-class $S\sub 1$)} $=$ \f{(find-class $S\sub 2$)}
+and $S\sub 1\neq S\sub 2$.
+If $C=$ \f{(find-class $S$)}, we say that $C$ is the \term{class} \term{named} $S$.
+
+A \term{class} $C\sub{1}$ is 
+a \newterm{direct superclass} of a \term{class} $C\sub{2}$
+if $C\sub{2}$ explicitly designates $C\sub{1}$ 
+as a \term{superclass} in its definition.
+In this case $C\sub{2}$ is a \newterm{direct subclass} of $C\sub{1}$.
+A \term{class} $C\sub{n}$ is a \newterm{superclass} of 
+a \term{class} $C\sub{1}$ if there exists a series of
+\term{classes} $C\sub{2},\ldots,C\sub{n-1}$ such that 
+$C\sub{i+1}$ is a \term{direct superclass} of $C\sub{i}$ for $1 \leq i<n$.
+In this case, $C\sub{1}$ is a \newterm{subclass} of $C\sub{n}$.
+A \term{class} is considered neither a \term{superclass} nor a \term{subclass} of itself.
+That is, if $C\sub{1}$ is a \term{superclass} of $C\sub{2}$, 
+then $C\sub{1} \neq C\sub{2}$.
+The set of \term{classes} consisting of some given \term{class} $C$ 
+along with all of its \term{superclasses} is called ``$C$ and its superclasses.''
+
+Each \term{class} has a \newterm{class precedence list},
+which is a total ordering on the set of the given \term{class} and its \term{superclasses}.
+The total ordering is expressed as a list ordered from most specific to least specific.
+The \term{class precedence list} is used in several ways.  In general, more
+specific \term{classes} can \newterm{shadow}\meaning{1} features that would
+otherwise be inherited from less specific \term{classes}.
+The \term{method} selection and combination process uses 
+the \term{class precedence list} to order \term{methods} 
+from most specific to least specific. 
+ 
+When a \term{class} is defined, the order in which its direct \term{superclasses}
+are mentioned in the defining form is important.  Each \term{class} has a
+\newterm{local precedence order}, which is a \term{list} consisting of the
+\term{class} followed by its \term{direct superclasses} in the order mentioned
+in the defining \term{form}.
+
+A \term{class precedence list} is always consistent with the
+\term{local precedence order} of each \term{class} in the list.  
+The \term{classes} in each \term{local precedence order} appear
+within the \term{class precedence list} in the same order.  
+If the \term{local precedence orders} are inconsistent with each other, 
+no \term{class precedence list} can be constructed, and an error is signaled.
+The \term{class precedence list} and its computation is discussed
+in \secref\DeterminingtheCPL.
+
+\term{classes} are organized into a directed acyclic graph.
+There are two distinguished \term{classes}, named \typeref{t} and \typeref{standard-object}.
+The \term{class} named \typeref{t} has no \term{superclasses}. 
+It is a \term{superclass} of every \term{class} except itself.  
+The \term{class} named \typeref{standard-object} is an \term{instance} of 
+\theclass{standard-class} and is a \term{superclass} of
+every \term{class} that is an \term{instance} of \theclass{standard-class} except itself.
+
+\reviewer{Barmar: This or something like it needs to be said in the introduction.}%!!!
+There is a mapping from the object system \term{class} space into
+the \term{type} space.  Many of the standard \term{types} specified 
+in this document have a corresponding \term{class} that has the same 
+\term{name} as the \term{type}. Some \term{types} do not have a
+corresponding \term{class}. The integration of the \term{type} and \term{class}
+systems is discussed in \secref\IntegratingTypesAndClasses.
+
+\term{Classes} are represented by \term{objects} that are themselves
+\term{instances} of \term{classes}. 
+The \term{class} of the \term{class} of an \term{object} is termed
+the \newterm{metaclass} of that \term{object}. When no misinterpretation is
+possible, the term \term{metaclass} is used to refer to a \term{class}
+that has \term{instances} that are themselves \term{classes}. The \term{metaclass}
+determines the form of inheritance used by the \term{classes} that are its
+\term{instances} and the representation of the \term{instances} of those \term{classes}.
+The \CLOS\ provides a default \term{metaclass}, \typeref{standard-class}, that is
+appropriate for most programs.
+%The meta-object protocol provides
+%mechanisms for defining and using new metaclasses.
+
+Except where otherwise specified, all \term{classes} mentioned in this
+standard are \term{instances} of \theclass{standard-class},
+all \term{generic functions} are \term{instances} 
+of \theclass{standard-generic-function},
+and all \term{methods} are \term{instances} of \theclass{standard-method}.
+
+
+\endsubSection%{Classes}
+%\beginsubsubsection{Metaclasses}
+%??? Is the following paragraph necessary in this specification???
+%
+%The \newterm{metaclass} of an object is the class of its class.  The
+%metaclass determines the representation of instances of its instances and
+%the forms of inheritance used by its instances for slot descriptions and
+%method inheritance.  The metaclass mechanism can be used to provide
+%particular forms of optimization or to tailor the \CLOS\ for particular
+%uses.  
+%The protocol for defining metaclasses is discussed in the chapter
+%``The \CLOS\ Meta-Object Protocol.''
+
+%\endsubsubsection%{Metaclasses}
+
+\beginsubsubsection{Standard Metaclasses}
+
+The \CLOS\ provides a number of predefined \term{metaclasses}. 
+These include the \term{classes} \typeref{standard-class}, 
+\typeref{built-in-class}, and \typeref{structure-class}:
+
+\beginlist
+
+\itemitem{\bull}
+\Theclass{standard-class} is the default \term{class} of 
+\term{classes} defined by \macref{defclass}.
+                        
+\itemitem{\bull} \Theclass{built-in-class} is the \term{class} whose
+\term{instances} are \term{classes} that have special implementations with
+restricted capabilities.  Any \term{class} that corresponds to a standard
+\term{type} might be an \term{instance} of \typeref{built-in-class}.
+The predefined \term{type} specifiers that are required to have
+corresponding \term{classes} are listed in \figref\ClassTypeCorrespondence.  
+It is \term{implementation-dependent} whether each of these \term{classes} 
+is implemented as a \term{built-in class}.
+
+\itemitem{\bull}                     
+All \term{classes} defined by means of \macref{defstruct} are
+\term{instances} of \theclass{structure-class}.
+\endlist
+
+\endsubsubsection%{Standard Metaclasses}
+
+\beginsubSection{Defining Classes}
+           
+The macro \macref{defclass} is used to define a new named \term{class}.  
+%The syntax for \macref{defclass} is given in Figure ??
+
+The definition of a \term{class} includes:
+
+\beginlist
+
+\itemitem{\bull} The \term{name} of the new \term{class}. 
+  For newly-defined \term{classes} this \term{name} is a \term{proper name}.
+
+\itemitem{\bull} The list of the direct \term{superclasses} of the new \term{class}. 
+
+\itemitem{\bull} A set of \newtermidx{slot specifiers}{slot specifier}.
+  Each \term{slot specifier} includes the \term{name} of the \term{slot} 
+  and zero or more \term{slot} options.  A \term{slot} option pertains 
+  only to a single \term{slot}.  If a \term{class} definition contains
+  two \term{slot specifiers} with the same \term{name}, an error is signaled.
+
+\itemitem{\bull} A set of \term{class} options.  
+  Each \term{class} option pertains to the \term{class} as a whole.  
+
+\endlist
+                                              
+The \term{slot} options and \term{class} options of 
+the \macref{defclass} form provide mechanisms for the following:
+
+\beginlist
+
+\itemitem{\bull} Supplying a default initial value \term{form} 
+for a given \term{slot}.  
+
+\itemitem{\bull} Requesting that \term{methods} for \term{generic functions}
+be automatically generated for reading or writing \term{slots}. 
+
+\itemitem{\bull} Controlling whether a given \term{slot} is shared by 
+all \term{instances}
+of the \term{class} or whether each 
+\term{instance} of the \term{class} has its own \term{slot}.
+
+\itemitem{\bull} Supplying a set of initialization arguments and initialization
+argument defaults to be used in \term{instance} creation.
+
+%\itemitem{\bull} Requesting that a constructor function be automatically
+%generated for making instances of the new class.
+
+\itemitem{\bull} Indicating that the \term{metaclass} is to be other 
+than the default.  The \kwd{metaclass} option is reserved for future use; 
+an implementation can be extended to make use of the \kwd{metaclass}
+option.
+
+\itemitem{\bull} Indicating the expected \term{type} for the value stored
+in the \term{slot}.
+
+\itemitem{\bull} Indicating the \term{documentation string} for the \term{slot}.
+
+\endlist 
+
+\endsubSection%{Defining Classes}
+
+\goodbreak
+
+\beginsubSection{Creating Instances of Classes}
+                      
+The generic function \funref{make-instance} creates and returns a new
+\term{instance} of a \term{class}.  
+The \OS\ provides several mechanisms for
+specifying how a new \term{instance} is to be initialized.  For example, it
+is possible to specify the initial values for \term{slots} in newly created
+\term{instances} 
+either by giving arguments to \funref{make-instance} or by
+providing default initial values.  Further initialization activities
+can be performed by \term{methods} written for \term{generic functions} 
+that are
+part of the initialization protocol.  The complete initialization
+protocol is described in \secref\ObjectCreationAndInit.
+
+\endsubSection%{Creating Instances of Classes}
+
+\beginsubSection{Inheritance}
+\DefineSection{Inheritance}
+                                              
+A \term{class} can inherit \term{methods}, \term{slots}, 
+and some \macref{defclass} options from its \term{superclasses}.  
+Other sections describe the inheritance of \term{methods}, 
+the inheritance of \term{slots} and \term{slot} options, 
+and the inheritance of \term{class} options.
+ 
+
+\beginsubsubsection{Examples of Inheritance}
+
+\code
+ (defclass C1 () 
+     ((S1 :initform 5.4 :type number) 
+      (S2 :allocation :class)))
+ 
+ (defclass C2 (C1) 
+     ((S1 :initform 5 :type integer)
+      (S2 :allocation :instance)
+      (S3 :accessor C2-S3)))
+\endcode
+
+\term{Instances} of the class \f{C1} have a \term{local slot} named \f{S1},
+whose default initial value is 5.4 and
+whose \term{value} should always be a \term{number}.
+The class \f{C1} also has a \term{shared slot} named \f{S2}.
+
+There is a \term{local slot} named \f{S1} in \term{instances} of \f{C2}.
+The default initial value of \f{S1} is 5.
+The value of \f{S1} should always be of type \f{(and integer number)}.
+There are also \term{local slots} named \f{S2} and \f{S3} in \term{instances} of \f{C2}.
+The class \f{C2} has a \term{method} for \f{C2-S3} for reading the value of slot \f{S3};
+there is also a \term{method} for \f{(setf C2-S3)} that writes the value of \f{S3}.
+
+\endsubsubsection%{Examples of Inheritance}
+
+\beginsubsubsection{Inheritance of Class Options}
+     
+The \kwd{default-initargs} class option is inherited.  The set of
+defaulted initialization arguments for a \term{class} is the union of the
+sets of initialization arguments supplied in
+the \kwd{default-initargs} class options of the \term{class} and its \term{superclasses}.
+When more than one default initial value \term{form} is supplied for a given
+initialization argument, the default initial value \term{form} that is used
+is the one supplied by the \term{class} that is most specific according to
+the \term{class precedence list}.
+
+
+If a given \kwd{default-initargs} class option specifies an
+initialization argument of the same \term{name} more than once, an
+error \oftype{program-error} is signaled.
+
+\endsubsubsection%{Inheritance of Class Options}
+
+
+\endsubSection%{Inheritance}
+
+
+\beginsubSection{Determining the Class Precedence List}
+\DefineSection{DeterminingtheCPL}
+
+The \macref{defclass} form for a \term{class} provides a total ordering
+on that \term{class} and its direct \term{superclasses}.  This ordering is
+called the \newterm{local precedence order}.  It is an ordered list of the
+\term{class} and its direct \term{superclasses}. The
+\newterm{class precedence list} for a class $C$ is a total ordering on
+$C$ and its \term{superclasses} that is consistent with the
+\term{local precedence orders} for each of $C$ and its \term{superclasses}.
+
+A \term{class} precedes its direct \term{superclasses}, 
+and a direct \term{superclass} precedes all other 
+direct \term{superclasses} specified to its right 
+in the \term{superclasses} list of the \macref{defclass} form.  
+For every class $C$, define $$R\sub C=\{(C,C\sub 1),(C\sub 1,C\sub
+2),\ldots,(C\sub {n-1},C\sub n)\}$$ where $C\sub 1,\ldots,C\sub n$ are
+the direct \term{superclasses} of $C$ in the order in which
+they are mentioned in the \macref{defclass} form. These ordered pairs
+generate the total ordering on the class $C$ and its direct
+\term{superclasses}.
+
+Let $S\sub C$ be the set of $C$ and its \term{superclasses}. Let $R$ be
+$$R=\bigcup\sub{c\in {S\sub C}}R\sub c$$.
+
+\reviewer{Barmar: ``Consistent'' needs to be defined, or maybe we should say
+``logically consistent''?}%!!!
+
+The set $R$ might or might not generate a partial ordering, depending on
+whether the $R\sub c$, $c\in S\sub C$, are 
+consistent; it is assumed
+that they are consistent and that $R$ generates a partial ordering.
+When the $R\sub c$ are not consistent, it is said that $R$ is inconsistent.
+
+%This partial ordering is generated by taking the the transitive
+%closure of the set $R\cup \{(c,c) \vert c\in {S\sub C}\}$.  When
+%$(C\sub 1,C\sub 2)\in R$\negthinspace, it is said that $C\sub 1$ 
+%{\bit precedes or equals} $C\sub 2$.  Intuitively, $C\sub 1$ precedes
+%or equals $C\sub 2$ when $C\sub 1=C\sub 2$ or $C\sub 2$ is a
+%superclass of $C\sub 1$.  
+%
+%Recall that a partial ordering of the set $S$ is a relation between 
+%objects of $S$ that is transitive, reflexive, and antisymmetric. The 
+%set $\{(c,c) \vert c\in {S\subC}\}$ was added to the transitive 
+%closure of the set $R$ in order to make the relation reflexive.  In 
+%the remainder of this section the set of precedence relations $R$ and 
+%not the partial ordering will be used.
+
+To compute the \term{class precedence list} for~$C$\negthinspace,
+topologically sort the elements of $S\sub C$ with respect to the
+partial ordering generated by $R$\negthinspace.  When the topological
+sort must select a \term{class} from a set of two or more 
+\term{classes}, none of
+which are preceded by other \term{classes} with respect to~$R$\negthinspace,
+the \term{class} selected is chosen deterministically, as described below.
+
+If $R$ is inconsistent, an error is signaled.
+
+
+\goodbreak
+
+\beginsubsubsection{Topological Sorting}
+
+% !!!
+% Barmar: Sometimes $C$ refers  to the original class and sometimes it refers
+%         to an element of $S\sub C$.
+% KAB: Really? Where?  I don't see any.
+
+%I didn't have time to figure out this comment but maybe someone will another time.
+% -kmp 11-Oct-90
+Topological sorting proceeds by finding a class $C$ in~$S\sub C$ such
+that no other \term{class} precedes that element according to the elements
+in~$R$\negthinspace.  The class $C$ is placed first in the result.
+Remove $C$ from $S\sub C$, and remove all pairs of the form $(C,D)$,
+$D\in S\sub C$, from $R$\negthinspace. Repeat the process, adding
+\term{classes} with no predecessors to the end of the result.  Stop when no
+element can be found that has no predecessor.
+
+If $S\sub C$ is not empty and the process has stopped, the set $R$ is
+inconsistent. If every \term{class} in the finite set of 
+\term{classes} is preceded
+by another, then $R$ contains a loop. That is, there is a chain of
+classes $C\sub 1,\ldots,C\sub n$ such that $C\sub i$ precedes
+$C\sub{i+1}$, $1\leq i<n$, and $C\sub n$ precedes $C\sub 1$.
+
+Sometimes there are several \term{classes} from $S\sub C$ with no
+predecessors.  In this case select the one that has a direct
+\term{subclass} rightmost in the \term{class precedence list} computed so far.
+%Because a direct superclass precedes all other direct superclasses to
+%its right, there can be only one such candidate class. 
+%%Barmar thinks the next sentence is redundant with previous paragraph,
+%but I think it's useful for emphasis. I put it in parens to deemphasize it. -kmp 11-Oct-90
+(If there is no such candidate \term{class}, $R$ does not generate 
+a partial ordering---the $R\sub c$, $c\in S\sub C$, are inconsistent.)
+
+In more precise terms, let $\{N\sub 1,\ldots,N\sub m\}$, $m\geq 2$, be
+the \term{classes} from $S\sub C$ with no predecessors.  Let $(C\sub
+1\ldots C\sub n)$, $n\geq 1$, be the \term{class precedence list}
+constructed so far.  $C\sub 1$ is the most specific \term{class}, and $C\sub
+n$ is the least specific.  Let $1\leq j\leq n$ be the largest number
+such that there exists an $i$ where $1\leq i\leq m$ and $N\sub i$
+is a direct \term{superclass} of $C\sub j$; $N\sub i$ is placed next.
+
+% The effect of this rule for selecting from a set of \term{classes} with no
+% predecessors is that the \term{classes} in a simple \term{superclass} chain are
+% adjacent in the \term{class precedence list} and that \term{classes} in each
+% relatively separated subgraph are adjacent in the \term{class precedence list}.
+% For example, let $T\sub 1$ and $T\sub 2$ be subgraphs
+% whose only element in common is the class $J$\negthinspace. Suppose
+% that no \term{superclass} of $J$ appears in either $T\sub 1$ or $T\sub 2$.
+% Let $C\sub 1$ be the bottom of $T\sub 1$; and let $C\sub 2$ be the
+% bottom of $T\sub 2$.  Suppose $C$ is a \term{class} whose direct \term{superclasses}
+% are $C\sub 1$ and $C\sub 2$ in that order, then the 
+% \term{class precedence list}
+% for $C$ will start with $C$ and will be followed by all \term{classes}
+% in $T\sub 1$ except $J$. All the \term{classes} of $T\sub 2$ will be next.
+% The class $J$ and its \term{superclasses} will appear last.
+%
+%% Replaced as follows per RPG. -kmp 13-Jan-92
+
+The effect of this rule for selecting from a set of \term{classes} with no
+predecessors is that the \term{classes} in a simple \term{superclass} chain are
+adjacent in the \term{class precedence list} and that \term{classes} in each
+relatively separated subgraph are adjacent in the \term{class precedence list}.
+For example, let $T\sub 1$ and $T\sub 2$ be subgraphs whose only
+element in common is the class $J$\negthinspace.
+% Suppose that no \term{superclass} of $J$ appears in 
+% either $T\sub 1$ or $T\sub 2$ and that $J$ 
+% is an indirect superclass of every class in both $T\sub 1$ and $T\sub 2$.
+%% Rewritten by RPG to avoid use of "indirect superclass". -kmp 13-Jan-92
+Suppose that no superclass of $J$ appears in either $T\sub 1$ or $T\sub 2$,
+and that $J$ is in the superclass chain of every class in both $T\sub 1$ and $T\sub 2$.
+    Let $C\sub 1$ be the bottom of $T\sub 1$; 
+and let $C\sub 2$ be the bottom of $T\sub 2$.
+Suppose $C$ is a \term{class} whose direct \term{superclasses}
+are $C\sub 1$ and $C\sub 2$ in that order, then the \term{class precedence list}
+for $C$ starts with $C$ and is followed by
+all \term{classes} in $T\sub 1$ except $J$. 
+All the \term{classes} of $T\sub 2$ are next.
+The \term{class} $J$ and its \term{superclasses} appear last.
+
+\endsubsubsection%{Topological Sorting}
+
+\beginsubsubsection{Examples of Class Precedence List Determination}
+
+This example determines a \term{class precedence list} for the
+class \f{pie}.  The following \term{classes} are defined:
+
+\code
+ (defclass pie (apple cinnamon) ())
+ 
+ (defclass apple (fruit) ())
+ 
+ (defclass cinnamon (spice) ())
+ 
+ (defclass fruit (food) ())
+
+ (defclass spice (food) ())
+
+ (defclass food () ())
+\endcode
+
+% $S$ => "$S\sub{pie}$ per Barmar and Laubsch.
+The set $S\sub{pie}$~$=$ $\{${\tt pie, apple, cinnamon, fruit, spice, food,
+standard-object, t}$\}$. The set $R$~$=$ $\{${\tt (pie, apple),
+(apple, cinnamon), (apple, fruit), (cinnamon, spice), \hfil\break
+(fruit, food), (spice, food), (food, standard-object), (standard-object,
+t)}$\}$.
+
+The class \f{pie} is not preceded by anything, so it comes first;
+the result so far is {\tt (pie)}.  Remove \f{pie} from $S$ and pairs
+mentioning \f{pie} from $R$ to get $S$~$=$ $\{${\tt apple, cinnamon,
+fruit, spice, food, standard-object, t}$\}$ and $R$~$=$~$\{${\tt
+(apple, cinnamon), (apple, fruit), (cinnamon, spice),\hfil\break (fruit,
+food), (spice, food), (food, standard-object),
+(standard-object, t)}$\}$.
+
+The class \f{apple} is not preceded by anything, so it is next; the
+result is {\tt (pie apple)}. Removing \f{apple} and the relevant
+pairs results in $S$~$=$ $\{${\tt cinnamon, fruit, spice, food,
+standard-object, t}$\}$ and $R$~$=$ $\{${\tt (cinnamon, spice),
+(fruit, food), (spice, food), (food, standard-object),\hfil\break
+(standard-object, t)}$\}$.
+
+The classes \f{cinnamon} and {\tt fruit} are not preceded by
+anything, so the one with a direct \term{subclass} rightmost in the 
+\term{class precedence list} computed so far goes next.  The class \f{apple} is a
+direct \term{subclass} of {\tt fruit}, and the class \f{pie} is a direct
+\term{subclass} of \f{cinnamon}.  Because \f{apple} appears to the right
+of \f{pie} in the \term{class precedence list}, 
+{\tt fruit} goes next, and the
+result so far is {\tt (pie apple fruit)}.  $S$~$=$ $\{${\tt cinnamon,
+spice, food, standard-object, t}$\}$; $R$~$=$ $\{${\tt (cinnamon,
+spice), (spice, food),\hfil\break (food, standard-object),
+(standard-object, t)}$\}$.
+
+The class \f{cinnamon} is next, giving the result so far as {\tt
+(pie apple fruit cinnamon)}.  At this point $S$~$=$ $\{${\tt spice,
+food, standard-object, t}$\}$; $R$~$=$ $\{${\tt (spice, food), (food,
+standard-object), (standard-object, t)}$\}$.
+
+The classes \f{spice}, \f{food}, \typeref{standard-object}, and 
+\typeref{t} are added in that order, and the \term{class precedence list} 
+is \f{(pie apple fruit cinnamon spice food standard-object t)}.
+
+It is possible to write a set of \term{class} definitions that cannot be 
+ordered.   For example: 
+
+\code
+ (defclass new-class (fruit apple) ())
+ 
+ (defclass apple (fruit) ())
+\endcode
+
+The class \f{fruit} must precede \f{apple} 
+because the local ordering of \term{superclasses} must be preserved.
+The class \f{apple} must precede \f{fruit} 
+because a \term{class} always precedes its own \term{superclasses}.
+When this situation occurs, an error is signaled, as happens here
+when the system tries to compute the \term{class precedence list} 
+%Barmar suggested we add:
+of \f{new-class}.
+
+The following might appear to be a conflicting set of definitions:
+
+\code
+ (defclass pie (apple cinnamon) ())
+ 
+ (defclass pastry (cinnamon apple) ())
+ 
+ (defclass apple () ())
+ 
+ (defclass cinnamon () ())
+\endcode
+
+The \term{class precedence list} for \f{pie} is 
+\f{(pie apple cinnamon standard-object t)}.
+
+The \term{class precedence list} for \f{pastry} is  
+\f{(pastry cinnamon apple standard-object t)}.
+
+It is not a problem for \f{apple} to precede \f{cinnamon} in the
+ordering of the \term{superclasses} of \f{pie} but not in the ordering for
+\f{pastry}.  However, it is not possible to build a new \term{class} that
+has both \f{pie} and \f{pastry} as \term{superclasses}.
+
+\endsubsubsection%{Examples of Class Precedence List Determination}
+
+\endsubSection%{Determining the Class Precedence List}
+\beginsubSection{Redefining Classes}  
+\DefineSection{ClassReDef}
+                                
+%"instance" => "direct instance" per Barrett,Barmar,Moon.
+A \term{class} that is a \term{direct instance} of \typeref{standard-class} can
+be redefined if the new \term{class} is also
+%"instance" => "direct instance" per Barrett,Barmar,Moon.
+a \term{direct instance} of \typeref{standard-class}.
+Redefining a \term{class} modifies the existing
+\term{class} \term{object} to reflect the new \term{class} definition; it does not
+create a new \term{class} \term{object} for the \term{class}.  
+Any \term{method} \term{object} created by a \kwd{reader}, \kwd{writer}, 
+or \kwd{accessor} option specified by the old \macref{defclass} form is
+removed from the corresponding \term{generic function}.
+\term{Methods} specified by the new \macref{defclass} form are added.
+
+% any function specified by the \kwd{constructor} option of the
+% old \macref{defclass} form is removed from the corresponding symbol function cell.
+
+When the class $C$ is redefined, changes are propagated to its \term{instances}
+and to \term{instances} of any of its \term{subclasses}.  Updating such an
+\term{instance} occurs at an \term{implementation-dependent} time, but no later than
+the next time a \term{slot} 
+of that \term{instance} is read or written.  Updating an
+\term{instance} 
+does not change its identity as defined by \thefunction{eq}.
+The updating process may change the \term{slots} of that
+particular \term{instance}, 
+but it does not create a new \term{instance}.  Whether
+updating an \term{instance} consumes storage is \term{implementation-dependent}.
+
+Note that redefining a \term{class} may cause \term{slots} to be added or 
+deleted.  If a \term{class} is redefined in a way that changes the set of
+\term{local slots} \term{accessible} in \term{instances}, the \term{instances} 
+are updated.  It is \term{implementation-dependent} whether \term{instances} 
+are updated if a \term{class} is redefined in a way that does not change 
+the set of \term{local slots} \term{accessible} in \term{instances}.
+
+The value of a \term{slot} 
+that is specified as shared both in the old \term{class}
+and in the new \term{class} is retained.  
+If such a \term{shared slot} was unbound
+in the old \term{class}, it is unbound in the new \term{class}.  
+\term{Slots} that
+were local in the old \term{class} and that are shared in the new 
+\term{class} are
+initialized.  Newly added \term{shared slots} are initialized.
+
+Each newly added \term{shared slot} is set to the result of evaluating the
+%captured \kwd{initform} form
+\term{captured initialization form} for the \term{slot} that was specified 
+in the \macref{defclass} \term{form} for the new \term{class}.  
+%If there is no \kwd{initform} form,
+If there was no \term{initialization form}, the \term{slot} is unbound.
+
+If a \term{class} is redefined in such a way that the set of
+\term{local slots} \term{accessible} in an \term{instance} of the \term{class} 
+is changed, a two-step process of updating the \term{instances} of the
+\term{class} takes place.  The process may be explicitly started by 
+invoking the generic function \funref{make-instances-obsolete}.  This
+two-step process can happen in other circumstances in some implementations.
+For example, in some implementations this two-step process is
+triggered if the order of \term{slots} in storage is changed.
+
+The first step modifies the structure of the \term{instance} by adding new
+\term{local slots} and discarding \term{local slots} that are not
+defined in the new version of the \term{class}.  The second step
+initializes the newly-added \term{local slots} and performs any other
+user-defined actions. These two steps are further specified
+in the next two sections.
+
+\beginsubsubsection{Modifying the Structure of Instances}
+
+\reviewer{Barmar: What about shared slots that are deleted?}%!!!
+
+The first step modifies the structure of \term{instances} of the redefined
+\term{class} to conform to its new \term{class} definition.  
+\term{Local slots} specified
+by the new \term{class} definition that are not specified as either local or
+shared by the old \term{class} are added, and \term{slots} 
+not specified as either
+local or shared by the new \term{class} definition that are specified as
+local by the old \term{class} are discarded. 
+The \term{names} of these added and discarded
+\term{slots} are passed as arguments 
+to \funref{update-instance-for-redefined-class}
+as described in the next section.
+
+The values of \term{local slots} specified by both the new and old
+\term{classes} are retained. If such a \term{local slot} was unbound,
+it remains unbound.
+
+The value of a \term{slot} that is specified as shared in the old 
+\term{class} and as local in the new \term{class} is retained.  If such 
+a \term{shared slot} was unbound, the \term{local slot} is unbound.
+
+\endsubsubsection%{Modifying the Structure of the Instance}
+
+
+\beginsubsubsection{Initializing Newly Added Local Slots}
+
+The second step initializes the newly added \term{local slots} and performs
+any other user-defined actions.  This step is implemented by the generic
+function \funref{update-instance-for-redefined-class}, which is called after
+completion of the first step of modifying the structure of the
+\term{instance}.
+
+The generic function \funref{update-instance-for-redefined-class} takes
+four required arguments: the \term{instance} being updated after it has
+undergone the first step, a list of the names of \term{local slots} that were
+added, a list of the names of \term{local slots} that were discarded, and a
+property list containing the \term{slot} names and values of 
+\term{slots} that were
+discarded and had values.  Included among the discarded \term{slots} are
+\term{slots} that were local in the old \term{class} and that are shared in the new
+\term{class}.
+                      
+The generic function \funref{update-instance-for-redefined-class} also
+takes any number of initialization arguments.  When it is called by
+the system to update an \term{instance} whose \term{class} 
+has been redefined, no
+initialization arguments are provided.
+                                               
+There is a system-supplied primary \term{method} for 
+\funref{update-instance-for-redefined-class} whose \term{parameter specializer}
+for its \term{instance} argument is \theclass{standard-object}.  
+First this \term{method} checks the validity of initialization arguments and signals an
+error if an initialization argument is supplied that is not declared
+as valid.  (For more information, \seesection\DeclaringInitargValidity.)
+Then it calls the generic function
+\funref{shared-initialize} with the following arguments: the 
+\term{instance},
+the list of \term{names} of 
+the newly added \term{slots}, and the initialization
+arguments it received.
+
+\endsubsubsection%{Initializing Newly added Local Slots}
+
+\beginsubsubsection{Customizing Class Redefinition}
+             
+\reviewer{Barmar: This description is hard to follow.}%!!!
+
+\term{Methods} for \funref{update-instance-for-redefined-class} may be 
+defined to specify actions to be taken when an \term{instance} is updated.
+If only \term{after methods} for \funref{update-instance-for-redefined-class} are
+defined, they will be run after the system-supplied primary \term{method} for
+initialization and therefore will not interfere with the default
+behavior of \funref{update-instance-for-redefined-class}.  Because no
+initialization arguments are passed to \funref{update-instance-for-redefined-class}
+when it is called by the system, the 
+%\kwd{initform} forms 
+\term{initialization forms} for \term{slots} 
+that are filled by \term{before methods} for \funref{update-instance-for-redefined-class} 
+will not be evaluated by \funref{shared-initialize}.
+
+\term{Methods} for \funref{shared-initialize} may be defined to customize
+\term{class} redefinition.  For more information, \seesection\SharedInitialize.
+
+\endsubsubsection%{Customizing Class Redefinition}
+
+%% The following was removed by request of Symbolics, who point out that other 
+%% extensions may well be permitted too, and there's no reason to give special
+%% advertising to these. -kmp 9-Oct-90
+%
+% \beginsubsubsection{Extensions}
+% 
+% There are two allowed extensions to \term{class} redefinition: 
+% 
+% \beginlist
+% 
+% \itemitem{\bull} The \OS\ may be extended to permit the new \term{class}
+% to be an \term{instance} of a \term{metaclass} 
+% other than the \term{metaclass} of the
+% old \term{class}.
+% 
+% \itemitem{\bull} The \OS\ may be extended to support an updating process
+% when either the old or the new \term{class} is an \term{instance} of a
+% \term{class} 
+% other than \typeref{standard-class} that is not a \term{built-in class}.
+% 
+% \endlist
+% 
+% \endsubsubsection%{Extensions}
+
+\beginsubSection{Integrating Types and Classes} 
+\DefineSection{IntegratingTypesAndClasses}
+                                              
+The \CLOS\ maps the space of \term{classes} into the space of \term{types}.
+Every \term{class} that has a proper name has a corresponding \term{type} 
+with the same \term{name}.  
+
+The proper name of every \term{class} is a valid \term{type specifier}.  In
+addition, every \term{class} \term{object} is a valid \term{type specifier}.  
+Thus the expression \f{(typep \param{object} \param{class})} evaluates to 
+\term{true} if the \term{class} of \param{object} is \param{class} itself or 
+a \term{subclass} of \term{class}.  The evaluation of the expression
+\f{(subtypep class1 class2)} returns the values 
+%was {\tt t~t} but came out as "t~t" in formatted form. -kmp 10-Oct-90
+%\t~\t\ if \f{class1} is a subclass of \f{class2} or if they are the
+\term{true} and \term{true} if \f{class1} is a subclass of \f{class2} or if they are the
+same \term{class}; otherwise it returns the values 
+%was {\tt nil~t}
+%\nil~\t.
+\term{false} and \term{true}.
+% If $I$ is an \term{instance} of some \term{class}
+% $C$ named $S$ and $C$ is an \term{instance} of \typeref{standard-class}, 
+% the evaluation of the expression \f{(type-of $I$\/)} will return $S$ if
+% $S$ is the proper name of $C$\negthinspace; if $S$ is not the proper
+% name of $C$\negthinspace, the expression \f{(type-of $I$\/)} will
+% return $C$\negthinspace.
+%% Barmar thought the above was too complicated.
+%% This is a partial simplification, not quite what he wanted, but hopefully
+%% an improvement.
+If  $I$ is an \term{instance} of some \term{class} $C$ named $S$ 
+and $C$ is an \term{instance} of \typeref{standard-class}, 
+the evaluation of the expression \f{(type-of $I$\/)} returns $S$ 
+if $S$ is the \term{proper name} of $C$; 
+otherwise, it returns $C$.
+
+Because the names of \term{classes} 
+and \term{class} \term{objects} are \term{type specifiers}, they may
+be used in the special form \specref{the} and in type declarations.
+                                   
+Many but not all of the predefined \term{type specifiers} have a
+corresponding \term{class} with 
+the same proper name as the \term{type}.  These type
+specifiers are listed in \figref\ClassTypeCorrespondence.
+For example, \thetype{array} has 
+a corresponding \term{class} named \typeref{array}.  
+No \term{type specifier} that is a
+list, such as {\tt (vector double-float 100)}, has a corresponding \term{class}.
+The \term{operator} \macref{deftype} does not create any \term{classes}.
+                                            
+Each \term{class} that corresponds to a predefined \term{type specifier} can
+be implemented in one of three ways, at the discretion of each implementation.
+It can be a \term{standard class},
+%% Not necessary. -kmp 12-Feb-92
+% (of the kind defined by \macref{defclass}), 
+a \term{structure class},
+%% Not necessary. -kmp 12-Feb-92
+% (defined by \macref{defstruct}), 
+\issue{METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED}
+%or a \term{built-in class}.
+or a \term{system class}.
+\endissue{METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED}
+%% Not necessary. -kmp 12-Feb-92
+% (implemented in a special, non-extensible way).
+
+%"instances" => "generalized instances" per Barmar,Moon.
+A \term{built-in class} is one whose \term{generalized instances} have restricted capabilities 
+or special representations.  Attempting to use \macref{defclass} to define 
+\term{subclasses} of a \typeref{built-in-class} signals an error.
+%"instance" => "generalized instance" per Barmar,Moon.
+Calling \funref{make-instance} to create a \term{generalized instance} of a 
+\term{built-in class} signals an error.  Calling \funref{slot-value} on a
+%"instance" => "generalized instance" per Barmar,Moon.
+\term{generalized instance} of a \term{built-in class} signals an error.
+Redefining a \term{built-in class} or using \funref{change-class} to change
+%"instance" => "object" per Barmar,Moon.
+the \term{class} of an \term{object} to or from a \term{built-in class} signals an error.
+However, \term{built-in classes} can be used as \term{parameter specializers} 
+in \term{methods}.
+                                        
+%The \OS\ specifies that all predefined \term{type specifiers}
+%listed in \figref\ClassTypeCorrespondence\ are built-in classes, but a particular
+%implementation is allowed to extend the \OS\ to define some of them as
+%standard classes or as structure classes.
+
+It is possible to determine whether a \term{class} is a \term{built-in class}
+by checking the \term{metaclass}.
+A \term{standard class}  is an \term{instance} of \theclass{standard-class},
+a \term{built-in class}  is an \term{instance} of \theclass{built-in-class}, and
+a \term{structure class} is an \term{instance} of \theclass{structure-class}.
+                                
+Each \term{structure} \term{type} created by \macref{defstruct} without 
+using the \kwd{type} option has a corresponding \term{class}.  
+%"instance" => "generalized instance" per Barmar,Moon.
+This \term{class} is a \term{generalized instance} of \theclass{structure-class}.  
+%A portable program must assume that
+%\typeref{structure-class} is a subclass of \typeref{built-in-class} and has the
+%same restrictions as built-in classes.  Whether \theclass{structure-class}
+%in fact is a subclass of \typeref{built-in-class} is
+%\term{implementation-dependent}. 
+The \kwd{include} option of \macref{defstruct} creates a direct
+\term{subclass} of the \term{class} 
+that corresponds to the included \term{structure} 
+%Added "type" -kmp
+\term{type}.
+
+% I moved the following two paragraphs here from the dictionary entry
+% for CLASS.  --sjl 7 Mar 92
+\issue{CONDITION-SLOTS:HIDDEN}
+It is \term{implementation-dependent} whether \term{slots} are involved in the
+operation of \term{functions} defined in this specification
+on \term{instances} of \term{classes} defined in this specification,
+except when \term{slots} are explicitly defined by this specification.
+
+If in a particular \term{implementation} a \term{class} defined in this specification
+has \term{slots} that are not defined by this specfication, the names of these \term{slots}
+must not be \term{external symbols} of \term{packages} defined in this specification nor
+otherwise \term{accessible} in \thepackage{cl-user}.
+\endissue{CONDITION-SLOTS:HIDDEN}
+
+                                                    
+The purpose of specifying that many of the standard \term{type specifiers} have a
+corresponding \term{class} is to enable users to write \term{methods} that
+discriminate on these \term{types}.  \term{Method} selection requires that a 
+\term{class precedence list} can be determined for each \term{class}. 
+
+The hierarchical relationships among the \term{type specifiers} are mirrored by
+relationships among the \term{classes} corresponding to those \term{types}.  
+%The existing type hierarchy is used for determining the
+%\term{class precedence list} 
+%for each \term{class} that corresponds to a predefined
+%\term{type}.  In some cases, 
+%a \term{local precedence order} is not specifiied for two \term{supertypes} 
+%of a
+%given \term{type specifier}.  For example, \typeref{null} is a \term{subtype} 
+%of both \typeref{symbol} and \typeref{list}, but it is not specified
+%whether \typeref{symbol} is more specific or less
+%specific than \typeref{list}.  The \CLOS\ defines those
+%relationships for all such \term{classes}.
+                 
+\figref\ClassTypeCorrespondence\ lists the set of \term{classes} 
+that correspond to predefined \term{type specifiers}.
+
+\issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+\DefineFigure{ClassTypeCorrespondence}
+\displaythree{Classes that correspond to pre-defined type specifiers}{
+arithmetic-error&generic-function&simple-error\cr
+array&hash-table&simple-type-error\cr
+bit-vector&integer&simple-warning\cr
+broadcast-stream&list&standard-class\cr
+built-in-class&logical-pathname&standard-generic-function\cr
+cell-error&method&standard-method\cr
+character&method-combination&standard-object\cr
+class&null&storage-condition\cr
+complex&number&stream\cr
+concatenated-stream&package&stream-error\cr
+condition&package-error&string\cr
+cons&parse-error&string-stream\cr
+control-error&pathname&structure-class\cr
+division-by-zero&print-not-readable&structure-object\cr
+echo-stream&program-error&style-warning\cr
+end-of-file&random-state&symbol\cr
+error&ratio&synonym-stream\cr
+file-error&rational&t\cr
+file-stream&reader-error&two-way-stream\cr
+float&readtable&type-error\cr
+floating-point-inexact&real&unbound-slot\cr
+floating-point-invalid-operation&restart&unbound-variable\cr
+floating-point-overflow&sequence&undefined-function\cr
+floating-point-underflow&serious-condition&vector\cr
+function&simple-condition&warning\cr
+}
+\endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+
+The \term{class precedence list} information specified in the entries for
+each of these \term{classes} are those that are required by the \OS.
+
+Individual implementations may be extended to define other type
+specifiers to have a corresponding \term{class}.  Individual implementations
+may be extended to add other \term{subclass} relationships and to add other
+\term{elements} to the \term{class precedence lists} as long as
+they do not violate the type relationships and disjointness
+requirements specified by this standard.
+A standard \term{class} defined with no direct \term{superclasses} is guaranteed to
+be disjoint from all of the \term{classes} in the table, except for the
+class named \typeref{t}.
+ 
+\endsubSection%{Integrating Types and Classes}

concept-compile.tex

@@ -0,0 +1,1418 @@
+% -*- Mode: TeX -*-
+%% Compilation
+
+% Rob MacLachlan wants some general discussion of inlining...
+%
+%   The most general statement of what I think that NOTINLINE does is:
+%   NOTINLINE inhibits any special-casing of calls to the named function.
+%   NOTINLINE requires that the call be done as though there was a run-time
+%   indirection through the SYMBOL-FUNCTION.
+%   
+%   In particular:
+%   NOTINLINE inhibits the (otherwise legal) compile-time resolution of
+%   function calls to the same DEFUN or defined in the same file.  [This is
+%   indeed explicitly allowed in the semantics of compilation.]
+%
+%   Implementations should also be encouraged to suppress any sort of inline
+%   coding when a function (+, CAR, whatever) is declared NOTINLINE.  Although
+%   users can't portably exploit this (due to the illegality of redefinition),
+%   some facilities such as TRACE may benefit from this capability.
+%
+%   Of course, it is possible that any of these actions are considered "inline
+%   expansion".  If so, there should at the very least be a glossary entry for
+%   inline expansion explaining this rather odd interpretation.
+
+\def\sim#1#2#3{{\cal S}\sub{#1}(#2,#3)}
+
+%The nature of the processing performed during compilation is discussed
+%in \secref\CompilationSemantics.  Following \secref\CompilationSemantics\ is
+%a discussion of the behavior of \funref{compile-file} and the
+%interface between \funref{compile-file} and \funref{load}.
+
+\beginsubSection{Compiler Terminology}
+\DefineSection{CompilationTerms}
+
+% Reference:  Issue CONSTANT-COMPILABLE-TYPES
+ 
+The following terminology is used in this section.
+ 
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The \newterm{compiler} is a utility that translates code into an
+\term{implementation-dependent} form that might be represented or
+executed efficiently.
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{compiler} refers to both of the \term{functions}
+\funref{compile} and \funref{compile-file}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+%In this section,
+The term \newterm{compiled code} refers to 
+\term{objects} representing compiled programs, such as \term{objects} constructed
+by \funref{compile} or by \funref{load} when \term{loading} a \term{compiled file}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{implicit compilation} refers to \term{compilation}
+performed during \term{evaluation}.
+
+\DefineSection{ConstantModification}
+%!!! This needs to be revisited. -kmp 12-Mar-91
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{literal object} refers to 
+     a quoted \term{object} 
+  or a \term{self-evaluating object} 
+  or an \term{object} that is a substructure of such an \term{object}.
+%% The following info is not in the glossary. -kmp 27-Jul-93
+A \term{constant variable} is not itself a \term{literal object}.
+%% I believe this discussion belongs somewhere other than in this terminology
+%% section.  I have added notes to the discussion of self-evaluating objects
+%% and QUOTE.  --sjl 3 Mar 92
+% \issue{CONSTANT-MODIFICATION:DISALLOW}
+% The consequences are undefined if \term{literal objects} are destructively modified.  
+% \endissue{CONSTANT-MODIFICATION:DISALLOW}
+%% \editornote{KMP: I don't think this is really right.  I think that we said that
+%%  it's ok to modify literal objects in code processed by COMPILE and EVAL. It's only
+%%  literal objects in file compilation that are suspect, no?}
+%% \editornote{SJL: No, it's an error to modify any literal constant.}
+ 
+%% "constants" => "literal constants" per Moon#4(first public review) -kmp 5-May-93
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+%% Note that there is more specific verbiage here than in Glossary.
+%% (The Glossary cross-references this section.)
+The term \newterm{coalesce} is defined as follows.
+Suppose \f{A} and \f{B} are two \term{literal constants} in the \term{source code},
+and that \f{A'} and \f{B'} are the corresponding \term{objects} in the \term{compiled code}.
+If \f{A'} and \f{B'} are \funref{eql} but
+\f{A} and \f{B} are not \funref{eql}, then it is said
+that \f{A} and \f{B} have been coalesced by the compiler.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{minimal compilation} refers to actions the compiler
+must take at \term{compile time}. These actions are specified in 
+\secref\CompilationSemantics.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The verb \newterm{process} refers to performing \term{minimal compilation},
+determining the time of evaluation for a \term{form},
+and possibly \term{evaluating} that \term{form} (if required).
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{further compilation} refers to
+\term{implementation-dependent} compilation beyond \term{minimal compilation}.
+%% The next sentence doesn't appear in the Glossary. -kmp 27-Jul-93
+That is, \term{processing} does not imply complete compilation.
+Block compilation and generation of machine-specific instructions are 
+examples of further compilation.
+Further compilation is permitted to take place at \term{run time}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+Four different \term{environments} relevant to compilation are
+distinguished:
+  the \term{startup environment},
+  the \term{compilation environment},
+  the \term{evaluation environment}, and
+  the \term{run-time environment}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The \newterm{startup environment} is
+the \term{environment} of the \term{Lisp image} 
+from which the \term{compiler} was invoked.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+%% This text is, however, much more verbose/detailed.
+The \newterm{compilation environment} is maintained by the compiler
+and is used to hold definitions and declarations to be used internally
+by the compiler.  Only those parts of a definition needed for correct
+compilation are saved. The \term{compilation environment} is used
+as the \term{environment} \term{argument} to macro expanders called by
+the compiler. It is unspecified whether a definition available in the
+\term{compilation environment} can be used in an \term{evaluation}
+initiated in the \term{startup environment} or \term{evaluation environment}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The \newterm{evaluation environment} is a \term{run-time environment}
+in which macro expanders and code specified by \specref{eval-when}
+to be evaluated are evaluated.  All evaluations initiated by the
+\term{compiler} take place in the \term{evaluation environment}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The \newterm{run-time environment} is the 
+\term{environment} in which the program being compiled will be executed.
+
+%% This text is missing from, but not inconsistent with, the Glossary. -kmp 27-Jul-93
+The \term{compilation environment} inherits from
+the \term{evaluation environment},
+and the \term{compilation environment} and \term{evaluation environment} 
+might be \term{identical}.
+The \term{evaluation environment} inherits from
+the \term{startup environment}, 
+and the \term{startup environment} and \term{evaluation environment} 
+might be \term{identical}.
+
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{compile time} refers to the duration of time that
+the compiler is processing \term{source code}.
+At \term{compile time},
+only the \term{compilation environment} 
+and  the \term{evaluation environment}
+are available.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{compile-time definition} refers to a definition in
+the \term{compilation environment}.
+For example, when compiling a file, 
+the definition of a function might be retained in the \term{compilation environment} 
+if it is declared \declref{inline}. 
+This definition might not be available in the \term{evaluation environment}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{run time} refers to the duration of time that the
+loader is loading compiled code or compiled code is being executed.
+%% The following info is not in the glossary. -kmp 27-Jul-93
+At run time, only the \term{run-time environment} is available.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{run-time definition} refers to a definition in the
+\term{run-time environment}.
+
+%% Checked to be consistent with glossary. -kmp 27-Jul-93
+The term \newterm{run-time compiler} refers to \thefunction{compile}
+or \term{implicit compilation}, for which the compilation and run-time 
+\term{environments} are maintained in the same \term{Lisp image}.
+%% The following info is not in the glossary. -kmp 27-Jul-93
+Note that when the \term{run-time compiler} is used,
+the \term{run-time environment} 
+and \term{startup environment} 
+are the same.
+
+\endsubSection%{Compiler Terminology}
+ 
+\beginsubSection{Compilation Semantics}
+\DefineSection{CompilationSemantics}
+ 
+Conceptually, compilation is a process that traverses code, performs
+certain kinds of syntactic and semantic analyses using information
+(such as proclamations and \term{macro} definitions) present in the
+\term{compilation environment}, and produces equivalent, possibly
+more efficient code.
+
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+
+\beginsubsubsection{Compiler Macros}
+\DefineSection{CompilerMacros}
+
+A \term{compiler macro} can be defined for a \term{name}
+that also names a \term{function} or \term{macro}.
+%Given that we have to allow macros, it's too bad we can't just 
+%say "any operator" in the previous. Why exclude special forms? -Barrett 13-Oct-91
+% Changed symbol => function name below; --sjl 3 Mar 92
+That is, it is possible for a
+\term{function name} to name both a \term{function} and a \term{compiler macro}.
+
+A \term{function name} names a \term{compiler macro} if \funref{compiler-macro-function}
+is \term{true} of the \term{function name} in the \term{lexical environment} in which
+it appears.  Creating a \term{lexical binding} for the \term{function name}
+not only creates a new local \term{function} or
+\term{macro} definition, but also \term{shadows}\meaning{2} the \term{compiler macro}.
+
+The \term{function} returned by \funref{compiler-macro-function}
+is a \term{function} of two arguments, called the
+expansion function.  To expand a \term{compiler macro},
+the expansion function is invoked by calling the \term{macroexpand hook} with
+      the expansion function as its first argument,
+      the entire compiler macro \term{form} as its second argument,
+  and the current compilation \term{environment} 
+       (or with the current lexical \term{environment},
+ 	 if the \term{form} is being processed by something
+	 other than \funref{compile-file}) 
+       as its third argument.
+The \term{macroexpand hook}, in turn, calls the expansion function with the
+\term{form} as its first argument and the \term{environment} as its second argument.
+The return value from the expansion function, which is passed through
+by the \term{macroexpand hook}, might either be the \term{same} \term{form}, 
+or else a form that can, at the discretion of the \term{code} doing the expansion, 
+be used in place of the original \term{form}.
+
+\displaythree{Defined names applicable to compiler macros}{
+*macroexpand-hook*&compiler-macro-function&define-compiler-macro\cr
+}
+
+\beginsubsubsubsection{Purpose of Compiler Macros}
+
+The purpose of the \term{compiler macro} facility is to permit 
+selective source code transformations as optimization advice 
+to the \term{compiler}.  When a \term{compound form} is being
+processed (as by the compiler), if the \term{operator} names a
+\term{compiler macro} then the \term{compiler macro function} may be
+invoked on the form, and the resulting expansion recursively processed
+in preference to performing the usual processing on the original \term{form}
+according to its normal interpretation as a \term{function form} or
+\term{macro form}.
+ 
+A \term{compiler macro function}, like a \term{macro function},
+is a \term{function} of two \term{arguments}: the entire call \term{form}
+and the \term{environment}. Unlike an ordinary \term{macro function}, a 
+\term{compiler macro function} can decline to provide an expansion merely by
+returning a value that is the \term{same} as the original \term{form}.
+The consequences are undefined if a \term{compiler macro function}
+destructively modifies any part of its \term{form} argument.
+ 
+The \term{form} passed to the compiler macro function can either be a \term{list}
+whose \term{car} is the function name, or a \term{list} whose \term{car} is
+\funref{funcall} and whose \term{cadr} is a list \f{(function \param{name})};
+note that this affects destructuring of the form argument by the 
+\term{compiler macro function}.
+\macref{define-compiler-macro} arranges for destructuring of arguments to be
+performed correctly for both possible formats.
+
+% Already explained in more detail in the previous section. -- sjl 3 Mar 92
+% When a \term{compiler macro function} is called as part of processing by the
+% evaluator or compiler, it is invoked by calling the \term{macroexpand hook}.
+
+When \funref{compile-file} chooses to expand a \term{top level form} that is
+a \term{compiler macro} \term{form}, the expansion is also treated as a \term{top level form}
+for the purposes of \specref{eval-when} processing; \seesection\TopLevelForms.
+%% Superfluous. -kmp
+%(just as would happen for the expansion of a \term{macro form}).
+
+\endsubsubsubsection%{Purpose of Compiler Macros}
+
+\beginsubsubsubsection{Naming of Compiler Macros}
+ 
+\term{Compiler macros} may be defined for \term{function names} that name
+\term{macros} as well as \term{functions}.  
+%!!! Isn't this said elsewhere? Does it need to be repeated here? -kmp 1-Jun-91
+% Yes, it's in the packages chapter.  --sjl 5 Mar 92
+% (It is not permitted to define
+% a \term{compiler macro} for a \term{name} that is an \term{external symbol} of 
+% \thepackage{common-lisp}.)
+
+\term{Compiler macro} definitions are strictly global.  There is no provision
+for defining local \term{compiler macros} in the way that \specref{macrolet}
+defines local \term{macros}.  Lexical bindings of a function name shadow any
+compiler macro definition associated with the name as well as its 
+global \term{function} or \term{macro} definition.
+ 
+Note that the presence of a compiler macro definition does not affect
+the values returned by
+\issue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+%by \macref{function-information}, or other accessors [sic]
+\endissue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+functions that access \term{function} definitions (\eg \funref{fboundp})
+or \term{macro} definitions (\eg \funref{macroexpand}).
+Compiler macros are global, and the function
+\funref{compiler-macro-function} is sufficient to resolve their interaction
+with other lexical and global definitions.
+
+\endsubsubsubsection%{Naming of Compiler Macros}
+
+\beginsubsubsubsection{When Compiler Macros Are Used}
+
+The presence of a \term{compiler macro} definition for a \term{function} or \term{macro}
+indicates that it is desirable for the \term{compiler} to use the expansion
+of the \term{compiler macro} instead of the original \term{function form} or
+\term{macro form}.  However, no language processor
+(compiler, evaluator, or other code walker) is ever required to actually
+invoke \term{compiler macro functions}, or to 
+make use of the resulting expansion if it does invoke 
+a \term{compiler macro function}.
+
+When the \term{compiler} encounters a \term{form} during processing that represents
+a call to a \term{compiler macro} \term{name} (that is not declared \declref{notinline}),
+the \term{compiler} might expand the \term{compiler macro}, 
+and might use the expansion in place of the original \term{form}.
+
+When \funref{eval} encounters a \term{form} during processing that represents 
+a call to a \term{compiler macro} \term{name} (that is not declared \declref{notinline}),
+\funref{eval} might expand the \term{compiler macro},
+and might use the expansion in place of the original \term{form}.
+
+There are two situations in which a \term{compiler macro} definition must not be
+applied by any language processor:
+
+\beginlist
+\itemitem{\bull}
+ The global function name binding associated with the compiler
+ macro is shadowed by a lexical binding of the function name.
+
+\itemitem{\bull}
+ The function name has been declared or proclaimed \declref{notinline} and
+ the call form appears within the scope of the declaration.
+\endlist
+
+It is unspecified whether \term{compiler macros} are expanded or used in any other
+situations.
+
+\beginsubsubsubsubsection{Notes about the Implementation of Compiler Macros}
+
+Although it is technically permissible, as described above,
+for \funref{eval} to treat \term{compiler macros} in the same situations
+as \term{compiler} might, this is not necessarily a good idea in
+\term{interpreted implementations}.
+
+\term{Compiler macros} exist for the purpose of trading compile-time speed
+for run-time speed.  Programmers who write \term{compiler macros} tend to
+assume that the \term{compiler macros} can take more time than normal \term{functions}
+and \term{macros} in order to produce code which is especially optimal for use
+at run time.  Since \funref{eval} in an \term{interpreted implementation}
+might perform semantic analysis of the same form multiple times, it might be 
+inefficient in general for the \term{implementation} to choose to call
+\term{compiler macros} on every such \term{evaluation}.
+
+Nevertheless, the decision about what to do in these situations is left to
+each \term{implementation}.
+
+\endsubsubsubsubsection%{Notes about the Implementation of Compiler Macros}
+
+\endsubsubsubsection%{When Compiler Macros Are Used}
+
+\endsubsubsection%{Compiler Macros}
+
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+
+\beginsubsubsection{Minimal Compilation}
+\DefineSection{MinimalCompilation}
+
+% Fixed major problems in this section.
+% See proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN, item (1).
+% -- sjl 3 Mar 92
+
+\term{Minimal compilation} is defined as follows:
+
+\beginlist 
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+%!!! This looks questionable. -kmp 11-Mar-91
+% This item is definitely wrong.  I commented it out.  -- sjl 3 Mar 92
+% \issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+%  \itemitem{\bull} All \term{compiler macro} calls appearing in the
+% source code being compiled are expanded at compile time in such a way
+% that they will not be expanded again at run time. 
+% \endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+%% Reinstated per X3J13 vote, with some clarifications. -kmp 7-Apr-92
+\itemitem{\bull} All \term{compiler macro}\idxterm{compiler macro} calls appearing in the
+\term{source code} being compiled are expanded, if at all, at compile time;
+they will not be expanded at run time.
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+% I made some minor wording changes to this paragraph.  -- sjl 3 Mar 92
+ \itemitem{\bull} All \term{macro}\idxterm{macro} and 
+\term{symbol macro}\idxterm{symbol macro} calls
+appearing in the source code being compiled are expanded at compile time
+in such a way that they will not be expanded again at run time.
+\specref{macrolet}\idxref{macrolet}
+and
+\specref{symbol-macrolet}\idxref{symbol-macrolet}
+are effectively replaced by
+\term{forms} corresponding to their bodies in which calls to 
+\term{macros} are replaced by their expansions.
+ 
+% I made some minor wording changes to this paragraph.  -- sjl 3 Mar 92
+\itemitem{\bull} 
+The first \term{argument} in a \specref{load-time-value}\idxref{load-time-value}
+\term{form} 
+in \term{source code} processed by \funref{compile}\idxref{compile}
+is \term{evaluated} at \term{compile time};
+in \term{source code} processed by \funref{compile-file}\idxref{compile-file}, 
+the compiler arranges for it to be \term{evaluated} at \term{load time}.
+In either case, the result of the \term{evaluation}
+is remembered and used later as the value of the 
+\specref{load-time-value} \term{form} at \term{execution time}.
+
+% I think the previous paragraph was supposed to replace this one, not
+% augment it.  It adds nothing but confusion.  -- sjl 3 Mar 92
+% \specref{load-time-value} forms in the source code will be evaluated
+% at compile time when compiled by \funref{compile} or at load time
+% when compiled by \funref{compile-file}, and the result of
+% evaluation will be used as a constant at run time.
+\endlist
+ 
+\endsubsubsection%{Minimal Compilation}
+
+\beginsubsubsection{Semantic Constraints}
+\DefineSection{SemanticConstraints}
+
+%% Removed per Dalton #1 (first public review). -kmp 10-May-93
+% % Fixed some garbled language in this section.
+% % See proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY.
+% % -- sjl 3 Mar 92
+% 
+% Conforming code must be structured so that its results and observable
+% side effects are the same whether or not compilation takes place.
+%
+% Additional constraints about the consistency of the compilation and
+% run-time \term{environments} imply additional semantic constraints on
+% conforming programs.  Conforming programs obeying these constraints
+% have the same behavior whether evaluated or compiled.
+% 
+% The following are the semantic constraints:
+%% and replaced with:
+
+All \term{conforming programs} must obey the following constraints,
+which are designed to minimize the observable differences 
+between compiled and interpreted programs:
+
+\beginlist
+% This entire item seems to have gotten totally garbled.  See replacement
+% text below.  -- sjl 3 Mar 92
+%  \itemitem{\bull} Any \term{form} that is a \term{list}
+% beginning with a \term{symbol} that does not name a 
+% \term{special form}, 
+% %%This is questionable. -kmp 11-Mar-91
+% %%Moon and Barrett thought so, too. Removed. -kmp 13-Oct-91
+% % \issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+% % a \term{compiler macro},
+% % \endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+% or a \term{macro}
+% defined in the compilation environment is a function call.
+% \issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+% (This implies that \term{setf expanders} must be available at compile time.)
+% \endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS} 
+ \itemitem{\bull} Definitions of any referenced \term{macros}
+must be present in the \term{compilation environment}.  
+Any \term{form} that is a \term{list}
+beginning with a \term{symbol} that does not name a
+\term{special operator} or a \term{macro} defined in the 
+\term{compilation environment} is treated by the compiler as a 
+function call.
+
+% This garbled item also replaced.  -- sjl 3 Mar 92
+%  \itemitem{\bull} Any binding of a \term{variable} not declared
+% \declref{special} is a lexical binding.
+ \itemitem{\bull} \declref{Special} proclamations for \term{dynamic variables}
+must be made in the \term{compilation environment}.  Any \term{binding}
+for which there is no \declref{special} declaration or proclamation in
+the \term{compilation environment} is treated by the compiler as
+a \term{lexical binding}.
+
+
+% Minor rewording.  -- sjl 3 Mar 92.
+ \itemitem{\bull} The definition of a function that is defined and
+declared \declref{inline} in the \term{compilation environment} must be
+the same at run time.
+ 
+%% Barrett didn't like this.  The paragraph that follows is a negotiated rewrite to clarify.
+%% -kmp 13-Oct-91
+%  \itemitem{\bull} Within a named function $F$, a recursive call to $F$
+% refers to $F$, unless that function has been declared \declref{notinline}.
+  
+ \itemitem{\bull} Within a \term{function} named $F$, the compiler may
+(but is not required to)
+assume that an apparent recursive call to a \term{function} named $F$ 
+refers to the same definition of $F$,
+unless that function has been declared \declref{notinline}.
+The consequences of redefining such a recursively defined \term{function} $F$ 
+while it is executing are undefined.
+
+ \itemitem{\bull} A call within a file to a named function that is
+defined in the same file refers to that function, unless that function
+has been declared \declref{notinline}.  The consequences are unspecified
+if functions are redefined individually at run time or multiply
+defined in the same file.
+
+% I believe this item has been made unnecessary by issue
+% LISP-SYMBOL-REDEFINITION.  -- sjl 3 Mar 92
+% \itemitem{\bull} A call to a built-in Common Lisp function refers to
+%that function.  Any built-in \clisp\ function might be proclaimed \declref{inline}.
+  
+ \itemitem{\bull} The argument syntax and number of return values for
+all functions whose \declref{ftype} is declared at compile time must
+remain the same at run time.
+ 
+% Reference:  CLtL page 69
+%"same" => "similar" per Moon
+ \itemitem{\bull} \term{Constant variables} defined in
+the \term{compilation environment} must have a \term{similar} value at
+run time.  A reference to 
+%the name of a constant
+a \term{constant variable} 
+in \term{source code} is equivalent to a reference to 
+%an \term{object} \funref{eql} to
+a \term{literal} \term{object} that is the \term{value} of the \term{constant variable}.
+ 
+% The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
+%    seems likely to change:
+% No, we later voted down the proposal to change it. -- sjl 3 Mar 92
+ \itemitem{\bull} Type definitions made with \macref{deftype} or
+\macref{defstruct} in the \term{compilation environment} must
+retain the same definition at run time.  Classes defined by \macref{defclass}
+in the \term{compilation environment} must be defined
+at run time to have the same \term{superclasses} and same 
+\term{metaclass}.
+
+This implies that \term{subtype}/\term{supertype} relationships of 
+\term{type specifiers} must not change between \term{compile time} and \term{run time}.  
+ 
+% Ref:  CLtL page 153
+ \itemitem{\bull} Type declarations present in the compilation 
+\term{environment} must accurately describe the corresponding values at run time;
+otherwise, the consequences are undefined.  It is permissible
+for an unknown \term{type} to appear in a declaration at 
+compile time, though a warning might be signaled in such a case.
+
+ \itemitem{\bull} Except in the situations explicitly listed above, a
+\term{function} defined in the \term{evaluation environment}
+is permitted to have a different definition or a different \term{signature}
+at run time, and the run-time definition prevails.
+
+\endlist 
+
+\term{Conforming programs} should not be written using any additional
+assumptions about consistency between the run-time 
+\term{environment} and the startup, evaluation, and compilation 
+\term{environments}.
+
+Except where noted, when a compile-time and a run-time definition are
+different, one of the following occurs at run time:
+
+\beginlist
+                                                          
+\item{\bull} an error \oftype{error} is signaled
+\item{\bull} the compile-time definition prevails
+\item{\bull} the run-time definition prevails
+
+\endlist
+ 
+If the \term{compiler} processes a \term{function form} whose \term{operator} 
+is not defined at compile time, no error is signaled at compile time.
+
+\endsubsubsection%{Semantic Constraints}
+\endsubSection%{Compilation Semantics}
+\beginsubSection{File Compilation}
+\DefineSection{FileCompilation}
+ 
+\Thefunction{compile-file} performs compilation of 
+\term{forms} in a file following the rules specified in \secref\CompilationSemantics,
+and produces an output file that can be loaded by using \funref{load}.
+ 
+Normally, the \term{top level forms} appearing in a file compiled with
+\funref{compile-file} are evaluated only when the resulting
+compiled file is loaded, and not when the file is compiled.  However,
+% the use of ``must'' is problematic here  --sjl 7 Mar 92
+%some forms in the file must be evaluated at compile time so the
+it is typically the case that some forms in the file need to be evaluated
+at compile time so the
+remainder of the file can be read and compiled correctly.
+
+\Thespecform{eval-when} can be used to control
+whether a \term{top level form} is evaluated at compile time, load
+time, or both.  It is possible to specify any of three situations with
+\specref{eval-when}, denoted by the symbols \kwd{compile-toplevel},
+\kwd{load-toplevel}, and \kwd{execute}.  For top level 
+\specref{eval-when} forms, \kwd{compile-toplevel} specifies that the
+compiler must evaluate the body at compile time, and {\tt
+:load-toplevel} specifies that the compiler must arrange to evaluate
+the body at load time. For non-top level \specref{eval-when} forms,
+\kwd{execute} specifies that the body must be executed in the run-time
+\term{environment}.
+
+The behavior of this \term{form} can be more precisely understood in
+terms of a model of how \funref{compile-file} processes forms in
+a file to be compiled. There are two processing modes, called
+``not-compile-time'' and ``compile-time-too''.
+ 
+Successive forms are read from the file by \funref{compile-file}
+and processed in not-compile-time mode; in this mode, 
+\funref{compile-file} arranges for forms to be evaluated only at load time
+and not at compile time.  When \funref{compile-file} is in
+compile-time-too mode, forms are evaluated both at compile time and
+load time.
+
+\beginsubsubsection{Processing of Top Level Forms}
+\DefineSection{TopLevelForms}
+
+Processing of \term{top level forms} in the file compiler is defined
+as follows:
+
+\beginlist
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+ \itemitem{1.} If the \term{form} is a \term{compiler macro form}
+(not disabled by a \declref{notinline} \term{declaration}),
+% Not clear what ``expand'' means here.  --sjl 7 Mar 92
+%the \term{implementation} might or might not choose to expand the \term{form} and,
+the \term{implementation} might or might not choose to compute
+the \term{compiler macro expansion} of the \term{form} and,
+having performed the expansion, might or might not choose to process the result
+as a \term{top level form} in the same processing mode
+(compile-time-too or not-compile-time).
+%% Added for Moon. -kmp 16-Feb-92
+If it declines to obtain or use the expansion, it must process the original \term{form}.
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+ 
+ \itemitem{2.} If the form is a \term{macro form},
+%% Probably better to do without this. -kmp,kab 13-Oct-91
+% \issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+% (and was not processed as a \term{compiler macro}),
+% \endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+% Not clear what ``expand'' means here.  --sjl 7 Mar 92
+%it is expanded and the result is processed as a \term{top level form} in
+its \term{macro expansion} is computed and processed as a 
+\term{top level form} in
+the same processing mode (compile-time-too or not-compile-time).
+ 
+ \itemitem{3.} If the form is a \specref{progn} form, each of its
+body \term{forms} is sequentially processed as a 
+\term{top level form} in the same processing mode.
+ 
+ \itemitem{4.} If the form is a \specref{locally}, 
+\specref{macrolet}, or \specref{symbol-macrolet}, 
+\funref{compile-file} establishes the appropriate bindings and processes the
+body forms as \term{top level forms} with those bindings in effect
+in the same processing mode.  (Note that this implies that the lexical
+\term{environment} in which \term{top level forms} are processed
+is not necessarily the \term{null lexical environment}.)
+ 
+ \itemitem{5.} If the form is an \specref{eval-when}\idxref{eval-when} form, it is
+handled according to \thenextfigure.
+
+\boxfig
+{\dimen0=.75pc
+\tabskip \dimen0 plus .5 fil
+\offinterlineskip
+\halign to \hsize {\strut#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip 
+\dimen0 plus .5 fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus 1fil
+&#\hfil&#\hfil&#\hfil\cr 
+\noalign{\vskip -11pt}
+\hfil\b{CT} &\hfil\b{LT} &\hfil\b{E} &\hfil\b{Mode}&\hfil\b{Action}&\hfil\b{New Mode}\cr
+\noalign{\hrule}
+Yes&Yes&\hfil---&\hfil---&Process&compile-time-too\cr
+No&Yes&Yes&\hfil CTT&Process&compile-time-too\cr
+No&Yes&Yes&\hfil NCT&Process&not-compile-time\cr
+No&Yes&No&\hfil---&Process&not-compile-time\cr
+Yes&No&\hfil---&\hfil---&Evaluate&\hfil---\cr
+No&No&Yes&\hfil CTT&Evaluate&\hfil---\cr
+No&No&Yes&\hfil NCT&Discard&\hfil---\cr
+No&No&No&\hfil---&Discard&\hfil---\cr
+\noalign{\vskip -9pt}
+}}
+\caption{EVAL-WHEN processing}
+\endfig
+
+Column \b{CT}   indicates whether \kwd{compile-toplevel} is specified.
+Column \b{LT}   indicates whether \kwd{load-toplevel} is specified.
+Column \b{E}    indicates whether \kwd{execute} is specified.  
+Column \b{Mode} indicates the processing mode; 
+		a dash (---) indicates that the processing mode is not relevant.
+   
+The \b{Action} column specifies one of three actions:
+
+\beginlist
+
+ \item{}\b{Process:} process the body as \term{top level forms} in the
+specified mode.
+ 
+ \item{}\b{Evaluate:} evaluate the body in the dynamic execution
+context of the compiler, using the \term{evaluation environment} as
+the global environment and the \term{lexical environment} in which
+the \specref{eval-when} appears.
+ 
+\item{}\b{Discard:} ignore the \term{form}.
+\endlist
+
+The \b{New Mode} column indicates the new processing mode. 
+A dash (---) indicates the compiler remains in its current mode.
+
+ \itemitem{6.} Otherwise, the form is a \term{top level form} that
+is not one of the special cases.  In compile-time-too mode, the
+compiler first evaluates the form in the evaluation 
+\term{environment} and then minimally compiles it.  In not-compile-time
+mode, the \term{form} is simply minimally compiled.  All \term{subforms}
+are treated as \term{non-top-level forms}.
+
+Note that \term{top level forms} are processed in the order in
+which they textually appear in the file and that each 
+\term{top level form} read by the compiler is processed before the next is
+read.  However, the order of processing (including macro expansion) of
+\term{subforms} that are not \term{top level forms} and the order of
+further compilation is unspecified as long as Common Lisp semantics
+are preserved.
+
+\endlist 
+ 
+\specref{eval-when} forms cause compile-time evaluation only at
+top level.  Both \kwd{compile-toplevel} and \kwd{load-toplevel} situation specifications
+are ignored for \term{non-top-level forms}. For \term{non-top-level forms}, 
+an \specref{eval-when}
+specifying the \kwd{execute} situation is treated as an \term{implicit progn}
+including the \term{forms} in the body of the \specref{eval-when} \term{form};
+otherwise, the \term{forms} in the body are ignored.
+
+\beginsubsubsubsection{Processing of Defining Macros}
+\DefineSection{DefiningMacros}
+
+% The material below was in its own section (3.2.6), but I think it
+% logically belongs here.  --sjl 3 Mar 92
+
+\issue{COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY}
+
+Defining \term{macros} (such as \macref{defmacro} or \macref{defvar})
+appearing within a file being processed by \funref{compile-file}
+normally have compile-time side effects which affect how subsequent \term{forms}
+in the same \term{file} are compiled.  A convenient model for explaining how these
+side effects happen is that the defining macro expands into one or
+more \specref{eval-when} \term{forms}, and that the calls which cause the compile-time
+side effects to happen appear 
+in the body of an \f{(eval-when (:compile-toplevel) ...)} \term{form}.
+
+%RPG: What does this mean and is it worth saying?
+%Sandra: I think it's fairly important for this information to remain,
+%  since it's what licenses implementations to use what we've been calling 
+%  "remote environments" to keep track of compile-time definitions.
+%KAB: I agree.
+The compile-time side effects may cause information about the definition to
+be stored differently than if the defining macro had been processed in the
+`normal' way (either interpretively or by loading the compiled file).
+
+In particular, the information stored by the defining \term{macros} at compile time
+might or might not be available to the interpreter (either during or after compilation),
+or during subsequent calls to the \term{compiler}.  For example,
+the following code is nonportable because it assumes that the \term{compiler}
+stores the macro definition of \f{foo} where it is available to the interpreter:
+    
+\code
+ (defmacro foo (x) `(car ,x))
+ (eval-when (:execute :compile-toplevel :load-toplevel)
+   (print (foo '(a b c))))
+\endcode
+    
+A portable way to do the same thing would be to include the macro
+definition inside the \specref{eval-when} \term{form}, as in:
+    
+\code
+ (eval-when (:execute :compile-toplevel :load-toplevel)
+   (defmacro foo (x) `(car ,x))
+   (print (foo '(a b c))))
+\endcode
+
+\endissue{COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY}
+
+% end of moved material.
+
+\Thenextfigure\ lists macros that make definitions
+available both in the compilation and run-time \term{environments}.
+It is not specified whether definitions made available in the
+\term{compilation environment} are available in the evaluation
+\term{environment}, nor is it specified whether they are available
+in subsequent compilation units or subsequent invocations of the
+compiler.  As with \specref{eval-when}, these compile-time side
+effects happen only when the defining macros appear at 
+top level.
+ 
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\issue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+\issue{CLOS-MACRO-COMPILATION:MINIMAL}
+% Removed DEFGENERIC, DEFINE-METHOD-COMBINATION, and DEFMETHOD for KAB.
+% He says they "might" but don't have to. -kmp 8-Feb-92
+\displaythree{Defining Macros That Affect the Compile-Time Environment}{
+declaim&define-modify-macro&defsetf\cr
+defclass&define-setf-expander&defstruct\cr
+defconstant&defmacro&deftype\cr
+define-compiler-macro&defpackage&defvar\cr
+define-condition&defparameter&\cr
+}
+
+\endissue{CLOS-MACRO-COMPILATION:MINIMAL}
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+\endissue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+
+\endsubsubsubsection%{Processing of Defining Macros}
+
+\beginsubsubsubsection{Constraints on Macros and Compiler Macros}
+\DefineSection{ConstraintsOnMacros}
+
+% Fixed major omission -- issue MACRO-SUBFORMS-TOP-LEVEL-P had not
+% been incorporated into the document yet.   --sjl 3 Mar 92
+\issue{MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS}
+
+Except where explicitly stated otherwise, no \term{macro} defined in
+the \clisp\ standard produces an expansion that could cause any of the
+\term{subforms} of the \term{macro form} to be treated as 
+\term{top level forms}.  If an \term{implementation} also provides a
+\term{special operator} definition of a \clisp\ \term{macro}, 
+the \term{special operator} definition must be semantically equivalent
+in this respect.
+
+\term{Compiler macro} expansions must also have the same
+top level evaluation semantics as the \term{form} which they replace.
+This is of concern both to \term{conforming implementations} and to
+\term{conforming programs}.
+
+\endissue{MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS}
+\endsubsubsubsection%{Constraints on Macros and Compiler Macros}
+
+\endsubsubsection%{Processing of Top Level Forms}
+
+\endsubSection%{File Compilation}
+
+%% Moon thought this section was stupid and wanted it moved into next section.
+% \beginsubSection{Compiler/Loader Interface}
+% % Reference: Issue QUOTE-SEMANTICS
+%  
+%  
+% \endsubSection%{Compiler/Loader Interface}
+
+\beginsubSection{Literal Objects in Compiled Files}
+\DefineSection{LiteralsInCompiledFiles}
+
+% Reference: Issue QUOTE-SEMANTICS
+
+%"constants" => "literal objects" per Moon #4(first public review) --kmp 5-May-93
+
+The functions \funref{eval} and \funref{compile} are
+required to ensure that \term{literal objects} referenced within the resulting
+interpreted or compiled code objects are the \term{same} as the
+corresponding \term{objects} in the \term{source code}.
+\funref{compile-file}, on the other hand, 
+must produce a \term{compiled file} that, when loaded with
+\funref{load}, constructs the \term{objects} defined by the
+\term{source code} and produces references to them.
+ 
+In the case of \funref{compile-file}, \term{objects}
+constructed by \funref{load} of the \term{compiled file} cannot be spoken
+of as being the \term{same} as the \term{objects} constructed at
+compile time, because the \term{compiled file} may be loaded into a different
+\term{Lisp image} than the one in which it was compiled.  This section
+defines the concept of \term{similarity} which relates
+\term{objects} in the \term{evaluation environment} to the
+corresponding \term{objects} in the \term{run-time environment}.
+ 
+The constraints on \term{literal objects} described in this section
+apply only to \funref{compile-file};
+\funref{eval} and \funref{compile} do not copy or coalesce constants.
+
+\beginsubsubsection{Externalizable Objects}
+\DefineSection{ExternalizableObjects}
+
+\issue{CONSTANT-COMPILABLE-TYPES:SPECIFY}
+The fact that the \term{file compiler} represents \term{literal} \term{objects} 
+externally in a \term{compiled file} and must later reconstruct suitable 
+equivalents of those \term{objects} when that \term{file} is loaded
+imposes a need for constraints on the nature of the \term{objects} that can be 
+used as \term{literal} \term{objects} in \term{code} to be processed 
+by the \term{file compiler}.
+
+An \term{object} that can be used as a \term{literal} \term{object} 
+in \term{code} to be processed by the \term{file compiler} is called an
+\newterm{externalizable object}.
+
+We define that two \term{objects} are \newterm{similar} if they satisfy
+a two-place conceptual equivalence predicate (defined below), which is
+independent of the \term{Lisp image} so that the two \term{objects} in
+different \term{Lisp images} can be understood to be equivalent under
+this predicate.  Further, by inspecting the definition of this conceptual
+predicate, the programmer can anticipate what aspects of an \term{object}
+are reliably preserved by \term{file compilation}.
+
+The \term{file compiler} must cooperate with the \term{loader} in order to
+assure that in each case where an \term{externalizable object} is processed
+as a \term{literal object}, the \term{loader} will construct a \term{similar}
+\term{object}.
+
+The set of \term{objects} that are \newtermidx{externalizable objects}{externalizable object} are those
+for which the new conceptual term ``\term{similar}'' is defined, such that
+when a \term{compiled file} is \term{loaded}, an \term{object} can be constructed
+which can be shown to be \term{similar} to the original \term{object} which
+existed at the time the \term{file compiler} was operating.
+\endissue{CONSTANT-COMPILABLE-TYPES:SPECIFY}
+
+\endsubsubsection%{Externalizable Objects}
+
+\beginsubsubsection{Similarity of Literal Objects}
+\DefineSection{Similarity}
+
+\beginsubsubsubsection{Similarity of Aggregate Objects}
+%Moon thinks this section is unnecessary.
+
+Of the \term{types} over which \term{similarity} is defined, 
+some are treated as aggregate objects.  For these types, 
+\term{similarity} is defined recursively.  
+We say that an \term{object} of these types has certain ``basic qualities''
+and to satisfy the \term{similarity} relationship, the values of the
+corresponding qualities of the two \term{objects} must also be similar.
+ 
+\endsubsubsubsection%{Similarity of Aggregate Objects}
+
+% What was left of this section made no sense at all, so I removed
+% the whole thing.  --sjl 3 Mar 92
+% \beginsubsubsubsection{Similarity of Circular Objects}
+% %Moon: I think this section is BS and should be deleted, but RPG might disagree.
+% 
+% %!!! This discussion needs to be reworked since we're not doing "depth-limited gunk" anymore.
+% This kind of definition has problems with any circular or ``infinitely
+% recursive'' object such as a list that is an element of itself.  
+% %% !!!! RPG thinks we should flush this part.  But that leaves the previous sentence
+% %% in a precarious situation.  I see no reason really why circular objects are
+% %% a problem.  Can't we just use the same tricks that make printing circular objects work?
+% %% And if that's right, how do I express it??
+% %% -kmp 26-Jan-92
+% % We use
+% % the idea of depth-limited comparison, and say that two objects are
+% % \term{similar} if they are \term{similar} at all finite levels.  This
+% % idea is implicit in the definitions below, and applies in all the
+% % places where qualities of two \term{objects} are required to be \term{similar}.
+%  
+% \endsubsubsubsection%{Similarity of Circular Objects}
+
+% The following terms are used throughout this proposal:
+% 
+%   The term "constant" [now "literal object" -kmp 8-Oct-91]
+%   refers to a quoted object or self-evaluating object,
+%   not a constant variable.
+% 
+%   The term "source code" is used to refer to the objects constructed
+%   when COMPILE-FILE calls READ, and additional objects constructed by
+%   macroexpansion during COMPILE-FILE.
+% 
+%   The term "compiled code" is used to refer to objects constructed by 
+%   LOAD.
+% 
+
+\beginsubsubsubsection{Definition of Similarity}
+
+Two \term{objects} $S$ (in \term{source code}) and $C$ (in \term{compiled code})
+     are defined to be \term{similar} if and only if 
+     they are both of one of the \term{types} listed here
+      (or defined by the \term{implementation}) 
+ and they both satisfy all additional requirements of \term{similarity} 
+      indicated for that \term{type}.
+
+\beginlist
+
+\itemitem{\typeref{number}}
+ 
+Two \term{numbers} $S$ and $C$ are \term{similar} if they are of the same \term{type}
+and represent the same mathematical value.
+
+\itemitem{\typeref{character}}
+ 
+% Two \term{characters} $S$ and $C$ are \term{similar} if they both 
+% represent the same \term{character}.
+%% Tentatively replaced. Mail sent to Quinquevirate to confirm. -kmp 29-Jan-92
+%% Lots of mail ensued ("Similarity of characters"), but this looks like it'll do for now.
+%% We should maybe return to it later in Public Review when there's more time. -kmp 4-Feb-92
+
+Two \term{simple} \term{characters} $S$ and $C$ are \term{similar} 
+if they have \term{similar} \term{code} \term{attributes}.
+
+\term{Implementations} providing additional, \term{implementation-defined} 
+\term{attributes} must define whether and how \term{non-simple} \term{characters} 
+can be regarded as \term{similar}.
+
+\itemitem{\typeref{symbol}}
+
+Two \term{apparently uninterned} \term{symbols} $S$ and $C$ are \term{similar}
+if their
+%% Per Moon#6 (first public review). -kmp 5-May-93
+%\term{print names}
+\term{names}
+are \term{similar}.
+
+\issue{COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY}
+Two \term{interned} symbols $S$ and $C$ are \term{similar} 
+if their \term{names} are \term{similar},
+and if either $S$ is accessible in the \term{current package} at compile time
+          and $C$ is accessible in the \term{current package} at load time,
+       or $C$ is accessible in the \term{package} that is \term{similar} to
+          the \term{home package} of $S$.
+
+(Note that \term{similarity} of
+%% Per Moon#6 (first public review). -kmp 5-May-93
+%\term{interned}
+\term{symbols} is dependent
+on neither the \term{current readtable} nor how \thefunction{read} would
+parse the \term{characters} in the \term{name} of the \term{symbol}.)
+\endissue{COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY}
+
+\itemitem{\typeref{package}}
+
+Two \term{packages} $S$ and $C$ are \term{similar} if their \term{names} are \term{similar}.
+
+Note that although a \term{package} \term{object} is an \term{externalizable object},
+the programmer is responsible for ensuring that the corresponding \term{package} is
+already in existence when code referencing it as a \term{literal} \term{object} 
+is \term{loaded}.  The \term{loader} finds the corresponding \term{package} \term{object}
+as if by calling \funref{find-package} with that \term{name} as an \term{argument}.
+An error is signaled by the \term{loader} if no \term{package} exists at load time.
+
+\itemitem{\typeref{random-state}}
+ 
+Two \term{random states} $S$ and $C$ are \term{similar} if $S$
+would always produce the same sequence of pseudo-random numbers 
+as a \term{copy}\meaning{5} of $C$
+when given as the \param{random-state} \term{argument} to \thefunction{random}, 
+assuming equivalent \param{limit} \term{arguments} in each case.
+
+(Note that since $C$ has been processed by the \term{file compiler},
+it cannot be used directly as an \term{argument} to \funref{random}
+because \funref{random} would perform a side effect.)
+
+\itemitem{\typeref{cons}} 
+
+Two \term{conses}, $S$ and $C$, are \term{similar} if
+    the \term{car}\meaning{2} of $S$ is \term{similar} to the \term{car}\meaning{2} of $C$,
+and the \term{cdr}\meaning{2} of $S$ is \term{similar} to the \term{cdr}\meaning{2} of $C$.
+
+\itemitem{\typeref{array}}
+
+Two one-dimensional \term{arrays}, $S$ and $C$, are \term{similar} if
+     the \term{length} of $S$ is \term{similar} to the \term{length} of $C$,
+     the \term{actual array element type} of $S$ is \term{similar} to
+     the \term{actual array element type} of $C$,
+ and each \term{active} \term{element} of $S$ is \term{similar} to
+      the corresponding \term{element} of $C$.
+
+Two \term{arrays} of \term{rank} other than one, $S$ and $C$, are \term{similar} if
+     the \term{rank} of $S$ is \term{similar} to the \term{rank} of $C$,
+     each \term{dimension}\meaning{1} of $S$ is \term{similar} to 
+      the corresponding \term{dimension}\meaning{1} of $C$,
+     the \term{actual array element type} of $S$ is \term{similar} to
+     the \term{actual array element type} of $C$,
+ and each \term{element} of $S$ is \term{similar} to
+      the corresponding \term{element} of $C$.
+
+In addition,
+if $S$ is a \term{simple array}, then $C$ must also be a \term{simple array}.
+If $S$ is a \term{displaced array},
+       has a \term{fill pointer},
+    or is \term{actually adjustable}, 
+$C$ is permitted to lack any or all of these qualities.
+
+\itemitem{\typeref{hash-table}}
+
+Two \term{hash tables} $S$ and $C$ are \term{similar} if they meet the following
+three requirements:
+ 
+\beginlist
+\item{1.}  They both have the same test 
+ 	    (\eg they are both \funref{eql} \term{hash tables}).
+ 
+\item{2.}  There is a unique one-to-one correspondence between the keys of
+           the two \term{hash tables}, such that the corresponding keys are 
+	   \term{similar}.
+
+\item{3.}  For all keys, the values associated with two corresponding keys
+           are \term{similar}.
+\endlist
+ 
+If there is more than one possible one-to-one correspondence between
+the keys of $S$ and $C$, the consequences are unspecified.  
+A \term{conforming program} cannot use a table such as $S$ as an
+\term{externalizable constant}.
+ 
+\itemitem{\typeref{pathname}}
+ 
+Two \term{pathnames} $S$ and $C$ are \term{similar} if all corresponding 
+\term{pathname components} are \term{similar}.
+
+\itemitem{\typeref{function}}
+ 
+\issue{CONSTANT-FUNCTION-COMPILATION:NO}
+\term{Functions} are not \term{externalizable objects}.
+\endissue{CONSTANT-FUNCTION-COMPILATION:NO}
+
+\itemitem{\typeref{structure-object} and \typeref{standard-object}}
+
+\issue{LOAD-OBJECTS:MAKE-LOAD-FORM}
+A general-purpose concept of \term{similarity} does not exist for \term{structures}
+and \term{standard objects}.
+However, a \term{conforming program} is permitted to define a \funref{make-load-form}
+\term{method} for any \term{class} $K$ defined by that \term{program} that is
+a \term{subclass} of either \typeref{structure-object} or \typeref{standard-object}.
+The effect of such a \term{method} is to define that an \term{object} $S$ of \term{type} $K$
+in \term{source code} is \term{similar} to an \term{object} $C$ of \term{type} $K$
+in \term{compiled code} if $C$ was constructed from \term{code} produced by 
+calling \funref{make-load-form} on $S$.
+\endissue{LOAD-OBJECTS:MAKE-LOAD-FORM}
+
+\endlist
+
+\endsubsubsection%{Similarity of Literal Objects}
+
+\beginsubsubsection{Extensions to Similarity Rules}
+
+Some \term{objects}, such as \term{streams}, \typeref{readtables}, and \typeref{methods}
+are not \term{externalizable objects} under the definition of similarity given above.
+That is, such \term{objects} may not portably appear as \term{literal} \term{objects} 
+in \term{code} to be processed by the \term{file compiler}. 
+
+An \term{implementation} is permitted to extend the rules of similarity, 
+so that other kinds of \term{objects} are \term{externalizable objects}
+for that \term{implementation}.
+
+If for some kind of \term{object}, \term{similarity} is
+neither defined by this specification 
+	    nor by the \term{implementation}, 
+then the \term{file compiler} must signal an error upon encountering such 
+an \term{object} as a \term{literal constant}.
+
+\endsubsubsection%{Extensions to Similarity Rules}
+  
+\beginsubsubsection{Additional Constraints on Externalizable Objects}
+
+% What was left of this paragraph didn't add anything to what was
+% already stated above, so I removed the whole thing.  --sjl 3 Mar 92
+% %% Moon wanted this removed because it was redundant 
+% %% and also because EQ isn't the only problem.
+% % Note that some \term{hash tables} that use
+% % \funref{eq} as test function may not be similar to themselves.  
+% %% KMP thinks this phrase is both superfluous and clumsy.
+% % One consequence of the restrictions on constants
+% % and the definition of similarity is that 
+% A \term{hash table} 
+% %cannot be used as a constant
+% is not an \term{externalizable object}
+% if it contains two \term{similar} keys
+% %% Moon thinks this is superfluous.
+% %where the values associated with those keys are also similar.
+
+If two \term{literal objects} appearing in the source code for a single file
+processed with
+%\funref{compile-file}
+the \term{file compiler} 
+are the \term{identical},
+the corresponding \term{objects} in the \term{compiled code} 
+must also be the \term{identical}.
+\issue{CONSTANT-COLLAPSING:GENERALIZE}
+% However, if two \term{objects} are \funref{eql} in the
+% compiled code, the corresponding \term{objects} in the source code
+% might not have been \funref{eql}.  
+% \term{Objects} \oftype{array}, \typeref{character}, \typeref{cons}, 
+% \typeref{hash-table}, \typeref{number}, \typeref{pathname}, 
+% \typeref{random-state}, and \typeref{string} may be coalesced
+% if they are similar.
+With the exception of \term{symbols} and \term{packages}, any two
+%constants
+\term{literal objects}
+in \term{code} being processed by
+%\funref{compile-file}
+the \term{file compiler}
+may be \term{coalesced} 
+if and only if they are \term{similar}; 
+if they are either both \term{symbols} or both \term{packages},
+they may only be \term{coalesced} if and only if they are \term{identical}.
+\endissue{CONSTANT-COLLAPSING:GENERALIZE}
+
+\issue{CONSTANT-CIRCULAR-COMPILATION:YES}
+\term{Objects} containing circular references can 
+%legitimately appear as constants to be compiled.
+be \term{externalizable objects}.
+The \term{file compiler} is required to preserve \funref{eql}ness of 
+substructures within a \term{file}.
+%compiled with \funref{compile-file}.
+Preserving \funref{eql}ness means that subobjects that are
+%\funref{eql} 
+the \term{same}
+in the \term{source code} must 
+%remain 
+be
+%\funref{eql}
+the \term{same}
+%after being compiled.
+in the corresponding \term{compiled code}.
+%that is, things don't get "less EQL" after compilation.
+%(Note that coalescing of constants implies that things may get "more
+%EQL".)
+\endissue{CONSTANT-CIRCULAR-COMPILATION:YES}
+
+In addition, the following are constraints on the handling of
+\term{literal objects} by the \term{file compiler}:
+ 
+\beginlist
+
+ \item{}\b{array:} If an \term{array} in the source code is a
+\term{simple array}, then the corresponding \term{array}
+in the compiled code will also be a \term{simple array}.  If
+an \term{array} in the source code is displaced, has a 
+\term{fill pointer}, or is \term{actually adjustable}, the corresponding 
+\term{array} in the compiled code might lack any or all of these
+qualities. If an \term{array} in the source code has a fill
+pointer, then the corresponding \term{array} in the compiled
+code might be only the size implied by the fill pointer.
+
+ \item{}\b{packages:} The loader is required to find the
+corresponding \term{package} \term{object} as if by calling 
+\funref{find-package} with the package name as an argument.  
+An error \oftype{package-error} is signaled if no 
+\term{package} of that name exists at load time.
+
+%!!! Barmar notes that this is not a constraint on the compiler (as list heading suggests)
+ \item{}\b{random-state:} A constant \term{random state}
+object cannot be used as the state argument 
+to \thefunction{random} because \funref{random} modifies this data structure.
+ 
+\item{}\b{structure, standard-object:}
+\term{Objects} of \term{type} \typeref{structure-object} and \typeref{standard-object}
+may appear in compiled constants if there is an
+appropriate \funref{make-load-form} method defined for that
+\term{type}.
+ 
+\issue{LOAD-OBJECTS:MAKE-LOAD-FORM}
+\DefineSection{CallingMakeLoadForm}
+% %\funref{compile-file} 
+% The \term{file compiler}
+% calls \funref{make-load-form} on any \term{object}
+% that is referenced as a \term{literal object}
+% if the \term{object}'s \term{metaclass} is
+%      \typeref{standard-class}, \typeref{structure-class}, 
+% %   any user-defined \term{metaclass} 
+% %    \editornote{KMP: Do we want to talk about user-defined metaclasses?}
+% %    that is not a \term{subclass} of \typeref{built-in-class},
+%   or any of a possibly empty \term{implementation-defined} set
+%       of other \term{metaclasses}.
+% %\funref{compile-file} 
+% The \term{file compiler}
+% will call \funref{make-load-form} 
+% once for any given \term{object} within a single \term{file}.
+% Barrett: Commented out the above, replacing it with appropriately
+%          massaged text from newer issue.
+\issue{MAKE-LOAD-FORM-CONFUSION:REWRITE}
+The \term{file compiler} calls \funref{make-load-form} on any \term{object}
+that is referenced as a \term{literal object} if the \term{object} is a
+\term{generalized instance} of \typeref{standard-object},
+\typeref{structure-object}, \typeref{condition}, or any of a 
+(possibly empty) \term{implementation-dependent} set of other \term{classes}.
+The \term{file compiler} only calls \funref{make-load-form} once for
+any given \term{object} within a single \term{file}.
+\endissue{MAKE-LOAD-FORM-CONFUSION:REWRITE}
+\endissue{LOAD-OBJECTS:MAKE-LOAD-FORM} 
+
+\issue{COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY}
+ \item{}\b{symbol:} In order to guarantee that \term{compiled files} can be \term{loaded}
+  correctly, users must ensure that the \term{packages} referenced in those \term{files}
+  are defined consistently at compile time and load time.  \term{Conforming programs}
+  must satisfy the following requirements:
+  
+\beginlist
+\itemitem{1.} The \term{current package} when a \term{top level form} in the \term{file}
+      is processed by \funref{compile-file} must be the same as the \term{current package}
+      when the \term{code} corresponding to that \term{top level form} in the
+      \term{compiled file} is executed by \funref{load}.  In particular:
+
+\beginlist
+
+\itemitem{a.} Any \term{top level form} in a \term{file} that alters
+	  the \term{current package} must change it to a \term{package}
+	  of the same \term{name} both at compile time and at load time.
+
+\itemitem{b.} If the first \term{non-atomic} \term{top level form} in the \term{file}
+	  is not an \macref{in-package} \term{form}, then the \term{current package}
+	  at the time \funref{load} is called must be a \term{package} with the 
+	  same \term{name} as the package that was the \term{current package}
+	  at the time \funref{compile-file} was called.
+\endlist
+
+\itemitem{2.} For all \term{symbols} 
+      appearing lexically within a \term{top level form} that
+      were \term{accessible} in the \term{package} that was the \term{current package}
+      during processing of that \term{top level form} at compile time, but
+      whose \term{home package} was another \term{package}, at load time there must
+      be a \term{symbol} with the same \term{name} that is \term{accessible} in both the
+      load-time \term{current package} and in the \term{package}
+      with the same \term{name} as the
+      compile-time \term{home package}. 
+  
+\itemitem{3.} For all \term{symbols} represented in the \term{compiled file} 
+      that were \term{external symbols} in
+      their \term{home package} at compile time, there must be a \term{symbol} with the
+      same \term{name} that is an \term{external symbol} in the \term{package} 
+      with the same \term{name} at load time.
+\endlist
+        
+  If any of these conditions do not hold, the \term{package} in which the \term{loader} looks
+  for the affected \term{symbols} is unspecified.  \term{Implementations} are permitted 
+  to signal an error or to define this behavior.
+\endissue{COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY}
+
+\endlist
+
+\endsubsubsection%{Additional Constraints on Externalizable Objects}
+
+\endsubSection%{Literal Objects in Compiled Files}
+
+\beginsubsection{Exceptional Situations in the Compiler}
+\DefineSection{FileCompilerExceptions}
+
+\issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+%% The following text was added by COMPILER-DIAGNOSTICS and then later removed.
+%\funref{compile-file} is required to handle the \misc{abort} restart by
+%aborting the smallest feasible part of the compilation.
+%\funref{compile-file} is allowed to establish a default
+%condition handler.  If such a condition handler is established,
+%however, it must first resignal the \term{condition} to give any
+%user-established handlers a chance to \term{handle} it.  If all user error
+%handlers decline, the default handler \term{handles} the 
+%\term{condition} in an implementation-specific way; for example, it might turn 
+%errors into warnings.
+\endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+
+\issue{COMPILER-WARNING-STREAM}
+\issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+%\funref{compile-file} is permitted to issue warnings through \term{error output}.
+\endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+\endissue{COMPILER-WARNING-STREAM}
+
+% Reference:  Issue COMPILER-DIAGNOSTICS
+% The STYLE-WARNING condition needs to be integrated into the section
+%     describing the hierarchy of condition types.
+
+\funref{compile} and \funref{compile-file} are permitted to
+signal errors and warnings, including errors due to compile-time
+processing of \f{(eval-when (:compile-toplevel) ...)} forms,
+macro expansion, and conditions signaled by the compiler itself.
+                                                
+\term{Conditions} \oftype{error} might be signaled by the compiler
+in situations where the compilation cannot proceed without intervention.  
+ 
+In addition to situations for which the standard specifies that
+\term{conditions} \oftype{warning} must or might be signaled,
+warnings might be signaled in situations where the compiler can
+determine that the consequences are undefined or that a run-time
+error will be signaled.  Examples of this situation are as follows: 
+    violating type declarations,
+    altering or assigning the value of a constant defined with \macref{defconstant},
+    calling built-in Lisp functions with a wrong number of arguments or malformed keyword
+      argument lists, 
+and using unrecognized declaration specifiers.
+ 
+The compiler is permitted to issue warnings about matters of
+programming style as conditions \oftype{style-warning}.
+Examples of this situation are as follows:
+      redefining a function using a different argument list,
+      calling a function with a wrong number of arguments,
+      not declaring \declref{ignore} of a local variable that is not referenced,
+  and referencing a variable declared \declref{ignore}.
+%% KAB didn't think this one was very convincing. KMP was not sure but figured
+%% it wouldn't hurt anything to remove it.
+%   and using \term{declaration specifiers} 
+% 	described in the standard but ignored by the compiler.
+
+Both \funref{compile} and \funref{compile-file} are permitted
+(but not required) to \term{establish} a \term{handler}
+for \term{conditions} \oftype{error}.  For example, they
+might signal a warning, and restart compilation from some
+\term{implementation-dependent} point in order to let the 
+compilation proceed without manual intervention.
+
+Both \funref{compile} and \funref{compile-file} return three
+values, the second two indicating whether the source code being compiled
+contained errors and whether style warnings were issued.
+ 
+% Reference:  issue WITH-COMPILATION-UNIT
+ 
+Some warnings might be deferred until the end of compilation. 
+See \macref{with-compilation-unit}.
+
+% This paragraph is redundant, so I removed it.  --sjl 3 Mar 92
+% \issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+% \funref{compile-file} is permitted, but not required, to establish a \term{handler}
+% for \typeref{error} \term{conditions}.  For example, such a \term{handler} might issue
+% a warning and restart compilation from some \term{implementation-dependent} 
+% point in order to let the compilation proceed without manual intervention.
+% \endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+
+\endsubSection%{Exceptional Situations in the Compiler}
+
+
+% merged section "File Compilation of Top Level Forms" with
+% section "Processing of Defining Macros", above.  --sjl  3 Mar 92

concept-conditions.tex

@@ -0,0 +1,841 @@
+% -*- Mode: TeX -*-
+
+%% Errors
+%% CONDITION-RESTARTS hasn't been included
+
+%!!! What to do with this use of "construct"? -kmp 3-Sep-91
+Common Lisp constructs are described not only in terms of their
+behavior in situations during which they are intended to be used (see
+the ``Description'' part of each \term{operator} specification),
+but in all other situations (see the ``Exceptional Situations''
+part of each \term{operator} specification).
+ 
+A situation is the evaluation of an expression in a specific context.
+%at a particular point in time? -kmp 5-Sep-91
+A \term{condition} is an \term{object} that
+represents a specific situation that has been detected.  
+\term{Conditions} are \instancesofclasses{condition}.
+A hierarchy of \term{condition} classes is defined in \clisp.  
+A \term{condition} has \term{slots} that contain data 
+relevant to the situation that the \term{condition} represents.
+
+An error is a situation in which normal program execution cannot
+continue correctly without some form of intervention (either
+interactively by the user or under program control).  Not all errors
+are detected.  When an error goes undetected, the effects can be
+\term{implementation-dependent}, \term{implementation-defined}, unspecified, or
+undefined. \Seesection\Definitions.  All detected errors can
+be represented by \term{conditions}, but not all 
+\term{conditions} represent errors.
+ 
+Signaling is the process by which a \term{condition} can alter
+the flow of control in a program by raising the 
+\term{condition} which can then be \term{handled}.  The functions
+\funref{error}, \funref{cerror}, \funref{signal}, and
+\funref{warn} are used to signal \term{conditions}.
+ 
+The process of signaling involves the selection and invocation of a
+\term{handler} from a set of \term{active} \term{handlers}.  
+A \term{handler} is a \term{function} of one argument (the 
+\term{condition}) that is invoked to handle a \term{condition}.
+Each \term{handler} is associated with a \term{condition} \term{type},
+and a \term{handler} will be invoked only on a \term{condition} of the
+\term{handler}'s associated \term{type}.
+ 
+\term{Active} \term{handlers} are \term{established} dynamically
+(see \macref{handler-bind} or \macref{handler-case}).
+\term{Handlers} are invoked in a \term{dynamic environment} 
+equivalent to that of the signaler,
+except that the set of \term{active} \term{handlers} 
+is bound in such a way as to include only those that were \term{active} 
+at the time the \term{handler} being invoked was \term{established}.
+Signaling a \term{condition} has no side-effect on the \term{condition}, 
+and there is no dynamic state contained in a \term{condition}.
+ 
+If a \term{handler} is invoked, it can address the \term{situation} 
+in one of three ways:
+ 
+\beginlist
+\itemitem{\b{Decline}}
+
+It can decline to \term{handle} the \term{condition}.  It does this by
+simply returning rather than transferring control.
+When this happens, any values returned by the handler are
+ignored and the next most recently established handler is invoked.
+If there is no such handler and the signaling function is \funref{error}
+or \funref{cerror}, the debugger is entered in the
+\term{dynamic environment} of the signaler. If there is no such
+handler and the signaling function is either \funref{signal} or
+\funref{warn}, the signaling function simply returns~\nil.
+
+\itemitem{\b{Handle}}
+ 
+It can \term{handle} the \term{condition} by performing a non-local
+transfer of control.  This can be done either primitively by using
+\specref{go}, \macref{return}, \specref{throw} or more
+abstractly by using a function such as \funref{abort} or
+\funref{invoke-restart}.
+
+\itemitem{\b{Defer}}
+ 
+It can put off a decision about whether to \term{handle} or \term{decline},
+by any of a number of actions, but most commonly by 
+    signaling another condition,
+    resignaling the same condition,
+ or forcing entry into the debugger.
+
+\endlist
+%%KMP
+%The latter two actions 
+%are really just ways of putting off the decision to either \term{handle}
+%or decline. Ultimately,
+%all a handler can do is to \term{handle} or decline to \term{handle}.
+ 
+\beginSubsection{Condition Types}
+ 
+\Thenextfigure\ lists the \term{standardized} \term{condition} \term{types}.
+Additional \term{condition} \term{types} can be defined by using \macref{define-condition}.
+
+\issue{UNDEFINED-FUNCTIONS-AND-VARIABLES:COMPROMISE}
+\issue{DATA-IO:ADD-SUPPORT}
+\issue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+\issue{ACCESS-ERROR-NAME}
+\issue{READER-ERROR:NEW-TYPE}
+\issue{FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89}
+\issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+\DefineFigure{StandardizedConditionTypes}
+\displaythree{Standardized Condition Types}{
+arithmetic-error&floating-point-overflow&simple-type-error\cr
+cell-error&floating-point-underflow&simple-warning\cr
+condition&package-error&storage-condition\cr
+control-error&parse-error&stream-error\cr
+division-by-zero&print-not-readable&style-warning\cr
+end-of-file&program-error&type-error\cr
+error&reader-error&unbound-slot\cr
+file-error&serious-condition&unbound-variable\cr
+floating-point-inexact&simple-condition&undefined-function\cr
+floating-point-invalid-operation&simple-error&warning\cr
+}
+\endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+\endissue{FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89}
+\endissue{READER-ERROR:NEW-TYPE}
+\endissue{ACCESS-ERROR-NAME}
+\endissue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+\endissue{DATA-IO:ADD-SUPPORT}
+\endissue{UNDEFINED-FUNCTIONS-AND-VARIABLES:COMPROMISE}
+
+All \term{condition} types are \subtypesof{condition}.  That is,
+ 
+\code
+ (typep \param{c} 'condition) \EV \term{true}
+\endcode
+if and only if \param{c} is a \term{condition}.
+ 
+\term{Implementations} must define all specified \term{subtype} relationships.
+%!!! Barrett: I don't understand this sentence.
+Except where noted, all \term{subtype} relationships indicated in 
+this document are not mutually exclusive.
+A \term{condition} inherits the structure of its \term{supertypes}.
+%!!! Barrett: It would be easier to say that conditions are classes, 
+%      but maybe there is some reason to avoid doing so?
+ 
+The metaclass of \theclass{condition} is not specified.
+\term{Names} of \term{condition} \term{types} may be used to specify
+\term{supertype} relationships in \macref{define-condition}, 
+but the consequences are not specified if an attempt is made to use
+a \term{condition} \term{type} as a \term{superclass} in a \macref{defclass} \term{form}.
+
+% \Thenextfigure\ lists the \term{condition} \term{types} defined in this specification.
+%  
+% \issue{UNDEFINED-FUNCTIONS-AND-VARIABLES:COMPROMISE}
+% \issue{DATA-IO:ADD-SUPPORT}
+% \issue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+% \issue{ACCESS-ERROR-NAME}
+% \issue{READER-ERROR:NEW-TYPE}
+% \issue{FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89}
+% \issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+% \displaythree{Condition Types}{
+% arithmetic-error&package-error&storage-condition\cr
+% cell-error&parse-error&stream-error\cr
+% condition&print-not-readable&style-warning\cr
+% control-error&program-error&type-error\cr
+% division-by-zero&reader-error&unbound-slot\cr
+% end-of-file&serious-condition&unbound-slot-instance\cr
+% error&simple-condition&unbound-variable\cr
+% file-error&simple-error&undefined-function\cr
+% floating-point-overflow&simple-type-error&warning\cr
+% floating-point-underflow&simple-warning&\cr
+% }
+% \endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+% \endissue{FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89}
+% \endissue{READER-ERROR:NEW-TYPE}
+% \endissue{ACCESS-ERROR-NAME}
+% \endissue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+% \endissue{DATA-IO:ADD-SUPPORT}
+% \endissue{UNDEFINED-FUNCTIONS-AND-VARIABLES:COMPROMISE}
+
+\Thenextfigure\ shows \term{operators} that
+define \term{condition} \term{types} and creating \term{conditions}.
+
+\displaythree{Operators that define and create conditions.}{
+define-condition&make-condition&\cr
+}
+
+\Thenextfigure\ shows \term{operators} that \term{read} 
+the \term{value} of \term{condition} \term{slots}.
+
+\issue{DATA-IO:ADD-SUPPORT}
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\displaytwo{Operators that read condition slots.}{
+arithmetic-error-operands&simple-condition-format-arguments\cr
+arithmetic-error-operation&simple-condition-format-control\cr
+cell-error-name&stream-error-stream\cr
+file-error-pathname&type-error-datum\cr
+package-error-package&type-error-expected-type\cr
+print-not-readable-object&unbound-slot-instance\cr
+}
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\endissue{DATA-IO:ADD-SUPPORT}
+
+\beginsubsubsection{Serious Conditions}
+
+A \term{serious condition} is a \term{condition} serious
+enough to require interactive intervention if not handled.  
+\term{Serious conditions} are typically signaled with \funref{error} or \funref{cerror};
+non-serious \term{conditions} are typically signaled with \funref{signal} or \funref{warn}.
+%%Barrett: Definitional.
+%All \term{serious conditions} should be \subtypesof{serious-condition}.
+
+\endsubsubsection%{Serious Conditions}
+
+\endSubsection%{Condition Types}
+
+\beginsubsection{Creating Conditions}
+
+The function \funref{make-condition} can be used to construct
+a \term{condition} \term{object} explicitly.  Functions such as \funref{error},
+\funref{cerror}, \funref{signal}, and \funref{warn} operate on
+\term{conditions} and might create \term{condition} \term{objects}
+implicitly.  Macros such as \macref{ccase}, \macref{ctypecase},
+\macref{ecase}, \macref{etypecase}, \macref{check-type}, and
+\macref{assert} might also implicitly create (and \term{signal})
+\term{conditions}.
+ 
+\beginsubsubsection{Condition Designators}
+\DefineSection{ConditionDesignators}
+
+A number of the functions in the condition system take arguments which
+are identified as \newtermidx{condition designators}{condition designator}.
+By convention, those arguments are notated as
+
+\ \param{datum} {\rest} \param{arguments}
+
+Taken together, the \param{datum} and the \param{arguments} are 
+``\term{designators} for a \term{condition} of default type \param{default-type}.''
+How the denoted \term{condition} is computed depends on the type of the \param{datum}:
+
+\beginlist
+
+\item{{\bull} If the \param{datum} is a \term{symbol} 
+              naming a \term{condition} \term{type} $\ldots$}
+
+The denoted \term{condition} is the result of
+
+\code
+ (apply #'make-condition \param{datum} \param{arguments})
+\endcode
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\item{{\bull} If the \param{datum} is a \term{format control} $\ldots$}
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+The denoted \term{condition} is the result of 
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\code
+ (make-condition \param{defaulted-type} 
+                 :format-control \param{datum}
+                 :format-arguments \param{arguments})
+\endcode
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+%Barrett wanted this added so that implementations could do something more
+%elaborate than just the given type without interfering with user programs.
+%There's a lot of mail about simple-condition-disjointness-bug which might or
+%might not actually turn into a formal issue someday. -kmp 2-Feb-92
+where the \param{defaulted-type} is a \term{subtype} of \param{default-type}.
+
+\item{{\bull} If the \param{datum} is a \term{condition} $\ldots$}
+
+The denoted \term{condition} is the \param{datum} itself.
+In this case, unless otherwise specified by the description of the
+\term{operator} in question, the \term{arguments} must be \term{null};
+that is, the consequences are undefined if any \param{arguments} were supplied. 
+
+\endlist
+
+Note that the \param{default-type} gets used only in the case where
+the \param{datum} \term{string} is supplied.  In the other situations,
+the resulting condition is not necessarily of \term{type} \param{default-type}.
+
+Here are some illustrations of how different \term{condition designators}
+can denote equivalent \term{condition} \term{objects}:
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\code
+(let ((c (make-condition 'arithmetic-error :operator '/ :operands '(7 0))))
+  (error c))
+\EQ (error 'arithmetic-error :operator '/ :operands '(7 0))
+
+(error "Bad luck.")
+\EQ (error 'simple-error :format-control "Bad luck." :format-arguments '())
+\endcode
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\endsubsubsection%{Condition Designators}
+
+\endsubsection%{Creating Conditions}
+ 
+\beginsubsection{Printing Conditions}
+\DefineSection{PrintingConditions}
+ 
+If the \kwd{report} argument to \macref{define-condition} is used,
+a print function is defined that is called whenever 
+the defined \term{condition} is printed while \thevalueof{*print-escape*} is \term{false}. 
+This function is called the \newterm{condition reporter};
+the text which it outputs is called a \newterm{report message}.
+
+When a \term{condition} is printed and \varref{*print-escape*}
+is \term{false}, the \term{condition reporter} for the \term{condition} is invoked.
+\term{Conditions} are printed automatically by functions such as
+\funref{invoke-debugger}, \funref{break}, and \funref{warn}.
+
+When \varref{*print-escape*} is \term{true}, the \term{object} should print in an
+abbreviated fashion according to the style of the implementation
+(\eg by \funref{print-unreadable-object}).  It is not required that a
+\term{condition} can be recreated by reading its printed representation.
+ 
+No \term{function} is provided for directly \term{accessing} 
+or invoking \term{condition reporters}.
+ 
+\beginsubsubsection{Recommended Style in Condition Reporting}
+
+In order to ensure a properly aesthetic result when presenting
+\term{report messages} to the user, certain stylistic conventions are
+recommended.
+
+There are stylistic recommendations for the content of the messages
+output by \term{condition reporters}, but there are no formal requirements 
+on those \term{programs}.
+If a \term{program} violates the recommendations for some message, the
+display of that message might be less aesthetic than if the guideline
+had been observed, but the \term{program} is still considered a
+\term{conforming program}.
+
+The requirements on a \term{program} or \term{implementation} which
+invokes a \term{condition reporter} are somewhat stronger.  A \term{conforming
+program} must be permitted to assume that if these style guidelines are
+followed, proper aesthetics will be maintained.  Where appropriate, any
+specific requirements on such routines are explicitly mentioned below.
+
+\beginsubsubsubsection{Capitalization and Punctuation in Condition Reports}
+
+It is recommended that a \term{report message} be a complete sentences, in the
+proper case and correctly punctuated.  In English, for example, this
+means the first letter should be uppercase, and there should be a
+trailing period.
+
+\code
+ (error "This is a message")  ; Not recommended
+ (error "this is a message.") ; Not recommended
+
+ (error "This is a message.") ; Recommended instead
+\endcode
+
+\endsubsubsubsection%{Capitalization and Punctuation in Condition Reports}
+
+\beginsubsubsubsection{Leading and Trailing Newlines in Condition Reports}
+
+It is recommended that a \term{report message} not begin with any 
+introductory text, such as ``\f{Error: }'' or ``\f{Warning: }''
+or even just \term{freshline} or \term{newline}. 
+Such text is added, if appropriate to the context,
+by the routine invoking the \term{condition reporter}.
+
+It is recommended that a \term{report message} not be followed 
+by a trailing \term{freshline} or \term{newline}.
+Such text is added, if appropriate to the context, 
+by the routine invoking the \term{condition reporter}.
+
+\code
+ (error "This is a message.~%")   ; Not recommended
+ (error "~&This is a message.")   ; Not recommended
+ (error "~&This is a message.~%") ; Not recommended
+
+ (error "This is a message.")     ; Recommended instead
+\endcode
+
+\endsubsubsubsection%{Leading and Trailing Newlines in Condition Reports}
+
+\beginsubsubsubsection{Embedded Newlines in Condition Reports}
+
+Especially if it is long, it is permissible and appropriate for 
+a \term{report message} to contain one or more embedded \term{newlines}.
+
+If the calling routine conventionally inserts some additional prefix
+(such as ``\f{Error: }'' or ``\f{;; Error: }'') on the first line of
+the message, it must also assure that an appropriate prefix will be
+added to each subsequent line of the output, so that the left edge of
+the message output by the \term{condition reporter} will still be properly
+aligned.
+
+\code
+ (defun test ()
+   (error "This is an error message.~\%It has two lines."))
+
+ ;; Implementation A
+ (test)
+ This is an error message.
+ It has two lines.
+
+ ;; Implementation B
+ (test)
+ ;; Error: This is an error message.
+ ;;        It has two lines.
+
+ ;; Implementation C
+ (test)
+ >> Error: This is an error message. 
+           It has two lines.
+\endcode
+
+\endsubsubsubsection%{Embedded Newlines in Condition Reports}
+
+\beginsubsubsubsection{Note about Tabs in Condition Reports}
+
+Because the indentation of a \term{report message} might be shifted to the right or
+left by an arbitrary amount, special care should be taken with the
+semi-standard \term{character} \TabChar\ 
+(in those \term{implementations} that support such a \term{character}).  
+Unless the \term{implementation} specifically defines its behavior 
+in this context, its use should be avoided.
+
+\endsubsubsubsection%{Note about Tabs in Condition Reports}
+
+\beginsubsubsubsection{Mentioning Containing Function in Condition Reports}
+
+The name of the containing function should generally not be mentioned in
+\term{report messages}.  It is assumed that the \term{debugger} will make this
+information accessible in situations where it is necessary and appropriate.
+
+\endsubsubsubsection%{Mentioning Containing Function in Condition Reports}
+
+\endsubsubsection%{Recommended Style in Condition Reporting}
+
+\endsubsection%{Printing Conditions}
+\goodbreak
+\beginSubsection{Signaling and Handling Conditions}
+\DefineSection{CondSignalHandle}
+ 
+The operation of the condition system depends on the ordering of
+active \term{applicable handlers} from most recent to least recent.
+
+Each \term{handler} is associated with a \term{type specifier}
+that must designate a \subtypeof{condition}.  A \term{handler}
+is said to be \term{applicable} to a \term{condition} if that
+\term{condition} is of the \term{type} designated by the associated
+\term{type specifier}.
+
+\term{Active} \term{handlers} are \term{established} by using 
+\macref{handler-bind} (or an abstraction based on \macref{handler-bind}, 
+such as \macref{handler-case} or \macref{ignore-errors}).
+ 
+\term{Active} \term{handlers} can be \term{established} within the
+dynamic scope of other \term{active} \term{handlers}.
+At any point during program execution, there is a set of \term{active} \term{handlers}.
+When a \term{condition} is signaled, the \term{most recent} active \term{applicable handler}
+for that \term{condition} is selected from this set.
+Given a \term{condition}, the order of recentness of 
+active \term{applicable handlers} is defined by the following two rules:
+ 
+\beginlist
+ 
+ \itemitem{1.} Each handler in a set of active handlers $H\sub 1$ is
+more recent than every handler in a set $H\sub 2$ if the
+handlers in $H\sub 2$ were active when the handlers in $H\sub 1$ were
+established.
+ 
+ \itemitem{2.} Let $h\sub 1$ and $h\sub 2$ be two applicable active
+handlers established by the same \term{form}. Then $h\sub 1$ is
+more recent than $h\sub 2$ if $h\sub 1$ was defined to the left of
+$h\sub 2$ in the \term{form} that established them.
+ 
+\endlist
+ 
+%!!! Barrett:  This doesn't match my reading of CSv18, p12.
+%     I believe contradicts p21,p22 of that document.  It also differs from
+%     previous paragraph (w/ item 2) and first paragraph under "signaling".
+Once a handler in a handler binding \term{form} (such as 
+\macref{handler-bind} or \macref{handler-case}) has been selected, all
+handlers in that \term{form} become inactive for 
+the remainder of the signaling process.
+%--------------------------------------
+While the selected \term{handler} runs, no other \term{handler} established
+by that \term{form} is active. That is, if the \term{handler} declines, 
+no other handler established by that \term{form} will be considered for possible invocation.
+%-----------------------------------------------------------------------------------------
+
+\Thenextfigure\ shows \term{operators} relating to 
+the \term{handling} of \term{conditions}.
+
+\displaythree{Operators relating to handling conditions.}{
+handler-bind&handler-case&ignore-errors\cr
+}
+ 
+\beginsubsubsection{Signaling}
+\DefineSection{Signaling}
+ 
+When a \term{condition} is signaled, the most recent
+applicable \term{active} \term{handler} is invoked.  
+Sometimes a handler will decline by simply returning
+without a transfer of control.
+In such cases, the next most recent applicable active handler is
+invoked. 
+ 
+If there are no applicable handlers for a \term{condition} that
+has been signaled, or if all applicable handlers decline, the
+\term{condition} is unhandled.
+ 
+The functions \funref{cerror} and \funref{error} invoke the
+interactive \term{condition} handler (the debugger) rather than
+return if the \term{condition} being signaled, regardless of
+its \term{type}, is unhandled.  In contrast, \funref{signal}
+returns \nil\ if the \term{condition} being signaled,
+regardless of its \term{type}, is unhandled.
+
+\Thevariable{*break-on-signals*} can be used to cause the
+debugger to be entered before the signaling process begins.
+ 
+\Thenextfigure\ shows \term{defined names} relating to
+the \term{signaling} of \term{conditions}.
+
+\displaythree{Defined names relating to signaling conditions.}{
+*break-on-signals*&error&warn\cr
+cerror&signal&\cr
+}
+
+\beginsubsubsubsection{Resignaling a Condition}
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+During the \term{dynamic extent} of the \term{signaling} process for
+a particular \term{condition} \term{object}, 
+\funref{signaling} the same \term{condition} \term{object} again
+is permitted if and only if the \term{situation} represented in both
+cases are the same.
+
+For example, a \term{handler} might legitimately \term{signal} 
+the \term{condition} \term{object} that is its \term{argument}
+in order to allow outer \term{handlers} first opportunity to \term{handle} 
+the condition.  (Such a \term{handlers} is sometimes called a ``default handler.'')
+This action is permitted because the \term{situation} which the second
+\term{signaling} process is addressing is really the same \term{situation}.
+
+On the other hand, in an \term{implementation} that implemented asynchronous 
+keyboard events by interrupting the user process with a call to \funref{signal},
+it would not be permissible for two distinct asynchronous keyboard events
+to \term{signal} \term{identical} \term{condition} \term{objects}
+at the same time for different 
+%% Per X3J13 (at request of Gadbois). -kmp 5-Oct-93
+%the
+situations.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+ 
+\endsubsubsubsection%{Resignaling a Condition}
+
+\endsubsubsection%{Signaling}
+\beginsubsubsection{Restarts}
+\DefineSection{Restarts}
+ 
+%!!! Barrett: Not true. Debugger may permit arbitrary returning, depending on implementation.
+The interactive condition handler returns only through
+non-local transfer of control to specially defined \term{restarts}
+that can be set up either by the system or by user code.  Transferring
+control to a restart is called ``invoking'' the restart.  Like
+handlers, active \term{restarts} are \term{established}
+dynamically, and 
+only active \term{restarts}
+can be invoked.  An active 
+\term{restart} can be invoked by the user from
+the debugger or by a program by using \funref{invoke-restart}.
+ 
+%!!! Barrett: :TEST predicate also affects applicability.
+A \term{restart} contains a 
+\term{function} to be \term{called} when the \term{restart} is
+invoked, an optional name that can be used to find or invoke the 
+\term{restart}, and
+an optional set of interaction information for the debugger to use to
+enable the user to manually invoke a \term{restart}. 
+%    some optional information that allows the debugger 
+%    to manage the interactive selection of the \term{restart} in
+%    situations where program handlers cannot select one.
+
+The name of a \term{restart} is
+used by \funref{invoke-restart}. \term{Restarts} that can be invoked
+only within the debugger do not need names.
+%Useless information - terms unnamed and anonymous are never used.
+%\term{Restart} names provide a means 
+%to access program interfaces
+%such as 
+%\funref{find-restart} and \funref{invoke-restart}.  
+%\term{Restarts} named
+%\nil\ are called ``unnamed'' or ``anonymous'' 
+%\term{restarts}. Named \term{restarts} 
+%can be used in both
+%interactive and non-interactive situations, but unnamed
+%\term{restarts} are typically useful only in interactive situations.
+ 
+\term{Restarts} can be established by using \macref{restart-bind}, 
+\macref{restart-case}, and \macref{with-simple-restart}.
+A \term{restart} function can itself invoke any other \term{restart}
+that was active at the time of establishment of the \term{restart} 
+of which the \term{function} is part.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\issue{JUN90-TRIVIAL-ISSUES:14}
+The \term{restarts} \term{established} by 
+    a \macref{restart-bind} \term{form}, 
+    a \macref{restart-case} \term{form},
+ or a \macref{with-simple-restart} \term{form}
+have \term{dynamic extent}
+which extends for the duration of that \term{form}'s execution.
+\endissue{JUN90-TRIVIAL-ISSUES:14}
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\term{Restarts} of the same name can be ordered from least recent to
+most recent according to the following two rules:
+ 
+\beginlist
+ 
+ \itemitem{1.} Each \term{restart} in a set of active restarts
+$R\sub 1$ is more recent than every \term{restart} in a
+set $R\sub 2$ if the \term{restarts} 
+in $R\sub 2$ were active when the  \term{restarts} in $R\sub 1$ were
+established.
+ 
+ \itemitem{2.} Let $r\sub 1$ and $r\sub 2$ be two active \term{restarts} with
+the same name established by the same \term{form}. Then $r\sub 1$ is
+more recent than $r\sub 2$ if $r\sub 1$ was defined to the
+left of $r\sub 2$ in the \term{form} that established them.
+ 
+\endlist
+
+If a \term{restart} is invoked but does not transfer control,
+the values resulting from the \term{restart} function are
+returned by the function that invoked the restart, either
+\funref{invoke-restart} or \funref{invoke-restart-interactively}.
+%!!! Barrett: There are other functions that invoke restarts that we built
+%      on these two; i.e., muffle-warning, etc.
+
+\beginsubsubsubsection{Interactive Use of Restarts}
+
+%%KMP replaced 
+%Interaction information comprises two \term{functions}, called the
+%\kwd{report} function and the \kwd{interactive}
+%function. The \kwd{report} function is used to print a
+%description of the \term{restart} and takes a 
+%\term{stream} as an argument.  The
+%\kwd{interactive} function is used to produce a list of
+%arguments for the \term{restart} function if that 
+%\term{restart} is invoked; the
+%\kwd{interactive} function takes no arguments.
+% 
+% 
+%When the debugger is entered, the set of active \term{restarts} 
+%is presented to the user. If an active \term{restart} has interaction
+%information, the \kwd{report} function is used to print a
+%description of the \term{restart}. If the 
+%\term{restart} is invoked (in an
+%\term{implementation-dependent} manner), the \kwd{interactive} function
+%is invoked to produce a list of arguments to which the \term{restart}
+%function is applied as if with \funref{apply}. If an active
+%\term{restart} does not have a \kwd{report} 
+%function and a description
+%of the \term{restart} is printed, the description is
+%\term{implementation-dependent}.  If an active \term{restart} does have not an
+%\kwd{interactive} function and the \term{restart} is invoked
+%interactively, the \term{restart} 
+%function is invoked with no arguments.
+%\macref{restart-bind} and \macref{restart-case} supply
+%defaults for interaction information.  
+%If a \term{restart} 
+%is invoked from
+%within the debugger and the \term{restart} 
+%function simply returns,
+%the consequences are unspecified.
+ 
+For interactive handling, two pieces of information are needed
+from a \term{restart}: a report function and an interactive function.
+ 
+The report function
+%which can be specified using the 
+%\kwd{report-function}
+%   keyword in 
+%\macref{restart-bind} or the 
+%\kwd{report} keyword in \macref{restart-case},
+is used by a program such as the debugger to
+present a description of the action the \term{restart} will take.  
+The report function is specified and established by the 
+\kwd{report-function} keyword to
+\macref{restart-bind} or the 
+\kwd{report} keyword to \macref{restart-case}. 
+%The
+%   report function is a function of one argument, a stream on which
+%   the output is to be done.  If no report function is specified by
+%   the user, the restart will be reported in an \term{implementation-dependent}
+%   way. 
+ 
+The interactive function, which can be specified using the 
+\kwd{interactive-function} keyword to 
+\macref{restart-bind} or \kwd{interactive} keyword
+to \macref{restart-case}, is used when the \term{restart}
+is invoked
+interactively, such as from the debugger, to produce a suitable
+list of arguments. 
+%The function takes no arguments, and may
+%   prompt interactively on *QUERY-IO* if necessary.  The result 
+%   should be a list of arguments suitable for use in the expression
+%     (APPLY #'INVOKE-RESTART <restart> <arguments>).
+%   If no interactive function is specified by the user, the argument
+%   list NIL will be assumed.
+ 
+\funref{invoke-restart} invokes the most recently \term{established}
+%!!! Barrett: "active" -- :TEST could inhibit activation.
+\term{restart} whose
+name is the same as the first argument to \funref{invoke-restart}.
+If a \term{restart} is invoked interactively by the debugger and  does
+not transfer control but rather returns values, the precise
+action of the debugger on those values is \term{implementation-defined}.
+
+%!!! Barrett: This doesn't talk about supplying restart objects to INVOKE-RESTART.
+ 
+\endsubsubsubsection%{Interactive Use of Restarts}
+\beginsubsubsubsection{Interfaces to Restarts}
+\DefineSection{InterfacesToRestarts}
+ 
+%%KMP replaced
+%It is possible to define a functional interface that hides the use of
+%\funref{invoke-restart}.  The functions \funref{abort},
+%\funref{continue}, \funref{muffle-warning}, \funref{store-value},
+%and \funref{use-value} are such interfaces.
+Some \term{restarts} have functional interfaces, 
+%either for syntactic
+%   convenience or to de-emphasize the use of restarts in their
+%   implementation.  
+such as \funref{abort}, \funref{continue}, 
+\funref{muffle-warning}, \funref{store-value}, and 
+\funref{use-value}.
+They are ordinary functions that use 
+ \funref{find-restart} and \funref{invoke-restart} internally,
+that have the same name as the \term{restarts} they manipulate,
+and that are provided simply for notational convenience.
+ 
+\Thenextfigure\ shows \term{defined names} relating to
+\term{restarts}.
+
+\displaythree{Defined names relating to restarts.}{
+abort&invoke-restart-interactively&store-value\cr
+compute-restarts&muffle-warning&use-value\cr
+continue&restart-bind&with-simple-restart\cr
+find-restart&restart-case&\cr
+invoke-restart&restart-name&\cr
+}
+ 
+\endsubsubsubsection%{Interfaces to Restarts}
+
+\beginsubsubsubsection{Restart Tests}
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+Each \term{restart} has an associated test, which is a function of one
+argument (a \term{condition} or \nil) which returns \term{true} if the \term{restart}
+should be visible in the current \term{situation}.  This test is created by 
+the \kwd{test-function} option to \macref{restart-bind} or 
+the \kwd{test} option to \macref{restart-case}.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\endsubsubsubsection%{Restart Tests}
+
+\beginsubsubsubsection{Associating a Restart with a Condition}
+\DefineSection{AssocRestartWithCond}
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+A \term{restart} can be ``associated with'' a \term{condition} explicitly
+by \macref{with-condition-restarts}, or implicitly by \macref{restart-case}.
+Such an assocation has \term{dynamic extent}.
+
+A single \term{restart} may be associated with several \term{conditions} 
+at the same time.
+A single \term{condition} may have several associated \term{restarts}
+at the same time.
+
+Active restarts associated with a particular \term{condition} can be detected
+by \term{calling} a \term{function} such as \funref{find-restart}, supplying
+that \term{condition} as the \param{condition} \term{argument}.
+Active restarts can also be detected without regard to any associated
+\term{condition} by calling such a function without a \param{condition} \term{argument},
+or by supplying a value of \nil\ for such an \term{argument}.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\endsubsubsubsection%{Associating a Restart with a Condition}
+
+\endsubsubsection%{Restarts}
+\endSubsection%{Signaling and Handling Conditions}
+\goodbreak
+\beginSubsection{Assertions}
+ 
+Conditional signaling of \term{conditions}
+based on such things as key match, form evaluation,
+and \term{type} are handled by assertion \term{operators}.
+\Thenextfigure\ shows \term{operators} relating to assertions.
+
+\displaythree{Operators relating to assertions.}{
+assert&check-type&ecase\cr
+ccase&ctypecase&etypecase\cr
+}
+ 
+\endSubsection%{Assertions}
+
+% Date: Tue, 4 Jun 91 10:39:28 EDT
+% From: kab@chestnut.com (Kim Barrett)
+% To: mueller@sumex-aim.stanford.edu
+% Cc: common-lisp@mcc.com
+% Message-Id: <9106041439.AA08564@chestnut.com>
+% In-Reply-To: <2884982915-12705048@KSL-EXP-30>
+% Subject: CLEH restarts...
+% 
+% [...]
+% The rules for determining whether a (visible) restart is active are:
+% 
+% 1. If the test function for the restart returns false when applied to the
+% condition argument (which may be NIL), then the restart is inactive.
+% 
+% 2. If testing for applicability to a specific condition (the condition argument
+% is actually a condition object), then either
+%   a. The restart is associated with the specified condition.
+%   b. The restart is not associated with some other condition object.
+%      [This case was accidentally left out of the Version 2 proposal.]
+% or the restart is inactive.
+% 
+% 3. If neither of (1) and (2) indicate the restart to be inactive, then it is
+% active.
+% [...]
+
+
+\beginsubsection{Notes about the Condition System's Background}
+
+For a background reference to the abstract concepts detailed in this
+section, see \CondSysPaper.  The details of that paper are not binding on
+this document, but may be helpful in establishing a conceptual basis for
+understanding this material.
+
+\endsubsection%{Notes about the Condition System's Background}

concept-conformance.tex

@@ -0,0 +1,275 @@
+%-*- Mode: TeX -*-
+
+%%Compliance
+This standard presents the syntax and semantics to be implemented by a
+\term{conforming implementation} (and its accompanying documentation).
+In addition, it imposes requirements on \term{conforming programs}.
+
+\beginsubSection{Conforming Implementations}
+ 
+A \newterm{conforming implementation} shall adhere to the requirements outlined
+in this section.
+
+\beginsubsubsection{Required Language Features}
+\DefineSection{ReqLangFeatures}
+
+A \term{conforming implementation} shall accept all features 
+(including deprecated features)
+of the language specified in this standard,
+with the meanings defined in this standard.
+
+A \term{conforming implementation} shall not require the inclusion of substitute
+or additional language elements in code in order to accomplish a feature of
+the language that is specified in this standard.
+
+\endsubsubsection%{Required Language Features}
+
+\beginsubsubsection{Documentation of Implementation-Dependent Features}
+
+A \term{conforming implementation} shall be accompanied by a document
+that provides a definition of all \term{implementation-defined}
+aspects of the language defined by this specification.
+
+In addition, a \term{conforming implementation} is encouraged (but not required) 
+to document items in this standard that are identified as
+\term{implementation-dependent}, although in some cases
+such documentation might simply identify the item as ``undefined.''
+
+\endsubsubsection%{Documentation of Implementation-Dependent Features}
+
+\beginsubsubsection{Documentation of Extensions}
+
+A \term{conforming implementation} shall be accompanied by a
+document that separately describes any features accepted by the
+\term{implementation} that are not specified in this standard, but that do not
+cause any ambiguity or contradiction when added to the language
+standard.  Such extensions shall be described as being ``extensions to
+\clisp\ as specified by ANSI \metavar{standard number}.''
+ 
+\endsubsubsection%{Documentation of Extensions}
+
+\beginsubsubsection{Treatment of Exceptional Situations}
+
+A \term{conforming implementation} shall treat exceptional situations 
+in a manner consistent with this specification.
+ 
+\beginsubsubsubsection{Resolution of Apparent Conflicts in Exceptional Situations}
+
+If more than one passage in this specification appears to apply to the
+same situation but in conflicting ways, the passage that appears
+to describe the situation in the most specific way (not necessarily the
+passage that provides the most constrained kind of error detection) 
+takes precedence.
+
+\beginsubsubsubsubsection{Examples of Resolution of Apparent Conflicts 
+			  in Exceptional Situations}
+
+Suppose that function \f{foo} is a member of a set $S$ of \term{functions} that
+operate on numbers.  Suppose that one passage states that an error must be
+signaled if any \term{function} in $S$ is ever given an argument of \f{17}.
+Suppose that an apparently conflicting passage states that the consequences 
+are undefined if \f{foo} receives an argument of \f{17}.  Then the second passage
+(the one specifically about \f{foo}) would dominate because the description of
+the situational context is the most specific, and it would not be required that
+\f{foo} signal an error on an argument of \f{17} even though other functions in 
+the set $S$ would be required to do so.
+
+\endsubsubsubsubsection%{Examples of Resolution of Apparent Conflicts
+%			 in Exceptional Situations}
+
+\endsubsubsubsection%{Resolution of Apparent Conflicts in Exceptional Situations}
+
+\endsubsubsection%{Treatment of Exceptional Situations}
+
+\beginsubsubsection{Conformance Statement}
+
+A \term{conforming implementation} shall produce a conformance statement 
+as a consequence of using the implementation, or that statement
+shall be included in the accompanying documentation.  If the implementation
+conforms in all respects with this standard, the conformance statement
+shall be
+ 
+\beginlist
+\item{} ``\metavar{Implementation} conforms with the requirements 
+	  of ANSI \metavar{standard number}''
+\endlist
+ 
+If the \term{implementation} conforms with some but not all of the requirements of this
+standard, then the conformance statement shall be
+ 
+\beginlist
+\item{} ``\metavar{Implementation} conforms with the requirements of
+	  ANSI \metavar{standard number} with the following exceptions: 
+	  \metavar{reference to or complete list of the requirements of
+		   the standard with which the implementation does not conform}.''
+\endlist 
+ 
+\endsubsubsection%{Conformance Statement}
+
+\endsubSection%{Conforming Implementations}
+
+\beginsubSection{Conforming Programs}
+\idxterm{conforming program}\idxterm{conforming code}
+
+Code conforming with the requirements of this standard shall adhere to the
+following:
+
+\beginlist
+ \itemitem{1.} \term{Conforming code} shall use only those features of the
+               language syntax and semantics that are 
+	       either specified in this standard
+		   or defined using the extension mechanisms 
+		      specified in the standard.
+%% This biz about syntactic extension seems overly specific for this context. -kmp 23-Oct-91
+% 		      (\eg \term{symbol macros}, 
+% 			   \term{macros}, 
+% %%Compiler macros do not extend syntax.  
+% %%They only provide an alternate implementation of existing syntax. -kmp 11-Mar-91
+% %\term{compiler macros},
+% 		       and \term{reader macros}).
+ 
+
+%% Rewritten per X3J13 and Boyer/Kaufmann/Moore #2 (second public review).
+%% -kmp 9-May-94
+% \itemitem{2.} \term{Conforming code} shall not rely on any particular
+%               interpretation of \term{implementation-dependent} features.
+\itemitem{2.} \term{Conforming code} may use
+	      \term{implementation-dependent} features and values, 
+	      but shall not rely upon
+	      any particular interpretation of these features and values 
+	      other than those that are discovered by the execution of \term{code}.
+
+\itemitem{3.} \term{Conforming code} shall not depend on the consequences
+	      of undefined or unspecified situations.
+
+\itemitem{4.} \term{Conforming code} does not use any constructions 
+	      that are prohibited by the standard.
+
+\itemitem{5.} \term{Conforming code} does not depend on extensions 
+	      included in an implementation.
+\endlist 
+
+% This material is all covered in more detail in chapter 3 (in the section
+% on constraints on externalizable objects).  There is no need to repeat
+% the material here.  --sjl 13 Mar 92
+%\beginsubsubsection{Conforming Programs in Files}
+%
+%A \term{conforming program} whose source text is in a \term{compilation unit}
+%must satisfy the following constraints:
+%
+%\beginlist
+%
+%\item{\bull} 
+%  Any \term{top level form} in a \term{file} that alters 
+%  \thevalueof{*package*} at compile time must also alter it at load time
+%  to a \term{similar} \term{package}.
+%
+%\item{\bull}
+%  If the first \term{non-atomic} \term{top level form} in the \term{file}
+%  is not a call to \macref{in-package}, then the \term{current package}
+%  at load time must be a \term{similar} \term{package} to the one in effect at 
+%  compile time.
+%
+%\item{\bull}
+%  Any \term{symbol} in the source text \term{accessible} in the
+%  \term{current package} at compile time and whose \term{home package} 
+%  is the package $P$ must be \term{accessible} in the \term{current package} 
+%  at load time and must also be \term{accessible} in a package \term{similar} to $P$.
+%  
+%\item{\bull} 
+%  Any \term{symbol} in the source text that is an \term{external symbol} 
+%  of the package $P$ at compile time must be an \term{external symbol} 
+%  of package \term{similar} to $P$ at load time.
+%
+%\endlist
+%
+%In \term{situations} in which any of these conditions does not hold,
+%an \term{implementation} might signal an error 
+%or might extend \clisp\ to handle the situation.
+%
+%\endsubsubsection%{Conforming Programs in Files}
+
+\beginsubsubsection{Use of Implementation-Defined Language Features}
+
+Note that \term{conforming code} may rely on particular
+\term{implementation-defined} values or features. Also note that the
+requirements for \term{conforming code} and \term{conforming implementations} do not
+require that the results produced by conforming code always be the
+same when processed by a \term{conforming implementation}. The results may be the
+same, or they may differ.
+
+%% Moved to its own section (see below) per Dalton #1 (1st Public Review) 
+%% by X3J13 vote May 4-5, 1994 (after 2nd public review).
+%% -kmp 9-May-94
+% %!!! Barmar wonders if this is really the right place for the next sentence.
+% \term{Portable code} is written using only \term{standard characters}.
+
+%Informally, the basic rules for conformance are as follows:
+%1. Conforming code is defined in terms of its structure,
+%and not in terms of its results and side effects.
+%2. Conforming code is written using only the syntax specified in the standard,
+%or syntax defined using the syntax extension mechanisms (macros and reader
+%macros) specified in the standard.
+%3. Conforming code is written in only the sequence specified in the standard.
+%4. Conforming code is written using only the functions, macros,
+%special forms, variables, and constants specified in the standard.
+%5. Conforming implementations provide the functionality and behavior 
+%specified in the standard.
+%The definitions of all names and syntax that aren't specified in the 
+%standard and aren't provided by the implementation must accompany the code. 
+%6. Conformance is not machine-checkable.
+ 
+Conforming code may run in all conforming implementations, but might
+have allowable \term{implementation-defined} behavior that makes it
+non-portable code.
+%Insofar as we allow options in the standard this will be true.
+For example, the following are examples of \term{forms} that are conforming, but
+that might return different \term{values} in different implementations:
+
+\code
+ (evenp most-positive-fixnum) \EV \term{implementation-dependent}
+ (random) \EV \term{implementation-dependent}
+ (> lambda-parameters-limit 93) \EV \term{implementation-dependent}
+ (char-name #\\A) \EV \term{implementation-dependent}
+\endcode 
+
+\beginsubsubsubsection{Use of Read-Time Conditionals}
+\DefineSection{ReadTimeConditionals}
+
+%The following is added to clarify a question from RWK.
+%Mail sent to him and Quinquevirate noting that this interpretation was made.
+% -kmp 10-Apr-91
+
+Use of \f{\#+} and \f{\#-} does not automatically disqualify a program
+from being conforming.  A program which uses \f{\#+} and \f{\#-} is 
+considered conforming if there is no set of \term{features} in which the
+program would not be conforming.  Of course, \term{conforming programs} are
+not necessarily working programs.  The following program is conforming:
+
+\code
+(defun foo ()
+  \#+ACME (acme:initialize-something)
+  (print 'hello-there))
+\endcode
+
+However, this program might or might not work, depending on whether the
+presence of the feature \f{ACME} really implies that a function named
+\f{acme:initialize-something} is present in the environment.  In effect,
+using \f{\#+} or \f{\#-} in a \term{conforming program} means that the variable
+\varref{*features*}\idxref{*features*}
+becomes just one more piece of input data to that 
+program.  Like any other data coming into a program, the programmer
+is responsible for assuring that the program does not make unwarranted
+assumptions on the basis of input data.
+
+\endsubsubsubsection%{Use of Read-Time Conditionals}
+
+\endsubsubsection%{Use of Implementation-Defined Language Features}
+
+\beginsubsubsection{Character Set for Portable Code}
+
+\term{Portable code} is written using only \term{standard characters}.
+
+\endsubsubsection%{Character Set for Portable Code}
+
+\endsubSection%{Conforming Programs}

concept-conses.tex

@@ -0,0 +1,134 @@
+% -*- Mode: TeX -*-
+
+A \newterm{cons} is a compound data \term{object} 
+having two components called the \term{car} and the \term{cdr}.
+
+\displaythree{Some defined names relating to conses.}{
+car&cons&rplacd\cr
+cdr&rplaca&\cr
+}
+
+Depending on context, a group of connected \term{conses} can be viewed
+in a variety of different ways.  A variety of operations is provided to
+support each of these various views.
+
+\beginsubsection{Conses as Trees}
+
+A \newterm{tree} is a binary recursive data structure made up of
+\term{conses} and \term{atoms}:
+the \term{conses} are themselves also \term{trees}
+(sometimes called ``subtrees'' or ``branches''), and the \term{atoms}
+are terminal nodes (sometimes called \newterm{leaves}). 
+Typically, the \term{leaves} represent data while the branches 
+establish some relationship among that data.
+
+\displayfour{Some defined names relating to trees.}{
+caaaar&caddar&cdar&nsubst\cr
+caaadr&cadddr&cddaar&nsubst-if\cr
+caaar&caddr&cddadr&nsubst-if-not\cr
+caadar&cadr&cddar&nthcdr\cr
+caaddr&cdaaar&cdddar&sublis\cr
+caadr&cdaadr&cddddr&subst\cr
+caar&cdaar&cdddr&subst-if\cr
+cadaar&cdadar&cddr&subst-if-not\cr
+cadadr&cdaddr&copy-tree&tree-equal\cr
+cadar&cdadr&nsublis&\cr
+}
+
+\beginsubsubsection{General Restrictions on Parameters that must be Trees}
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+Except as explicitly stated otherwise,
+for any \term{standardized} \term{function} that takes a \term{parameter}
+that is required to be a \term{tree},
+the consequences are undefined
+if that \term{tree} is circular.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\endsubsubsection%{General Restrictions on Parameters that must be Trees}
+
+\endsubsection%{Conses as Trees}
+
+\beginsubsection{Conses as Lists}
+
+A \newterm{list} is a chain of \term{conses} in which the \term{car} of each
+\term{cons} is an \term{element} of the \term{list}, 
+and the \term{cdr} of each \term{cons} is either the next
+link in the chain or a terminating \term{atom}.  
+
+A \newterm{proper list} is a \term{list} terminated by the \term{empty list}.
+The \term{empty list} is a \term{proper list}, but is not a \term{cons}.
+
+An \newterm{improper list} is a \term{list} that is not a \term{proper list};
+that is, it is a \term{circular list} or a \term{dotted list}.
+
+A \newterm{dotted list} is a \term{list} that has a terminating \term{atom}
+that is not the \term{empty list}.  A \term{non-nil} \term{atom} by itself
+is not considered to be a \term{list} of any kind---not even a \term{dotted list}.
+
+A \newterm{circular list} is a chain of \term{conses} that has no termination 
+because some \term{cons} in the chain is the \term{cdr} of a later \term{cons}.
+
+\displayfour{Some defined names relating to lists.}{
+append&last&nbutlast&rest\cr
+butlast&ldiff&nconc&revappend\cr
+copy-alist&list&ninth&second\cr
+copy-list&list*&nreconc&seventh\cr
+eighth&list-length&nth&sixth\cr
+endp&make-list&nthcdr&tailp\cr
+fifth&member&pop&tenth\cr
+first&member-if&push&third\cr
+fourth&member-if-not&pushnew&\cr
+}
+ 
+\beginsubsubsection{Lists as Association Lists}
+
+An \newterm{association list} is a \term{list} of \term{conses} 
+representing an association of \term{keys} with \term{values}, 
+where the \term{car} of each \term{cons} is the \term{key} 
+and the \term{cdr} is the \term{value} associated with that \term{key}.
+
+\displayfour{Some defined names related to assocation lists.}{
+acons&assoc-if&pairlis&rassoc-if\cr
+assoc&assoc-if-not&rassoc&rassoc-if-not\cr
+}
+
+\endsubsubsection%{Lists as Association Lists}
+
+\beginsubsubsection{Lists as Sets}
+
+\term{Lists} are sometimes viewed as sets by considering their elements
+unordered and by assuming there is no duplication of elements.
+
+\displayfour{Some defined names related to sets.}{
+adjoin&nset-difference&set-difference&union\cr
+intersection&nset-exclusive-or&set-exclusive-or&\cr
+nintersection&nunion&subsetp&\cr
+}
+
+\endsubsubsection%{Lists as Sets}
+
+\beginsubsubsection{General Restrictions on Parameters that must be Lists}
+
+%Barrett: This forces something like
+% 	    \f{(MEMBER X '(X Y . Z))} to detect the \f{( . Z )}
+% 	  in safe code even when it would not naturally be reached
+% 	  by the search.  We should soften this slightly.
+%KMP: Fixed.
+Except as explicitly specified otherwise,
+any \term{standardized} \term{function} that takes a \term{parameter}
+that is required to be a \term{list} should be prepared to signal 
+an error \oftype{type-error} if the \term{value} received is a \term{dotted list}.
+
+% Sandra complained that this was only said a few places, 
+% and needed to be said more.
+% This is a stopgap while we make sure we mean it everywhere.
+Except as explicitly specified otherwise,
+for any \term{standardized} \term{function} that takes a \term{parameter}
+that is required to be a \term{list}, 
+the consequences are undefined 
+if that \term{list} is \term{circular}.
+
+\endsubsubsection%{General Restrictions on Parameters that must be Lists}
+
+\endsubsection%{Conses as Lists}

concept-decls.tex

@@ -0,0 +1,507 @@
+% -*- Mode: TeX -*-
+
+\newtermidx{Declarations}{declaration} provide a way of specifying information for use by
+program processors, such as the evaluator or the compiler.
+
+\newtermidx{Local declarations}{local declaration}
+can be embedded in executable code using \misc{declare}.
+\newtermidx{Global declarations}{global declaration}, 
+or \newtermidx{proclamations}{proclamation},
+are established by \funref{proclaim} or \macref{declaim}.
+
+%% 9.3.0 1
+\Thespecform{the} provides a shorthand notation for 
+making a \term{local declaration} about the \term{type} of the
+\term{value} of a given \term{form}.
+%% 9.0.0 4
+% This is redundant with the next sentence.  --sjl 3 Mar 92
+% The consequences are undefined if a program violates a type declaration.
+%% 9.2.0 1
+
+%% 9.2.0 6
+The consequences are undefined if a program violates a \term{declaration}
+or a \term{proclamation}.
+
+\beginSubsection{Minimal Declaration Processing Requirements}
+
+In general, an \term{implementation} is free to ignore
+\term{declaration specifiers} except for the
+     \declref{declaration}\idxref{declaration},
+     \declref{notinline}\idxref{notinline},
+     \declref{safety}\idxref{safety},
+ and \declref{special}\idxref{special} \term{declaration specifiers}.
+
+A \declref{declaration} \term{declaration} must suppress warnings
+about unrecognized \term{declarations} of the kind that it declares.
+If an \term{implementation} does not produce warnings about
+unrecognized declarations, it may safely ignore this \term{declaration}.
+
+A \declref{notinline} \term{declaration} must be recognized by any \term{implementation}
+that supports inline functions or \term{compiler macros} in order to disable those facilities.
+An \term{implementation} that does not use inline functions or \term{compiler macros}
+may safely ignore this \term{declaration}.
+
+A \declref{safety} \term{declaration} that increases the current safety level 
+must always be recognized.  An \term{implementation} that always processes 
+code as if safety were high may safely ignore this \term{declaration}.
+
+A \declref{special} \term{declaration} must be processed by all \term{implementations}.
+
+\endSubsection%{Minimal Declaration Processing Requirements}
+
+\beginSubsection{Declaration Specifiers}
+
+A \newterm{declaration specifier} is an \term{expression} that can appear at
+top level of a \misc{declare} expression or a \macref{declaim} form, or as 
+the argument to \funref{proclaim}.
+It is a \term{list} whose \term{car} is a \term{declaration identifier},
+and whose \term{cdr} is data interpreted according to rules specific to
+the \term{declaration identifier}.
+
+\endSubsection%{Declaration Specifiers}
+
+\beginSubsection{Declaration Identifiers}
+
+\Thenextfigure\ shows a list of all 
+\term{declaration identifiers}\idxterm{declaration identifier} 
+defined by this standard.
+
+\issue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+\displaythree{Common Lisp Declaration Identifiers}{
+declaration&ignore&special\cr
+dynamic-extent&inline&type\cr
+ftype&notinline&\cr
+ignorable&optimize&\cr
+}
+%FUNCTION removed.
+\endissue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+
+%% 9.2.0 20
+An implementation is free to support other (\term{implementation-defined})
+\term{declaration identifiers} as well.  
+% Sections 3.2.2.3 and 3.2.5 both classify this as an ordinary warning.
+% --sjl 3 Mar 92
+% A warning \oftype{style-warning} might be issued
+A warning might be issued
+if a \term{declaration identifier} 
+is not among those defined above,
+%Added for Barmar:   -kmp 11-Jan-91
+is not defined by the \term{implementation},
+is not a \term{type} \term{name}, 
+and has not been declared in a \declref{declaration} \term{proclamation}.
+
+% I can't figure out where this paragraph came from, and I'm convinced
+% it's wrong.  Issue DECLARATION-SCOPE was intended to assign consistent
+% scoping rules to all declarations based only on whether they are ``bound''
+% or ``free''.  Allowing random scoping rules will also totally defeat
+% the proposed define-declaration extensions.  --sjl 7 Mar 92
+%For \term{implementation-defined} \term{declaration identifiers},
+%the \term{scope} of \term{free declarations} and \term{bound declarations}
+%is \term{implementation-defined}.
+
+\beginsubsubsection{Shorthand notation for Type Declarations}
+
+%Barrett says class objects are ok here, too.
+A \term{type specifier} can be used as a \term{declaration identifier}.
+\f{(\param{type-specifier} \starparam{var})} is taken as shorthand for
+\f{(type \param{type-specifier} \starparam{var})}.
+
+\endsubsubsection%{Shorthand notation for Type Declarations}
+
+\endSubsection%{Declaration Identifiers}
+
+\beginSubsection{Declaration Scope}
+\DefineSection{DeclScope}
+
+% Declarations can be divided into two kinds: those that concern 
+% the \term{bindings} of variables, and those that do not.
+% The \declref{special} declaration falls into both classes.
+% Declarations that concern \term{variable} \term{bindings} apply
+% only to the \term{bindings} made by the \term{form} at the head of 
+% whose body they appear.  
+% 
+% All declarations introduced with \misc{declare} fall into two classes:
+% \term{bound declarations} and \term{free declarations}.
+% \term{Bound declarations} affect both a binding and any references;
+% \term{free declarations} affect only references.
+% Some declarations may be used in either way, depending on context.
+%
+%% The above rewritten with help from Sandra and Moon. -kmp 22-Aug-91
+
+\term{Declarations} can be divided into two kinds: those that apply to the
+\term{bindings} of \term{variables} or \term{functions}; and those that
+do not apply to \term{bindings}.
+
+A \term{declaration} that appears at the head of a binding \term{form} 
+and applies to a \term{variable} or \term{function} \term{binding} 
+made by that \term{form} is called a \newterm{bound declaration}; 
+such a \term{declaration} affects both the \term{binding} and
+any references within the \term{scope} of the \term{declaration}.  
+
+\term{Declarations} that are not \term{bound declarations} are called
+\newtermidx{free declarations}{free declaration}.
+
+% \term{Free declarations} that apply to
+% \term{bindings} affect only references to those \term{bindings}.  
+A \term{free declaration} in a \term{form} $F1$ that applies to a \term{binding}
+for a \term{name} $N$ \term{established} by some \term{form} $F2$
+of which $F1$ is a \term{subform}
+affects only references to $N$ within $F1$; it does not to apply to
+other references to $N$ outside of $F1$, nor does it affect the manner
+in which the \term{binding} of $N$ by $F2$ is \term{established}.
+
+\term{Declarations} that do not apply to \term{bindings} can only appear 
+as \term{free declarations}.
+
+% Common Lisp prohibits binding the same name twice in the same binding form.
+% It has been proposed that multiple bindings be permitted for LET*, DO*, PROG* 
+% forms and for &AUX variables in lambda expressions, but never approved. 
+% In an implementation which permits multiple bindings, `bound' declarations
+% should probably be treated as if there were a separate `bound' declaration 
+% for each of the bindings, but for us to say so would really go beyond the
+% scope of this document.  As such, we'll just not say anything and leave it to
+% any implementation which defines that circumstance to also define the relationship
+% to bound declarations. -kmp 22-Aug-91
+
+%% Rewritten by Sandra in response to Margolin #7, Dalton #3, Moon #7 (First Public Review)
+% %% 9.1
+% Some \term{forms} contain pieces of code that, properly speaking,
+% are not part of the body of the \term{form}.  Examples of this
+% are initialization forms that provide values for bound variables,
+% and the result forms of iteration \term{forms}.
+% 
+% \issue{DECLARATION-SCOPE:NO-HOISTING}
+%  
+% The \term{scope} of a \term{declaration} located at the head of 
+% a \term{special form}, \term{macro form}, or \term{lambda expression} is as follows:
+% \beginlist
+% \itemitem{1.}
+% It always includes the body forms as well as any \term{step} or exit \term{forms}.
+% \itemitem{2.}
+% It also includes the \term{scope} of the name binding, if any, to which 
+% it applies (\specref{let}, \misc{lambda},  \specref{flet},  \macref{do}, etc. 
+% introduce name bindings; \specref{locally} does not).
+% \endlist
+% 
+% %!!!! RPG: I'm tired but this doesn't make sense to me at all.
+% This prescription depends on the fact that the \term{scope} of name bindings
+% is already well-defined.
+% Whether or not a particular declaration affects an initialization form 
+% (such as for \specref{let} or \specref{let*}) 
+% depends solely on whether it is
+% applied to a variable or function name being bound whose \term{scope}
+% includes such \term{forms}.  
+% In this sense, the above specification limits the
+% \term{scope} of declarations for name bindings to be exactly the 
+% \term{scope} of the
+% name binding itself. 
+% There is no ``hoisting'' for declarations in \term{special forms} or 
+% \term{lambda expressions}; 
+% the only initialization forms affected by a declaration 
+% are those included indirectly, by the effect, if any, that a 
+% declaration has on a name binding. 
+% Thus there is no
+% ``hoisting'' of the special declarations in the following example:
+% 
+% % \code
+% %  (defun bar (x y)           ;[1] 1st occurrence of x
+% %    (let ((old-x x)          ;[2] 2nd occurrence of x 
+% %          (x y))             ;[3] 3rd occurrence of x
+% %      (declare (special x))
+% %      (list old-x x)))
+% % \endcode
+% % 
+% % Laubsch: ?
+% % Barmar: Say what [the above] example is supposed to return.
+% % RPG: Also, say explicitly which bindings and references are special.
+% 
+% \code
+%  (let ((x 1))                ;[1] 1st occurrence of x
+%    (declare (special x))     ;[2] 2nd occurrence of x
+%    (let ((x 2))              ;[3] 3rd occurrence of x
+%      (let ((old-x x)         ;[4] 4th occurrence of x
+%            (x 3))            ;[5] 5th occurrence of x
+%        (declare (special x)) ;[6] 6th occurrence of x
+%        (list old-x x))))     ;[7] 7th occurrence of x
+% \EV (2 3)
+% \endcode
+% 
+% The first occurrence of \f{x} \term{establishes} a \term{dynamic binding}
+% of \f{x} because of the \declref{special} \term{declaration} for \f{x}
+% in the second line.  The third occurrence of \f{x} \term{establishes} a
+% \term{lexical binding} of \f{x} (because there is no \declref{special}
+% \term{declaration} in the corresponding \macref{let} \term{form}).
+% The fourth occurrence of \f{x} \term{x} is a reference to the
+% \term{lexical binding} of \f{x} established in the third line.
+% The fifth occurrence of \f{x} \term{establishes} a \term{dynamic binding}
+% of \term{x} for the body of the \macref{let} \term{form} that begins on
+% that line because of the \declref{special} \term{declaration} for \f{x}
+% in the sixth line. The reference to \f{x} in the fourth line is not
+% affected by the \declref{special} \term{declaration} in the sixth line 
+% because that reference is not within the ``would-be \term{lexical scope}''
+% of the \term{variable} \f{x} in the fifth line.  The reference to \f{x}
+% in the seventh line is a reference to the \term{dynamic binding} of \term{x}
+% \term{established} in the fifth line.
+% 
+% Those declarations not correlated with any name \term{binding} do
+% not cover any of the initialization forms; their \term{scope} only
+% includes the body as well as any ``stepper'' or result forms.  In a
+% sense, the above specification limits the \term{scope} of these
+% kinds of declarations to be the same as an arbitrary name 
+% \term{binding} in a \specref{let}, \specref{flet}, 
+% \issue{WITH-ADDED-METHODS:DELETE}
+% %\macref{with-added-methods},
+% \endissue{WITH-ADDED-METHODS:DELETE}
+% \issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% %\specref{generic-flet},
+% %\specref{generic-labels},
+% \endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% and \specref{labels}
+% \term{form}.
+% %[See also the issue DECLARE-TYPE-FREE.]
+% 
+% In the following:\idxref{notinline}
+% 
+% \code
+%  (lambda (&optional (x (foo 1))) ;[1]
+%    (declare (notinline foo))     ;[2]
+%    (foo x))                      ;[3]
+% \endcode
+% 
+% the \term{call} to \f{foo} in the first line might be 
+% compiled inline even though the \term{call} to \f{foo} in
+% the third line must not be.  This is because
+% the \declref{notinline} \term{declaration}
+% for \f{foo} in the second line applies only to the body on the
+% third line.  In order to suppress inlining for both \term{calls}, 
+% one might write:\idxref{notinline}
+% 
+% \code
+%  (locally (declare (notinline foo)) ;[1]
+%    (lambda (&optional (x (foo 1)))  ;[2]
+%      (foo x)))                      ;[3]
+% \endcode
+% 
+% or, alternatively:\idxref{notinline}
+% 
+% \code
+%  (lambda (&optional                               ;[1]
+%             (x (locally (declare (notinline foo)) ;[2]
+%                  (foo 1))))                       ;[3]
+%    (declare (notinline foo))                      ;[4]
+%    (foo x))                                       ;[5]
+% \endcode
+% 
+% In the following:\idxterm{type declaration}
+% 
+% \code
+%  (defun foo (x)                               ;[1]
+%    (if (typep x 'integer)                     ;[2]
+%        (list (let ((y (+ x 42)))              ;[3]
+%                (declare (fixnum x y))         ;[4]
+%                y)                             ;[5]
+%              (+ x 42))                        ;[6]
+%        `(foo ,x)))                            ;[7]
+% \endcode
+% 
+% \f{x} is not initially (\eg in the first line) known to be a \term{fixnum} 
+% since the scope of the \declref{fixnum} \term{declaration} for \f{x} in the fourth line
+% covers only the body of the \macref{let} form in the fifth line, but not the
+% \term{initialization form} for \f{y} in the third line.  The compiler can assume that
+% \f{x} is not greater than the value of \f{(- most-positive-fixnum 42)} because \f{y}
+% has been declared to be a \term{fixnum} in the fourth line.
+% Even so, neither the \term{call} to \funref{+} in the third line 
+%              nor the one in the sixth line 
+% may be optimized into \term{calls} to \term{implementation-dependent} 
+% \term{fixnum}-only arithmetic operators,
+% just in case the call to \f{foo} looks something like:
+% 
+% \code
+%  (foo (- most-negative-fixnum 1))
+% \endcode
+% 
+% In following:\idxterm{type declaration}
+% 
+% \code
+%  (defun foo (x)                               ;[1]
+%    (if (typep x 'integer)                     ;[2]
+%        (list (let ((y (+ x 42)))              ;[3]
+%                (declare (fixnum x))           ;[4]
+%                x                              ;[5]
+%                y)                             ;[6]
+%              (+ x 42))                        ;[7]
+%        `(foo ,x)))                            ;[8]
+% \endcode
+% 
+% \f{x} can be determined to be a \term{fixnum} throughout 
+% the third through seventh lines, but only by inference
+% from the fact that the reference to \f{x} in the fifth line
+% (the only reference to which the \declref{fixnum} \term{declaration}
+% in the fourth line applies) 
+% is known to be a \term{fixnum}.  Since the compiler is capable of detecting that
+% there are no \term{assignments} to \f{x}, it may reason that \f{x} is a \term{fixnum}
+% throughout even though there is no explicit \term{declaration}.
+% However, since there is no \declref{fixnum} \term{declaration} for \f{y} (as there
+% was in the previous example), the compiler may not assume that the result of the
+% addition in the third line is a \term{fixnum}.  Therefore, 
+% neither \term{call} to \funref{+} (one the third and seventh lines) 
+% may be optimized into \term{calls} to \term{implementation-dependent} 
+% \term{fixnum}-only arithmetic operators,
+% just in case the call to \term{foo} looks something like:
+% 
+% \code
+%  (foo most-positive-fixnum)
+% \endcode
+% 
+% However, in the following:\idxterm{type declaration}
+% 
+% \code
+%  (defun foo (x)                               ;[1]
+%    (if (typep x 'integer)                     ;[2]
+%        (list (let ((y (the fixnum (+ x 42)))) ;[3]
+%                (declare (fixnum x y))         ;[4]
+%                x                              ;[5]
+%                y)                             ;[6]
+%              (+ x 42))                        ;[7]
+%        `(foo ,x)))                            ;[8]
+% \endcode
+% 
+% the compiler can infer that \f{x} is a \term{fixnum} throughout 
+% the third through seventh lines by reasoning similar
+% to that for the previous example.  Further, it can infer that the result of the 
+% call to \funref{+} in the third line is a \term{fixnum} because of the \declref{fixnum}
+% \term{declaration} in the fourth line.  Consequently, that \term{call} to \funref{+}
+% may be optimized into a \term{call} to an \term{implementation-dependent} 
+% \term{fixnum}-only arithmetic operator.  Further, the \term{call} to \funref{+}
+% in the seventh line may be similarly optimized because the compiler can prove that
+% the \f{x} in that line has the same \term{value}.
+% 
+% \endissue{DECLARATION-SCOPE:NO-HOISTING}
+
+\issue{DECLARATION-SCOPE:NO-HOISTING}
+\issue{WITH-ADDED-METHODS:DELETE}
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+The \term{scope} of a \term{bound declaration} is the same as the
+%% Per X3J13. -kmp 5-Oct-93
+%\term{scope}
+\term{lexical scope}
+of the \term{binding} to which it applies;
+%% Added per X3J13. -kmp 5-Oct-93
+for \term{special variables},
+this means the \term{scope} that the \term{binding} 
+would have had had it been a \term{lexical binding}.
+
+Unless explicitly stated otherwise, the \term{scope} of a 
+\term{free declaration} includes only the body \term{subforms} of 
+the \term{form} at whose head it appears, and no other \term{subforms}.
+The \term{scope} of \term{free declarations} specifically does not
+include \term{initialization forms} for \term{bindings} established
+by the \term{form} containing the \term{declarations}.
+
+Some \term{iteration forms} include step, end-test, or result 
+\term{subforms} that are also included in the \term{scope}
+of \term{declarations} that appear in the \term{iteration form}.
+Specifically, the \term{iteration forms} and \term{subforms} involved
+are:
+
+\beginlist
+\item{\bull} \macref{do}, \macref{do*}:  
+  \param{step-forms}, \param{end-test-form}, and \param{result-forms}.
+\item{\bull} \macref{dolist}, \macref{dotimes}:
+  \param{result-form}
+\item{\bull} \macref{do-all-symbols}, \macref{do-external-symbols}, \macref{do-symbols}:
+  \param{result-form}
+\endlist
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\endissue{WITH-ADDED-METHODS:DELETE}
+
+\beginsubsubsection{Examples of Declaration Scope}
+
+Here is an example illustrating the \term{scope} of \term{bound declarations}.
+
+\code
+ (let ((x 1))                ;[1] 1st occurrence of x
+   (declare (special x))     ;[2] 2nd occurrence of x
+   (let ((x 2))              ;[3] 3rd occurrence of x
+     (let ((old-x x)         ;[4] 4th occurrence of x
+           (x 3))            ;[5] 5th occurrence of x
+       (declare (special x)) ;[6] 6th occurrence of x
+       (list old-x x))))     ;[7] 7th occurrence of x
+\EV (2 3)
+\endcode
+
+The first occurrence of \f{x} \term{establishes} a \term{dynamic binding}
+of \f{x} because of the \declref{special} \term{declaration} for \f{x}
+in the second line.  The third occurrence of \f{x} \term{establishes} a
+\term{lexical binding} of \f{x} (because there is no \declref{special}
+\term{declaration} in the corresponding \macref{let} \term{form}).
+The fourth occurrence of \f{x} \term{x} is a reference to the
+\term{lexical binding} of \f{x} established in the third line.
+The fifth occurrence of \f{x} \term{establishes} a \term{dynamic binding}
+of \term{x} for the body of the \macref{let} \term{form} that begins on
+that line because of the \declref{special} \term{declaration} for \f{x}
+in the sixth line. The reference to \f{x} in the fourth line is not
+affected by the \declref{special} \term{declaration} in the sixth line 
+because that reference is not within the ``would-be \term{lexical scope}''
+of the \term{variable} \f{x} in the fifth line.  The reference to \f{x}
+in the seventh line is a reference to the \term{dynamic binding} of \term{x}
+\term{established} in the fifth line.
+
+
+Here is another example, to illustrate the \term{scope} of a
+\term{free declaration}.  In the following:
+
+\code
+ (lambda (&optional (x (foo 1))) ;[1]
+   (declare (notinline foo))     ;[2]
+   (foo x))                      ;[3]
+\endcode
+
+the \term{call} to \f{foo} in the first line might be 
+compiled inline even though the \term{call} to \f{foo} in
+the third line must not be.  This is because
+the \declref{notinline} \term{declaration}
+for \f{foo} in the second line applies only to the body on the
+third line.  In order to suppress inlining for both \term{calls}, 
+one might write:
+
+\code
+ (locally (declare (notinline foo)) ;[1]
+   (lambda (&optional (x (foo 1)))  ;[2]
+     (foo x)))                      ;[3]
+\endcode
+
+or, alternatively:
+
+\code
+ (lambda (&optional                               ;[1]
+            (x (locally (declare (notinline foo)) ;[2]
+                 (foo 1))))                       ;[3]
+   (declare (notinline foo))                      ;[4]
+   (foo x))                                       ;[5]
+\endcode
+
+
+Finally, here is an example that shows the \term{scope} of
+\term{declarations} in an \term{iteration form}.
+
+\code
+ (let ((x  1))                     ;[1]
+   (declare (special x))           ;[2]
+     (let ((x 2))                  ;[3]
+       (dotimes (i x x)            ;[4]
+         (declare (special x)))))  ;[5]
+\EV 1
+\endcode
+
+In this example, the first reference to \f{x} on the fourth line is to
+the \term{lexical binding} of \f{x} established on the third line.
+However, the second occurrence of \f{x} on the fourth line lies within
+the \term{scope} of the \term{free declaration} on the fifth line
+(because this is the \param{result-form} of the \macref{dotimes})
+and therefore refers to the \term{dynamic binding} of \f{x}.
+\endissue{DECLARATION-SCOPE:NO-HOISTING}
+
+\endsubsubsection%{Examples of Declaration Scope}
+
+\endSubsection%{Declaration Scope}

concept-definitions.tex

@@ -0,0 +1,1401 @@
+%-*- Mode: TeX -*-
+
+%%Definitions
+This section contains notational conventions and definitions of terms
+used in this manual.
+
+\beginsubSection{Notational Conventions}\idxtext{notation}
+
+The following notational conventions are used throughout this document.
+
+%========================================
+\beginsubsubsection{Font Key}\idxtext{font key}
+
+Fonts are used in this document to convey information.
+
+\beginlist
+
+\itemitem{\term{name}} 
+
+Denotes a formal term whose meaning is defined in the Glossary.
+When this font is used, the Glossary definition takes precedence 
+over normal English usage.
+
+Sometimes a glossary term appears subscripted, 
+as in ``\term{whitespace}\meaning{2}.''  
+Such a notation selects one particular Glossary definition out of several,
+in this case the second.
+The subscript notation for Glossary terms is generally used where the
+context might be insufficient to disambiguate among the available definitions.
+
+\itemitem{\newterm{name}} 
+
+Denotes the introduction of a formal term locally to the current text.
+There is still a corresponding glossary entry, and is formally equivalent
+to a use of ``\term{name},'' but the hope is that making such uses 
+conspicuous will save the reader a trip to the glossary in some cases.
+
+\itemitem{\misc{name}}
+                           
+Denotes a symbol in \thepackage{common-lisp}.
+For information about \term{case} conventions,
+\seesection\CaseInSymbols.
+
+\itemitem{\f{name}} 
+
+Denotes a sample \term{name} or piece of \term{code} that a programmer
+might write in \clisp.
+
+This font is also used for certain \term{standardized} names that are not
+names of \term{external symbols} of \thepackage{common-lisp}, 
+such as \term{keywords}\meaning{1},
+        \term{package} \term{names},
+    and \term{loop keywords}.
+
+\itemitem{\param{name}} 
+
+Denotes the name of a \term{parameter} or \term{value}.
+
+In some situations the notation ``\metaparam{name}'' (\ie the same font,
+but with surrounding ``angle brackets'') is used instead in order to
+provide better visual separation from surrounding characters.  These
+``angle brackets'' are metasyntactic, and never actually appear in program
+input or output.
+
+\endlist
+
+\endsubsubsection%{Font Key}
+%========================================
+\beginsubsubsection{Modified BNF Syntax}\idxtext{bnf key}
+\DefineSection{ModifiedBNF}
+
+This specification uses an extended Backus Normal Form (BNF) to
+describe the syntax of \clisp\ \term{macro forms} and \term{special forms}.
+This section discusses the syntax of BNF expressions.
+
+\beginsubsubsubsection{Splicing in Modified BNF Syntax}
+
+The primary extension used is the following:
+
+$$\hbox{\interleave{$O$}}$$
+
+An expression of this form appears whenever a list of elements is
+to be spliced into a larger structure and the elements can appear in
+any order. The symbol $O$ represents a description of the syntax of
+some number of syntactic elements to be spliced; that description must
+be of the form
+
+$$O\sub 1\ \vert\ \ldots\ \vert\ O\sub l$$
+
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+\noindent where each $O\sub i$ can be of the form $S$ or of
+the form \star{$S$} or of the form \one{$S$}.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+The expression \interleave{$O$} means that a list of the form
+
+$$(O\sub{i\sub 1}\ldots O\sub{i\sub j})\quad 1\leq j$$
+
+\noindent is spliced into the enclosing expression,
+such that if $n \neq m$ and $1\leq n,m\leq j$,
+then either $O\sub{i\sub n}\neq O\sub{i\sub m}$
+         or $O\sub{i\sub n} = O\sub{i\sub m} = Q\sub{k}$, 
+where for some $1\leq k \leq n$, $O\sub{k}$ is of the form \star{$Q\sub{k}$}.
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+%Added to accomodate new LOOP BNF. -kmp 1-May-93
+Furthermore, for each $O\sub{i\sub n}$ that is of the form \one{$Q\sub{k}$},
+that element is required to appear somewhere in the list to be spliced.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+
+For example, the expression
+
+\f{(x \interleave{A | \star{B} | C} y)}
+
+\noindent means that at most one {\tt A}, any number of {\tt B}'s, and
+at most one {\tt C} can occur in any order.
+It is a description of any of these:
+
+\code
+ (x y)
+ (x B A C y)
+ (x A B B B B B C y)
+ (x C B A B B B y)
+\endcode
+
+\noindent but not any of these:
+
+\code
+ (x B B A A C C y)
+ (x C B C y)
+\endcode
+
+\noindent In the first case, both {\tt A} and {\tt C} appear too often,
+and in the second case {\tt C} appears too often.
+
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+% I added this notation to make the LOOP bvl easier to specify. -kmp 29-Apr-93
+
+The notation \plus{\interleave{$O\sub1$ | $O\sub2$ | $\ldots$}} 
+adds the additional restriction that at least one item from among the possible
+choices must be used.  For example:
+
+\f{(x \plus{\interleave{A | \star{B} | C}} y)}
+
+\noindent means that at most one {\tt A}, any number of {\tt B}'s, and
+at most one {\tt C} can occur in any order, but that in any case at least
+one of these options must be selected.
+It is a description of any of these:
+
+\code
+ (x B y)
+ (x B A C y)
+ (x A B B B B B C y)
+ (x C B A B B B y)
+\endcode
+
+\noindent but not any of these:
+
+\code
+ (x y)
+ (x B B A A C C y)
+ (x C B C y)
+\endcode
+
+\noindent In the first case, no item was used;
+in the second case, both {\tt A} and {\tt C} appear too often;
+and in the third case {\tt C} appears too often.
+
+Also, the expression:
+
+\f{(x \interleave{\one{A} | \one{B} | C} y)}
+
+\noindent can generate exactly these and no others:
+
+\code
+ (x A B C y)
+ (x A C B y)
+ (x A B y)
+ (x B A C y)
+ (x B C A y)
+ (x B A y)
+ (x C A B y)
+ (x C B A y)
+\endcode
+
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+
+\endsubsubsubsection%{Splicing in Modified BNF Syntax}
+
+\beginsubsubsubsection{Indirection in Modified BNF Syntax}
+
+An indirection extension is introduced in order to make this
+new syntax more readable:
+
+$$\hbox{\down{O}}$$
+
+\noindent If \param{O} is a non-terminal symbol, the right-hand side
+of its definition is substituted for the entire expression 
+\down{O}.  For example, the following BNF is equivalent to
+the BNF in the previous example:
+
+\f{(x \interleave{\down{O}} y)}
+\Vskip 1pc!
+\auxbnf{O}{\f{A} | \star{\f{B}} | \f{C}}
+\Vskip 1pc!
+
+\endsubsubsubsection%{Indirection in Modified BNF Syntax}
+
+\beginsubsubsubsection{Additional Uses for Indirect Definitions in Modified BNF Syntax}
+
+In some cases, an auxiliary definition in the BNF might appear to be unused
+within the BNF, but might still be useful elsewhere.  For example, consider the
+following definitions:
+
+\DefmacWithValues case
+		  {keyform  \stardown{normal-clause} \brac{\down{otherwise-clause}}}
+		  {\starparam{result}}
+\DefmacWithValues ccase
+		  {keyplace \stardown{normal-clause}}
+		  {\starparam{result}}
+\DefmacWithValues ecase
+		  {keyform  \stardown{normal-clause}}
+		  {\starparam{result}}
+
+\auxbnf{normal-clause}{\paren{keys \starparam{form}}}
+\auxbnf{otherwise-clause}{\paren{\curly{otherwise | t} \starparam{form}}}
+\auxbnf{clause}{normal-clause | otherwise-clause}
+\Vskip 1pc!
+
+Here the term ``\param{clause}'' might appear to be ``dead'' in that it
+is not used in the BNF.  However, the purpose of the BNF is not just to guide parsing,
+but also to define useful terms for reference in the descriptive text which follows.
+As such, the term ``\param{clause}'' might appear in text that follows,
+as shorthand for ``\param{normal-clause} or \param{otherwise-clause}.''
+
+\endsubsubsubsection%{Additional Uses for Indirect Definitions in Modified BNF Syntax}
+
+\endsubsubsection%{Modified BNF Syntax}
+%========================================
+\beginsubsubsection{Special Symbols}
+
+The special symbols described here are used as a notational convenience
+within this document, and are part of neither the \clisp\ language nor
+its environment.
+
+\beginlist
+\itemitem{\EV}
+
+This indicates evaluation.
+For example:
+
+\code
+ (+ 4 5) \EV 9 
+\endcode
+This means that the result of
+evaluating the \term{form} \f{(+ 4 5)} is \f{9}.
+                                                                 
+%!!! Are the first two of these notations still used?  Maybe remove...
+If a \term{form} returns \term{multiple values}, those values might
+be shown separated by spaces, line breaks, or commas.
+For example:
+
+\code
+ (truncate 7 5)
+\EV 1 2
+ (truncate 7 5) 
+\EV 1
+   2
+ (truncate 7 5)
+\EV 1, 2
+\endcode
+
+Each of the above three examples is equivalent, and specifies
+that \f{(truncate 7 5)} returns two values, which are \f{1} and \f{2}.
+
+Some \term{conforming implementations} actually type an arrow (or some
+other indicator) before showing return values, while others do not.
+
+\itemitem{\OV}
+
+The notation ``{\OV}'' is used to denote one of several possible
+alternate results.  The example
+
+\code
+ (char-name #\\a)
+\EV NIL
+\OV "LOWERCASE-a"
+\OV "Small-A"
+\OV "LA01"
+\endcode
+
+indicates that \nil, \f{"LOWERCASE-a"}, \f{"Small-A"}, \f{"LA01"} are
+among the possible results of \f{(char-name \#\\a)}---each with equal preference.
+Unless explicitly specified otherwise, it should not be assumed that the set of possible 
+results shown is exhaustive.
+Formally, the above example is equivalent to
+
+\code
+ (char-name #\\a) \EV \term{implementation-dependent}
+\endcode
+
+but it is intended to provide additional information to illustrate some
+of the ways in which it is permitted for implementations to diverge.
+
+\itemitem{\NV}
+
+The notation ``{\NV}'' is used to denote a result which is not possible.
+This might be used, for example, in order to emphasize a situation where
+some anticipated misconception might lead the reader to falsely believe
+that the result might be possible.  For example,
+
+\code
+ (function-lambda-expression 
+    (funcall #'(lambda (x) #'(lambda () x)) nil))
+\EV NIL, \term{true}, NIL
+\OV (LAMBDA () X), \term{true}, NIL
+\NV NIL, \term{false}, NIL
+\NV (LAMBDA () X), \term{false}, NIL
+\endcode
+
+%% 1.2.3 3
+\itemitem{\EQ} 
+
+This indicates code equivalence. For example:
+
+\code
+ (gcd x (gcd y z)) \EQ (gcd (gcd x y) z)
+\endcode
+This means that the results and observable side-effects of evaluating
+the \term{form}
+\hbox{\f{(gcd x (gcd y z))} } are always the same as the results
+and observable side-effects of
+\hbox{\f{(gcd (gcd x y) z)} } for any 
+\f{x}, \f{y}, and \f{z}.
+                      
+%!!! Need to expand on the definition of observable side-effects.
+
+\itemitem{{\OUT}}
+
+\clisp\ specifies input and output with respect to a non-interactive stream model.
+The specific details of how interactive input and output are mapped onto that
+non-interactive model are \term{implementation-defined}.
+
+For example, \term{conforming implementations} are permitted to differ in issues 
+of how interactive input is terminated.  For example, \thefunction{read}
+terminates when the final delimiter is typed on a non-interactive stream.
+In some \term{implementations}, an interactive call to \funref{read} returns
+as soon as the final delimiter is typed, even if that delimiter is not a \term{newline}.
+In other \term{implementations}, a final \term{newline} is always required.
+In still other \term{implementations}, there might be a command which ``activates''
+a buffer full of input without the command itself being visible on the program's
+input stream.
+
+In the examples in this document, the notation ``{\OUT}'' precedes 
+lines where interactive input and output occurs.  Within such a scenario,
+``\IN{this notation}'' notates user input.
+
+For example, the notation
+
+\code
+ (+ 1 (print (+ (sqrt (read)) (sqrt (read)))))
+\OUT \IN{9 16 }
+\OUT 7
+\EV 8
+\endcode
+
+shows an interaction in which
+  ``\f{(+ 1 (print (+ (sqrt (read)) (sqrt (read)))))}''
+    is a \term{form} to be \term{evaluated},
+  ``\f{9 16 }'' is interactive input,
+  ``\f{7}'' is interactive output, and 
+  ``\f{8}'' is the \term{value} \term{yielded} from the \term{evaluation}.
+
+The use of this notation is intended to disguise small differences 
+in interactive input and output behavior between \term{implementations}.
+
+Sometimes, the non-interactive stream model calls for a \term{newline}.
+How that \term{newline} character is interactively entered is an 
+\term{implementation-defined} detail of the user interface, but in that
+case, either the notation ``\NewlineChar'' or ``\CRLF'' might be used.
+
+\code
+ (progn (format t "~&Who? ") (read-line))
+\OUT Who? \IN{Fred, Mary, and Sally\CRLF}
+\EV "Fred, Mary, and Sally", \term{false}
+\endcode
+
+\endlist
+
+\endsubsubsection%{Special Symbols}
+%========================================
+\beginsubsubsection{Objects with Multiple Notations}
+
+Some \term{objects} in \clisp\ can be notated in more than one way.
+In such situations, the choice of which notation to use is technically arbitrary,
+but conventions may exist which convey a ``point of view'' or ``sense of intent.''
+
+%----------------------------------------
+\beginsubsubsubsection{Case in Symbols}\idxtext{case in symbol names}
+\DefineSection{CaseInSymbols}
+
+While \term{case} is significant in the process of \term{interning} a \term{symbol},
+the \term{Lisp reader}, by default, attempts to canonicalize the case of a
+\term{symbol} prior to interning; \seesection\ReadtableCaseReadEffect.
+As such, case in \term{symbols} is not, by default, significant.
+Throughout this document, except as explicitly noted otherwise,
+the case in which a \term{symbol} appears is not significant; 
+that is, \f{HELLO}, \f{Hello}, \f{hElLo}, and \f{hello} are
+all equivalent ways to denote a symbol whose name is \f{"HELLO"}.
+
+The characters \term{backslash} and \term{vertical-bar} are used to explicitly
+quote the \term{case} and other parsing-related 
+%was "attributes" but now that attributes has formaly meaning, 
+%not sure if it's too limiting here, so use a general term. -kmp 26-Jan-92
+aspects
+of characters.  As such,
+the notations \f{|hello|} and \f{\\h\\e\\l\\l\\o} are equivalent ways
+to refer to a symbol whose name is \f{"hello"}, and which is \term{distinct} from
+any symbol whose name is \f{"HELLO"}.
+
+The \term{symbols} that correspond to \clisp\ \term{defined names}
+have \term{uppercase} names even though their names generally appear
+in \term{lowercase} in this document.
+
+\endsubsubsubsection%{Case in Symbols}
+%----------------------------------------
+\beginsubsubsubsection{Numbers}
+
+%% 1.2.1 1
+Although \clisp\ provides a variety of ways for programs to manipulate the
+input and output radix for rational numbers, all numbers in this document
+are in decimal notation unless explicitly noted otherwise.
+
+\endsubsubsubsection%{Numbers}
+%----------------------------------------
+\beginsubsubsubsection{Use of the Dot Character}
+
+%% 1.2.5 9
+The dot appearing by itself in an \term{expression} such as
+
+\f{(\param{item1} \param{item2} {\dot} \param{tail})}
+
+means that \param{tail} represents a \term{list} of \term{objects} 
+at the end of a list.  For example,
+
+\f{(A B C {\dot} (D E F))}
+
+is notationally equivalent to:
+
+\f{(A B C D E F)}
+
+Although \term{dot} is a valid constituent character in a symbol, no 
+\term{standardized} \term{symbols} contain the character \term{dot},
+so a period that follows a reference to a \term{symbol} at the end of
+a sentence in this document should always be interpreted as a period
+and never as part of the \term{symbol}'s \term{name}.
+For example, within this document, a sentence such as
+ ``This sample sentence refers to the symbol \funref{car}.'' 
+% confusion about fonts below made more consistent w/previous section
+% on symbol names  --sjl 13 Mar 1992
+%refers to a function named ``\funref{car}'' with three letters in its name,
+%and never to a four-letter symbol ``\funref{car.}''
+refers to a symbol whose name is \f{"CAR"} (with three letters),
+and never to a four-letter symbol \f{"CAR."}
+
+\endsubsubsubsection%{Use of the Dot Character}
+%----------------------------------------
+\beginsubsubsubsection{NIL}\idxterm{nil}\idxterm{()}\idxref{nil}
+
+\nil\ has a variety of meanings.
+It is a \term{symbol} in \thepackage{common-lisp} with the \term{name} \f{"NIL"},
+it is \term{boolean} (and \term{generalized boolean}) \term{false},
+it is the \term{empty list},
+and it is the \term{name} of the \term{empty type} (a \term{subtype} of all \term{types}).
+
+Within \clisp, \nil\ can be notated interchangeably as either \f{NIL} or \f{()}.
+By convention, the choice of notation offers a hint as to which of its many
+roles it is playing.
+
+\showthree{Notations for NIL}{
+\hfil\b{For Evaluation?}&\hfil\b{Notation}\hfil&\b{Typically Implied Role}\cr
+\noalign{\vskip 2pt\hrule\vskip 2pt}
+Yes&\f{nil}&use as a \term{boolean}.\cr
+Yes&\f{'nil}&use as a \term{symbol}.\cr
+Yes&\f{'()}&use as an \term{empty list}\cr
+No&\f{nil}&use as a \term{symbol} or \term{boolean}.\cr
+No&\f{()}&use as an \term{empty list}.\cr
+}
+
+Within this document only, \nil\ is also sometimes notated as \term{false} to
+emphasize its role as a \term{boolean}.
+
+For example:
+
+\code
+ (print ())                          ;avoided
+ (defun three nil 3)                 ;avoided 
+ '(nil nil)                          ;list of two symbols
+ '(() ())                            ;list of empty lists
+ (defun three () 3)                  ;Emphasize empty parameter list.
+ (append '() '()) \EV ()              ;Emphasize use of empty lists
+ (not nil) \EV \term{true}                   ;Emphasize use as Boolean false
+ (get 'nil 'color)                   ;Emphasize use as a symbol
+\endcode
+
+A \term{function} is sometimes said to ``be \term{false}'' or ``be \term{true}''
+in some circumstance.
+Since no \term{function} object can be the same as \nil\ 
+and all \term{function} \term{objects} represent \term{true} when viewed as \term{booleans},
+it would be meaningless to say that the \term{function} was literally \term{false} 
+and uninteresting to say that it was literally \term{true}.
+Instead, these phrases are just traditional alternative ways of saying that the
+\term{function} ``returns \term{false}'' or ``returns \term{true},'' respectively.
+
+\endsubsubsubsection%{NIL}
+
+\endsubsubsection%{Objects with Multiple Notations}
+
+%========================================
+\beginsubsubsection{Designators}
+\DefineSection{Designators}
+
+A \newterm{designator} is an \term{object} that denotes another \term{object}.
+
+%!!! RPG: Not clear.  Rewrite.
+Where a \term{parameter} of an \term{operator} is described as a \term{designator},
+the description of the \term{operator} is written in a way that assumes that
+the value of the \term{parameter} is the denoted \term{object};
+that is, that the \term{parameter} is already of the denoted \term{type}.
+(The specific nature of the \term{object} denoted by
+   a ``\metavar{type} \term{designator}''
+or a ``\term{designator} for a \metavar{type}'' 
+can be found in the Glossary entry for ``\metavar{type} \term{designator}.'')
+
+For example, ``\nil'' and ``\thevalueof{*standard-output*}'' are operationally
+indistinguishable as \term{stream designators}.  Similarly, 
+the \term{symbol} \f{foo} and the \term{string} \f{"FOO"} 
+are operationally indistinguishable as \term{string designators}.  
+
+Except as otherwise noted, in a situation where the denoted \term{object} 
+might be used multiple times, it is \term{implementation-dependent}
+whether the \term{object} is coerced only once or whether the coercion occurs
+each time the \term{object} must be used.
+
+For example, \funref{mapcar} receives a \term{function designator} as an argument,
+and its description is written as if this were simply a function.  In fact, it
+is \term{implementation-dependent} whether the \term{function designator} is 
+coerced right away or whether it is carried around internally in the form that
+it was given as an \term{argument} and re-coerced each time it is needed.  In most
+cases, \term{conforming programs} cannot detect the distinction, but there are some 
+pathological situations (particularly those involving self-redefining or 
+mutually-redefining functions) which do conform and which can detect this difference.
+The following program is a \term{conforming program}, but might or might not have
+portably correct results, depending on whether its correctness depends on one or
+the other of the results:
+
+\code
+ (defun add-some (x) 
+   (defun add-some (x) (+ x 2))
+   (+ x 1)) \EV ADD-SOME
+ (mapcar 'add-some '(1 2 3 4))
+\EV (2 3 4 5)
+\OV (2 4 5 6)
+\endcode
+
+In a few rare situations, there may be a need in a dictionary entry
+to refer to the \term{object} that was the original \term{designator}
+for a \term{parameter}.
+Since naming the \term{parameter} would refer to the denoted \term{object},
+the phrase ``the \metavar{parameter-name} \term{designator}'' 
+can be used to refer to the \term{designator} which was the \term{argument}
+from which the \term{value} of \metavar{parameter-name} was computed.
+
+\endsubsubsection%{Designators}
+%========================================
+\beginsubsubsection{Nonsense Words}\idxcode{foo}\idxcode{bar}\idxcode{baz}\idxcode{quux}
+
+When a word having no pre-attached semantics is required (\eg in an
+example), it is common in the Lisp community to use one of the words
+``foo,'' ``bar,'' ``baz,'' and ``quux.''  For example, in
+
+\code
+ (defun foo (x) (+ x 1))
+\endcode
+the use of the name \f{foo} is just a shorthand way of saying 
+``please substitute your favorite name here.''
+
+These nonsense words have gained such prevalance of usage, that it is
+commonplace for newcomers to the community to begin to wonder if there
+is an attached semantics which they are overlooking---there is not.
+
+\endsubsubsection%{Nonsense Words}
+
+\endsubSection%{Notational Conventions}
+
+%!!! Barmar thinks \secref\InterpretingDictionaryEntries
+%    should move to someplace around here.
+
+\beginsubSection{Error Terminology}\idxtext{error terminology}
+\DefineSection{ErrorTerms}
+
+Situations in which errors might, should, or must be signaled are described
+in the standard.  The wording used to describe such situations is intended
+to have precise meaning. The following list is a glossary of those meanings.
+
+\beginlist
+\itemitem{\b{Safe code}}\idxterm{safe}
+
+This is \term{code} processed with the \declref{safety} optimization 
+at its highest setting (\f{3}).  \declref{safety} is a lexical property
+of code.  The phrase ``the function \f{F} should signal an error'' 
+means that if \f{F} is invoked from code processed with the highest
+\declref{safety} optimization, an error is signaled.
+It is \term{implementation-dependent} whether \f{F} or the calling 
+code signals the error.
+
+\itemitem{\b{Unsafe code}}\idxterm{unsafe}
+
+This is code processed with lower safety levels.
+		        
+Unsafe code might do error checking.  Implementations are permitted to
+treat all code as safe code all the time.
+                        
+%% 1.2.4 6
+%% 1.2.4 9
+%% 1.2.4 10
+\itemitem{\b{An error is signaled}}%
+\idxterm{signal}\idxtext{is signaled}\idxtext{must signal}
+
+This means that an error is signaled in both safe and unsafe code.
+\term{Conforming code} may rely on the fact that the error is signaled
+in both safe and unsafe code.  Every implementation is required to
+detect the error in both safe and unsafe code. For example, ``an error
+is signaled if \funref{unexport} is given a \term{symbol}
+not \term{accessible} in the \term{current package}.''
+
+If an explicit error type is not specified, the default is \typeref{error}.
+
+\itemitem{\b{An error should be signaled}}%
+\idxterm{signal}\idxtext{should signal}
+
+This means that an error is signaled in safe code, and an error
+might be signaled in unsafe code.  \term{Conforming code} may rely on the
+fact that the error is signaled in safe code.  Every
+implementation is required to detect the error at least in safe code.
+When the error is not signaled, the ``consequences are undefined''
+(see below).  For example, ``\funref{+} should signal an error \oftype{type-error}
+if any argument is not \oftype{number}.''
+
+\itemitem{\b{Should be prepared to signal an error}}%
+\idxterm{signal}\idxtext{prepared to signal}
+
+This is similar to ``should be signaled'' except that it does not
+imply that `extra effort' has to be taken on the part of an \term{operator}
+to discover an erroneous situation if the normal action of that \term{operator}
+can be performed successfully with only `lazy' checking.
+An \term{implementation} is always permitted to signal an error,
+but even in \term{safe} \term{code}, it is only required to signal the error
+when failing to signal it might lead to incorrect results.
+In \term{unsafe} \term{code}, the consequences are undefined.
+
+For example, defining that 
+ ``\funref{find} should be prepared to signal an error \oftype{type-error}
+   if its second \term{argument} is not a \term{proper list}''
+does not imply that an error is always signaled.  The \term{form}
+
+\code
+ (find 'a '(a b . c))
+\endcode
+
+must either signal an error \oftype{type-error} in \term{safe} \term{code},
+else return \f{A}.
+In \term{unsafe} \term{code}, the consequences are undefined.
+By contrast,
+
+\code
+ (find 'd '(a b . c))
+\endcode
+
+must signal an error \oftype{type-error} in \term{safe} \term{code}.
+In \term{unsafe} \term{code}, the consequences are undefined.
+Also,
+
+\code
+ (find 'd '#1=(a b . #1#))
+\endcode
+
+in \term{safe code}
+   might return \nil\ (as an \term{implementation-defined} extension),
+   might never return,
+or might signal an error \oftype{type-error}.
+In \term{unsafe} \term{code}, the consequences are undefined.
+
+Typically, the ``should be prepared to signal'' terminology is used in
+type checking situations where there are efficiency considerations that
+make it impractical to detect errors that are not relevant to the
+correct operation of the \term{operator}.
+
+\itemitem{\b{The consequences are unspecified}}%
+\idxtext{consequences}\idxtext{unspecified consequences}
+
+This means that the consequences are unpredictable but harmless.
+Implementations are permitted to specify the consequences of this
+situation. No \term{conforming code} may depend on the results or effects of
+this situation, and all \term{conforming code} is required to treat the
+results and effects of this situation as unpredictable but harmless.
+For example, ``if the second argument to \funref{shared-initialize}
+specifies a name that does not correspond to any \term{slots}
+\term{accessible} in the \term{object}, the results are unspecified.''
+
+%% 1.2.4 4
+\itemitem{\b{The consequences are undefined}}%
+\idxtext{consequences}\idxtext{undefined consequences}
+
+This means that the consequences are unpredictable. The consequences
+may range from harmless to fatal.  No \term{conforming code} may depend on
+the results or effects. \term{Conforming code} must treat the consequences as
+unpredictable.  In places where the words ``must,'' ``must not,'' or
+``may not'' are used, then ``the consequences are undefined'' if the
+stated requirement is not met and no specific consequence is
+explicitly stated.  An implementation is permitted to signal an error
+in this case.
+
+For example: ``Once a name has been declared by \macref{defconstant}
+to be constant, any further assignment or binding of that
+variable has undefined consequences.''
+                                               
+\itemitem{\b{An error might be signaled}}%
+\idxterm{signal}\idxtext{might signal}
+
+This means that the situation has undefined consequences;
+however, if an error is signaled, it is of the specified \term{type}.
+For example, ``\funref{open} might signal an error \oftype{file-error}.''
+                           
+\itemitem{\b{The return values are unspecified}}%
+\idxtext{unspecified values}
+
+This means that only the number and nature of the return values of a
+\term{form} are not specified.  However, the issue of whether or not
+any side-effects or transfer of control occurs is still well-specified.
+
+A program can be well-specified even if it uses a function whose
+returns values are unspecified.  For example, even if the return
+values of some function \f{F} are unspecified, an expression such as
+\f{(length (list (F)))} is still well-specified because it does not
+rely on any particular aspect of the value or values returned by \f{F}.
+
+\itemitem{\b{Implementations may be extended to cover this situation}}%
+\idxtext{extensions}
+
+This means that the \term{situation} has undefined consequences;
+however, a \term{conforming implementation} is free to treat
+the situation in a more specific way.  
+For example, an \term{implementation} might define 
+    that      an error is signaled,
+ or that      an error should be signaled,
+ or even that a certain well-defined non-error behavior occurs.
+
+%% 1.2.4 5
+No \term{conforming code} may depend on the consequences of such a \term{situation};
+all \term{conforming code} must treat the consequences of the situation
+as undefined. \term{Implementations} are required to document how the
+situation is treated.
+
+For example, ``implementations may be extended to define other type
+specifiers to have a corresponding \term{class}.''
+
+\itemitem{\b{Implementations are free to extend the syntax}}%
+\idxtext{extensions}
+
+This means that in this situation implementations are permitted to
+define unambiguous extensions to the syntax of the \term{form} being
+described.  No \term{conforming code} may depend on this extension.
+Implementations are required to document each such extension. All
+\term{conforming code} is required to treat the syntax as meaningless. The
+standard might disallow certain extensions while allowing others. For
+example, ``no implementation is free to extend the syntax of
+\macref{defclass}.''
+                          
+\issue{ERROR-TERMINOLOGY-WARNING:MIGHT}
+\itemitem{\b{A warning might be issued}}%
+\idxtext{warning}
+         
+This means that \term{implementations} are encouraged to issue a warning
+if the context is appropriate (\eg when compiling).  However, a
+\term{conforming implementation} is not required to issue a warning.
+\endissue{ERROR-TERMINOLOGY-WARNING:MIGHT}
+
+% This means that a warning might be issued, as described in \funref{warn},
+% in both safe and unsafe code when the situation is detected.
+% \term{Conforming code} can rely on the fact that a warning will be issued in
+% both safe and unsafe code when the situation is detected.  Every
+% implementation is required to detect this situation in both safe and
+% unsafe code when the situation is detected. The presence of a warning
+% will in no way alter the value returned by the \term{form} that
+% caused the situation to occur. For example, ``a warning is issued if a
+% declaration specifier is not one of those defined in the description
+% of \misc{declare} and has not been declared in a \declref{declaration}
+% declaration.''
+%                        
+% \itemitem{\b{A warning should be issued}}
+% 
+% This means that a warning might be issued. \term{Conforming code} must not
+% rely on the fact that a warning will be issued. If the situation is
+% detected, a warning might be issued.  The presence of a warning will
+% in no way alter the value returned by the \term{form} that caused the
+% situation to occur. For example, ``a warning should be issued if a
+% variable declared \declref{ignore} is ever referenced or is also declared
+% \declref{special}, or if a variable is lexical, never referenced, and not
+% declared \declref{ignore}.''
+
+\endlist
+
+\endsubSection%{Error Terminology}
+
+\beginsubsection{Sections Not Formally Part Of This Standard}
+\DefineSection{RemovableText}
+
+%% A lot of this seems to be just rationale.  Does it really need to
+%% be included here?  --sjl 13 Mar 92
+
+Front matter and back matter, such as the ``Table of Contents,'' 
+``Index,'' ``Figures,'' ``Credits,'' and ``Appendix'' are not considered formally 
+part of this standard, so that we retain the flexibility needed to update
+these sections even at the last minute without fear of needing a formal 
+vote to change those parts of the document.  These items are quite short 
+and very useful, however, and it is not recommended that they be removed 
+even in an abridged version of this document.
+
+Within the concept sections, subsections whose names begin with 
+the words ``Note'' or ``Notes'' or ``Example'' or ``Examples'' 
+are provided for illustration purposes only, and are not considered
+part of the standard.
+
+An attempt has been made to place these sections last in their parent section,
+so that they could be removed without disturbing the contiguous numbering of the 
+surrounding sections in order to produce a document of smaller size.
+
+Likewise, the ``Examples'' and ``Notes'' sections in a dictionary entry
+are not considered part of the standard and could be removed if necessary.
+
+Nevertheless, the examples provide important clarifications and consistency 
+checks for the rest of the material, and such abridging is not recommended
+unless absolutely unavoidable.
+
+\endsubsection%{Sections Not Formally Part Of This Standard}
+
+\beginsubSection{Interpreting Dictionary Entries}
+\DefineSection{InterpretingDictionaryEntries}
+
+The dictionary entry for each \term{defined name} is partitioned into
+sections.  Except as explicitly indicated otherwise below, each section
+is introduced by a label identifying that section.  The omission of a
+section implies that the section is either not applicable, or would
+provide no interesting information.
+
+This section defines the significance of each potential section in a
+dictionary entry.
+
+\beginsubsubsection{The ``Affected By'' Section of a Dictionary Entry}
+
+For an \term{operator}, anything that can affect the side effects of
+or \term{values} returned by the \term{operator}.
+
+For a \term{variable}, anything that can affect the \term{value} of the \term{variable}
+including \term{functions} that bind or assign it.
+
+\endsubsubsection%{The ``Affected By'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Arguments'' Section of a Dictionary Entry}
+
+This information describes the syntax information of entries such as those for
+\term{declarations} and special \term{expressions} which are never \term{evaluated}
+as \term{forms}, and so do not return \term{values}.
+
+\endsubsubsection%{The ``Arguments'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Arguments and Values'' Section of a Dictionary Entry}
+
+An English language description of what \term{arguments} the \term{operator} accepts
+and what \term{values} it returns, including information about defaults for \term{parameters}
+corresponding to omittable \term{arguments}
+(such as \term{optional parameters} and \term{keyword parameters}).
+For \term{special operators} and \term{macros},
+their \term{arguments} are not \term{evaluated} unless it is explicitly stated in their
+descriptions that they are \term{evaluated}.
+
+%% I added the first part of this sentence as editorial discretion 
+%% since I believe we strongly feel that this is not specified otherwise,
+%% but we want to avoid an unexpected conflict in case it is. -kmp 9-May-94
+Except as explicitly specified otherwise,
+%% Added per X3J13 at May 4-5, 1994 meeting.  -kmp 9-May-94
+the consequences are undefined if these type restrictions are violated.
+
+\endsubsubsection%{The ``Arguments and Values'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Binding Types Affected'' Section of a Dictionary Entry}
+
+This information alerts the reader to the kinds of \term{bindings} that might 
+potentially be affected by a declaration.  Whether in fact any particular such
+\term{binding} is actually affected is dependent on additional factors as well.
+See the ``Description'' section of the declaration in question for details.
+
+\endsubsubsection%{The ``Binding Types Affected'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Class Precedence List'' Section of a Dictionary Entry}
+
+This appears in the dictionary entry for a \term{class},
+and contains an ordered list of the \term{classes} defined 
+by \clisp\ that must be in the \term{class precedence list} of this \term{class}.
+
+It is permissible for other (\term{implementation-defined}) \term{classes}
+to appear in the \term{implementation}'s \term{class precedence list} for the \term{class}.
+
+It is permissible for 
+  either \typeref{standard-object}
+      or \typeref{structure-object}
+to appear in the \term{implementation}'s \term{class precedence list};
+for details, \seesection\TypeRelationships.
+
+Except as explicitly indicated otherwise somewhere in this specification,
+no additional \term{standardized} \term{classes} may appear in 
+the \term{implementation}'s \term{class precedence list}.
+
+By definition of the relationship between \term{classes} and \term{types},
+the \term{classes} listed in this section are also \term{supertypes} of 
+the \term{type} denoted by the \term{class}.
+
+\endsubsubsection%{The ``Class Precedence List'' Section of a Dictionary Entry}
+
+\beginsubsubsection{Dictionary Entries for Type Specifiers}
+\DefineSection{TypeSpecEntries}
+
+The \term{atomic type specifiers} are those \term{defined names} 
+listed in \figref\StandardizedAtomicTypeSpecs.
+Such dictionary entries are of kind 
+``Class,'' ``Condition Type,'' ``System Class,'' or ``Type.''
+A description of how to interpret 
+a \term{symbol} naming one of these \term{types} or \term{classes} 
+as an \term{atomic type specifier}
+is found in the ``Description'' section of such dictionary entries.
+
+The \term{compound type specifiers} are those \term{defined names} 
+listed in \figref\StandardizedCompoundTypeSpecNames.
+Such dictionary entries are of kind ``Class,'' ``System Class,''
+``Type,'' or ``Type Specifier.''
+A description of how to interpret as a \term{compound type specifier}
+a \term{list} whose \term{car} is such a \term{symbol}
+is found in the 
+     ``Compound Type Specifier Kind,''
+     ``Compound Type Specifier Syntax,''
+     ``Compound Type Specifier Arguments,''
+ and ``Compound Type Specifier Description''
+sections of such dictionary entries.
+
+\beginsubsubsubsection{The ``Compound Type Specifier Kind'' Section of a Dictionary Entry}
+
+An ``abbreviating'' \term{type specifier} is one that describes a \term{subtype}
+for which it is in principle possible to enumerate the \term{elements},
+but for which in practice it is impractical to do so.
+
+A ``specializing'' \term{type specifier} is one that describes a \term{subtype}
+by restricting the \term{type} of one or more components of the \term{type},
+such as \term{element type} or \term{complex part type}.
+
+A ``predicating'' \term{type specifier} is one that describes a \term{subtype}
+containing only those \term{objects} that satisfy a given \term{predicate}.
+
+A ``combining'' \term{type specifier} is one that describes a \term{subtype}
+in a compositional way, using combining operations (such as ``and,'' ``or,'' and
+``not'') on other \term{types}.
+
+\endsubsubsubsection%{The ``Compound Type Specifier Kind'' Section of a Dictionary Entry}
+
+\beginsubsubsubsection{The ``Compound Type Specifier Syntax'' Section of a Dictionary Entry}
+
+This information about a \term{type} describes the syntax of a 
+\term{compound type specifier} for that \term{type}.
+
+Whether or not the \term{type} is acceptable as an \term{atomic type specifier}
+is not represented here; \seesection\TypeSpecEntries.
+
+\endsubsubsubsection%{The ``Compound Type Specifier Syntax'' Section of a Dictionary Entry}
+
+\beginsubsubsubsection{The ``Compound Type Specifier Arguments'' Section of a Dictionary Entry}
+
+This information describes \term{type} information for the structures defined in
+the ``Compound Type Specifier Syntax'' section.
+
+\endsubsubsubsection%{The ``Compound Type Specifier Arguments'' Section of a Dictionary Entry}
+
+\beginsubsubsubsection{The ``Compound Type Specifier Description'' Section of a Dictionary Entry}
+
+This information describes the meaning of the structures defined in
+the ``Compound Type Specifier Syntax'' section.
+
+\endsubsubsubsection%{The ``Compound Type Specifier Description'' Section of a Dictionary Entry}
+
+\endsubsubsection%{Dictionary Entries for Type Specifiers}
+
+\beginsubsubsection{The ``Constant Value'' Section of a Dictionary Entry}
+
+This information describes the unchanging \term{type} and \term{value} of 
+a \term{constant variable}.
+
+\endsubsubsection%{The ``Constant Value'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Description'' Section of a Dictionary Entry}
+
+A summary of the \term{operator} and all intended aspects of the \term{operator}, 
+but does not necessarily include all the fields referenced below it 
+(``Side Effects,'' ``Exceptional Situations,'' \etc.)
+
+\endsubsubsection%{The ``Description'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Examples'' Section of a Dictionary Entry}
+
+Examples of use of the \term{operator}.
+These examples are not considered part of the standard;
+\seesection\RemovableText.
+
+\endsubsubsection%{The ``Examples'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Exceptional Situations'' Section of a Dictionary Entry}
+
+  Three kinds of information may appear here:
+\beginlist
+\item{\bull}
+Situations that are detected by the \term{function} and formally signaled.
+\item{\bull}
+Situations that are handled by the \term{function}.
+\item{\bull}
+Situations that may be detected by the \term{function}.
+\endlist
+This field does not include conditions that could
+be signaled by \term{functions} passed to and called by this \term{operator}
+as arguments or through dynamic variables, nor by executing subforms of this
+operator if it is a \term{macro} or \term{special operator}.
+
+\endsubsubsection%{The ``Exceptional Situations'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Initial Value'' Section of a Dictionary Entry}
+
+This information describes the initial \term{value} of a \term{dynamic variable}.
+Since this variable might change, see \term{type} restrictions in the ``Value Type'' section.
+
+\endsubsubsection%{The ``Initial Value'' Section of a Dictionary Entry}
+
+\issue{DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT}
+\beginsubsubsection{The ``Argument Precedence Order'' Section of a Dictionary Entry}
+
+%% Added italic font for "argument precedence order" per Boyer/Kaufmann/Moore #3.
+%% -kmp 9-May-94
+This information describes the \term{argument precedence order}.
+If it is omitted, the \term{argument precedence order} is the default (left to right).
+
+\endsubsubsection%{The ``Argument Precedence Order'' Section of a Dictionary Entry}
+\endissue{DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT}
+
+\beginsubsubsection{The ``Method Signature'' Section of a Dictionary Entry}
+
+The description of a \term{generic function} includes descriptions of the
+\term{methods} that are defined on that \term{generic function} by the standard.  
+A method signature is used to describe the \term{parameters} and 
+\term{parameter specializers} for each \term{method}. 
+\term{Methods} defined for the \term{generic function} must be of the form described
+by the \term{method} \term{signature}. 
+
+\Defmeth {F} {\paren{\param{x} \param{class}}
+	      \paren{\param{y} t}
+	      {\opt} \param{z} {\key} \param{k}}
+
+\noindent This \term{signature} indicates that this method on the \term{generic function}
+\b{F} has two \term{required parameters}:
+     \param{x}, which must be a \term{generalized instance} of the \term{class} \param{class};
+ and \param{y}, which can  be any \term{object} 
+       (\ie a \term{generalized instance} of the \term{class} \typeref{t}).
+In addition, there is an \term{optional parameter} \param{z} and a
+\term{keyword parameter} \param{k}.  This \term{signature} also indicates that this
+method on \f{F} is a \term{primary method} and has no \term{qualifiers}.
+
+For each \term{parameter}, the \term{argument} supplied must be in the
+intersection of the \term{type} specified in the description of the
+corresponding \term{generic function} and the \term{type} given in 
+the \term{signature} of some \term{method} (including not only those 
+\term{methods} defined in this specification, but also
+\term{implementation-defined} or user-defined \term{methods} in situations
+where the definition of such \term{methods} is permitted).
+
+\endsubsubsection%{The ``Method Signature'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Name'' Section of a Dictionary Entry}
+
+This section introduces the dictionary entry.  It is not explicitly labeled.
+It appears preceded and followed by a horizontal bar.
+
+In large print at left, the \term{defined name} appears; if more than one
+\term{defined name} is to be described by the entry, all such \term{names} 
+are shown separated by commas.
+
+In somewhat smaller italic print at right is an indication of what kind
+of dictionary entry this is.  Possible values are:
+
+% This list believed correct as of 23-Oct-91 -kmp
+\beginlist
+
+\itemitem{\i{Accessor}}
+
+This is an \term{accessor} \term{function}.
+
+\itemitem{\i{Class}}
+
+This is a \term{class}.
+
+\itemitem{\i{Condition Type}}
+
+This is a \subtypeof{condition}.
+% We don't need to constrain how implementations define condition types.
+% --sjl 13 Mar 92
+%\term{Condition types} are defined with
+%\macref{define-condition}, not \macref{defclass}.
+
+\itemitem{\i{Constant Variable}}
+
+This is a \term{constant variable}.
+
+\itemitem{\i{Declaration}}
+
+This is a \term{declaration identifier}.
+
+\itemitem{\i{Function}}
+
+This is a \term{function}.
+
+\itemitem{\i{Local Function}}
+
+This is a \term{function} that is defined only lexically within the scope of some
+other \term{macro form}.
+
+\itemitem{\i{Local Macro}}
+
+This is a \term{macro} that is defined only lexically within the scope of some
+other \term{macro form}.
+
+\itemitem{\i{Macro}}
+
+This is a \term{macro}.
+
+\itemitem{\i{Restart}}
+
+This is a \term{restart}.
+
+\itemitem{\i{Special Operator}}
+
+This is a \term{special operator}.
+
+\itemitem{\i{Standard Generic Function}}
+
+This is a \term{standard generic function}.
+
+\itemitem{\i{Symbol}}
+
+This is a \term{symbol} that is specially recognized in some particular situation,
+such as the syntax of a \term{macro}.
+
+\itemitem{\i{System Class}}
+
+This is like \term{class}, but it identifies a \term{class} that is potentially
+a \term{built-in class}.  (No \term{class} is actually required to be a
+\term{built-in class}.)
+
+\itemitem{\i{Type}}
+
+This is an \term{atomic type specifier},
+and depending on information for each particular entry,
+may subject to form other \term{type specifiers}.
+
+\itemitem{\i{Type Specifier}}
+
+This is a \term{defined name} that is not an \term{atomic type specifier},
+but that can be used in constructing valid \term{type specifiers}.
+
+\itemitem{\i{Variable}}
+
+This is a \term{dynamic variable}.
+
+\endlist
+
+\endsubsubsection%{The ``Name'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Notes'' Section of a Dictionary Entry}
+
+Information not found elsewhere in this description
+which pertains to this \term{operator}.
+Among other things, this might include 
+ cross reference information,
+ code equivalences, 
+ stylistic hints,
+ implementation hints,
+ typical uses.
+This information is not considered part of the standard;
+any \term{conforming implementation} or \term{conforming program}
+is permitted to ignore the presence of this information.
+
+\endsubsubsection%{The ``Notes'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Pronunciation'' Section of a Dictionary Entry}
+
+This offers a suggested pronunciation for \term{defined names} 
+so that people not in verbal communication with the original designers
+can figure out how to pronounce words that are not in normal English usage.
+This information is advisory only, and is not considered part of the standard.
+% Added for Ida, who wondered why these didn't occur for every entry.
+For brevity, it is only provided for entries with names that are specific to
+\clisp\ and would not be found in {\WebstersDictionary}.
+
+\endsubsubsection%{The ``Pronunciation'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``See Also'' Section of a Dictionary Entry}
+
+List of references to other parts of this standard
+that offer information relevant to this \term{operator}. 
+This list is not part of the standard.
+         
+\endsubsubsection%{The ``See Also'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Side Effects'' Section of a Dictionary Entry}
+
+Anything that is changed as a result of the
+evaluation of the \term{form} containing this \term{operator}.
+
+\endsubsubsection%{The ``Side Effects'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Supertypes'' Section of a Dictionary Entry}
+
+This appears in the dictionary entry for a \term{type},
+and contains a list of the \term{standardized} \term{types} 
+that must be \term{supertypes} of this \term{type}.
+
+%!!! Is this needed? Mail sent to `barmar' and `barrett' with subject "supertypes"
+%    asking for opinions. -kmp 10-Feb-92
+In \term{implementations} where there is a corresponding \term{class},
+the order of the \term{classes} in the \term{class precedence list} 
+is consistent with the order presented in this section.
+
+\endsubsubsection%{The ``Supertypes'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Syntax'' Section of a Dictionary Entry}
+
+This section describes how to use the \term{defined name} in code.
+The ``Syntax'' description for a \term{generic function} 
+describes the \term{lambda list} of the \term{generic function} itself, 
+while the ``Method Signatures'' describe the \term{lambda lists} 
+of the defined \term{methods}.
+The ``Syntax'' description for 
+     an \term{ordinary function},
+     a \term{macro},
+  or a \term{special operator}
+describes its \term{parameters}.
+
+For example, an \term{operator} description might say:
+
+\Defun {F} {x y {\opt} z {\key} k}
+
+\noindent This description indicates that the function \b{F} 
+has two required parameters, \param{x} and \param{y}.  In addition,
+there is an optional parameter \param{z} and a keyword parameter \param{k}.
+
+For \term{macros} and \term{special operators}, syntax is given 
+in modified BNF notation; \seesection\ModifiedBNF.
+For \term{functions} a \term{lambda list} is given.
+%Added per Barmar:
+In both cases, however, the outermost parentheses are omitted,
+and default value information is omitted.
+
+\beginsubsubsubsection{Special ``Syntax'' Notations for Overloaded Operators}
+%RPG: Nice idea.
+
+If two descriptions exist for the same operation but with different numbers of
+arguments, then the extra arguments are to be treated as optional.  For example,
+this pair of lines:
+
+\DefunWithValues file-position {stream} {position}
+\DefunWithValues file-position {stream position-spec} {success-p}
+
+\noindent is operationally equivalent to this line:
+
+\DefunWithValues file-position {stream {\opt} position-spec} {result}
+
+\noindent and differs only in that it provides on opportunity to introduce different
+names for \term{parameter} and \term{values} for each case.
+The separated (multi-line) notation is used when an \term{operator} is overloaded in
+such a way that the \term{parameters} are used in different ways
+depending on how many \term{arguments} are supplied (\eg for \thefunction{/})
+or the return values are different in the two cases (\eg for \thefunction{file-position}).
+
+\endsubsubsubsection%{Special ``Syntax'' Notations for Overloaded Operators}
+
+\beginsubsubsubsection{Naming Conventions for Rest Parameters}
+
+Within this specification, 
+if the name of a \term{rest parameter} is chosen to be a plural noun,
+use of that name in \param{parameter} font refers
+to the \term{list} to which the \term{rest parameter} is bound.
+Use of the singular form of that name in \param{parameter} font refers 
+to an \term{element} of that \term{list}.
+
+For example, given a syntax description such as:
+
+\Defun {F} {{\rest} \param{arguments}}
+
+\noindent it is appropriate to refer either to the \term{rest parameter} named
+\param{arguments} by name, or to one of its elements by speaking of ``an \param{argument},''
+``some \param{argument},'' ``each \param{argument}'' \etc.
+
+\endsubsubsubsection%{Naming Conventions for Rest Parameters}
+
+\beginsubsubsubsection{Requiring Non-Null Rest Parameters in the ``Syntax'' Section}
+
+In some cases it is useful to refer to all arguments equally as a single
+aggregation using a \term{rest parameter} while at the same time
+requiring at least one argument.  A variety of imperative and
+declarative means are available in \term{code} for expressing such a
+restriction, however they generally do not manifest themselves in a
+\term{lambda list}.  For descriptive purposes within this specification,
+
+\Defun {F} {{\rest} \plus{arguments}}
+
+\noindent means the same as
+
+\Defun {F} {{\rest} arguments}
+
+\noindent but introduces the additional requirement that there be 
+at least one \param{argument}.
+
+\endsubsubsubsection%{Requiring Non-Null Rest Parameters in the ``Syntax'' Section}
+
+\beginsubsubsubsection{Return values in the ``Syntax'' Section}
+
+An evaluation arrow ``{\EV}'' precedes a list of \term{values} to be returned.
+For example:
+
+\DefunWithValues {F} {a b c} {x}
+
+\noindent indicates that \f{F} is an operator that has three \term{required parameters}
+(\ie \param{a}, \param{b}, and \param{c}) and that returns one \term{value} (\ie \param{x}).
+If more than one \term{value} is returned by an operator, the \term{names} of the
+\term{values} are separated by commas, as in:
+
+\DefunWithValues {F} {a b c} {x, y, z}
+
+\beginsubsubsubsubsection{No Arguments or Values in the ``Syntax'' Section}
+
+If no \term{arguments} are permitted, or no \term{values} are returned, 
+a special notation is used to make this more visually apparent.  For example,
+
+\DefunWithValues {F} {\noargs} {\novalues}
+
+indicates that \f{F} is an operator that accepts no \term{arguments} and returns
+no \term{values}.
+
+\endsubsubsubsubsection%{No Arguments or Values in the ``Syntax'' Section}
+
+\beginsubsubsubsubsection{Unconditional Transfer of Control in the ``Syntax'' Section}
+
+Some \term{operators} perform an unconditional transfer of control, and
+so never have any return values.  Such \term{operators} are notated using
+a notation such as the following:
+
+\DefunNoReturn F {a b c}
+
+\endsubsubsubsubsection%{Unconditional Transfer of Control in the ``Syntax'' Section}
+
+\endsubsubsubsection%{Return values in the ``Syntax'' Section}
+
+\endsubsubsection%{The ``Syntax'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Valid Context'' Section of a Dictionary Entry}
+
+This information is used by dictionary entries such as ``Declarations''
+in order to restrict the context in which the declaration may appear.
+
+A given ``Declaration'' might appear in 
+     a \term{declaration} (\ie a \misc{declare} \term{expression}),
+     a \term{proclamation} (\ie a \macref{declaim} or \funref{proclaim} \term{form}),
+  or both.
+
+\endsubsubsection%{The ``Valid Context'' Section of a Dictionary Entry}
+
+\beginsubsubsection{The ``Value Type'' Section of a Dictionary Entry}
+
+This information describes any \term{type} restrictions on a \term{dynamic variable}.
+
+%% I added the first part of this sentence as editorial discretion 
+%% since I believe we strongly feel that this is not specified otherwise,
+%% but we want to avoid an unexpected conflict in case it is. -kmp 9-May-94
+Except as explicitly specified otherwise,
+%% Added per X3J13 at May 4-5, 1994 meeting.  -kmp 9-May-94
+the consequences are undefined if this type restriction is violated.
+
+\endsubsubsection%{The ``Value Type'' Section of a Dictionary Entry}
+
+\endsubSection%{Interpreting Dictionary Entries}

concept-deprecated.tex

@@ -0,0 +1,87 @@
+% -*- Mode: TeX -*-
+
+Deprecated language features are not expected to appear in future \clisp\
+standards, but are required to be implemented for conformance with this
+standard; \seesection\ReqLangFeatures.
+
+\term{Conforming programs} can use deprecated features;
+however, it is considered good programming style to avoid them.
+It is permissible for the compiler to produce \term{style warnings} 
+about the use of such features at compile time, 
+but there should be no such warnings at program execution time.
+
+\beginsubsection{Deprecated Functions}
+
+\issue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+\issue{GENTEMP-BAD-IDEA:DEPRECATE}
+The \term{functions} in \thenextfigure\ are deprecated.
+\displaythree{Deprecated Functions}{
+assoc-if-not&nsubst-if-not&require\cr
+count-if-not&nsubstitute-if-not&set\cr
+delete-if-not&position-if-not&subst-if-not\cr
+find-if-not&provide&substitute-if-not\cr
+gentemp&rassoc-if-not&\cr
+member-if-not&remove-if-not&\cr
+}
+%Restored PROVIDE,REQUIRE -kmp 7-Feb-92
+%Added GENTEMP -kmp 18-Aug-93
+\endissue{GENTEMP-BAD-IDEA:DEPRECATE}
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+\endissue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+
+\endsubsection%{Deprecated Functions}
+
+\beginsubsection{Deprecated Argument Conventions}
+
+\issue{GENSYM-NAME-STICKINESS:LIKE-TEFLON}
+The ability to pass a numeric \term{argument} to \funref{gensym} has been deprecated.
+\endissue{GENSYM-NAME-STICKINESS:LIKE-TEFLON}
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+\Thekeyarg{test-not} to the \term{functions} in \thenextfigure\ are deprecated.
+
+\displaythree{Functions with Deprecated :TEST-NOT Arguments}{
+adjoin&nset-difference&search\cr
+assoc&nset-exclusive-or&set-difference\cr
+count&nsublis&set-exclusive-or\cr
+delete&nsubst&sublis\cr
+delete-duplicates&nsubstitute&subsetp\cr
+find&nunion&subst\cr
+intersection&position&substitute\cr
+member&rassoc&tree-equal\cr
+mismatch&remove&union\cr
+nintersection&remove-duplicates&\cr
+}
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\issue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+\issue{EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993}
+The use of the situation names \misc{compile}, \misc{load}, and \misc{eval}
+in \specref{eval-when} is deprecated.
+\endissue{EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993}
+\endissue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+
+\endsubsection%{Deprecated Argument Conventions}
+
+\beginsubsection{Deprecated Variables}
+
+\issue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+The \term{variable} \varref{*modules*} is deprecated.
+\endissue{REQUIRE-PATHNAME-DEFAULTS-AGAIN:X3J13-DEC-91}
+
+\endsubsection%{Deprecated Variables}
+
+\beginsubsection{Deprecated Reader Syntax}
+
+\issue{STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS}
+The \f{\#S} \term{reader macro} forces keyword names into \thepackage{keyword};
+\seesection\SharpsignS.
+This feature is deprecated;
+in the future, keyword names will be taken in the package they are read in,
+so \term{symbols} that are actually in \thepackage{keyword}
+should be used if that is what is desired.
+\endissue{STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS}
+
+\endsubsection%{Deprecated Reader Syntax}
+

concept-destruction.tex

@@ -0,0 +1,176 @@
+% -*- Mode: TeX -*-
+% Destructive Operations
+
+\issue{DESTRUCTIVE-OPERATIONS:SPECIFY}
+\beginsubsection{Modification of Literal Objects}
+
+The consequences are undefined if \term{literal} \term{objects} 
+are destructively modified.  For this purpose, the following operations 
+are considered \term{destructive}:
+
+\beginlist
+
+\itemitem{\typeref{random-state}}
+
+% Using it as an argument to the function RANDOM.
+
+Using it as an \term{argument} to \thefunction{random}.
+
+\itemitem{\typeref{cons}}
+
+% Altering or destructively modifying the CAR or CDR of the cons.
+
+Changing the \term{car}\meaning{1} or \term{cdr}\meaning{1} of the \term{cons},
+or performing a \term{destructive} operation on an \term{object} which is either
+the \term{car}\meaning{2} or the \term{cdr}\meaning{2} of the \term{cons}.
+
+\itemitem{\typeref{array}}
+
+% Altering or destructively modifying any array element;
+% changing the fill pointer, dimensions, or displacement of
+% the array (regardless of whether the array is actually adjustable);
+% or altering the contents of any array that is displaced to this array
+% or that otherwise shares its contents with this array.
+
+Storing a new value into some element of the \term{array},
+or performing a \term{destructive} operation 
+on an \term{object} that is already such an \term{element}.
+
+Changing the \term{fill pointer}, \term{dimensions}, or displacement of
+the \term{array} (regardless of whether the \term{array} is \term{actually adjustable}).
+
+Performing a \term{destructive} operation on another \term{array} 
+that is displaced to the \term{array} or that otherwise shares its contents
+with the \term{array}.
+
+\itemitem{\typeref{hash-table}}
+
+% Altering or destructively modifying any key or its corresponding
+% value, or adding or removing entries from the hash table.
+
+Performing a \term{destructive} operation on any \term{key}.
+
+Storing a new \term{value}\meaning{4} for any \term{key},
+or performing a \term{destructive} operation 
+on any \term{object} that is such a \term{value}.
+
+Adding or removing entries from the \term{hash table}.
+
+\itemitem{\typeref{structure-object}}
+
+% Altering or destructively modifying the contents of any slot.
+
+Storing a new value into any slot,
+or performing a \term{destructive} operation on an \term{object} 
+that is the value of some slot.
+
+\itemitem{\typeref{standard-object}}
+
+% Altering or destructively modifying the contents of any slot, or
+% changing the class of the object.
+
+Storing a new value into any slot,
+or performing a \term{destructive} operation on an \term{object} 
+that is the value of some slot.
+
+Changing the class of the \term{object} (\eg using \thefunction{change-class}).
+
+\itemitem{\typeref{readtable}}
+
+% Altering the readtable-case; altering the syntax type of any
+% character in this readtable; altering the reader macro function
+% associated with any character in this readtable; or altering the
+% reader macro functions associated with characters defined as 
+% dispatching macro characters in this readtable.
+
+Altering the \term{readtable case}.
+
+Altering the syntax type of any character in this readtable.
+
+Altering the \term{reader macro function} associated with any \term{character}
+in the \term{readtable}, or altering the \term{reader macro functions}
+associated with \term{characters} defined as \term{dispatching macro characters}
+in the \term{readtable}.
+
+\itemitem{\typeref{stream}}
+
+% Performing I/O operations on the stream, or closing the stream.
+
+Performing I/O operations on the \term{stream},
+or \term{closing} the \term{stream}.
+
+\itemitem{All other standardized types}
+
+ [This category includes, for example, \typeref{character},
+                                      \typeref{condition},
+                                      \typeref{function},
+                                      \typeref{method-combination},
+                                      \typeref{method},
+                                      \typeref{number},
+                                      \typeref{package},
+                                      \typeref{pathname},
+                                      \typeref{restart},
+                                  and \typeref{symbol}.]
+
+% (including number, character, symbol, package, pathname, function,
+%  method, method-combination, condition, restart)
+% There are no destructive operations defined on these data types.
+
+There are no \term{standardized} \term{destructive} operations
+defined on \term{objects} of these \term{types}.
+
+\endlist
+
+\endsubsection%{Modification of Literal Objects}
+\endissue{DESTRUCTIVE-OPERATIONS:SPECIFY}
+
+\beginsubsection{Transfer of Control during a Destructive Operation}
+
+%%% This text used to just apply to SORT.
+%%% KMP modified it to generalize from errors to arbitrary transfer 
+%%%   of control, since not just errors can cause this. Consider:
+%%%   (prog foo ((a (list 1 2 3 4 5 6 7 8 9 10)))
+%%%     (sort a #'(lambda (x y) 
+%%%                 (if (zerop (random 5)) (return-from foo a) (> x y)))))
+%%% Barrett suggested further generalizing it for other the sake of 
+%%%   application to other destructive operations.
+%%% KMP agreed since it's true that things are ill-defined whether we say 
+%%% it or not, so we might as well say it explicitly.
+%%%
+%%% Original text from SORT:
+%%%  %% 14.4.0 8
+%%%  Should execution of the \param{key} or the \param{predicate} 
+%%%  cause an error,
+%%%  the state of the \param{sequence} being sorted is
+%%%  undefined.  However, if the error is corrected, the sort will
+%%%  proceed correctly. 
+
+Should a transfer of control out of a \term{destructive} operation occur
+(\eg due to an error) the state of the \param{object} being modified is
+\term{implementation-dependent}.
+
+\beginsubsubsection{Examples of Transfer of Control during a Destructive Operation}
+
+The following examples illustrate some of the many ways in which the
+\term{implementation-dependent} nature of the modification can manifest
+itself.
+
+\code
+ (let ((a (list 2 1 4 3 7 6 'five)))
+   (ignore-errors (sort a #'<))
+   a)
+\EV (1 2 3 4 6 7 FIVE)
+\OV (2 1 4 3 7 6 FIVE)
+\OV (2)
+
+ (prog foo ((a (list 1 2 3 4 5 6 7 8 9 10)))
+   (sort a #'(lambda (x y) (if (zerop (random 5)) (return-from foo a) (> x y)))))
+\EV (1 2 3 4 5 6 7 8 9 10)
+\OV (3 4 5 6 2 7 8 9 10 1)
+\OV (1 2 4 3)
+\endcode
+
+\endsubsubsection%{Examples of Transfer of Control during a Destructive Operation}
+
+\endsubsection%{Transfer of Control during a Destructive Operation}
+

concept-environment.tex

@@ -0,0 +1,246 @@
+% -*- Mode: TeX -*-
+%% Interface with the Programming Environment
+
+\beginSubsection{Top level loop}
+\DefineSection{TopLevelLoop}
+%% 20.2.0 1
+The top level loop is the \clisp\ mechanism by which the user normally
+interacts with the \clisp\ system. This loop is sometimes referred to 
+as the \term{Lisp read-eval-print loop}
+because it typically consists of an endless loop that reads an expression,
+evaluates it and prints the results.
+
+%% 20.2.0 2
+The top level loop is not completely specified; thus the user
+interface is \term{implementation-defined}.
+%% 20.2.0 3
+%% Moon deleted the following sentence
+%The top level loop 
+%traps all attempts to \term{throw} and recovers from them.
+The top level loop 
+prints all values resulting from the evaluation of a 
+\term{form}.
+%% 20.2.0 4
+\Thenextfigure\ lists variables that are maintained by the \term{Lisp read-eval-print loop}.
+
+\displayfour{Variables maintained by the Read-Eval-Print Loop}{
+*&+&/&-\cr
+**&++&//&\cr
+***&+++&///&\cr
+}
+
+\endSubsection%{Top level loop}
+
+\beginsubsection{Debugging Utilities}
+ 
+\Thenextfigure\ shows \term{defined names} relating to
+debugging.
+
+\displaythree{Defined names relating to debugging}{
+*debugger-hook*&documentation&step\cr
+apropos&dribble&time\cr
+apropos-list&ed&trace\cr
+break&inspect&untrace\cr
+describe&invoke-debugger&\cr
+}
+ 
+\endsubsection%{Debugging Utilities}
+
+\beginSubsection{Environment Inquiry}
+%% 25.4.0 1
+Environment inquiry \term{defined names} provide information about
+the hardware and software configuration on which a \clisp\ program is
+being executed.
+
+\Thenextfigure\ shows \term{defined names} relating to environment inquiry.
+
+\displaythree{Defined names relating to environment inquiry.}{
+*features*&machine-instance&short-site-name\cr
+lisp-implementation-type&machine-type&software-type\cr
+lisp-implementation-version&machine-version&software-version\cr
+long-site-name&room&\cr
+}
+%Removed identity! -kmp 3-Jan-91
+
+\endSubsection%{Environment Inquiry}
+
+\beginsubsection{Time}
+\DefineSection{Time}
+
+%% 25.4.1 1
+Time is represented in four different ways in \clisp:
+    \term{decoded time},
+    \term{universal time},
+    \term{internal time},
+and seconds.
+\term{Decoded time} and \term{universal time} are used primarily to represent calendar time,
+and are precise only to one second.
+\term{Internal time} is used primarily to represent measurements of computer
+time (such as run time) and is precise to some \term{implementation-dependent}
+fraction of a second called an \term{internal time unit},
+as specified by \conref{internal-time-units-per-second}.
+%Actually, relative universal times aren't actually used for anything.
+%But it didn't seem worth removing the mention, since it's a legit concept. -kmp 9-Sep-91
+%% Moon wanted this shifted to say that Universal time is only absolute.
+% \term{Decoded time} is used only for \term{absolute} \term{time} indications.
+% \term{Universal time} and \term{internal time} formats are used for both \term{absolute}
+% and \term{relative} \term{times}.
+An \term{internal time} can be used 
+  for either \term{absolute} and \term{relative} \term{time} measurements.
+Both a \term{universal time} and a \term{decoded time} can be used 
+  only for \term{absolute} \term{time} measurements.
+%This may be gratuitous, but I just want to be clear.
+In the case of one function, \funref{sleep},
+time intervals are represented as a non-negative \term{real} number of seconds.
+
+\Thenextfigure\ shows \term{defined names} relating to \term{time}.
+
+\displaytwo{Defined names involving Time.}{
+decode-universal-time&get-internal-run-time\cr
+encode-universal-time&get-universal-time\cr
+get-decoded-time&internal-time-units-per-second\cr
+get-internal-real-time&sleep\cr
+}
+
+
+\beginsubsubsection{Decoded Time}
+\DefineSection{DecodedTime}
+
+%% 25.4.1 2
+A \newterm{decoded time} is an ordered series of nine values that, taken together,
+represent a point in calendar time (ignoring \term{leap seconds}):
+
+%% 25.4.1 3
+\beginlist
+\itemitem{\b{Second}}
+
+An \term{integer} between 0 and~59, inclusive.
+
+%% 25.4.1 4
+\itemitem{\b{Minute}}
+
+An \term{integer} between 0 and~59, inclusive.
+
+%% 25.4.1 5
+\itemitem{\b{Hour}}
+
+An \term{integer} between 0 and~23, inclusive.
+
+%% 25.4.1 6
+\itemitem{\b{Date}}
+
+An \term{integer} between 1 and~31, inclusive (the upper limit actually
+depends on the month and year, of course).
+
+%% 25.4.1 7
+\itemitem{\b{Month}}
+
+An \term{integer} between 1 and 12, inclusive;
+1~means January, 2~means February, and so on; 12~means December.
+
+%% 25.4.1 8
+\itemitem{\b{Year}}
+
+An \term{integer} indicating the year A.D.  However, if this 
+\term{integer}
+is between 0 and 99, the ``obvious'' year is used; more precisely,
+that year is assumed that is equal to the 
+\term{integer} modulo 100 and
+within fifty years of the current year (inclusive backwards
+and exclusive forwards).  
+Thus, in the year 1978, year 28 is 1928
+but year 27 is 2027.  (Functions that return time in this format always return
+a full year number.) 
+
+%% 25.4.1 10
+\itemitem{\b{Day of week}}
+
+An \term{integer} between~0 and~6, inclusive;
+0~means Monday, 1~means Tuesday, and so on; 6~means Sunday.
+                      
+%% 25.4.1 11
+\itemitem{\b{Daylight saving time flag}}
+
+A \term{generalized boolean} that,
+if \term{true}, indicates that daylight saving time is in effect.
+ 
+%% 25.4.1 12
+\itemitem{\b{Time zone}}
+
+A \term{time zone}.
+
+\endlist
+
+\Thenextfigure\ shows \term{defined names} relating to \term{decoded time}.
+
+\displaytwo{Defined names involving time in Decoded Time.}{
+decode-universal-time&get-decoded-time\cr
+}
+
+
+\endsubsubsection%{Decoded Time}
+
+\beginsubsubsection{Universal Time}
+\DefineSection{UniversalTime}
+
+%% 25.4.1 13
+% \newtermidx{Universal time}{universal time} represents time as a single non-negative \term{integer}.
+% For \term{relative} time purposes, this is a number of seconds.
+% For absolute time, this is the
+% number of seconds since midnight, January 1, 1900 GMT (ignoring \term{leap seconds}).
+\newtermidx{Universal time}{universal time} is an \term{absolute} \term{time} represented as a
+single non-negative \term{integer}---the number of seconds since
+midnight, January 1, 1900 GMT (ignoring \term{leap seconds}).
+Thus the time 1 is 00:00:01 (that is, 12:00:01 a.m.) on January 1, 1900 GMT.
+Similarly, the time 2398291201 corresponds to time 00:00:01 on January 1,
+1976 GMT.
+Recall that the year 1900 was not a leap year; for the purposes of
+\clisp, a year is a leap year if and only if its number is divisible by 4,
+except that years divisible by 100 are not leap years, except that years
+divisible by 400 are leap years.  Therefore the year 2000 will
+be a leap year.
+Because \term{universal time} must be a non-negative \term{integer},
+times before the base time of midnight, January 1, 1900 GMT cannot be processed by \clisp.
+
+\displaytwo{Defined names involving time in Universal Time.}{
+decode-universal-time&get-universal-time\cr
+encode-universal-time&\cr
+}
+
+\endsubsubsection%{Universal Time}
+
+\beginsubsubsection{Internal Time}
+\DefineSection{InternalTime}
+
+%% 25.4.1 14
+\newtermidx{Internal time}{internal time} represents time as a single \term{integer},
+in terms of an \term{implementation-dependent} unit called an \term{internal time unit}.
+Relative time is measured as a number of these units.
+Absolute time is relative to an arbitrary time base.
+
+\Thenextfigure\ shows \term{defined names} related to \term{internal time}.
+
+\displaytwo{Defined names involving time in Internal Time.}{
+get-internal-real-time&internal-time-units-per-second\cr
+get-internal-run-time&\cr
+}
+
+\endsubsubsection%{Internal Time}
+
+\beginsubsubsection{Seconds}
+
+One function, \funref{sleep}, takes its argument as a non-negative \term{real} number
+of seconds.  Informally, it may be useful to think of this as 
+a \term{relative} \term{universal time}, but it differs in one important way:
+\term{universal times} are always non-negative \term{integers}, whereas the argument to
+\funref{sleep} can be any kind of non-negative \term{real}, in order to allow for
+the possibility of fractional seconds.
+
+\displaytwo{Defined names involving time in Seconds.}{
+sleep&\cr
+}
+
+\endsubsubsection%{Seconds}
+
+\endsubsection%{Time}
+

concept-eval.tex

@@ -0,0 +1,1274 @@
+% -*- Mode: TeX -*-
+%%Evaluation
+
+\term{Execution} of \term{code} can be accomplished by a variety of means ranging
+from direct interpretation of a \term{form} representing a \term{program}
+to invocation of \term{compiled code} produced by a \term{compiler}.
+ 
+\newtermidx{Evaluation}{evaluation} is the process by which a \term{program} is \term{executed} in \clisp.
+The mechanism of \term{evaluation} is manifested
+ both implicitly through the effect of the \term{Lisp read-eval-print loop},
+ and  explicitly through the presence of the \term{functions} 
+       \funref{eval},
+       \funref{compile},
+       \funref{compile-file},
+   and \funref{load}.
+Any of these facilities might share the same execution strategy, 
+or each might use a different one.
+
+The behavior of a \term{conforming program} processed by \funref{eval}
+and by \funref{compile-file} might differ; \seesection\SemanticConstraints.
+
+\term{Evaluation} can be understood in terms of a model in which an
+interpreter recursively traverses a \term{form} performing each
+step of the computation as it goes.  
+This model, which describes the semantics of \clisp\ \term{programs},
+is described in \secref\EvaluationModel.
+
+\beginsubSection{Introduction to Environments}
+\DefineSection{IntroToEnvs}
+
+A \newterm{binding} is an association between a \term{name} and
+that which the name denotes.  \term{Bindings} are \term{established}
+in a \term{lexical environment} or a \term{dynamic environment}
+by particular \term{special operators}.
+
+An \newterm{environment} is a set of \term{bindings} and other information
+used during evaluation (\eg to associate meanings with names).
+
+\term{Bindings} in an \term{environment} are partitioned into \newtermidx{namespaces}{namespace}.
+A single \term{name} can simultaneously have more than one
+associated \term{binding} per \term{environment},
+but can have only one associated \term{binding} per \term{namespace}.
+
+%!!!! Moon: There out to be a list of the namespaces!!
+%           Do they even have agreed-upon names?
+
+\beginsubsubsection{The Global Environment}
+
+The \newterm{global environment} is that part of an \term{environment}
+that contains \term{bindings} with both \term{indefinite scope} 
+and \term{indefinite extent}.
+The \term{global environment} contains, among other things, the following:
+
+\beginlist
+\item{\bull} \term{bindings} of \term{dynamic variables} and \term{constant variables}.
+\item{\bull} \term{bindings} of \term{functions}, \term{macros}, and \term{special operators}.
+\item{\bull}%
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}%
+ \term{bindings} of \term{compiler macros}.
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}%
+\item{\bull} \term{bindings} of \term{type} and \term{class} \term{names}
+\item{\bull} information about \term{proclamations}.
+\endlist
+
+\endsubsubsection%{The Global Environment}
+
+\beginsubsubsection{Dynamic Environments}
+
+A \newterm{dynamic environment} for \term{evaluation} is that part of an
+\term{environment} that contains \term{bindings} whose duration
+is bounded by points of \term{establishment} and \term{disestablishment} 
+within the execution of the \term{form} that
+established the \term{binding}.
+A \term{dynamic environment} contains, among other things, the following:
+
+\beginlist
+\item{\bull} \term{bindings} for \term{dynamic variables}.
+\item{\bull} information about \term{active} \term{catch tags}.
+\item{\bull} information about \term{exit points} established by \specref{unwind-protect}.
+\item{\bull} information about \term{active} \term{handlers} and \term{restarts}.
+\endlist
+
+The \term{dynamic environment} that is active at any given point 
+in the \term{execution} of a \term{program} is referred to by 
+definite reference as ``the current \term{dynamic environment},''
+or sometimes as just ``the \term{dynamic environment}.''
+
+Within a given \term{namespace},
+a \term{name} is said to be \term{bound}
+in a \term{dynamic environment} if there is a \term{binding} 
+%or mapping
+associated with its \term{name} in the \term{dynamic environment} 
+or, if not, there is a \term{binding} 
+%or mapping
+associated with its name in the \term{global environment}.
+
+\endsubsubsection%{Dynamic Environments}
+
+\beginsubsubsection{Lexical Environments}
+
+A \newterm{lexical environment} for \term{evaluation} at some position in a \term{program}
+is that part of the \term{environment} that contains information having 
+\term{lexical scope} within the \term{forms} containing that position.
+A \term{lexical environment} contains, among other things, the following:
+
+\beginlist
+\item{\bull} \term{bindings} of \term{lexical variables} and \term{symbol macros}.
+\item{\bull} \term{bindings} of \term{functions} and \term{macros}.
+             (Implicit in this is information about those \term{compiler macros} 
+	      that are locally disabled.)
+%% Replaced by parenthetical remark on previous bullet. -kmp 5-Dec-91
+% \item{\bull} \term{bindings} of \term{compiler macros}
+% 	     (specifically, information about those \term{compiler macros} 
+% 	      that are locally disabled)
+\item{\bull} \term{bindings} of \term{block tags}.
+\item{\bull} \term{bindings} of \term{go tags}.
+\item{\bull} information about \term{declarations}.
+\endlist
+
+The \term{lexical environment} that is active at any given position
+in a \term{program} being semantically processed is referred to by
+definite reference as ``the current \term{lexical environment},''
+or sometimes as just ``the \term{lexical environment}.''  
+
+Within a given \term{namespace},
+a \term{name} is said to be \term{bound} in a \term{lexical environment}
+if there is a \term{binding} 
+%or mapping
+associated with its \term{name}
+in the \term{lexical environment} or, if not, there is a \term{binding} 
+%or mapping
+associated with its name in the \term{global environment}.
+
+\beginsubsubsubsection{The Null Lexical Environment}
+\DefineSection{NullLexicalEnv}
+
+The \newterm{null lexical environment} is equivalent to the \term{global environment}.
+
+Although in general the representation of an \term{environment} \term{object}
+is \term{implementation-dependent}, \nil\ can be used in any situation where an
+\term{environment} \term{object} is called for in order to denote 
+the \term{null lexical environment}.
+
+\endsubsubsubsection%{The Null Lexical Environment}
+
+\endsubsubsection%{Lexical Environments}
+
+\beginsubsubsection{Environment Objects}
+\DefineSection{EnvObjs}
+
+Some \term{operators} make use of an \term{object}, 
+called an \newterm{environment object},
+that represents the set of \term{lexical bindings} needed to perform
+semantic analysis on a \term{form} in a given \term{lexical environment}.
+The set of \term{bindings} in an \term{environment object}
+may be a subset of the \term{bindings} that would be needed to actually 
+perform an \term{evaluation}; for example, \term{values} associated with
+\term{variable} \term{names} and \term{function names} in the corresponding
+\term{lexical environment} might not be available in an \term{environment object}.
+
+The \term{type} and nature of an \term{environment object} is \term{implementation-dependent}.
+The \term{values} of \term{environment parameters} to \term{macro functions}
+are examples of \term{environment objects}.
+
+The \term{object} \nil\ when used as an \term{environment object}
+denotes the \term{null lexical environment};
+\seesection\NullLexicalEnv.
+
+\endsubsubsection%{Environment Objects}
+
+\endSubsection%{Introduction to Environments}
+
+\beginSubsection{The Evaluation Model}
+\DefineSection{EvaluationModel}
+
+A \clisp\ system evaluates \term{forms} with respect to lexical,
+dynamic, and global \term{environments}.  The following sections
+describe the components of the \clisp\ evaluation model.
+
+\beginsubsubsection{Form Evaluation}
+
+%% 5.1.0 2
+%% 5.1.1 1
+\term{Forms} fall into three categories:
+%!!!Is this a correct use of self-evaluating? -kmp 09-Apr-91
+\term{symbols}, \term{conses}, and \term{self-evaluating objects}.
+The following sections explain these categories.
+                                            
+\beginsubsubsubsection{Symbols as Forms}
+\DefineSection{SymbolsAsForms}
+
+If a \term{form} is a \term{symbol},
+then it is either a \term{symbol macro} or a \term{variable}.
+
+The \term{symbol} names a \term{symbol macro} 
+if there is a \term{binding} of the \term{symbol} as a \term{symbol macro}
+in the current \term{lexical environment} 
+\issue{ISO-COMPATIBILITY:ADD-SUBSTRATE}
+ (see \macref{define-symbol-macro} and \specref{symbol-macrolet}).
+\endissue{ISO-COMPATIBILITY:ADD-SUBSTRATE}
+If the \term{symbol} is a \term{symbol macro},
+its expansion function is obtained.
+The expansion function is a function of two arguments, and is invoked
+by calling the \term{macroexpand hook} with 
+     the expansion function as its first argument,
+     the \term{symbol} as its second argument,
+ and an \term{environment object} (corresponding to the current \term{lexical environment})
+      as its third argument.
+The \term{macroexpand hook}, in turn, calls the expansion function with the
+\term{form} as its first argument and the \term{environment} as its second argument.
+The \term{value} of the expansion function, which is passed through
+by the \term{macroexpand hook}, is a \term{form}. 
+This resulting \term{form} is processed in place of the original \term{symbol}.
+
+If a \term{form} is a \term{symbol} that is not a \term{symbol macro},
+then it is the \term{name} of a \term{variable}, and the \term{value} of that
+\term{variable} is returned. There are three kinds of variables:
+ \term{lexical variables},
+ \term{dynamic variables},
+and
+ \term{constant variables}.
+% global variables.
+A \term{variable} can store one \term{object}.
+The main operations on a \term{variable} are 
+ to \term{read}\meaning{1} and 
+ to \term{write}\meaning{1}
+its \term{value}.
+
+%% 7.1.1 1
+%% 7.2.0 2
+%% 7.2.0 3
+
+An error \oftype{unbound-variable} should be signaled if
+an \term{unbound variable} is referenced.
+
+\term{Non-constant variables} can be \term{assigned} by using \specref{setq} 
+or \term{bound}\meaning{3} by using \specref{let}.
+\Thenextfigure\ lists some \term{defined names} that
+are applicable to assigning, binding, and defining \term{variables}.
+
+\displaythree{Some Defined Names Applicable to Variables}{
+boundp&let&progv\cr
+defconstant&let*&psetq\cr
+defparameter&makunbound&set\cr
+defvar&multiple-value-bind&setq\cr
+lambda&multiple-value-setq&symbol-value\cr
+}
+
+The following is a description of each kind of variable.
+
+\beginsubsubsubsubsection{Lexical Variables}
+
+%!!! Issue of (let ((x x)) (declare (special x)) ...). Is the outer X special? -kmp
+%% 5.1.2 2
+%% Rewritten by KAB and KMP.
+% A \term{variable} that occurs textually within a \term{form}
+% that creates a \term{lexical binding} for a \term{variable}
+% of the same name is a \term{lexical variable} unless the reference is locally
+% declared \declref{special} (see \misc{declare}) or the \term{binding}
+% is shadowed by a \term{form} that creates a \term{dynamic binding} of the same name.
+
+%% 5.1.2 3
+A \term{lexical variable} is a \term{variable} that can be referenced only within 
+the \term{lexical scope} of the \term{form} that establishes that \term{variable};
+\term{lexical variables} have \term{lexical scope}.
+Each time a \term{form} creates a \term{lexical binding} of a \term{variable},
+a \term{fresh} \term{binding} is \term{established}.
+
+Within the \term{scope} of a \term{binding} for a \term{lexical variable} \term{name},
+uses of that \term{name} as a \term{variable} are considered to be references
+to that \term{binding} except where the \term{variable} is \term{shadowed}\meaning{2} 
+by a \term{form} that \term{establishes} a \term{fresh} \term{binding} for that 
+\term{variable} \term{name},
+or by a \term{form} that locally \term{declares} the \term{name} \declref{special}.
+
+A \term{lexical variable} always has a \term{value}.
+There is no \term{operator} that introduces a \term{binding} for a
+\term{lexical variable} without giving it an initial \term{value}, nor
+is there any \term{operator} that can make a \term{lexical variable} be \term{unbound}.
+
+\term{Bindings} of \term{lexical variables} are found in the \term{lexical environment}.
+
+\endsubsubsubsubsection%{Lexical Variables}
+
+\beginsubsubsubsubsection{Dynamic Variables}
+
+A \term{variable} is a \term{dynamic variable} if one of the following
+conditions hold:
+
+\beginlist
+
+ \item{\bull} It is locally declared or globally proclaimed \declref{special}.
+
+ \item{\bull} It occurs textually within a \term{form} that
+creates a \term{dynamic binding} for a \term{variable} of the \term{same} \term{name},
+and the \term{binding} is not \term{shadowed}\meaning{2} by a \term{form}
+that creates a \term{lexical binding} of the same \term{variable} \term{name}.
+
+%% Is this right? Is there an issue that applies to this? -kmp
+%% Removed for now because Barrett and Moon balked, too. -kmp 13-Oct-91
+%  \item{\bull} It is not locally declared \declref{special}, 
+%  and it does not occur textually within a \term{form} that creates
+%  a lexical \term{binding} for a variable of the same name.
+
+\endlist
+
+%!!! Barrett wants to mention "dynamic scope" here someplace.
+A \term{dynamic variable} can be referenced at any time in any \term{program};
+there is no textual limitation on references to \term{dynamic variables}.
+At any given time, all \term{dynamic variables} with a given name refer to 
+exactly one \term{binding}, either in the \term{dynamic environment}
+or in the \term{global environment}.
+
+%% 5.1.2 5
+The \term{value} part of the \term{binding} for a \term{dynamic variable} might
+be empty; in this case, the \term{dynamic variable} is said to have no \term{value},
+or to be \term{unbound}.  A \term{dynamic variable} can be made \term{unbound}
+by using \funref{makunbound}.
+           
+The effect of \term{binding} a \term{dynamic variable} is to create
+a new \term{binding} to which all references to that \term{dynamic variable}
+in any \term{program} refer for the duration of the \term{evaluation} of the \term{form}
+that creates the \term{dynamic binding}.
+
+% %!!! Need to merge this in with previous or delete it.
+% %% 5.1.2 4
+% A \term{dynamic variable} that is referenced outside the \term{dynamic extent} of
+% a \term{form} that \term{binds} the \term{symbol} that names the
+% variable is a global variable. A global variable is \term{unbound}
+% unless and until explicitly assigned a value, except for global
+% variables defined in this specification or by an implementation.
+
+A \term{dynamic variable} can be referenced outside the \term{dynamic extent} of
+a \term{form} that \term{binds} it.  Such a \term{variable} is sometimes called 
+a ``global variable'' but is still in all respects just a \term{dynamic variable}
+whose \term{binding} happens to exist in the \term{global environment} rather than in some
+\term{dynamic environment}.
+
+% slight rewording  --sjl 3 Mar 92
+A \term{dynamic variable} is \term{unbound}
+unless and until explicitly assigned a value, except for 
+those variables whose initial value is 
+defined in this specification or by an \term{implementation}.
+
+%% Pretty much said above.
+% \term{Bindings} of \term{dynamic variables} are found in the \term{dynamic environment}
+% or the \term{global environment}.
+
+\endsubsubsubsubsection%{Dynamic Variables}
+
+\beginsubsubsubsubsection{Constant Variables}
+\DefineSection{ConstantVars}
+
+%% 1.2.5 6
+%% 5.1.2 6
+Certain variables, called \term{constant variables}, are reserved as ``named constants.''  
+The consequences are undefined if an attempt is made to 
+    assign a value to,
+ or create
+a \term{binding} for a \term{constant variable}, 
+except that a `compatible' redefinition of a \term{constant variable}
+using \macref{defconstant} is permitted; \seemac{defconstant}.
+
+\term{Keywords}, 
+\term{symbols} defined by \clisp\ or the \term{implementation}
+  as constant (such as \nil, \t, and \conref{pi}),
+and \term{symbols} declared as constant using \macref{defconstant}
+are \term{constant variables}.
+
+\endsubsubsubsubsection%{Constant Variables}
+
+\beginsubsubsubsubsection{Symbols Naming Both Lexical and Dynamic Variables}
+
+%A \term{symbol} can name both a \term{lexical variable} and a \term{dynamic variable}.
+%%KAB: The above is a little confusing, as it could be read to mean they 
+%%     are somehow in different namespaces.
+%%KMP: Replaced by the following section:
+
+The same \term{symbol} can name both 
+    a \term{lexical variable} 
+and a \term{dynamic variable},
+but never in the same \term{lexical environment}.
+
+In the following example, the \term{symbol} \f{x} is used,
+at different times, 
+    as the \term{name} of a \term{lexical variable}
+and as the \term{name} of a \term{dynamic variable}.
+ 
+\code
+ (let ((x 1))            ;Binds a special variable X
+   (declare (special x))
+   (let ((x 2))          ;Binds a lexical variable X
+     (+ x                ;Reads a lexical variable X
+        (locally (declare (special x))
+                 x))))   ;Reads a special variable X
+\EV 3
+\endcode
+
+\endsubsubsubsubsection%{Symbols Naming Both Lexical and Dynamic Variables}
+
+\endsubsubsubsection%{Symbols as Forms}
+
+\beginsubsubsubsection{Conses as Forms}
+
+A \term{cons} that is used as a \term{form} is called a \term{compound form}.
+
+If the \term{car} of that \term{compound form} is a \term{symbol}, 
+that \term{symbol} is the \term{name} of an \term{operator},
+and the \term{form} is either a \term{special form}, a \term{macro form},
+or a \term{function form}, depending on the \term{function} \term{binding} 
+of the \term{operator} in the current \term{lexical environment}.
+If the \term{operator} is neither a \term{special operator}
+nor a \term{macro name}, it is assumed to be a \term{function name}
+(even if there is no definition for such a \term{function}).
+
+If the \term{car} of the \term{compound form} is not a \term{symbol},
+then that \term{car} must be a \term{lambda expression},
+in which case the \term{compound form} is a \term{lambda form}.
+
+How a \term{compound form} is processed depends on whether it is 
+classified as a \term{special form}, a \term{macro form}, 
+a \term{function form}, or a \term{lambda form}.
+
+\beginsubsubsubsubsection{Special Forms}
+
+% special form changed to special operator in a few places  --sjl 3 Mar 92
+A \term{special form} is a \term{form} with special syntax,
+special evaluation rules, or both, possibly manipulating the
+evaluation environment, control flow, or both.
+% When the operator names a \term{special form},
+% the operation is performed using special purpose code 
+% in the current \term{lexical environment} and \term{dynamic environments}.
+%% Simplified for Sandra:
+A \term{special operator} has access to
+    the current \term{lexical environment} 
+and the current \term{dynamic environment}.
+Each \term{special operator} defines the manner in which its \term{subexpressions}
+are treated---which are \term{forms}, which are special syntax, \etc.
+
+Some \term{special operators} create new 
+lexical or dynamic \term{environments} for use during the 
+\term{evaluation} of \term{subforms}
+of the \term{special form}.  For example, \specref{block} creates a
+new \term{lexical environment} that is the same as the one in force
+at the point of evaluation of the \specref{block} \term{form}
+with the addition of a \term{binding} of the \specref{block} name
+to an \term{exit point} from the \specref{block}.
+
+%Moon observes that this is no different than for any other form:
+%
+% Generally, \term{special forms} will return normally, \term{yielding}
+% one or more values, but some \term{special forms} may cause a non-local exit.
+
+The set of \term{special operator} \term{names} is fixed in \clisp; 
+no way is provided for the user to define a \term{special operator}.
+\Thenextfigure\ lists all of the \clisp\ \term{symbols}
+that have definitions as \term{special operators}.
+
+\DefineFigure{CLSpecialOps}
+%% 5.1.3 2
+%% 7.0.0 5
+%% 7.7.0 1
+%% 7.8.3 3
+%% 7.8.3 5
+%% 7.8.5 3
+%% 7.10.0 1
+\issue{COMPILER-LET-CONFUSION:ELIMINATE}
+\issue{WITH-ADDED-METHODS:DELETE}
+\issue{LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM}
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\displaythree{Common Lisp Special Operators}{
+block&let*&return-from\cr
+catch&load-time-value&setq\cr
+eval-when&locally&symbol-macrolet\cr
+flet&macrolet&tagbody\cr
+function&multiple-value-call&the\cr
+go&multiple-value-prog1&throw\cr
+if&progn&unwind-protect\cr
+labels&progv&\cr
+let&quote&\cr
+}
+%Removed COMPILER-LET -kmp 3-Jan-91
+%Removed WITH-ADDED-METHODS -kmp 7-Jan-91
+%Removed DECLARE per Moon's comments. -kmp 10-Mar-91
+%Added LOAD-TIME-VALUE -kmp 26-May-91
+%Added LOCALLY per Barrett comments. -kmp 13-Oct-91
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\endissue{LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM}
+\endissue{WITH-ADDED-METHODS:DELETE}
+\endissue{COMPILER-LET-CONFUSION:ELIMINATE}
+
+%% 5.1.3 9
+\endsubsubsubsubsection%{Special Forms}
+
+\beginsubsubsubsubsection{Macro Forms}
+
+If the \term{operator} names a \term{macro},
+its associated \term{macro function} is applied
+to the entire \term{form} and the result of that application is
+used in place of the original \term{form}.
+
+Specifically, a \term{symbol} names a \term{macro} in a given \term{lexical environment} if
+\funref{macro-function} is \term{true} of the 
+\term{symbol} and that \term{environment}.
+The \term{function} returned by \funref{macro-function}
+is a \term{function} of two arguments, called the
+expansion function.
+The expansion function is invoked by calling the \term{macroexpand hook} with
+      the expansion function as its first argument,
+      the entire \term{macro form} as its second argument,
+%   and the current \term{lexical environment} 
+% %% KAB thinks this is a bogus distinction.
+% %       (or with the current compilation \term{environment},
+% %        if the \term{form} is being processed by \funref{compile-file})
+%% Trying again... -kmp&kab 8-Feb-92
+    and an \term{environment object} (corresponding to the current \term{lexical environment})
+      as its third argument.
+The \term{macroexpand hook}, in turn, calls the expansion function with the
+\term{form} as its first argument and the \term{environment} as its second argument.
+The \term{value} of the expansion function, which is passed through
+by the \term{macroexpand hook}, is a \term{form}. 
+% (\funref{macroexpand}
+% and \funref{macroexpand-1} attach a second, \term{generalized boolean} return value
+% which is always \term{true} in this context, and hence always ignored.)
+The returned \term{form} is \term{evaluated} in place of the original \term{form}.
+
+\issue{SELF-MODIFYING-CODE:FORBID}
+The consequences are undefined if a \term{macro function} destructively modifies
+any part of its \term{form} argument.
+\endissue{SELF-MODIFYING-CODE:FORBID}
+
+%% 8.0.0 6
+A \term{macro name} is not a \term{function designator},
+and cannot be used as the \param{function} argument to \term{functions} 
+such as \funref{apply}, \funref{funcall}, or \funref{map}.
+
+An \term{implementation} is free to implement a \clisp\ \term{special operator}
+as a \term{macro}.  An \term{implementation} is free to implement any
+\term{macro} \term{operator} as a \term{special operator}, but only
+if an equivalent definition of the \term{macro} is also provided.
+% I don't think this adds anything to the above, and it's more confusing.
+% So I commented it out.  --sjl 3 Mar 92
+% %% 7.1.1 23
+% A \clisp\ \term{symbol} may name both a \term{special operator} 
+% and a \term{macro},
+% %I added this: -kmp -kmp 12-Mar-91
+% but in that case the definitions must be semantically equivalent.
+
+\Thenextfigure\ lists some \term{defined names} that are applicable
+to \term{macros}.
+
+\displaythree{Defined names applicable to macros}{
+*macroexpand-hook*&macro-function&macroexpand-1\cr
+defmacro&macroexpand&macrolet\cr
+}
+%DEFINE-COMPILER-MACRO and COMPILER-MACRO-FUNCTION removed per Moon. -kmp 10-Mar-91
+
+\endsubsubsubsubsection%{Macro Forms}
+
+\beginsubsubsubsubsection{Function Forms}
+\DefineSection{FunctionForms}
+
+If the \term{operator} is a \term{symbol} naming a \term{function},
+the \term{form} represents a \term{function form},
+and the \term{cdr} of the list contains the \term{forms} 
+which when evaluated will supply the arguments passed to the \term{function}.
+
+When a \term{function name} is not defined, 
+an error \oftype{undefined-function} should be signaled at run time;
+\seesection\SemanticConstraints.
+
+A \term{function form} is evaluated as follows:
+
+The \term{subforms} in the \term{cdr} of the original \term{form}
+are evaluated in left-to-right order in the current lexical and 
+dynamic \term{environments}.  The \term{primary value} of each
+such \term{evaluation} becomes an \term{argument} to the named \term{function};
+% removed inappropriate reference to Lambda List section.  --sjl 3 Mar 92
+any additional \term{values} returned by the \term{subforms} are discarded.
+
+The \term{functional value} of the \term{operator} 
+is retrieved from the \term{lexical environment},
+and that \term{function} is invoked with the indicated arguments.
+
+%%How the function treats its arguments, what bindings it establishes, etc. 
+%% does not belong here. -kmp,moon
+% and a new \term{lexical environment} is created that contains only
+% the \term{bindings} established by \term{binding} each parameter
+% name in the lambda list of the \term{function} with the
+% corresponding value in the evaluated arguments along with a binding of
+% the name of the \term{function} with the \term{exit point} that
+% returns from the \term{function}. This is the lexical 
+% \term{environment} used for evaluating the body of the \term{function}.
+
+\issue{FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED}
+Although the order of \term{evaluation} of 
+the \term{argument} \term{subforms} themselves is 
+strictly left-to-right, it is not specified whether 
+the definition of the \term{operator} in a \term{function form} is looked up 
+before the \term{evaluation} of the \term{argument} \term{subforms},
+after the \term{evaluation} of the \term{argument} \term{subforms},
+or between the \term{evaluation} of any two \term{argument} \term{subforms} 
+if there is more than one such \term{argument} \term{subform}.  
+For example, the following might return 23 or~24.
+
+\code
+ (defun foo (x) (+ x 3))
+ (defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
+ (foo (progn (bar) 20))
+\endcode
+\endissue{FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED}
+
+A \term{binding} for a \term{function name} can be \term{established} in 
+one of several ways.  A \term{binding} for a \term{function name} in 
+the \term{global environment} can be \term{established} by 
+ \macref{defun},
+ \SETFof{fdefinition},
+% added symbol-function --sjl 3 Mar 92
+ \SETFof{symbol-function},
+%% KAB: Doesn't belong here.
+%\macref{defmacro},
+%\SETFof{macro-function},
+ \funref{ensure-generic-function},
+ \macref{defmethod} (implicitly, due to \funref{ensure-generic-function}),
+or
+ \macref{defgeneric}.
+A \term{binding} for a \term{function name} in the \term{lexical environment}
+can be \term{established} by
+   \specref{flet}
+or \specref{labels}.
+\issue{WITH-ADDED-METHODS:DELETE}
+%\specref{with-added-methods},
+\endissue{WITH-ADDED-METHODS:DELETE}%
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+%  \specref{generic-flet},
+% or
+%  \specref{generic-labels}.
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+%%Moon thinks this is redundant, so asked that it be deleted. -kmp 11-Mar-91
+% If a \term{symbol} that names a \term{function} appears
+% as the first element of a function call \term{form}, then it refers
+% to the definition established by the innermost
+%  \specref{flet},
+%  \specref{labels},
+% \issue{WITH-ADDED-METHODS:DELETE}
+% %\specref{with-added-methods},
+% \endissue{WITH-ADDED-METHODS:DELETE}%
+%  \specref{generic-flet},
+% or
+%  \specref{generic-labels}
+% that textually contains the reference, or to the global definition (if any) if there
+% is no such containing \term{form}.  As noted earlier, this use
+% of \term{symbols} to name \term{functions} is
+% independent of their use in naming dynamic and lexical variables.
+
+\Thenextfigure\ lists some \term{defined names} that are applicable to \term{functions}.
+
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\issue{WITH-ADDED-METHODS:DELETE}
+\displaythree{Some function-related defined names}{
+apply&fdefinition&mapcan\cr
+call-arguments-limit&flet&mapcar\cr
+complement&fmakunbound&mapcon\cr
+constantly&funcall&mapl\cr
+defgeneric&function&maplist\cr
+defmethod&functionp&multiple-value-call\cr
+defun&labels&reduce\cr
+fboundp&map&symbol-function\cr
+}
+%Removed GENERIC-FLET, GENERIC-LABELS. -kmp 7-Feb-92
+%Removed WITH-ADDED-METHODS -kmp 7-Jan-91
+%Added MAPC, MAPCAR, MAPCAN, MAPLIST, MAPL, MAPCON, 
+% CONSTANTLY, COMPLEMENT, REDUCE, FDEFINITION.
+%Removed LAMBDA-LIST-KEYWORDS.
+%Not including all the things with :TEST, :TEST-NOT, :KEY arguments, though.
+%  -kmp 16-Oct-91
+\endissue{WITH-ADDED-METHODS:DELETE}
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+\endsubsubsubsubsection%{Function Forms}
+
+\beginsubsubsubsubsection{Lambda Forms}
+\DefineSection{LambdaForms}
+
+A \term{lambda form} is similar to a \term{function form}, except that
+the \term{function name} is replaced by a \term{lambda expression}.
+
+A \term{lambda form} is equivalent to using \term{funcall} of a
+\term{lexical closure} of the \term{lambda expression} on the given \term{arguments}.
+(In practice, some compilers are more likely to produce inline code 
+for a \term{lambda form} than for an arbitrary named function 
+that has been declared \declref{inline}; however, such a difference
+is not semantic.)
+
+For further information, \seesection\LambdaExpressions.
+
+\endsubsubsubsubsection%{Lambda Forms}
+
+\endsubsubsubsection%{Conses as forms}
+
+\beginsubsubsubsection{Self-Evaluating Objects}
+
+\issue{EVAL-OTHER:SELF-EVALUATE}
+A \term{form} that is neither a \term{symbol} nor a \term{cons} is 
+defined to be a \term{self-evaluating object}.  \term{Evaluating}
+such an \term{object} \term{yields} the \term{same} \term{object} 
+as a result.
+\endissue{EVAL-OTHER:SELF-EVALUATE}
+
+Certain specific \term{symbols} and \term{conses} might also happen 
+to be ``self-evaluating'' but only as a special case of a more 
+general set of rules for the \term{evaluation} of \term{symbols} and
+\term{conses}; such \term{objects} are not considered to be
+\term{self-evaluating objects}.
+
+% added  --sjl 3 Mar 92
+The consequences are undefined if \term{literal objects} (including
+\term{self-evaluating objects}) are destructively modified.
+
+\beginsubsubsubsubsection{Examples of Self-Evaluating Objects}
+
+\term{Numbers}, \term{pathnames}, and \term{arrays} are examples of
+\term{self-evaluating objects}.
+
+\code
+ 3 \EV 3
+ #c(2/3 5/8) \EV #C(2/3 5/8)
+ #p"S:[BILL]OTHELLO.TXT" \EV #P"S:[BILL]OTHELLO.TXT"
+ #(a b c) \EV #(A B C)
+ "fred smith" \EV "fred smith"
+\endcode
+
+\endsubsubsubsubsection%{Examples of Self-Evaluating Objects}
+
+\endsubsubsubsection%{Self-Evaluating Objects}
+
+\endsubsubsection%{Form Evaluation}
+
+\endSubsection%{The Evaluation Model}
+
+\beginsubsection{Lambda Expressions}
+\DefineSection{LambdaExpressions}
+
+% I found the last paragraph of this section very confusing, so I
+% reworded the first paragraph to make it unnecessary.  -- sjl 3 Mar 92
+
+% In a \term{lambda expression},
+% the current lexical \term{environment} is extended by adding the \term{binding} of
+% each \term{parameter} in the \term{lambda list} of the \term{lambda expression}
+% with the corresponding \term{value} from the \term{arguments}.
+% This is the \term{lexical environment} used for evaluating the body
+% of the \term{lambda expression}.
+
+In a \term{lambda expression},
+the body is evaluated in a lexical \term{environment} that is formed by
+adding the \term{binding} of 
+each \term{parameter} in the \term{lambda list}
+with the corresponding \term{value} from the \term{arguments}
+to the current lexical \term{environment}.
+
+For further discussion of how \term{bindings} are \term{established} 
+based on the \term{lambda list}, \seesection\LambdaLists.
+
+The body of a \term{lambda expression} is an \term{implicit progn};
+the \term{values} it returns are returned by the \term{lambda expression}.
+
+% When the \term{function} returns,
+% the \term{lexical environment} that was in effect
+% when the original \term{form} was evaluated 
+% is re-established.
+
+\endsubsection%{Lambda Expressions}
+
+\beginSubsection{Closures and Lexical Binding}
+ 
+%% 7.1.1 5
+A \term{lexical closure} is a \term{function} that can refer to and alter
+the values of \term{lexical bindings} \term{established} by \term{binding} \term{forms}
+that textually include the function definition.
+ 
+Consider this code, where \f{x} is not declared \declref{special}:
+ 
+\code
+ (defun two-funs (x)
+   (list (function (lambda () x))
+         (function (lambda (y) (setq x y)))))
+ (setq funs (two-funs 6))
+ (funcall (car funs)) \EV 6
+ (funcall (cadr funs) 43) \EV 43
+ (funcall (car funs)) \EV 43
+\endcode
+
+\Thespecform{function} coerces a 
+\term{lambda expression} into a \term{closure} in which the 
+\term{lexical environment} in effect when the \term{special form} is
+evaluated is captured along with the \term{lambda expression}.
+
+The function \f{two-funs} returns a \term{list} of two 
+\term{functions}, each of which refers to the \term{binding} of the
+variable \f{x} created on entry to the function \f{two-funs} when it
+was called.
+%% For Moon.
+%with argument \f{6}.
+This variable has the value \f{6}
+initially, but \specref{setq} can alter this \term{binding}.
+% %Barrett finds the next sentence confusing.
+% %Moon, too.
+% The \term{lexical closure} created for the first 
+% \term{lambda expression} does not capture the value \f{6} for \f{x}
+% when the \term{closure} is created.  The second \term{function} can be
+% used to alter the variable binding (to \f{43}, in the example), and
+% this altered variable binding then becomes accessible to the first
+% \term{function}.
+The \term{lexical closure} created for the first 
+\term{lambda expression} does not ``snapshot'' the \term{value} \f{6} for \f{x}
+when the \term{closure} is created; rather it captures the \term{binding} of \f{x}.
+The second \term{function} can be used to alter the \term{value} in the same (captured)
+\term{binding} (to \f{43}, in the example), and
+this altered variable binding then affects the value returned by the first \term{function}.
+
+                     
+%% 7.1.1 6
+In situations where a \term{closure} of a 
+\term{lambda expression} over the same set of \term{bindings} may be
+produced more than once, the various resulting \term{closures} may
+or may not be \term{identical}, at the discretion of the \term{implementation}.
+That is, two \term{functions} that are behaviorally
+indistinguishable might or might not be \term{identical}.
+Two \term{functions} that are behaviorally distinguishable are \term{distinct}.
+For example:
+ 
+\code
+ (let ((x 5) (funs '()))
+   (dotimes (j 10)                          
+     (push #'(lambda (z)                        
+               (if (null z) (setq x 0) (+ x z)))
+           funs))
+   funs)
+\endcode
+The result of the above \term{form} is a \term{list} of ten \term{closures}.
+Each requires only the \term{binding} of \f{x}.
+It is the same \term{binding} in each case, 
+but the ten \term{closure} \term{objects} might or might not be \term{identical}.
+On the other hand, the result of the \term{form}
+ 
+\code
+ (let ((funs '()))     
+   (dotimes (j 10)
+     (let ((x 5))
+       (push (function (lambda (z)
+                        (if (null z) (setq x 0) (+ x z))))
+             funs)))
+  funs)
+\endcode
+is also a \term{list} of ten \term{closures}.
+However, in this case no two of the \term{closure} \term{objects} can
+be \term{identical} because each \term{closure} is closed over a distinct
+\term{binding} of \f{x}, and these \term{bindings} can be behaviorally
+distinguished because of the use of \specref{setq}.
+ 
+%% 7.1.1 7                        
+The result of the \term{form}
+ 
+\code
+ (let ((funs '()))
+   (dotimes (j 10)
+     (let ((x 5))
+       (push (function (lambda (z) (+ x z)))
+            funs)))
+   funs)
+\endcode
+is a \term{list} of ten \term{closure} \term{objects} that
+might or might not be \term{identical}.
+A different \term{binding} of \f{x} is involved for
+each \term{closure}, but the \term{bindings} cannot be distinguished
+because their values are the \term{same} and immutable (there being no occurrence
+of \specref{setq} on \f{x}).  A compiler could internally
+transform the \term{form} to
+ 
+\code
+ (let ((funs '()))
+   (dotimes (j 10)
+     (push (function (lambda (z) (+ 5 z)))
+           funs))
+  funs)
+\endcode
+where the \term{closures} may be \term{identical}.
+%% Moon thought this was redundant and distracting. -kmp 8-Feb-92
+% In some \term{implementations},
+% two distinct evaluations of the same \specref{function} \term{form} might 
+% produce \term{identical} \term{closures} if they must be behaviorally
+% identical with respect to invocation.
+ 
+%% 7.1.1 9
+It is possible that a \term{closure} does not
+close over any variable bindings.
+In the code fragment
+ 
+\code
+ (mapcar (function (lambda (x) (+ x 2))) y)
+\endcode
+the function \f{(lambda (x) (+ x 2))} contains no references to any outside
+object. In this case, the same \term{closure} might be returned
+for all evaluations of the \specref{function} \term{form}.
+
+\endSubsection%{Closures and Lexical Binding}
+ 
+\beginSubsection{Shadowing}
+\DefineSection{Shadowing}
+%% 5.1.3 10
+%% 3.0.0 13
+%
+% If two \term{forms} that establish lexical entities with the same
+% \term{name} are textually nested, then references within the inner
+% \term{form} refer to the entity established by the inner one; the
+% inner one shadows the outer one.  Outside the inner \term{form} but
+% inside the outer one, references refer to the entity established by
+% the outer \term{form}.  For example:
+%
+%% Rewritten for Sandra:
+
+If two \term{forms} that \term{establish} \term{lexical bindings} with
+the same \term{name} $N$ are textually nested, then references to $N$
+within the inner \term{form} refer to the \term{binding} established by
+the inner \term{form}; the inner \term{binding} for $N$
+\newtermidx{shadows}{shadow} the outer \term{binding} for $N$.  Outside the inner
+\term{form} but inside the outer one, references to $N$ refer to the
+\term{binding} established by the outer \term{form}.  For example:
+
+%!!! Barrett thinks this doesn't explain, and that we should discuss,
+%    (let ((x ...)) (let ((x ...)) (declare (special x)) ...))
+
+\code
+ (defun test (x z)
+   (let ((z (* x 2)))
+     (print z))
+   z)
+\endcode
+The \term{binding} of the variable \f{z} by
+\specref{let} shadows
+the \term{parameter} binding for the function \f{test}.  The reference to the
+variable \f{z} in the \funref{print} \term{form} refers to the \specref{let} binding.
+The reference to \f{z} at the end of the function \f{test} 
+refers to the \term{parameter} named \f{z}.
+
+%!!! What to do with this use of "construct"? -kmp 3-Sep-91
+%% 3.0.0 26
+Constructs that are lexically scoped act as if new names were
+generated for each \term{object} on each execution.  Therefore,
+dynamic shadowing cannot occur.  For example:
+
+\code
+ (defun contorted-example (f g x)
+   (if (= x 0)
+       (funcall f)
+       (block here
+          (+ 5 (contorted-example g
+                                  #'(lambda () (return-from here 4))
+                                  (- x 1))))))
+\endcode
+Consider the call \f{(contorted-example nil nil 2)}.  This produces
+\f{4}.  During the course of execution, there are three
+calls to \f{contorted-example}, interleaved with two 
+blocks:
+
+\code
+ (contorted-example nil nil 2)
+   (block here\ssso ...)
+     (contorted-example nil #'(lambda () (return-from here\ssso 4)) 1)
+       (block here\ssst ...)
+         (contorted-example #'(lambda () (return-from here\ssso 4))
+                            #'(lambda () (return-from here\ssst 4))
+                            0)
+             (funcall f)
+                    where f \EV #'(lambda () (return-from here\ssso 4))
+                 (return-from here\ssso 4)
+\endcode
+At the time the \f{funcall} is executed
+there are two \specref{block} \term{exit points} outstanding, each apparently
+named \f{here}.
+The \specref{return-from} \term{form} executed as a result of the \f{funcall}
+operation
+refers to the outer outstanding \term{exit point}
+(here\ssso), not the
+inner one (here\ssst).
+It
+refers to that \term{exit point} textually visible at the point of
+execution of \specref{function}
+(here abbreviated by the \f{\#'} syntax) that resulted
+in creation of the \term{function} \term{object} actually invoked by 
+\funref{funcall}.                       
+
+%% 3.0.0 27
+If, in this example, one were to change the \f{(funcall f)} to
+\f{(funcall g)}, then the value of the call \f{(contorted-example nil nil 2)}
+would be \f{9}.  The value would change because 
+\funref{funcall} would cause the
+execution of \f{(return-from here\ssst\ 4)}, thereby causing
+a return from the inner \term{exit point} (here\ssst).
+When that occurs, the value \f{4} is returned from the
+middle invocation of \f{contorted-example}, \f{5} is added to that
+to get \f{9}, and that value is returned from the outer block
+and the outermost call to \f{contorted-example}.  The point
+is that the choice of \term{exit point}
+returned from has nothing to do with its
+being innermost or outermost; rather,
+it depends on the lexical environment
+that is packaged up with a \term{lambda expression} when
+\specref{function} is executed.
+                                  
+\endSubsection%{Shadowing}
+
+\beginSubsection{Extent}
+%% 3.0.0 28
+\f{Contorted-example} works only because the
+\term{function} named by \f{f} is invoked during the \term{extent} of the 
+\term{exit point}.
+Once the flow of execution has left the block,
+the \term{exit point} is \term{disestablished}.  For example:
+
+\code
+ (defun invalid-example ()
+   (let ((y (block here #'(lambda (z) (return-from here z)))))
+     (if (numberp y) y (funcall y 5))))
+\endcode
+One might expect the call \f{(invalid-example)} to produce \f{5}
+by the following incorrect reasoning:
+\specref{let} binds \f{y} to the
+value of \specref{block}; this value is a \term{function} resulting
+from the \term{lambda expression}.  Because \f{y} is not a number, it is
+invoked on the value \f{5}.  The \specref{return-from} should then
+return this value from the                      
+\term{exit point} named \f{here}, thereby
+exiting from the block again and giving \f{y} the value \f{5}
+which, being a number, is then returned as the value of the call
+to \f{invalid-example}.
+
+%% 3.0.0 29
+The argument fails only because \term{exit points} have 
+\term{dynamic extent}.  The argument is correct up to the execution of
+\specref{return-from}.  The execution of \specref{return-from}
+should signal an error \oftype{control-error}, however, not
+because it cannot refer to the \term{exit point}, but because it
+does correctly refer to an \term{exit point} and that 
+\term{exit point} has been \term{disestablished}.
+
+%% 3.0.0 14
+%% 3.0.0 16
+A reference by name to a dynamic \term{exit point} binding such as
+a \term{catch tag} refers to the most recently 
+\term{established} \term{binding} of that name that has not been 
+\term{disestablished}.  For example:
+
+\code
+ (defun fun1 (x)
+   (catch 'trap (+ 3 (fun2 x))))
+ (defun fun2 (y)
+   (catch 'trap (* 5 (fun3 y))))
+ (defun fun3 (z)
+   (throw 'trap z))
+\endcode
+Consider the call \f{(fun1 7)}.  The result is \f{10}.  At the time
+the \specref{throw} is executed, there are two outstanding catchers with the
+name \f{trap}: one established within procedure \f{fun1}, and the other
+within procedure \f{fun2}.  The latter is the more recent, and so the
+value \f{7} is returned from \specref{catch} in \f{fun2}.
+Viewed from within \f{fun3}, the \specref{catch} 
+in \f{fun2} shadows the one in \f{fun1}.
+Had \f{fun2} been defined as
+
+\code
+ (defun fun2 (y)
+   (catch 'snare (* 5 (fun3 y))))
+\endcode
+then the two \term{exit points} 
+would have different \term{names}, and therefore the one
+in \f{fun1} would not be shadowed.  The result would then have been \f{7}.
+
+\endSubsection%{Extent}
+
+\beginSubsection{Return Values}
+
+Ordinarily the result of calling a \term{function} is a single \term{object}.
+Sometimes, however, it is convenient for a function to compute several
+\term{objects} and return them.
+
+% slight rewording -- sjl 3 Mar 92
+In order to receive other than exactly one value from a \term{form},
+one of several \term{special forms} or \term{macros} must be used to request those
+values.  If a \term{form} produces \term{multiple values} which were not
+requested in this way, then the first value is given to the caller and
+all others are discarded; if the \term{form} produces zero values,
+then the caller receives \nil\ as a value.
+
+\Thenextfigure\ lists 
+some \term{operators} for receiving \term{multiple values}\meaning{2}.
+These \term{operators} can be used to specify 
+    one or more \term{forms} to \term{evaluate} 
+and where to put the \term{values} returned by those \term{forms}.
+
+\displaythree{Some operators applicable to receiving multiple values}{
+multiple-value-bind&multiple-value-prog1&return-from\cr
+multiple-value-call&multiple-value-setq&throw\cr
+multiple-value-list&return&\cr
+}
+
+\Thefunction{values} can produce \term{multiple values}\meaning{2}.
+\f{(values)} returns zero values;
+\f{(values \param{form})} returns the \term{primary value} returned by \param{form};
+\f{(values \param{form1} \param{form2})} returns two values,
+    the \term{primary value} of \param{form1}
+and the \term{primary value} of \param{form2};
+and so on.
+
+See \conref{multiple-values-limit} and \funref{values-list}.
+
+%% This little piece of language analysis isn't useful to the spec.
+%% -kmp&kab 13-Oct-91
+% 
+% \term{Multiple values} can result from a \term{form} under precisely these
+% circumstances:
+% \beginlist
+% \itemitem{\b{Evaluation and Application}}
+% 
+% \beginlist
+% \itemitem{\funref{eval}}
+% 
+% \funref{eval} returns \term{multiple values} if the form given it to
+% evaluate produces \term{multiple values}.
+% 
+% \itemitem{\funref{apply}, \funref{funcall}, \specref{multiple-value-call}}
+% 
+% \funref{apply}, \funref{funcall}, and \specref{multiple-value-call}
+% can return \term{multiple values} from the function applied or called.
+% \endlist
+% 
+% \itemitem{\b{Sequential Forms}}
+% 
+% \beginlist
+% \itemitem{\specref{progn}}
+% 
+% The special form \specref{progn} can return \term{multiple values} resulting
+% from evaluation of the last \term{subform}.
+% 
+% \itemitem{\term{implicit progn}}
+% 
+% Other situations are referred to as an \term{implicit progn}, in
+% which several forms are evaluated and the results of all but the last
+% form are discarded.  An \term{implicit progn} returns multiple
+% values if the last form does.  These situations include the body of a
+% \term{lambda expression}, including those constructed implicitly by
+% \macref{defmethod}, \macref{defun}, \macref{defmacro},
+% \issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+% \macref{define-compiler-macro},
+% \endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+% \specref{flet},
+% \specref{macrolet}, \specref{generic-flet}, \specref{labels},
+% \specref{generic-labels}, \macref{deftype}.  Also included are
+% bodies of the \specref{eval-when}, \specref{progv},
+% \specref{let}, \specref{let*}, \macref{when},
+% \macref{unless}, \specref{block},
+% \macref{multiple-value-bind}, and \specref{catch} \term{forms}, as well as
+% clauses in such conditional \term{forms} as \macref{case},
+% \macref{typecase}, \macref{ecase}, \macref{etypecase},
+% \macref{ccase}, and \macref{ctypecase}. If a body has no
+% \term{forms}, a single \nil\ is returned.
+% \endlist
+% 
+% \itemitem{\b{Conditional Forms}}
+% 
+% \beginlist
+% \itemitem{\specref{if}}
+% 
+% \specref{if} can return \term{multiple values} from whichever \term{subform} is selected
+% (the \i{then} form or the \i{else} form).
+% 
+% \itemitem{\macref{and}, \macref{or}}
+% 
+% \macref{and} and \macref{or} can return \term{multiple values} from the last \term{subform}
+% but not from \term{subforms} other than the last.
+% 
+% \itemitem{\macref{cond}}
+% 
+% \macref{cond} can return \term{multiple values} from the last \term{subform} of
+% the \term{implicit progn} of the selected clause.
+% If, however, the clause selected is a singleton clause,
+% then only a single value (the \term{true} value returned by the predicate)
+% is returned.  This is true even if the singleton clause is
+% the last clause of the \macref{cond}.  A final clause
+% {\tt (\i{form})} is not equivalent to {\tt (t \i{form})}
+% because the latter returns \term{multiple values} from \i{form}
+% while the former does not; a final clause of {\tt (\i{form})}
+% is instead equivalent to {\tt (t (values \i{forms}))}.
+% \endlist
+% 
+% \itemitem{\b{Returning from a Block}}
+% 
+% \beginlist
+% \itemitem{\specref{block}}
+% 
+% The \specref{block} special form can return \term{multiple values} 
+% from its last \term{subform} when it exits normally.  
+% If \specref{return-from} (or \macref{return}) is used to terminate
+% the \term{block} prematurely, then \specref{return-from} can
+% return \term{multiple values} 
+% %from its \term{subform} 
+% as the \term{values} of the terminated \term{block}.
+% Other \term{operators} that implicitly create \term{blocks},
+% such as \macref{do}, \macref{dolist}, \macref{dotimes}, 
+%         \macref{prog}, and \macref{prog*},
+% also can return \term{multiple values} specified by
+% \specref{return-from} (or \macref{return}).
+% 
+% \itemitem{\macref{do}}
+% 
+% \macref{do} can return \term{multiple values} from the last form of the
+% exit clause, exactly as if the exit clause were a \macref{cond}
+% clause.  Similarly, \macref{dolist} and \macref{dotimes} can
+% return \term{multiple values} from the \param{result-form} if that is
+% executed.  \macref{loop} can return \term{multiple values} by using
+% \macref{return} and \specref{return-from}.  These situations are
+% all examples of implicit uses of \specref{return-from}.
+% 
+% \endlist
+% 
+% \itemitem{\b{Throwing out of a Catch}}
+% 
+% \beginlist
+% 
+% \itemitem{\specref{catch}}
+% 
+% The \specref{catch} \term{form} returns \term{multiple values} if
+% the result form in a \specref{throw} exiting from
+% such a catch produces \term{multiple values}.
+% \endlist
+% 
+% \itemitem{\b{Miscellaneous Situations}}
+% 
+% \beginlist
+% 
+% \itemitem{\macref{multiple-value-prog1}}
+% 
+% \specref{multiple-value-prog1} can return \term{multiple values} from its first
+% \term{subform}.  \macref{prog1} always returns a single value.
+% 
+% \itemitem{\specref{unwind-protect}}
+% 
+% \specref{unwind-protect} returns \term{multiple values} if the form it protects
+% returns \term{multiple values}.
+% 
+% \itemitem{\specref{the}}
+% 
+% \specref{the} returns \term{multiple values} if the form it contains returns
+% \term{multiple values}.
+% \endlist
+% \endlist
+% 
+% Among special forms that never return \term{multiple values} are
+% \specref{setq}, \macref{multiple-value-setq}, \macref{prog1}, and
+% \macref{prog2}.
+% 
+% In an ordinary function call,
+% each argument form produces exactly one argument;  if such a form
+% returns zero values, \nil\ is used for the argument, and if more than one
+% value, all but the first are discarded.
+% Similarly, conditional \term{forms} (such as \specref{if} \term{forms})
+% that test the value of a form
+% will use exactly one value, the first one, from that form and discard the rest;
+% such \term{forms} will use \nil\ as the test value if zero values are returned.
+%          
+\endSubsection%{Return Values}
+
+

concept-exits.tex

@@ -0,0 +1,61 @@
+% -*- Mode: TeX -*-
+%% Exit Extents
+
+% This text was originally duplicated in each of GO, RETURN-FROM,
+% and THROW.  I thought it would be less redundant to centralize it here.
+% --sjl 7 Mar 92
+
+
+\issue{EXIT-EXTENT:MINIMAL}
+When a transfer of control is initiated by \specref{go}, 
+\specref{return-from}, or \specref{throw}
+the following events occur in order to accomplish the transfer of control.
+Note that for \specref{go}, 
+the \term{exit point} is the \term{form} within the \specref{tagbody}
+that is being executed at the time the \specref{go} is performed;
+for \specref{return-from},
+the \term{exit point} is the corresponding 
+\specref{block} \term{form};
+and for \specref{throw},
+the \term{exit point} is the corresponding 
+\specref{catch} \term{form}. 
+
+\beginlist
+\itemitem{1.} 
+ Intervening \term{exit points} are ``abandoned''
+ (\ie their \term{extent} ends 
+      and it is no longer valid to attempt to transfer control through them).
+
+\itemitem{2.} 
+ The cleanup clauses of any intervening \specref{unwind-protect} clauses
+ are evaluated.
+ 
+\itemitem{3.} 
+% added condition handlers and restarts  -- sjl 7 Mar 92
+ Intervening dynamic \term{bindings} of \declref{special} variables,
+ \term{catch tags}, \term{condition handlers}, and \term{restarts}
+ are undone.
+ 
+\itemitem{4.} 
+ The \term{extent} of the \term{exit point} being invoked ends,
+ and control is passed to the target.
+\endlist 
+ 
+The extent of an exit being ``abandoned'' because it is being passed over
+ends as soon as the transfer of control is initiated. That is,
+event 1 occurs at the beginning of the initiation of the transfer of
+control. 
+The consequences are undefined if an attempt is made to transfer control 
+to an \term{exit point} whose \term{dynamic extent} has ended.
+ 
+%Moon had me add the part about "interleaved" -kmp 13-Feb-92
+Events 2 and 3 are actually performed interleaved, in the order
+corresponding to the reverse order in which they were established.
+The effect of this is that the cleanup clauses of an \specref{unwind-protect}
+see the same dynamic \term{bindings} 
+of variables and \term{catch tags} as were
+visible when the \specref{unwind-protect} was entered.
+ 
+Event 4 occurs at the end of the transfer of control.
+ 
+\endissue{EXIT-EXTENT:MINIMAL}

concept-extensions.tex

@@ -0,0 +1,124 @@
+%-*- Mode: TeX -*-
+%%Language Extensions
+
+\issue{EXTENSIONS-POSITION:DOCUMENTATION}
+ 
+A language extension is any documented \term{implementation-defined} behavior
+of a \term{defined name} in this standard that varies from the
+behavior described in this standard, or a documented consequence of a
+situation that the standard specifies as undefined, unspecified, or
+extendable by the implementation.  For example, if this standard says
+that ``the results are unspecified,'' an extension would be to specify
+the results.
+
+\reviewer{Barmar: This contradicts previous definitions of conforming code.}
+If the correct behavior of a program depends on the results provided
+by an extension, only implementations with the same extension will
+execute the program correctly.  Note that such a program might be
+non-conforming.  Also, if this standard says that ``an implementation
+may be extended,'' a conforming, but possibly non-portable, program
+can be written using an extension.
+
+An implementation can have extensions, provided they do not alter the
+behavior of conforming code and provided they are not explicitly
+prohibited by this standard.
+
+\endissue{EXTENSIONS-POSITION:DOCUMENTATION}
+          
+The term ``extension'' refers only to extensions available upon
+startup.  An implementation is free to allow or prohibit redefinition
+of an extension.
+
+The following list contains specific guidance to implementations 
+concerning certain types of extensions.
+\beginlist
+%\itemitem{\b{Additional syntax}}
+%
+%An implementation is not allowed to extend \term{macros} 
+%and \term{special forms} to take
+%additional syntax not specified in this standard.
+ 
+%\itemitem{\b{Extra optional or named arguments}}
+% 
+%Unless explicitly allowed in this standard, 
+%implementations are not allowed to include definitions
+%of \term{functions} with extra optional or named arguments
+%with system-dependent meanings.
+%
+%When extra optional or named arguments are allowed by this
+%standard, they will be annotated as follows:
+%\term{functions} that may be
+%extended to take implementation-specific optional arguments are indicated
+%by \f{&rest ignore} in their argument list.
+%\term{functions} that may be extended
+%to take additional keyword parameters are indicated by \keyref{allow-other-keys}.
+% 
+%The goal is not to outlaw any extensions currently offered by
+%implementors, but to make the range of extensions to \term{functions} 
+%defined in
+%this standard well documented in this standard.  Implementations that want to
+%extend \term{functions} that aren't explicitly 
+%allowed to be extended can instead
+%shadow them.
+%
+% or as follows, if this proposal passes.
+%Alternate proposal: NOT-IN-STANDARD-PACKAGE
+% 
+%Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
+%provide additional named arguments to a function if the names are not in
+%an implementation-specific package (the list of these currently includes
+%the LISP, USER, and KEYWORD packages).
+% 
+
+\itemitem{\b{Extra return values}}
+
+\issue{EXTRA-RETURN-VALUES:NO} 
+An implementation must return exactly
+the number of return values specified by this standard unless the
+standard specifically indicates otherwise.
+\endissue{EXTRA-RETURN-VALUES:NO}
+
+%\itemitem{\b{Function behavior on non-standard data types}}
+%
+%An implementation does not define the behavior of \term{functions}
+%on \term{types} not explicitly permitted by this standard. 
+
+\itemitem{\b{Unsolicited messages}}
+
+\issue{UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS}
+ 
+No output can be produced by a function other than that specified in
+the standard or due to the signaling of \term{conditions}
+detected by the function.
+ 
+Unsolicited output, such as garbage collection notifications and
+autoload heralds, should not go directly to the \term{stream}
+that is the value of a \term{stream} variable defined in this
+standard, but can go indirectly to \term{terminal I/O} by using a
+\term{synonym stream} to \varref{*terminal-io*}.
+ 
+Progress reports from such functions as \funref{load} and
+\funref{compile} are considered solicited, and are not covered by
+this prohibition.
+
+\endissue{UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS}
+ 
+\itemitem{\b{Implementation of macros and special forms}}
+
+%Operators that are defined as \term{macros} or
+%\term{special forms} may be defined as \term{functions}
+%instead if the semantics can be preserved. 
+%
+%or as follows:
+%Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO
+%
+%The standard will remain silent on the issue of whether or not is
+%is valid for an implementation to implementation "macros" and 
+%"special forms" as functions.
+\issue{MACRO-AS-FUNCTION:DISALLOW}
+
+\term{Macros} and \term{special operators} defined in this standard
+must not be \term{functions}.
+\endissue{MACRO-AS-FUNCTION:DISALLOW} 
+
+\endlist

concept-filenames.tex

@@ -0,0 +1,170 @@
+% -*- Mode: TeX -*-
+
+There are many kinds of \term{file systems},
+varying widely both in their superficial syntactic details,
+		and in their underlying power and structure.
+The facilities provided by \clisp\ for referring to and manipulating \term{files}
+has been chosen to be compatible with many kinds of \term{file systems},
+while at the same time minimizing the program-visible differences 
+between kinds of \term{file systems}.
+
+%% 23.1.0 1
+Since \term{file systems} vary in their conventions for naming \term{files},
+there are two distinct ways to represent \term{filenames}:
+as \term{namestrings} and as \term{pathnames}.
+
+\beginSubsection{Namestrings as Filenames}
+
+\issue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+A \newterm{namestring} is a \term{string} that represents a \term{filename}.
+
+In general, the syntax of \term{namestrings} involves the use of 
+\term{implementation-defined} conventions, 
+usually those customary for the \term{file system} in which the named \term{file} resides.
+The only exception is the syntax of a \term{logical pathname} \term{namestring},
+which is defined in this specification; \seesection\LogPathNamestrings.
+\endissue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+
+A \term{conforming program} must never unconditionally use a
+\term{literal} \term{namestring} other than a \term{logical pathname} \term{namestring}
+because \clisp\ does not define any \term{namestring} syntax 
+other than that for \term{logical pathnames}
+that would be guaranteed to be portable.
+However, a \term{conforming program} can, if it is careful, 
+successfully manipulate user-supplied data 
+which contains or refers to non-portable \term{namestrings}.
+
+%%% 23.1.1 11
+A \term{namestring} can be \term{coerced} to a \term{pathname} by \thefunctions{pathname}
+or \funref{parse-namestring}.
+%% Not true for logical pathnames.  Anyway, better said (if at all) in the function entries.
+% The effect of these \term{functions} is necessarily
+% \term{implementation-dependent} because the format of \term{namestrings}
+% is \term{implementation-dependent}.
+
+\endSubsection%{Namestrings as Filenames}
+
+\beginSubsection{Pathnames as Filenames}
+\DefineSection{PathnamesAsFilenames}
+
+% From Chapter 21.1 ...
+%
+% \term{Pathnames} provide a means for expressing many operations that
+% manipulate files or file names in a manner that does not depend on the specific
+% format of file names on a particular file system.
+
+\newtermidx{Pathnames}{pathname} are structured \term{objects} that can represent,
+in an \term{implementation-independent} way,
+the \term{filenames} that are used natively by an underlying \term{file system}.
+
+In addition, \term{pathnames} can also represent certain partially composed 
+\term{filenames} for which an underlying \term{file system} 
+might not have a specific \term{namestring} representation.
+
+%% 23.1.1 10
+% A \term{pathname} 
+% is not necessarily the name of a specific file.
+% Rather, it is a specification (possibly only a partial specification) of
+% how to access a file.  
+
+A \term{pathname} need not correspond to any file that actually exists, 
+and more than one \term{pathname} can refer to the same file.
+For example, the \term{pathname} with a version of \kwd{newest} 
+might refer to the same file as a \term{pathname} 
+with the same components except a certain number as the version.
+Indeed, a \term{pathname} with version \kwd{newest} might refer to
+different files as time passes, because the meaning of such a \term{pathname}
+depends on the state of the file system.  
+
+Some \term{file systems} naturally use a structural model for their
+\term{filenames}, while others do not.  Within the \clisp\ \term{pathname} model, 
+all \term{filenames} are seen as having a particular structure,
+even if that structure is not reflected in the underlying \term{file system}.
+The nature of the mapping between structure imposed by \term{pathnames}
+and the structure, if any, that is used by the underlying \term{file system}
+is \term{implementation-defined}.
+
+%% 23.1.0 2
+%In order to allow code to operate in a network environment
+%that may have more than one kind of file system, the pathname facility
+%allows a file name to specify which file system (called the
+%host) is to be used.
+%Left out.
+
+%% 23.1.1 3
+Every \term{pathname} has six components:
+     a host,
+     a device,
+     a directory,
+     a name,
+     a type,
+ and a version.
+By naming \term{files} with \term{pathnames}, 
+\clisp\ programs can work in essentially the same way even in \term{file systems}
+that seem superficially quite different.
+For a detailed description of these components, \seesection\PathnameComponents.
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+\issue{PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE}%
+% %% Per X3J13. -kmp 5-Oct-93
+% The mapping of the \term{pathname} components into the concepts peculiar to 
+% each \term{file system} is \term{implementation-defined}.
+% There exist conceivable \term{pathnames} for which there is no valid mapping 
+% in a particular \term{implementation}. The time at which this error detection
+% occurs is \term{implementation-dependent}.
+The mapping of the \term{pathname} components into the concepts peculiar to
+each \term{file system} is \term{implementation-defined}.
+There exist conceivable \term{pathnames}
+for which there is no mapping to a syntactically valid \term{filename}
+in a particular \term{implementation}.
+An \term{implementation} may use various strategies in an attempt to find a mapping;
+for example, 
+an \term{implementation} may quietly truncate \term{filenames}
+that exceed length limitations imposed by the underlying \term{file system},
+or ignore certain \term{pathname} components
+for which the \term{file system} provides no support.
+If such a mapping cannot be found,
+an error \oftype{file-error} is signaled.
+
+The time at which this mapping and associated error signaling 
+occurs is \term{implementation-dependent}.
+Specifically, it may occur 
+    at the time the \term{pathname} is constructed,
+    when coercing a \term{pathname} to a \term{namestring},
+ or when an attempt is made to \term{open} or otherwise access the \term{file} 
+     designated by the \term{pathname}.
+\endissue{PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\Thenextfigure\ lists some \term{defined names} that are applicable to \term{pathnames}.
+
+\displaythree{Pathname Operations}{
+*default-pathname-defaults*&namestring&pathname-name\cr
+directory-namestring&open&pathname-type\cr
+enough-namestring&parse-namestring&pathname-version\cr
+file-namestring&pathname&pathnamep\cr
+file-string-length&pathname-device&translate-pathname\cr
+host-namestring&pathname-directory&truename\cr
+make-pathname&pathname-host&user-homedir-pathname\cr
+merge-pathnames&pathname-match-p&wild-pathname-p\cr
+}
+\endSubsection%{Pathnames as Filenames}
+
+\beginSubsection{Parsing Namestrings Into Pathnames}
+
+%% 23.1.1 11
+Parsing is the operation used to convert a \term{namestring} into a \term{pathname}.
+\issue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+Except in the case of parsing \term{logical pathname} \term{namestrings},
+\endissue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+this operation is \term{implementation-dependent},
+because the format of \term{namestrings} is \term{implementation-dependent}.
+
+%% 23.1.1 20
+A \term{conforming implementation} is free to accommodate other \term{file system}
+features in its \term{pathname} representation and provides a parser that can process 
+such specifications in \term{namestrings}.  
+\term{Conforming programs} must not depend on any such features, 
+since those features will not be portable.
+
+\endSubsection%{Parsing Namestrings Into Pathnames}

concept-files.tex

@@ -0,0 +1,138 @@
+% -*- Mode: TeX -*-
+
+%% 23.0.0 6 was left out.
+
+This section describes the \clisp\ interface to file systems.
+%% 23.0.0 5
+The model used by this interface assumes 
+     that \newtermidx{files}{file} are named by \newtermidx{filenames}{filename},
+     that a \term{filename} can be represented by a \term{pathname} \term{object}, 
+ and that given a \term{pathname} a \newterm{stream} can be constructed 
+      that connects to a \term{file} whose \term{filename} it represents.
+
+For information about opening and closing \term{files},
+and manipulating their contents, \seechapter\Streams.
+
+\Thenextfigure\ lists some \term{operators} 
+that are applicable to \term{files} and directories.
+
+\displaythree{File and Directory Operations}{
+compile-file&file-length&open\cr
+delete-file&file-position&probe-file\cr
+directory&file-write-date&rename-file\cr
+file-author&load&with-open-file\cr
+}
+
+\beginsubsection{Coercion of Streams to Pathnames}
+\DefineSection{StreamsToPathnames}
+
+A \newterm{stream associated with a file} is either a \term{file stream}
+or a \term{synonym stream} whose target is a \newterm{stream associated with a file}.
+Such streams can be used as \term{pathname designators}.
+
+Normally, when a \term{stream associated with a file} is used as a
+\term{pathname designator}, it denotes the \term{pathname} used to 
+open the \term{file}; this may be, but is not required to be, the
+actual name of the \term{file}.
+
+Some functions, such as \funref{truename} and \funref{delete-file},
+coerce \term{streams} to \term{pathnames} in a different way that 
+involves referring to the actual \term{file} that is open, which might
+or might not be the file whose name was opened originally.  Such special
+situations are always notated specifically and are not the default.
+
+\endsubsection%{Coercion of Streams to Pathnames}
+
+\beginsubsection{File Operations on Open and Closed Streams}
+\DefineSection{OpenAndClosedStreams}
+
+\issue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+
+Many \term{functions} that perform \term{file} operations accept either
+\term{open} or \term{closed} \term{streams} as \term{arguments};
+\seesection\StreamArgsToStandardizedFns.
+
+Of these, the \term{functions} in \thenextfigure\ treat \term{open} and 
+\term{closed} \term{streams} differently.
+
+\displaythree{File Functions that Treat Open and Closed Streams Differently}{
+delete-file&file-author&probe-file\cr
+directory&file-write-date&truename\cr
+}
+
+Since treatment of \term{open} \term{streams} by the \term{file system} 
+may vary considerably between \term{implementations}, however, 
+a \term{closed} \term{stream} might be the most reliable kind of
+\term{argument} for some of these functions---in particular, those in
+\thenextfigure.  For example, in some \term{file systems}, 
+\term{open} \term{files} are written under temporary names 
+and not renamed until \term{closed}
+and/or are held invisible until \term{closed}.
+In general, any code that is intended to be portable should
+use such \term{functions} carefully.
+
+\displaythree{File Functions where Closed Streams Might Work Best}{
+directory&probe-file&truename\cr
+}
+\endissue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+
+\endsubsection%{File Operations on Open and Closed Streams}
+
+\beginsubsection{Truenames}
+\DefineSection{Truenames}
+
+Many \term{file systems} permit more than one \term{filename} to designate 
+a particular \term{file}.
+
+Even where multiple names are possible, most \term{file systems} have a convention
+for generating a canonical \term{filename} in such situations.  Such a canonical
+\term{filename} (or the \term{pathname} representing such a \term{filename}) is
+called a \newterm{truename}.  
+
+%This came from the CLtL description of PROBE-FILE
+The \term{truename} of a \term{file} may differ from other \term{filenames}
+for the file because of
+     symbolic links,
+     version numbers,
+% Added to distinguish from Sandra's addition that follows. -kmp 12-Dec-91
+     logical device translations in the \term{file system},
+% Added per Sandra. -kmp 12-Dec-91
+     \term{logical pathname} translations within \clisp,
+  or other artifacts of the \term{file system}.
+
+The \term{truename} for a \term{file} is often, but not necessarily, unique for
+each \term{file}.  For instance, a Unix \term{file} with multiple hard links 
+could have several \term{truenames}.
+
+\beginsubsubsection{Examples of Truenames}
+
+For example, a DEC TOPS-20 system with \term{files} \f{PS:<JOE>FOO.TXT.1} 
+and \f{PS:<JOE>FOO.TXT.2} might permit the second \term{file} to be referred
+to as \f{PS:<JOE>FOO.TXT.0}, since the ``\f{.0}'' notation denotes ``newest''
+version of several \term{files}.
+In the same \term{file system}, a ``logical device'' ``\f{JOE:}'' might be 
+taken to refer to \f{PS:<JOE>}'' and so the names \f{JOE:FOO.TXT.2} or
+\f{JOE:FOO.TXT.0} might refer to \f{PS:<JOE>FOO.TXT.2}.
+In all of these cases, the \term{truename} of the file would probably be
+\f{PS:<JOE>FOO.TXT.2}.
+
+If a \term{file} is a symbolic link to another \term{file} (in a \term{file system}
+permitting such a thing), it is conventional for the \term{truename} to be
+the canonical name of the \term{file} after any symbolic links have been followed;
+that is, it is the canonical name of the \term{file} whose contents would
+become available if an \term{input} \term{stream} to that \term{file} were 
+opened.
+
+In the case of a \term{file} still being created (that is, of an \term{output}
+\term{stream} open to such a \term{file}), the exact \term{truename} of the file
+might not be known until the \term{stream} is closed.  In this case, 
+\thefunction{truename} might return different values for such a \term{stream}
+before and after it was closed.  In fact, before it is closed, the name returned
+might not even be a valid name in the \term{file system}---for example, while a
+file is being written, it might have version \kwdref{newest} and might only take on 
+a specific numeric value later when the file is closed even in a \term{file system}
+where all files have numeric versions.
+
+\endsubsubsection%{Examples of Truenames}
+
+\endsubsection%{Truenames}

concept-format.tex

@@ -0,0 +1,1922 @@
+% -*- Mode: TeX -*-
+%% Formatted Output
+
+\issue{PRETTY-PRINT-INTERFACE}
+\editornote{KMP: This is transplanted from FORMAT and will need a bit of work before
+ it looks good standing alone. Bear with me.}
+
+%% 22.3.1 21
+\funref{format} is useful for producing nicely formatted text, producing
+good-looking messages, and so on.  \funref{format} can generate and return
+a \term{string} or output to \param{destination}.
+
+The \param{control-string} argument to \funref{format} is actually a \term{format control}.
+% It can be any function at all that does the right things with its
+% arguments.  --sjl 16 Mar 92
+%That is, it can be either a \term{format string} or a \term{function} that was returned
+That is, it can be either a \term{format string} or a \term{function},
+for example a \term{function} returned
+by the \macref{formatter} \term{macro}.
+
+If it is a \term{function}, the \term{function} is called with the appropriate
+output stream as its first argument and the data arguments to \funref{format}
+as its remaining arguments.  The function should perform whatever output is 
+necessary and return the unused tail of the arguments (if any).
+
+The compilation process performed by \macref{formatter} produces a \term{function}
+that would do with its \term{arguments} as the \funref{format} interpreter
+would do with those \term{arguments}.
+
+The remainder of this section describes what happens if the \param{control-string}
+is a \term{format string}.  
+\endissue{PRETTY-PRINT-INTERFACE}
+
+
+% Removed redundant text --sjl 16 Mar 92
+%%% 22.3.2 6
+%\funref{format} produces formatted output by outputting the characters
+%of \param{control-string} and observing that a \term{tilde}
+%introduces a directive.  The character after the tilde, possibly preceded 
+%by prefix parameters and modifiers, specifies what kind of formatting 
+%is desired.  
+
+\param{Control-string} is composed of simple text (\term{characters}) 
+and embedded directives.
+
+%% 22.3.3 7
+\funref{format} writes the simple text as is;
+each embedded directive specifies further text output 
+that is to appear at the corresponding point within the simple text.  
+Most directives use one or more elements of \param{args} to
+create their output.
+
+%% 22.3.3 9
+A directive consists of a \term{tilde},
+optional prefix parameters
+separated by commas, optional \term{colon} and \term{at-sign} modifiers,
+and a single character indicating what kind of directive this is.
+\issue{FORMAT-ATSIGN-COLON}
+There is no required ordering between the \term{at-sign} and \term{colon} modifier.
+\endissue{FORMAT-ATSIGN-COLON}
+The \term{case} of the directive character is ignored.
+Prefix parameters are notated as signed (sign is optional) decimal numbers,
+or as a \term{single-quote} followed by a character.
+For example, \f{~5,'0d} can be used
+to print an \term{integer} 
+in decimal radix in five columns with leading zeros,
+or \f{~5,'*d} to get leading asterisks.
+
+%% 22.3.2 10
+In place of a prefix parameter to a directive, \f{V} (or \f{v}) can be used. 
+In this case, \funref{format} takes an argument from \param{args} as a parameter to
+the directive.  The argument should be an \term{integer} or \term{character}.
+If the \param{arg} used by a \f{V} parameter is \nil,
+the effect is as if the parameter had been omitted.
+\f{\#} can be used in place of a prefix parameter; it
+represents the number of \param{args} remaining to be processed.
+When used within a recursive format, in the context of \f{~?} or \f{~\{},
+the \f{\#} prefix parameter represents the number of \term{format arguments}
+remaining within the recursive call.
+
+Examples of \term{format strings}:
+
+\showtwo{Examples of format control strings}{
+\f{"~S"}       & ;This is an S directive with no parameters or modifiers.       \cr
+\f{"~3,-4:@s"} & ;This is an S directive with two parameters, \f{3} and \f{-4}, \cr
+ 	       & ; and both the \term{colon} and \term{at-sign} flags.          \cr
+\f{"~,+4S"}    & ;Here the first prefix parameter is omitted and takes          \cr
+ 	       & ; on its default value, while the second parameter is \f{4}.   \cr
+}
+
+\funref{format} sends the output to \param{destination}.
+If \param{destination} is \nil,
+\funref{format} creates and returns a \term{string} 
+containing the output from \param{control-string}.
+If \param{destination} is \term{non-nil}, 
+it must be a \term{string} with a \term{fill pointer}, 
+a \term{stream}, or the symbol \t.
+If \param{destination} is a \term{string} with a \term{fill pointer}, 
+the output is added to the end of the \term{string}. 
+If \param{destination} is a \term{stream}, 
+the output is sent to that \term{stream}. 
+If \param{destination} is \t,
+the output is sent to \term{standard output}.
+
+%% 22.3.2 8 
+%%(left out)
+
+
+%% 22.3.2 15
+In the description of the directives that follows,
+the term \j{arg} in general
+refers to the next item of the set of \param{args} to be processed.
+The word or phrase at the beginning of each description is a mnemonic
+for the directive.
+\issue{FORMAT-PRETTY-PRINT:YES}
+\funref{format} directives do not bind any of the printer control
+variables (\varref{*print-...*}) except as specified in the following
+descriptions.
+   Implementations may specify the binding of new, implementation-specific 
+printer control variables for each \funref{format} directive, but they
+    may neither bind any standard printer control variables not
+    specified in description of a \funref{format} 
+directive nor fail to bind
+    any standard printer control variables as specified in the
+    description.
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+% This section needs a lot of work on fonts.  Maybe all the syntax parts
+% of the format directives should use \param instead of \i.  Or change the
+% \i{foo} to \i{foo\/} to fix kerning problems.
+%
+% I decided to make a \j{...} which is \i{...\/} instead.
+% It's not pretty but it's fast and I'm out of time. -kmp 30-Aug-93.
+
+\beginsubsection{FORMAT Basic Output}
+
+\beginsubsubsection{Tilde C: Character}
+\idxtext{C (format directive)}\idxtext{Tilde C (format directive)}
+
+
+%% 22.3.2 38   
+               
+The next \j{arg} should be a \term{character}; 
+it is printed
+according to the modifier flags.
+
+
+%% 22.3.2 39
+\issue{FORMAT-OP-C}
+\f{~C} prints the \term{character} 
+as if by using \funref{write-char} if it is a \term{simple character}.
+\term{Characters} that are not \term{simple}
+are not necessarily printed as if by \funref{write-char},
+but are displayed in an \term{implementation-defined}, abbreviated format.
+For example,
+
+\code
+ (format nil "~C" #\\A) \EV "A"
+ (format nil "~C" #\\Space) \EV " "
+\endcode
+\endissue{FORMAT-OP-C}
+
+%% 22.3.2 40
+\f{~:C} is the same as \f{~C} for \term{printing} \term{characters},
+but other \term{characters} are ``spelled out.''  The intent is that this
+is a ``pretty'' format for printing characters.
+For \term{simple} \term{characters} that are not \term{printing},
+what is spelled out is the \term{name} of the \term{character} (see \funref{char-name}).
+For \term{characters} that are not \term{simple} and not \term{printing},
+what is spelled out is \term{implementation-defined}.
+For example, 
+
+\code
+ (format nil "~:C" #\\A) \EV "A"
+ (format nil "~:C" #\\Space) \EV "Space"
+;; This next example assumes an implementation-defined "Control" attribute.
+ (format nil "~:C" #\\Control-Space)
+\EV "Control-Space"
+\OV "c-Space"
+\endcode
+
+%% 22.3.2 41  
+\f{~:@C} prints what \f{~:C} would, and then
+if the \term{character} requires unusual shift keys on the keyboard to type it,
+this fact is mentioned.  For example,
+
+\begingroup
+\def\Partial{$\partial$}
+\code
+ (format nil "~:@C" #\\Control-Partial) \EV "Control-{\Partial} (Top-F)"  
+\endcode
+\endgroup
+
+This is the format used for telling the user about a key he is expected to type,
+in prompts, for instance.  The precise output may depend not only
+on the implementation, but on the particular I/O devices in use.
+                           
+%% 22.3.2 42 
+\f{~@C} 
+prints the \term{character} in a way that the \term{Lisp reader} can understand,
+using \f{\#\\} syntax.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~@C}  binds \varref{*print-escape*} to \t.
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde C: Character}
+
+\beginsubsubsection{Tilde Percent: Newline}
+\idxtext{Percent (format directive)}\idxtext{Tilde Percent (format directive)}
+
+%% 22.3.2 96
+
+This outputs a \f{\#\\Newline} character, thereby terminating the current
+output line and beginning a new one.
+\f{~\j{n}\%} outputs \j{n} newlines.
+No \j{arg} is used.  
+
+\endsubsubsection%{Tilde Percent: Newline}
+
+\beginsubsubsection{Tilde Ampersand: Fresh-Line}
+\idxtext{Ampersand (format directive)}\idxtext{Tilde Ampersand (format directive)}
+
+%% 22.3.2 97
+
+Unless it can be determined that the output stream
+is already at the beginning of a line,
+this outputs a newline.
+\f{~\j{n}\&} calls \funref{fresh-line}
+and then outputs \j{n}\minussign 1 newlines.
+\f{~0\&} does nothing.
+
+\endsubsubsection%{Tilde Ampersand: Fresh-Line}
+
+\beginsubsubsection{Tilde Vertical-Bar: Page}
+\idxtext{Vertical-Bar (format directive)}\idxtext{Tilde Vertical-Bar (format directive)}
+
+%% 22.3.2 98
+
+This outputs a page separator character, if possible.
+\f{~\j{n}|} does this \j{n} times.
+
+\endsubsubsection%{Tilde Vertical-Bar: Page}
+
+%% 22.3.2 99
+
+\beginsubsubsection{Tilde Tilde: Tilde}
+\idxtext{Tilde (format directive)}\idxtext{Tilde Tilde (format directive)}
+
+This outputs a \term{tilde}.  \f{~\j{n}~} outputs \j{n} tildes.
+
+\endsubsubsection%{Tilde Tilde: Tilde}
+
+\endsubsection%{FORMAT Basic Output}
+
+\beginsubsection{FORMAT Radix Control}
+
+\beginsubsubsection{Tilde R: Radix}
+\idxtext{R (format directive)}\idxtext{Tilde R (format directive)}
+
+%% 22.3.2 29
+
+\f{~\j{n}R} prints \j{arg} in radix \j{n}.
+The modifier flags and any remaining parameters are used as for
+the \f{~D} directive.
+\f{~D} is the same as \f{~10R}.  
+The full form is 
+\f{~\j{radix},\j{mincol},\j{padchar},\j{commachar},\j{comma-interval}R}.
+
+%% 22.3.2 30
+If no prefix parameters are given to \f{~R}, then a different
+interpretation is given.  The argument should be an \term{integer}.
+For example, if \j{arg} is 4:
+
+%% 22.3.2 31
+\beginlist
+\itemitem{\bull}
+\f{~R} prints \j{arg} as a cardinal English number: \f{four}.
+
+%% 22.3.2 32
+\itemitem{\bull}
+\f{~:R} prints \j{arg} as an ordinal English number: \f{fourth}.
+
+%% 22.3.2 33
+\itemitem{\bull}   
+\f{~@R} prints \j{arg} as a Roman numeral: \f{IV}.
+
+%% 22.3.2 34
+\itemitem{\bull}      
+\f{~:@R} prints \j{arg} as an old Roman numeral: \f{IIII}.
+\endlist
+
+\issue{FORMAT-COMMA-INTERVAL}
+For example:
+
+\code
+ (format nil "~,,' ,4:B" 13) \EV "1101"
+ (format nil "~,,' ,4:B" 17) \EV "1 0001"
+ (format nil "~19,0,' ,4:B" 3333) \EV "0000 1101 0000 0101"
+ (format nil "~3,,,' ,2:R" 17) \EV "1 22"
+ (format nil "~,,'|,2:D" #xFFFF) \EV  "6|55|35"
+\endcode
+\endissue{FORMAT-COMMA-INTERVAL}
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+If and only if the first parameter, \j{n}, is supplied,
+\f{~R} binds
+     \varref{*print-escape*} to \term{false},
+     \varref{*print-radix*} to \term{false}, 
+     \varref{*print-base*} to \j{n},
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+
+If and only if no parameters are supplied,
+\f{~R} binds \varref{*print-base*} to \f{10}.
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde R: Radix}
+
+\beginsubsubsection{Tilde D: Decimal}
+\idxtext{D (format directive)}\idxtext{Tilde D (format directive)}
+
+%% 22.3.2 20
+
+An \j{arg}, which should be an \term{integer}, 
+is printed in decimal radix.
+\f{~D} will never put a decimal point after the number.
+
+%% 22.3.2 21
+\f{~\j{mincol}D} uses 
+a column width of \j{mincol}; spaces are inserted on
+the left if the number requires fewer than \j{mincol} columns for its digits
+and sign.  If the number doesn't fit in \j{mincol} columns, additional columns
+are used as needed.
+
+%% 22.3.2 22
+\f{~\j{mincol},\j{padchar}D} uses \j{padchar} as the pad character
+instead of space.
+
+%% 22.3.2 23
+If \j{arg} is not an \term{integer}, it is printed in \f{~A} format and decimal base.
+
+%% 22.3.2 24
+The \f{@} modifier causes the number's sign to be printed always; the default
+is to print it only if the number is negative.
+\issue{FORMAT-COMMA-INTERVAL}
+The \f{:} modifier causes commas to be printed between groups of digits;
+\j{commachar} may be used to change the character used as the comma.
+\j{comma-interval} 
+must be an \term{integer} and defaults to 3.  When the \f{:} 
+modifier is given to any of
+these directives, the \j{commachar} 
+is printed between groups of \j{comma-interval}
+digits.
+\endissue{FORMAT-COMMA-INTERVAL}
+
+Thus the most general form of \f{~D} is
+\f{~\j{mincol},\j{padchar},\j{commachar},\j{comma-interval}D}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~D} binds
+     \varref{*print-escape*} to \term{false},
+     \varref{*print-radix*} to \term{false},
+     \varref{*print-base*} to \f{10},
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde D: Decimal}
+
+\beginsubsubsection{Tilde B: Binary}
+\idxtext{B (format directive)}\idxtext{Tilde B (format directive)}
+
+%% 22.3.2 25
+
+This is just like \f{~D} but prints in binary radix (radix 2)
+instead of decimal.  The full form is therefore
+\f{~\j{mincol},\j{padchar},\j{commachar},\j{comma-interval}B}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~B} binds
+     \varref{*print-escape*} to \term{false},
+     \varref{*print-radix*} to \term{false},
+     \varref{*print-base*} to \f{2},
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde B: Binary}
+
+\beginsubsubsection{Tilde O: Octal}
+\idxtext{O (format directive)}\idxtext{Tilde O (format directive)}
+
+%% 22.3.2 26
+
+This is just like \f{~D} but prints in octal radix (radix 8)
+instead of decimal.  The full form is therefore
+\f{~\j{mincol},\j{padchar},\j{commachar},\j{comma-interval}O}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~O} binds
+     \varref{*print-escape*} to \term{false},
+     \varref{*print-radix*} to \term{false},
+     \varref{*print-base*} to \f{8},
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde O: Octal}
+
+\beginsubsubsection{Tilde X: Hexadecimal}
+\idxtext{X (format directive)}\idxtext{Tilde X (format directive)}
+
+%% 22.3.2 27
+
+This is just like \f{~D} but prints in hexadecimal radix
+(radix 16) instead of decimal.  The full form is therefore
+\f{~\j{mincol},\j{padchar},\j{commachar},\j{comma-interval}X}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~X} binds
+     \varref{*print-escape*} to \term{false},
+     \varref{*print-radix*} to \term{false},
+     \varref{*print-base*} to \f{16},
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde X: Hexadecimal}
+
+\endsubsection%{FORMAT Radix Control}
+
+\beginsubsection{FORMAT Floating-Point Printers}
+
+\beginsubsubsection{Tilde F: Fixed-Format Floating-Point}
+\idxtext{F (format directive)}\idxtext{Tilde F (format directive)}
+
+%% 22.3.2 43
+
+The next \j{arg} is printed as a \term{float}.
+
+%% 22.3.2 44
+The full form is \f{~\j{w},\j{d},\j{k},\j{overflowchar},\j{padchar}F}.
+The parameter \j{w}
+is the width of the field to be printed; \j{d} is the number
+of digits to print after the decimal point; \j{k} is a scale factor
+that defaults to zero.
+
+%% 22.3.2 45
+Exactly \j{w} characters will
+be output.  First, leading copies of the character \j{padchar}
+(which defaults to a space) are printed, if necessary, to pad the
+field on the left.
+If the \j{arg} is negative, then a minus sign is printed;
+if the \j{arg} is not negative, then a plus sign is printed
+if and only if the \f{@}
+modifier was supplied.  Then a sequence
+of digits, containing a single embedded decimal point, is printed;
+this represents the magnitude of the value of \j{arg} times $10^\j{k}$,
+rounded to \j{d} fractional digits.                         
+When rounding up and rounding down would produce printed values
+equidistant from the scaled value of \j{arg}, then the implementation
+is free to use either one.  For example, printing the argument
+\f{6.375} using the format \f{~4,2F} may correctly produce
+either \f{6.37} or \f{6.38}.
+Leading zeros are not permitted, except that a single
+zero digit is output before the decimal point if the printed value
+is less than one, and this single zero digit is not output
+at all if \j{w}=\j{d}+1.
+
+%% 22.3.2 46
+If it is impossible to print the value in the required format in a field
+of width \j{w}, then one of two actions is taken.  If the
+parameter \j{overflowchar} is supplied, then \j{w} copies of that
+parameter are printed instead of the scaled value of \j{arg}.
+If the \j{overflowchar} parameter is omitted, then the scaled value
+is printed using more than \j{w} characters, as many more as may be
+needed.
+
+%% 22.3.2 47
+If the \j{w} parameter is omitted, then the field is of variable width.
+In effect, a value is chosen
+for \j{w} in such a way that no leading pad characters need to be printed
+and exactly \j{d} characters will follow the decimal point.
+For example, the directive \f{~,2F} will print exactly
+two digits after the decimal point and as many as necessary before the
+decimal point.
+
+%% 22.3.2 48
+If the parameter \j{d} is omitted, then there is no constraint
+on the number of digits to appear after the decimal point.
+A value is chosen for \j{d} in such a way that as many digits
+as possible may be printed subject to the width constraint
+imposed by the parameter \j{w} and the constraint that no trailing
+zero digits may appear in the fraction, except that if the
+fraction to be printed is zero, then a single zero digit should
+appear after the decimal point if permitted by the width constraint.
+
+%% 22.3.2 49
+If both \j{w} and \j{d} are omitted, then the effect is to print
+the value using ordinary free-format output; \funref{prin1} uses this format
+for any number whose magnitude is either zero or between
+$10^{-3}$ (inclusive) and $10^7$ (exclusive).
+
+%% 22.3.2 50
+If \j{w} is omitted, then if the magnitude of \j{arg} is so large (or, if
+\j{d} is also omitted, so small) that more than 100 digits would have to
+be printed, then an implementation is free, at its discretion, to print
+the number using exponential notation instead, as if by the directive
+\f{~E} (with all parameters to \f{~E} defaulted, not
+taking their values from the \f{~F} directive).
+
+%% 22.3.2 51
+If \j{arg} is a \term{rational} 
+number, then it is coerced to be a \term{single float}
+and then printed.  Alternatively, an implementation is permitted to
+process a \term{rational} 
+number by any other method that has essentially the
+same behavior but avoids loss of precision or overflow
+because of the coercion.  If \j{w} and \j{d} are
+not supplied and the number has no exact decimal representation,
+for example \f{1/3}, some precision cutoff must be chosen
+by the implementation since only a finite number of digits may be printed.
+
+%% 22.3.2 52
+If \j{arg} is a \term{complex} number or some non-numeric
+\term{object}, 
+then it is printed using the format directive \f{~\j{w}D},
+thereby printing it in decimal radix and a minimum field width of \j{w}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~F} binds
+    \varref{*print-escape*} to \term{false}
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde F: Fixed-Format Floating-Point}
+
+\beginsubsubsection{Tilde E: Exponential Floating-Point}
+\idxtext{E (format directive)}\idxtext{Tilde E (format directive)}
+
+%% 22.3.2 62
+
+The next \j{arg} is printed as a \term{float} in exponential notation.
+
+%% 22.3.2 63
+The full form is
+\f{~\j{w},\j{d},\j{e},\j{k},\j{overflowchar},\j{padchar},\j{exponentchar}E}.
+The parameter \j{w}
+is the width of the field to be printed; \j{d} is the number
+of digits to print after the decimal point; \j{e} is the number
+of digits to use when printing the exponent;
+\j{k} is a scale factor that defaults to one (not zero).
+
+%% 22.3.2 64
+Exactly \j{w} characters will
+be output.  First, leading copies of the character \j{padchar}
+(which defaults to a space) are printed, if necessary, to pad the
+field on the left.
+If the \j{arg} is negative, then a minus sign is printed;
+if the \j{arg} is not negative, then a plus sign is printed
+if and only if the \f{@}
+modifier was supplied.  Then a sequence
+of digits containing a single embedded decimal point is printed.
+The form of this sequence of digits depends on the scale factor \j{k}.
+If \j{k} is zero, then \j{d} digits are printed after the decimal
+point, and a single zero digit appears before the decimal point if
+the total field width will permit it.  If \j{k} is positive,
+then it must be strictly less than \j{d}+2;  \j{k} significant digits
+are printed before the decimal point, and \j{d}\minussign \j{k}+1
+digits are printed after the decimal point.  If \j{k} is negative,
+then it must be strictly greater than \minussign \j{d};
+a single zero digit appears before the decimal point if
+the total field width will permit it, and after the decimal point
+are printed first
+\minussign \j{k} zeros and then \j{d}+\j{k} significant digits.
+The printed fraction must be properly rounded.         
+When rounding up and rounding down would produce printed values
+equidistant from the scaled value of \j{arg}, then the implementation
+is free to use either one.  For example, printing the argument
+\f{637.5} using the format \f{~8,2E} may correctly produce
+either \f{6.37E+2} or \f{6.38E+2}.
+
+%% 22.3.2 65
+Following the digit sequence, the exponent is printed.
+First the character parameter \j{exponentchar} is printed; if this
+parameter is omitted, then the \term{exponent marker} that
+\funref{prin1} would use is printed, as determined from the
+type of the \term{float} and the current value of
+\varref{*read-default-float-format*}.
+Next, either a plus sign or a minus sign
+is printed, followed by \j{e} digits representing the power of
+ten by which the printed fraction must be multiplied
+to properly represent the rounded value of \j{arg}.
+
+%% 22.3.2 66
+If it is impossible to print the value in the required format in a field
+of width \j{w}, possibly because \j{k} is too large or too small
+or because the exponent cannot be printed in \j{e} character positions,
+then one of two actions is taken.  If the
+parameter \j{overflowchar} is supplied, then \j{w} copies of that
+parameter are printed instead of the scaled value of \j{arg}.
+If the \j{overflowchar} parameter is omitted, then the scaled value
+is printed using more than \j{w} characters, as many more as may be
+needed; if the problem is that \j{d} is too small for the supplied \j{k}
+or that \j{e} is too small, then a larger value is used for \j{d} or \j{e}
+as may be needed.
+
+%% 22.3.2 67
+If the \j{w} parameter is omitted, then the field is of variable width.
+In effect a value is chosen
+for \j{w} in such a way that no leading pad characters need to be printed.
+
+%% 22.3.2 68
+If the parameter \j{d} is omitted, then there is no constraint
+on the number of digits to appear.
+A value is chosen for \j{d} in such a way that as many digits
+as possible may be printed subject to the width constraint
+imposed by the parameter \j{w}, the constraint of the scale factor \j{k},
+and the constraint that no trailing
+zero digits may appear in the fraction, except that if the
+fraction to be printed is zero then a single zero digit should
+appear after the decimal point.
+
+%% 22.3.2 69
+If the parameter \j{e} is omitted, then the exponent is printed
+using the smallest number of digits necessary to represent its value.
+
+%% 22.3.2 70
+If all of \j{w}, \j{d}, and \j{e} are omitted, then the effect is to print
+the value using ordinary free-format exponential-notation output;
+\funref{prin1} uses 
+\issue{FORMAT-E-EXPONENT-SIGN:FORCE-SIGN}
+a similar
+\endissue{FORMAT-E-EXPONENT-SIGN:FORCE-SIGN}
+format for any non-zero number whose magnitude
+is less than $10^{-3}$ or greater than or equal to $10^7$.
+\issue{FORMAT-E-EXPONENT-SIGN:FORCE-SIGN}
+The only difference is that the \f{~E} 
+directive always prints a plus or minus sign in front of the
+    exponent, while \funref{prin1} omits the plus sign if the exponent is
+    non-negative.
+\endissue{FORMAT-E-EXPONENT-SIGN:FORCE-SIGN}
+
+%% 22.3.2 71       
+If \j{arg} is a \term{rational} 
+number, then it is coerced to be a \term{single float}
+and then printed.  Alternatively, an implementation is permitted to
+process a \term{rational} 
+number by any other method that has essentially the
+same behavior but avoids loss of precision or overflow
+because of the coercion.  If \j{w} and \j{d} are
+unsupplied and the number has no exact decimal representation,
+for example \f{1/3}, some precision cutoff must be chosen
+by the implementation since only a finite number of digits may be printed.
+
+%% 22.3.2 72
+If \j{arg} is a \term{complex} number or some non-numeric
+\term{object}, 
+then it is printed using the format directive \f{~\j{w}D},
+thereby printing it in decimal radix and a minimum field width of \j{w}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~E} binds
+     \varref{*print-escape*} to \term{false}
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde E: Exponential Floating-Point}
+
+\beginsubsubsection{Tilde G: General Floating-Point}
+\idxtext{G (format directive)}\idxtext{Tilde G (format directive)}
+
+%% 22.3.2 82
+
+The next \j{arg} is printed as a \term{float} 
+in either fixed-format or exponential notation as appropriate.
+
+%% 22.3.2 83
+The full form is \f{~\j{w},\j{d},\j{e},\j{k},\j{overflowchar},\j{padchar},\j{exponentchar}G}.
+The format in which to print \j{arg} depends on the magnitude (absolute
+value) of the \j{arg}.  Let \j{n} be an integer such that
+$10^{\j{n}-1}$ $\le$ |\j{arg}| < $10^\j{n}$.
+Let \j{ee} equal \j{e}+2, or 4 if \j{e} is omitted.
+Let \j{ww} equal \j{w}\minussign \j{ee},
+or \nil\ if \j{w} is omitted.  If \j{d} is omitted, first let \j{q}
+be the number of digits needed to print \j{arg} with no loss
+of information and without leading or trailing zeros;
+then let \j{d} equal \f{(max \j{q} (min \j{n} 7))}.
+Let \j{dd} equal \j{d}\minussign \j{n}.
+
+%% 22.3.2 84
+If 0 $\le$ \j{dd} $\le$ \j{d}, then \j{arg} is printed
+as if by the format directives
+                                                                         
+%!!! ",," ??? -kmp 12-May-91
+\f{~\j{ww},\j{dd},,\j{overflowchar},\j{padchar}F~\j{ee}@T}
+
+Note that the scale factor \j{k} is not passed to the \f{~F}
+directive.  For all other values of \j{dd}, \j{arg} is printed as if
+by the format directive
+
+\f{~\j{w},\j{d},\j{e},\j{k},\j{overflowchar},\j{padchar},\j{exponentchar}E}
+
+%% 22.3.2 85               
+In either case, an \f{@}
+modifier is supplied to the \f{~F}
+or \f{~E} directive if and only if one was supplied to the
+\f{~G} directive.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~G} binds
+     \varref{*print-escape*} to \term{false}
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde G: General Floating-Point}
+
+\beginsubsubsection{Tilde Dollarsign: Monetary Floating-Point}
+\idxtext{Dollarsign (format directive)}\idxtext{Tilde Dollarsign (format directive)}
+
+%% 22.3.2 90
+
+The next \j{arg} is printed as a \term{float} in fixed-format notation.  
+
+%% 22.3.2 91
+The full form is \f{~\j{d},\j{n},\j{w},\j{padchar}\$}.
+The parameter \j{d} is the number
+of digits to print after the decimal point (default value 2);
+\j{n} is the minimum number of digits to print before the decimal
+point (default value 1);
+\j{w} is the minimum total width of the field to be printed (default
+value 0).
+
+%% 22.3.2 92
+First padding and the sign are output.
+If the \j{arg} is negative, then a minus sign is printed;
+if the \j{arg} is not negative, then a plus sign is printed
+if and only if the \f{@} modifier was supplied.  
+If the \f{:} modifier is used, the sign appears before any padding,
+and otherwise after the padding.
+If \j{w} is supplied and the number of other characters to be output
+is less than \j{w}, then copies of \j{padchar} (which defaults
+to a space) are output to
+make the total field width equal \j{w}.
+Then \j{n} digits are printed for the integer part of \j{arg},
+with leading zeros if necessary; then a decimal point;
+then \j{d} digits of fraction, properly rounded.
+
+%% 22.3.2 93
+If the magnitude of \j{arg} is so large that more than \j{m} digits would
+have to be printed, where \j{m} is the larger of \j{w} and 100, then an
+implementation is free, at its discretion, to print the number using
+exponential notation instead, as if by the directive
+\f{~\j{w},\j{q},,,,\j{padchar}E}, where \j{w} and \j{padchar} are
+present or omitted according to whether they were present or omitted in
+the \f{~\$} directive, and where \j{q}=\j{d}+\j{n}\minussign 1,
+where \j{d} and \j{n} are the (possibly default) values given to the
+\f{~\$} directive.
+
+%% 22.3.2 94
+If \j{arg} is a \term{rational} 
+number, then it is coerced to be a \term{single float}
+and then printed.  Alternatively, an implementation is permitted to
+process a \term{rational} number by any 
+other method that has essentially the
+same behavior but avoids loss of precision or overflow
+because of the coercion.
+
+%% 22.3.2 95
+If \j{arg} is a \term{complex} number or some non-numeric
+\term{object},
+then it is printed using the format directive \f{~\j{w}D},
+thereby printing it in decimal radix and a minimum field width of \j{w}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~\$} binds \varref{*print-escape*} to \term{false}
+\issue{PRINC-READABLY:X3J13-DEC-91}
+ and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde Dollarsign: Monetary Floating-Point}
+
+\endsubsection%{FORMAT Floating-Point Printers}
+
+\beginsubsection{FORMAT Printer Operations}
+\DefineSection{FORMATPrinterOps}
+
+\beginsubsubsection{Tilde A: Aesthetic}
+\idxtext{A (format directive)}\idxtext{Tilde A (format directive)}
+
+%% A originally stood for ASCII. This seems like a bad mnemonic in a portable standard.
+%% Replaced it with "Aesthetic". -kmp 30-Aug-93
+
+%% 22.3.2 16
+
+An \j{arg}, any \term{object}, 
+is printed without escape characters
+(as by \funref{princ}).  If \j{arg} is a \term{string}, 
+its \term{characters}
+will be output verbatim.
+If \j{arg} is \nil\ it will be printed as \nil;
+the \term{colon} modifier (\f{~:A}) will cause an \j{arg} of \nil\ to be printed as \empty,
+but if \j{arg} is a composite structure, such as a \term{list} or \term{vector},
+any contained occurrences of \nil\ will still be printed as \nil.
+
+%% 22.3.2 17
+\f{~\j{mincol}A} inserts spaces on the right, if necessary, to make the
+width at least \j{mincol} columns.  The \f{@}
+modifier causes the spaces
+to be inserted on the left rather than the right.
+
+%% 22.3.2 18
+\f{~\j{mincol},\j{colinc},\j{minpad},\j{padchar}A} 
+is the full form of \f{~A},
+which allows control of the padding.
+The \term{string} is padded on the right (or on the left if the
+\f{@} modifier is used) with at least \j{minpad} copies
+of \j{padchar}; padding characters are then inserted \j{colinc} characters
+at a time until the total width is at least \j{mincol}.
+The defaults are \f{0} for \j{mincol} and \j{minpad}, \f{1} for \j{colinc},
+and the space character for \j{padchar}.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~A} binds \varref{*print-escape*} to \term{false},
+\issue{PRINC-READABLY:X3J13-DEC-91}
+and \varref{*print-readably*} to \term{false}.
+\endissue{PRINC-READABLY:X3J13-DEC-91}
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde A: Aesthetic}
+
+\beginsubsubsection{Tilde S: Standard}
+\idxtext{S (format directive)}\idxtext{Tilde S (format directive)}
+
+%% S originally stood for S-expression, a term which no longer has any meaning.
+%% Replaced it with "Standard", since this is the standard lisp representation.
+%% -kmp 30-Aug-93
+
+%% 22.3.2 19
+
+This is just like \f{~A}, but \j{arg} is printed with escape
+characters (as by \funref{prin1} rather than \f{princ}).  The output is
+therefore suitable for input to \funref{read}.  \f{~S} accepts
+all the arguments and modifiers that \f{~A} does.
+
+\issue{FORMAT-PRETTY-PRINT:YES}
+\f{~S} binds \varref{*print-escape*} to \t.
+\endissue{FORMAT-PRETTY-PRINT:YES}
+
+\endsubsubsection%{Tilde S: Standard}
+
+\issue{PRETTY-PRINT-INTERFACE}
+\beginsubsubsection{Tilde W: Write}
+\idxtext{W (format directive)}\idxtext{Tilde W (format directive)}
+
+An argument, any \term{object}, is printed obeying every printer control
+variable (as by \funref{write}).  In addition, \f{~W} interacts correctly with depth
+abbreviation, by not resetting the depth counter to zero.  \f{~W} does not
+accept parameters.  If given the \term{colon} modifier, \f{~W} binds \varref{*print-pretty*}
+to \term{true}.  If given the \term{at-sign} modifier, \f{~W} binds \varref{*print-level*}
+and \varref{*print-length*} to \nil.
+ 
+\f{~W} provides automatic support for the detection of circularity and
+sharing.  If \thevalueof{*print-circle*} is not \nil\ and \f{~W} is applied
+to an argument that is a circular (or shared) reference, an appropriate 
+\f{\#\param{n}\#} marker is inserted in the output instead of printing the argument.
+ 
+\endsubsubsection%{Tilde W: Write}
+\endissue{PRETTY-PRINT-INTERFACE}
+
+\endsubsection%{FORMAT Printer Operations}
+
+\beginsubsection{FORMAT Pretty Printer Operations}
+
+\issue{PRETTY-PRINT-INTERFACE}
+
+The following constructs provide access to the \term{pretty printer}:
+
+\beginsubsubsection{Tilde Underscore: Conditional Newline}
+\DefineSection{TildeUnderscore}
+\idxtext{Underscore (format directive)}\idxtext{Tilde Underscore (format directive)}
+
+Without any modifiers, \f{~_} is the same as \f{(pprint-newline :linear)}.
+\f{~@_}  is the same as \f{(pprint-newline :miser)}.
+\f{~:_}  is the same as \f{(pprint-newline :fill)}.
+\f{~:@_} is the same as \f{(pprint-newline :mandatory)}.
+
+\endsubsubsection%{Tilde Underscore: Conditional Newline}
+
+\beginsubsubsection{Tilde Less-Than-Sign: Logical Block}
+\DefineSection{TildeLessThanLogicalBlock}
+\idxtext{Less-Than-Sign (format directive)}\idxtext{Tilde Less-Than-Sign (format directive)}
+
+\f{~<...~:>}
+
+If \f{~:>} is used to terminate a \f{~<...~>},
+the directive is equivalent to a call to \macref{pprint-logical-block}.
+The argument corresponding to the \f{~<...~:>} directive is treated in
+the same way as the \term{list} argument to \funref{pprint-logical-block},
+thereby providing automatic support for non-\term{list} arguments and
+the detection of circularity, sharing, and depth abbreviation.  
+The portion of the \param{control-string} nested within the \f{~<...~:>}
+specifies the \kwd{prefix} (or \kwd{per-line-prefix}), \kwd{suffix},
+and body of the \macref{pprint-logical-block}.
+ 
+The \param{control-string} portion enclosed by \f{~<...~:>} can be divided
+into segments \f{~<\param{prefix}~;\param{body}~;\param{suffix}~:>}
+by \f{~;} directives.  If the first section is terminated by \f{~@;}, 
+it specifies a per-line prefix rather than a simple prefix.  
+The \param{prefix} and \param{suffix} cannot contain format directives.  
+An error is signaled if either the prefix or suffix fails to be a
+constant string or if the enclosed portion is divided into more than three segments.
+ 
+If the enclosed portion is divided into only two segments, the \param{suffix}
+defaults to the null string.  If the enclosed portion consists of only
+a single segment, both the \param{prefix} and the \param{suffix} default to 
+the null string.  If the \term{colon} modifier is used (\ie \f{~:<...~:>}),
+the \param{prefix} and \param{suffix} default to \f{"("} and \f{")"}
+(respectively) instead of the null string.
+ 
+The body segment can be any arbitrary \term{format string}.
+This \term{format string} is applied to the elements of the list
+corresponding to the \f{~<...~:>} directive as a whole.
+Elements are extracted from this list using \macref{pprint-pop},
+thereby providing automatic support for malformed lists, and the detection
+of circularity, sharing, and length abbreviation.
+Within the body segment, \f{~{\hat}} acts like \macref{pprint-exit-if-list-exhausted}.
+ 
+\f{~<...~:>} supports a feature not supported by \macref{pprint-logical-block}.
+If \f{~:@>} is used to terminate the directive (\ie \f{~<...~:@>}), 
+then a fill-style conditional newline is automatically inserted after each
+group of blanks immediately contained in the body (except for blanks
+after a ~\NewlineChar\ directive).  This makes it easy to achieve the
+equivalent of paragraph filling.
+ 
+If the \term{at-sign} modifier is used with \f{~<...~:>}, the entire remaining argument
+list is passed to the directive as its argument.  All of the remaining
+arguments are always consumed by \f{~@<...~:>}, even if they are not all used
+by the \term{format string} nested in the directive.  Other than the difference in
+its argument, \f{~@<...~:>} is exactly the same as \f{~<...~:>} except that
+circularity detection is not applied if \f{~@<...~:>} is encountered at top
+level in a \term{format string}.  This ensures that circularity detection is
+applied only to data lists, not to \term{format argument} \term{lists}.
+
+\f{" . \#\param{n}\#"} is printed if circularity or sharing has to be indicated
+for its argument as a whole.
+ 
+To a considerable extent, the basic form of the directive \f{~<...~>} is
+incompatible with the dynamic control of the arrangement of output by
+\f{~W}, \f{~_}, \f{~<...~:>}, \f{~I}, and \f{~:T}.  As a result, an error 
+is signaled if any of these directives is nested within \f{~<...~>}.  
+Beyond this, an error is also signaled if the \f{~<...~:;...~>} form of
+\f{~<...~>} is used in the same \term{format string} with 
+\f{~W}, \f{~_}, \f{~<...~:>}, \f{~I}, or \f{~:T}.
+ 
+See also \secref\TildeLessThanJustification.
+
+\endsubsubsection%{Tilde Less-Than-Sign: Logical Block}
+
+\beginsubsubsection{Tilde I: Indent}
+\DefineSection{TildeI}
+\idxtext{I (format directive)}\idxtext{Tilde I (format directive)}
+ 
+\f{~\param{n}I}  is the same as \f{(pprint-indent :block n)}.
+
+\f{~\param{n}:I} is the same as \f{(pprint-indent :current n)}.
+In both cases, \param{n} defaults to zero, if it is omitted.
+ 
+\endsubsubsection%{Tilde I: Indent}
+
+\beginsubsubsection{Tilde Slash: Call Function}
+\idxtext{Slash (format directive)}\idxtext{Tilde Slash (format directive)}
+
+\f{~/\param{name}/}
+
+User defined functions can be called from within a format
+string by using the directive \f{~/\param{name}/}.
+The \term{colon} modifier, the \term{at-sign} modifier, and arbitrarily many parameters 
+can be specified with the \f{~/\param{name}/} directive.
+\param{name} can be any arbitrary string that does not contain a "/".
+All of the characters in \param{name} are treated as if they were upper case.
+If \param{name} contains a single \term{colon} (\f{:}) or double \term{colon} (\f{::}),
+then everything up to but not including the first \f{":"} or \f{"::"}
+is taken to be a \term{string} that names a \term{package}.
+Everything after the first \f{":"} or \f{"::"} (if any) is taken to be a 
+\term{string} that names a \f{symbol}.  The function corresponding to a 
+\f{~/name/} directive is obtained by looking up the \term{symbol}
+that has the indicated name in the indicated \term{package}.
+If \param{name} does not contain a \f{":"} or \f{"::"},
+%then the whole \param{name} string is looked up in \thepackage{user}.
+then the whole \param{name} string is looked up in \thepackage{common-lisp-user}. 
+
+When a \f{~/name/} directive is encountered,
+the indicated function is called with four or more arguments.
+The first four arguments are:
+     the output stream,
+     the \term{format argument} corresponding to the directive,
+     a \term{generalized boolean} that is \term{true} if the \term{colon} modifier was used,
+ and a \term{generalized boolean} that is \term{true} if the \term{at-sign} modifier was used.
+The remaining arguments consist of any parameters specified with the directive.
+The function should print the argument appropriately.
+Any values returned by the function are ignored.
+ 
+The three \term{functions} 
+      \funref{pprint-linear},
+      \funref{pprint-fill},
+  and \funref{pprint-tabular}
+are specifically designed so that they can be called by \f{~/.../}
+(\ie \f{~/pprint-linear/}, \f{~/pprint-fill/}, and \f{~/pprint-tabular/}).
+In particular they take \term{colon} and \term{at-sign} arguments.
+
+\endissue{PRETTY-PRINT-INTERFACE}
+
+\endsubsubsection%{Tilde Slash: Call Function}
+
+\endsubsection%{FORMAT Pretty Printer Operations}
+
+\beginsubsection{FORMAT Layout Control}
+
+\beginsubsubsection{Tilde T: Tabulate}
+\idxtext{T (format directive)}\idxtext{Tilde T (format directive)}
+
+%% 22.3.2 102       
+
+This spaces over to a given column.
+\f{~\j{colnum},\j{colinc}T} will output
+sufficient spaces to move the cursor to column \j{colnum}.  If the cursor
+is already at or beyond column \j{colnum}, it will output spaces to move it to
+column \j{colnum}+\j{k}*\j{colinc} for the smallest positive integer
+\j{k} possible, unless \j{colinc} is zero, in which case no spaces
+are output if the cursor is already at or beyond column \j{colnum}.
+\j{colnum} and \j{colinc} default to \f{1}.
+
+%% 22.3.2 103
+If for some reason the current absolute column position cannot be determined
+by direct inquiry,
+\funref{format} 
+may be able to deduce the current column position by noting         
+that certain directives (such as \f{~\%}, or \f{~\&},
+or \f{~A} 
+with the argument being a string containing a newline) cause
+the column position to be reset to zero, and counting the number of characters
+emitted since that point.  If that fails, \funref{format} 
+may attempt a
+similar deduction on the riskier assumption that the destination was
+at column zero when \funref{format} 
+was invoked.  If even this heuristic fails
+or is implementationally inconvenient, at worst
+the \f{~T} operation will simply output two spaces.
+
+%% 22.3.2 104              
+\f{~@T} performs relative tabulation.
+\f{~\j{colrel},\j{colinc}@T} outputs \j{colrel} spaces
+and then outputs the smallest non-negative
+number of additional spaces necessary to move the cursor
+to a column that is a multiple                                       
+of \j{colinc}.  For example, the directive 
+\f{~3,8@T} outputs
+three spaces and then moves the cursor to a ``standard multiple-of-eight
+tab stop'' if not at one already.
+If the current output column cannot be determined, however,
+then \j{colinc} is ignored, and exactly \j{colrel} spaces are output.
+
+If the \term{colon} modifier is used with the \f{~T} directive,
+the tabbing computation is done relative to the horizontal position where the
+section immediately containing the directive begins, rather than with
+respect to a horizontal position of zero.  The numerical parameters are
+both interpreted as being in units of \term{ems} and both default to \f{1}.
+\f{~\param{n},\param{m}:T} is the same as 
+  \f{(pprint-tab :section \param{n} \param{m})}.
+\f{~\param{n},\param{m}:@T} is the same as
+  \f{(pprint-tab :section-relative \param{n} \param{m})}.
+
+\endsubsubsection%{Tilde T: Tab}
+
+\beginsubsubsection{Tilde Less-Than-Sign: Justification}
+\DefineSection{TildeLessThanJustification}
+\idxtext{Less-Than-Sign (format directive)}\idxtext{Tilde Less-Than-Sign (format directive)}
+
+%% 22.3.2 136                           
+\f{~\j{mincol},\j{colinc},\j{minpad},\j{padchar}<\j{str}~>}
+
+This justifies the text produced by processing \j{str}
+within a field at least \j{mincol} columns wide.  \j{str}
+may be divided up into segments with \f{~;}, in which case the
+spacing is evenly divided between the text segments.
+
+%% 22.3.2 137
+With no modifiers, the leftmost text segment is left justified in the
+field, and the rightmost text segment is right justified.  If there is
+only one text element, as a special case, it is right justified.
+The \f{:} modifier causes                                            
+spacing to be introduced before the first text segment;  the 
+\f{@} modifier causes spacing to be added after the last.
+The \j{minpad} parameter (default \f{0}) is the minimum number of
+padding characters to be output between each segment.
+The padding character is supplied by \j{padchar},
+which defaults to the space character.
+If the total width needed to satisfy these constraints is greater
+than \j{mincol}, then the width used is \j{mincol}+\j{k}*\j{colinc}
+for the smallest possible non-negative integer value \j{k}.
+\j{colinc} defaults to \f{1}, and \j{mincol} defaults to \f{0}.
+
+%% 22.3.2 139
+Note that \j{str} may include \funref{format} directives.
+All the clauses in \j{str} are processed in order;
+it is the resulting pieces of text that are justified.
+
+%% 22.3.2 140      
+The \f{~\hat } directive may be used to terminate processing of the
+clauses prematurely, in which case only the completely processed clauses
+are justified.
+
+%% 22.3.2 141                           
+If the first clause of a \f{~<} 
+is terminated with \f{~:;} instead of
+\f{~;}, then it is used in a special way.  All of the clauses are
+processed (subject to \f{~\hat }, of course), but the 
+first one is not used
+in performing the spacing and padding.  When the padded result has been
+determined, then if it will fit on the current line of output, it is
+output, and the text for the first clause is discarded.  If, however, the
+padded text will not fit on the current line, then the text segment for
+the first clause is output before the padded text.  The first clause
+ought to contain a newline (such as a \f{~\%} directive).  The first
+clause is always processed, and so any arguments it refers to will be
+used; the decision is whether to use the resulting segment of text, not
+whether to process the first clause.  If the \f{~:;} has a prefix
+parameter \j{n}, then the padded text must fit on the current line with
+\j{n} character positions to spare to avoid outputting the first clause's
+text.  For example, the control string
+
+\code
+ "~%;; ~\lbr\ ~<~%;; ~1:; ~S~>~\hat\ ,~\rbr\ .~%"
+\endcode
+
+can be used to print a list of items separated by commas without
+breaking items over line boundaries, beginning each line with
+\f{;; }.  The prefix parameter 
+\f{1} in \f{~1:;} accounts for the width of the
+comma that will follow the justified item if it is not the last
+element in the list, or the period 
+if it is.  If \f{~:;} has a second
+prefix parameter, then it is used as the width of the line,
+thus overriding the natural line width of the output stream.  To make
+the preceding example use a line width of 50, one would write
+     
+\code
+ "~%;; ~\lbr\ ~<~%;; ~1,50:; ~S~>~\hat\ ,~\rbr \ .~%"
+\endcode
+%% 22.3.2 142
+If the second argument is not supplied, then \funref{format} uses the
+line width of the \param{destination} output stream.
+If this cannot be determined (for example, when producing a 
+\term{string} result), then \funref{format} uses \f{72} as the line length.
+
+See also \secref\TildeLessThanLogicalBlock.
+
+\endsubsubsection%{Tilde Less-Than-Sign: Justification}
+
+\beginsubsubsection{Tilde Greater-Than-Sign: End of Justification}
+\idxtext{Greater-Than-Sign (format directive)}\idxtext{Tilde Greater-Than-Sign (format directive)}
+
+%% 22.3.2 143       
+
+\f{~>} terminates a \f{~<}.
+The consequences of using it elsewhere are undefined.
+
+\endsubsubsection%{Tilde Greater-Than-Sign: End of Justification}
+
+\endsubsection%{FORMAT Layout Control}
+
+\beginsubsection{FORMAT Control-Flow Operations}
+
+\beginsubsubsection{Tilde Asterisk: Go-To}
+\idxtext{Asterisk (format directive)}\idxtext{Tilde Asterisk (format directive)}
+
+%% 22.3.2 105       
+                                                
+The next \j{arg} is ignored.
+\f{~\j{n}*} ignores the next \j{n} arguments.
+
+%% 22.3.2 106   
+\f{~:*} backs up in the list of
+arguments so that the argument last processed will be processed again.
+\f{~\j{n}:*} backs up \j{n} arguments.
+
+%% 22.3.2 107                        
+When within a \f{~\{} construct
+(see below), the ignoring (in either direction) is relative to the list
+of arguments being processed by the iteration.
+
+%% 22.3.2 108       
+\f{~\j{n}@*} 
+goes to the \j{n}th \j{arg}, where 0 means the first one;
+\j{n} defaults to 0, so \f{~@*} goes back to the first \j{arg}.      
+Directives after a \f{~\j{n}@*}
+will take arguments in sequence beginning with the one gone to.
+When within a \f{~\{} construct, the ``goto''
+is relative to the list of arguments being processed by the iteration.
+
+\endsubsubsection%{Tilde Asterisk: Go-To}
+
+\beginsubsubsection{Tilde Left-Bracket: Conditional Expression}
+\idxtext{Left-Bracket (format directive)}\idxtext{Tilde Left-Bracket (format directive)}
+
+%% 22.3.2 121                                                 
+\f{~[\j{str0}~;\j{str1}~;\j{...}~;\j{strn}~]}
+
+This is a set of control strings, called \j{clauses}, one of which is
+chosen and used.  The clauses are separated by \f{~;}
+and the construct is terminated by \f{~]}.  For example,
+
+\f{"~[Siamese~;Manx~;Persian~] Cat"}
+                              
+The \j{arg}th
+clause is selected, where the first clause is number 0.
+If a prefix parameter is given (as \f{~\j{n}[}),
+then the parameter is used instead of an argument.    
+If \j{arg} is out of range then no clause is selected
+and no error is signaled.
+After the selected alternative has been processed, the control string
+continues after the \f{~]}.
+
+%% 22.3.2 122
+\f{~[\j{str0}~;\j{str1}~;\j{...}~;\j{strn}~:;\j{default}~]}
+has a default case.
+If the \j{last} \f{~;} used to separate clauses
+is \f{~:;} instead, then the last clause is an else clause
+that is performed if no other clause is selected.
+For example:
+
+\f{"~[Siamese~;Manx~;Persian~:;Alley~] Cat"}
+
+%!!! Deja vu. Is this repeated somewhere??? -kmp 11-Jun-91
+%% 22.3.2 123
+\f{~:[\param{alternative}~;\param{consequent}~]} 
+selects the \param{alternative} control string if \j{arg} is \term{false},
+and selects the \param{consequent} control string otherwise.
+                                                             
+%% 22.3.2 124
+\f{~@[\param{consequent}~]} 
+tests the argument.  If it is \term{true},           
+then the argument is not used up by the \f{~[} command
+but remains as the next one to be processed,
+and the one clause \param{consequent} is processed.
+If the \j{arg} is \term{false}, then the argument is used up,
+and the clause is not processed.
+The clause therefore should normally use exactly one argument,
+and may expect it to be \term{non-nil}.
+For example:
+
+\code
+ (setq *print-level* nil *print-length* 5)
+ (format nil
+        "~@[ print level = ~D~]~@[ print length = ~D~]"
+        *print-level* *print-length*)
+\EV  " print length = 5"
+\endcode
+
+Note also that
+
+\code
+ (format \param{stream} "...~@[\param{str}~]..." ...)
+\EQ (format \param{stream} "...~:[~;~:*\param{str}~]..." ...)
+\endcode
+
+%% 22.3.2 125
+The combination of \f{~[} and \f{\#} is useful, for
+example, for dealing with English conventions for printing lists:
+                         
+\code
+ (setq foo "Items:~#[ none~; ~S~; ~S and ~S~
+           ~:;~@\{~#[~; and~] ~S~\hat\ ,~\}~].")
+ (format nil foo) \EV  "Items: none."
+ (format nil foo 'foo) \EV  "Items: FOO."
+ (format nil foo 'foo 'bar) \EV  "Items: FOO and BAR."
+ (format nil foo 'foo 'bar 'baz) \EV  "Items: FOO, BAR, and BAZ."
+ (format nil foo 'foo 'bar 'baz 'quux) \EV  "Items: FOO, BAR, BAZ, and QUUX."
+\endcode
+
+\endsubsubsection%{Tilde Left-Bracket: Conditional Expression}
+
+\beginsubsubsection{Tilde Right-Bracket: End of Conditional Expression}
+\idxtext{Right-Bracket (format directive)}\idxtext{Tilde Right-Bracket (format directive)}
+
+%% 22.3.2 127
+
+\f{~]} terminates a \f{~[}.
+The consequences of using it elsewhere are undefined.
+
+\endsubsubsection%{Tilde Right-Bracket: End of Conditional Expression}
+
+\beginsubsubsection{Tilde Left-Brace: Iteration}
+\idxtext{Left-Brace (format directive)}\idxtext{Tilde Left-Brace (format directive)}
+
+%% 22.3.2 128                                  
+\f{~\{\j{str}~\}}
+
+This is an iteration construct.  The argument should be a \term{list},
+which is used as a set of arguments 
+as if for a recursive call to \funref{format}.
+The \term{string} \j{str} is used repeatedly as the control string.
+Each iteration can absorb as many elements of the \term{list} as it likes
+as arguments;
+if \j{str} uses up two arguments by itself, then two elements of the
+\term{list} will get used up each time around the loop.
+If before any iteration step the \term{list} 
+is empty, then the iteration is terminated.
+Also, if a prefix parameter \j{n} is given, then there will be at most \j{n}
+repetitions of processing of \j{str}.  
+Finally, the \f{~\hat } directive can be
+used to terminate the iteration prematurely.
+
+%% 22.3.2 129
+For example:
+                                                                       
+\code
+ (format nil "The winners are:~\{ ~S~\}." 
+         '(fred harry jill)) 
+\EV "The winners are: FRED HARRY JILL."                           
+ (format nil "Pairs:~\{ <~S,~S>~\}." 
+         '(a 1 b 2 c 3))
+\EV "Pairs: <A,1> <B,2> <C,3>."
+\endcode
+
+%% 22.3.2 130                                   
+\f{~:\lbr \j{str}~\rbr  } is similar, 
+but the argument should be a \term{list} of sublists.
+At each repetition step, one sublist 
+is used as the set of arguments for
+processing \j{str}; on the next repetition, a new sublist 
+is used, whether
+or not all of the last sublist had been processed.  
+For example:
+
+                                                                               
+
+\code
+ (format nil "Pairs:~:\lbr <~S,~S>~\rbr\ ." 
+                 '((a 1) (b 2) (c 3)))
+\EV "Pairs: <A,1> <B,2> <C,3>."
+\endcode
+
+%% 22.3.2 131              
+\f{~@\lbr \j{str}~\rbr }
+is similar to \f{~\lbr \j{str}~\rbr  }, but instead of
+using one argument that is a list, all the remaining arguments
+are used as the list of arguments for the iteration.
+Example:
+                                    
+\code
+ (format nil "Pairs:~@\lbr <~S,~S>~\rbr\ ." 'a 1 'b 2 'c 3)
+\EV "Pairs: <A,1> <B,2> <C,3>."
+\endcode
+If the iteration is terminated before all the remaining arguments are
+consumed, then any arguments not processed by the iteration remain to be
+processed by any directives following the iteration construct.
+
+%% 22.3.2 132                                   
+\f{~:@\lbr \j{str}~\rbr  } 
+combines the features                              
+of \f{~:\lbr \j{str}~\rbr  }
+and \f{~@\lbr \j{str}~\rbr  }.
+All the remaining arguments
+are used, and each one must be a \term{list}.
+On each iteration, the next argument is 
+used as a \term{list} of arguments to \j{str}.
+Example:
+                                     
+\code
+ (format nil "Pairs:~:@\lbr <~S,~S>~\rbr\ ." 
+              '(a 1) '(b 2) '(c 3)) 
+\EV "Pairs: <A,1> <B,2> <C,3>."
+\endcode
+%% 22.3.2 133                                             
+Terminating the repetition construct with \f{~:\rbr } 
+instead of \f{~\rbr  }
+forces \j{str} to be processed at least once, even if the initial
+list of arguments is null. However, this will not override an explicit
+prefix parameter of zero.
+
+%% 22.3.2 134
+If \j{str} is empty, then an argument is used as \j{str}.  
+It must be a \term{format control}
+and precede any arguments processed by the iteration.  As an example,
+the following are equivalent:
+
+\code
+    (apply #'format stream string arguments)
+ \EQ (format stream "~1\{~:\}" string arguments)
+\endcode
+
+This will use \f{string} as a formatting string.  
+The \f{~1\lbr } says it will                 
+be processed at most once, and the \f{~:\rbr } 
+says it will be processed at least once.
+Therefore it is processed exactly once, using \f{arguments} as the arguments.
+This case may be handled more clearly by the \f{~?} directive,
+but this general feature of \f{~\lbr  }
+is more powerful than \f{~?}.
+
+\endsubsubsection%{Tilde Left-Brace: Iteration}
+
+\beginsubsubsection{Tilde Right-Brace: End of Iteration}
+\idxtext{Right-Brace (format directive)}\idxtext{Tilde Right-Brace (format directive)}
+
+%% 22.3.2 135               
+                               
+\f{~\}} terminates a \f{~\{}.
+The consequences of using it elsewhere are undefined.
+
+\endsubsubsection%{Tilde Right-Brace: End of Iteration}
+
+\beginsubsubsection{Tilde Question-Mark: Recursive Processing}
+\idxtext{Question-Mark (format directive)}\idxtext{Tilde Question-Mark (format directive)}
+
+%% Was "Indirection", now "Recursive Processing". -kmp 30-Aug-93
+
+%% 22.3.2 109       
+
+The next \j{arg} must be a \term{format control}, and the one after it a \term{list};
+both are consumed by the \f{~?} directive.
+The two are processed as a \param{control-string}, with the elements of the \term{list} 
+as the arguments.  Once the recursive processing
+has been finished, the processing of the control
+string containing the \f{~?} directive is resumed.
+Example:
+
+\code
+ (format nil "~? ~D" "<~A ~D>" '("Foo" 5) 7) \EV "<Foo 5> 7"
+ (format nil "~? ~D" "<~A ~D>" '("Foo" 5 14) 7) \EV "<Foo 5> 7"
+\endcode
+Note that in the second example three arguments are supplied
+to the \term{format string} \f{"<~A ~D>"}, but only two are processed
+and the third is therefore ignored.
+
+%% 22.3.2 110    
+With the \f{@}
+modifier, only one \j{arg} is directly consumed.
+The \j{arg} must be a \term{string}; 
+it is processed as part of the control
+string as if it had appeared in place of the \f{~@?} construct,
+and any directives in the recursively processed control string may      
+consume arguments of the control string containing the \f{~@?}
+directive.
+Example:
+
+\code
+ (format nil "~@? ~D" "<~A ~D>" "Foo" 5 7) \EV "<Foo 5> 7"
+ (format nil "~@? ~D" "<~A ~D>" "Foo" 5 14 7) \EV "<Foo 5> 14"
+\endcode
+
+\endsubsubsection%{Tilde Question-Mark: Recursive Processing}
+
+\endsubsection%{FORMAT Control-Flow Operations}
+
+\beginsubsection{FORMAT Miscellaneous Operations}
+
+\beginsubsubsection{Tilde Left-Paren: Case Conversion}
+\idxtext{Left-Paren (format directive)}\idxtext{Tilde Left-Paren (format directive)}
+
+%% 22.3.2 115             
+\f{~(\j{str}~)}
+
+The contained control string \j{str} is processed, and what it produces
+is subject to case conversion.
+
+%% 22.3.2 116
+With no flags, every \term{uppercase} \term{character}
+is converted to the corresponding \term{lowercase} \term{character}.
+
+%% 22.3.2 117   
+\f{~:(} capitalizes all words, as if by \funref{string-capitalize}.
+                        
+%% 22.3.2 118    
+\f{~@(} 
+capitalizes just the first word and forces the rest to lower
+case.
+
+%% 22.3.2 119               
+\f{~:@(} converts every lowercase character
+to the corresponding uppercase character.
+
+%% 22.3.2 120                    
+In this example \f{~@(} is used to cause the first word
+produced by \f{~@R} to be capitalized:
+
+\code
+ (format nil "~@R ~(~@R~)" 14 14) 
+\EV "XIV xiv"
+ (defun f (n) (format nil "~@(~R~) error~:P detected." n)) \EV F
+ (f 0) \EV "Zero errors detected."
+ (f 1) \EV "One error detected."
+ (f 23) \EV "Twenty-three errors detected."
+\endcode
+
+%% This next is from Pitman #36 (first public review):
+When case conversions appear nested, the outer conversion dominates,
+as illustrated in the following example:
+
+\code
+ (format nil "~@(how is ~:(BOB SMITH~)?~)")
+ \EV "How is bob smith?"
+ \NV "How is Bob Smith?"
+\endcode
+
+\endsubsubsection%{Tilde Left-Paren: Case Conversion}
+
+\beginsubsubsection{Tilde Right-Paren: End of Case Conversion}
+\idxtext{Right-Paren (format directive)}\idxtext{Tilde Right-Paren (format directive)}
+
+%% 22.3.2 127
+
+\f{~)} terminates a \f{~(}.
+The consequences of using it elsewhere are undefined.
+
+\endsubsubsection%{Tilde Right-Paren: End of Case Conversion}
+
+\beginsubsubsection{Tilde P: Plural}
+\idxtext{P (format directive)}\idxtext{Tilde P (format directive)}
+
+%% 22.3.2 35
+
+If \j{arg} is not \funref{eql} 
+to the integer \f{1}, a lowercase \f{s} is
+printed; if \j{arg} is \funref{eql} to \f{1}, nothing is printed.  
+If \j{arg} is a floating-point \f{1.0}, the \f{s} is
+printed.
+
+%% 22.3.2 36
+\f{~:P} does the same thing, 
+after doing a \f{~:*} to back up one argument;
+that is, it prints a lowercase \f{s} if the previous argument was not
+\f{1}.  
+
+%% 22.3.2 37 
+\f{~@P} 
+prints \f{y} if the argument is \f{1}, or \f{ies} if it is
+not.  \f{~:@P} does the same thing, but backs up first.
+
+\code
+ (format nil "~D tr~:@P/~D win~:P" 7 1) \EV "7 tries/1 win"
+ (format nil "~D tr~:@P/~D win~:P" 1 0) \EV "1 try/0 wins"
+ (format nil "~D tr~:@P/~D win~:P" 1 3) \EV "1 try/3 wins"
+\endcode
+
+\endsubsubsection%{Tilde P: Plural}
+
+\endsubsection%{FORMAT Miscellaneous Operations}
+
+\beginsubsection{FORMAT Miscellaneous Pseudo-Operations}
+
+\beginsubsubsection{Tilde Semicolon: Clause Separator}
+\idxtext{Semicolon (format directive)}\idxtext{Tilde Semicolon (format directive)}
+
+%% 22.3.2 126
+
+This separates clauses in \f{~[} and \f{~<} constructs.
+The consequences of using it elsewhere are undefined.
+
+\endsubsubsection%{Tilde Semicolon: Clause Separator}
+
+\beginsubsubsection{Tilde Circumflex: Escape Upward}
+\idxtext{Circumflex (format directive)}\idxtext{Tilde Circumflex (format directive)}
+
+%% 22.3.2 144         
+{\f{~\hat }}
+
+This is an escape construct.  If there are no more arguments remaining to
+be processed, then the immediately           
+enclosing \f{~\lbr  } or \f{~<} construct
+is terminated.  If there is no such enclosing construct, then the entire
+formatting operation is terminated.  
+In the \f{~<} case, the formatting
+is performed, but no more segments are processed before doing the
+justification.     
+\f{~\hat } may appear anywhere in a \f{~\lbr  }
+construct.
+
+\code
+ (setq donestr "Done.~{\hat} ~D warning~:P.~{\hat} ~D error~:P.")
+\EV "Done.~{\hat} ~D warning~:P.~{\hat} ~D error~:P."
+ (format nil donestr) \EV "Done."
+ (format nil donestr 3) \EV "Done. 3 warnings."
+ (format nil donestr 1 5) \EV "Done. 1 warning. 5 errors."
+\endcode
+                                
+%% 22.3.2 145
+If a prefix parameter is given, then termination occurs if the parameter
+is zero.  (Hence \f{~{\hat}} is equivalent to 
+\f{~\#{\hat}}.)  If two
+parameters are given, termination occurs if they are equal.
+\reviewer{Barmar: Which equality predicate?}  If three
+parameters are given, termination occurs if the first is less than or
+equal to the second and the second is less than or equal to the third.
+Of course, this is useless if all the prefix parameters are constants; at
+least one of them should be a \f{\#} or a \f{V} parameter.
+
+%% 22.3.2 146                                              
+If \f{~{\hat}} is used within a \f{~:\lbr  } 
+construct, then it terminates
+the current iteration step because in the standard case it tests for
+remaining arguments of the current step only; the next iteration step
+commences immediately.  \f{~:{\hat}} is used to terminate
+the iteration process.
+\issue{FORMAT-COLON-UPARROW-SCOPE}
+\f{~:{\hat}} 
+may be used only if the command it would terminate is 
+\f{~:\lbr  } or \f{~:@\lbr  }.
+The entire iteration process is terminated if and only if the sublist that is
+supplying the arguments for the current iteration step is the last sublist in
+the case of \f{~:\lbr }, 
+or the last \funref{format}        
+argument in the case of \f{~:@\lbr  }. 
+\f{~:{\hat}} is not
+equivalent to \f{~\#:{\hat}}; 
+the latter terminates the entire iteration if and only if no
+arguments remain for the current iteration step.
+For example:
+
+\code
+ (format nil "~:\lbr\ ~@?~:\hat\ ...~\rbr\ " '(("a") ("b"))) \EV "a...b"
+\endcode
+\endissue{FORMAT-COLON-UPARROW-SCOPE}
+
+%% 22.3.2 147     
+If \f{~{\hat}} appears within a control string being processed
+under the control of a \f{~?} directive, but not within
+any \f{~\lbr  } or \f{~<} construct within that string,
+then the string being
+processed will be terminated, thereby ending processing
+of the \f{~?} directive.  Processing then
+continues within the string   
+containing the \f{~?} directive at the point following that directive.
+
+%% 22.3.2 148     
+If \f{~{\hat}}                                          
+appears within a \f{~[} or \f{~(} construct,
+then all the commands up to the \f{~{\hat}} are properly selected
+or case-converted,                   
+the \f{~[} or \f{~(} processing is terminated,
+and the outward search continues         
+for a \f{~\lbr  } or \f{~<} construct
+to be terminated.  For example:
+                            
+\code
+ (setq tellstr "~@(~@[~R~]~{\hat} ~A!~)")
+\EV "~@(~@[~R~]~{\hat} ~A!~)"
+ (format nil tellstr 23) \EV "Twenty-three!"
+ (format nil tellstr nil "losers") \EV " Losers!"
+ (format nil tellstr 23 "losers") \EV "Twenty-three losers!"
+\endcode
+
+%% 22.3.2 149                                     
+Following are examples of the use of \f{~{\hat}} 
+within a \f{~<} construct.
+
+\code
+ (format nil "~15<~S~;~{\hat}~S~;~{\hat}~S~>" 'foo)
+\EV  "            FOO"
+ (format nil "~15<~S~;~{\hat}~S~;~{\hat}~S~>" 'foo 'bar)
+\EV  "FOO         BAR"
+ (format nil "~15<~S~;~{\hat}~S~;~{\hat}~S~>" 'foo 'bar 'baz)
+\EV  "FOO   BAR   BAZ"
+\endcode
+
+\endsubsubsection%{Tilde Circumflex: Escape Upward}
+
+\beginsubsubsection{Tilde Newline: Ignored Newline}
+\idxtext{Newline (format directive)}\idxtext{Tilde Newline (format directive)}
+
+%% 22.3.2 100
+
+\term{Tilde} immediately followed by a \term{newline} ignores the \term{newline}
+and any following non-newline \term{whitespace}\meaning{1} characters.
+With a \f{:},
+ the \term{newline} is ignored, 
+ but any following \term{whitespace}\meaning{1} is left in place.
+With an \f{@},
+ the \term{newline} is left in place,
+ but any following \term{whitespace}\meaning{1} is ignored.
+For example:
+
+%% 22.3.2 101
+\code
+ (defun type-clash-error (fn nargs argnum right-type wrong-type)
+   (format *error-output*
+           "~&~S requires its ~:[~:R~;~*~]~ 
+           argument to be of type ~S,~%but it was called ~
+           with an argument of type ~S.~%"
+           fn (eql nargs 1) argnum right-type wrong-type))
+ (type-clash-error 'aref nil 2 'integer 'vector)  prints:
+AREF requires its second argument to be of type INTEGER,
+but it was called with an argument of type VECTOR.
+NIL
+ (type-clash-error 'car 1 1 'list 'short-float)  prints:
+CAR requires its argument to be of type LIST,
+but it was called with an argument of type SHORT-FLOAT.
+NIL
+\endcode
+Note that in this example newlines appear in the output only as specified
+by the \f{~\&} and \f{~\%} directives; the 
+actual newline characters
+in the control string are suppressed because each is preceded by a tilde.
+                                                                     
+\endsubsubsection%{Tilde Newline: Ignored Newline}
+
+\endsubsection%{FORMAT Miscellaneous Pseudo-Operations}
+
+\beginsubsection{Additional Information about FORMAT Operations}
+
+\beginsubsubsection{Nesting of FORMAT Operations}
+
+%% 22.3.2 112
+%% this paragraph was left out
+%% 22.3.2 113
+The case-conversion, conditional, iteration, and justification
+constructs can contain other formatting constructs by bracketing them.
+These constructs must nest properly with respect to each other.
+For example, it is not legitimate to put the start of a case-conversion
+construct in each arm of a conditional and the
+end of the case-conversion construct outside the conditional:
+
+\code
+ (format nil "~:[abc~:@(def~;ghi~
+:@(jkl~]mno~)" x) ;Invalid!
+\endcode
+This notation is invalid because the \f{~[...~;...~]}
+and \f{~(...~)} constructs are not properly nested.
+                                   
+%% 22.3.2 114                                           
+The processing indirection caused by the \f{~?} directive
+is also a kind of nesting for the purposes of this rule of proper nesting.
+It is not permitted to
+start a bracketing construct within a string processed
+under control of a \f{~?}                                      
+directive and end the construct at some point after the \f{~?} construct
+in the string containing that construct, or vice versa.
+For example, this situation is invalid:
+                                                                               
+\code
+ (format nil "~@?ghi~)" "abc~@(def") ;Invalid!
+\endcode
+This notation
+is invalid because the \f{~?}
+and \f{~(...~)} constructs are not properly nested.
+
+\endsubsubsection%{Nesting of FORMAT Operations}
+
+\beginsubsubsection{Missing and Additional FORMAT Arguments}
+
+%% 22.3.3 3
+The consequences are undefined if no \param{arg} remains for a directive 
+requiring an argument.  However, it is permissible for one or more \param{args} 
+to remain unprocessed by a directive; such \param{args} are ignored.
+ 
+\endsubsubsection%{Missing and Additional FORMAT Arguments}
+
+\beginsubsubsection{Additional FORMAT Parameters}
+
+%% 22.3.3 11
+The consequences are undefined if a format directive is given more parameters 
+than it is described here as accepting.
+
+\endsubsubsection%{Additional FORMAT Parameters}
+
+\beginsubsubsection{Undefined FORMAT Modifier Combinations}
+
+%% 22.3.3 11
+The consequences are undefined if \term{colon} or \term{at-sign} modifiers
+are given to a directive in a combination not specifically described
+here as being meaningful.
+
+\endsubsubsection%{Undefined FORMAT Modifier Combinations}
+
+\endsubsection%{Additional Information about FORMAT Operations}
+
+\beginsubsection{Examples of FORMAT}
+
+%% 22.3.2 12
+%% 22.3.2 13
+%% 22.3.2 14                                                                 
+\code
+ (format nil "foo") \EV "foo"
+ (setq x 5) \EV 5
+ (format nil "The answer is ~D." x) \EV "The answer is 5."
+ (format nil "The answer is ~3D." x) \EV "The answer is   5."
+ (format nil "The answer is ~3,'0D." x) \EV "The answer is 005."
+ (format nil "The answer is ~:D." (expt 47 x))
+\EV "The answer is 229,345,007."
+ (setq y "elephant") \EV "elephant"
+ (format nil "Look at the ~A!" y) \EV "Look at the elephant!"
+ (setq n 3) \EV 3
+ (format nil "~D item~:P found." n) \EV "3 items found."
+ (format nil "~R dog~:[s are~; is~] here." n (= n 1))
+\EV "three dogs are here."
+ (format nil "~R dog~:*~[s are~; is~:;s are~] here." n)
+\EV "three dogs are here."
+ (format nil "Here ~[are~;is~:;are~] ~:*~R pupp~:@P." n)
+\EV "Here are three puppies."
+\endcode
+%% 22.3.2 53
+\code
+ (defun foo (x)
+   (format nil "~6,2F|~6,2,1,'*F|~6,2,,'?F|~6F|~,2F|~F"
+           x x x x x x)) \EV FOO
+ (foo 3.14159)  \EV "  3.14| 31.42|  3.14|3.1416|3.14|3.14159"
+ (foo -3.14159) \EV " -3.14|-31.42| -3.14|-3.142|-3.14|-3.14159"
+ (foo 100.0)    \EV "100.00|******|100.00| 100.0|100.00|100.0"
+ (foo 1234.0)   \EV "1234.00|******|??????|1234.0|1234.00|1234.0"
+ (foo 0.006)    \EV "  0.01|  0.06|  0.01| 0.006|0.01|0.006"
+\endcode
+%% 22.3.2 73
+\code
+ (defun foo (x)  
+    (format nil
+           "~9,2,1,,'*E|~10,3,2,2,'?,,'\$E|~
+            ~9,3,2,-2,'%@E|~9,2E"
+           x x x x))
+ (foo 3.14159)  \EV "  3.14E+0| 31.42\$-01|+.003E+03|  3.14E+0"
+ (foo -3.14159) \EV " -3.14E+0|-31.42\$-01|-.003E+03| -3.14E+0"
+ (foo 1100.0)   \EV "  1.10E+3| 11.00\$+02|+.001E+06|  1.10E+3"
+ (foo 1100.0L0) \EV "  1.10L+3| 11.00\$+02|+.001L+06|  1.10L+3"
+ (foo 1.1E13)   \EV "*********| 11.00\$+12|+.001E+16| 1.10E+13"
+ (foo 1.1L120)  \EV "*********|??????????|%%%%%%%%%|1.10L+120"
+ (foo 1.1L1200) \EV "*********|??????????|%%%%%%%%%|1.10L+1200"
+\endcode
+As an example of the effects of varying the scale factor, the code
+
+\code
+ (dotimes (k 13)
+   (format t "~%Scale factor ~2D: |~13,6,2,VE|"
+           (- k 5) (- k 5) 3.14159))
+\endcode
+produces the following output:
+
+\code
+Scale factor -5: | 0.000003E+06|
+Scale factor -4: | 0.000031E+05|
+Scale factor -3: | 0.000314E+04|
+Scale factor -2: | 0.003142E+03|
+Scale factor -1: | 0.031416E+02|
+Scale factor  0: | 0.314159E+01|
+Scale factor  1: | 3.141590E+00|
+Scale factor  2: | 31.41590E-01|
+Scale factor  3: | 314.1590E-02|
+Scale factor  4: | 3141.590E-03|
+Scale factor  5: | 31415.90E-04|
+Scale factor  6: | 314159.0E-05|
+Scale factor  7: | 3141590.E-06|
+\endcode
+
+%% 22.3.2 86
+\code
+ (defun foo (x)
+   (format nil "~9,2,1,,'*G|~9,3,2,3,'?,,'\$G|~9,3,2,0,'%G|~9,2G"
+          x x x x))                                     
+ (foo 0.0314159) \EV "  3.14E-2|314.2\$-04|0.314E-01|  3.14E-2"
+ (foo 0.314159)  \EV "  0.31   |0.314    |0.314    | 0.31    "
+ (foo 3.14159)   \EV "   3.1   | 3.14    | 3.14    |  3.1    "
+ (foo 31.4159)   \EV "   31.   | 31.4    | 31.4    |  31.    "
+ (foo 314.159)   \EV "  3.14E+2| 314.    | 314.    |  3.14E+2"
+ (foo 3141.59)   \EV "  3.14E+3|314.2\$+01|0.314E+04|  3.14E+3"
+ (foo 3141.59L0) \EV "  3.14L+3|314.2\$+01|0.314L+04|  3.14L+3"
+ (foo 3.14E12)   \EV "*********|314.0\$+10|0.314E+13| 3.14E+12"
+ (foo 3.14L120)  \EV "*********|?????????|%%%%%%%%%|3.14L+120"
+ (foo 3.14L1200) \EV "*********|?????????|%%%%%%%%%|3.14L+1200"
+\endcode
+
+%% 22.3.2 138   
+\code
+ (format nil "~10<foo~;bar~>")   \EV "foo    bar"
+ (format nil "~10:<foo~;bar~>")  \EV "  foo  bar"
+ (format nil "~10<foobar~>")     \EV "    foobar"
+ (format nil "~10:<foobar~>")    \EV "    foobar"
+ (format nil "~10:@<foo~;bar~>") \EV "  foo bar "
+ (format nil "~10@<foobar~>")    \EV "foobar    "
+ (format nil "~10:@<foobar~>")   \EV "  foobar  "
+\endcode
+
+\issue{PATHNAME-PRINT-READ:SHARPSIGN-P}
+\code
+  (FORMAT NIL "Written to ~A." #P"foo.bin")
+  \EV "Written to foo.bin."
+\endcode
+\endissue{PATHNAME-PRINT-READ:SHARPSIGN-P}
+
+\endsubsection%{Examples of FORMAT}
+
+\beginsubsection{Notes about FORMAT}
+
+%% 22.3.2 5
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+Formatted output is performed not only by \funref{format},
+but by certain other functions that accept a \term{format control}
+the way \funref{format} does.  For example, error-signaling functions
+such as \funref{cerror} accept \term{format controls}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+Note that the meaning of \nil\ and \t\ as destinations to \funref{format} 
+are different than those of \nil\ and \t\ as \term{stream designators}.
+
+The \f{~{\hat}} should appear only at the beginning of a \f{~<} clause,
+because it aborts the entire clause in which it appears (as well as
+all following clauses).                                     
+
+\endsubsection%{Notes about FORMAT}

concept-gfs-and-methods.tex

@@ -0,0 +1,931 @@
+% -*- Mode: TeX -*-
+
+%!!! Uses of "built-in" could be "\term{standardized}" here.
+
+\beginSubsection{Introduction to Generic Functions}
+\DefineSection{IntroToGFs}
+
+A \newterm{generic function} is a function whose behavior depends on
+the \term{classes} or identities of the \term{arguments} supplied to it.
+A \term{generic function} \term{object} 
+%contains
+is associated with 
+     a set of \term{methods},
+     a \term{lambda list},
+     a \term{method combination}\meaning{2}, 
+ and other information.
+
+Like an \term{ordinary function}, a \term{generic function} takes \term{arguments},
+performs a series of operations, and perhaps returns useful \term{values}.
+An \term{ordinary function} has a single body of \term{code} that is always \term{executed}
+when the \term{function} is called.  A \term{generic function} has a set of bodies
+of \term{code} of which a subset is selected for \term{execution}. The selected
+bodies of \term{code} and the manner of their combination are determined by
+the \term{classes} or identities of one or more of the \term{arguments} to the
+\term{generic function} and by its \term{method combination}.
+
+\term{Ordinary functions} and \term{generic functions} are called with identical syntax.
+ 
+\term{Generic functions} are true \term{functions} that can be passed as \term{arguments}
+and used as the first \term{argument} to \funref{funcall} and \funref{apply}.
+
+A \term{binding} of a \term{function name} to a \term{generic function}
+can be \term{established} in one of several ways.  It can be
+\term{established} in the \term{global environment} by 
+ \funref{ensure-generic-function},
+ \macref{defmethod} (implicitly, due to \funref{ensure-generic-function})
+or
+ \macref{defgeneric} (also implicitly, due to \funref{ensure-generic-function}).
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+No \term{standardized} mechanism is provided for \term{establishing} a
+\term{binding} of a \term{function name} to a \term{generic function}
+in the \term{lexical environment}.
+% It can be \term{established} in the \term{lexical environment} by 
+\issue{WITH-ADDED-METHODS:DELETE}
+% \specref{with-added-methods},
+\endissue{WITH-ADDED-METHODS:DELETE}
+%  \specref{generic-flet}
+% or
+%  \specref{generic-labels}.
+% The \term{name} part of such a \term{binding}, like the name of an ordinary
+% \term{function}, can be either a \term{symbol} or a two-element
+% \term{list} whose first element is \misc{setf} and whose second element
+% is a \term{symbol}.  This is true for both \term{lexical bindings} and
+% \term{global bindings}.
+% 
+% The \specref{generic-flet} special form creates new local generic
+% functions using the set of methods specified by the method definitions
+% in the \specref{generic-flet} form.  The scoping of generic function names
+% within a \specref{generic-flet} form is the same as for \specref{flet}.
+% 
+% The \specref{generic-labels} special form creates a set of new mutually
+% recursive local generic functions using the set of methods specified
+% by the method definitions in the \specref{generic-labels} form.  The
+% scoping of generic function names within a \specref{generic-labels} form
+% is the same as for \specref{labels}.
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+\issue{WITH-ADDED-METHODS:DELETE}
+% The \specref{with-added-methods} special form creates new local generic
+% functions by adding the set of methods specified by the method
+% definitions with a given name in the \specref{with-added-methods} form to
+% copies of the methods of the lexically visible generic function of the
+% same name. If there is a lexically visible ordinary function of the
+% same name as one of specified generic functions, that function
+% becomes the method function of the default method for the new generic
+% function of that name.
+\endissue{WITH-ADDED-METHODS:DELETE}
+
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% The \macref{generic-function} macro creates an anonymous generic
+% function with the set of methods specified by the method definitions
+% in the \macref{generic-function} form.
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+When a \macref{defgeneric} form is evaluated, one of three actions
+is taken (due to \funref{ensure-generic-function}):
+
+%!!! Barrett observes that GENERIC-FLET and GENERIC-LABELS are not correctly
+%    spoken for here because they are classified as method-defining.
+%    But since they've been flushed, I guess it doesn't matter. -kmp 12-Feb-92
+\beginlist
+
+\itemitem{\bull} If a generic function of the given name already exists,
+the existing generic function object is modified.  Methods specified
+by the current \macref{defgeneric} form are added, and any methods in the
+existing generic function that were defined by a previous \macref{defgeneric}
+form are removed.  Methods added by the current \macref{defgeneric} 
+form might replace methods defined by \macref{defmethod}, 
+\macref{defclass}, \macref{define-condition}, or \macref{defstruct}.  
+No other methods in the generic function are affected
+or replaced.
+
+\itemitem{\bull} If the given name names 
+    an \term{ordinary function}, 
+    a  \term{macro},
+ or a \term{special operator}, 
+an error is signaled.
+
+\itemitem{\bull} Otherwise a generic function is created with the
+methods specified by the method definitions in the \macref{defgeneric}
+form.
+
+\endlist
+
+Some \term{operators} permit specification of the options of a
+\term{generic function}, such as 
+the \term{type} of \term{method combination} it uses 
+or its \term{argument precedence order}.
+These \term{operators} will be referred to as
+``operators that specify generic function options.''
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% These \term{operators} are:
+%  \macref{defgeneric},
+%% Reworded since there's only one.
+The only \term{standardized} \term{operator} in this category is \macref{defgeneric}.
+%\macref{generic-function},
+\issue{WITH-ADDED-METHODS:DELETE}
+%\specref{with-added-methods},
+\endissue{WITH-ADDED-METHODS:DELETE}
+%  \specref{generic-flet}, 
+% and
+%  \specref{generic-labels}.
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+Some \term{operators} define \term{methods} for a \term{generic function}.
+These \term{operators} will be referred to as
+\newtermidx{method-defining operators}{method-defining operator};
+their associated \term{forms} are called \term{method-defining forms}.
+The \term{standardized} \term{method-defining operators} are listed in \thenextfigure.
+% The \term{standardized} \term{operators} in this category are:
+%  \macref{defgeneric},
+%  \macref{defmethod},
+% \issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% %\macref{generic-function},
+% % \specref{generic-flet},
+% % \specref{generic-labels},
+% \endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% \issue{WITH-ADDED-METHODS:DELETE}
+% %\specref{with-added-methods}, 
+% \endissue{WITH-ADDED-METHODS:DELETE}%
+%  \macref{defclass},
+%  \macref{define-condition},
+% and 
+%  \macref{defstruct}.
+\DefineFigure{StdMethDefOps}
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\issue{WITH-ADDED-METHODS:DELETE}
+%Removed GENERIC-FUNCTION, GENERIC-FLET, and GENERIC-LABELS.
+%Removed WITH-ADDED-METHODS.
+\displaythree{Standardized Method-Defining Operators}{
+defgeneric&defmethod&defclass\cr
+define-condition&defstruct&\cr
+}
+\endissue{WITH-ADDED-METHODS:DELETE}
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+Note that of the \term{standardized} \term{method-defining operators}
+% all of the method-defining operators except
+%  \macref{defclass},
+%  \macref{defmethod},
+%  \macref{define-condition},
+% and 
+%  \macref{defstruct} 
+only \macref{defgeneric}
+can specify \term{generic function} options.
+\macref{defgeneric} and any \term{implementation-defined} \term{operators}
+that can specify \term{generic function} options
+are also referred to as ``operators that specify generic function options.''
+
+\endSubsection%{Introduction to Generic Functions}
+
+\beginSubsection{Introduction to Methods}
+\DefineSection{IntroToMethods}
+
+\term{Methods} define the class-specific or identity-specific behavior
+and operations of a \term{generic function}. 
+
+%KAB was a bit unhappy with "contains" here.
+%He also didn't like the term "method function".
+A \term{method} \term{object} 
+%contains
+is associated with 
+%     a method function,
+     \term{code} that implements the method's behavior,
+     a sequence of \term{parameter specializers} 
+       that specify when the given \term{method} is applicable,
+     a \term{lambda list},
+ and a sequence of \term{qualifiers} that are used by the method combination
+       facility to distinguish among \term{methods}.
+
+A method object is not a function and cannot be invoked as a function. 
+Various mechanisms in the \OS\ take a method object and invoke its method
+function, as is the case when a generic function is invoked.  When this
+occurs it is said that the method is invoked or called.
+
+A method-defining form contains the \term{code} that is to be run when the
+arguments to the generic function cause the method that it defines to
+be invoked.  When a method-defining form is evaluated, a method object
+is created and one of four actions is taken:
+
+\beginlist
+
+\itemitem{\bull} If a \term{generic function} of the given name already exists
+and if a \term{method object} already exists that agrees with the new one on
+\term{parameter specializers} and \term{qualifiers}, the new \term{method object} replaces
+the old one.  For a definition of one method agreeing with another on
+\term{parameter specializers} and \term{qualifiers}, 
+\seesection\SpecializerQualifierAgreement.
+
+\itemitem{\bull} If a \term{generic function} of the given name already exists
+and if there is no \term{method object} that agrees with the new one on
+\term{parameter specializers} and \term{qualifiers}, the existing \term{generic function}
+\term{object} is modified to contain the new \term{method} \term{object}.
+
+\itemitem{\bull} If the given \term{name} names an \term{ordinary function}, a \term{macro},
+or a \term{special operator}, an error is signaled.
+
+\itemitem{\bull} Otherwise a \term{generic function} is created with the \term{method}
+specified by the \term{method-defining form}.
+
+\endlist
+
+If the \term{lambda list} of a new \term{method} is not
+\term{congruent} with the \term{lambda list} of the \term{generic function},
+an error is signaled.  If a \term{method-defining operator} that cannot specify
+\term{generic function} options creates a new \term{generic function}, 
+a \term{lambda list} for that \term{generic function} is derived from the
+\term{lambda list} of the \term{method} in the \term{method-defining form} in such a way
+as to be \term{congruent} with it.  For a discussion of \newterm{congruence},
+\seesection\GFMethodLambdaListCongruency.
+
+Each method has a \term{specialized lambda list}, which determines
+when that method can be applied.  A \term{specialized lambda list} is like
+an \term{ordinary lambda list} except that a specialized parameter
+may occur instead of the name of a required parameter.  A specialized parameter
+is a list \f{(\i{variable-name} \i{parameter-specializer-name})},
+where \i{parameter-specializer-name} is one of the following:
+
+\beginlist
+
+\itemitem{a \term{symbol}}
+
+denotes a \term{parameter specializer} which is the \term{class} 
+named by that \term{symbol}.
+
+\issue{CLASS-OBJECT-SPECIALIZER:AFFIRM}
+%This was apparently introduced accidentally, but has been confirmed by X3J13 vote.
+% -kmp 08-Apr-91
+\itemitem{a \term{class}}
+
+denotes a \term{parameter specializer} which is the \term{class} itself.
+\endissue{CLASS-OBJECT-SPECIALIZER:AFFIRM}
+
+\itemitem{\f{(eql \i{form})}}
+
+denotes a \term{parameter specializer} which satisfies the \term{type specifier}
+\f{(eql \i{object})}, where \i{object} is the 
+result of evaluating \i{form}.  The form \i{form} is evaluated in 
+the lexical environment in which the method-defining form is evaluated.
+Note that \i{form} is evaluated only once, at the time the method is
+defined, not each time the generic function is called.
+\endlist
+
+\term{Parameter specializer names} are used in macros intended as the
+user-level interface (\macref{defmethod}), while \term{parameter specializers}
+are used in the functional interface.
+
+Only required parameters may be specialized, and there must be a
+\term{parameter specializer} for each required parameter.  For notational
+simplicity, if some required parameter in a \term{specialized lambda list} in
+a method-defining form is simply a variable name, its 
+\term{parameter specializer} defaults to \theclass{t}.
+
+Given a generic function and a set of arguments, an applicable
+method is a method for that generic function whose parameter
+specializers are satisfied by their corresponding arguments.  The
+following definition specifies what it means for a method to be
+applicable and for an argument to satisfy a \term{parameter specializer}.
+
+%Barmar: Review use of ``instance'' here.  Also, instead of
+%  ``$C=P\sub i$ or ...'' we should refer just to ``(TYPEP Ai Pi) is true.''
+%Since this is a hot topic on the mail right now, I'll leave this 
+% until the dust settles. -kmp 22-Oct-90
+%KMP: I think this is finally fixed.
+Let $\langle A\sub 1, \ldots, A\sub n\rangle$ be the required
+arguments to a generic function in order. Let $\langle P\sub 1,
+\ldots, P\sub n\rangle$ be the \term{parameter specializers} corresponding to
+the required parameters of the method $M$ in order.  The method $M$ is
+% applicable when each $A\sub i$ satisfies $P\sub i$.
+% If $P\sub i$ is a class, and if $A\sub i$ is a \term{direct instance} of a class
+% $C$\negthinspace, then it is said that $A\sub i$ satisfies
+% $P\sub i$ when $C=P\sub i$ or when $C$ is a subclass of $P\sub i$.  If
+% $P\sub i$ is {\tt (eql \i{object})}, then it is said that
+% $A\sub i$ satisfies $P\sub i$ when
+% %\thefunction{eql} applied to $A\sub i$ and \i{object} \term{yields} \term{true}.
+% $A\sub i$ is the \term{same} as \i{object} (\ie under \funref{eql}).
+applicable when each $A\sub i$ is of the \term{type} specified by 
+the \term{type specifier} $P\sub i$.
+% Because a \term{parameter specializer} is a \term{type specifier}, 
+% \thefunction{typep} can be used during method selection 
+% to determine whether an
+% argument satisfies a \term{parameter specializer}.  
+% %% For Moon
+% %In general
+% A
+% %arbitrary
+% \term{parameter specializer} cannot be a \term{compound type specifier}.
+% %Example moved to the glossary.
+% %such as {\tt (vector single-float)}.
+% The only \term{list} that can be a \term{parameter specializer} is \f{(eql \i{object})}.
+% %This requires that
+% %Common Lisp be modified to include the \term{type specifier} \funref{eql} to be
+% %defined as if the following were evaluated:
+% %
+% %$$\hbox{\f{(deftype eql (object) `(member ,object))}}$$
+% %                                                                  
+%% Rewritten by KMP:
+%% This part isn't really needed because it's said just a few paragraphs before.
+% A \term{parameter specializer} can be a \term{class}, a \term{class} \term{name},
+% or \f{(eql \i{object})}.  
+%% I think this can stand on its own.
+Because every valid \term{parameter specializer} is 
+also a valid \term{type specifier}, \thefunction{typep} can be used during method
+selection to determine whether an argument satisfies a \term{parameter specializer}.  
+
+A method all of whose \term{parameter specializers} are 
+\theclass{t} is called a \newterm{default method}; it is always applicable but
+may be shadowed by a more specific method.
+
+Methods can have \term{qualifiers}, which give the method combination
+procedure a way to distinguish among methods.  A method that has one
+or more \term{qualifiers} is called a \term{qualified method}.
+A method with no \term{qualifiers} is called an \term{unqualified method}. 
+A \term{qualifier} is any \term{non-list}.
+% The \term{qualifiers} defined by standard method combination 
+% and by the built-in method combination types are \term{symbols}.
+%% Simplification per Barrett:
+The \term{qualifiers} defined by the \term{standardized} method combination types 
+are \term{symbols}.
+
+In this specification, the terms ``\term{primary method}'' and 
+``\term{auxiliary method}'' are used to partition \term{methods}
+within a method combination type according to their intended use.  
+In standard method combination, \term{primary methods} are 
+\term{unqualified methods} 
+and \term{auxiliary methods} are methods with a single \term{qualifier} 
+that is one of \kwd{around}, \kwd{before}, or \kwd{after}.
+\term{Methods} with these \term{qualifiers} are called \term{around methods},
+\term{before methods}, and \term{after methods}, respectively.
+When a method combination type is defined using the short form of
+\macref{define-method-combination}, \term{primary methods} are 
+methods qualified with the name of the type of method combination, 
+and auxiliary methods have the \term{qualifier} \kwd{around}.
+Thus the terms ``\term{primary method}'' and ``\term{auxiliary method}''
+have only a relative definition within a given method combination type.
+
+\endSubsection%{Introduction to Methods}
+
+\beginSubsection{Agreement on Parameter Specializers and Qualifiers}
+\DefineSection{SpecializerQualifierAgreement}
+
+Two \term{methods} are said to agree with each other on \term{parameter specializers}
+and \term{qualifiers} if the following conditions hold:
+
+\beginlist
+
+\itemitem{1.} Both methods have the same number of required parameters.
+Suppose the \term{parameter specializers} of the two methods are
+$P\sub{1,1}\ldots P\sub{1,n}$ and $P\sub{2,1}\ldots P\sub{2,n}$.
+
+\itemitem{2.} For each $1\leq i\leq n$, $P\sub{1,i}$ agrees with $P\sub{2,i}$.
+The \term{parameter specializer} $P\sub{1,i}$ agrees with $P\sub{2,i}$ if
+$P\sub{1,i}$ and $P\sub{2,i}$ are the same class or if 
+$P\sub{1,i}=\hbox{{\tt(\b{eql} $\hbox{\i{object}}\sub 1$)}}$,
+$P\sub{2,i}=\hbox{{\tt(\b{eql} $\hbox{\i{object}}\sub 2$)}}$, and
+{\tt (\b{eql} $\hbox{\i{object}}\sub 1$ $\hbox{\i{object}}\sub 2$)}.
+Otherwise $P\sub{1,i}$ and $P\sub{2,i}$ do not agree.
+
+
+\itemitem{3.} The two \term{lists} of \term{qualifiers} are the \term{same} 
+under \funref{equal}.
+
+% \itemitem{3.} The lists of \term{qualifiers} of both methods contain the same   
+% \term{non-nil} atoms in the same order. That is, the lists are \funref{equal}.
+
+\endlist
+
+\endSubsection%{Agreement on Parameter Specializers and Qualifiers}
+
+\beginSubsection{Congruent Lambda-lists for all Methods of a Generic Function}
+\DefineSection{GFMethodLambdaListCongruency}
+
+These rules define the congruence of a set of \term{lambda lists}, including the
+\term{lambda list} of each method for a given generic function and the
+\term{lambda list} specified for the generic function itself, if given.
+
+\beginlist
+
+\itemitem{1.} Each \term{lambda list} must have the same number of required
+parameters.
+
+\itemitem{2.} Each \term{lambda list} must have the same number of optional
+parameters.  Each method can supply its own default for an optional
+parameter.
+                                       
+\itemitem{3.} If any \term{lambda list} mentions \keyref{rest} or \keyref{key}, each
+\term{lambda list} must mention one or both of them.
+                                                        
+\itemitem{4.} If the \term{generic function} \term{lambda list}
+mentions \keyref{key}, each
+method must accept all of the keyword names mentioned after \keyref{key},
+either by accepting them explicitly, by specifying \keyref{allow-other-keys},
+or by specifying \keyref{rest} but not \keyref{key}.
+Each method can accept additional keyword arguments of its own.  The
+checking of the validity of keyword names is done in the generic
+function, not in each method.
+%!!! "Leftmost". Sigh.
+A method is invoked as if the keyword
+argument pair whose name is \kwd{allow-other-keys} and whose value
+is \term{true} were supplied, though no such argument pair will be passed.
+%!!! KAB: Alternatively, as if the lambda list of the method specified &allow-other-keys.
+                      
+\itemitem{5.} The use of \keyref{allow-other-keys} need not be consistent
+across \term{lambda lists}.  If \keyref{allow-other-keys} is mentioned in 
+the \term{lambda list} of any applicable \term{method} or of the \term{generic function},
+any keyword arguments may be mentioned in the call to the \term{generic function}.
+                      
+\itemitem{6.} The use of \keyref{aux} need not be consistent across methods.
+
+If a \term{method-defining operator} that cannot specify \term{generic function} options
+creates a \term{generic function}, and if the \term{lambda list} for the method
+mentions keyword arguments, the \term{lambda list} of the generic function
+will mention \keyref{key} (but no keyword arguments).
+
+\endlist
+
+\endSubsection%{Congruent Lambda-lists for All Methods of a Generic Function}
+
+%\newpage
+
+\beginSubsection{Keyword Arguments in Generic Functions and Methods}
+\DefineSection{KwdArgsInGFsAndMeths}
+                                                        
+When a generic function or any of its methods mentions 
+\keyref{key} in a \term{lambda list}, the specific set of keyword
+arguments accepted by the generic function varies according to the
+applicable methods.  The set of keyword arguments accepted by the
+generic function for a particular call is the union of the keyword
+arguments accepted by all applicable methods and the keyword arguments
+mentioned after \keyref{key} in the generic function definition,
+if any.  A method that has \keyref{rest} but not \keyref{key} does not affect the
+set of acceptable keyword arguments.  If
+the \term{lambda list} of any applicable method or of the generic
+function definition contains \keyref{allow-other-keys}, all
+keyword arguments are accepted by the generic function.
+
+The \term{lambda list} congruence rules require that each method
+accept all of the keyword arguments mentioned after \keyref{key} in the
+generic function definition, by accepting them explicitly, by
+specifying \keyref{allow-other-keys}, or by specifying \keyref{rest} but
+not \keyref{key}.  Each method can accept additional keyword arguments
+of its own, in addition to the keyword arguments mentioned in the
+generic function definition.
+
+If a \term{generic function} is passed a keyword argument that no applicable
+method accepts, an error should be signaled; \seesection\FuncallErrorChecking.
+
+\beginsubsubsection{Examples of Keyword Arguments in Generic Functions and Methods}
+
+For example, suppose there are two methods defined for {\tt width}
+as follows:
+
+\code
+ (defmethod width ((c character-class) &key font) ...)
+ 
+ (defmethod width ((p picture-class) &key pixel-size) ...)
+\endcode
+
+\noindent Assume that there are no other methods and no generic
+function definition for {\tt width}. The evaluation of the
+following form should signal an error because 
+the keyword argument \kwd{pixel-size} is not accepted by the applicable method.
+
+\code
+ (width (make-instance `character-class :char #\\Q) 
+        :font 'baskerville :pixel-size 10)
+\endcode
+
+The evaluation of the following form should signal an error.
+
+\code
+ (width (make-instance `picture-class :glyph (glyph #\\Q)) 
+        :font 'baskerville :pixel-size 10)
+\endcode
+
+The evaluation of the following form will not signal an error
+if the class named {\tt character-picture-class} is a subclass of
+both {\tt picture-class} and {\tt character-class}.
+
+\code
+ (width (make-instance `character-picture-class :char #\\Q)
+        :font 'baskerville :pixel-size 10)
+\endcode
+
+\endsubsubsection%{Examples of Keyword Arguments in Generic Functions and Methods}
+
+\endSubsection%{Keyword Arguments in Generic Functions and Methods}
+
+\beginSubsection{Method Selection and Combination}
+\DefineSection{MethodSelectionAndCombination}
+
+When a \term{generic function} is called with particular arguments, it must
+determine the code to execute.  This code is called the 
+\newterm{effective method} for those \term{arguments}.
+The \term{effective method} is a 
+combination of the \term{applicable methods} in the \term{generic function}
+that \term{calls} some or all of the \term{methods}.
+
+\issue{CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST}
+% If a \term{generic function} is      
+% called and no \term{methods} are \term{applicable},
+% the \term{generic function} \funref{no-applicable-method} is invoked.
+If a \term{generic function} is called and no \term{methods} are 
+\term{applicable}, the \term{generic function} \funref{no-applicable-method}
+is invoked, with the \term{results} from that call being used as the
+\term{results} of the call to the original \term{generic function}.  Calling
+\funref{no-applicable-method} takes precedence over checking for acceptable
+keyword arguments; \seesection\KwdArgsInGFsAndMeths.
+\endissue{CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST}
+
+When the \term{effective method} has been determined,
+it is invoked with the same \term{arguments} as were passed to the \term{generic function}.  
+Whatever \term{values} it returns are returned as the \term{values}
+of the \term{generic function}.
+
+\beginsubsubsection{Determining the Effective Method}
+\DefineSection{DeterminingtheEffectiveMethod}
+
+The effective method is determined by the following three-step procedure:
+
+\beginlist
+
+\itemitem{1.}{Select the applicable methods.}
+
+\itemitem{2.}{Sort the applicable methods by precedence order, putting
+the most specific method first.}
+
+\itemitem{3.}{Apply method combination to the sorted list of
+applicable methods, producing the effective method.}
+
+\endlist
+
+\beginsubsubsubsection{Selecting the Applicable Methods}
+\DefineSection{SelApplMeth}
+
+This step is described in \secref\IntroToMethods.
+
+\endsubsubsubsection%{Selecting the Applicable Methods}
+
+\beginsubsubsubsection{Sorting the Applicable Methods by Precedence Order}
+
+To compare the precedence of two methods, their \term{parameter specializers}
+are examined in order.  The default examination order is from left to
+right, but an alternative order may be specified by the 
+\kwd{argument-precedence-order} option to \macref{defgeneric} or to any of
+the other operators that specify generic function options.
+
+The corresponding \term{parameter specializers} from each method are
+compared.  When a pair of \term{parameter specializers} agree, the next
+pair are compared for agreement.  If all corresponding parameter
+specializers agree, the two methods must have different
+\term{qualifiers}; in this case, either method can be selected to precede the
+other.  For information about agreement, \seesection\SpecializerQualifierAgreement.
+
+If some corresponding \term{parameter specializers} do not agree, the first
+pair of \term{parameter specializers} that do not agree determines the
+precedence.  If both \term{parameter specializers} are classes, the more
+specific of the two methods is the method whose \term{parameter specializer}
+appears earlier in the \term{class precedence list} of the corresponding
+argument.  Because of the way in which the set of applicable methods
+is chosen, the \term{parameter specializers} are guaranteed to be present in
+the class precedence list of the class of the argument.
+
+If just one of a pair of corresponding \term{parameter specializers} is {\tt (eql \i{object})},
+the \term{method} with that \term{parameter specializer} precedes the
+other \term{method}.  If both \term{parameter specializers} are \funref{eql}
+\term{expressions}, the
+specializers must agree (otherwise the two \term{methods} would
+not both have been applicable to this argument).
+
+The resulting list of \term{applicable methods} has the most specific
+\term{method} first and the least specific \term{method} last.    
+
+\endsubsubsubsection%{Sorting the Applicable Methods by Precedence Order}
+
+\beginsubsubsubsection{Applying method combination to the sorted list of applicable methods}
+\DefineSection{ApplyMethCombToSortedMethods}
+
+In the simple case---if standard method combination is used and all
+applicable methods are primary methods---the 
+%!!! Barrett suggests that this is not the normal meaning of "effective method"
+effective method is the most specific method.
+That method can call the next most specific
+method by using \thefunction{call-next-method}.  The method that
+\funref{call-next-method} will call is referred to as the 
+\newterm{next method}.  The predicate \funref{next-method-p} tests whether a next
+method exists.  If \funref{call-next-method} is called and there is no
+next most specific method, the generic function \funref{no-next-method}
+is invoked.
+
+In general, the effective method is some combination of the applicable
+methods.  It is described by a \term{form} that contains calls to some or
+all of the applicable methods, returns the value or values that will
+be returned as the value or values of the generic function, and
+optionally makes some of the methods accessible by means of 
+\funref{call-next-method}.
+%% Moon wanted this removed.  Barrett agrees. -kmp 9-Feb-92
+% This Lisp form is the body of the effective
+% method; it is augmented with an appropriate \term{lambda list} to
+% make it a function.
+
+The role of each method in the effective method is determined by its
+%\term{method}
+\term{qualifiers} and the specificity of the method.  A \term{qualifier}
+serves to mark a method, and the meaning of a \term{qualifier} is
+determined by the way that these marks are used by this step
+of the procedure.  If an applicable method has an unrecognized
+\term{qualifier}, this step signals an error and does not include that method
+in the effective method.
+
+When standard method combination is used together with qualified methods, 
+the effective method is produced as described in \secref\StdMethComb.
+                                                                  
+Another type of method combination can be specified by using the
+\kwd{method-combination} option of \macref{defgeneric} or
+of any of the other operators that specify generic function options.  In
+this way this step of the procedure can be customized.
+
+New types of method combination can be defined by using 
+\themacro{define-method-combination}. 
+
+\endsubsubsubsection%{Applying method combination to the sorted list of applicable methods}
+
+\endsubsubsection%{Determining the Effective Method}
+
+\beginsubsubsection{Standard Method Combination}
+\DefineSection{StdMethComb}
+\idxref{standard}
+                                                       
+%!!! Barrett: "supported" ?
+Standard method combination is supported by \theclass{standard-generic-function}.
+It is used if no other type of method
+combination is specified or if the built-in method combination type
+\misc{standard} is specified. 
+
+Primary methods define the main action of the effective method,  
+while auxiliary methods modify that action in one of three ways.
+A primary method has no method \term{qualifiers}.
+                                                           
+An auxiliary method is a method whose 
+%\term{method}
+\term{qualifier} is \kwd{before}, \kwd{after}, or \kwd{around}.
+Standard method combination
+allows no more than one \term{qualifier} per method; if a method definition
+specifies more than one \term{qualifier} per method, an error is signaled.
+
+\beginlist
+
+\itemitem{\bull}
+A \term{before method} has the keyword \kwd{before} as its only \term{qualifier}.
+A \term{before method} specifies \term{code} that is to be run before any 
+\term{primary methods}.
+
+\itemitem{\bull}
+An \term{after method} has the keyword \kwd{after} as its only \term{qualifier}.
+An \term{after method} specifies \term{code} that is to be run after
+\term{primary methods}.
+
+\itemitem{\bull}
+An \term{around method} has the keyword \kwd{around} as its only \term{qualifier}.
+An \term{around method} specifies \term{code} that is to be run instead of other
+\term{applicable methods},
+%%I found this to be too vague. -kmp 9-Jan-91
+%but which is able to cause some of them to be run.
+but which might contain explicit \term{code}
+which calls some of those \term{shadowed} \term{methods}
+(via \funref{call-next-method}).
+
+\endlist
+
+The semantics of standard method combination is as follows:
+
+\beginlist
+                               
+\itemitem{\bull} If there are any \term{around methods}, the most specific
+\term{around method} is called.  It supplies the value or values of the
+generic function.
+
+\itemitem{\bull} Inside the body of an \term{around method}, 
+\funref{call-next-method} can be used to call the \term{next method}.  When the next
+method returns, the \term{around method} can execute more code,
+perhaps based on the returned value or values.
+% !!!
+% Moon: Can't happen, `next page' says signals an error if there are no primaries.
+% Barrett: This is a bone of contention. (e.g., no-next-method might -do- the signaling)
+\TheGF{no-next-method} is invoked if \funref{call-next-method} is used and
+there is no \term{applicable method} to call.  \Thefunction{next-method-p}
+may be used to determine whether a \term{next method} exists.
+
+\itemitem{\bull} 
+If an \term{around method} invokes \funref{call-next-method},
+the next most specific \term{around method}
+is called, if one is applicable.  If there are no \term{around methods} 
+or if \funref{call-next-method} is called by the least
+specific \term{around method}, the other methods are called as
+follows:
+\beginlist
+\itemitem{--} All the \term{before methods} are called, in
+most-specific-first order.  Their values are ignored.
+An error is signaled if \funref{call-next-method} is used in a
+\term{before method}.
+
+\itemitem{--} The most specific primary method is called.  Inside the
+body of a primary method, \funref{call-next-method} may be used to call
+the next most specific primary method.  When that method returns, the
+previous primary method can execute more code, perhaps based on the
+returned value or values.  The generic function \funref{no-next-method}
+is invoked if \funref{call-next-method} is used and there are no more
+applicable primary methods.  \Thefunction{next-method-p} may be
+used to determine whether a \term{next method} exists.  If \funref{call-next-method}
+is not used, only the most specific \term{primary method} is called.
+
+\itemitem{--} All the \term{after methods} are called in
+most-specific-last order.  Their values are ignored.
+An error is signaled if \funref{call-next-method} is used in an
+\term{after method}.
+\endlist
+\itemitem{\bull} If no \term{around methods} were invoked, the most
+specific primary method supplies the value or values returned by the
+generic function.  The value or values returned by the invocation of
+\funref{call-next-method} in the least specific \term{around method} are
+those returned by the most specific primary method.
+
+\endlist
+
+In standard method combination, if there is an applicable method
+but no applicable primary method, an error is signaled.
+     
+The \term{before methods} are run in most-specific-first order while
+the \term{after methods} are run in least-specific-first order.  The
+design rationale for this difference can be illustrated with an
+example.  Suppose class $C\sub 1$ modifies the behavior of its
+superclass, $C\sub 2$, by adding \term{before methods} and \term{after methods}.
+Whether the behavior of the class $C\sub 2$ is defined
+directly by methods on $C\sub 2$ or is inherited from its superclasses
+does not affect the relative order of invocation of methods on
+instances of the class $C\sub 1$.  Class $C\sub 1$'s 
+\term{before method} runs before all of class $C\sub 2$'s methods.  
+Class $C\sub 1$'s \term{after method} runs after all of class $C\sub 2$'s methods.
+
+By contrast, all \term{around methods} run before any other methods
+run.  Thus a less specific \term{around method} runs before a more
+specific primary method.
+
+If only primary methods are used and if \funref{call-next-method} is not
+used, only the most specific method is invoked; that is, more specific
+methods shadow more general ones. 
+
+\endsubsubsection%{Standard Method Combination}
+
+\beginsubsubsection{Declarative Method Combination}
+           
+The macro \macref{define-method-combination} defines new forms of method
+combination.  It provides a mechanism for customizing the production
+of the effective method. The default procedure for producing an
+effective method is described in \secref\DeterminingtheEffectiveMethod.
+There are two forms of
+\macref{define-method-combination}.  The short form is a simple facility while
+the long form is more powerful and more verbose.  The long form
+resembles \macref{defmacro} in that the body is an expression that
+computes a Lisp form; it provides mechanisms for implementing
+arbitrary control structures within method combination and for
+arbitrary processing of method \term{qualifiers}.  
+
+\endsubsubsection%{Declarative Method Combination}
+
+\beginsubsubsection{Built-in Method Combination Types}
+\DefineSection{BuiltInMethCombTypes}
+
+The \CLOS\ provides a set of built-in method combination types.  To
+specify that a generic function is to use one of these method
+combination types, the name of the method combination type is given as
+the argument to the \kwd{method-combination} option to 
+\macref{defgeneric} or to the \kwd{method-combination} option to any of the
+other operators that specify generic function options.
+
+The names of the built-in  method combination types are listed in \thenextfigure.
+\idxref{+}%
+\idxref{and}%
+\idxref{append}%
+\idxref{list}%
+\idxref{max}%
+\idxref{min}%
+\idxref{nconc}%
+\idxref{or}%
+\idxref{progn}%
+\idxref{standard}
+
+\displayfive{Built-in Method Combination Types}{
++&append&max&nconc&progn\cr
+and&list&min&or&standard\cr
+}
+
+The semantics of the \misc{standard} built-in method combination type is
+described in \secref\StdMethComb.  The other
+built-in method combination types are called simple built-in method
+combination types.
+
+The simple built-in method combination types act as though they were
+defined by the short form of \macref{define-method-combination}.  
+They recognize two roles for \term{methods}:
+
+\beginlist
+                                                                  
+\itemitem{\bull} An \term{around method} has the keyword symbol 
+\kwd{around} as its sole \term{qualifier}.  The meaning of 
+\kwd{around} \term{methods} is the same as in standard method combination.
+Use of the functions \funref{call-next-method} and \funref{next-method-p}
+is supported in \term{around methods}.
+
+\itemitem{\bull} A primary method has the name of the method combination
+type as its sole \term{qualifier}.  For example, the built-in method
+combination type {\tt and} recognizes methods whose sole \term{qualifier} is
+{\tt and}; these are primary methods. Use of the functions 
+\funref{call-next-method} and \funref{next-method-p} is not supported 
+in \term{primary methods}.
+
+\endlist
+
+The semantics of the simple built-in method combination types is as
+follows:
+
+\beginlist
+\itemitem{\bull}                                                    
+If there are any \term{around methods}, the most specific \term{around method}
+is called.   It supplies the value or values of the \term{generic function}. 
+                                    
+\itemitem{\bull} Inside the body of an \term{around method}, the function
+\funref{call-next-method} can be used to call the \term{next method}.
+% !!!
+% Moon: Can't happen, `next page' says signals an error if there are no primaries.
+% Barrett: This is a bone of contention. (e.g., no-next-method might -do- the signaling)
+\TheGF{no-next-method} is invoked if 
+\funref{call-next-method} is used and there is no applicable method to call.
+\Thefunction{next-method-p} may be used to determine whether a
+\term{next method} exists. When the \term{next method} returns, 
+the \term{around method} can execute more code,
+perhaps based on the returned value or values.
+                    
+\itemitem{\bull} If an \term{around method} invokes \funref{call-next-method},
+the next most specific \term{around method} is
+called, if one is applicable.  If there are no \term{around methods}
+or if \funref{call-next-method} is called by the least specific
+\term{around method}, a Lisp form derived from the name of the built-in
+method combination type and from the list of applicable primary
+methods is evaluated to produce the value of the generic function.
+Suppose the name of the method combination type is \i{operator}
+and the call to the generic function is of the form
+
+$$(\hbox{\i{generic-function}}\ a\sub 1\ldots a\sub n)$$
+
+\itemitem{} Let $M\sub 1,\ldots,M\sub k$ be the applicable primary methods
+in order; then the derived Lisp form is
+
+$$(\hbox{\i{operator}}\ \langle M\sub  1%
+\ a\sub 1\ldots a\sub n\rangle\ldots\langle%
+M\sub k\ a\sub 1\ldots a\sub n\rangle)$$
+
+\itemitem{} If the expression $\langle M\sub i \ a\sub 1\ldots a\sub
+n\rangle$ is
+evaluated, the method $M\sub i$ will be applied to the arguments
+$a\sub 1\ldots a\sub n$.  
+For example,
+if \i{operator} is {\tt or},
+the expression $\langle M\sub i \ a\sub 1\ldots a\sub n\rangle$ is
+evaluated only if $\langle M\sub j \ a\sub 1\ldots a\sub n\rangle$,
+$1\leq j<i$, returned {\tt nil}.
+                                                      
+\itemitem{} The default order for the primary methods is 
+\kwd{most-specific-first}.  However, the order can be reversed by supplying
+\kwd{most-specific-last} as the second argument to the \kwd{method-combination} option.
+\endlist
+
+The simple built-in method combination types require exactly one
+\term{qualifier} per method.  An error is signaled if there are applicable
+methods with no \term{qualifiers} or with \term{qualifiers} that are not supported
+by the method combination type. An error is signaled if there are
+applicable \term{around methods} and no applicable primary
+methods.
+
+\endsubsubsection%{Built-in Method Combination Types}
+
+\endSubsection%{Method Selection and Combination}
+
+\beginSubsection{Inheritance of Methods}
+\DefineSection{MethodInheritance}
+
+A subclass inherits methods in the sense that any method applicable to
+all instances of a class is also applicable to all instances of any
+subclass of that class.
+
+The inheritance of methods acts the same way regardless of 
+which of the \term{method-defining operators} created the methods.
+% whether the
+% method was created by using one of the method-defining operators or by
+% using one of the \macref{defclass} options that causes methods to be
+% generated automatically.
+
+The inheritance of methods is described in detail in 
+\secref\MethodSelectionAndCombination.
+
+\endSubsection%{Inheritance of Methods}

concept-glossary.tex

@@ -0,0 +1,5091 @@
+% -*- Mode: TeX -*-
+
+% !!! Moon wonders if "denote" is the right verb for talking about what "designators"
+%     refer to.
+%
+% !!! Moon thinks the bottom header gets too close to the running text in this chapter.
+%     It even overstrikes on a few pages (e.g., p26-28 of draft 10.156)
+%
+% Barmar thinks we should define reference terms for expressions like "left & right".
+%
+% Moon sez: Most occurrences of "which" in the glossary should be "that" in correct English.
+% I should review this later. -kmp
+%
+% Think about unifying terms: "type lattice", "type hierarchy", "type hierarchy lattice",
+% "directed acyclic graph".
+% RPG says "hierarchy" or "dag" are ok, but not "lattice".
+% Allan Wechsler (ACW@Symbolics.COM) says: 
+%  Regarding DAGs vs. lattices: I don't know the basis of Dick Gabriel's
+%  objection to the latter term.  I think that it's quite clear
+%  mathematically that "lattice" is correct and "directed acyclic graph" is
+%  incorrect, but Gabriel's objection may not be mathematical.  Details on
+%  request.  I'm using the definitions from the ``Encyclopedic Dictionary of
+%  Mathematics.''
+%
+% Think about these terms, which are commonly used without definition:
+%   "qualifier pattern" - something that gets matched against in method comb.
+%   "type specifier list" - the list form of a type specifier
+%   "default value"
+%   "optional parameter", ...
+%
+% Think about these terms, which are common concepts in search of a name, to cut
+% down on wasted verbiage at multiple places in the text.
+%   "stringname" - a string or a symbol, which is taken the name of a string.
+%                  if a symbol, then then it is treated as if its name had been supplied.
+%
+% Sometime search for braces immediately followed by an alpha char 
+% ("{...}s", "{...}es", "{...}ing", "{...}ed", etc.) because these are often
+% clues to needed glossary words.
+%
+% KMP: Maybe a term "user symbol" being defined as 
+%      "a symbol that is not accessible in the common-lisp package".
+%    (I find it cumbersome to write a param description that says
+%     a symbol that is not in the common-lisp package.
+%    This comes up in a number of places.)
+% Barmar: That sounds like a reasonable term and definition.
+% KMP: Issue--some places might need a restriction on keywords, too, but that should
+%    probably not be piggy-backed on the "user symbol" term.
+
+\def\gentry#1{\itemitem{}\b{#1}\idxterm{#1}}
+\def\gexample#1{{``#1''}}
+\def\indextab#1{\endlist\indextabnote{#1}\beginlist}
+\def\firstindextab#1{\indextabnote{#1}\beginlist}
+\def\indextabnote#1{\goodbreak\item{\b{#1}}\penalty20000}
+ 
+\def\Noun{\i{n.}}
+\def\Verb{\i{v.}}
+\def\TransitiveVerb{\i{v.t.}}
+\def\Adjective{\i{adj.}}
+\def\Adverb{\i{adv.}}
+
+\def\ANSI{\i{ANSI}}
+\def\IEEE{\i{IEEE}}
+\def\ISO{\i{ISO}}
+\def\Traditional{\i{Trad.}}
+\def\Mathematics{\i{Math.}}
+\def\Idiomatic{\i{Idiom.}}
+\def\Computers{\i{Comp.}}
+
+%% Glossary
+ 
+Each entry in this glossary has the following parts:
+ 
+\beginlist
+ 
+\item{\bull} the term being defined, set in boldface.
+ 
+ \item{\bull} optional pronunciation, enclosed in square brackets and
+set in boldface, as in the following example:
+\pronounced{\Stress{a}\stress{list}}.  The pronunciation key follows
+\WebstersDictionary\TypographyCaveats.
+ 
+ \item{\bull} the part or parts of speech, set in italics.  If a term
+can be used as several parts of speech, there is a separate definition
+for each part of speech.
+ 
+ \item{\bull} one or more definitions, organized as follows:
+ 
+\beginlist
+ 
+ \item{--} an optional number, present if there are several
+definitions. Lowercase letters might also be used in cases where subdefinitions of
+a numbered definition are necessary.
+ 
+ \item{--} an optional part of speech, set in italics, present if the
+term is one of several parts of speech.
+ 
+ \item{--} an optional discipline, set in italics, present if the term
+has a standard definition being repeated. For example, ``{\Mathematics}''
+ 
+ \item{--} an optional context, present if this definition is
+meaningful only in that context. For example, ``(of a \term{symbol})''.
+ 
+ \item{--} the definition.
+ 
+ \item{--} an optional example sentence. For example,
+           \gexample{This is an example of an example.}
+ 
+ \item{--} optional cross references.
+%%There are a lot of options, and they are all pretty self-explanatory. -kmp 11-Sep-91
+%A cross reference to another word uses the following form: \Seeterm{word}.
+%A cross reference to a section uses the following form: \Seesection\Sample.
+ 
+\endlist
+\endlist
+ 
+In addition, some terms have idiomatic usage in the Common Lisp
+community which is not shared by other communities, or which is not
+technically correct.  Definitions labeled ``{\Idiomatic}'' represent
+such idiomatic usage; these definitions are sometimes followed by an
+explanatory note.
+ 
+Words in \term{this font} are words with entries in the glossary.
+%Word in \typeref{this font} are names of data types.
+Words in example sentences do not follow this convention.
+ 
+When an ambiguity arises, the longest matching substring has precedence.
+For example, ``\term{complex float}'' refers to a single glossary entry 
+for ``\term{complex float}'' rather than the combined meaning of the 
+glossary terms ``\term{complex}'' and ``\term{float}.''
+
+Subscript notation, as in ``\term{something}\meaning{n}'' means that
+the \i{n}th definition of ``\term{something}'' is intended.  This
+notation is used only in situations where the context might be insufficient
+to disambiguate.
+
+The following are abbreviations used in the glossary:
+ 
+\tabletwo{Abbreviation}{Meaning}{
+\entry{\Adjective}{adjective}
+\entry{\Adverb}{adverb}
+\entry{\ANSI}{compatible with one or more ANSI standards}
+\entry{\Computers}{computers}
+\entry{\Idiomatic}{idiomatic}
+\entry{\IEEE}{compatible with one or more IEEE standards}
+\entry{\ISO}{compatible with one or more ISO standards}
+\entry{\Mathematics}{mathematics}
+\entry{\Traditional}{traditional}
+\entry{\Noun}{noun}
+\entry{\Verb}{verb}
+\entry{\TransitiveVerb}{transitive verb}
+}
+ 
+\beginlist
+
+\firstindextab{Non-alphabetic}
+
+\gentry{()} \pronounced{\Stress{nil}}, \Noun\
+  an alternative notation for writing the symbol~\nil, used to emphasize
+  the use of \term{nil} as an \term{empty list}.
+
+\indextab{A}
+
+\gentry{absolute} \Adjective\
+  1. (of a \term{time})
+     representing a specific point in time.
+  2. (of a \term{pathname})
+     representing a specific position in a directory hierarchy.
+  \Seeterm{relative}.
+
+\gentry{access} \Noun, \TransitiveVerb\
+%\term{variable} removed since generalized reference implies it.
+  1. \TransitiveVerb\ (a \term{place}, or \term{array})
+     to \term{read}\meaning{1} or \term{write}\meaning{1} the \term{value} of
+         the \term{place}
+      or an \term{element} of the \term{array}.
+  2. \Noun\ (of a \term{place})
+     an attempt to \term{access}\meaning{1} the \term{value} of the \term{place}.
+
+% Moon: Useless entry. Adds nothing to normal English usage.
+% KMP: Allows usage to be italicized; also, courtesy to non-native 
+%      English speakers, who may not be as familiar with all our word forms.
+\gentry{accessibility} \Noun\
+  the state of being \term{accessible}.
+
+%!!! Moon: accessible[1] and reference[2] don't seem to match up.
+\gentry{accessible} \Adjective\ 
+  1. (of an \term{object}) capable of being \term{referenced}.
+  2. (of \term{shared slots} or \term{local slots} in an \term{instance} of 
+     a \term{class}) having been defined by the \term{class} 
+     of the \term{instance} or \term{inherited} from a
+     \term{superclass} of that \term{class}.
+%!!! JonL: this reader thing should be an effect, not the definition.
+%          use "present" and "inherited".
+  3. (of a \term{symbol} in a \term{package})
+     capable of being \term{referenced} without a \term{package prefix} 
+     when that \term{package} is current, regardless of whether the
+     \term{symbol} is \term{present} in that \term{package} or is \term{inherited}.
+
+\gentry{accessor} \Noun\
+  an \term{operator} that performs an \term{access}.
+  \Seeterm{reader} and \term{writer}.
+
+\gentry{active} \Adjective\ 
+  1. (of a \term{handler}, a \term{restart}, or a \term{catch tag})
+     having been \term{established} but not yet \term{disestablished}.
+  2. (of an \term{element} of an \term{array})
+     having an index that is greater than or equal to zero,
+     but less than the \term{fill pointer} (if any).
+     For an \term{array} that has no \term{fill pointer},
+     all \term{elements} are considered \term{active}.
+
+\gentry{actual adjustability} \Noun\ (of an \term{array})
+  a \term{generalized boolean} that is associated with the \term{array}, 
+  representing whether the \term{array} is \term{actually adjustable}.
+  \SeetermAlso{expressed adjustability} and \funref{adjustable-array-p}.
+
+\gentry{actual argument} \Noun\ \Traditional\ 
+  an \term{argument}.
+
+\gentry{actual array element type} \Noun\ (of an \term{array})
+  the \term{type} for which the \term{array} is actually specialized,
+  which is the \term{upgraded array element type} of 
+  the \term{expressed array element type} of the \term{array}.
+  \Seefun{array-element-type}.
+
+\gentry{actual complex part type} \Noun\ (of a \term{complex})
+  the \term{type} in which the real and imaginary parts of the \term{complex}
+  are actually represented, which is the \term{upgraded complex part type} of the
+  \term{expressed complex part type} of the \term{complex}.
+
+\gentry{actual parameter} \Noun\ \Traditional\ 
+  an \term{argument}.
+
+\gentry{actually adjustable} \Adjective\ (of an \term{array})
+  such that \funref{adjust-array} can adjust its characteristics
+  by direct modification.
+  A \term{conforming program} may depend on
+  an \term{array} being \term{actually adjustable}
+  only if either that \term{array} is known to have been \term{expressly adjustable}
+  or if that \term{array} has been explicitly tested by \funref{adjustable-array-p}.
+
+\gentry{adjustability} \Noun\ (of an \term{array})
+  1. \term{expressed adjustability}.
+  2. \term{actual adjustability}.
+
+\gentry{adjustable} \Adjective\ (of an \term{array})
+  1. \term{expressly adjustable}.
+  2. \term{actually adjustable}.
+
+\gentry{after method} \Noun\
+  a \term{method} having the \term{qualifier} \kwd{after}.
+
+\gentry{alist} \pronounced{\Stress{\harda}\stress{list}}, \Noun\ 
+  an \term{association list}.
+ 
+\gentry{alphabetic} \Noun, \Adjective\
+%% 13.2.0 12
+  1. \Adjective\ (of a \term{character})
+     being one of the \term{standard characters} \f{A} through \f{Z} 
+         or \f{a} through \f{z},
+      or being any \term{implementation-defined} character that has \term{case},
+      or being some other \term{graphic} \term{character}
+         defined by the \term{implementation} to be \term{alphabetic}\meaning{1}.
+  2. a. \Noun\
+        one of several possible \term{constituent traits} of a \term{character}.
+        For details, \seesection\ConstituentChars\ and \secref\ReaderAlgorithm.
+     b. \Adjective\ (of a \term{character})
+        being a \term{character} 
+              that has \term{syntax type} \term{constituent} in the \term{current readtable} 
+	  and that has the \term{constituent trait} \term{alphabetic}\meaning{2a}.
+	\Seefigure\ConstituentTraitsOfStdChars.
+
+\gentry{alphanumeric} \Adjective\ (of a \term{character})
+%% 13.2.0 12
+  being either an \term{alphabetic}\meaning{1} \term{character}
+            or a \term{numeric} {character}.
+
+\gentry{ampersand} \Noun\
+  the \term{standard character} that is called ``ampersand'' (\f{\&}).
+  \Seefigure\StdCharsThree.
+
+\gentry{anonymous} \Adjective\ 
+  1. (of a \term{class} or \term{function}) having no \term{name}
+  2. (of a \term{restart}) having a \term{name} of \nil.
+
+\gentry{apparently uninterned} \Adjective\ 
+  having a \term{home package} of \nil.  (An \term{apparently uninterned} \term{symbol} 
+  might or might not be an \term{uninterned} \term{symbol}.  \term{Uninterned symbols}
+  have a \term{home package} of \nil, but \term{symbols} which have been \term{uninterned}
+  from their \term{home package} also have a \term{home package} of \nil,
+  even though they might still be \term{interned} in some other \term{package}.)
+
+%!!! Moon: Need to reconcile this entry with the following three.
+\gentry{applicable} \Adjective\
+  1. (of a \term{handler}) being an \term{applicable handler}.
+  2. (of a \term{method}) being an \term{applicable method}.
+  3. (of a \term{restart}) being an \term{applicable restart}.
+
+\gentry{applicable handler} \Noun\ (for a \term{condition} being \term{signaled})
+  an \term{active} \term{handler} for which the associated type contains the
+  \term{condition}.
+
+\gentry{applicable method} \Noun\ (of a \term{generic function}
+				     called with \term{arguments})
+  a \term{method} of the \term{generic function} for which the
+  \term{arguments} satisfy the \term{parameter specializers} 
+  of that \term{method}.
+% and which has not been \term{shadowed}\meaning{2}.
+%Moon says: ``applicableness does not take method combination into account
+%             and shadowing is a property of method combination.''
+  \Seesection\SelApplMeth.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\gentry{applicable restart} \Noun\
+  1. (for a \term{condition})
+     an \term{active} \term{handler} for which the associated test returns 
+     \term{true} when given the \term{condition} as an argument.
+  2. (for no particular \term{condition})
+     an \term{active} \term{handler} for which the associated test returns 
+     \term{true} when given \nil\ as an argument.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\gentry{apply} \TransitiveVerb\ (a \term{function} to a \term{list})
+  to \term{call} the \term{function} with arguments that are the \term{elements}
+  of the \term{list}.
+  \gexample{Applying the function \funref{+} to a list of integers returns
+	    the sum of the elements of that list.} 
+
+\gentry{argument} \Noun\
+  1. (of a \term{function}) an \term{object} which is offered as data
+     to the \term{function} when it is \term{called}.
+%% I wonder if we should say this. -kmp
+%    In other literature, but not here, this is sometimes called an ``actual argument.''
+%
+% 1. (of a \term{function}) an \term{object} which is paired 
+%    with a corresponding \term{parameter} in order to provide data
+%    flow into the function at the time it is called.
+% Moon says:
+%   ``Not all arguments have corresponding parameters, when the function accepts
+%     keyword or rest arguments.  Consider \kwd{allow-other-keys}.  Thus this definition
+%     cannot be exactly correct.  I don't think the definition of arguments should
+%     have anything to do with what the function does internally to receive the
+%     arguments.''
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+  2. (of a \term{format control}) a \term{format argument}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\gentry{argument evaluation order} \Noun\ 
+  the order in which \term{arguments} are evaluated in a function call.
+  \gexample{The argument evaluation order for Common Lisp is left to right.}
+  \Seesection\Evaluation.
+
+\gentry{argument precedence order} \Noun\
+  the order in which the \term{arguments} to a \term{generic function} are
+  considered when sorting the \term{applicable methods} into precedence order.
+
+\gentry{around method} \Noun\
+  a \term{method} having the \term{qualifier} \kwd{around}.
+
+\gentry{array} \Noun\
+  an \term{object} \oftype{array}, which serves as a container for other
+  \term{objects} arranged in a Cartesian coordinate system.
+
+\gentry{array element type} \Noun\ (of an \term{array})
+  1. a \term{type} associated with the \term{array}, 
+     and of which all \term{elements} of the \term{array} are 
+     constrained to be members.
+  2. the \term{actual array element type} of the \term{array}.
+  3. the \term{expressed array element type} of the \term{array}.
+
+\gentry{array total size} \Noun\ 
+  the total number of \term{elements} in an \term{array}, computed by taking 
+  the product of the \term{dimensions} of the \term{array}.
+  (The size of a zero-dimensional \term{array} is therefore one.)
+
+\gentry{assign} \TransitiveVerb\ (a \term{variable})
+  to change the \term{value} of the \term{variable} in a \term{binding}
+  that has already been \term{established}.
+  \Seespec{setq}.
+
+\gentry{association list} \Noun\ 
+  a \term{list} of \term{conses} representing an association 
+  of \term{keys} with \term{values}, where the \term{car} of each
+  \term{cons} is the \term{key} and the \term{cdr} is the
+  \term{value} associated with that \term{key}.
+ 
+\gentry{asterisk} \Noun\
+  the \term{standard character} that is variously called
+      ``asterisk''
+   or ``star'' (\f{*}).
+  \Seefigure\StdCharsThree.
+
+\gentry{at-sign} \Noun\
+  the \term{standard character} that is variously called
+     ``commercial at''
+  or ``at sign'' (\f{@}).
+  \Seefigure\StdCharsThree.
+
+\gentry{atom} \Noun\
+  any \term{object} that is not a \term{cons}.
+  \gexample{A vector is an atom.}
+
+\gentry{atomic} \Adjective\ 
+  being an \term{atom}.
+  \gexample{The number 3, the symbol \f{foo}, and \nil\ are atomic.}
+
+\gentry{atomic type specifier} \Noun\
+  a \term{type specifier} that is \term{atomic}.
+  For every \term{atomic type specifier}, \i{x}, there is an equivalent
+  \term{compound type specifier} with no arguments supplied, \f{(\i{x})}.
+
+\gentry{attribute} \Noun\ (of a \term{character})
+  a program-visible aspect of the \term{character}.
+  The only \term{standardized} \term{attribute} of a \term{character}
+  is its \term{code}\meaning{2}, but \term{implementations} are permitted to have
+  additional \term{implementation-defined} \term{attributes}.
+  \Seesection\CharacterAttributes.
+  \gexample{An implementation that support fonts
+            might make font information an attribute of a character,
+            while others might represent font information separately from characters.}
+
+\gentry{aux variable} \Noun\
+  a \term{variable} that occurs in the part of a \term{lambda list}
+  that was introduced by \keyref{aux}.  Unlike all other \term{variables}
+  introduced by a \term{lambda-list}, \term{aux variables} are not 
+  \term{parameters}.
+
+\gentry{auxiliary method} \Noun\
+  a member of one of two sets of \term{methods} 
+  (the set of \term{primary methods} is the other)
+  that form an exhaustive partition of the set of \term{methods}
+  on the \term{method}'s \term{generic function}.
+  How these sets are determined is dependent on the \term{method combination} type;
+  \seesection\IntroToMethods.
+
+\indextab{B}
+ 
+\gentry{backquote} \Noun\
+  the \term{standard character} that is variously called
+       ``grave accent'' 
+    or ``backquote'' (\f{`}).
+  \Seefigure\StdCharsThree.
+
+\gentry{backslash} \Noun\
+  the \term{standard character} that is variously called
+       ``reverse solidus'' 
+    or ``backslash'' (\f{\\}).
+  \Seefigure\StdCharsThree.
+
+\gentry{base character} \Noun\
+  a \term{character}
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+  \oftype{base-char}.
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+
+\gentry{base string} \Noun\
+  a \term{string} \oftype{base-string}.
+
+\gentry{before method} \Noun\
+  a \term{method} having the \term{qualifier} \kwd{before}.
+
+\gentry{bidirectional} \Adjective\ (of a \term{stream})
+  being both an \term{input} \term{stream} and an \term{output} \term{stream}.
+
+\gentry{binary} \Adjective\ 
+  1. (of a \term{stream})
+     being a \term{stream} that has an \term{element type} that is a \subtypeof{integer}.
+     The most fundamental operation on a \term{binary} \term{input} \term{stream} 
+     is \funref{read-byte} and on a \term{binary} \term{output} \term{stream} 
+     is \funref{write-byte}.
+     \Seeterm{character}.
+  2. (of a \term{file})
+     having been created by opening a \term{binary} \term{stream}.
+     (It is \term{implementation-dependent} whether this is an detectable aspect 
+      of the \term{file}, or whether any given \term{character} \term{file} can be
+      treated as a \term{binary} \term{file}.)
+
+%!!! JonL: In the iteration chapter, you also use this to mean to 
+%          reset the value of a variable.
+% KMP: Those references need to be fixed.
+\gentry{bind} \TransitiveVerb\ (a \term{variable})
+  to establish a \term{binding} for the \term{variable}.
+
+\gentry{binding} \Noun\ 
+  an association between a \term{name} and that which the \term{name} 
+  denotes.  
+  \gexample{A lexical binding is a lexical association between a 
+            name and its value.}
+%% Added per Boyer/Kaufmann/Moore #5 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+  When the term \term{binding} is qualified by the name of a \term{namespace},
+  such as ``variable'' or ``function,'' 
+  it restricts the binding to the indicated namespace, as in:
+  \gexample{\specref{let} establishes variable bindings.}
+  or 
+  \gexample{\specref{let} establishes bindings of variables.}
+ 
+\gentry{bit} \Noun\ 
+  an \term{object} \oftype{bit}; 
+  that is, the \term{integer} \f{0} or the \term{integer} \f{1}.
+
+\gentry{bit array} \Noun\
+  a specialized \term{array} that is of \term{type} \f{(array bit)},
+  and whose elements are \oftype{bit}.
+
+\gentry{bit vector} \Noun\ 
+  a specialized \term{vector} that is \oftype{bit-vector},
+  and whose elements are \oftype{bit}.
+
+\gentry{bit-wise logical operation specifier} \Noun\ 
+  an \term{object} which names one of the sixteen possible bit-wise logical
+  operations that can be performed by the \funref{boole} function,
+  and which is the \term{value} of exactly one of the
+  \term{constant variables} 
+  \conref{boole-clr},     \conref{boole-set},
+  \conref{boole-1},       \conref{boole-2},
+  \conref{boole-c1},      \conref{boole-c2},
+  \conref{boole-and},     \conref{boole-ior},
+  \conref{boole-xor},     \conref{boole-eqv},
+  \conref{boole-nand},    \conref{boole-nor},
+  \conref{boole-andc1},   \conref{boole-andc2},
+  \conref{boole-orc1}, or \conref{boole-orc2}.
+
+\gentry{block} \Noun\
+  a named lexical \term{exit point}, 
+  \term{established} explicitly by \specref{block}
+  		  or implicitly by \term{operators} 
+		       such as \macref{loop}, \macref{do} and \macref{prog},
+  to which control and values may be transfered by 
+  using a \specref{return-from} \term{form} with the name of the \term{block}.
+
+\gentry{block tag} \Noun\ 
+  the \term{symbol} that, within the \term{lexical scope} 
+  of a \specref{block} \term{form}, names the \term{block}
+  \term{established} by that \specref{block} \term{form}.
+  See \macref{return} or \specref{return-from}.
+
+\gentry{boa lambda list} \Noun\
+  a \term{lambda list} that is syntactically like an \term{ordinary lambda list},
+  but that is processed in ``\b{b}y \b{o}rder of \b{a}rgument'' style.
+  \Seesection\BoaLambdaLists.
+
+\gentry{body parameter} \Noun\
+  a \term{parameter} available in certain \term{lambda lists}
+  which from the point of view of \term{conforming programs}
+  is like a \term{rest parameter} in every way except that it is introduced
+  by \keyref{body} instead of \keyref{rest}.  (\term{Implementations} are 
+  permitted to provide extensions which distinguish \term{body parameters}
+  and \term{rest parameters}---\eg the \term{forms} for \term{operators}
+  which were defined using a \term{body parameter} might be pretty printed
+  slightly differently than \term{forms} for \term{operators} which were 
+  defined using \term{rest parameters}.)
+
+\gentry{boolean} \Noun\ 
+  an \term{object} \oftype{boolean};
+  that is, one of the following \term{objects}: 
+       the symbol~\t\   (representing \term{true}),
+    or the symbol~\nil\ (representing \term{false}).
+  \Seeterm{generalized boolean}.
+
+\gentry{boolean equivalent} \Noun\ (of an \term{object} $O\sub 1$)
+  any \term{object} $O\sub 2$ that has the same truth value as $O\sub 1$
+  when both $O\sub 1$ and $O\sub 2$ are viewed as \term{generalized booleans}.
+ 
+\gentry{bound} \Adjective, \TransitiveVerb\ 
+  1. \Adjective\ having an associated denotation in a \term{binding}.
+     \gexample{The variables named by a \specref{let} are bound within
+               its body.}
+     \Seeterm{unbound}.
+  2. \Adjective\ having a local \term{binding} which 
+     \term{shadows}\meaning{2} another. 
+     \gexample{The variable \varref{*print-escape*} is bound while in
+               the \funref{princ} function.}
+  3. \TransitiveVerb\ the past tense of \term{bind}.
+
+\gentry{bound declaration} \Noun\ 
+  a \term{declaration} that refers to or is associated with a \term{variable}
+  or \term{function} and that appears within the \term{special form} 
+  that \term{establishes} the \term{variable} or \term{function},
+  but before the body of that \term{special form}
+% This next parenthetical remark was added because Moon thinks (and I agree)
+% that rather than just "within" we need to say "at the head of the body" 
+% in order to make it clear that 
+%    (let ((a (let ((b 1))
+%               (declare (fixnum a))
+%               (expt b 100))))
+%      (print a))
+%    is not accidentally covered.
+  (specifically, at the head of that \term{form}'s body).
+%!!! Barmar: The following should be replaced by a cross-reference to a
+%   	     concept section.
+  (If a \term{bound declaration} refers to a \term{function} \term{binding} or
+   a \term{lexical variable} \term{binding}, the \term{scope} of
+   the \term{declaration} is exactly the \term{scope} of that
+   \term{binding}.  If the \term{declaration} refers to a
+   \term{dynamic variable} \term{binding}, the \term{scope} of
+   the \term{declaration} is what the \term{scope} of the 
+   \term{binding} would have been if it were lexical rather than dynamic.)
+ 
+\gentry{bounded} \Adjective\ (of a \term{sequence} $S$,
+			      by an ordered pair
+			          of \term{bounding indices} $i\sub{start}$ and $i\sub{end}$)
+  restricted to a subrange of the \term{elements} of $S$ that includes each \term{element}
+  beginning with (and including) the one indexed by $i\sub{start}$ and
+  continuing up to (but not including) the one indexed by $i\sub{end}$.
+
+\gentry{bounding index} \Noun\ (of a \term{sequence} with \term{length} $n$)
+  either of a conceptual pair of \term{integers}, $i\sub{start}$ and $i\sub{end}$,
+  respectively called the ``lower bounding index'' and ``upper bounding index'',
+  such that $0 \leq i\sub{start} \leq i\sub{end} \leq n$, and which therefore delimit
+  a subrange of the \term{sequence} \term{bounded} by $i\sub{start}$ and $i\sub{end}$.
+
+\gentry{bounding index designator} (for a \term{sequence})
+  one of two \term{objects} that, taken together as an ordered pair, 
+  behave as a \term{designator} for \term{bounding indices} of the \term{sequence}; 
+  that is, they denote \term{bounding indices} of the \term{sequence},
+  and are either:
+      an \term{integer} (denoting itself) and \nil\ 
+       (denoting the \term{length} of the \term{sequence}),
+   or two \term{integers} (each denoting themselves).
+
+\gentry{break loop} \Noun\
+  A variant of the normal \term{Lisp read-eval-print loop} that is recursively
+  entered, usually because the ongoing \term{evaluation} of some other \term{form}
+  has been suspended for the purpose of debugging.  Often, a \term{break loop}
+  provides the ability to exit in such a way as to continue the suspended computation.
+  \Seefun{break}.
+
+\gentry{broadcast stream} \Noun\
+  an \term{output} \term{stream} \oftype{broadcast-stream}.
+
+\gentry{built-in class} \Noun\
+%"instance" => "generalized instance" per Quinquevirate. -kmp 14-Feb-92
+  a \term{class} that is a \term{generalized instance} \ofclass{built-in-class}.
+
+%!!! KMP: This term is confusing and should probably be called something else.
+\gentry{built-in type} \Noun\
+   one of the \term{types} in \figref\StandardizedAtomicTypeSpecs.
+
+% \gentry{built-in type} \Noun\
+%   one of the \term{types} in \thenextfigure.
+% 
+% Moon: Aren't there a bunch missing, like base-char and simple-vector.
+% \displaythree{Built-in types}{
+% array&integer&restart\cr
+% bit-vector&long-float&sequence\cr
+% character&null&short-float\cr
+% complex&number&single-float\cr
+% condition&package&stream\cr
+% cons&pathname&string\cr
+% double-float&random-state&symbol\cr
+% float&ratio&vector\cr
+% function&rational&\cr
+% hash-table&readtable&\cr
+% }
+
+\gentry{byte} \Noun\
+  1. adjacent bits within an \term{integer}.
+     (The specific number of bits can vary from point to point in the program;
+      \seefun{byte}.)
+  2. an integer in a specified range.
+% Moon: Below 0 and a power of 2?
+% KMP: I'm not so sure.  In the context of OPEN, it seems to mean any integer.
+     (The specific range can vary from point to point in the program;
+      \seefuns{open} and \funref{write-byte}.)
+
+\gentry{byte specifier} \Noun\
+  An \term{object} of \term{implementation-dependent} nature 
+  that is returned by \thefunction{byte} and
+  that specifies the range of bits in an \term{integer} to be used
+  as a \term{byte} by \term{functions} such as \funref{ldb}.
+
+\indextab{C}
+
+\gentry{cadr} \pronounced{\Stress{ka}\stress{d\schwa r}}, \Noun\ (of an \term{object})
+  the \term{car} of the \term{cdr} of that \term{object}.
+
+\gentry{call} \TransitiveVerb, \Noun\ 
+  1. \TransitiveVerb\ (a \term{function} with \term{arguments})
+     to cause the \term{code} represented by that \term{function} to be 
+     \term{executed} in an \term{environment} where \term{bindings} for
+     the \term{values} of its \term{parameters} have been \term{established}
+     based on the \term{arguments}.
+     \gexample{Calling the function \funref{+} with the arguments 
+               \f{5} and \f{1} yields a value of \f{6}.}
+  2. \Noun\ a \term{situation} in which a \term{function} is called.
+
+\gentry{captured initialization form} \Noun\
+  an \term{initialization form} along with the \term{lexical environment}
+  in which the \term{form} that defined the \term{initialization form}
+  was \term{evaluated}.
+  \gexample{Each newly added shared slot is set to the result of evaluating
+            the captured initialization form for the slot that was specified
+            in the \macref{defclass} form for the new class.}
+
+\gentry{car} \Noun\
+  1. a. (of a \term{cons}) 
+        the component of a \term{cons} corresponding to the first
+        \term{argument} to \funref{cons}; the other component is the
+        \term{cdr}.
+	\gexample{The function \funref{rplaca} modifies the car of a cons.}
+     b. (of a \term{list})
+        the first \term{element} of the \term{list}, or \nil\ if the
+        \term{list} is the \term{empty list}.
+  2. the \term{object} that is held in the \term{car}\meaning{1}.
+     \gexample{The function \funref{car} returns the car of a cons.}
+ 
+\gentry{case} \Noun\ (of a \term{character})
+  the property of being either \term{uppercase} or \term{lowercase}.
+  Not all \term{characters} have \term{case}.
+  \gexample{The characters \f{\#\\A} and \f{\#\\a} have case,
+	    but the character \f{\#\\\$} has no case.}
+  \Seesection\CharactersWithCase\ and \thefunction{both-case-p}.
+
+\gentry{case sensitivity mode} \Noun\
+  one of the \term{symbols}
+  \kwd{upcase}, \kwd{downcase}, \kwd{preserve}, or \kwd{invert}.
+
+\gentry{catch} \Noun\
+  an \term{exit point} which is \term{established} by a \specref{catch}
+  \term{form} within the \term{dynamic scope} of its body,
+  which is named by a \term{catch tag},
+  and to which control and \term{values} may be \term{thrown}.
+
+\gentry{catch tag} \Noun\
+  an \term{object} which names an \term{active} \term{catch}.
+  (If more than one \term{catch} is active with the same \term{catch tag},
+   it is only possible to \term{throw} to the innermost such \term{catch}
+   because the outer one is \term{shadowed}\meaning{2}.)
+
+\gentry{cddr} \pronounced{\Stress{k\.ud}\schwa \stress{d\schwa r}} or
+	      \pronounced{\Stress{k\schwa}\stress{d\.ud\schwa r}}, \Noun\ 
+	      (of an \term{object})
+  the \term{cdr} of the \term{cdr} of that \term{object}.
+
+\gentry{cdr} \pronounced{\Stress{k\.u}\stress{d\schwa r}}, \Noun\ 
+  1. a. (of a \term{cons}) 
+        the component of a \term{cons} corresponding to the second \term{argument}
+        to \funref{cons}; the other component is the \term{car}.
+	\gexample{The function \funref{rplacd} modifies the cdr of a cons.}
+     b. (of a \term{list} $L\sub 1$)
+        either the \term{list} $L\sub 2$ that contains 
+	       the \term{elements} of $L\sub 1$ that follow after the first, 
+	or else \nil\ if $L\sub 1$ is the \term{empty list}.
+  2. the \term{object} that is held in the \term{cdr}\meaning{1}.
+     \gexample{The function \funref{cdr} returns the cdr of a cons.}
+
+\gentry{cell} \Noun\ \Traditional\ (of an \term{object})
+  a conceptual \term{slot} of that \term{object}.
+  The \term{dynamic variable} and global \term{function} \term{bindings}
+  of a \term{symbol} are sometimes referred to as its \term{value cell}
+  and \term{function cell}, respectively.
+
+\gentry{character} \Noun, \Adjective\
+  1. \Noun\ an \term{object} \oftype{character}; that is,
+     an \term{object} that represents a unitary token in an aggregate quantity of text;
+     \seesection\CharacterConcepts.
+  2. \Adjective\ 
+     a. (of a \term{stream})
+        having an \term{element type} that is a \subtypeof{character}.
+        The most fundamental operation on a \term{character} \term{input} \term{stream} 
+        is \funref{read-char} and on a \term{character} \term{output} \term{stream} 
+        is \funref{write-char}. \Seeterm{binary}.
+     b. (of a \term{file})
+        having been created by opening a \term{character} \term{stream}.
+        (It is \term{implementation-dependent} whether this is an inspectable aspect 
+         of the \term{file}, or whether any given \term{binary} \term{file} can be
+         treated as a \term{character} \term{file}.)
+
+%!!! Moon: This never says what it is!
+\gentry{character code} \Noun\
+  1. one of possibly several \term{attributes} of a \term{character}.
+  2. a non-negative \term{integer} less than \thevalueof{char-code-limit}
+     that is suitable for use as a \term{character code}\meaning{1}.
+
+\gentry{character designator} \Noun\
+  a \term{designator} for a \term{character}; that is,
+  an \term{object} that denotes a \term{character} 
+  and that is one of:
+       a \term{designator} for a \term{string} of \term{length} one
+         (denoting the \term{character} that is its only \term{element}),
+\issue{CHARACTER-PROPOSAL:2-1-1}
+% Integers used to be permitted (a la INT-CHAR), but are now removed.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+    or a \term{character} (denoting itself).
+
+\gentry{circular} \Adjective\
+  1. (of a \term{list}) a \term{circular list}.
+  2. (of an arbitrary \term{object})
+     having a \term{component}, \term{element}, \term{constituent}\meaning{2}, 
+     or \term{subexpression} (as appropriate to the context) 
+     that is the \term{object} itself.
+
+\gentry{circular list} \Noun\ 
+  a chain of \term{conses} that has no termination because some
+ \term{cons} in the chain is the \term{cdr} of a later \term{cons}.
+
+\gentry{class} \Noun\
+  1. an \term{object} that uniquely determines the structure and behavior of 
+     a set of other \term{objects} called its \term{direct instances}, 
+     that contributes structure and behavior to a set of
+     other \term{objects} called its \term{indirect instances},
+     and that acts as a \term{type specifier} for a set of objects
+     called its \term{generalized instances}.
+     \gexample{The class \typeref{integer} is a subclass of the class \typeref{number}.}
+     (Note that the phrase ``the \term{class} \f{foo}'' is often substituted for
+      the more precise phrase ``the \term{class} named \f{foo}''---in both
+      cases, a \term{class} \term{object} (not a \term{symbol}) is denoted.)
+  2. (of an \term{object})
+     the uniquely determined \term{class} of which the \term{object} is
+     a \term{direct instance}.
+     \Seefun{class-of}.
+     \gexample{The class of the object returned by \funref{gensym} 
+ 	       is \typeref{symbol}.}
+     (Note that with this usage a phrase such as ``its \term{class} is \f{foo}'' 
+      is often substituted for the more precise phrase
+      ``its \term{class} is the \term{class} named \f{foo}''---in both
+      cases, a \term{class} \term{object} (not a \term{symbol}) is denoted.)
+
+\gentry{class designator} \Noun\
+  a \term{designator} for a \term{class}; that is,
+  an \term{object} that denotes a \term{class} 
+  and that is one of:
+       a \term{symbol} (denoting the \term{class} named by that \term{symbol};
+		        \seefun{find-class})
+    or a \term{class} (denoting itself).
+
+\gentry{class precedence list} \Noun\
+  a unique total ordering on a \term{class}
+  and its \term{superclasses} that is consistent with the
+  \term{local precedence orders} for the \term{class} and its
+  \term{superclasses}.
+  For detailed information, \seesection\DeterminingtheCPL.
+
+\gentry{close} \TransitiveVerb\ (a \term{stream})
+  to terminate usage of the \term{stream} as a source or sink of data,
+  permitting the \term{implementation} to reclaim its internal data structures,
+  and to free any external resources which might have been locked by the
+ \term{stream} when it was opened.
+
+\gentry{closed} \Adjective\ (of a \term{stream})
+  having been \term{closed} (\seeterm\term{close}).
+  Some (but not all) operations that are valid on \term{open} \term{streams} 
+  are not valid on \term{closed} \term{streams}.
+  \Seesection\OpenAndClosedStreams.
+
+\gentry{closure} \Noun\
+  a \term{lexical closure}.
+ 
+%"constant objects" => "literal objects" per Moon #4(first public review) --kmp 5-May-93
+\gentry{coalesce} \TransitiveVerb\ (\term{literal objects} that are \term{similar})
+  to consolidate the identity of those \term{objects},
+  such that they become the \term{same} %was "identical". -kmp 27-Jul-93
+  \term{object}.
+  \Seesection\CompilationTerms.
+
+\gentry{code} \Noun\
+  1. \Traditional\ 
+     any representation of actions to be performed, whether conceptual
+     or as an actual \term{object}, such as
+         \term{forms},
+         \term{lambda expressions},
+         \term{objects} of \term{type} \term{function}, 
+         text in a \term{source file},
+      or instruction sequences in a \term{compiled file}.
+      This is a generic term;
+      the specific nature of the representation depends on its context.
+  2. (of a \term{character})
+     a \term{character code}.
+
+\gentry{coerce} \TransitiveVerb\ (an \term{object} to a \term{type})
+  to produce an \term{object} from the given \term{object},
+  without modifying that \term{object},
+  by following some set of coercion rules that must be specifically 
+  stated for any context in which this term is used.
+  The resulting \term{object} is necessarily of the indicated \term{type}, 
+  except when that type is a \subtypeof{complex}; in that case,
+  if a \term{complex rational} with an imaginary part of zero would result,
+  the result is a \term{rational} 
+  rather than a \term{complex}---\seesection\RuleOfCanonRepForComplexRationals.
+
+\gentry{colon} \Noun\
+  the \term{standard character} that is called ``colon'' (\f{:}).
+  \Seefigure\StdCharsThree.
+
+\gentry{comma} \Noun\
+  the \term{standard character} that is called ``comma'' (\f{,}).
+  \Seefigure\StdCharsThree.
+
+\gentry{compilation} \Noun\
+  the process of \term{compiling} \term{code} by the \term{compiler}.
+
+%!!! Needs to acknowledge the interpreter in case of lazy semantic processing.
+\gentry{compilation environment} \Noun\ 
+  1. An \term{environment} that represents information known by the
+     \term{compiler} about a \term{form} that is being \term{compiled}.
+     \Seesection\CompilationTerms.
+  2. An \term{object} that represents the
+     \term{compilation environment}\meaning{1} 
+     and that is used as a second argument to a \term{macro function}
+     (which supplies a \term{value} for any \keyref{environment} \term{parameter}
+      in the \term{macro function}'s definition).
+
+\gentry{compilation unit} \Noun\
+  an interval during which a single unit of compilation is occurring.
+  \Seemac{with-compilation-unit}.
+
+\gentry{compile} \TransitiveVerb\ 
+  1. (\term{code})
+     to perform semantic preprocessing of the \term{code}, usually optimizing
+     one or more qualities of the code, such as run-time speed of \term{execution}
+     or run-time storage usage.  The minimum semantic requirements of compilation are
+     that it must remove all macro calls and arrange for all \term{load time values}
+     to be resolved prior to run time.
+  2. (a \term{function})
+     to produce a new \term{object} \oftype{compiled-function}
+     which represents the result of \term{compiling} the \term{code} 
+     represented by the \term{function}.  \Seefun{compile}.
+  3. (a \term{source file})
+     to produce a \term{compiled file} from a \term{source file}.
+     \Seefun{compile-file}.
+
+\gentry{compile time} \Noun\ 
+  the duration of time that the \term{compiler} is processing \term{source code}.
+
+\gentry{compile-time definition} \Noun\
+  a definition in the \term{compilation environment}.
+
+\gentry{compiled code} \Noun\
+  1. \term{compiled functions}.
+  2. \term{code} that represents \term{compiled functions},
+     such as the contents of a \term{compiled file}.
+
+\gentry{compiled file} \Noun\
+  a \term{file} which represents the results of \term{compiling} the 
+  \term{forms} which appeared in a corresponding \term{source file},
+  and which can be \term{loaded}.  \Seefun{compile-file}.
+
+\issue{COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN}
+\gentry{compiled function} \Noun\
+  an \term{object} \oftype{compiled-function}, which is a \term{function}
+  that has been \term{compiled}, which contains no references to \term{macros} that
+  must be expanded at run time, and which contains no unresolved references 
+  to \term{load time values}.
+\endissue{COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN}
+
+\gentry{compiler} \Noun\
+  a facility that is part of Lisp and that translates \term{code}
+  into an \term{implementation-dependent} form
+  that might be represented or \term{executed} efficiently.
+  The functions \funref{compile} and \funref{compile-file}
+  permit programs to invoke the \term{compiler}.
+
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+\gentry{compiler macro} \Noun\
+  an auxiliary macro definition for a globally defined \term{function}
+  or \term{macro} which might or might not be called by any given
+  \term{conforming implementation} and which must preserve the semantics
+  of the globally defined \term{function} or \term{macro} but which might
+  perform some additional optimizations.  (Unlike a \term{macro}, 
+  a \term{compiler macro} does not extend the syntax of \clisp; rather, it
+  provides an alternate implementation strategy for some existing syntax
+  or functionality.)
+
+\gentry{compiler macro expansion} \Noun\
+  1. the process of translating a \term{form} into another \term{form}
+     by a \term{compiler macro}.
+  2. the \term{form} resulting from this process.
+
+\gentry{compiler macro form} \Noun\
+  a \term{function form} or \term{macro form} whose \term{operator}
+  has a definition as a \term{compiler macro}, 
+  or a \funref{funcall} \term{form} whose first \term{argument} is a
+  \specref{function} \term{form} whose \term{argument} is the \term{name}
+  of a \term{function} that has a definition as a \term{compiler macro}.
+
+\gentry{compiler macro function} \Noun\ 
+  a \term{function} of two arguments, a \term{form} and an 
+  \term{environment}, that implements \term{compiler macro expansion} by
+  producing either a \term{form} to be used in place of the original
+  argument \term{form} or else \nil, indicating that the original \term{form}
+  should not be replaced.  \Seesection\CompilerMacros.
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+
+\gentry{complex} \Noun\
+  an \term{object} \oftype{complex}.
+
+\gentry{complex float} \Noun\
+  an \term{object} \oftype{complex} which has a \term{complex part type}
+  that is a \term{subtype} of \typeref{float}.
+  A \term{complex float} is a \term{complex},
+  but it is not a \term{float}.
+
+\gentry{complex part type} \Noun\ (of a \term{complex})
+  1. the \term{type} which is used to represent both the real part 
+     and the imaginary part of the \term{complex}.
+  2. the \term{actual complex part type} of the \term{complex}.
+  3. the \term{expressed complex part type} of the \term{complex}.
+
+\gentry{complex rational} \Noun\
+  an \term{object} \oftype{complex} which has a \term{complex part type}
+  that is a \term{subtype} of \typeref{rational}.
+  A \term{complex rational} is a \term{complex}, but it is not a \term{rational}.  
+  No \term{complex rational} has an imaginary part of zero because such a
+  number is always represented by \clisp\ as an \term{object} \oftype{rational};
+  \seesection\RuleOfCanonRepForComplexRationals.
+
+\gentry{complex single float} \Noun\
+  an \term{object} \oftype{complex} which has a \term{complex part type}
+  that is a \term{subtype} of \typeref{single-float}.
+  A \term{complex single float} is a \term{complex},
+  but it is not a \term{single float}.
+
+\gentry{composite stream} \Noun\
+  a \term{stream} that is composed of one or more other \term{streams}.
+  \gexample{\funref{make-synonym-stream} creates a composite stream.}
+ 
+\gentry{compound form} \Noun\
+  a \term{non-empty} \term{list} which is a \term{form}:
+  a \term{special form},
+  a \term{lambda form},
+  a \term{macro form}, 
+  or a \term{function form}.
+
+\gentry{compound type specifier} \Noun\
+  a \term{type specifier} that is a \term{cons};
+  \ie a \term{type specifier} that is not an \term{atomic type specifier}.
+  \gexample{\f{(vector single-float)} is a compound type specifier.}
+
+\gentry{concatenated stream} \Noun\
+  an \term{input} \term{stream} \oftype{concatenated-stream}.
+
+\gentry{condition} \Noun\
+  1. an \term{object} which represents a \term{situation}---usually,
+     but not necessarily, during \term{signaling}.
+  2. an \term{object} \oftype{condition}.
+
+\gentry{condition designator} \Noun\
+  one or more \term{objects} that, taken together, 
+  denote either an existing \term{condition} \term{object} 
+	     or a \term{condition} \term{object} to be implicitly created.
+  For details, \seesection\ConditionDesignators.
+
+\gentry{condition handler} \Noun\
+  a \term{function} that might be invoked by the act of \term{signaling},
+  that receives the \term{condition} being signaled as its only argument,
+  and that is permitted to \term{handle} the \term{condition} 
+  or to \term{decline}.  \Seesection\Signaling.
+
+\gentry{condition reporter} \Noun\
+  a \term{function} that describes how a \term{condition} is to be printed
+  when the \term{Lisp printer} is invoked while \varref{*print-escape*} 
+  is \term{false}.  \Seesection\PrintingConditions.
+
+\gentry{conditional newline} \Noun\
+  a point in output where a \term{newline} might be inserted at the
+  discretion of the \term{pretty printer}.
+  There are four kinds of \term{conditional newlines},
+  called ``linear-style,''
+	 ``fill-style,''
+	 ``miser-style,''
+     and ``mandatory-style.''
+  \Seefun{pprint-newline} and \secref\DynamicControlofOutput.
+
+\gentry{conformance} \Noun\
+  a state achieved by proper and complete adherence to the requirements
+  of this specification.  \Seesection\Conformance.
+
+\gentry{conforming code} \Noun\
+  \term{code} that is all of part of a \term{conforming program}.
+
+\gentry{conforming implementation} \Noun\
+  an \term{implementation}, used to emphasize complete and correct
+  adherance to all conformance criteria.
+  A \term{conforming implementation} is capable of 
+      accepting a \term{conforming program} as input,
+      preparing that \term{program} for \term{execution},
+  and executing the prepared \term{program} in accordance with this specification.
+  An \term{implementation} which
+  has been extended may still be a \term{conforming implementation} 
+  provided that no extension interferes with the correct function of any
+  \term{conforming program}.
+
+\gentry{conforming processor} \Noun\ \ANSI\ 
+  a \term{conforming implementation}.
+
+\gentry{conforming program} \Noun\
+  a \term{program}, used to emphasize the fact that the \term{program}
+  depends for its correctness only upon documented aspects of \clisp, and
+  can therefore be expected to run correctly in any \term{conforming implementation}.
+
+\gentry{congruent} \Noun\ 
+  conforming to the rules of \term{lambda list} congruency, as detailed in 
+  \secref\GFMethodLambdaListCongruency.
+
+\gentry{cons} \Noun\Verb\ 
+  1. \Noun\ a compound data \term{object} having two components called the
+     \term{car} and the \term{cdr}.
+  2. \Verb\ to create such an \term{object}.
+  3. \Verb\ \Idiomatic\ to create any \term{object}, or to allocate storage.
+
+\gentry{constant} \Noun\
+  1. a \term{constant form}.
+  2. a \term{constant variable}.
+  3. a \term{constant object}.
+  4. a \term{self-evaluating object}.
+
+\gentry{constant form} \Noun\
+  any \term{form}
+   for which \term{evaluation} always \term{yields} the same \term{value},
+   that neither affects nor is affected by the \term{environment}
+     in which it is \term{evaluated} (except that it is permitted to
+     refer to the names of \term{constant variables} 
+     defined in the \term{environment}),
+   and
+   that neither affects nor is affected by the state of any \term{object}
+     except those \term{objects} that are \term{otherwise inaccessible parts}
+     of \term{objects} created by the \term{form} itself.
+  \gexample{A \funref{car} form in which the argument is a
+            \specref{quote} form is a constant form.}
+
+\gentry{constant object} \Noun\
+  an \term{object} that is constrained (\eg by its context in a \term{program}
+  or by the source from which it was obtained) to be \term{immutable}.
+  \gexample{A literal object that has been processed by \funref{compile-file}
+	    is a constant object.}
+
+\gentry{constant variable} \Noun\
+  a \term{variable}, the \term{value} of which can never change;
+  that is, a \term{keyword}\meaning{1} or a \term{named constant}.
+  \gexample{The symbols \t, \nil, \kwd{direction}, and
+            \conref{most-positive-fixnum}\ are constant variables.}
+
+\gentry{constituent} \Noun, \Adjective\
+  1. a. \Noun\ the \term{syntax type} of a \term{character} that is part of a \term{token}.
+         For details, \seesection\ConstituentChars.
+     b. \Adjective\ (of a \term{character})
+        having the \term{constituent}\meaning{1a} \term{syntax type}\meaning{2}.
+     c. \Noun\ a \term{constituent}\meaning{1b} \term{character}.
+  2. \Noun\ (of a \term{composite stream})
+     one of possibly several \term{objects} that collectively comprise
+     the source or sink of that \term{stream}.
+
+\gentry{constituent trait} \Noun\ (of a \term{character})
+  one of several classifications of a \term{constituent} \term{character}
+  in a \term{readtable}.  \Seesection\ConstituentChars.
+
+\gentry{constructed stream} \Noun\ 
+  a \term{stream} whose source or sink is a Lisp \term{object}.
+  Note that since a \term{stream} is another Lisp \term{object},
+  \term{composite streams} are considered \term{constructed streams}.
+  \gexample{A string stream is a constructed stream.}
+
+\gentry{contagion} \Noun\
+  a process whereby operations on \term{objects} of differing \term{types}
+  (\eg arithmetic on mixed \term{types} of \term{numbers}) produce a result
+  whose \term{type} is controlled by the dominance of one \term{argument}'s
+  \term{type} over the \term{types} of the other \term{arguments}.
+  \Seesection\NumericContagionRules.
+
+\gentry{continuable} \Noun\ (of an \term{error})
+  an \term{error} that is \term{correctable} by the \f{continue} restart.
+
+\gentry{control form} \Noun\
+  1. a \term{form} that establishes one or more places to which control
+     can be transferred.
+  2. a \term{form} that transfers control.
+% Moon says he can't think of any form which doesn't match this:
+% 3. a \term{form} from which control can be transferred.
+
+\gentry{copy} \Noun\
+  1. (of a \term{cons} $C$)
+     a \term{fresh} \term{cons} with the \term{same} \term{car} and \term{cdr} as $C$.
+  2. (of a \term{list} $L$)
+     a \term{fresh} \term{list} with the \term{same} \term{elements} as $L$.  
+     (Only the \term{list structure} is \term{fresh};
+      the \term{elements} are the \term{same}.)
+     \Seefun{copy-list}.
+  3. (of an \term{association list} $A$ with \term{elements} $A\sub{i}$)
+     a \term{fresh} \term{list} $B$ with \term{elements} $B\sub{i}$, each of which is
+     \nil\ if $A\sub i$ is \nil, or else a \term{copy} of the \term{cons} $A\sub i$.
+     \Seefun{copy-alist}.
+  4. (of a \term{tree} $T$)
+     a \term{fresh} \term{tree} with the \term{same} \term{leaves} as $T$.
+     \Seefun{copy-tree}.
+  5. (of a \term{random state} $R$)
+     a \term{fresh} \term{random state} that, if used as an argument to
+     to \thefunction{random} would produce the same series of ``random''
+     values as $R$ would produce.
+\issue{DEFSTRUCT-COPIER:ARGUMENT-TYPE}
+  6. (of a \term{structure} $S$)
+     a \term{fresh} \term{structure} that has the same \term{type} as $S$,
+     and that has slot values, each of which is the \term{same} as the 
+     corresponding slot value of $S$.
+\endissue{DEFSTRUCT-COPIER:ARGUMENT-TYPE}
+%% Proposed:
+%   7. (of an \term{array} $A\sub 1$)
+%      a \term{fresh} \term{array} $A\sub 2$
+%      with the same \term{array element type} as $A\sub 1$
+%      and the \term{same} \term{active} \term{elements} as $A\sub 1$.
+%   8. (of a \term{readtable} $R\sub 1$)
+%      a \term{fresh} \term{readtable} $R\sub 2$
+%      that has the same \term{readtable case} as $R\sub 1$
+%      and whose associations between \term{macro characters} 
+%        			        and their \term{reader macro functions}
+%      are distinct from those of $R\sub 1$.
+% 
+  (Note that since the difference between a \term{cons}, a \term{list}, 
+   and a \term{tree} is a matter of ``view'' or ``intention,''  there can
+   be no general-purpose \term{function} which, based solely on the \term{type}
+   of an \term{object}, can determine which of these distinct meanings is 
+   intended.  The distinction rests solely on the basis of the text description
+   within this document.  For example, phrases like ``a \term{copy} of the
+   given \term{list}'' or ``copy of the \term{list} \param{x}'' imply the
+   second definition.)
+
+\gentry{correctable} \Adjective\ (of an \term{error})
+  1. (by a \term{restart} other than \misc{abort} 
+      that has been associated with the \term{error})
+     capable of being corrected by invoking that \term{restart}.
+     \gexample{The function \funref{cerror} signals an error 
+	       that is correctable by the \misc{continue} \term{restart}.}
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+     (Note that correctability is not a property of an
+      \term{error} \term{object}, but rather a property of the 
+      \term{dynamic environment} that is in effect when the
+      \term{error} is \term{signaled}.
+      Specifically, the \term{restart} is ``associated with'' 
+      the \term{error} \term{condition} \term{object}.
+      \Seesection\AssocRestartWithCond.)
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+  2. (when no specific \term{restart} is mentioned)
+     \term{correctable}\meaning{1} by at least one \term{restart}.
+     \gexample{\funref{import} signals a correctable error \oftype{package-error}
+	       if any of the imported symbols has the same name as
+	        some distinct symbol already accessible in the package.}
+
+\gentry{current input base} \Noun\ (in a \term{dynamic environment})
+  the \term{radix} that is \thevalueof{*read-base*} in that \term{environment}, 
+  and that is the default \term{radix} employed by the \term{Lisp reader}
+  and its related \term{functions}.
+
+\gentry{current logical block} \Noun\
+  the context of the innermost lexically enclosing use of \macref{pprint-logical-block}.
+
+\gentry{current output base} \Noun\ (in a \term{dynamic environment})
+  the \term{radix} that is \thevalueof{*print-base*} in that \term{environment}, 
+  and that is the default \term{radix} employed by the \term{Lisp printer}
+  and its related \term{functions}.
+
+\gentry{current package} \Noun\ (in a \term{dynamic environment})
+  the \term{package} that is \thevalueof{*package*} in that \term{environment}, 
+  and that is the default \term{package} employed by the \term{Lisp reader} 
+  and \term{Lisp printer}, and their related \term{functions}.
+
+% Added for consistency with other "current xxx" terms. -kmp 27-Aug-93
+\gentry{current pprint dispatch table} \Noun\ (in a \term{dynamic environment})
+  the \term{pprint dispatch table} that is \thevalueof{*print-pprint-dispatch*}
+  in that \term{environment}, and that is the default \term{pprint dispatch table}
+  employed by the \term{pretty printer}.
+
+\gentry{current random state} \Noun\ (in a \term{dynamic environment})
+  the \term{random state} that is \thevalueof{*random-state*} in that \term{environment}, 
+  and that is the default \term{random state} employed by \funref{random}.
+
+\gentry{current readtable} \Noun\ (in a \term{dynamic environment})
+  the \term{readtable} that is \thevalueof{*readtable*} in that \term{environment}, 
+  and that affects the way in which \term{expressions}\meaning{2} are parsed 
+  into \term{objects} by the \term{Lisp reader}.
+
+\indextab{D}
+
+\gentry{data type} \Noun\ \Traditional\ 
+  a \term{type}.
+
+\gentry{debug I/O} \Noun\ 
+  the \term{bidirectional} \term{stream} 
+  that is the \term{value} of \thevariable{*debug-io*}.
+
+\gentry{debugger} \Noun\
+  a facility that allows the \term{user} to handle a \term{condition} interactively.
+  For example, the \term{debugger} might permit interactive
+  selection of a \term{restart} from among the \term{active} \term{restarts},
+  and it might perform additional \term{implementation-defined} services
+  for the purposes of debugging.
+
+\gentry{declaration} \Noun\
+  a \term{global declaration} or \term{local declaration}.
+
+\gentry{declaration identifier} \Noun\
+  one of the \term{symbols}
+     \declref{declaration},
+     \declref{dynamic-extent},
+     \declref{ftype},
+     \declref{function},
+     \declref{ignore}, 
+     \declref{inline},  
+     \declref{notinline},
+     \declref{optimize}, 
+     \declref{special}, 
+  or \declref{type};
+  or a \term{symbol} which is the \term{name} of a \term{type};
+  or a \term{symbol} which has been \term{declared}
+     to be a \term{declaration identifier} by using a \declref{declaration}
+     \term{declaration}.
+\issue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+% or by using \funref{define-declaration}.
+\endissue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+
+\gentry{declaration specifier} \Noun\
+  an \term{expression} that can appear at top level of a \misc{declare} 
+  expression or a \macref{declaim} form, or as the argument to \funref{proclaim},
+  and which has a \term{car} which is a \term{declaration identifier},
+  and which has a \term{cdr} that is data interpreted according to rules
+  specific to the \term{declaration identifier}.
+
+\gentry{declare} \Verb\ 
+  to \term{establish} a \term{declaration}.
+  \Seemisc{declare}, \macref{declaim}, or \funref{proclaim}.
+
+\gentry{decline} \Verb\ (of a \term{handler})
+  to return normally without having \term{handled} the \term{condition}
+  being \term{signaled}, permitting the signaling process to continue
+  as if the \term{handler} had not been present.
+
+\gentry{decoded time} \Noun\
+  \term{absolute} \term{time}, represented as an ordered series of
+  nine \term{objects} which, taken together, form a description of
+  a point in calendar time, accurate to the nearest second (except
+  that \term{leap seconds} are ignored).
+  \Seesection\DecodedTime.
+
+\gentry{default method} \Noun\
+  a \term{method} having no \term{parameter specializers} other than
+  \theclass{t}.  Such a \term{method} is always an \term{applicable method}
+  but might be \term{shadowed}\meaning{2} by a more specific \term{method}.
+
+\gentry{defaulted initialization argument list} \Noun\
+  a \term{list} of alternating initialization argument \term{names} and
+  \term{values} in which unsupplied initialization arguments are
+  defaulted, used in the protocol for initializing and reinitializing 
+  \term{instances} of \term{classes}.
+
+% This is new per Barrett #3 (first public review). -kmp 12-May-93
+\gentry{define-method-combination arguments lambda list} \Noun\
+  a \term{lambda list} used by the \kwd{arguments} option 
+  to \macref{define-method-combination}.
+  \Seesection\DefMethCombArgsLambdaLists.
+
+% This is new.  --sjl 5 Mar 92
+\gentry{define-modify-macro lambda list} \Noun\
+  a \term{lambda list} used by \macref{define-modify-macro}.
+  \Seesection\DefineModifyMacroLambdaLists.
+
+\gentry{defined name} \Noun\
+  a \term{symbol} the meaning of which is defined by \clisp.
+
+\gentry{defining form} \Noun\
+  a \term{form} that has the side-effect of \term{establishing} a definition.
+  \gexample{\macref{defun} and \macref{defparameter} are defining forms.}
+
+\gentry{defsetf lambda list} \Noun\
+  a \term{lambda list} that is like an \term{ordinary lambda list} 
+  except that it does not permit \keyref{aux}
+     and that it permits use of \keyref{environment}.
+  \Seesection\DefsetfLambdaLists.
+
+\issue{DEFTYPE-KEY:ALLOW}
+\issue{DEFTYPE-DESTRUCTURING:YES}
+\gentry{deftype lambda list} \Noun\
+  a \term{lambda list} that is like a \term{macro lambda list}
+  except that the default \term{value} for unsupplied \term{optional parameters}
+  and \term{keyword parameters} is the \term{symbol} \misc{*} (rather than \nil).
+  \Seesection\DeftypeLambdaLists.
+\endissue{DEFTYPE-DESTRUCTURING:YES}
+\endissue{DEFTYPE-KEY:ALLOW}
+
+\gentry{denormalized} \Adjective, \ANSI, \IEEE\ (of a \term{float})
+  conforming to the description of ``denormalized'' as described by 
+  {\IEEEFloatingPoint}.
+  For example, in an \term{implementation} where the minimum possible exponent 
+  was \f{-7} but where \f{0.001} was a valid mantissa, the number \f{1.0e-10}
+  might be representable as \f{0.001e-7} internally even if the \term{normalized}
+  representation would call for it to be represented instead as \f{1.0e-10} 
+  or \f{0.1e-9}.  By their nature, \term{denormalized} \term{floats} generally
+  have less precision than \term{normalized} \term{floats}.
+
+\gentry{derived type} \Noun\
+  a \term{type specifier} which is defined in terms of an expansion into another
+  \term{type specifier}.  \macref{deftype} defines \term{derived types}, 
+  and there may be other \term{implementation-defined} \term{operators}
+  which do so as well.
+
+\gentry{derived type specifier} \Noun\
+  a \term{type specifier} for a \term{derived type}.
+
+\gentry{designator} \Noun\ 
+  an \term{object} that denotes another \term{object}.
+  In the dictionary entry for an \term{operator}
+  if a \term{parameter} is described as a \term{designator} for a \term{type},
+  the description of the \term{operator} is written in a way
+  that assumes that appropriate coercion to that \term{type} has already occurred;
+  that is, that the \term{parameter} is already of the denoted \term{type}.
+  For more detailed information, \seesection\Designators.
+
+\gentry{destructive} \Adjective\ (of an \term{operator})
+  capable of modifying some program-visible aspect of one or more
+  \term{objects} that are either explicit \term{arguments} to the
+  \term{operator} or that can be obtained directly or indirectly 
+  from the \term{global environment} by the \term{operator}.
+
+% This is new.  --sjl 5 Mar 92
+\gentry{destructuring lambda list} \Noun\
+  an \term{extended lambda list} used in \macref{destructuring-bind} and
+  nested within \term{macro lambda lists}.  
+  \Seesection\DestructuringLambdaLists.
+
+\gentry{different} \Adjective\ 
+  not the \term{same}
+  \gexample{The strings \f{"FOO"} and \f{"foo"} are different under
+	    \funref{equal} but not under \funref{equalp}.}
+
+\gentry{digit} \Noun\ (in a \term{radix})
+  a \term{character} that is among the possible digits (\f{0} to \f{9},
+  \f{A} to \f{Z}, and \f{a} to \f{z}) and that is defined to have an 
+  associated numeric weight as a digit in that \term{radix}.
+  \Seesection\Digits.
+
+\gentry{dimension} \Noun\
+  1. a non-negative \term{integer} indicating the number of
+     \term{objects} an \term{array} can hold along one axis.
+     If the \term{array} is a \term{vector} with a \term{fill pointer},
+     the \term{fill pointer} is ignored.
+     \gexample{The second dimension of that array is 7.}
+  2. an axis of an array.
+     \gexample{This array has six dimensions.}
+ 
+\gentry{direct instance} \Noun\ (of a \term{class} $C$)
+  an \term{object} whose \term{class} is $C$ itself,
+  rather than some \term{subclass} of $C$.
+  \gexample{The function \funref{make-instance} always returns a 
+  	    direct instance of the class which is (or is named by)
+	    its first argument.}
+
+\gentry{direct subclass} \Noun\ (of a \term{class} $C\sub{1}$)
+  a \term{class} $C\sub{2}$,
+  such that $C\sub{1}$ is a \term{direct superclass} of $C\sub{2}$.
+
+\gentry{direct superclass} \Noun\ (of a \term{class} $C\sub{1}$)
+  a \term{class} $C\sub{2}$ which was explicitly designated as 
+  a \term{superclass} of $C\sub{1}$ in the definition of $C\sub{1}$.
+
+\gentry{disestablish} \TransitiveVerb\ 
+  to withdraw the \term{establishment} of 
+      an \term{object},
+      a  \term{binding},
+      an \term{exit point}, 
+      a  \term{tag},
+      a  \term{handler},
+      a  \term{restart}, 
+   or an \term{environment}.
+ 
+\gentry{disjoint} \Noun\ (of \term{types})
+  having no \term{elements} in common.
+
+\gentry{dispatching macro character} \Noun\ 
+  a \term{macro character} that has an associated table that specifies 
+  the \term{function} to be called for each \term{character} that is
+  seen following the \term{dispatching macro character}.
+  \Seefun{make-dispatch-macro-character}.
+
+\gentry{displaced array} \Noun\
+%Alternatively (from an old definition of make-array):
+% ...an indirect or shared \term{array} that shares its contents...
+  an \term{array} which has no storage of its own, but which is instead
+  indirected to the storage of another \term{array}, called its
+  \term{target}, at a specified offset, in such a way that any attempt
+  to \term{access} the \term{displaced array} implicitly references the 
+  \term{target} \term{array}.
+
+\gentry{distinct} \Adjective\
+  not \term{identical}.
+
+\gentry{documentation string} \Noun\ (in a defining \term{form}) 
+  A \term{literal} \term{string} which because of the context in which
+  it appears (rather than because of some intrinsically observable 
+  aspect of the \term{string}) is taken as documentation.
+  In some cases, the \term{documentation string} is saved in such a
+  way that it can later be obtained by supplying either an \term{object}, 
+  or by supplying a \term{name} and a ``kind'' to \thefunction{documentation}.
+  \gexample{The body of code in a \macref{defmacro} form can be preceded 
+	    by a documentation string of kind \misc{function}.}
+
+\gentry{dot} \Noun\
+  the \term{standard character} that is variously called
+     ``full stop,''
+     ``period,''
+  or ``dot'' (\f{.}).
+  \Seefigure\StdCharsThree.
+
+%Maybe separate into adjective so we can say "(possibly dotted) list" etc. -kmp 7-May-91
+\gentry{dotted list} \Noun\
+  a \term{list} which has a terminating \term{atom} that is not \nil.
+  (An \term{atom} by itself is not a \term{dotted list}, however.)
+
+\gentry{dotted pair} \Noun\
+  1. a \term{cons} whose \term{cdr} is a \term{non-list}.
+  2. any \term{cons}, used to emphasize the use of the \term{cons}
+     as a symmetric data pair.
+ 
+\gentry{double float} \Noun\
+  an \term{object} \oftype{double-float}.
+
+\gentry{double-quote} \Noun\
+  the \term{standard character} that is variously called
+      ``quotation mark''
+   or ``double quote'' (\f{"}).
+  \Seefigure\StdCharsThree.
+
+\gentry{dynamic binding} \Noun\ 
+  a \term{binding} in a \term{dynamic environment}.
+
+\gentry{dynamic environment} \Noun\
+  that part of an \term{environment} that contains \term{bindings} 
+  with \term{dynamic extent}.  A \term{dynamic environment} contains,
+%!!! Moon: This phrase ["among other things"] always scares me. Is it necessary?
+  among other things:
+    \term{exit points} established by \specref{unwind-protect},
+  and 
+    \term{bindings} of
+      \term{dynamic variables},
+      \term{exit points} established by \specref{catch},
+      \term{condition handlers},
+    and
+      \term{restarts}.  
+ 
+%%!!! The CLIM folks want to be able to say:
+%%      ``the parameter x has dynamic extent''
+%%    and have it imply that:
+%%      (a) ``the implementation of the indicated function 
+%%            may declare the argument to be dynamic extent''
+%%    and
+%%      (b) ``it is permissible to pass an object which was 
+%%            the value of a variable which had been declared dynamic extent''
+%%    -kmp 30-Jan-92
+\gentry{dynamic extent} \Noun\
+  an \term{extent} whose duration is bounded by points of 
+  \term{establishment} and \term{disestablishment} within the execution
+  of a particular \term{form}.  \Seeterm{indefinite extent}.
+  \gexample{Dynamic variable bindings have dynamic extent.}
+ 
+\gentry{dynamic scope} \Noun\
+  \term{indefinite scope} along with \term{dynamic extent}.
+ 
+\gentry{dynamic variable} \Noun\
+  a \term{variable} the \term{binding} for which is in the \term{dynamic environment}.
+  \Seemisc{special}.
+
+\indextab{E}
+
+\gentry{echo stream} \Noun\
+  a \term{stream} \oftype{echo-stream}.
+
+\gentry{effective method} \Noun\
+  the combination of \term{applicable methods} that are executed
+  when a \term{generic function} is invoked with a particular sequence
+  of \term{arguments}.
+ 
+\gentry{element} \Noun\
+  1. (of a \term{list}) 
+     an \term{object} that is the \term{car} of one of the \term{conses}
+     that comprise the \term{list}.
+  2. (of an \term{array})
+     an \term{object} that is stored in the \term{array}.
+  3. (of a \term{sequence})
+     an \term{object} that is an \term{element} of the \term{list} or \term{array}
+     that is the \term{sequence}.
+  4. (of a \term{type})
+     an \term{object} that is a member of the set of \term{objects}
+     designated by the \term{type}.
+  5. (of an \term{input} \term{stream})
+     a \term{character} or \term{number} (as appropriate to the
+     \term{element type} of the \term{stream})
+     that is among the ordered series of \term{objects} that can be 
+     read from the \term{stream} (using \funref{read-char} or \funref{read-byte},
+     as appropriate to the \term{stream}).
+  6. (of an \term{output} \term{stream})
+     a \term{character} or \term{number} (as appropriate to the
+     \term{element type} of the \term{stream})
+     that is among the ordered series of \term{objects} that has been
+     or will be written to the \term{stream} (using \funref{write-char} 
+     or \funref{write-byte}, as appropriate to the \term{stream}).
+  7. (of a \term{class}) a \term{generalized instance} of the \term{class}.
+
+\gentry{element type} \Noun\ 
+  1. (of an \term{array}) the \term{array element type} of the \term{array}.
+  2. (of a \term{stream}) the \term{stream element type} of the \term{stream}.
+
+\gentry{em} \Noun\ \Traditional\ 
+  a context-dependent unit of measure commonly used in typesetting,
+  equal to the displayed width of of a letter ``M'' in the current font.
+  (The letter ``M'' is traditionally chosen because it is typically 
+   represented by the widest \term{glyph} in the font, and other characters' 
+   widths are typically fractions of an \term{em}.  In implementations providing 
+   non-Roman characters with wider characters than ``M,'' it is permissible 
+   for another character to be the \term{implementation-defined} reference character
+   for this measure, and for ``M'' to be only a fraction of an \term{em}
+   wide.)  
+  In a fixed width font, a line with \i{n} characters is \i{n} 
+  \term{ems} wide; in a variable width font, \i{n} \term{ems} is the
+  expected upper bound on the width of such a line.
+
+\gentry{empty list} \Noun\
+  the \term{list} containing no \term{elements}. \Seeterm{()}.
+ 
+\gentry{empty type} \Noun\
+  the \term{type} that contains no \term{elements}, and that is
+  a \term{subtype} of all \term{types} (including itself).
+  \Seeterm{nil}.
+
+\gentry{end of file} \Noun\
+  1. the point in an \term{input} \term{stream} beyond which there is
+     no further data.
+     Whether or not there is such a point on an \term{interactive stream} 
+     is \term{implementation-defined}.
+  2. a \term{situation} that occurs upon an attempt to obtain data from an
+     \term{input stream} that is at the \term{end of file}\meaning{1}.
+
+%% This might be handy sometime...
+%
+% \gentry{end of line} \Noun\
+%   the termination of a line of text,
+%   whether by a \term{newline} or an \term{end of file}.
+
+\gentry{environment} \Noun\
+  1. a set of \term{bindings}. \Seesection\IntroToEnvs.
+  2. an \term{environment object}.
+     \gexample{\funref{macroexpand} takes an optional environment argument.}
+
+\gentry{environment object} \Noun\
+  an \term{object} representing a set of \term{lexical bindings},
+     used in the processing of a \term{form} to provide meanings for
+     \term{names} within that \term{form}.
+     \gexample{\funref{macroexpand} takes an optional environment argument.}
+     (The \term{object} \nil\ when used as an \term{environment object}
+      denotes the \term{null lexical environment};
+      the \term{values} of \term{environment parameters} 
+      to \term{macro functions} are \term{objects}
+      of \term{implementation-dependent} nature which represent the 
+      \term{environment}\meaning{1} in which the corresponding \term{macro form}
+      is to be expanded.)
+     \Seesection\EnvObjs.
+
+\gentry{environment parameter} \Noun\
+  A \term{parameter} in a \term{defining form} $f$ for which there is no corresponding
+  \term{argument}; instead, this \term{parameter} receives as its value an
+  \term{environment} \term{object} which corresponds to the
+  \term{lexical environment} in which the \term{defining form} $f$ appeared.
+
+%!!! Moon: I disagree with 1 and 2, "undefined consequences" /= "defined to signal an error"
+\gentry{error} \Noun\
+  1. (only in the phrase ``is an error'')
+     a \term{situation} in which the semantics of a program are not specified, 
+     and in which the consequences are undefined.
+  2. a \term{condition} which represents an \term{error} \term{situation}.
+     \Seesection\ErrorTerms.
+  3. an \term{object} \oftype{error}.
+
+\gentry{error output} \Noun\ 
+  the \term{output} \term{stream} which is the \term{value} of the \term{dynamic variable}
+  \varref{*error-output*}.
+
+\gentry{escape} \Noun, \Adjective\
+  1. \Noun\ a \term{single escape} or a \term{multiple escape}.
+  2. \Adjective\ \term{single escape} or \term{multiple escape}.
+
+%!!!! RPG doesn't think this definition is really adequate, 
+%     especially for declarations.
+\gentry{establish} \TransitiveVerb\ 
+  to build or bring into being 
+      a  \term{binding},
+      a  \term{declaration},
+      an \term{exit point},
+      a  \term{tag},
+      a  \term{handler}, 
+      a \term{restart},
+   or an \term{environment}. 
+  \gexample{\specref{let} establishes lexical bindings.}
+
+%% Experimental definition not installed. -kmp 26-Jan-92
+% \gentry{establish} \TransitiveVerb\ 
+%   1. (an \term{environment}) to build or bring into being.
+%   2. (a  \term{binding},
+%       a  \term{declaration},
+%       an \term{exit point},
+%       a  \term{tag},
+%       a  \term{handler}, 
+%       a \term{restart})
+%      to \term{establish}\meaning{1} an augmented \term{environment}
+%      in which that entity is \term{active}, applicable, present, or visible.
+%   \gexample{\specref{let} establishes lexical bindings.}
+
+\gentry{evaluate} \TransitiveVerb\ (a \term{form} or an \term{implicit progn})
+  to \term{execute} the \term{code} represented by the \term{form}
+  (or the series of \term{forms} making up the \term{implicit progn})
+  by applying the rules of \term{evaluation},
+  returning zero or more values.
+
+\gentry{evaluation} \Noun\
+  a model whereby \term{forms} are \term{executed}, returning zero or more values.
+  Such execution might be implemented directly in one step by an interpreter
+  or in two steps by first \term{compiling} the \term{form} and then
+  \term{executing} the \term{compiled} \term{code}; this choice is 
+  dependent both on context and the nature of the \term{implementation}, 
+  but in any case is not in general detectable by any program.  The evaluation
+  model is designed in such a way that a \term{conforming implementation} 
+  might legitimately have only a compiler and no interpreter, or vice versa.
+  \Seesection\EvaluationModel.
+ 
+\gentry{evaluation environment} \Noun\
+  a \term{run-time environment} in which macro expanders 
+  and code specified by \specref{eval-when} to be evaluated
+  are evaluated.  All evaluations initiated by the \term{compiler} 
+  take place in the \term{evaluation environment}.
+
+\gentry{execute} \TransitiveVerb\ \Traditional\ (\term{code})
+  to perform the imperative actions represented by the \term{code}.
+
+\gentry{execution time} \Noun\
+  the duration of time that \term{compiled code} is being \term{executed}.
+
+\gentry{exhaustive partition} \Noun\ (of a \term{type})
+  a set of \term{pairwise} \term{disjoint} \term{types} that form an 
+  \term{exhaustive union}.
+
+\gentry{exhaustive union} \Noun\ (of a \term{type})
+  a set of \term{subtypes} of the \term{type},
+  whose union contains all \term{elements} of that \term{type}.
+ 
+\gentry{exit point} \Noun\
+  a point in a \term{control form}
+% Moon would remove this first phrase, but I think the phrases refer 
+% respectively to BLOCK, UNWIND-PROTECT, and TAGBODY. -kmp 14-Nov-91
+       from which (\eg \specref{block}),
+       through which (\eg \specref{unwind-protect}),
+    or to which (\eg \specref{tagbody})
+  control and possibly \term{values} can be transferred both actively by using 
+  another \term{control form} and passively through the normal control and
+  data flow of \term{evaluation}.
+  \gexample{\specref{catch} and \specref{block} establish bindings for
+            exit points to which \specref{throw} and \specref{return-from},
+	    respectively, can transfer control and values;
+	    \specref{tagbody} establishes a binding for an exit point
+	    with lexical extent to which \specref{go} can transfer control;
+	    and \specref{unwind-protect} establishes an exit point 
+	    through which control might be transferred by 
+	    operators such as \specref{throw}, \specref{return-from},
+            and \specref{go}.}
+
+\gentry{explicit return} \Noun\ 
+  the act of transferring control (and possibly \term{values}) 
+  to a \term{block} by using \specref{return-from} (or \macref{return}).
+
+\gentry{explicit use} \Noun\ (of a \term{variable} $V$ in a \term{form} $F$)
+  a reference to $V$ that is directly apparent in the normal semantics of $F$;
+  \ie that does not expose any undocumented details of the
+      \term{macro expansion} of the \term{form} itself.
+  References to $V$ exposed by expanding \term{subforms} of $F$ are, however,
+  considered to be \term{explicit uses} of $V$.
+
+%Barmar prefers "printed representation of" to "textual notation for"
+\gentry{exponent marker} \Noun\
+  a character that is used in the textual notation for a \term{float}
+  to separate the mantissa from the exponent.
+  The characters defined as \term{exponent markers} in the \term{standard readtable}
+  are shown in \thenextfigure.
+  For more information, \seesection\CharacterSyntax.
+  \gexample{The exponent marker `d' in `3.0d7' indicates
+	    that this number is to be represented as a double float.}
+
+\tablefigtwo{Exponent Markers}{Marker}{Meaning}{
+ \f{D} or \f{d} & \typeref{double-float}                                     \cr
+ \f{E} or \f{e} & \typeref{float} (see \varref{*read-default-float-format*}) \cr
+ \f{F} or \f{f} & \typeref{single-float}                                     \cr
+ \f{L} or \f{l} & \typeref{long-float}                                       \cr
+ \f{S} or \f{s} & \typeref{short-float}                                      \cr
+}
+
+\gentry{export} \TransitiveVerb\ (a \term{symbol} in a \term{package})
+  to add the \term{symbol} to the list of \term{external symbols} of the
+  \term{package}.
+
+\gentry{exported} \Adjective\ (of a \term{symbol} in a \term{package})
+  being an \term{external symbol} of the \term{package}.
+
+\gentry{expressed adjustability} \Noun\ (of an \term{array})
+  a \term{generalized boolean} that is conceptually (but not necessarily actually)
+  associated with the \term{array}, representing whether the \term{array}
+  is \term{expressly adjustable}.
+  \SeetermAlso{actual adjustability}.
+
+\gentry{expressed array element type} \Noun\ (of an \term{array})
+  the \term{type} which is the \term{array element type}
+  implied by a \term{type declaration} for the \term{array}, 
+  or which is the requested \term{array element type} at its time 
+  of creation, prior to any selection of an \term{upgraded array element type}.
+  (\clisp\ does not provide a way of detecting this \term{type}
+   directly at run time, but an \term{implementation} is permitted 
+   to make assumptions about the \term{array}'s contents and
+   the operations which may be performed on the \term{array} when
+   this \term{type} is noted during code analysis, even if those 
+   assumptions would not be valid in general for the
+   \term{upgraded array element type} of the
+   \term{expressed array element type}.)
+% KMP->Barmar:
+%  You remarked that you think you can rely on array-element-type and 
+%  upgraded-xxx-type. This is intended to permit a compiler optimizer like:
+%      (frob (make-array n :element-type '(unsigned-byte 13)))
+%  to turn into
+%      (si:frob-internal-signed-byte-13 
+%        (make-array n :element-type '(unsigned-byte 13)))
+%  even though the implementation knows that (unsigned-byte 16) will really get
+%  allocated, let's say.  Moreover, the compiler should be permitted to warn about:
+%      (defun foo (n) 
+%        (let ((x (make-array n :element-type '(unsigned-byte 2))))
+% 	 (setf (aref x 0) 17.) ...))
+%  It generally will not warn about:
+%      (defun foo (n)
+%        (bar (make-array n :element-type '(unsigned-byte 2))))
+%      (defun bar (a)
+%        (setf (aref x 0) 17.) ...)
+%  I agree that it should never warn about:
+%      (defun foo (n) 
+%        (let ((x (make-array n :element-type '(unsigned-byte 2))))
+% 	 (when (type-equivalent-p (array-element-type x) 'fixnum)
+% 	    (setf (aref x 0) 17.) ...)))
+%  because this is portably guarded even if it behaves differently on the
+%  different implementations to which it is ported.
+% 
+%  This makes it tough to do the optimization I'm referring to, but I don't
+%  think that implementations which really properly check that the path is
+%  clear between the allocation and the reference should be forbidden from
+%  flagging an unconditional non-portability.
+%
+% Barmar: 
+%  You apparently understand the point I was making.  If you can come up
+%  with a concise way to phrase it in the definition of "declared XXX
+%  type", that's all I was hoping for.  If not, I don't think this is a
+%  critical issue.
+
+\gentry{expressed complex part type} \Noun\ (of a \term{complex})
+  the \term{type} which is implied as the \term{complex part type}
+  by a \term{type declaration} for the \term{complex}, 
+  or which is the requested \term{complex part type} at its time of
+  creation, prior to any selection of an \term{upgraded complex part type}.
+  (\clisp\ does not provide a way of detecting this \term{type}
+   directly at run time, but an \term{implementation} is permitted 
+   to make assumptions about the operations which may be performed on
+   the \term{complex} when this \term{type} is noted during code
+   analysis, even if those assumptions would not be valid in general for 
+   the \term{upgraded complex part type} of the
+   \term{expressed complex part type}.)
+
+\gentry{expression} \Noun\
+  1. an \term{object}, often used to emphasize the use 
+     of the \term{object} to encode or represent information in a specialized
+     format, such as program text.
+     \gexample{The second expression in a \specref{let} form is a list
+   	       of bindings.}
+  2. the textual notation used to notate an \term{object} in a source file.
+     \gexample{The expression \f{'sample} is equivalent to \f{(quote sample)}.}
+
+\gentry{expressly adjustable} \Adjective\ (of an \term{array})
+  being \term{actually adjustable} by virtue of an explicit request for this
+  characteristic having been made at the time of its creation.
+  All \term{arrays} that are \term{expressly adjustable} 
+  are \term{actually adjustable},
+  but not necessarily vice versa.
+
+\gentry{extended character} \Noun\
+  a \term{character} 
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+  \oftype{extended-char}:
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+  a \term{character} that is not a \term{base character}.
+
+\gentry{extended function designator} \Noun\
+  a \term{designator} for a \term{function}; that is,
+  an \term{object} that denotes a \term{function}
+  and that is one of:
+      a \term{function name} (denoting the \term{function} it names
+                              in the \term{global environment}),
+   or a \term{function} (denoting itself).
+  The consequences are undefined if 
+  a \term{function name} is used as an 
+  \term{extended function designator} but
+  it does not have a global definition as a \term{function},
+  or if it is a \term{symbol} 
+     that has a global definition as a \term{macro} or a \term{special form}.
+  \SeetermAlso{function designator}.
+
+\gentry{extended lambda list} \Noun\
+  a list resembling an \term{ordinary lambda list} in form and purpose, but 
+  offering additional syntax or functionality not available in an
+  \term{ordinary lambda list}.
+  \gexample{\macref{defmacro} uses extended lambda lists.}
+ 
+\gentry{extension} \Noun\
+  a facility in an \term{implementation} of \clisp\ 
+  that is not specified by this standard.
+
+\gentry{extent} \Noun\
+  the interval of time during which a \term{reference} to 
+      an \term{object},
+      a  \term{binding},
+      an \term{exit point},
+      a  \term{tag},
+      a  \term{handler},
+      a  \term{restart},
+   or an \term{environment} is defined.
+ 
+\gentry{external file format} \Noun\
+  an \term{object} of \term{implementation-dependent} nature which determines
+  one of possibly several \term{implementation-dependent} ways in which
+  \term{characters} are encoded externally in a \term{character} \term{file}.
+
+\gentry{external file format designator} \Noun\
+  a \term{designator} for an \term{external file format}; that is,
+  an \term{object} that denotes an \term{external file format}
+  and that is one of:
+      the \term{symbol} \kwd{default} 
+         (denoting an \term{implementation-dependent} default 
+          \term{external file format} that can accomodate at least
+          the \term{base characters}),
+      some other \term{object} defined by the \term{implementation} to be
+      an \term{external file format designator}
+         (denoting an \term{implementation-defined} \term{external file format}),
+   or some other \term{object} defined by the \term{implementation} to be
+      an \term{external file format} 
+         (denoting itself).
+
+\gentry{external symbol} \Noun\ (of a \term{package})
+  a \term{symbol} that is part of the `external interface' to the \term{package}
+  and that are \term{inherited}\meaning{3} by any other \term{package}
+   that \term{uses} the \term{package}.
+  When using the \term{Lisp reader}, 
+  if a \term{package prefix} is used,
+  the \term{name} of an \term{external symbol} is separated
+    from the \term{package} \term{name} by a single \term{package marker}
+  while
+  the \term{name} of an \term{internal symbol} is separated
+    from the \term{package} \term{name} by a double \term{package marker};
+  \seesection\SymbolTokens.
+
+\gentry{externalizable object} \Noun\
+  an \term{object} that can be used as a \term{literal} \term{object} 
+  in \term{code} to be processed by the \term{file compiler}.  
+
+\indextab{F}
+ 
+\gentry{false} \Noun\
+  the \term{symbol} \nil,
+  used to represent the failure of a \term{predicate} test.
+
+\gentry{fbound} \pronounced{\Stress{ef}\stress{ba\.und}} \Adjective\ 
+							 (of a \term{function name})
+  \term{bound} in the \term{function} \term{namespace}.
+  (The \term{names} of \term{macros} and \term{special operators} are \term{fbound},
+   but the nature and \term{type} of the \term{object} which is their \term{value}
+   is \term{implementation-dependent}.
+\issue{SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES}
+   Further, defining a \term{setf expander} \param{F} does not cause the \term{setf function}
+   \f{(setf \param{F})} to become defined; as such, if there is a such a definition
+   of a \term{setf expander} \param{F}, the \term{function} \f{(setf \param{F})}
+   can be \term{fbound} if and only if, by design or coincidence, a
+   function binding for \f{(setf \param{F})} has been independently established.)
+\endissue{SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES}
+  \Seefuns{fboundp} and \funref{symbol-function}.
+
+\gentry{feature} \Noun\
+  1. an aspect or attribute 
+        of \clisp, 
+        of the \term{implementation},
+     or of the \term{environment}.
+  2. a \term{symbol} that names a \term{feature}\meaning{1}.
+  \Seesection\Features.
+  \gexample{The \kwd{ansi-cl} feature is present in all conforming implementations.}
+
+\gentry{feature expression} \Noun\
+  A boolean combination of \term{features} used by the \f{\#+} and \f{\#-} 
+  \term{reader macros} in order to direct conditional \term{reading} of
+  \term{expressions} by the \term{Lisp reader}.
+  \Seesection\FeatureExpressions.
+
+\gentry{features list} \Noun\
+  the \term{list} that is \thevalueof{*features*}.
+
+\gentry{file} \Noun\
+  a named entry in a \term{file system},
+  having an \term{implementation-defined} nature.
+
+\gentry{file compiler} \Noun\
+  any \term{compiler} which \term{compiles} \term{source code} contained in a \term{file},
+  producing a \term{compiled file} as output.  The \funref{compile-file} 
+  function is the only interface to such a \term{compiler} provided by \clisp,
+  but there might be other, \term{implementation-defined} mechanisms for 
+  invoking the \term{file compiler}.
+
+\gentry{file position} \Noun\ (in a \term{stream})
+  a non-negative \term{integer} that represents a position in the \term{stream}.
+  Not all \term{streams} are able to represent the notion of \term{file position};
+  in the description of any \term{operator} which manipulates \term{file positions}, 
+  the behavior for \term{streams} that don't have this notion must be explicitly stated.
+  For \term{binary} \term{streams}, the \term{file position} represents the number 
+  of preceding \term{bytes} in the \term{stream}.
+  For \term{character} \term{streams}, the constraint is more relaxed: 
+  \term{file positions} must increase monotonically, the amount of the increase
+  between \term{file positions} corresponding to any two successive characters
+  in the \term{stream} is \term{implementation-dependent}.
+
+\gentry{file position designator} \Noun\ (in a \term{stream})
+  a \term{designator} for a \term{file position} in that \term{stream}; that is,
+      the symbol \kwd{start}  
+        (denoting \f{0}, the first \term{file position} in that \term{stream}),
+      the symbol \kwd{end}
+	(denoting the last \term{file position} in that \term{stream};
+	 \ie the position following the last \term{element} of the \term{stream}),
+   or a \term{file position} (denoting itself).
+
+\gentry{file stream} \Noun\
+  an \term{object} \oftype{file-stream}.
+
+\gentry{file system} \Noun\
+  a facility which permits aggregations of data to be stored in named
+  \term{files} on some medium that is external to the \term{Lisp image}
+  and that therefore persists from \term{session} to \term{session}.
+
+\issue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+\gentry{filename} \Noun\
+%% This term applies some places to logical pathnames and doesn't work very well
+%% for them, so I tried to make it more abstract. -kmp 28-Aug-93
+%   an \term{implementation-dependent} handle, not necessarily ever directly
+%   represented as an \term{object}, that can be used to refer to a \term{file}
+%   in a \term{file system}.  \term{Physical pathnames} and 
+%   \term{physical pathname} \term{namestrings} are two kinds of \term{objects} 
+%   that substitute for \term{filenames} in \clisp.  The specific relationship 
+%   between \term{filenames} and \term{physical pathnames}, and between
+%   \term{filenames} and \term{namestrings}, is \term{implementation-defined}.
+  a handle, not necessarily ever directly represented as an \term{object},
+  that can be used to refer to a \term{file} in a \term{file system}.
+  \term{Pathnames} and \term{namestrings} are two kinds of \term{objects} 
+  that substitute for \term{filenames} in \clisp.  
+\endissue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+
+\gentry{fill pointer} \Noun\ (of a \term{vector})
+  an \term{integer} associated with a \term{vector} that represents the
+  index above which no \term{elements} are \term{active}.
+  (A \term{fill pointer} is a non-negative \term{integer} no
+   larger than the total number of \term{elements} in the \term{vector}.
+   Not all \term{vectors} have \term{fill pointers}.)
+ 
+\gentry{finite} \Adjective\ (of a \term{type})
+  having a finite number of \term{elements}.
+  \gexample{The type specifier \f{(integer 0 5)} denotes a finite type,
+	    but the type specifiers \typeref{integer} and \f{(integer 0)} do not.}
+
+\gentry{fixnum} \Noun\ 
+  an \term{integer} \oftype{fixnum}.
+
+\gentry{float} \Noun\
+  an \term{object} \oftype{float}.
+
+\issue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+\gentry{for-value} \Adjective\ (of a \term{reference} to a \term{binding})
+  being a \term{reference} that \term{reads}\meaning{1}
+  the \term{value} of the \term{binding}.
+\endissue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+
+\gentry{form} \Noun\
+  1. any \term{object} meant to be \term{evaluated}.
+  2.    a \term{symbol},
+        a \term{compound form},
+     or a \term{self-evaluating object}.
+  3. (for an \term{operator}, as in ``\metavar{operator} \term{form}'')
+     a \term{compound form} having that \term{operator} as its first element.
+     \gexample{A \specref{quote} form is a constant form.}
+ 
+\gentry{formal argument} \Noun\ \Traditional\ 
+  a \term{parameter}.
+
+\gentry{formal parameter} \Noun\ \Traditional\ 
+  a \term{parameter}.
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\gentry{format} \TransitiveVerb\ (a \term{format control} and \term{format arguments})
+  to perform output as if by \funref{format},
+  using the \term{format string} and \term{format arguments}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\gentry{format argument} \Noun\
+  an \term{object} which is used as data by functions such as \funref{format}
+  which interpret \term{format controls}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\gentry{format control} \Noun\
+     a \term{format string},
+  or a \term{function} that obeys the \term{argument} conventions
+     for a \term{function} returned by \themacro{formatter}.
+  \Seesection\CompilingFormatStrings.
+
+\gentry{format directive} \Noun\
+  1. a sequence of \term{characters} in a \term{format string}
+     which is introduced by a \term{tilde}, and which is specially 
+     interpreted by \term{code} which processes \term{format strings}
+     to mean that some special operation should be performed, possibly
+     involving data supplied by the \term{format arguments} that 
+     accompanied the \term{format string}.  \Seefun{format}.
+     \gexample{In \f{"~D base 10 = ~8R"}, the character
+     	       sequences `\f{~D}' and `\f{~8R}' are format directives.}
+  2. the conceptual category of all \term{format directives}\meaning{1}
+     which use the same dispatch character.
+     \gexample{Both \f{"~3d"} and \f{"~3,'0D"} are valid uses of the
+	       `\f{~D}' format directive.}
+
+\gentry{format string} \Noun\
+  a \term{string} which can contain both ordinary text and \term{format directives},
+  and which is used in conjunction with \term{format arguments} to describe how 
+  text output should be formatted by certain functions, such as \funref{format}.
+
+\gentry{free declaration} \Noun\
+  a declaration that is not a \term{bound declaration}.
+  \Seemisc{declare}.
+ 
+\gentry{fresh} \Adjective\ 
+  1. (of an \term{object} \term{yielded} by a \term{function})
+     having been newly-allocated by that \term{function}.
+     (The caller of a \term{function} that returns a \term{fresh} \term{object}
+      may freely modify the \term{object} without fear that such modification will
+      compromise the future correct behavior of that \term{function}.)
+  2. (of a \term{binding} for a \term{name})
+     newly-allocated; not shared with other \term{bindings} for that \term{name}.
+
+\gentry{freshline} \Noun\
+  a conceptual operation on a \term{stream}, implemented by \thefunction{fresh-line}
+  and by the \term{format directive} \f{~\&}, which advances the display position
+  to the beginning of the next line (as if a \term{newline} had been typed, or 
+  \thefunction{terpri} had been called)
+  unless the \term{stream} is already known to be positioned at the beginning of a line.
+  Unlike \term{newline}, \term{freshline} is not a \term{character}.
+
+\gentry{funbound} \pronounced{\Stress{ef}unba\.und} \Noun\ (of a \term{function name})
+  not \term{fbound}.
+
+\gentry{function} \Noun\
+  %% 6.2.2 26
+  1. an \term{object} representing code,
+     which can be \term{called} with zero or more \term{arguments},
+     and which produces zero or more \term{values}.
+  2. an \term{object} \oftype{function}.
+
+\gentry{function block name} \Noun\ (of a \term{function name})
+  The \term{symbol} that would be used as the name of an \term{implicit block}
+  which surrounds the body of a \term{function} having that \term{function name}.
+  If the \term{function name} is a \term{symbol}, its \term{function block name} is
+  the \term{function name} itself.
+  If the \term{function name} is a \term{list} whose \term{car} is \misc{setf}
+  and whose \term{cadr} is a \term{symbol}, its \term{function block name} is 
+  the \term{symbol} that is the \term{cadr} of the \term{function name}.
+  An \term{implementation} which supports additional kinds of \term{function names}
+  must specify for each how the corresponding \term{function block name} is computed.
+
+\gentry{function cell} \Noun\ \Traditional\ (of a \term{symbol})
+  The \term{place} which holds the \term{definition} of the
+  global \term{function} \term{binding}, if any, named by that \term{symbol},
+  and which is \term{accessed} by \funref{symbol-function}.
+  \Seeterm{cell}.
+
+\gentry{function designator} \Noun\
+  a \term{designator} for a \term{function}; that is,
+  an \term{object} that denotes a \term{function}
+  and that is one of:
+      a \term{symbol} (denoting the \term{function} named by that \term{symbol}
+                       in the \term{global environment}),
+   or a \term{function} (denoting itself).
+  The consequences are undefined if 
+  a \term{symbol} is used as a \term{function designator} but
+  it does not have a global definition as a \term{function},
+  or it has a global definition as a \term{macro} or a \term{special form}.
+  \SeetermAlso{extended function designator}.
+
+\gentry{function form} \Noun\
+  a \term{form} that is a \term{list} and that has a first element 
+  which is the \term{name} of a \term{function} to be called on
+  \term{arguments} which are the result of \term{evaluating} subsequent
+  elements of the \term{function form}.
+ 
+\gentry{function name} \Noun\ 
+  1. (in an \term{environment})
+     A \term{symbol} or a \term{list} \f{(setf \i{symbol})} 
+     that is the \term{name} of a \term{function} in that \term{environment}.
+%   \editornote{KMP: I think that in many (but obviously not all) cases where
+% 	           `function name' is used, `operator name' might be intended.
+% 		   I'll be looking for such cases later, but if readers happen
+% 		   to notice any of these, they should feel free to mark them.}%!!!
+% !!! Moon: Not always with respect to an environment, see e.g., function block name.
+%           Also, can sometimes name a macro or special operator or be fbound.
+%% Added per Boyer/Kaufmann/Moore #8,#9 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+  2. A \term{symbol} or a \term{list} \f{(setf \i{symbol})}.
+
+\gentry{functional evaluation} \Noun\ 
+  the process of extracting a \term{functional value} from a \term{function name}
+%Added for Moon:
+  or a \term{lambda expression}.
+  The evaluator performs \term{functional evaluation} 
+       implicitly when it encounters a \term{function name} 
+%Added for Moon:
+ 	or a \term{lambda expression}
+        in the \term{car} of a \term{compound form}, 
+    or explicitly when it encounters a \specref{function} \term{special form}.
+  Neither a use of a \term{symbol} as a \term{function designator} nor a
+  use of \thefunction{symbol-function} to extract the \term{functional value}
+  of a \term{symbol} is considered a \term{functional evaluation}.
+
+\gentry{functional value} \Noun\ 
+  1. (of a \term{function name} $N$ in an \term{environment} $E$)
+     The \term{value} of the \term{binding} named $N$
+     in the \term{function} \term{namespace} for \term{environment} $E$;
+%!!! Moon: Wrong.  Function cell only holds global binding.
+     that is, the contents of the \term{function cell} named $N$ in 
+     \term{environment} $E$.
+  2. (of an \term{fbound} \term{symbol} $S$)
+     the contents of the \term{symbol}'s \term{function cell}; that is,
+     the \term{value} of the \term{binding} named $S$
+     in the \term{function} \term{namespace} of the \term{global environment}.
+     (A \term{name} that is a \term{macro name} in the \term{global environment}
+      or is a \term{special operator} might or might not be \term{fbound}.
+%!!! Moon: Isn't this ["might or might not be fbound"] contrary to CLtL?
+%          I don't have the book here, so I didn't check.
+      But if $S$ is such a \term{name} and is \term{fbound}, the specific
+      nature of its \term{functional value} is \term{implementation-dependent};
+      in particular, it might or might not be a \term{function}.)
+
+\gentry{further compilation} \Noun\ 
+  \term{implementation-dependent} compilation beyond \term{minimal compilation}.
+  Further compilation is permitted to take place at \term{run time}.
+  \gexample{Block compilation and generation of machine-specific instructions
+            are examples of further compilation.}  
+
+\indextab{G}
+
+\gentry{general} \Adjective\ (of an \term{array})
+  having \term{element type} \typeref{t},
+   and consequently able to have any \term{object} as an \term{element}.
+
+\gentry{generalized boolean} \Noun\ 
+  an \term{object} used as a truth value, where the symbol~\nil\ 
+  represents \term{false} and all other \term{objects} represent \term{true}.
+  \Seeterm{boolean}.
+
+\gentry{generalized instance} \Noun\ (of a \term{class})
+  an \term{object} the \term{class} of which is either that \term{class} itself,
+  or some subclass of that \term{class}.  (Because of the correspondence between
+  types and classes, the term ``generalized instance of $X$''
+  implies ``object of type $X$'' and in cases where $X$ is a \term{class} 
+  (or \term{class name}) the reverse is also true.
+  The former terminology emphasizes the view of $X$ as a \term{class}
+  while the latter emphasizes the view of $X$ as a \term{type specifier}.)
+
+\gentry{generalized reference} \Noun\
+  a reference to a location storing an \term{object} as if to a \term{variable}.
+  (Such a reference can be either to \term{read} or \term{write} the location.)
+  \Seesection\GeneralizedReference.  See also \term{place}.
+
+\gentry{generalized synonym stream} \Noun\ (with a \term{synonym stream symbol})
+  1. (to a \term{stream}) 
+     a \term{synonym stream} to the \term{stream},
+     or a \term{composite stream} which has as a target 
+     a \term{generalized synonym stream} to the \term{stream}.
+  2. (to a \term{symbol})
+     a \term{synonym stream} to the \term{symbol},
+     or a \term{composite stream} which has as a target 
+     a \term{generalized synonym stream} to the \term{symbol}.
+
+\gentry{generic function} \Noun\
+  a \term{function} whose behavior depends on the \term{classes} or
+  identities of the arguments supplied to it and whose parts include, among
+  other things, a set of \term{methods}, a \term{lambda list}, and a
+  \term{method combination} type.
+
+\gentry{generic function lambda list} \Noun\
+  A \term{lambda list} that is used to describe data flow into a \term{generic function}.
+  \Seesection\GFLambdaLists.
+
+\gentry{gensym} \Noun\ \Traditional\ 
+  an \term{uninterned} \term{symbol}.
+  \Seefun{gensym}.
+
+%!!! Needs work. -kmp 25-Oct-90
+\gentry{global declaration} \Noun\ 
+  a \term{form} that makes certain kinds of information about 
+  code globally available; that is, a \funref{proclaim} \term{form} 
+  or a \macref{declaim} \term{form}.
+
+\gentry{global environment} \Noun\ 
+  that part of an \term{environment} that contains \term{bindings}
+  with \term{indefinite scope} and \term{indefinite extent}.
+ 
+\gentry{global variable} \Noun\
+  a \term{dynamic variable} or a \term{constant variable}.%Is this really right?
+
+\gentry{glyph} \Noun\ 
+  a visual representation.
+  \gexample{Graphic characters have associated glyphs.}
+
+\gentry{go} \Verb\ 
+  to transfer control to a \term{go point}.
+  \Seespec{go}.
+
+\gentry{go point}
+  one of possibly several \term{exit points} that are \term{established} 
+  by \specref{tagbody} (or other abstractions, such as \macref{prog}, 
+  which are built from \specref{tagbody}).
+
+\gentry{go tag} \Noun\ 
+  the \term{symbol} or \term{integer} that, within the \term{lexical scope} 
+  of a \specref{tagbody} \term{form}, names an \term{exit point}
+  \term{established} by that \specref{tagbody} \term{form}.
+
+\gentry{graphic} \Adjective\ (of a \term{character})
+  being a ``printing'' or ``displayable'' \term{character} 
+  that has a standard visual representation
+  as a single \term{glyph}, such as \f{A} or \f{*} or \f{=}.
+  \term{Space} is defined to be \term{graphic}.
+  Of the \term{standard characters}, all but \term{newline} are \term{graphic}.
+  \Seeterm{non-graphic}.
+
+\indextab{H}
+
+\gentry{handle} \Verb\ (of a \term{condition} being \term{signaled})
+  to perform a non-local transfer of control, terminating the ongoing
+  \term{signaling} of the \term{condition}.
+
+\gentry{handler} \Noun\ 
+  %I'm expecting that we might have a need for other kinds of handlers. -kmp 31-Dec-90
+  a \term{condition handler}.
+
+\gentry{hash table} \Noun\ 
+  an \term{object} \oftype{hash-table}, 
+  which provides a mapping from \term{keys} to \term{values}.
+
+\gentry{home package} \Noun\ (of a \term{symbol})
+  the \term{package}, if any, which is contents of the \term{package cell} 
+  of the \term{symbol}, and which dictates how the \term{Lisp printer} 
+  prints the \term{symbol} when it is not \term{accessible} in the
+  \term{current package}. (\term{Symbols} which have \nil\ in their
+  \term{package cell} are said to have no \term{home package}, and also
+  to be \term{apparently uninterned}.)
+
+\indextab{I}                           
+
+\gentry{I/O customization variable} \Noun\
+  one of the \term{stream variables} in \thenextfigure, 
+  or some other (\term{implementation-defined}) \term{stream variable}
+      that is defined by the \term{implementation} 
+      to be an \term{I/O customization variable}.
+
+\showthree{Standardized I/O Customization Variables}{
+*debug-io*&*error-io*&query-io*\cr
+*standard-input*&*standard-output*&*trace-output*\cr
+}
+
+\gentry{identical} \Adjective\ 
+  the \term{same} under \funref{eq}.
+
+\gentry{identifier} \Noun\        
+  1. a \term{symbol} used to identify or to distinguish \term{names}. 
+  2. a \term{string} used the same way.            
+ 
+\gentry{immutable} \Adjective\
+  not subject to change, either because no \term{operator} is provided which is
+  capable of effecting such change or because some constraint exists which 
+  prohibits the use of an \term{operator} that might otherwise be capable of
+  effecting such a change.  Except as explicitly indicated otherwise,
+  \term{implementations} are not required to detect attempts to modify
+  \term{immutable} \term{objects} or \term{cells}; the consequences of attempting
+  to make such modification are undefined.
+  \gexample{Numbers are immutable.}
+
+\gentry{implementation} \Noun\ 
+  a system, mechanism, or body of \term{code} that implements the semantics of \clisp.
+
+\gentry{implementation limit} \Noun\ 
+  a restriction imposed by an \term{implementation}.
+ 
+\gentry{implementation-defined} \Adjective\ 
+  \term{implementation-dependent}, but required by this specification to be
+  defined by each \term{conforming implementation} and to be documented by 
+  the corresponding implementor.
+%When this was moved to this position from far away, it became redundant. -kmp 14-Nov-91
+% %I added this after asking Quinquevirate if they thought I should.
+% %No one objected, and RPG thought it was a good idea. -kmp 17-Oct-90
+%   A \term{conforming implementation} is required to document its treatment of each 
+%   item in this specification which is marked \term{implementation-defined}.
+ 
+\gentry{implementation-dependent} \Adjective\ 
+  describing a behavior or aspect of \clisp\ which has been deliberately left
+  unspecified, that might be defined in some \term{conforming implementations} 
+  but not in others, and whose details may differ between \term{implementations}.
+%I added this after asking Quinquevirate if they thought I should.
+%No one objected, and RPG thought it was a good idea. -kmp 17-Oct-90
+  A \term{conforming implementation} is encouraged (but not required) to 
+  document its treatment of each item in this specification which is
+  marked \term{implementation-dependent}, although in some cases
+  such documentation might simply identify the item as ``undefined.''
+  
+\gentry{implementation-independent} \Adjective\ 
+  used to identify or emphasize a behavior or aspect of \clisp\ which does 
+  not vary between \term{conforming implementations}.
+
+\gentry{implicit block} \Noun\ 
+ a \term{block} introduced by a \term{macro form} 
+ rather than by an explicit \specref{block} \term{form}.
+
+\gentry{implicit compilation} \Noun\ 
+ \term{compilation} performed during \term{evaluation}.
+
+\gentry{implicit progn} \Noun\ 
+  an ordered set of adjacent \term{forms} appearing in another
+  \term{form}, and defined by their context in that \term{form}
+  to be executed as if within a \specref{progn}.
+
+\gentry{implicit tagbody} \Noun\ 
+  an ordered set of adjacent \term{forms} and/or \term{tags} 
+  appearing in another \term{form}, and defined by their context 
+  in that \term{form} to be executed as if within a \specref{tagbody}.
+
+\gentry{import} \TransitiveVerb\ (a \term{symbol} into a \term{package})
+  to make the \term{symbol} be \term{present} in the \term{package}.
+
+\gentry{improper list} \Noun\ 
+  a \term{list} which is not a \term{proper list}:  
+  a \term{circular list} or a \term{dotted list}.
+ 
+\gentry{inaccessible} \Adjective\ 
+  not \term{accessible}.
+ 
+\gentry{indefinite extent} \Noun\ 
+  an \term{extent} whose duration is unlimited.
+  \gexample{Most Common Lisp objects have indefinite extent.}
+ 
+\gentry{indefinite scope} \Noun\ 
+  \term{scope} that is unlimited.
+ 
+\gentry{indicator} \Noun\ 
+  a \term{property indicator}.
+
+\gentry{indirect instance} \Noun\ (of a \term{class} $C\sub 1$)
+  an \term{object} of \term{class} $C\sub 2$, 
+  where $C\sub 2$ is a \term{subclass} of $C\sub 1$.
+  \gexample{An integer is an indirect instance of the class \typeref{number}.}
+
+\gentry{inherit} \TransitiveVerb\ 
+  1. to receive or acquire a quality, trait, or characteristic; 
+     to gain access to a feature defined elsewhere.
+  2. (a \term{class}) to acquire the structure and behavior defined
+     by a \term{superclass}.
+  3. (a \term{package}) to make \term{symbols} \term{exported} by another
+     \term{package} \term{accessible} by using \funref{use-package}.
+ 
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+\gentry{initial pprint dispatch table} \Noun\
+  \thevalueof{*print-pprint-dispatch*} at the time the \term{Lisp image} is started.
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+\issue{WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91}
+\gentry{initial readtable} \Noun\
+  \thevalueof{*readtable*} at the time the \term{Lisp image} is started.
+\endissue{WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91}
+
+\issue{PLIST-DUPLICATES:ALLOW}
+\gentry{initialization argument list} \Noun\ 
+% a \term{proper list} of \term{keyword/value pairs} 
+% (of initialization argument \term{names} and \term{values})
+  a \term{property list} of initialization argument \term{names} and \term{values}
+  used in the protocol for initializing and reinitializing \term{instances} of \term{classes}.
+  \Seesection\ObjectCreationAndInit.
+\endissue{PLIST-DUPLICATES:ALLOW}
+ 
+\gentry{initialization form} \Noun\ 
+  a \term{form} used to supply the initial \term{value} for a \term{slot}
+  or \term{variable}.
+  \gexample{The initialization form for a slot in a \macref{defclass} form
+            is introduced by the keyword \kwd{initform}.}
+
+\gentry{input} \Adjective\ (of a \term{stream})
+  supporting input operations (\ie being a ``data source'').
+  An \term{input} \term{stream} might also be an \term{output} \term{stream},
+  in which case it is sometimes called a \term{bidirectional} \term{stream}.
+  \Seefun{input-stream-p}.
+
+\gentry{instance} \Noun\ 
+  1. a \term{direct instance}.
+  2. a \term{generalized instance}.
+  3. an \term{indirect instance}.
+
+\gentry{integer} \Noun\ 
+  an \term{object} \oftype{integer}, which represents a mathematical integer.
+
+\gentry{interactive stream} \Noun\ 
+  a \term{stream} on which it makes sense to perform interactive querying.
+  \Seesection\InteractiveStreams.
+
+%!!! The usage "interning a symbol" is used but not described here.
+%     e.g., see the type entry for KEYWORD.
+\gentry{intern} \TransitiveVerb\ 
+  1. (a \term{string} in a \term{package})
+     to look up the \term{string} in the \term{package}, 
+     returning either a \term{symbol} with that \term{name}
+     which was already \term{accessible} in the \term{package}
+     or a newly created \term{internal symbol} of the \term{package} 
+     with that \term{name}.
+  2. \Idiomatic\ generally, to observe a protocol whereby objects which 
+     are equivalent or have equivalent names under some predicate defined
+     by the protocol are mapped to a single canonical object.
+
+\gentry{internal symbol} \Noun\ (of a \term{package})
+  a symbol which is \term{accessible} in the \term{package},
+  but which is not an \term{external symbol} of the \term{package}.
+
+\gentry{internal time} \Noun\
+  \term{time}, represented as an \term{integer} number of \term{internal time units}.
+  \term{Absolute} \term{internal time} is measured as an offset 
+  from an arbitrarily chosen, \term{implementation-dependent} base.
+  \Seesection\InternalTime.
+
+%% 25.4.1 21
+\gentry{internal time unit} \Noun\ 
+  a unit of time equal to $1/n$ of a second, 
+  for some \term{implementation-defined} \term{integer} value of $n$.
+  \Seevar{internal-time-units-per-second}.
+
+\gentry{interned} \Adjective\ \Traditional\ 
+  1. (of a \term{symbol}) \term{accessible}\meaning{3} in
+     any \term{package}.
+  2. (of a \term{symbol} in a specific \term{package}) 
+     \term{present} in that \term{package}.
+
+\gentry{interpreted function} \Noun\ 
+  a \term{function} that is not a \term{compiled function}.
+  (It is possible for there to be a \term{conforming implementation} which
+   has no \term{interpreted functions}, but a \term{conforming program}
+   must not assume that all \term{functions} are \term{compiled functions}.)
+
+\gentry{interpreted implementation} \Noun\
+  an \term{implementation} that uses an execution strategy for 
+  \term{interpreted functions} that does not involve a one-time semantic
+  analysis pre-pass, and instead uses ``lazy'' (and sometimes repetitious)
+  semantic analysis of \term{forms} as they are encountered during execution.
+
+\gentry{interval designator} \Noun\ (of \term{type} $T$)
+  an ordered pair of \term{objects} that describe a \term{subtype} of $T$
+  by delimiting an interval on the real number line.
+  \Seesection\IntervalDesignators.
+
+\gentry{invalid} \Noun, \Adjective\
+  1. \Noun\
+     a possible \term{constituent trait} of a \term{character}
+     which if present signifies that the \term{character} 
+     cannot ever appear in a \term{token} 
+     except under the control of a \term{single escape} \term{character}.
+     For details, \seesection\ConstituentChars.
+  2. \Adjective\ (of a \term{character})
+     being a \term{character} that has \term{syntax type} \term{constituent}
+     in the \term{current readtable} and that has the 
+     \term{constituent trait} \term{invalid}\meaning{1}.
+     \Seefigure\ConstituentTraitsOfStdChars.
+
+\issue{DOTIMES-IGNORE:X3J13-MAR91}
+\gentry{iteration form} \Noun\
+  a \term{compound form} whose \term{operator} is named in \thenextfigure,
+  or a \term{compound form} that has an \term{implementation-defined} \term{operator}
+     and that is defined by the \term{implementation} to be an \term{iteration form}.
+
+\displaythree{Standardized Iteration Forms}{
+do&do-external-symbols&dotimes\cr
+do*&do-symbols&loop\cr
+do-all-symbols&dolist&\cr
+}
+
+% Moon: Is this correct? I think WITH variables in LOOP are not iteration variables.
+% KMP: Looks right to me. See issue DOTIMES-IGNORE.
+\gentry{iteration variable} \Noun\
+  a \term{variable} $V$, the \term{binding} for which was created by an
+  \term{explicit use} of $V$ in an \term{iteration form}.
+\endissue{DOTIMES-IGNORE:X3J13-MAR91}
+
+\indextab{K}
+
+\gentry{key} \Noun\ 
+  an \term{object} used for selection during retrieval. 
+  \Seeterm{association list}, \term{property list}, and \term{hash table}.
+  Also, \seesection\SequenceConcepts.
+ 
+\gentry{keyword} \Noun\ 
+  1. a \term{symbol} the \term{home package} of which is \thepackage{keyword}.
+  2. any \term{symbol}, usually but not necessarily in \thepackage{keyword},
+     that is used as an identifying marker in keyword-style argument passing.
+     \Seemisc{lambda}.
+  3. \Idiomatic\ a \term{lambda list keyword}.
+
+\gentry{keyword parameter} \Noun\
+  A \term{parameter} for which a corresponding keyword \term{argument}
+  is optional.  (There is no such thing as a required keyword \term{argument}.)
+  If the \term{argument} is not supplied, a default value is used.
+  \SeetermAlso{supplied-p parameter}.
+
+\issue{PLIST-DUPLICATES:ALLOW}
+\gentry{keyword/value pair} \Noun\ 
+  two successive \term{elements} (a \term{keyword} and a \term{value}, 
+  respectively) of a \term{property list}.
+\endissue{PLIST-DUPLICATES:ALLOW}
+ 
+\indextab{L}
+ 
+\gentry{lambda combination} \Noun\ \Traditional\ 
+  a \term{lambda form}.
+
+\gentry{lambda expression} \Noun\ 
+  a \term{list} which can be used in place of a \term{function name} in 
+  certain contexts to denote a \term{function} by directly describing its
+  behavior rather than indirectly by referring to the name of an
+  \term{established} \term{function}; its name derives from the fact that its
+  first element is the \term{symbol} \f{lambda}.
+  \Seemisc{lambda}.
+ 
+\gentry{lambda form} \Noun\ 
+  a \term{form} that is a \term{list} and that has a first element
+  which is a \term{lambda expression} representing a \term{function}
+  to be called on \term{arguments} which are the result of \term{evaluating}
+  subsequent elements of the \term{lambda form}.
+
+\gentry{lambda list} \Noun\ 
+  a \term{list} that specifies a set of \term{parameters} 
+  (sometimes called \term{lambda variables})
+  and a protocol for receiving \term{values} for those \term{parameters};
+  that is,
+  an \term{ordinary lambda list},
+  an \term{extended lambda list},
+  or a \term{modified lambda list}.
+
+\gentry{lambda list keyword} \Noun\ 
+  a \term{symbol} whose \term{name} begins with \term{ampersand}
+  and that is specially recognized in a \term{lambda list}.
+  Note that no \term{standardized} \term{lambda list keyword} 
+  is in \thepackage{keyword}.
+ 
+\gentry{lambda variable} \Noun\ 
+  a \term{formal parameter}, used to emphasize the \term{variable}'s
+  relation to the \term{lambda list} that \term{established} it.
+ 
+\gentry{leaf} \Noun\ 
+  1. an \term{atom} in a \term{tree}\meaning{1}.
+  2. a terminal node of a \term{tree}\meaning{2}.
+ 
+\gentry{leap seconds} \Noun\
+  additional one-second intervals of time that are occasionally inserted 
+  into the true calendar by official timekeepers as a correction similar 
+  to ``leap years.''  All \clisp\ \term{time} representations ignore 
+  \term{leap seconds}; every day is assumed to be exactly 86400 seconds 
+  long.
+
+\gentry{left-parenthesis} \Noun\
+  the \term{standard character} ``\f{(}'',
+  that is variously called
+      ``left parenthesis''
+   or ``open parenthesis''
+  \Seefigure\StdCharsThree.
+
+\gentry{length} \Noun\ (of a \term{sequence})
+  the number of \term{elements} in the \term{sequence}.
+  (Note that if the \term{sequence} is a \term{vector} with a 
+   \term{fill pointer}, its \term{length} is the same as the 
+   \term{fill pointer} even though the total allocated size of
+   the \term{vector} might be larger.)
+
+\gentry{lexical binding} \Noun\ 
+  a \term{binding} in a \term{lexical environment}.
+
+\gentry{lexical closure} \Noun\ 
+  a \term{function} that, when invoked on \term{arguments}, executes
+  the body of a \term{lambda expression} in the \term{lexical environment} 
+  that was captured at the time of the creation of the \term{lexical closure},
+  augmented by \term{bindings} of the \term{function}'s \term{parameters}
+  to the corresponding \term{arguments}.
+ 
+\gentry{lexical environment} \Noun\ 
+  that part of the \term{environment} that contains \term{bindings}
+  whose names have \term{lexical scope}. A \term{lexical environment} 
+  contains, among other things:
+%!!! Moon: [re "among other things"] scary!
+     ordinary \term{bindings} of \term{variable} \term{names} to \term{values},
+     lexically \term{established} \term{bindings} of \term{function names}
+        to \term{functions},
+     \term{macros},
+     \term{symbol macros},
+     \term{blocks},
+     \term{tags},
+  and
+     \term{local declarations} (\seemisc{declare}).
+
+\gentry{lexical scope} \Noun\ 
+  \term{scope} that is limited to a spatial or textual region within the
+  establishing \term{form}.
+%!!! Moon: [re "names" in this example] "bindings"?
+  \gexample{The names of parameters to a function normally are lexically scoped.}
+
+\gentry{lexical variable} \Noun\ 
+  a \term{variable} the \term{binding} for which is in the
+  \term{lexical environment}.
+
+%!!! KMP wonders if the "Lisp xxx" terms shouldn't be renamed to not require 
+%    the use of the prefix "Lisp".
+
+%!!! Moon: Too long?
+%    KMP: Maybe I'll separate out into a concept section.
+\gentry{Lisp image} \Noun\
+  a running instantiation of a \clisp\ \term{implementation}.
+  A \term{Lisp image} is characterized by a single address space in which any
+  \term{object} can directly refer to any another in conformance with this specification,
+  and by a single, common, \term{global environment}.
+  (External operating systems sometimes call this a 
+       ``core image,''
+       ``fork,''
+       ``incarnation,'' 
+       ``job,''
+    or ``process.''  Note however, that the issue of a ``process'' in such 
+    an operating system is technically orthogonal to the issue of a \term{Lisp image}
+    being defined here.  Depending on the operating system, a single ``process'' 
+    might have multiple \term{Lisp images}, and multiple ``processes'' might reside
+    in a single \term{Lisp image}.  Hence, it is the idea of a fully shared address
+    space for direct reference among all \term{objects} which is the defining
+    characteristic.  Note, too, that two ``processes'' which have a communication 
+    area that permits the sharing of some but not all \term{objects} are considered
+    to be distinct \term{Lisp images}.)
+
+\gentry{Lisp printer} \Noun\ \Traditional\ 
+  the procedure that prints the character representation of an
+  \term{object} onto a \term{stream}. (This procedure is implemented
+  by \thefunction{write}.)
+ 
+\gentry{Lisp read-eval-print loop} \Noun\ \Traditional\ 
+  an endless loop that \term{reads}\meaning{2} a \term{form},
+  \term{evaluates} it,
+  and prints (\ie \term{writes}\meaning{2}) the results.
+  In many \term{implementations},
+  the default mode of interaction with \clisp\ during program development
+  is through such a loop.
+
+\gentry{Lisp reader} \Noun\ \Traditional\ 
+  the procedure that parses character representations of \term{objects}
+  from a \term{stream}, producing \term{objects}.
+  (This procedure is implemented by \thefunction{read}.)
+  %!!! KMP wants more words about the readtable here.
+ 
+\gentry{list} \Noun\ 
+  1. a chain of \term{conses} in which the \term{car} of each
+     \term{cons} is an \term{element} of the \term{list}, 
+     and the \term{cdr} of each \term{cons} is either the next
+     link in the chain or a terminating \term{atom}.  
+     \SeetermAlso{proper list},
+	    \term{dotted list}, 
+         or \term{circular list}.
+  2. the \term{type} that is the union of \typeref{null} and \typeref{cons}.
+
+\gentry{list designator} \Noun\
+  a \term{designator} for a \term{list} of \term{objects}; that is,
+  an \term{object} that denotes a \term{list} 
+  and that is one of:
+       a \term{non-nil} \term{atom} 
+         (denoting a \term{singleton} \term{list} 
+          whose \term{element} is that \term{non-nil} \term{atom})
+       or a \term{proper list} (denoting itself).
+
+\gentry{list structure} \Noun\ (of a \term{list})
+  the set of \term{conses} that make up the \term{list}.
+  Note that while the \term{car}\meaning{1b} component of each such \term{cons}
+  is part of the \term{list structure}, 
+  the \term{objects} that are \term{elements} of the \term{list}
+  (\ie the \term{objects} that are the \term{cars}\meaning{2} of each \term{cons}
+   in the \term{list})
+  are not themselves part of its \term{list structure}, 
+  even if they are \term{conses},
+  except in the (\term{circular}\meaning{2})
+  case where the \term{list} 
+  actually contains one of its \term{tails} as an \term{element}.
+  (The \term{list structure} of a \term{list} is sometimes redundantly 
+   referred to as its ``top-level list structure'' in order to emphasize
+   that any \term{conses} that are \term{elements} of the \term{list} 
+   are not involved.)
+
+\gentry{literal} \Adjective\ (of an \term{object})
+  referenced directly in a program rather than being computed by the program;
+  that is,
+  appearing as data in a \specref{quote} \term{form}, 
+  or, if the \term{object} is a \term{self-evaluating object},
+  appearing as unquoted data.
+  \gexample{In the form \f{(cons "one" '("two"))}, 
+            the expressions \f{"one"}, \f{("two")}, and \f{"two"}
+            are literal objects.}
+
+\gentry{load} \TransitiveVerb\ (a \term{file})
+  to cause the \term{code} contained in the \term{file} to be \term{executed}.
+  \Seefun{load}.
+
+\gentry{load time} \Noun\
+  the duration of time that the loader is \term{loading} \term{compiled code}.
+
+\gentry{load time value} \Noun\ 
+  an \term{object} referred to in \term{code} by a \specref{load-time-value} 
+  \term{form}.  The \term{value} of such a \term{form} is some specific
+  \term{object} which can only be computed in the run-time \term{environment}.
+  In the case of \term{file} \term{compilation}, the \term{value} is
+  computed once as part of the process of \term{loading} the \term{compiled file},
+  and not again.  \Seespec{load-time-value}.
+
+\gentry{loader} \Noun\
+  a facility that is part of Lisp and that \term{loads} a \term{file}.
+  \Seefun{load}.
+
+\gentry{local declaration} \Noun\ 
+  an \term{expression} which may appear only in specially designated
+  positions of certain \term{forms}, and which provides information about
+  the code contained within the containing \term{form}; 
+  that is, a \misc{declare} \term{expression}.
+
+\gentry{local precedence order} \Noun\ (of a \term{class})
+  a \term{list} consisting of the \term{class} followed by its
+  \term{direct superclasses} in the order mentioned in the defining
+  \term{form} for the \term{class}.
+ 
+\gentry{local slot} \Noun\ (of a \term{class})
+  a \term{slot} \term{accessible} in only one \term{instance}, 
+  namely the \term{instance} in which the \term{slot} is allocated.
+
+% Or maybe... {Request for comment sent to Moon. -kmp 28-Feb-91}
+%
+% \gentry{local slot} \Noun\ 
+%   1. (of an \term{instance}) a \term{slot} which is allocated in and \term{accessible}
+%      to just that \term{instance}.
+%   2. (of a \term{class}) a \term{slot} which is allocated anew for each 
+%      \term{generalized instance} of the \term{class}.
+
+\gentry{logical block} \Noun\
+  a conceptual grouping of related output used by the \term{pretty printer}.
+  \Seemac{pprint-logical-block} and \secref\DynamicControlofOutput.
+
+\gentry{logical host} \Noun\
+  an \term{object} of \term{implementation-dependent} nature 
+  that is used as the representation of a ``host'' in a \term{logical pathname},
+  and that has an associated set of translation rules for converting
+  \term{logical pathnames} belonging to that host into \term{physical pathnames}.
+  \Seesection\LogicalPathnames.
+
+\gentry{logical host designator} \Noun\
+  a \term{designator} for a \term{logical host}; that is,
+  an \term{object} that denotes a \term{logical host} 
+  and that is one of:
+       a \term{string} (denoting the \term{logical host} that it names),
+    or a \term{logical host} (denoting itself).
+  (Note that because the representation of a \term{logical host} 
+   is \term{implementation-dependent},
+   it is possible that an \term{implementation} might represent 
+   a \term{logical host} as the \term{string} that names it.)
+
+\gentry{logical pathname} \Noun\ 
+  an \term{object} \oftype{logical-pathname}.
+
+\gentry{long float} \Noun\ 
+  an \term{object} \oftype{long-float}.
+
+\gentry{loop keyword} \Noun\ \Traditional\
+  a symbol that is a specially recognized part of the syntax of 
+  an extended \macref{loop} \term{form}.  Such symbols are recognized by their
+  \term{name} (using \funref{string=}), not by their identity; as such, they
+  may be in any package.  A \term{loop keyword} is not a \term{keyword}.
+
+\gentry{lowercase} \Adjective\ (of a \term{character})
+     being among \term{standard characters} corresponding to
+     the small letters \f{a} through \f{z},
+  or being some other \term{implementation-defined} \term{character}
+      that is defined by the \term{implementation} to be \term{lowercase}.
+  \Seesection\CharactersWithCase.
+
+\indextab{M}
+ 
+\gentry{macro} \Noun\ 
+  1. a \term{macro form}
+  2. a \term{macro function}.
+  3. a \term{macro name}.
+ 
+\gentry{macro character} \Noun\ 
+  a \term{character} which, when encountered by the \term{Lisp reader} 
+  in its main dispatch loop, introduces a \term{reader macro}\meaning{1}.
+  (\term{Macro characters} have nothing to do with \term{macros}.)
+
+\gentry{macro expansion} \Noun\ 
+  1. the process of translating a \term{macro form} into another
+     \term{form}.
+  2. the \term{form} resulting from this process.
+ 
+\gentry{macro form} \Noun\ 
+%!!! JonL thinks "stands for" is "shaky"
+  a \term{form} that stands for another \term{form} 
+  (\eg for the purposes of abstraction, information hiding, 
+       or syntactic convenience);
+  that is, 
+    either a \term{compound form} whose first element is a \term{macro name}, 
+    or     a \term{form} that is a \term{symbol} that names a 
+             \term{symbol macro}.
+
+\gentry{macro function} \Noun\ 
+  a \term{function} of two arguments, a \term{form} and an 
+  \term{environment}, that implements \term{macro expansion} by
+  producing a \term{form} to be evaluated in place of the original
+  argument \term{form}.
+ 
+\gentry{macro lambda list} \Noun\
+  an \term{extended lambda list} used in \term{forms} that \term{establish}
+  \term{macro} definitions, such as \macref{defmacro} and \macref{macrolet}.
+  \Seesection\MacroLambdaLists.
+
+\gentry{macro name} \Noun\ 
+  a \term{name} for which \funref{macro-function} returns \term{true}
+  and which when used as the first element of a \term{compound form}
+  identifies that \term{form} as a \term{macro form}.
+ 
+\gentry{macroexpand hook} \Noun\
+  the \term{function} that is \thevalueof{*macroexpand-hook*}.
+
+\gentry{mapping} \Noun\ 
+  1. a type of iteration in which a \term{function} is successively 
+     applied to \term{objects} taken from corresponding entries in
+     collections such as \term{sequences} or \term{hash tables}.
+  2. \Mathematics\ a relation between two sets in which each element of the
+     first set (the ``domain'') is assigned one element of the second
+     set (the ``range'').
+
+\gentry{metaclass} \Noun\ 
+  1. a \term{class} whose instances are \term{classes}.
+  2. (of an \term{object}) the \term{class} of the \term{class} of the \term{object}.
+ 
+\gentry{Metaobject Protocol} \Noun\
+  one of many possible descriptions of how a \term{conforming implementation}
+  might implement various aspects of the \CLOS.  This description is beyond
+  the scope of this document, and no \term{conforming implementation} is
+  required to adhere to it except as noted explicitly in this specification.
+  Nevertheless, its existence helps to establish normative practice, 
+  and implementors with no reason to diverge from it are encouraged to
+  consider making their \term{implementation} adhere to it where possible.
+  It is described in detail in \MetaObjectProtocol.
+
+\gentry{method} \Noun\ 
+  an \term{object} that is part of a \term{generic function} and which
+  provides information about how that \term{generic function} should 
+  behave when its \term{arguments} are \term{objects} of certain
+  \term{classes} or with certain identities.
+ 
+\gentry{method combination} \Noun\ 
+  1. generally, the composition of a set of \term{methods} to produce an
+     \term{effective method} for a \term{generic function}.
+  2. an object \oftype{method-combination}, which represents the details
+     of how the \term{method combination}\meaning{1} for one or more 
+     specific \term{generic functions} is to be performed.
+ 
+\gentry{method-defining form} \Noun\ 
+  a \term{form} that defines a \term{method} for a \term{generic function},
+  whether explicitly or implicitly.  
+  \Seesection\IntroToGFs.
+
+\gentry{method-defining operator} \Noun\
+  an \term{operator} corresponding to a \term{method-defining} \term{form}.
+  \Seefigure\StdMethDefOps.
+
+\gentry{minimal compilation} \Noun\
+  actions the \term{compiler} must take at compile time. 
+  \Seesection\CompilationSemantics.
+
+\gentry{modified lambda list} \Noun\ 
+  a list resembling an \term{ordinary lambda list} in form and purpose, 
+  but which deviates in syntax or functionality from the definition of an 
+  \term{ordinary lambda list}.
+  \Seeterm{ordinary lambda list}.
+  \gexample{\macref{deftype} uses a modified lambda list.}
+
+\gentry{most recent} \Adjective\
+  innermost;
+  that is, having been \term{established} (and not yet \term{disestablished})
+%!!! Moon: This next line looks out of order.  Maybe reorganize this description.
+%          Put it before the parens? No. Hmm...
+  more recently than any other of its kind.
+
+\gentry{multiple escape} \Noun, \Adjective\
+  1. \Noun\ the \term{syntax type} of a \term{character} 
+     that is used in pairs  to indicate that the enclosed \term{characters}
+     are to be treated as \term{alphabetic}\meaning{2} \term{characters}
+     with their \term{case} preserved.
+     For details, \seesection\MultipleEscapeChar.
+  2. \Adjective\ (of a \term{character}) 
+     having the \term{multiple escape} \term{syntax type}.
+  3. \Noun\ a \term{multiple escape}\meaning{2} \term{character}.
+     (In the \term{standard readtable},
+      \term{vertical-bar} is a \term{multiple escape} \term{character}.)
+
+\gentry{multiple values} \Noun\ 
+  1. more than one \term{value}.
+     \gexample{The function \funref{truncate} returns multiple values.}
+  2. a variable number of \term{values}, possibly including zero or one.
+     \gexample{The function \funref{values} returns multiple values.}
+  3. a fixed number of values other than one.
+     \gexample{The macro \macref{multiple-value-bind} is among the few
+	       operators in \clisp\ which can detect and manipulate
+ 	       multiple values.}
+
+\indextab{N}
+ 
+%!!! Moon: also, of a keyword argument or initarg.
+\gentry{name} \Noun, \TransitiveVerb\ 
+  1. \Noun\ an \term{identifier} by which an \term{object},
+     a \term{binding}, or an \term{exit point}
+%or "tag"
+     is referred to by association using a \term{binding}.
+  2. \TransitiveVerb\ to give a \term{name} to.
+  3. \Noun\ (of an \term{object} having a name component) 
+     the \term{object} which is that component.  
+     \gexample{The string which is a symbol's name is returned
+	       by \funref{symbol-name}.}
+  4. \Noun\ (of a \term{pathname})
+     a. the name component, returned by \funref{pathname-name}.
+     b. the entire namestring, returned by \funref{namestring}.
+  5. \Noun\ (of a \term{character})
+     a \term{string} that names the \term{character}
+     and that has \term{length} greater than one.
+     (All \term{non-graphic} \term{characters} are required to have \term{names}
+      unless they have some \term{implementation-defined} \term{attribute}
+      which is not \term{null}.  Whether or not other \term{characters}
+      have \term{names} is \term{implementation-dependent}.)
+
+\gentry{named constant} \Noun\ 
+  a \term{variable} that is defined by \clisp,
+				    by the \term{implementation},
+  				 or by user code (\seemac{defconstant})
+  to always \term{yield} the same \term{value} when \term{evaluated}.
+  \gexample{The value of a named constant may not be changed
+            by assignment or by binding.}
+
+%!!! Moon: "kind" is not defined, but I thin kthis is wrong.  Especially if "kind"
+%          is similar to "type".  Also, should relate to "environment" and section 3.1.
+\gentry{namespace} \Noun\ 
+  1. \term{bindings} whose denotations are restricted to a particular kind.
+     \gexample{The bindings of names to tags is the tag namespace.}
+  2. any \term{mapping} whose domain is a set of \term{names}.
+     \gexample{A package defines a namespace.}
+ 
+\issue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+\gentry{namestring} \Noun\ 
+  a \term{string} that represents a \term{filename}
+  using either the \term{standardized} notation for naming \term{logical pathnames}
+         described in \secref\LogPathNamestrings,
+     or some \term{implementation-defined} notation for naming a \term{physical pathname}.
+\endissue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+
+\gentry{newline} \Noun\
+  the \term{standard character} \NewlineChar,
+  notated for the \term{Lisp reader} as \f{\#\\Newline}.
+
+\gentry{next method} \Noun\ 
+  the next \term{method} to be invoked with respect to a given
+  \term{method} for a particular set of arguments or argument
+  \term{classes}.  
+%JonL thinks we should add "under standardized method combinations"?
+%Moon thinks maybe not.  He says this is about as good as we should expect to get
+% given the space in the glossary.
+  \Seesection\ApplyMethCombToSortedMethods.
+ 
+\gentry{nickname} \Noun\ (of a \term{package})
+  one of possibly several \term{names} that can be used to refer to
+  the \term{package} but that is not the primary \term{name} 
+  of the \term{package}.
+
+\gentry{nil} \Noun\ 
+  the \term{object} that is at once
+        the \term{symbol} named \f{"NIL"} in \thepackage{common-lisp},
+        the \term{empty list},
+        the \term{boolean} (or \term{generalized boolean}) representing \term{false},
+    and the \term{name} of the \term{empty type}.
+%!!! Should other things be here like use of NIL to represent 
+%    null lexical environment (should there be a term "environment designator"?),
+%    use of NIL as an input/output stream designator, etc.?
+ 
+\gentry{non-atomic} \Adjective\ 
+  being other than an \term{atom}; \ie being a \term{cons}.
+
+\gentry{non-constant variable} \Noun\
+  a \term{variable} that is not a \term{constant variable}.
+
+\gentry{non-correctable} \Adjective\ (of an \term{error})
+  not intentionally \term{correctable}.
+  (Because of the dynamic nature of \term{restarts},
+   it is neither possible nor generally useful to completely prohibit
+   an \term{error} from being \term{correctable}.
+   This term is used in order to express an intent that no special effort
+   should be made by \term{code} signaling an \term{error} to make
+   that \term{error} \term{correctable}; 
+   however, there is no actual requirement on \term{conforming programs}
+   or \term{conforming implementations} imposed by this term.)
+
+\gentry{non-empty} \Adjective\
+  having at least one \term{element}.
+
+% Replaced by "distinct"
+% \gentry{non-eq} \Adjective\
+%   not \term{eq}.
+
+\gentry{non-generic function} \Noun\ 
+  a \term{function} that is not a \term{generic function}.
+
+\gentry{non-graphic} \Adjective\ (of a \term{character})
+  not \term{graphic}.
+  \Seesection\GraphicChars.
+
+\gentry{non-list} \Noun, \Adjective\ 
+  other than a \term{list}; \ie a \term{non-nil} \term{atom}.
+
+\gentry{non-local exit} \Noun\ 
+  a transfer of control (and sometimes \term{values}) to 
+  an \term{exit point} for reasons other than a \term{normal return}.
+  \gexample{The operators \specref{go}, \specref{throw}, 
+	    and \specref{return-from} cause a non-local exit.}
+
+\gentry{non-nil} \Noun, \Adjective\ 
+  not \nil.  Technically, any \term{object} which is not \nil\ can be
+  referred to as \term{true}, but that would tend to imply a unique view
+  of the \term{object} as a \term{generalized boolean}.
+  Referring to such an \term{object} as \term{non-nil} avoids this implication.
+
+%!!! Moon: Is this right? Is it a non-empty environment, 
+%          or any environment other than NIL?  Where is this term used?
+\gentry{non-null lexical environment} \Noun\ 
+  a \term{lexical environment} that has additional information not present in
+  the \term{global environment}, such as one or more \term{bindings}.
+
+\gentry{non-simple} \Adjective\
+  not \term{simple}.
+
+%!!! Make a glossary term for "constituent character"?
+%!!! What about "extended token"?
+\gentry{non-terminating} \Adjective\ (of a \term{macro character})
+  being such that it is treated as a constituent \term{character}
+  when it appears in the middle of an extended token.
+  \Seesection\ReaderAlgorithm.
+
+\gentry{non-top-level form} \Noun\ 
+  a \term{form} that, by virtue of its position as a \term{subform}
+  of another \term{form}, is not a \term{top level form}.
+  \Seesection\TopLevelForms.
+
+\gentry{normal return} \Noun\ 
+  the natural transfer of control and \term{values} which occurs after
+  the complete \term{execution} of a \term{form}.
+
+\gentry{normalized} \Adjective, \ANSI, \IEEE\ (of a \term{float})
+  conforming to the description of ``normalized'' as described by {\IEEEFloatingPoint}.
+  \Seeterm{denormalized}.
+
+\gentry{null} \Adjective, \Noun\ 
+  1. \Adjective\ 
+     a. (of a \term{list}) having no \term{elements}: empty.  \Seeterm{empty list}.
+     b. (of a \term{string}) having a \term{length} of zero.
+	(It is common, both within this document and in observed spoken behavior,
+         to refer to an empty string by an apparent definite reference,
+         as in ``the \term{null} \term{string}'' even though no attempt is made to
+	 \term{intern}\meaning{2} null strings.  The phrase 
+         ``a \term{null} \term{string}'' is technically more correct, 
+	 but is generally considered awkward by most Lisp programmers.  
+	 As such, the phrase ``the \term{null} \term{string}'' 
+         should be treated as an indefinite reference in all cases 
+	 except for anaphoric references.)
+      c. (of an \term{implementation-defined} \term{attribute} of a \term{character})
+	 An \term{object} to which the value of that \term{attribute} defaults 
+	 if no specific value was requested.
+  2. \Noun\ an \term{object} \oftype{null} (the only such \term{object} being \nil).
+
+%!!! Moon: Is this correct?  has global bindings.  what about declarations?
+\gentry{null lexical environment} \Noun\ 
+  the \term{lexical environment} which has no \term{bindings}.
+
+\gentry{number} \Noun\
+  an \term{object} \oftype{number}.
+
+\gentry{numeric} \Adjective\ (of a \term{character})
+     being one of the \term{standard characters} \f{0} through \term{9},
+  or being some other \term{graphic} \term{character}
+     defined by the \term{implementation} to be \term{numeric}.
+
+\indextab{O}
+
+\gentry{object} \Noun\ 
+  1. any Lisp datum. 
+     \gexample{The function \funref{cons} creates an object which refers
+               to two other objects.}
+  2. (immediately following the name of a \term{type})
+     an \term{object} which is of that \term{type}, used to emphasize that the
+     \term{object} is not just a \term{name} for an object of that \term{type}
+     but really an \term{element} of the \term{type} in cases where \term{objects}
+     of that \term{type} (such as \typeref{function} or \typeref{class}) are commonly
+     referred to by \term{name}.
+     \gexample{The function \funref{symbol-function} takes a function name 
+	       and returns a function object.}
+
+\gentry{object-traversing} \Adjective\ 
+  operating in succession on components of an \term{object}.
+  \gexample{The operators \funref{mapcar}, \funref{maphash}, 
+	    \macref{with-package-iterator} and \funref{count}
+ 	    perform object-traversing operations.}
+
+\gentry{open} \Adjective, \TransitiveVerb\ (a \term{file})
+  1. \TransitiveVerb\ to create and return a \term{stream} to the \term{file}.
+  2. \Adjective\ (of a \term{stream})
+     having been \term{opened}\meaning{1}, but not yet \term{closed}.
+
+\gentry{operator} \Noun\ 
+  1. a \term{function}, \term{macro}, or \term{special operator}.
+  2. a \term{symbol} that names
+     such a \term{function}, \term{macro}, or \term{special operator}.
+  3. (in a \specref{function} \term{special form})
+     the \term{cadr} of the \specref{function} \term{special form}, which 
+     might be either an \term{operator}\meaning{2} or a \term{lambda expression}.
+%Barmar thinks that since operator(2) says "symbol" this last is unnecessary and confusing.
+%KMP disagrees because "lambda expression" is added here.
+  4. (of a \term{compound form})
+     the \term{car} of the \term{compound form}, which might be 
+     either an \term{operator}\meaning{2}
+%Moon asked whether this was permitted to include function objects,
+%but I don't think so.  Barmar and Barrett also expressed that sentiment
+%in mail to Quinquevirate (subject line "#'#.#'car").  
+%No one took the alternate viewpoint. -kmp 14-Nov-91
+     or a \term{lambda expression}, and which is never \f{(setf \term{symbol})}.
+
+\gentry{optimize quality} \Noun\ 
+  one of several aspects of a program that might be optimizable by
+  certain compilers.  Since optimizing one such quality
+  might conflict with optimizing another, relative priorities for
+  qualities can be established in an \declref{optimize} \term{declaration}.
+  The \term{standardized} \term{optimize qualities} are
+    \f{compilation-speed} (speed of the compilation process), 
+\issue{OPTIMIZE-DEBUG-INFO:NEW-QUALITY}
+    \f{debug} (ease of debugging),
+\endissue{OPTIMIZE-DEBUG-INFO:NEW-QUALITY}%
+    \f{safety} (run-time error checking),
+    \f{space} (both code size and run-time space),
+  and
+    \f{speed} (of the object code).
+  \term{Implementations} may define additional \term{optimize qualities}.
+
+\gentry{optional parameter} \Noun\
+  A \term{parameter} for which a corresponding positional \term{argument}
+  is optional.  If the \term{argument} is not supplied, a default value
+  is used.  \SeetermAlso{supplied-p parameter}.
+
+\gentry{ordinary function} \Noun\ 
+  a \term{function} that is not a \term{generic function}.
+
+\gentry{ordinary lambda list} \Noun\ 
+  the kind of \term{lambda list} used by \misc{lambda}.
+  \Seeterm{modified lambda list} and \term{extended lambda list}.
+  \gexample{\macref{defun} uses an ordinary lambda list.}
+
+\gentry{otherwise inaccessible part} \Noun\ (of an \term{object}, $O\sub{1}$)
+  an \term{object}, $O\sub{2}$, which would be made \term{inaccessible} if 
+  $O\sub{1}$ were made \term{inaccessible}.  (Every \term{object} is an
+  \term{otherwise inaccessible part} of itself.)
+
+\gentry{output} \Adjective\ (of a \term{stream})
+  supporting output operations (\ie being a ``data sink'').
+  An \term{output} \term{stream} might also be an \term{input} \term{stream},
+  in which case it is sometimes called a \term{bidirectional} \term{stream}.
+  \Seefun{output-stream-p}.
+
+\indextab{P}
+ 
+\gentry{package} \Noun\ 
+  an \term{object} \oftype{package}.
+
+%!!! Moon: "interned" means "accessible" according to the glossary, but I thought
+%          a symbol was supposed to be "present" in its home package.  Maybe I'm wrong.
+\gentry{package cell} \Noun\ \Traditional\ (of a \term{symbol})
+  The \term{place} in a \term{symbol} that holds one of
+  possibly several \term{packages} in which the \term{symbol} is 
+  \term{interned}, called the \term{home package}, or which holds
+  \nil\ if no such \term{package} exists or is known.
+  \Seefun{symbol-package}.
+
+\gentry{package designator} \Noun\
+  a \term{designator} for a \term{package}; that is,
+  an \term{object} that denotes a \term{package}
+  and that is one of:
+      a \term{\packagenamedesignator} 
+		      (denoting the \term{package} that has the \term{string}
+		       that it designates as its \term{name} 
+		       or as one of its \term{nicknames}),
+   or a \term{package} (denoting itself).
+
+\gentry{package marker} \Noun\ 
+  a character which is used in the textual notation for a symbol 
+  to separate the package name from the symbol name, and which
+  is \term{colon} in the \term{standard readtable}.
+  \Seesection\CharacterSyntax.
+
+% \gentry{package name designator} \Noun\
+%   a \term{designator} for the \term{name} of a \term{package}; that is,
+%   an \term{object} that denotes a \term{string} 
+%   and that is one of:
+%        a \term{character} (denoting a \term{singleton} \term{string}
+% 			   that has the \term{character} as its only \term{element}),
+%        a \term{symbol} (denoting the \term{string} that is its \term{name}),
+%     or a \term{string} (denoting itself).
+
+\gentry{package prefix} \Noun\ 
+  a notation preceding the \term{name} of a \term{symbol} in text that is
+  processed by the \term{Lisp reader}, which uses a \term{package} \term{name}
+  followed by one or more \term{package markers}, and which indicates that
+  the symbol is looked up in the indicated \term{package}.
+
+%!!! Moon: Is DO-ALL-SYMBOLS really -required- not to find symbols in unregistered packages?
+\gentry{package registry} \Noun\
+  A mapping of \term{names} to \term{package} \term{objects}.
+  It is possible for there to be a \term{package} \term{object} which is not
+  in this mapping; such a \term{package} is called an \term{unregistered package}.
+  \term{Operators} such as \funref{find-package} consult this mapping in order
+  to find a \term{package} from its \term{name}.
+  \term{Operators} such as \macref{do-all-symbols}, \funref{find-all-symbols}, 
+  and \funref{list-all-packages} operate only on \term{packages} that exist
+  in the \term{package registry}.
+
+\gentry{pairwise} \Adverb\ (of an adjective on a set)
+  applying individually to all possible pairings of elements of the set.
+  \gexample{The types $A$, $B$, and $C$ are pairwise disjoint if 
+            $A$ and $B$ are disjoint,
+            $B$ and $C$ are disjoint, and
+            $A$ and $C$ are disjoint.}
+
+%!!! This needs work but should be better than nothing for now. -kmp 13-Feb-92
+\gentry{parallel} \Adjective\ \Traditional\ (of \term{binding} or \term{assignment})
+  done in the style of \macref{psetq}, \macref{let}, or \macref{do};
+  that is, first evaluating all of the \term{forms} that produce \term{values},
+  and only then \term{assigning} or \term{binding} the \term{variables} (or \term{places}).
+  Note that this does not imply traditional computational ``parallelism'' 
+  since the \term{forms} that produce \term{values} are evaluated \term{sequentially}.
+  \Seeterm{sequential}.
+
+\gentry{parameter} \Noun\ 
+  1. (of a \term{function})
+     a \term{variable} in the definition of a \term{function}
+       which takes on the \term{value} of a corresponding \term{argument}
+       (or of a \term{list} of corresponding arguments)
+       to that \term{function} when it is called,
+     or
+       which in some cases is given a default value because there
+       is no corresponding \term{argument}.
+  2. (of a \term{format directive})
+%Moon thinks "as data flow" is awkward.  I don't know what to substitute. -kmp 15-Nov-91
+     an \term{object} received as data flow by a \term{format directive}
+     due to a prefix notation within the \term{format string} at the 
+     \term{format directive}'s point of use.
+     \Seesection\FormattedOutput.
+     \gexample{In \f{"~3,'0D"}, the number \f{3} and the character
+	       \f{\#\\0} are parameters to the \f{~D} format directive.}
+
+\gentry{parameter specializer} \Noun\ 
+  1. (of a \term{method}) an \term{expression} which constrains the
+     \term{method} to be applicable only to \term{argument} sequences
+     in which the corresponding \term{argument} matches the
+     \term{parameter specializer}.
+  2. a \term{class},
+     or a \term{list} \f{(eql \term{object})}.
+
+\gentry{parameter specializer name} \Noun\ 
+  1. (of a \term{method} definition) an expression used in code to
+     name a \term{parameter specializer}. 
+     \Seesection\IntroToMethods.
+  2. a \term{class},
+\issue{CLASS-OBJECT-SPECIALIZER:AFFIRM}
+     a \term{symbol} naming a \term{class},
+\endissue{CLASS-OBJECT-SPECIALIZER:AFFIRM}
+     or a \term{list} \f{(eql \term{form})}.
+
+\gentry{pathname} \Noun\ 
+  an \term{object} \oftype{pathname}, which is a structured representation 
+  of the name of a \term{file}.  A \term{pathname} has six components:
+    a ``host,''
+    a ``device,''
+    a ``directory,''
+    a ``name,''
+    a ``type,'' and
+    a ``version.''
+
+\gentry{pathname designator} \Noun\
+  a \term{designator} for a \term{pathname}; that is,
+  an \term{object} that denotes a \term{pathname}
+  and that is one of:
+\issue{PATHNAME-LOGICAL:ADD}
+       a \term{pathname} \term{namestring} 
+\issue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+%          (denoting the corresponding \term{pathname};
+% 	  unless explicitly specified otherwise,
+%           only a \term{physical pathname} \term{namestring} is required
+%           to be recognized by an \term{implementation} as 
+%           a \term{pathname designator}---whether
+%           or not a \term{logical pathname} \term{namestring} is
+%           permitted as a \term{pathname designator} is 
+%           \term{implementation-defined}),
+           (denoting the corresponding \term{pathname}),
+\endissue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+\endissue{PATHNAME-LOGICAL:ADD}
+       a \term{stream associated with a file} 
+%% 23.1.2 32
+         (denoting the \term{pathname} used to open the \term{file};
+	  this may be, but is not required to be, the actual name of the \term{file}),
+    or a \term{pathname} (denoting itself).
+  \Seesection\OpenAndClosedStreams.
+
+% \editornote{KMP: `Pervasive' is still used, but isn't it supposed to be getting phased out?}
+% 
+% \gentry{pervasive} \Noun\
+%   ... needs a definition...
+
+\gentry{physical pathname} \Noun\
+  a \term{pathname} that is not a \term{logical pathname}.
+
+\editornote{KMP: Still need to reconcile some confusion in the uses of ``generalized
+		 reference'' and ``place.'' I think one was supposed to refer to the
+	         abstract concept, and the other to an object (a form), but the usages
+		 have become blurred.}
+%Moon: I have no opinion.
+
+\gentry{place} \Noun\ 
+  1. a \term{form} which is suitable for use as a \term{generalized reference}.
+  2. the conceptual location referred to by such a \term{place}\meaning{1}.
+
+\gentry{plist} \pronounced{\Stress{p\harde}\stress{list}} \Noun\ 
+  a \term{property list}.
+
+\gentry{portable} \Adjective\ (of \term{code})
+  required to produce equivalent results and observable side effects
+  in all \term{conforming implementations}.
+
+\gentry{potential copy} \Noun\ (of an \term{object} $O\sub 1$ subject to constriants)
+  an \term{object} $O\sub 2$ that if the specified constraints are satisfied
+  by $O\sub 1$ without any modification might or might not be \term{identical}
+  to $O\sub 1$, or else that must be a \term{fresh} \term{object} that
+  resembles a \term{copy} of $O\sub 1$ except that it has been modified as
+  necessary to satisfy the constraints.
+
+\gentry{potential number} \Noun\ 
+  A textual notation that might be parsed by the \term{Lisp reader} 
+  in some \term{conforming implementation} as a \term{number} 
+  but is not required to be parsed as a \term{number}.
+  No \term{object} is a \term{potential number}---either an \term{object} is
+  a \term{number} or it is not.
+  \Seesection\PotentialNumbersAsTokens.
+
+\gentry{pprint dispatch table} \Noun\ 
+  an \term{object} that can be \thevalueof{*print-pprint-dispatch*} 
+  and hence can control how \term{objects} are printed when
+  \varref{*print-pretty*} is \term{true}.
+  \Seesection\PPrintDispatchTables.
+
+\gentry{predicate} \Noun\ 
+  a \term{function} that returns a \term{generalized boolean}
+  as its first value.
+
+\gentry{present} \Noun\
+  1. (of a \term{feature} in a \term{Lisp image})
+     a state of being that is in effect if and only if the \term{symbol} 
+     naming the \term{feature} is an \term{element} of the \term{features list}.
+  2. (of a \term{symbol} in a \term{package})
+     being accessible in that \term{package} directly,
+     rather than being inherited from another \term{package}.
+
+\gentry{pretty print} \TransitiveVerb\ (an \term{object})
+  to invoke the \term{pretty printer} on the \term{object}.
+
+% Waters observes:
+%  In most places the text talks about the pretty printer either being used or not.
+%  However, it is not all that clear what the pretty printer per se is.  In the
+%  description of *print-pprint-dispatch* I think that it makes it pretty clear that
+%  what pretty printer means is that printing is controled by *print-pprint-dispatch*.
+%  And in fact I believe that this is in fact all it means.  You can put a value in
+%  *print-pprint-dispatch* that makes pretty printing look exactly like 
+%  non-pretty-printing after all.  Therefore, I think it would be an overall
+%  clarification to say more often that setting *print-pretty* to true means having
+%  *print-pprint-dispatch* control printing---nothing more and nothing less.
+\gentry{pretty printer} \Noun\ 
+  the procedure that prints the character representation of an
+  \term{object} onto a \term{stream} when the \term{value} of
+  \varref{*print-pretty*} is \term{true}, 
+  and that uses layout techniques (\eg indentation) that
+  tend to highlight the structure of the \term{object} in a way that
+  makes it easier for human readers to parse visually.
+  \Seevar{*print-pprint-dispatch*} and \secref\PPrinter.
+
+\gentry{pretty printing stream} \Noun\ 
+  a \term{stream} that does pretty printing.  Such streams are created by
+  \thefunction{pprint-logical-block} as a link between the output stream 
+  and the logical block.
+
+\gentry{primary method} \Noun\ 
+  a member of one of two sets of \term{methods} 
+  (the set of \term{auxiliary methods} is the other)
+  that form an exhaustive partition of the set of \term{methods}
+  on the \term{method}'s \term{generic function}.
+  How these sets are determined is dependent on the \term{method combination} type;
+  \seesection\IntroToMethods.
+
+\gentry{primary value} \Noun\ (of \term{values} resulting from the
+				   \term{evaluation} of a \term{form})
+  the first \term{value}, if any, or else \nil\ if there are no \term{values}.
+  \gexample{The primary value returned by \funref{truncate} is an
+            integer quotient, truncated toward zero.}
+
+\gentry{principal} \Adjective\ (of a value returned by a \clisp\ \term{function} that
+			        implements a mathematically irrational or transcendental 
+		                function defined in the complex domain)
+  of possibly many (sometimes an infinite number of) correct values for the
+  mathematical function, being the particular \term{value} which the corresponding
+  \clisp\ \term{function} has been defined to return.
+
+\gentry{print name} \Noun\ \Traditional\ (usually of a \term{symbol})
+  a \term{name}\meaning{3}.
+
+\gentry{printer control variable} \Noun\ 
+  a \term{variable} whose specific purpose is to control some action
+  of the \term{Lisp printer}; that is, one of the \term{variables}
+  in \figref\StdPrinterControlVars,
+  or else some \term{implementation-defined} \term{variable} which is
+     defined by the \term{implementation} to be a \term{printer control variable}.
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+\gentry{printer escaping} \Noun\
+  The combined state of the \term{printer control variables}
+  \varref{*print-escape*} and \varref{*print-readably*}.
+  If the value of either \varref{*print-readably*} or \varref{*print-escape*} is \term{true}, 
+  then \newterm{printer escaping} is ``enabled'';
+  otherwise (if the values of both \varref{*print-readably*} and \varref{*print-escape*}
+	     are \term{false}), 
+  then \term{printer escaping} is ``disabled''.
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+
+\gentry{printing} \Adjective\ (of a \term{character})
+  being a \term{graphic} \term{character} other than \term{space}.
+
+\gentry{process} \TransitiveVerb\ (a \term{form} by the \term{compiler})
+  to perform \term{minimal compilation}, determining the time of 
+  evaluation for a \term{form}, and possibly \term{evaluating} that
+  \term{form} (if required).
+
+\gentry{processor} \Noun, \ANSI\
+  an \term{implementation}.
+
+\gentry{proclaim} \TransitiveVerb\ (a \term{proclamation})
+  to \term{establish} that \term{proclamation}.
+
+\gentry{proclamation} \Noun\ 
+  a \term{global declaration}.
+
+\gentry{prog tag} \Noun\ \Traditional\ 
+  a \term{go tag}.
+
+\gentry{program} \Noun\ \Traditional\ 
+  \clisp\ \term{code}.
+
+\gentry{programmer} \Noun\
+  an active entity, typically a human, that writes a \term{program},
+  and that might or might not also be a \term{user} of the \term{program}.
+
+\gentry{programmer code} \Noun\ 
+  \term{code} that is supplied by the programmer;
+  that is, \term{code} that is not \term{system code}.
+
+\gentry{proper list} \Noun\ 
+  A \term{list} terminated by the \term{empty list}.
+  (The \term{empty list} is a \term{proper list}.)
+  \Seeterm{improper list}.
+
+\gentry{proper name} \Noun\ (of a \term{class})
+  a \term{symbol} that \term{names} the \term{class} whose \term{name}
+  is that \term{symbol}. 
+  \Seefuns{class-name} and \funref{find-class}.
+ 
+\gentry{proper sequence} \Noun\ 
+  a \term{sequence} which is not an \term{improper list}; 
+  that is, a \term{vector} or a \term{proper list}.
+ 
+% Moon: proper subtype -- I don't understand the parenthesized phrase, perhaps not
+%  only because I believe types have members, not elements.
+\gentry{proper subtype} \Noun\ (of a \term{type})
+  a \term{subtype} of the \term{type} which is not the \term{same} \term{type}
+  as the \term{type} (\ie its \term{elements} are a ``proper subset'' of the 
+  \term{type}).
+ 
+\gentry{property} \Noun\ (of a \term{property list})
+  1. a conceptual pairing of a \term{property indicator} and its
+     associated \term{property value} on a \term{property list}.
+  2. a \term{property value}.
+%%Barmar says he's never heard this usage. -kmp -11-Dec-90
+% 3. a \term{property indicator}.
+
+\gentry{property indicator} \Noun\ (of a \term{property list}) 
+  the \term{name} part of a \term{property}, used as a \term{key}
+  when looking up a \term{property value} on a \term{property list}. 
+ 
+\gentry{property list} \Noun\ 
+\issue{PLIST-DUPLICATES:ALLOW}
+  1.  a \term{list} containing an even number of \term{elements} that are
+      alternating \term{names}  (sometimes called \term{indicators} 
+      or \term{keys}) and \term{values} (sometimes called \term{properties}).
+      When there is more than one \term{name} and \term{value} pair with
+      the \term{identical} \term{name} in a \term{property list},
+      the first such pair determines the \term{property}.
+\endissue{PLIST-DUPLICATES:ALLOW}
+  2. (of a \term{symbol})
+     the component of the \term{symbol} containing a \term{property list}.
+
+\issue{PLIST-DUPLICATES:ALLOW}
+% \gentry{property list format} \Noun\ 
+%   the form of a property list, having an even number of \term{elements}
+%   that are alternating \term{names} and \term{values}, but without the
+%   implied restriction that no \term{keys} be duplicated.
+%   \gexample{When \keyref{key} is used in a lambda list, the corresponding keyword
+% 	    arguments are specified in property list format.}
+\endissue{PLIST-DUPLICATES:ALLOW}
+
+\gentry{property value} \Noun\ (of a \term{property indicator} on 
+				  a \term{property list})
+  the \term{object} associated with the \term{property indicator}
+  on the \term{property list}.
+
+\gentry{purports to conform} \Verb\
+  makes a good-faith claim of conformance.  
+  This term expresses intention to conform, regardless of whether the
+  goal of that intention is realized in practice.  
+  For example, language implementations have been known to have bugs,
+  and while an \term{implementation} of this specification with bugs
+  might not be a \term{conforming implementation}, it can still
+  \term{purport to conform}.  This is an important distinction in
+  certain specific cases; \eg \seevar{*features*}.
+
+\indextab{Q}
+
+\gentry{qualified method} \Noun\ 
+  a \term{method} that has one or more \term{qualifiers}.
+
+%Maybe this should be called a method qualifier? -kmp
+\gentry{qualifier} \Noun\ (of a \term{method} for a \term{generic function})
+  one of possibly several \term{objects} used to annotate the \term{method} 
+  in a way that identifies its role in the \term{method combination}.  
+  The \term{method combination} \term{type} determines 
+   how many \term{qualifiers} are permitted for each \term{method}, 
+   which \term{qualifiers} are permitted,
+  and
+   the semantics of those \term{qualifiers}.
+
+%qualifier list?
+
+\gentry{query I/O} \Noun\ 
+  the \term{bidirectional} \term{stream}
+  that is the \term{value} of \thevariable{*query-io*}.
+
+\gentry{quoted object} \Noun\ 
+  an \term{object} which is the second element of a
+  \specref{quote} \term{form}.
+
+\indextab{R}
+ 
+\gentry{radix} \Noun\
+  an \term{integer} between 2 and 36, inclusive, which can be used 
+  to designate a base with respect to which certain kinds of numeric
+  input or output are performed.  
+%% 13.2.0 20
+  (There are $n$ valid digit characters for any given \term{radix} $n$,
+   and those digits are the first $n$ digits in the sequence
+   \f{0}, \f{1}, $\ldots$, \f{9}, \f{A}, \f{B}, $\ldots$, \f{Z},
+   which have the weights   
+   \f{0}, \f{1}, $\ldots$, \f{9}, \f{10}, \f{11}, $\ldots$, \f{35},
+   respectively.
+   Case is not significant in parsing numbers of radix greater
+   than \f{10}, so ``9b8a'' and ``9B8A'' denote the same \term{radix}
+   \f{16} number.)
+
+\gentry{random state} \Noun\ 
+  an \term{object} \oftype{random-state}.
+
+\gentry{rank} \Noun\ 
+  a non-negative \term{integer} indicating the number of
+  \term{dimensions} of an \term{array}.
+ 
+\gentry{ratio} \Noun\ 
+  an \term{object} \oftype{ratio}.
+
+\gentry{ratio marker} \Noun\ 
+  a character which is used in the textual notation for a \term{ratio}
+  to separate the numerator from the denominator, and which
+  is \term{slash} in the \term{standard readtable}.
+  \Seesection\CharacterSyntax.
+
+\gentry{rational} \Noun\ 
+  an \term{object} \oftype{rational}.
+ 
+\gentry{read} \TransitiveVerb\ 
+\issue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+  1. (a \term{binding} or \term{slot} or component)
+     to obtain the \term{value} of the \term{binding} or \term{slot}.
+\endissue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+  2. (an \term{object} from a \term{stream})
+     to parse an \term{object} from its representation on the \term{stream}.
+
+%% There were no actual uses of this. -kmp 18-Jan-92
+% \gentry{read macro} \Noun\ \Traditional\
+%   a \term{reader macro}.
+
+%% KMP: Maybe...
+% \gentry{readable} \Adjective\ (of the printed representation of an \term{object})
+%   printed \term{readably}.
+
+\gentry{readably} \Adverb\ (of a manner of printing an \term{object} $O\sub 1$)
+  in such a way as to permit the \term{Lisp Reader} to later \term{parse}
+  the printed output into an \term{object} $O\sub 2$ that is \term{similar} to $O\sub 1$.
+
+\gentry{reader} \Noun\
+  1. a \term{function} that \term{reads}\meaning{1} a \term{variable} or \term{slot}.
+  2. the \term{Lisp reader}.
+
+\gentry{reader macro} \Noun\
+  1. a textual notation introduced by dispatch on one or two \term{characters} 
+     that defines special-purpose syntax for use by the \term{Lisp reader},
+     and that is implemented by a \term{reader macro function}.
+     \Seesection\ReaderAlgorithm.
+  2. the \term{character} or \term{characters} that introduce
+     a \term{reader macro}\meaning{1}; that is,
+        a \term{macro character}
+     or the conceptual pairing of a \term{dispatching macro character} and the
+          \term{character} that follows it.
+  (A \term{reader macro} is not a kind of \term{macro}.)
+
+\gentry{reader macro function} \Noun\
+  a \term{function} \term{designator} that denotes a \term{function}
+  that implements a \term{reader macro}\meaning{2}.
+  \Seefuns{set-macro-character} and \funref{set-dispatch-macro-character}.
+
+\gentry{readtable} \Noun\
+  an \term{object} \oftype{readtable}.
+
+\gentry{readtable case} \Noun\
+  an attribute of a \term{readtable}
+  whose value is a \term{case sensitivity mode},
+  and that selects the manner in which \term{characters}
+       in a \term{symbol}'s \term{name} are to be treated by
+            the \term{Lisp reader}
+        and the \term{Lisp printer}.
+  \Seesection\ReadtableCaseReadEffect\ and \secref\ReadtableCasePrintEffect.
+
+\gentry{readtable designator} \Noun\
+  a \term{designator} for a \term{readtable}; that is,
+  an \term{object} that denotes a \term{readtable}
+  and that is one of:
+       \nil\ (denoting the \term{standard readtable}),
+    or a \term{readtable} (denoting itself).
+
+\gentry{recognizable subtype} \Noun\ (of a \term{type})
+  a \term{subtype} of the \term{type} which can be reliably detected 
+  to be such by the \term{implementation}.
+  \Seefun{subtypep}.
+
+\gentry{reference} \Noun, \TransitiveVerb\ 
+  1. \Noun\ an act or occurrence of referring to an \term{object},
+     a \term{binding}, an \term{exit point}, a \term{tag}, 
+     or an \term{environment}.
+%But what does "refer" mean?
+  2. \TransitiveVerb\ to refer to an \term{object}, a \term{binding}, an
+     \term{exit point}, a \term{tag}, or an \term{environment},
+     usually by \term{name}.
+
+\gentry{registered package} \Noun\
+  a \term{package} \term{object} that is installed in the \term{package registry}.
+  (Every \term{registered package} has a \term{name} that is a \term{string},
+   as well as zero or more \term{string} nicknames.
+   All \term{packages} that are initially specified by \clisp\ 
+   or created by \funref{make-package} or \macref{defpackage}
+   are \term{registered packages}.  \term{Registered packages} can be turned into
+   \term{unregistered packages} by \funref{delete-package}.)
+
+\gentry{relative} \Adjective\
+  1. (of a \term{time})
+     representing an offset from an \term{absolute} \term{time}
+     in the units appropriate to that time.
+     For example, 
+     a \term{relative} \term{internal time} is the difference between
+     two \term{absolute} \term{internal times}, and is measured in
+     \term{internal time units}.
+  2. (of a \term{pathname})
+     representing a position in a directory hierarchy by motion 
+     from a position other than the root, which might therefore vary.
+     \gexample{The notation \f{\#P"../foo.text"} denotes a relative
+	       pathname if the host file system is Unix.}
+  \Seeterm{absolute}.
+
+\gentry{repertoire} \Noun, \ISO\
+  a \term{subtype} of \typeref{character}.  \Seesection\CharRepertoires.
+
+\gentry{report} \Noun\ (of a \term{condition})
+  to \term{call} \thefunction{print-object} on the \term{condition} 
+  in an \term{environment} where \thevalueof{*print-escape*} is \term{false}.
+
+\gentry{report message} \Noun\
+  the text that is output by a \term{condition reporter}.
+
+\gentry{required parameter} \Noun\
+  A \term{parameter} for which a corresponding positional \term{argument}
+  must be supplied when \term{calling} the \term{function}.
+
+\gentry{rest list} \Noun\ (of a \term{function} having a \term{rest parameter})
+  The \term{list} to which the \term{rest parameter} is \term{bound} on some
+  particular \term{call} to the \term{function}.
+
+\gentry{rest parameter} \Noun\
+  A \term{parameter} which was introduced by \keyref{rest}.
+
+\gentry{restart} \Noun\ 
+  an \term{object} \oftype{restart}.
+
+\gentry{restart designator} \Noun\
+  a \term{designator} for a \term{restart}; that is,
+  an \term{object} that denotes a \term{restart}
+  and that is one of:
+       a \term{non-nil} \term{symbol} 
+	 (denoting the most recently established \term{active}
+	  \term{restart} whose \term{name} is that \term{symbol}),
+    or a \term{restart} (denoting itself).
+
+\gentry{restart function} \Noun\
+  a \term{function} that invokes a \term{restart}, as if by \funref{invoke-restart}.
+  The primary purpose of a \term{restart function} is to provide an alternate
+  interface. By convention, a \term{restart function} usually has the same name 
+  as the \term{restart} which it invokes. \Thenextfigure\ shows a list of the
+  \term{standardized} \term{restart functions}.
+
+\displaythree{Standardized Restart Functions}{
+abort&muffle-warning&use-value\cr
+continue&store-value&\cr
+}
+
+\gentry{return} \TransitiveVerb\ (of \term{values})
+  1. (from a \term{block}) to transfer control and \term{values} from the \term{block};
+     that is, to cause the \term{block} to \term{yield} the \term{values} immediately
+     without doing any further evaluation of the \term{forms} in its body.
+  2. (from a \term{form}) to \term{yield} the \term{values}.
+
+\gentry{return value} \Noun\ \Traditional\ 
+  a \term{value}\meaning{1}
+
+\gentry{right-parenthesis} \Noun\
+  the \term{standard character} ``\f{)}'',
+  that is variously called
+      ``right parenthesis''
+   or ``close parenthesis''
+  \Seefigure\StdCharsThree.
+
+%% No longer needed as a glossary term. \Seesection\RuleOfCanonRepForComplexRationals.
+%%   -kmp
+%
+% %Moon says:
+% % rule of canonical representation for complex rationals -- you forgot to say the
+% % real part has to be rational.  Compare CLtL2 p.291.
+% \gentry{rule of canonical representation for complex rationals} \Noun\ 
+%   a requirement by \clisp\ on \term{conforming implementations} that all 
+%   numbers representing mathematical complex numbers with an imaginary part 
+%   of rational zero be represented by \clisp\ as \term{objects} \oftype{rational}
+%   rather than as \term{objects} \oftype{complex}.
+
+\gentry{run time} \Noun\
+  1. \term{load time}
+  2. \term{execution time}
+
+\gentry{run-time compiler} \Noun\
+  refers to the \funref{compile} function or to \term{implicit compilation}, 
+  for which the compilation and run-time \term{environments} are maintained 
+  in the same \term{Lisp image}.
+
+\gentry{run-time definition} \Noun\
+  a definition in the \term{run-time environment}.
+
+\gentry{run-time environment} \Noun\
+  the \term{environment} in which a program is \term{executed}.
+
+\indextab{S}
+ 
+\gentry{safe} \Adjective\ 
+  1. (of \term{code})
+     processed in a \term{lexical environment} where the the highest
+     \declref{safety} level (\f{3}) was in effect. 
+     \Seemisc{optimize}.
+  2. (of a \term{call}) a \term{safe call}.
+
+\gentry{safe call} \Noun\
+  a \term{call} in which 
+        the \term{call},
+        the \term{function} being \term{called},
+    and the point of \term{functional evaluation}
+  are all \term{safe}\meaning{1} \term{code}.
+  For more detailed information, \seesection\SafeAndUnsafeCalls.
+
+\gentry{same} \Adjective\ 
+  1. (of \term{objects} under a specified \term{predicate}) 
+     indistinguishable by that \term{predicate}.
+     \gexample{The symbol \f{car}, the string \f{"car"}, and the string \f{"CAR"}
+	       are the \f{same} under \funref{string-equal}}.
+  2. (of \term{objects} if no predicate is implied by context)
+     indistinguishable by \funref{eql}.
+     Note that \funref{eq} might be capable of distinguishing some 
+     \term{numbers} and \term{characters} which \funref{eql} cannot 
+     distinguish, but the nature of such, if any, 
+     is \term{implementation-dependent}.
+     Since \funref{eq} is used only rarely in this specification,
+     \funref{eql} is the default predicate when none is mentioned explicitly.
+     \gexample{The conses returned by two successive calls to \funref{cons}
+	       are never the same.}
+  3. (of \term{types}) having the same set of \term{elements};
+     that is, each \term{type} is a \term{subtype} of the others.
+     \gexample{The types specified by \f{(integer 0 1)},
+				      \f{(unsigned-byte 1)},
+				  and \f{bit} are the same.}
+
+\gentry{satisfy the test} \Verb\ 
+       (of an \term{object} being considered by a \term{sequence function})
+  1. (for a one \term{argument} test)
+     to be in a state such that the \term{function} which is the
+     \param{predicate} \term{argument} to the \term{sequence function}
+     returns \term{true} when given a single \term{argument} that is the
+     result of calling the \term{sequence function}'s \param{key} \term{argument}
+     on the \term{object} being considered.  
+     \Seesection\SatisfyingTheOneArgTest.
+%!!! Moon: Shouldn't the test-not predicate return false to satisfy the test?
+%          Also, sometimes both arguments are run through the key,
+%          e.g., search, mismatch; you're perhaps being too specific.
+  2. (for a two \term{argument} test)
+     to be in a state such that the two-place \term{predicate} 
+     which is the \term{sequence function}'s 
+     \param{test} \term{argument}
+     returns \term{true} when given a first \term{argument} that 
+     is
+%     the result of calling the \term{sequence function}'s 
+%     \param{key} \term{argument} on
+     the \term{object} being considered, 
+     and when given a second \term{argument}
+     that is the result of calling the \term{sequence function}'s 
+     \param{key} \term{argument} on an \term{element} of the
+     \term{sequence function}'s \param{sequence} \term{argument} 
+     which is being tested for equality;
+     or to be in a state such that the \param{test-not} \term{function}
+     returns \term{false} given the same \term{arguments}.
+     \Seesection\SatisfyingTheTwoArgTest.
+
+%!!! Moon: Can scope ever apply to anything but a name?
+%    I think objects and environments have extent but not scope.
+\gentry{scope} \Noun\ 
+  the structural or textual region of code in which \term{references} 
+  to an \term{object}, a \term{binding}, an \term{exit point}, 
+  a \term{tag}, or an \term{environment} (usually by \term{name}) 
+  can occur.
+
+\gentry{script} \Noun\ \ISO\
+  one of possibly several sets that form an \term{exhaustive partition}
+  of the type \typeref{character}.  \Seesection\CharScripts.
+
+\gentry{secondary value} \Noun\ (of \term{values} resulting from the
+				   \term{evaluation} of a \term{form})
+  the second \term{value}, if any, 
+  or else \nil\ if there are fewer than two \term{values}.
+  \gexample{The secondary value returned by \funref{truncate} is a remainder.}
+
+\gentry{section} \Noun\
+  a partitioning of output by a \term{conditional newline} on a \term{pretty printing stream}.
+  \Seesection\DynamicControlofOutput.
+
+\gentry{self-evaluating object} \Noun\
+  an \term{object} that is neither a \term{symbol} nor a
+% \term{compound form} => \term{cons} because Moon pointed out that
+% this wrongly seemed to permit things which were conses but not valid forms.
+  \term{cons}.
+  If a \term{self-evaluating object} is \term{evaluated},
+  it \term{yields} itself as its only \term{value}.
+  \gexample{Strings are self-evaluating objects.}
+
+\gentry{semi-standard} \Adjective\ (of a language feature)
+  not required to be implemented by any \term{conforming implementation},
+  but nevertheless recommended as the canonical approach in situations where
+  an \term{implementation} does plan to support such a feature.
+  The presence of \term{semi-standard} aspects in the language is intended
+  to lessen portability problems and reduce the risk of gratuitous divergence
+  among \term{implementations} that might stand in the way of future 
+  standardization.
+
+\gentry{semicolon} \Noun\
+  the \term{standard character} that is called ``semicolon'' (\f{;}).
+  \Seefigure\StdCharsThree.
+
+\gentry{sequence} \Noun\ 
+  1. an ordered collection of elements
+  2. a \term{vector} or a \term{list}.
+
+\gentry{sequence function} \Noun\
+  one of the \term{functions} in \figref\SequenceFunctions,
+  or an \term{implementation-defined} \term{function} 
+     that operates on one or more \term{sequences}.
+     and that is defined by the \term{implementation} to be a \term{sequence function}.
+
+%!!! This needs work but should be better than nothing for now. -kmp 13-Feb-92
+\gentry{sequential} \Adjective\ \Traditional\ (of \term{binding} or \term{assignment})
+  done in the style of \macref{setq}, \macref{let*}, or \macref{do*};
+  that is, interleaving the evaluation of the \term{forms} that produce \term{values}
+  with the \term{assignments} or \term{bindings} of the \term{variables} (or \term{places}).
+  \Seeterm{parallel}.
+
+\gentry{sequentially} \Adverb\
+  in a \term{sequential} way.
+
+\gentry{serious condition} \Noun\ 
+  a \term{condition} \oftype{serious-condition}, 
+  which represents a \term{situation} that is generally sufficiently 
+  severe that entry into the \term{debugger} should be expected if 
+  the \term{condition} is \term{signaled} but not \term{handled}.
+
+\gentry{session} \Noun\
+  the conceptual aggregation of events in a \term{Lisp image} from the time
+  it is started to the time it is terminated.
+
+\gentry{set} \TransitiveVerb\ \Traditional\ (any \term{variable}
+				     or a \term{symbol} that 
+				        is the \term{name} of a \term{dynamic variable})
+  to \term{assign} the \term{variable}.
+
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\gentry{setf expander} \Noun\ 
+  a function used by \macref{setf} to compute the \term{setf expansion}
+  of a \term{place}.
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\gentry{setf expansion} \Noun\ 
+  a set of five \term{expressions}\meaning{1} that, taken together, describe 
+       how to store into a \term{place} 
+   and which \term{subforms} of the macro call associated with the
+       \term{place} are evaluated.
+  \Seesection\SetfExpansions.
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+ 
+\gentry{setf function} \Noun\
+  a \term{function} whose \term{name} is \f{(setf \term{symbol})}.
+
+\issue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+\gentry{setf function name} \Noun\ (of a \term{symbol} \param{S})
+  the \term{list} \f{(setf \param{S})}.
+\endissue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+
+\gentry{shadow} \TransitiveVerb\ 
+  1. to override the meaning of.
+     \gexample{That binding of \f{X} shadows an outer one.} 
+  2. to hide the presence of.
+     \gexample{That \specref{macrolet} of \f{F} shadows the
+               outer \specref{flet} of \f{F}.}
+  3. to replace.
+     \gexample{That package shadows the symbol \f{cl:car} with
+               its own symbol \f{car}.}
+
+\gentry{shadowing symbol} \Noun\ (in a \term{package})
+  an \term{element} of the \term{package}'s \term{shadowing symbols list}.
+
+\gentry{shadowing symbols list} \Noun\ (of a \term{package})
+  a \term{list}, associated with the \term{package}, 
+  of \term{symbols} that are to be exempted from `symbol conflict errors'
+  detected when packages are \term{used}.
+  \Seefun{package-shadowing-symbols}.
+
+\gentry{shared slot} \Noun\ (of a \term{class}) 
+  a \term{slot} \term{accessible} in more than one \term{instance} 
+  of a \term{class}; specifically, such a \term{slot} is \term{accessible}
+  in all \term{direct instances} of the \term{class} and in those 
+  \term{indirect instances} whose \term{class} does not 
+  \term{shadow}\meaning{1} the \term{slot}.
+ 
+\gentry{sharpsign} \Noun\
+  the \term{standard character} that is variously called ``number sign,'' ``sharp,''
+  or ``sharp sign'' (\f{\#}).
+  \Seefigure\StdCharsThree.
+
+\gentry{short float} \Noun\ 
+  an \term{object} \oftype{short-float}.
+
+\gentry{sign} \Noun\ 
+  one of the \term{standard characters} ``\f{+}'' or ``\f{-}''.
+
+\gentry{signal} \Verb\ 
+  to announce, using a standard protocol, that a particular situation,
+  represented by a \term{condition}, has been detected.  
+  \Seesection\ConditionSystemConcepts.
+
+\gentry{signature} \Noun\ (of a \term{method})
+  a description of the \term{parameters} and
+  \term{parameter specializers} for the \term{method} which 
+  determines the \term{method}'s applicability for a given set of
+  required \term{arguments}, and which also describes the
+  \term{argument} conventions for its other, non-required 
+  \term{arguments}.
+
+\gentry{similar} \Adjective\ (of two \term{objects})
+  defined to be equivalent under the \term{similarity} relationship.
+
+\gentry{similarity} \Noun\
+  a two-place conceptual equivalence predicate, 
+  which is independent of the \term{Lisp image} 
+  so that two \term{objects} in different \term{Lisp images} 
+  can be understood to be equivalent under this predicate.
+  \Seesection\LiteralsInCompiledFiles.
+
+\gentry{simple} \Adjective\
+  1. (of an \term{array}) being \oftype{simple-array}.
+  2. (of a \term{character})
+     having no \term{implementation-defined} \term{attributes},
+     or else having \term{implementation-defined} \term{attributes}
+      each of which has the \term{null} value for that \term{attribute}.
+
+\gentry{simple array} \Noun\ 
+  an \term{array} \oftype{simple-array}.
+
+\gentry{simple bit array} \Noun\
+  a \term{bit array} that is a \term{simple array};
+  that is, an \term{object} of \term{type} \f{(simple-array bit)}.
+
+\gentry{simple bit vector} \Noun\ 
+  a \term{bit vector} \oftype{simple-bit-vector}.
+
+\gentry{simple condition} \Noun\ 
+  a \term{condition} \oftype{simple-condition}.
+
+\gentry{simple general vector} \Noun\ 
+  a \term{simple vector}.
+
+\gentry{simple string} \Noun\ 
+  a \term{string} \oftype{simple-string}.
+
+%!!! Moon: "not the same as a one-dimensional simple array.
+% Does the addition of the "Not all ..." thing fix that?  (Mail sent to Moon.) -kmp 14-Jan-92
+\gentry{simple vector} \Noun\
+  a \term{vector} \oftype{simple-vector},
+  sometimes called a ``\term{simple general vector}.''
+  Not all \term{vectors} that are \term{simple} are \term{simple vectors}---only
+  those that have \term{element type} \typeref{t}.
+
+\gentry{single escape} \Noun, \Adjective\
+  1. \Noun\ the \term{syntax type} of a \term{character} 
+     that indicates that the next \term{character} is 
+     to be treated as an \term{alphabetic}\meaning{2} \term{character}
+     with its \term{case} preserved.
+     For details, \seesection\SingleEscapeChar.
+  2. \Adjective\ (of a \term{character})
+     having the \term{single escape} \term{syntax type}.
+  3. \Noun\ a \term{single escape}\meaning{2} \term{character}.
+     (In the \term{standard readtable},
+      \term{slash} is the only \term{single escape}.)
+
+\gentry{single float} \Noun\ 
+  an \term{object} \oftype{single-float}.
+
+\gentry{single-quote} \Noun\
+  the \term{standard character} that is variously called
+      ``apostrophe,''
+      ``acute accent,''
+      ``quote,''
+   or ``single quote'' (\f{'}).
+  \Seefigure\StdCharsThree.
+
+\gentry{singleton} \Adjective\ (of a \term{sequence})
+  having only one \term{element}.
+  \gexample{\f{(list 'hello)} returns a singleton list.}
+
+\gentry{situation} \Noun\ 
+  the \term{evaluation} of a \term{form} in a specific \term{environment}.
+
+\gentry{slash} \Noun\
+  the \term{standard character} that is variously called
+       ``solidus'' 
+    or ``slash'' (\f{/}).
+  \Seefigure\StdCharsThree.
+
+%!!! Moon: too general--limit to CLOS slots. "a named component"?
+\gentry{slot} \Noun\ 
+  a component of an \term{object} that can store a \term{value}.
+
+% slot option?
+
+% Per X3J13 -kmp 5-Oct-93
+\gentry{slot specifier} \Noun\
+  a representation of a \term{slot} 
+  that includes the \term{name} of the \term{slot} and zero or more \term{slot} options.
+  A \term{slot} option pertains only to a single \term{slot}.
+
+\gentry{source code} \Noun\ 
+  \term{code} representing \term{objects} suitable for \term{evaluation}
+  (\eg \term{objects} created by \funref{read}, 
+       by \term{macro expansion}, 
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+    or by \term{compiler macro expansion}).
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+
+\gentry{source file} \Noun\ 
+  a \term{file} which contains a textual representation of \term{source code},
+  that can be edited, \term{loaded}, or \term{compiled}.
+
+\gentry{space} \Noun\
+  the \term{standard character} \SpaceChar,
+  notated for the \term{Lisp reader} as \f{\#\\Space}.
+
+\gentry{special form} \Noun\ 
+  a \term{list}, other than a \term{macro form}, which is a
+  \term{form} with special syntax or special \term{evaluation} 
+  rules or both, possibly manipulating the \term{evaluation} 
+  \term{environment} or control flow or both.  The first element of
+  a \term{special form} is a \term{special operator}.
+
+\gentry{special operator} \Noun\ 
+  one of a fixed set of \term{symbols}, 
+  enumerated in \figref\CLSpecialOps,
+  that may appear in the \term{car} of
+  a \term{form} in order to identify the \term{form} as a \term{special form}.
+
+\gentry{special variable} \Noun\ \Traditional\
+  a \term{dynamic variable}.
+
+\gentry{specialize} \TransitiveVerb\ (a \term{generic function})
+  to define a \term{method} for the \term{generic function}, or in other words,
+  to refine the behavior of the \term{generic function} by giving it a specific
+  meaning for a particular set of \term{classes} or \term{arguments}. 
+     
+\gentry{specialized} \Adjective\ 
+  1. (of a \term{generic function})
+     having \term{methods} which \term{specialize} the \term{generic function}.
+  2. (of an \term{array})
+     having an \term{actual array element type}
+     that is a \term{proper subtype} of \thetype{t};
+     \seesection\ArrayElements.
+     \gexample{\f{(make-array 5 :element-type 'bit)} makes an array of length
+	       five that is specialized for bits.}
+
+\gentry{specialized lambda list} \Noun\
+  an \term{extended lambda list} used in \term{forms} that \term{establish}
+  \term{method} definitions, such as \macref{defmethod}.
+  \Seesection\SpecializedLambdaLists.
+
+\gentry{spreadable argument list designator} \Noun\
+  a \term{designator} for a \term{list} of \term{objects}; that is,
+  an \term{object} that denotes a \term{list} 
+  and that is a \term{non-null} \term{list} $L1$ of length $n$,
+  whose last element is a \term{list} $L2$ of length $m$
+  (denoting a list $L3$ of length $m+n-1$ whose \term{elements} are
+   $L1\sub i$ for $i < n-1$ followed by $L2\sub j$ for $j < m$).
+  \gexample{The list (1 2 (3 4 5)) is a spreadable argument list designator for
+	    the list (1 2 3 4 5).}
+
+\gentry{stack allocate} \TransitiveVerb\ \Traditional\ 
+  to allocate in a non-permanent way, such as on a stack.  Stack-allocation
+  is an optimization technique used in some \term{implementations} for
+  allocating certain kinds of \term{objects} that have \term{dynamic extent}.
+  Such \term{objects} are allocated on the stack rather than in the heap
+  so that their storage can be freed as part of unwinding the stack rather
+  than taking up space in the heap until the next garbage collection.
+  What \term{types} (if any) can have \term{dynamic extent} can vary
+  from \term{implementation} to \term{implementation}.  No
+  \term{implementation} is ever required to perform stack-allocation.
+
+%!!! Moon thinks this is too circular.
+\gentry{stack-allocated} \Adjective\ \Traditional\ 
+  having been \term{stack allocated}.
+
+\gentry{standard character} \Noun\ 
+  a \term{character} \oftype{standard-char}, which is one of a fixed set of 96
+  such \term{characters} required to be present in all \term{conforming implementations}.
+  \Seesection\StandardChars.
+
+% Definitions of terms "standard function", "standard macro", and "standard special form"
+% removed since they were not used anywhere, and since they were yucky anyway.
+%  -kmp 15-Oct-91
+
+%Moon: "direct instance" or "generalized instance". I think it's "direct" 
+%      but don't know for sure.
+%After some discussion (with subject line "standard class, standard generic function"),
+%Moon and KMP think this is a technical issue which requires X3J13 vote to proceed on.
+%Leaving it unchanged for now. -kmp 15-Nov-91
+%Changing it to "generalized instance" on advice from Quinquevirate. -kmp 14-Feb-92
+\gentry{standard class} \Noun\ 
+  a \term{class} that is a \term{generalized instance} \ofclass{standard-class}.
+
+%Moon: Same comment as for "standard class".
+\gentry{standard generic function}
+  a \term{function} \oftype{standard-generic-function}.
+
+\gentry{standard input} \Noun\ 
+  the \term{input} \term{stream} which is the \term{value} of the \term{dynamic variable}
+  \varref{*standard-input*}.
+
+\gentry{standard method combination} \Noun\ 
+  the \term{method combination} named \typeref{standard}.
+
+\gentry{standard object} \Noun\ 
+  an \term{object} that is 
+%This phrase added per Moon:
+  a \term{generalized instance} 
+  \ofclass{standard-object}.
+
+\gentry{standard output} \Noun\ 
+  the \term{output} \term{stream} which is the \term{value} of the \term{dynamic variable}
+  \varref{*standard-output*}.
+
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+\gentry{standard pprint dispatch table} \Noun\
+  A \term{pprint dispatch table} that is \term{different} from 
+  the \term{initial pprint dispatch table},
+  that implements \term{pretty printing} as described in this specification,
+  and that, unlike other \term{pprint dispatch tables},
+  must never be modified by any program.
+  (Although the definite reference ``the \term{standard pprint dispatch table}''
+   is generally used
+   within this document, it is actually \term{implementation-dependent} whether a
+   single \term{object} fills the role of the \term{standard pprint dispatch table},
+   or whether there might be multiple such objects, any one of which could be used on any
+   given occasion where ``the \term{standard pprint dispatch table}'' is called for.
+   As such, this phrase should be seen as an indefinite reference 
+   in all cases except for anaphoric references.)
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+\issue{WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91}
+\gentry{standard readtable} \Noun\
+  A \term{readtable} that is \term{different} from the \term{initial readtable},
+  that implements the \term{expression} syntax defined in this specification,
+  and that, unlike other \term{readtables}, must never be modified by any program.
+  (Although the definite reference ``the \term{standard readtable}'' is generally used
+   within this document, it is actually \term{implementation-dependent} whether a
+   single \term{object} fills the role of the \term{standard readtable},
+   or whether there might be multiple such objects, any one of which could be used on any
+   given occasion where ``the \term{standard readtable}'' is called for.
+   As such, this phrase should be seen as an indefinite reference 
+   in all cases except for anaphoric references.)
+\endissue{WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91}
+
+\gentry{standard syntax} \Noun\
+  the syntax represented by the \term{standard readtable} 
+  and used as a reference syntax throughout this document.
+  \Seesection\TheStandardSyntax.
+
+\gentry{standardized} \Adjective\ (of a \term{name}, \term{object}, or definition)
+  having been defined by \clisp.
+  \gexample{All standardized variables that are required to 
+	    hold bidirectional streams have ``\f{-io*}'' in their name.}
+
+\gentry{startup environment} \Noun\
+  the \term{global environment} of the running \term{Lisp image} 
+  from which the \term{compiler} was invoked.
+
+\gentry{step} \TransitiveVerb, \Noun\ 
+  1. \TransitiveVerb\ (an iteration \term{variable}) to \term{assign} the \term{variable}
+     a new \term{value} at the end of an iteration, in preparation for a new iteration.
+  2. \Noun\ the \term{code} that identifies how the next value in an iteration
+     is to be computed.
+  3. \TransitiveVerb\ (\term{code}) to specially execute the \term{code}, pausing at
+     intervals to allow user confirmation or intervention, usually for debugging.
+
+\gentry{stream} \Noun\ 
+  an \term{object} that can be used with an input or output function to
+  identify an appropriate source or sink of \term{characters} or 
+  \term{bytes} for that operation.
+
+\issue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+\issue{PATHNAME-STREAM:FILES-OR-SYNONYM}
+\gentry{stream associated with a file} \Noun\ 
+  a \term{file stream}, or a \term{synonym stream} the \term{target} 
+  of which is a \term{stream associated with a file}.
+%!!! I wonder if this really needs to be said...
+  Such a \term{stream} cannot be created with
+      \funref{make-two-way-stream}, 
+      \funref{make-echo-stream},
+      \funref{make-broadcast-stream}, 
+      \funref{make-concatenated-stream},
+      \funref{make-string-input-stream},
+   or \funref{make-string-output-stream}.
+\endissue{PATHNAME-STREAM:FILES-OR-SYNONYM}
+\endissue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+
+\gentry{stream designator} \Noun\
+  a \term{designator} for a \term{stream}; that is,
+  an \term{object} that denotes a \term{stream} 
+  and that is one of:
+      \t\ (denoting \thevalueof{*terminal-io*}), 
+      \nil\ (denoting \thevalueof{*standard-input*}
+             for \term{input} \term{stream designators}
+             or denoting \thevalueof{*standard-output*}
+             for \term{output} \term{stream designators}),
+   or a \term{stream} (denoting itself).
+
+\gentry{stream element type} \Noun\ (of a \term{stream})
+  the \term{type} of data for which the \term{stream} is specialized.
+%KMP: Is there a notion of upgraded element type in this situation?
+%Moon: Surely!  But there is no way for a portable program to detect it.
+
+\gentry{stream variable} \Noun\
+  a \term{variable} whose \term{value} must be a \term{stream}.
+
+\gentry{stream variable designator} \Noun\
+  a \term{designator} for a \term{stream variable}; that is,
+  a \term{symbol} that denotes a \term{stream variable} 
+  and that is one of:
+      \t\ (denoting \varref{*terminal-io*}), 
+      \nil\ (denoting \varref{*standard-input*}
+             for \term{input} \term{stream variable designators}
+             or denoting \varref{*standard-output*}
+             for \term{output} \term{stream variable designators}),
+   or some other \term{symbol} (denoting itself).
+
+\gentry{string} \Noun\ 
+  a specialized \term{vector} that is \oftype{string},
+  and whose elements are \oftypes{character}.
+
+\gentry{string designator} \Noun\
+  a \term{designator} for a \term{string}; that is,
+  an \term{object} that denotes a \term{string} 
+  and that is one of:
+       a \term{character} (denoting a \term{singleton} \term{string}
+			   that has the \term{character} as its only \term{element}),
+       a \term{symbol} (denoting the \term{string} that is its \term{name}),
+    or a \term{string} (denoting itself).
+\issue{STRING-COERCION:MAKE-CONSISTENT}
+  The intent is that this term be consistent with the behavior of \funref{string};
+  \term{implementations} that extend \funref{string} must extend the meaning of 
+  this term in a compatible way.
+\endissue{STRING-COERCION:MAKE-CONSISTENT}
+
+\gentry{string equal} \Adjective\ 
+  the \term{same} under \funref{string-equal}.
+
+\gentry{string stream} \Noun\ 
+  a \term{stream} \oftype{string-stream}.
+
+\gentry{structure} \Noun\ 
+  an \term{object} \oftype{structure-object}.
+% It's really pathetic that the type structure-object 
+% is not just called structure. -kmp 2-Jan-91
+
+\gentry{structure class} \Noun\ 
+%Moon: See comment for standard class.
+%"instance" => "generalized instance" per Quinquevirate. -kmp 14-Feb-92
+  a \term{class} that is a \term{generalized instance} \ofclass{structure-class}.
+
+\gentry{structure name} \Noun\
+  a \term{name} defined with \macref{defstruct}.
+  Usually, such a \term{type} is also a \term{structure class},
+%!!! Really? Must they be implementation-dependent?
+  but there may be \term{implementation-dependent} situations 
+  in which this is not so, if the \kwd{type} option to \macref{defstruct} is used.
+
+\gentry{style warning} \Noun\
+  a \term{condition} \oftype{style-warning}.
+
+\gentry{subclass} \Noun\ 
+  a \term{class} that \term{inherits} from another \term{class}, 
+  called a \term{superclass}.
+  (No \term{class} is a \term{subclass} of itself.)
+ 
+\gentry{subexpression} \Noun\ (of an \term{expression})
+  an \term{expression} that is contained within the \term{expression}. 
+  (In fact, the state of being a \term{subexpression} is not an attribute 
+   of the \term{subexpression}, but really an attribute of the containing
+   \term{expression} since the \term{same} \term{object} can at once be
+   a \term{subexpression} in one context, and not in another.)
+
+\gentry{subform} \Noun\ (of a \term{form})
+  an \term{expression} that is a \term{subexpression} of the \term{form},
+  and which by virtue of its position in that \term{form} is also a
+  \term{form}.
+  \gexample{\f{(f x)} and \f{x}, but not \f{exit}, are subforms of
+	    \f{(return-from exit (f x))}.}
+
+\gentry{subrepertoire} \Noun\ 
+  a subset of a \term{repertoire}.
+
+\gentry{subtype} \Noun\ 
+  a \term{type} whose membership is the same as or a proper subset of the
+  membership of another \term{type}, called a \term{supertype}.
+  (Every \term{type} is a \term{subtype} of itself.)
+ 
+\gentry{superclass} \Noun\ 
+  a \term{class} from which another \term{class} 
+  (called a \term{subclass}) \term{inherits}.
+  (No \term{class} is a \term{superclass} of itself.)
+  \Seeterm{subclass}.
+ 
+\gentry{supertype} \Noun\ 
+  a \term{type} whose membership is the same as or a proper superset
+  of the membership of another \term{type}, called a \term{subtype}.
+  (Every \term{type} is a \term{supertype} of itself.)
+  \Seeterm{subtype}.
+ 
+\gentry{supplied-p parameter} \Noun\
+  a \term{parameter} which recieves its \term{generalized boolean} value
+  implicitly due to the presence or absence of an \term{argument} 
+  corresponding to another \term{parameter} 
+  (such as an \term{optional parameter} or a \term{rest parameter}).
+  \Seesection\OrdinaryLambdaLists.
+
+\gentry{symbol} \Noun\ 
+  an \term{object} \oftype{symbol}.
+
+\gentry{symbol macro} \Noun\ 
+  a \term{symbol} that stands for another \term{form}.
+  \Seemac{symbol-macrolet}.
+
+% \gentry{symbol name designator} \Noun\
+%   a \term{designator} for the \term{name} of a \term{symbol}; that is,
+%   an \term{object} that denotes a \term{symbol} 
+%   and that is one of:
+%        a \term{character} (denoting a \term{singleton} \term{string}
+% 			   that has the \term{character} as its only \term{element}),
+%        a \term{symbol} (denoting the \term{string} that is its \term{name}),
+%     or a \term{string} (denoting itself).
+
+\gentry{synonym stream} \Noun\ 
+  1. a \term{stream} \oftype{synonym-stream}, 
+     which is consequently a \term{stream} that is an alias for another \term{stream},
+     which is the \term{value} of a \term{dynamic variable}
+     whose \term{name} is the \term{synonym stream symbol} of the \term{synonym stream}.
+     \Seefun{make-synonym-stream}.
+  2. (to a \term{stream})
+     a \term{synonym stream} which has the \term{stream} as the \term{value}
+     of its \term{synonym stream symbol}.
+  3. (to a \term{symbol})
+     a \term{synonym stream} which has the \term{symbol} as its
+     \term{synonym stream symbol}.
+
+\gentry{synonym stream symbol} \Noun\ (of a \term{synonym stream})
+  the \term{symbol} which names the \term{dynamic variable} which has as its
+  \term{value} another \term{stream} for which the \term{synonym stream}
+  is an alias.
+
+\gentry{syntax type} \Noun\ (of a \term{character})
+  one of several classifications, enumerated in \figref\PossibleSyntaxTypes,
+  that are used for dispatch during parsing by the \term{Lisp reader}.
+  \Seesection\CharacterSyntaxTypes.
+
+\gentry{system class} \Noun\ 
+  a \term{class} that may be \oftype{built-in-class} in a \term{conforming implementation}
+  and hence cannot be inherited by \term{classes} defined by \term{conforming programs}.
+
+\gentry{system code} \Noun\ 
+  \term{code} supplied by the \term{implementation} to implement this specification
+  (\eg the definition of \funref{mapcar})
+  or generated automatically in support of this specification
+  (\eg during method combination);
+  that is, \term{code} that is not \term{programmer code}.
+
+% %!!! Now that there's this term "standarized", this term could probably go away.
+% %    -kmp 24-Jan-92
+% \gentry{system stream variable} \Noun\
+%   a \term{standardized} \term{stream variable}.
+%   \Seesection\StreamConcepts.
+
+\indextab{T}
+
+\gentry{t} \Noun\ 
+  1. a. the \term{boolean} representing true.
+     b. the canonical \term{generalized boolean} representing true.
+        (Although any \term{object} other than \nil\ is considered \term{true} 
+	 as a \term{generalized boolean},
+         \f{t} is generally used when there is no special reason to prefer one 
+         such \term{object} over another.)
+  2. the \term{name} of the \term{type} to which all \term{objects} belong---the
+     \term{supertype} of all \term{types} (including itself).
+  3. the \term{name} of the \term{superclass} of all \term{classes} except itself.
+ 
+\gentry{tag} \Noun\ 
+  1. a \term{catch tag}.
+  2. a \term{go tag}.
+
+\issue{TAILP-NIL:T}
+\gentry{tail} \Noun\ (of a \term{list})
+  an \term{object} that is the \term{same} as either some \term{cons}
+  which makes up that \term{list} or the \term{atom} (if any) which terminates
+  the \term{list}.
+  \gexample{The empty list is a tail of every proper list.}
+\endissue{TAILP-NIL:T}
+
+\gentry{target} \Noun\ 
+  1. (of a \term{constructed stream}) 
+     a \term{constituent} of the \term{constructed stream}.
+     \gexample{The target of a synonym stream is 
+	       the value of its synonym stream symbol.}
+  2. (of a \term{displaced array})
+     the \term{array} to which the \term{displaced array} is displaced.
+  (In the case of a chain of \term{constructed streams} or \term{displaced arrays},
+   the unqualified term ``\term{target}'' always refers to the immediate 
+   \term{target} of the first item in the chain, not the immediate target
+   of the last item.)
+%!!! Do we want a term "eventual target" to talk about the last item?
+
+\gentry{terminal I/O} \Noun\ 
+  the \term{bidirectional} \term{stream}
+  that is the \term{value} of \thevariable{*terminal-io*}.
+
+\gentry{terminating} \Noun\ (of a \term{macro character})
+  being such that, if it appears while parsing a token, it terminates that token.
+  \Seesection\ReaderAlgorithm.
+
+\gentry{tertiary value} \Noun\ (of \term{values} resulting from the
+				   \term{evaluation} of a \term{form})
+  the third \term{value}, if any,
+  or else \nil\ if there are fewer than three \term{values}.
+
+\gentry{throw} \Verb\ 
+  to transfer control and \term{values} to a \term{catch}.
+  \Seespec{throw}.
+
+\gentry{tilde} \Noun\
+  the \term{standard character} that is called ``tilde'' (\f{~}).
+  \Seefigure\StdCharsThree.
+
+%!!! Moon: What's a "time line"?
+\gentry{time}
+  a representation of a point (\term{absolute} \term{time}) 
+		   or an interval (\term{relative} \term{time})
+  on a time line.
+  \Seeterm{decoded time}, \term{internal time}, and \term{universal time}.
+
+\issue{TIME-ZONE-NON-INTEGER:ALLOW}
+\gentry{time zone} \Noun\
+  a \term{rational} multiple of \f{1/3600} between \f{-24} (inclusive)
+  and \f{24} (inclusive) that represents a time zone as a number of hours
+  offset from Greenwich Mean Time.  Time zone values increase with motion to the west,
+  so   Massachusetts, U.S.A. is in time zone \f{5},
+       California, U.S.A. is time zone \f{8},
+   and Moscow, Russia is time zone \term{-3}.
+%   (In regions where ``daylight savings time'' might apply,
+%    the time zone does not depend on whether daylight savings time
+%    is in effect---such information is represented separately.)
+%% Moon didn't like that, and prefers the following:
+   (When ``daylight savings time'' is separately represented
+    as an \term{argument} or \term{return value}, the \term{time zone}
+    that accompanies it does not depend on whether daylight savings time
+    is in effect.)
+\endissue{TIME-ZONE-NON-INTEGER:ALLOW}
+
+\gentry{token} \Noun\
+  a textual representation for a \term{number} or a \term{symbol}.
+  \Seesection\InterpOfTokens.
+
+\gentry{top level form} \Noun\ 
+% The old definition is contradicted by item (4) in the description of how
+% EVAL-WHEN works. --sjl 3 Mar 92
+%  a \term{form} which, because it is not a \term{subform} of some \term{form}
+%  that \term{establishes} a new \term{lexical environment}, is to be executed
+%  in the \term{null lexical environment}.
+  a \term{form} which is processed specially by \funref{compile-file} for
+  the purposes of enabling \term{compile time} \term{evaluation} of that
+  \term{form}.  
+  \term{Top level forms} include those \term{forms} which 
+  are not \term{subforms} of any other \term{form},
+  and certain other cases.  \Seesection\TopLevelForms.
+ 
+\gentry{trace output} \Noun\ 
+  the \term{output} \term{stream} which is the \term{value} of the \term{dynamic variable}
+  \varref{*trace-output*}.
+
+\gentry{tree} \Noun\ 
+  1. a binary recursive data structure made up of \term{conses} and
+     \term{atoms}:  the \term{conses} are themselves also \term{trees}
+     (sometimes called ``subtrees'' or ``branches''), and the \term{atoms}
+     are terminal nodes (sometimes called \term{leaves}). Typically,
+     the \term{leaves} represent data while the branches establish some 
+     relationship among that data.
+% Moon wondered if "acyclic" should be here.  I think that's fine for math
+% but not for computer science. so i'm leaving it out.  I think it's
+% useful to talk about a tree that is circular, but "circular tree" would
+% be an oxymoron under so rigorous a definition.  as with a list, one
+% often doesn't descend a tree in order to prove it's well-formed before
+% manipulating it with tree primitives, and you'd still like to be able to
+% say it was a tree.   tree is more of a view on the process of
+% destructuring than a kind of object.  after all, all objects are trees.
+% -kmp 15-Nov-91
+  2. in general, any recursive data structure that has some notion of
+     ``branches'' and \term{leaves}.
+ 
+\gentry{tree structure} \Noun\ (of a \term{tree}\meaning{1})
+  the set of \term{conses} that make up the \term{tree}.
+  Note that while the \term{car}\meaning{1b} component of each such \term{cons}
+  is part of the \term{tree structure}, 
+  the \term{objects} that are the \term{cars}\meaning{2} of each \term{cons}
+  in the \term{tree}
+  are not themselves part of its \term{tree structure} 
+  unless they are also \term{conses}.
+
+\gentry{true} \Noun\ 
+  any \term{object} 
+      that is not \term{false}
+  and that is used to represent the success of a \term{predicate} test.
+  \Seeterm{t}\meaning{1}.
+
+\gentry{truename} \Noun\ 
+  1. the canonical \term{filename} of a \term{file} in the \term{file system}.
+     \Seesection\Truenames.
+  2. a \term{pathname} representing a \term{truename}\meaning{1}.
+
+\gentry{two-way stream} \Noun\ 
+  a \term{stream} \oftype{two-way-stream},
+  which is a \term{bidirectional} \term{composite stream} that 
+       receives its input  from an associated \term{input}  \term{stream} 
+   and sends    its output to   an associated \term{output} \term{stream}.
+
+\gentry{type} \Noun\ 
+  1. a set of \term{objects}, usually with common structure, behavior, or purpose.
+     (Note that the expression ``\i{X} is of type \param{S$\sub{a}$}'' 
+      naturally implies that ``\i{X} is of type \param{S$\sub{b}$}'' if 
+      \param{S$\sub{a}$} is a \term{subtype} of \param{S$\sub{b}$}.)
+  2. (immediately following the name of a \term{type})
+     a \term{subtype} of that \term{type}.
+     \gexample{The type \typeref{vector} is an array type.}
+
+\gentry{type declaration} \Noun\ 
+  a \term{declaration} that asserts that every reference to a 
+  specified \term{binding} within the scope of the \term{declaration}
+  results in some \term{object} of the specified \term{type}.
+
+\gentry{type equivalent} \Adjective\ (of two \term{types} $X$ and $Y$)
+  having the same \term{elements};
+  that is, $X$ is a \term{subtype} of $Y$ 
+       and $Y$ is a \term{subtype} of $X$.
+
+\gentry{type expand} \Noun\
+  to fully expand a \term{type specifier}, removing any references to
+  \term{derived types}.  (\clisp\ provides no program interface to cause
+  this to occur, but the semantics of \clisp\ are such that every
+  \term{implementation} must be able to do this internally, and some
+  situations involving \term{type specifiers} are most easily described
+  in terms of a fully expanded \term{type specifier}.)
+
+\gentry{type specifier} \Noun\ 
+  an \term{expression} that denotes a \term{type}.
+  \gexample{The symbol \f{random-state}, the list \f{(integer 3 5)},
+            the list \f{(and list (not null))}, and the class named
+            \f{standard-class} are type specifiers.}
+
+\indextab{U}
+ 
+\gentry{unbound} \Adjective\ 
+  not having an associated denotation in a \term{binding}.
+  \Seeterm{bound}.
+ 
+\gentry{unbound variable} \Noun\
+  a \term{name} that is syntactically plausible as the name of a
+  \term{variable} but which is not \term{bound} 
+  in the \term{variable} \term{namespace}.
+
+\gentry{undefined function} \Noun\
+  a \term{name} that is syntactically plausible as the name of a
+  \term{function} but which is not \term{bound}
+  in the \term{function} \term{namespace}.
+
+\gentry{unintern} \TransitiveVerb\ (a \term{symbol} in a \term{package})
+  to make the \term{symbol} not be \term{present} in that \term{package}.
+  (The \term{symbol} might continue to be \term{accessible} by inheritance.)
+
+\gentry{uninterned} \Adjective\ (of a \term{symbol}) 
+  not \term{accessible} in any \term{package}; \ie not \term{interned}\meaning{1}.
+
+\gentry{universal time} \Noun\
+  \term{time}, represented as a non-negative \term{integer} number of seconds.
+%!!! Moon: Universal time is -always- absolute!
+  \term{Absolute} \term{universal time} is measured as an offset
+  from the beginning of the year 1900 (ignoring \term{leap seconds}).
+  \Seesection\UniversalTime.
+
+\gentry{unqualified method} \Noun\ 
+  a \term{method} with no \term{qualifiers}.
+
+\gentry{unregistered package} \Noun\
+  a \term{package} \term{object} that is not present in the \term{package registry}.
+  An \term{unregistered package} has no \term{name}; \ie its \term{name} is \nil.
+  \Seefun{delete-package}.
+
+\gentry{unsafe} \Adjective\ (of \term{code})
+  not \term{safe}.  (Note that, unless explicitly specified otherwise,
+  if a particular kind of error checking is
+  guaranteed only in a \term{safe} context, the same checking might or might not occur
+  in that context if it were \term{unsafe}; describing a context as \term{unsafe}
+  means that certain kinds of error checking are not reliably enabled
+  but does not guarantee that error checking is definitely disabled.)
+
+\gentry{unsafe call} \Noun\
+  a \term{call} that is not a \term{safe call}.
+  For more detailed information, \seesection\SafeAndUnsafeCalls.
+
+\gentry{upgrade} \TransitiveVerb\ (a declared \term{type} to an actual \term{type})
+  1. (when creating an \term{array})
+     to substitute an \term{actual array element type} 
+     for an \term{expressed array element type}
+     when choosing an appropriately \term{specialized} \term{array} representation.
+     \Seefun{upgraded-array-element-type}.
+  2. (when creating a \term{complex})
+     to substitute an \term{actual complex part type} 
+     for an \term{expressed complex part type}
+     when choosing an appropriately \term{specialized} \term{complex} representation.
+     \Seefun{upgraded-complex-part-type}.
+
+\gentry{upgraded array element type} \Noun\ (of a \term{type})
+  a \term{type} that is a \term{supertype} of the \term{type}
+  and that is used instead of the \term{type} whenever the
+  \term{type} is used as an \term{array element type} 
+  for object creation or type discrimination.
+  \Seesection\ArrayUpgrading.
+
+\gentry{upgraded complex part type} \Noun\ (of a \term{type})
+  a \term{type} that is a \term{supertype} of the \term{type}
+  and that is used instead of the \term{type} whenever the
+  \term{type} is used as a \term{complex part type} 
+  for object creation or type discrimination.
+  \Seefun{upgraded-complex-part-type}.
+
+\gentry{uppercase} \Adjective\ (of a \term{character})
+     being among \term{standard characters} corresponding to
+     the capital letters \f{A} through \f{Z},
+  or being some other \term{implementation-defined} \term{character}
+      that is defined by the \term{implementation} to be \term{uppercase}.
+  \Seesection\CharactersWithCase.
+
+\gentry{use} \TransitiveVerb\ (a \term{package} $P\sub 1$)
+  to \term{inherit} the \term{external symbols} of $P\sub 1$.
+  (If a package $P\sub 2$ uses $P\sub 1$,
+   the \term{external symbols} of $P\sub 1$
+   become \term{internal symbols} of $P\sub 2$ 
+   unless they are explicitly \term{exported}.)
+  \gexample{The package \packref{cl-user} uses the package \packref{cl}.}
+
+\gentry{use list} \Noun\ (of a \term{package})
+  a (possibly empty) \term{list} associated with each \term{package}
+  which determines what other \term{packages} are currently being
+  \term{used} by that \term{package}.
+
+\gentry{user} \Noun\ 
+  an active entity, typically a human, that invokes or interacts with a
+  \term{program} at run time, but that is not necessarily a \term{programmer}.
+
+\indextab{V}
+ 
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\gentry{valid array dimension} \Noun\ 
+  a \term{fixnum} suitable for use as an \term{array} \term{dimension}.
+  Such a \term{fixnum} must be greater than or equal to zero, 
+  and less than the \term{value} of \conref{array-dimension-limit}.
+  When multiple \term{array} \term{dimensions} are to be used together to specify a 
+  multi-dimensional \term{array}, there is also an implied constraint 
+  that the product of all of the \term{dimensions} be less than the \term{value} of 
+  \conref{array-total-size-limit}.
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\gentry{valid array index} \Noun\ (of an \term{array})
+  a \term{fixnum} suitable for use as one of possibly several indices needed
+  to name an \term{element} of the \term{array} according to a multi-dimensional
+  Cartesian coordinate system. Such a \term{fixnum} must
+  be greater than or equal to zero,
+  and must be less than the corresponding \term{dimension}\meaning{1}
+  of the \term{array}.
+  (Unless otherwise explicitly specified, 
+   the phrase ``a \term{list} of \term{valid array indices}'' further implies
+   that the \term{length} of the \term{list} must be the same as the
+   \term{rank} of the \term{array}.)
+  \gexample{For a \f{2} by~\f{3} array,
+	    valid array indices for the first  dimension are \f{0} and~\f{1}, and
+	    valid array indices for the second dimension are \f{0}, \f{1} and~\f{2}.}
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\gentry{valid array row-major index} \Noun\ (of an \term{array},
+					     which might have any number 
+					     of \term{dimensions}\meaning{2})
+  a single \term{fixnum} suitable for use in naming any \term{element}
+  of the \term{array}, by viewing the array's storage as a linear
+  series of \term{elements} in row-major order.
+  Such a \term{fixnum} must be greater than or equal to zero,
+  and less than the \term{array total size} of the \term{array}.
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\gentry{valid fill pointer} \Noun\ (of an \term{array})
+  a \term{fixnum} suitable for use as a \term{fill pointer} for the \term{array}.
+  Such a \term{fixnum} must be greater than or equal to zero, 
+  and less than or equal to the \term{array total size} of the \term{array}.
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\editornote{KMP: The ``valid pathname xxx'' definitions were taken from 
+		 text found in make-pathname, but look wrong to me.
+		 I'll fix them later.}%!!!
+
+\issue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+
+\gentry{valid logical pathname host} \Noun\
+  a \term{string} that has been defined as the name of a \term{logical host}.
+  \Seefun{load-logical-pathname-translations}.
+
+\gentry{valid pathname device} \Noun\
+     a \term{string},
+     \nil,
+     \kwd{unspecific}, 
+  or some other \term{object} defined by the \term{implementation} 
+      to be a \term{valid pathname device}.
+
+\gentry{valid pathname directory} \Noun\
+     a \term{string},
+     a \term{list} of \term{strings},
+     \nil,
+\issue{PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION}
+     \kwd{wild},
+\endissue{PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION}
+     \kwd{unspecific},
+  or some other \term{object} defined by the \term{implementation} 
+      to be a \term{valid directory component}.
+
+\gentry{valid pathname host} \Noun\
+     a \term{valid physical pathname host}
+  or a \term{valid logical pathname host}.
+
+\gentry{valid pathname name} \Noun\
+     a \term{string},
+     \nil,
+     \kwd{wild},
+     \kwd{unspecific},
+  or some other \term{object} defined by the \term{implementation} 
+     to be a \term{valid pathname name}.
+
+\gentry{valid pathname type} \Noun\
+     a \term{string},
+     \nil,
+     \kwd{wild},
+     \kwd{unspecific}.
+%!!! Moon: "... or some other ..."
+
+\gentry{valid pathname version} \Noun\
+     a non-negative \term{integer},
+     or one of \kwd{wild},
+               \kwd{newest},
+ 	       \kwd{unspecific},
+   	    or \nil.
+%!!! KMP: "... or some other ..."
+%!!! What to do about this?
+ The symbols \kwd{oldest}, \kwd{previous}, and \kwd{installed} are
+ \term{semi-standard} special version symbols.
+
+\gentry{valid physical pathname host} \Noun\
+   any of
+     a \term{string},
+     a \term{list} of \term{strings},
+     or the symbol \kwd{unspecific},
+   that is recognized by the implementation as the name of a host.
+
+\endissue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+
+\gentry{valid sequence index} \Noun\ (of a \term{sequence})
+  an \term{integer} suitable for use to name an \term{element} 
+  of the \term{sequence}.  Such an \term{integer} must 
+  be greater than or equal to zero,
+  and must be less than the \term{length} of the \term{sequence}.
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+  (If the \term{sequence} is an \term{array},
+   the \term{valid sequence index} is further constrained to be a \term{fixnum}.)
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\gentry{value} \Noun\ 
+  1. a. one of possibly several \term{objects} that are the result of
+        an \term{evaluation}.
+     b. (in a situation where exactly one value is expected from the
+	 \term{evaluation} of a \term{form})
+        the \term{primary value} returned by the \term{form}.
+     c. (of \term{forms} in an \term{implicit progn}) one of possibly
+        several \term{objects} that result from the \term{evaluation}
+        of the last \term{form}, or \nil\ if there are no \term{forms}.
+  2. an \term{object} associated with a \term{name} in a \term{binding}.
+  3. (of a \term{symbol}) the \term{value} of the \term{dynamic variable}
+     named by that symbol.
+  4. an \term{object} associated with a \term{key} 
+     in an \term{association list}, 
+	a  \term{property list},
+     or a  \term{hash table}.
+
+\gentry{value cell} \Noun\ \Traditional\ (of a \term{symbol})
+  The \term{place} which holds the \term{value}, if any, of the
+  \term{dynamic variable} named by that \term{symbol},
+  and which is \term{accessed} by \funref{symbol-value}.
+  \Seeterm{cell}.
+
+\gentry{variable} \Noun\ 
+%% Rewritten per Boyer/Kaufmann/Moore #5 (by X3J13 vote at May 4-5, 1994 meeting).
+%% -kmp 9-May-94
+%   %!!! Moon: This is certainly no valid definition, especially when contrasting
+%   %          the variable namespace with the function namespace.
+%   a \term{binding} in which a \term{symbol} is the \term{name}
+%   used to refer to an \term{object}.
+  a \term{binding} in the ``variable'' \term{namespace}.
+  \Seesection\SymbolsAsForms.
+ 
+\gentry{vector} \Noun\ 
+  a one-dimensional \term{array}.
+
+\gentry{vertical-bar} \Noun\
+  the \term{standard character} that is called ``vertical bar'' (\f{|}).
+  \Seefigure\StdCharsThree.
+
+\indextab{W}
+ 
+%"cursor" => "print position" because Barmar didn't like "cursor".
+\gentry{whitespace} \Noun\ 
+  1. one or more \term{characters} that are
+      either the \term{graphic} \term{character} \f{\#\\Space}
+          or else \term{non-graphic} characters such as \f{\#\\Newline} 
+                  that only move the print position.
+  2. a. \Noun\ the \term{syntax type} of a \term{character} 
+         that is a \term{token} separator.
+         For details, \seesection\WhitespaceChars.
+     b. \Adjective\ (of a \term{character})
+        having the \term{whitespace}\meaning{2a} \term{syntax type}\meaning{2}.
+     c. \Noun\ a \term{whitespace}\meaning{2b} \term{character}.
+
+\gentry{wild} \Adjective\
+  1. (of a \term{namestring}) using an \term{implementation-defined}
+     syntax for naming files, which might ``match'' any of possibly several
+     possible \term{filenames}, and which can therefore be used to refer to 
+     the aggregate of the \term{files} named by those \term{filenames}.
+  2. (of a \term{pathname}) a structured representation of a name which
+     might ``match'' any of possibly several \term{pathnames}, and which can
+     therefore be used to refer to the aggregate of the \term{files} named by those
+     \term{pathnames}.  The set of \term{wild} \term{pathnames} includes, but
+     is not restricted to, \term{pathnames} which have a component which is
+     \kwd{wild}, or which have a directory component which contains \kwd{wild} 
+     or \kwd{wild-inferors}.
+     \Seefun{wild-pathname-p}.
+%!!! Need to fix this.  Some places use wild to refer to components instead of full pathnames.
+%   3. (of a \term{pathname} component)
+%      a component of a \term{pathname} that might ``match'' any of possibly 
+%      several values for that component, and which can
+%      therefore be used to refer to the aggregate of the \term{files} named by those
+%      \term{pathnames}.  The set of \term{wild} \term{pathnames} includes, but
+%      is not restricted to, \term{pathnames} which have a component which is
+%      \kwd{wild}, or which have a directory component which contains \kwd{wild} 
+%      or \kwd{wild-inferors}.
+%      \Seefun{wild-pathname-p}.
+
+\gentry{write} \TransitiveVerb\ 
+\issue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+  1. (a \term{binding} or \term{slot} or component)
+     to change the \term{value} of the \term{binding} or \term{slot}.
+\endissue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+  2. (an \term{object} to a \term{stream})
+     to output a representation of the \term{object} to the \term{stream}.
+
+
+\gentry{writer} \Noun\
+  a \term{function} that \term{writes}\meaning{1} a \term{variable} or \term{slot}.
+
+\indextab{Y}
+ 
+\gentry{yield} \TransitiveVerb\ (\term{values})
+  to produce the \term{values} as the result of \term{evaluation}.
+  \gexample{The form \f{(+ 2 3)} yields \f{5}.}
+
+\endlist
+\endlist

concept-hash-tables.tex

@@ -0,0 +1,267 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Hash-Table Operations}
+
+\Thenextfigure\ lists some \term{defined names} that are applicable 
+to \term{hash tables}.  The following rules apply to \term{hash tables}.
+
+%% 16.0.0 2
+%% 16.0.0 4
+\beginlist
+\itemitem{--}
+A \term{hash table} can only associate one value with a given
+key. If an attempt is made to add a second value for a given key,
+the second value will replace the first.
+Thus, adding a value to a \term{hash table} is a destructive operation;
+the \term{hash table} is modified.  
+
+%% 16.0.0 5
+\itemitem{--}
+There are four kinds of \term{hash tables}:
+  those whose keys are compared with \funref{eq},
+  those whose keys are compared with \funref{eql},
+  those whose keys are compared with \funref{equal}, and
+\issue{HASH-TABLE-TESTS:ADD-EQUALP}
+  those whose keys are compared with \funref{equalp}.  
+\endissue{HASH-TABLE-TESTS:ADD-EQUALP}
+
+%% 16.0.0 6
+\itemitem{--}
+\term{Hash tables} are created by \funref{make-hash-table}. 
+\funref{gethash} is used to look up a key and find the associated value.
+New entries are added to \term{hash tables} using \macref{setf} with \funref{gethash}.
+\funref{remhash} is used to remove an entry.
+For example:
+
+\code
+ (setq a (make-hash-table)) \EV #<HASH-TABLE EQL 0/120 32536573>
+ (setf (gethash 'color a) 'brown) \EV BROWN
+ (setf (gethash 'name a) 'fred) \EV FRED
+ (gethash 'color a) \EV BROWN, \term{true}
+ (gethash 'name a) \EV FRED, \term{true}
+ (gethash 'pointy a) \EV NIL, \term{false}
+\endcode
+
+%% 16.0.0 7             
+In this example, the symbols \f{color} and \f{name} are being used as
+keys, and the symbols \f{brown} and \f{fred} are being used as the
+associated values.  The \term{hash table} 
+has two items in it, one of which                              
+associates from \f{color} to \f{brown}, and the other of which
+associates from \f{name} to \f{fred}.
+
+%% 16.0.0 8
+\itemitem{--}
+A key or a value may be any \term{object}.
+
+\issue{HASH-TABLE-SIZE:INTENDED-ENTRIES}
+% The following will be deleted.
+% 
+% %% 16.0.0 9
+% \itemitem{--}
+% A \term{hash table}'s size is the maximum number of entries
+% it can hold without collisions. Usually the actual capacity of
+% the table is somewhat less, since the hashing is not perfectly
+% collision-free.  If so many entries are
+% added that the capacity is exceeded, the \term{hash table} 
+% will automatically
+% grow, and the entries will be rehashed (new hash values will be
+% recomputed, and everything will be rearranged so that the fast hash
+% lookup still works).  This is transparent to the caller; it all happens
+% automatically.
+\endissue{HASH-TABLE-SIZE:INTENDED-ENTRIES}
+
+%% 16.0.0 10
+\itemitem{--}
+% The cases of \f{nil} as a value and no entry in the \term{hash table} 
+% can be distinguished by the second value returned by \funref{gethash}.
+%% Reworded per Barmar:
+The existence of an entry in the \term{hash table} can be determined
+from the \term{secondary value} returned by \funref{gethash}.
+\endlist               
+
+\displaythree{Hash-table defined names}{
+clrhash&hash-table-p&remhash\cr
+gethash&make-hash-table&sxhash\cr
+hash-table-count&maphash&\cr
+}
+
+
+\endsubsection%{Hash-Table Operations}
+
+\beginsubsection{Modifying Hash Table Keys}
+\DefineSection{ModifyingHashKeys}
+
+\issue{HASH-TABLE-KEY-MODIFICATION:SPECIFY}
+
+The function supplied as the \kwd{test} argument to \funref{make-hash-table}
+specifies the `equivalence test' for the \term{hash table} it creates.
+ 
+An \term{object} is `visibly modified' with regard to an equivalence test
+if there exists some set of \term{objects} (or potential \term{objects})
+which are equivalent to the \term{object} before the modification but are
+no longer equivalent afterwards.
+
+% If an \term{object} is used as a key in a \term{hash table} and is then visibly 
+% modified with regard to the equivalence test of the \term{hash table}, then
+% using the \term{object} as a key in further operations on the \term{hash table}
+% has unspecified consequences.  Moreover, this applies for other \term{objects}
+% which either are or were equivalent to the key object.  Further, undoing the 
+% modification does not remove this effect.
+
+If an \term{object} $O\sub 1$ is used as a key in a \term{hash table} $H$
+and is then visibly modified with regard to the equivalence test of $H$,
+then the consequences are unspecified if $O\sub 1$, or any \term{object}
+$O\sub 2$ equivalent to $O\sub 1$ under the equivalence test (either before
+or after the modification), is used as a key in further operations on $H$.
+The consequences of using $O\sub 1$ as a key are unspecified 
+even if $O\sub 1$ is visibly modified 
+and then later modified again in such a way as 
+to undo the visible modification.
+ 
+Following are specifications of the modifications which are visible to the
+equivalence tests which must be supported by \term{hash tables}.  The modifications
+are described in terms of modification of components, and are defined
+recursively.  Visible modifications of components of the \term{object} are 
+visible modifications of the \term{object}.
+
+\beginsubsubsection{Visible Modification of Objects with respect to EQ and EQL}
+\DefineSection{VisModEQ}
+\DefineSection{VisModEQL}
+
+No \term{standardized} \term{function} is provided that is capable of visibly
+modifying an \term{object} with regard to \funref{eq} or \funref{eql}.
+
+\endsubsubsection%{Visible Modification of Objects with respect to EQ and EQL}
+
+\beginsubsubsection{Visible Modification of Objects with respect to EQUAL}
+\DefineSection{VisModEQUAL}
+
+As a consequence of the behavior for \funref{equal},
+the rules for visible modification of \term{objects} not explicitly mentioned in this
+section are inherited from those in \secref\VisModEQL.
+ 
+\beginsubsubsubsection{Visible Modification of Conses with respect to EQUAL}
+
+Any visible change to the \term{car} or the \term{cdr} of a \term{cons}
+is considered a visible modification with regard to \funref{equal}.
+ 
+\endsubsubsubsection%{Visible Modification of Conses with respect to EQUAL}
+
+\beginsubsubsubsection{Visible Modification of Bit Vectors and Strings with respect to EQUAL}
+
+For a \term{vector} \oftype{bit-vector} or \oftype{string}, any visible change
+     to an \term{active} \term{element} of the \term{vector},
+  or to the \term{length} of the \term{vector} (if it is \term{actually adjustable} 
+					           or has a \term{fill pointer})
+is considered a visible modification with regard to \funref{equal}.
+ 
+\endsubsubsubsection%{Visible Modification of Bit Vectors and Strings with respect to EQUAL}
+
+\endsubsubsection%{Visible Modification of Objects with respect to EQUAL}
+
+\beginsubsubsection{Visible Modification of Objects with respect to EQUALP}
+
+As a consequence of the behavior for \funref{equalp},
+the rules for visible modification of \term{objects} not explicitly mentioned in this
+section are inherited from those in \secref\VisModEQUAL.
+
+\beginsubsubsubsection{Visible Modification of Structures with respect to EQUALP}
+
+Any visible change to a \term{slot} of a \term{structure}
+is considered a visible modification with regard to \funref{equalp}.
+ 
+\endsubsubsubsection%{Visible Modification of Structures with respect to EQUALP}
+ 
+\beginsubsubsubsection{Visible Modification of Arrays with respect to EQUALP}
+
+In an \term{array}, any visible change
+     to an \term{active} \term{element},
+     to the \term{fill pointer} (if the \term{array} can and does have one),
+  or to the \term{dimensions} (if the \term{array} is \term{actually adjustable})
+is considered a visible modification with regard to \funref{equalp}.
+
+\endsubsubsubsection%{Visible Modification of Arrays with respect to EQUALP}
+
+\beginsubsubsubsection{Visible Modification of Hash Tables with respect to EQUALP}
+ 
+In a \term{hash table}, any visible change
+     to the count of entries in the \term{hash table},
+     to the keys,
+  or to the values associated with the keys
+is considered a visible modification with regard to \funref{equalp}.
+
+Note that the visibility of modifications to the keys depends on the equivalence test
+of the \term{hash table}, not on the specification of \funref{equalp}.
+ 
+\endsubsubsubsection%{Visible Modification of Hash Tables with respect to EQUALP}
+
+\endsubsubsection%{Visible Modification of Objects with respect to EQUALP}
+
+\beginsubsubsection{Visible Modifications by Language Extensions}
+
+\term{Implementations} that extend the language by providing additional mutator
+functions (or additional behavior for existing mutator functions) must
+document how the use of these extensions interacts with equivalence tests and
+\term{hash table} searches.
+ 
+\term{Implementations} that extend the language by defining additional acceptable
+equivalence tests for \term{hash tables} (allowing additional values for the \kwd{test}
+argument to \funref{make-hash-table}) must document the visible components of these
+tests.
+
+\endsubsubsection%{Visible Modifications by Language Extensions}
+
+% !!! Maybe consider making these things visible...
+%
+% Test Cases/Examples:
+% 
+%  (setf ht (make-hash-table :test #'eq))
+%  (setf a (cons 1 2))
+%  (setf (gethash a ht) 'win)
+%  (setf (cdr a) 3)
+%  (gethash a ht 'lose) => win t
+% 
+%  The same example with :test #'equal in the first line would be an error.
+% 
+%  The following example is not an error, because EQUAL does not examine the
+%  components of general vectors:
+% 
+%  (setf ht (make-hash-table :test #'equal))
+%  (setf a (vector 1 2))
+%  (setf (gethash a ht) 'win)
+%  (setf (aref a 1) 3)
+%  (gethash a ht 'lose) => win t
+% 
+%  The following example is not an error, because EQUALP is limited by the
+%  fill-pointer when examining the elements of a vector:
+% 
+%  (setf ht (make-hash-table :test #'equalp))
+%  (setf a (make-array 3 :fill-pointer 2 :initial-contents '(1 2 3)))
+%  (setf (gethash a ht) 'win)
+%  (setf (aref a 2) 4)
+%  (gethash a ht 'lose) => win t
+% 
+%  The following example is an error, because EQUALP may examine the dimensions
+%  of arrays:
+% 
+%  (setf ht (make-hash-table :test #'equalp))
+%  (setf a (make-array '(2 3) :adjustable t))
+%  (setf (gethash a ht) 'win)
+%  (setf a (adjust-array a '(3 2)))
+%  (gethash a ht 'lose) => `unspecified'
+% 
+%  The following example is not an error, because EQUALP is case insensitive:
+% 
+%  (setf ht (make-hash-table :test #'equalp))
+%  (setf a "ABC")
+%  (setf (gethash a ht) 'win)
+%  (setf (char a 0) #\a)
+%  (gethash a ht 'lose) => win t
+% 
+%  The same example with :test #'equal in the first line would be an error.
+% 
+
+\endissue{HASH-TABLE-KEY-MODIFICATION:SPECIFY}
+
+\endsubsection%{Modifying Hash Table Keys}

concept-history.tex

@@ -0,0 +1,211 @@
+%-*- Mode: TeX -*-
+%%Scope, Purpose, and History
+\beginsubSection{Scope and Purpose}
+The specification set forth in this document is designed to promote
+the portability of \clisp\ programs among a variety of data processing
+systems. It is a language specification aimed at an audience of
+implementors and knowledgeable programmers. It is neither a tutorial nor
+an implementation guide.
+\endsubSection%{Scope and Purpose}
+
+\beginsubSection{History}
+ 
+Lisp is a family of languages with a long history.  Early key ideas in
+Lisp were developed by John McCarthy during the 1956 Dartmouth Summer
+Research Project on Artificial Intelligence.  McCarthy's motivation
+was to develop an algebraic list processing language for artificial
+intelligence work.
+Implementation efforts for early dialects of Lisp were undertaken on
+the IBM~704, the IBM~7090, the Digital Equipment Corporation (DEC) PDP-1,
+the DEC~PDP-6, and the PDP-10. The primary dialect of Lisp between
+1960 and 1965 was Lisp~1.5. By the early 1970's there were two
+predominant dialects of Lisp, both arising from these early efforts:
+MacLisp and Interlisp.
+For further information about very early Lisp dialects, 
+see {\AnatomyOfLisp} or {\LispOnePointFive}.
+ 
+MacLisp improved on the Lisp~1.5 notion of special variables and error
+handling. MacLisp also introduced the concept of functions that could take
+a variable number of arguments, macros, arrays, non-local dynamic
+exits, fast arithmetic, the first good Lisp compiler, and an emphasis
+on execution speed. 
+% This next sentence transplanted from a later paragraph about PSL.
+% JonL says: My recollection was that it was closer to 100 than to 50.
+%            More likely, it had been received by about 100 sites, 
+%            and was actually in continued usage by 50 at the end of the decade.
+% KMP: Changed "was available" to "was in use" to compensate. (6-Dec-91)
+By the end of the 1970's, MacLisp was in use at over 50 sites.
+%From about 1969 onward Jonl White was the dominant force behind Maclisp.
+For further information about Maclisp, 
+see {\Moonual} or {\Pitmanual}.
+ 
+Interlisp introduced many ideas into Lisp programming environments and
+methodology. One of the Interlisp ideas that influenced \clisp\ was an iteration
+construct implemented by Warren Teitelman that inspired the \macref{loop}
+macro used both on the Lisp Machines and in MacLisp, and now in \clisp.
+For further information about Interlisp,
+see {\InterlispManual}.
+ 
+Although the first implementations of Lisp were on the IBM~704 and the
+IBM~7090, later work focussed on the DEC
+PDP-6 and, later, PDP-10 computers, the latter being the mainstay of
+Lisp and artificial intelligence work at such places as 
+Massachusetts Institute of Technology (MIT), Stanford University,
+and 
+Carnegie Mellon University (CMU) from the mid-1960's through much of the 1970's.
+The PDP-10 computer and its predecessor the PDP-6 computer were, by
+design, especially well-suited to Lisp because they had 36-bit words
+and 18-bit addresses. This architecture allowed a \term{cons} cell to be
+stored in one word; single instructions could extract the 
+\term{car} and \term{cdr}
+parts.  The PDP-6 and PDP-10 had fast, powerful stack instructions
+that enabled fast function calling.
+But the limitations of the PDP-10 were evident by 1973: it supported a
+small number of researchers using Lisp, and the small, 18-bit address
+space ($2^{18}$ $=$ 262,144 words) limited the size of a single
+program.
+One response to the address space problem was the Lisp Machine, a
+special-purpose computer designed to run Lisp programs.  The other
+response was to use general-purpose computers with address spaces
+larger than 18~bits, such as the DEC VAX and
+the \hbox{S-1}~Mark~IIA.
+For further information about S-1 Common Lisp, see ``{\SOneCLPaper}.''
+ 
+The Lisp machine concept was developed in the late 1960's.  In the
+early 1970's, Peter Deutsch, working with 
+Daniel Bobrow, implemented a Lisp on the
+Alto, a single-user minicomputer, using microcode to interpret a
+byte-code implementation language. Shortly thereafter, Richard
+Greenblatt began work on a different hardware and instruction set
+design at MIT.
+Although the Alto was not a total success as a Lisp machine, a dialect
+of Interlisp known as Interlisp-D became available on the D-series
+machines manufactured by Xerox---the Dorado, Dandelion,
+Dandetiger, and Dove (or Daybreak).
+An upward-compatible extension of MacLisp called Lisp
+Machine Lisp became available on the early MIT Lisp Machines.
+Commercial Lisp machines from Xerox, Lisp Machines (LMI), and
+Symbolics were on the market by 1981.
+For further information about Lisp Machine Lisp, see {\Chinual}.
+ 
+During the late 1970's, Lisp Machine Lisp began to expand towards a
+much fuller language.  Sophisticated lambda lists, 
+\f{setf}, multiple values, and structures
+like those in \clisp\ are the results of early
+experimentation with programming styles by the Lisp Machine group.
+Jonl White and others migrated these features to MacLisp.
+Around 1980, Scott Fahlman and others at CMU began work on a Lisp to
+run on the Scientific Personal Integrated Computing
+Environment (SPICE) workstation.  One of the goals of the project was to
+design a simpler dialect than Lisp Machine Lisp.
+ 
+The Macsyma group at MIT began a project during the late 1970's called
+the New Implementation of Lisp (NIL) for the VAX, which was headed by
+White.  One of the stated goals of the NIL project was to fix many of
+the historic, but annoying, problems with Lisp while retaining significant 
+compatibility with MacLisp.  At about the same time, a research group at
+Stanford University and Lawrence Livermore National Laboratory headed
+by Richard P. Gabriel began the design of a Lisp to run on the
+\hbox{S-1}~Mark~IIA supercomputer.  \hbox{S-1}~Lisp, never completely
+functional, was the test bed for adapting advanced compiler techniques
+to Lisp implementation.  Eventually the \hbox{S-1} and NIL groups
+collaborated.
+For further information about the NIL project,
+see ``{\NILReport}.''
+ 
+% The first efforts towards Lisp standardization were Standard Lisp and
+% Portable Standard Lisp (PSL).  In 1969, Anthony Hearn and Martin Griss
+% defined Standard Lisp---a subset of Lisp~1.5 and other dialects---to
+% transport REDUCE, a symbolic algebra system. 
+% PSL was designed to provide more control over the environment and
+% the compiler.
+% At the end of the 1970's, PSL ran on about a dozen different
+% computers.  PSL and Franz Lisp---a MacLisp-like dialect for Unix
+% machines---were the first examples of widely available Lisp dialects
+% on multiple hardware platforms. MacLisp was available at over 50
+% sites.
+% For further information about Standard Lisp, 
+% see ``{\StandardLispReport}.''
+%
+%% Sandra:  This paragraph contains inaccuracies and is not well-organized.
+%%          Suggested rewrite [taken -kmp] below.
+
+The first effort towards Lisp standardization was made in 1969, 
+when Anthony Hearn and Martin Griss at the University of Utah 
+defined Standard Lisp---a subset of Lisp~1.5 and other dialects---to 
+transport REDUCE, a symbolic algebra system.
+During the 1970's, the Utah group implemented first a retargetable
+optimizing compiler for Standard Lisp,
+and then an extended implementation known as Portable Standard Lisp (PSL).
+By the mid 1980's, PSL ran on about a dozen kinds of computers.
+For further information about Standard Lisp, see ``{\StandardLispReport}.''
+ 
+PSL and Franz Lisp---a MacLisp-like dialect for Unix machines---were 
+the first examples of widely available Lisp dialects on multiple 
+hardware platforms. 
+
+One of the most important developments in Lisp occurred during the
+second half of the 1970's: Scheme. Scheme, designed by Gerald J.
+Sussman and Guy L. Steele Jr., is a simple dialect of Lisp whose
+design brought to Lisp some of the ideas from programming language
+semantics developed in the 1960's.  Sussman was one of the prime
+innovators behind many other advances in Lisp technology from the late
+1960's through the 1970's.
+The major contributions of Scheme were lexical scoping, lexical
+closures, first-class continuations, and simplified syntax (no
+separation of value cells and function cells). Some of these contributions made
+a large impact on the design of \clisp.
+For further information about Scheme, see {\IEEEScheme} or ``{\RevisedCubedScheme}.''
+
+In the late 1970's object-oriented programming concepts started to
+make a strong impact on Lisp. 
+At MIT, certain ideas from Smalltalk made their way into several
+widely used programming systems.
+Flavors, an object-oriented programming system with multiple inheritance, 
+was developed at MIT for the Lisp machine community by Howard Cannon and others.
+At Xerox, the experience with Smalltalk and 
+Knowledge Representation Language (KRL) led to the development of 
+Lisp Object Oriented Programming System (LOOPS) and later Common LOOPS.
+For further information on Smalltalk, see {\SmalltalkBook}.
+For further information on Flavors, see {\FlavorsPaper}.
+
+These systems influenced the design of the Common Lisp Object System (CLOS).
+CLOS was developed specifically for this standardization effort,
+and was separately written up in ``\CLOSPaper.''  However, minor details
+of its design have changed slightly since that publication, and that paper 
+should not be taken as an authoritative reference to the semantics of the
+\CLOS\ as described in this document.
+
+In 1980 Symbolics and LMI were developing Lisp Machine Lisp; stock-hardware
+implementation groups were developing NIL, Franz Lisp, and PSL; Xerox
+was developing Interlisp; and the SPICE project at CMU was developing
+a MacLisp-like dialect of Lisp called SpiceLisp.
+ 
+In April 1981, after a DARPA-sponsored meeting concerning the
+splintered Lisp community, Symbolics, the SPICE project, the NIL
+project, and the \hbox{S-1}~Lisp project joined together to define
+\clisp.  Initially spearheaded by White and Gabriel, the
+driving force behind this grassroots effort was provided by Fahlman,
+Daniel Weinreb, David Moon, Steele,  and Gabriel.
+\clisp\ was designed as a description of a family of languages.  The
+primary influences on \clisp\ were Lisp Machine Lisp, MacLisp, NIL,
+\hbox{S-1}~Lisp, Spice Lisp, and Scheme.
+\CLtL\ is a description of that design.  Its
+semantics were intentionally underspecified in places where it was
+felt that a tight specification would overly constrain \clisp\
+research and use.
+%% Per X3J13. -kmp 05-Oct-93
+%Between 1984 and 1989, \clisp\ became a de facto standard. 
+
+In 1986 X3J13 was formed as a technical working group to
+produce a draft for an ANSI \clisp\ standard. Because of the
+acceptance of \clisp, the goals of this group differed from those of
+the original designers. These new goals included stricter
+standardization for portability, an object-oriented programming
+system, a condition system, iteration facilities, and a way to handle
+large character sets.  To accommodate those
+goals, a new language specification, this
+document, was developed.
+ 
+\endsubSection%{History}
+

concept-logical-pathnames.tex

@@ -0,0 +1,169 @@
+% -*- Mode: TeX -*-
+
+\beginSubsection{Syntax of Logical Pathname Namestrings}
+\DefineSection{LogPathNamestrings}
+
+\issue{PATHNAME-LOGICAL:ADD}
+The syntax of a \term{logical pathname} \term{namestring} is as follows.
+%Added for clarity. -kmp 26-Jun-93
+(Note that unlike many notational descriptions in this document,
+ this is a syntactic description of character sequences,
+ not a structural description of \term{objects}.)
+
+\auxbnf{logical-pathname}%
+{\brac{\down{host} \param{host-marker}} \CR
+ \brac{\down{\param{relative-directory-marker}}}
+ \star{\curly{\down{directory} \param{directory-marker}}} \CR
+ \brac{\down{name}} 
+ \brac{\param{type-marker} \down{type} 
+ \brac{\param{version-marker} \down{version}}}}
+
+\auxbnf{host}{\down{word}}
+\auxbnf{directory}{\down{word} | \down{wildcard-word} | \down{wild-inferiors-word}}
+\auxbnf{name}{\down{word} | \down{wildcard-word}}
+\auxbnf{type}{\down{word} | \down{wildcard-word}}
+\auxbnf{version}{\down{pos-int} | \param{newest-word} | \param{wildcard-version}}
+
+\param{host-marker}---a \term{colon}.
+
+\param{relative-directory-marker}---a \term{semicolon}.
+
+\param{directory-marker}---a \term{semicolon}.
+
+\param{type-marker}---a \term{dot}.
+
+\param{version-marker}---a \term{dot}.
+
+\param{wild-inferiors-word}---The two character sequence ``\f{**}'' (two \term{asterisks}).
+
+\param{newest-word}---The six character sequence ``\f{newest}'' 
+		   or the six character sequence ``\f{NEWEST}''.
+
+\param{wildcard-version}---an \term{asterisk}.
+
+\param{wildcard-word}---one or more \term{asterisks}, uppercase letters,
+   digits, and hyphens, including at least one \term{asterisk}, 
+   with no two \term{asterisks} adjacent.
+
+\param{word}---one or more uppercase letters, digits, and hyphens.
+
+\param{pos-int}---a positive \term{integer}.
+
+\beginsubsubsection{Additional Information about Parsing Logical Pathname Namestrings}
+
+\beginsubsubsubsection{The Host part of a Logical Pathname Namestring}
+
+The \param{host} must have been defined as a \term{logical pathname} host;
+this can be done by using \macref{setf} of \funref{logical-pathname-translations}.
+
+The \term{logical pathname} host name \f{"SYS"} is reserved for the implementation.
+The existence and meaning of \f{SYS:} \term{logical pathnames} 
+is \term{implementation-defined}.
+ 
+\endsubsubsubsection%{The Host part of a Logical Pathname Namestring}
+
+\beginsubsubsubsection{The Device part of a Logical Pathname Namestring}
+ 
+There is no syntax for a \term{logical pathname} device since
+the device component of a \term{logical pathname} is always \kwd{unspecific};
+\seesection\LogicalPathCompUnspecific.
+
+\endsubsubsubsection%{The Device part of a Logical Pathname Namestring}
+
+\beginsubsubsubsection{The Directory part of a Logical Pathname Namestring}
+
+If a \param{relative-directory-marker} precedes the \param{directories},
+the directory component parsed is as \term{relative};
+otherwise, the directory component is parsed as \term{absolute}.
+
+If a \param{wild-inferiors-marker} is specified,
+it parses into \kwd{wild-inferiors}.
+ 
+\endsubsubsubsection%{The Directory part of a Logical Pathname Namestring}
+
+\beginsubsubsubsection{The Type part of a Logical Pathname Namestring}
+
+The \param{type} of a \term{logical pathname} for a \term{source file}
+is \f{"LISP"}.   This should be translated into whatever type is 
+appropriate in a physical pathname.
+ 
+\endsubsubsubsection%{The Type part of a Logical Pathname Namestring}
+
+\beginsubsubsubsection{The Version part of a Logical Pathname Namestring}
+
+Some \term{file systems} do not have \param{versions}. 
+\term{Logical pathname} translation to such a \term{file system}
+ignores the \param{version}.
+This implies that a program cannot rely on being able to store
+more than one version of a file named by a \term{logical pathname}.
+
+If a \param{wildcard-version} is specified,
+it parses into \kwd{wild}.
+
+\endsubsubsubsection%{The Version part of a Logical Pathname Namestring}
+
+\beginsubsubsubsection{Wildcard Words in a Logical Pathname Namestring}
+
+Each \term{asterisk} in a \param{wildcard-word} matches a sequence of 
+zero or more characters.  The \param{wildcard-word} ``\f{*}'' 
+parses into \kwd{wild}; other \term{wildcard-words} parse into \term{strings}.
+ 
+\endsubsubsubsection%{Wildcard Words in a Logical Pathname Namestring}
+
+\beginsubsubsubsection{Lowercase Letters in a Logical Pathname Namestring}
+
+When parsing \param{words} and \param{wildcard-words},
+lowercase letters are translated to uppercase.
+
+\endsubsubsubsection%{Lowercase Letters in a Logical Pathname Namestring}
+
+\beginsubsubsubsection{Other Syntax in a Logical Pathname Namestring}
+
+The consequences of using characters other than those specified here
+in a \term{logical pathname} \term{namestring} are unspecified.
+
+%% !!! What does this mean??  This section is supposed to be about syntax, 
+%%     not component values.  Sigh.  -kmp 26-Jun-93
+The consequences of using any value not specified here as a 
+\term{logical pathname} component are unspecified.
+
+\endsubsubsubsection%{Other Syntax in a Logical Pathname Namestring}
+
+%This wasn't a valid reference.
+%See ``Input/Output'' for parsing and file manipulation details.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\endsubsubsection%{Additional Information about Parsing Logical Pathname Namestrings}
+
+\endSubsection%{Syntax of Logical Pathname Namestrings}
+
+\beginSubsection{Logical Pathname Components}
+
+\beginsubsubsection{Unspecific Components of a Logical Pathname}
+\DefineSection{LogicalPathCompUnspecific}
+
+The device component of a \term{logical pathname} is always \kwd{unspecific};
+no other component of a \term {logical pathname} can be \kwd{unspecific}.  
+
+\endsubsubsection%{Unspecific Components of a Logical Pathname}
+
+\beginsubsubsection{Null Strings as Components of a Logical Pathname}
+
+The null string, \f{""}, is not a valid value for any component of a \term{logical pathname}.
+%% I removed the following because:
+%%   - it's redundant with the syntax info above
+%%   - I doubt it's really the reason
+%%   - it's not sufficient to cause this: e.g., you might assume that
+%%       (probe-file "X:FOO;*.LISP") could return a logical pathname containing
+%%     a null string name even though you didn't type it in, since * is not a zero-char
+%%     string but only matches one.  The resulting logical pathname might have no 
+%%     printed representation.  But the previous sentence makes a stronger claim:  it
+%%     says that there is no such file, whether printable or not.  So the following
+%%     cannot be the reason.
+%%  -kmp 26-Jun-93
+%
+% since it is neither a \param{word} nor a \param{wildcard-word}.
+
+\endsubsubsection%{Null Strings as Components of a Logical Pathname}
+
+\endSubsection%{Logical Pathname Components}

concept-loop.tex

@@ -0,0 +1,2389 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Overview of the Loop Facility}
+
+\Themacro{loop} performs iteration.
+
+\beginsubsubsection{Simple vs Extended Loop}
+
+\macref{loop} \term{forms} are partitioned into two categories: 
+     simple \macref{loop} \term{forms} 
+ and extended \macref{loop} \term{forms}.
+
+\beginsubsubsubsection{Simple Loop}
+\DefineSection{SimpleLoop}
+
+A simple \macref{loop} \term{form} is one that has a body containing
+only \term{compound forms}.
+%% 7.8.1 3
+Each \term{form} is \term{evaluated} in turn from left to right.
+When the last \param{form} has been \term{evaluated}, 
+then the first \param{form} is evaluated again, and so on, in a never-ending cycle.
+%% 7.8.1 4
+A simple \macref{loop} \term{form} establishes an \term{implicit block} named \nil.
+The execution of a simple \macref{loop} can be terminated by explicitly
+transfering control to the \term{implicit block} (using \macref{return} or
+\specref{return-from}) or to some \term{exit point} outside of the \term{block} 
+(\eg using \specref{throw}, \specref{go}, or \specref{return-from}).
+
+%KMP: What about LOOP-FINISH here?
+%     Test cases: (loop (loop-finish)) and (loop do (loop (loop-finish))).
+%     Mail sent to X3J13 saying I was going to make this explicitly vague,
+%     since some implementations 
+%     See the LOOP-FINISH dictionary entry.
+
+\endsubsubsubsection%{Simple Loop}
+%========================================
+\beginsubsubsubsection{Extended Loop}
+
+An extended \macref{loop} \term{form} is one that has a body containing
+\term{atomic} \term{expressions}.  When \themacro{loop} processes such a
+\term{form}, it invokes a facility that is commonly called ``the Loop Facility.''
+
+The Loop Facility provides standardized access to mechanisms commonly used 
+in iterations through Loop schemas, which are introduced by \term{loop keywords}.
+
+The body of an extended \macref{loop} \term{form} is divided into \macref{loop} clauses,
+each which is in turn made up of \term{loop keywords} and \term{forms}. 
+
+\endsubsubsubsection%{Extended Loop}
+
+\endsubsubsection%{Simple vs Extended Loop}
+
+\beginsubsubsection{Loop Keywords}
+
+%2
+\term{Loop keywords} are not true \term{keywords}\meaning{1}; 
+they are special \term{symbols}, recognized by \term{name} rather than \term{object} identity,
+that are meaningful only to the \macref{loop} facility.
+A \term{loop keyword} is a \term{symbol} but is recognized by its \term{name}
+(not its identity), regardless of the \term{packages} in which it is \term{accessible}.  
+
+\issue{JUN90-TRIVIAL-ISSUES:11}
+In general, \term{loop keywords} are not \term{external symbols} of \thepackage{common-lisp},
+except in the coincidental situation that a \term{symbol} with the same name as a
+\term{loop keyword} was needed for some other purpose in \clisp.  For example,
+there is a \term{symbol} in \thepackage{common-lisp} whose \term{name} is \f{"UNLESS"} but
+not one whose \term{name} is \f{"UNTIL"}.
+\endissue{JUN90-TRIVIAL-ISSUES:11}
+
+If no \term{loop keywords} are supplied in a \macref{loop} \term{form},
+the Loop Facility executes the loop body repeatedly; \seesection\SimpleLoop.
+
+\endsubsubsection%{Loop Keywords}
+
+\beginsubsubsection{Parsing Loop Clauses}
+ 
+%7
+The syntactic parts of an extended \macref{loop} \term{form} are called clauses; 
+%the scope \reviewer{Barmar: what meaning of scope?}%!!!
+%of each clause
+the rules for parsing are determined by 
+%the parsing of
+that clause's keyword.
+The following example shows a \macref{loop} \term{form} with six clauses:
+ 
+\code
+ (loop for i from 1 to (compute-top-value)       ; first clause
+       while (not (unacceptable i))              ; second clause
+       collect (square i)                        ; third clause
+       do (format t "Working on ~D now" i)       ; fourth clause
+       when (evenp i)                            ; fifth clause
+         do (format t "~D is a non-odd number" i)
+       finally (format t "About to exit!"))      ; sixth clause
+\endcode
+ 
+%8 
+Each \term{loop keyword} introduces 
+either a compound loop clause or a simple loop clause
+that can consist of a \term{loop keyword} followed by a single \term{form}.
+The number of \term{forms} in a clause is determined by the \term{loop keyword} 
+that begins the clause and by the auxiliary keywords in the clause.
+The keywords \loopref{do}, 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+\loopref{doing},
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+\loopref{initially}, and \loopref{finally} 
+are the only loop keywords that can take any number of \term{forms} and 
+group them as an \term{implicit progn}.
+
+%9 
+Loop clauses can contain auxiliary keywords, which are sometimes
+called prepositions.  For example, the first clause in the code
+above includes the prepositions \loopref{from} and \loopref{to}, 
+which mark the value from which stepping begins and the value at which stepping
+ends.
+
+For detailed information about \macref{loop} syntax,
+\seemac{loop}.
+
+\endsubsubsection%{Parsing Loop Clauses}
+ 
+\beginsubsubsection{Expanding Loop Forms}
+
+%!!! Barmar: This seems to legislate the implementation. We should define the meaning
+%      and let the implementors worry about how to code it.
+
+%3
+A \macref{loop} \term{macro form} expands into a \term{form} containing
+%one or more \term{lambda expressions} for the local \term{binding} of loop variables
+one or more binding forms (that \term{establish} \term{bindings} of loop variables)
+and a \specref{block} and a \specref{tagbody} (that express a looping control 
+structure). The variables established in \macref{loop} are bound as
+if by \specref{let} or \misc{lambda}.  
+
+Implementations can interleave the setting of initial values with the \term{bindings}.  
+However, the assignment of the initial values is always calculated in the order
+specified by the user.  A variable is thus sometimes bound to a meaningless value 
+of the correct \term{type}, and then later in the prologue it is set to the true
+initial value by using \specref{setq}.
+\issue{LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE}
+One implication of this interleaving is that it is \term{implementation-dependent}
+whether the \term{lexical environment} in which the initial value \term{forms}
+(variously called the \param{form1}, \param{form2}, \param{form3}, \param{step-fun},
+ \param{vector}, \param{hash-table}, and \param{package}) in any \param{for-as-subclause},
+except \param{for-as-equals-then},
+are \term{evaluated} includes only the loop variables preceding that \term{form}
+or includes more or all of the loop variables;
+the \param{form1} and \param{form2} in a \param{for-as-equals-then} form
+includes the \term{lexical environment} of all the loop variables.
+\endissue{LOOP-INITFORM-ENVIRONMENT:PARTIAL-INTERLEAVING-VAGUE}
+ 
+%4
+After the \term{form} is expanded, it consists of three basic parts in the 
+\specref{tagbody}: 
+      the loop prologue,
+      the loop body,
+  and the loop epilogue.
+
+\beginlist
+\itemitem{\b{Loop prologue}}
+ 
+The loop prologue contains \term{forms} 
+that are executed before iteration begins, such as
+any automatic variable initializations prescribed 
+by the \param{variable} clauses, along with any \loopref{initially} clauses
+in the order they appear in the source.
+ 
+\itemitem{\b{Loop body}}
+ 
+The loop body contains those \term{forms} that are executed during iteration, 
+including application-specific calculations, termination tests,
+and variable \term{stepping}\meaning{1}.
+                           
+\itemitem{\b{Loop epilogue}}
+ 
+The loop epilogue contains \term{forms} that are executed after iteration 
+terminates, such as \loopref{finally} clauses, if any, along
+with any implicit return value from an \param{accumulation} clause or
+an \param{termination-test} clause.
+
+\endlist
+ 
+%5
+Some clauses from the source \term{form}
+contribute code only to the loop prologue; these clauses must
+  come before other clauses that are in the main body of the \macref{loop} form.            
+  Others contribute code only to the loop epilogue.
+  All other clauses contribute to the final 
+translated \term{form} in the same 
+  order given in the original source \term{form} of the \macref{loop}.
+
+%6
+Expansion of the \macref{loop} macro produces an \term{implicit block} named \nil\ 
+\issue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+unless \loopref{named} is supplied.
+\endissue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+Thus, \specref{return-from} (and sometimes \macref{return})
+can be used to return values from \macref{loop} or to exit \macref{loop}.
+%%Barmar: Has nothing to do with LOOP specifically.
+%   Within the executable parts of loop clauses and around the entire
+%   \macref{loop} form, variables can be bound by using \specref{let}.
+
+\endsubsubsection%{Expanding Loop Forms}
+
+\beginsubsubsection{Summary of Loop Clauses}
+ 
+%11
+Loop clauses fall into one of the following categories:
+ 
+\beginsubsubsubsection{Summary of Variable Initialization and Stepping Clauses}
+
+The \loopref{for} and \loopref{as} constructs provide iteration control clauses
+that establish a variable to be initialized.
+\loopref{for} and \loopref{as} clauses can be combined with the loop
+keyword \loopref{and} to get \term{parallel} initialization and \term{stepping}\meaning{1}.
+Otherwise, the initialization and \term{stepping}\meaning{1} are \term{sequential}.
+
+%\issue{LOOP-AND-DISCREPANCY:NO-REITERATION}
+% When two or more such clauses are joined with \loopref{and}, 
+% clauses after the first do not have \loopref{for} or \loopref{as} before them.
+%\endissue{LOOP-AND-DISCREPANCY:NO-REITERATION}
+
+The \loopref{with} construct is similar to a single \specref{let} clause.
+\loopref{with} clauses can be combined using the \term{loop keyword} \loopref{and}
+to get \term{parallel} initialization.
+
+%% Removed per Barmar.  See Termination Clauses.
+%   The \loopref{repeat} construct causes iteration to terminate after 
+%   a specified number of times.  It uses an internal variable 
+%   to keep track of the number of iterations.
+
+For more information, \seesection\LOOPVarInitAndStep.
+
+\endsubsubsubsection%{Summary of Variable Initialization and Stepping Clauses}
+
+\beginsubsubsubsection{Summary of Value Accumulation Clauses}
+ 
+The \loopref{collect} (or \loopref{collecting}) construct
+takes one \term{form} in its clause
+and adds the value of that \term{form} to the end of a \term{list} 
+of values.  By default, the \term{list} of values is returned 
+when the \macref{loop} finishes.
+ 
+The \loopref{append} (or \loopref{appending}) construct 
+takes one \term{form} in its clause
+and appends the value of that \term{form} to the end of a \term{list}
+of values.  By default, the \term{list} of values is returned when the 
+\macref{loop} finishes.
+ 
+The \loopref{nconc} (or \loopref{nconcing}) construct 
+is similar to the \loopref{append} construct,  
+but its \term{list} values are concatenated as if by the function
+\loopref{nconc}.  By default, the \term{list} of values is returned when 
+the \macref{loop} finishes.
+ 
+The \loopref{sum} (or \loopref{summing}) construct 
+takes one \term{form} in its clause 
+that must evaluate to a \term{number} and accumulates the sum of all these
+\term{numbers}.  By default, the cumulative sum is returned when the
+\macref{loop} finishes.
+ 
+The \loopref{count} (or \loopref{counting}) construct 
+takes one \term{form} in its clause 
+and counts the number of times that the \term{form} evaluates to \term{true}.
+By default, the count is returned when the \macref{loop} finishes.
+ 
+The \loopref{minimize} (or \loopref{minimizing}) construct
+takes one \term{form} in its clause 
+and determines the minimum value obtained by evaluating that \term{form}.
+By default, the minimum value is returned when the \macref{loop} finishes.
+ 
+The \loopref{maximize} (or \loopref{maximizing}) construct
+takes one \term{form} in its clause 
+and determines the maximum value obtained by evaluating that \term{form}.
+By default, the maximum value is returned when the \macref{loop} finishes.
+
+For more information, \seesection\LOOPValAcc.
+
+\endsubsubsubsection%{Summary of Value Accumulation Clauses}
+
+\beginsubsubsubsection{Summary of Termination Test Clauses}
+ 
+The \loopref{for} and \loopref{as} constructs provide a termination test
+that is determined by the iteration control clause.
+ 
+The \loopref{repeat} construct causes termination after a specified
+number of iterations.
+%Moved from text removed by Barmar above, so it doesn't get lost. -kmp 30-Jul-91
+(It uses an internal variable to keep track of the number of iterations.)
+ 
+The \loopref{while} construct takes one \term{form}, a \param{test}, 
+and terminates the iteration if the \param{test} evaluates to \term{false}.
+%!!! Barmar thinks this is not necessary:
+A \loopref{while} clause is equivalent to the expression 
+\f{(if (not \param{test}) (loop-finish))}.
+ 
+The \loopref{until} construct is the inverse of \loopref{while};
+it terminates the iteration if the \param{test} evaluates to
+any \term{non-nil} value.
+%!!! Barmar thinks this is not necessary:
+An \loopref{until} clause is equivalent to the expression
+\hbox{\f{(if \param{test} (loop-finish))}}.
+ 
+The \loopref{always} construct takes one \term{form} and
+terminates the \macref{loop} if the \term{form} ever evaluates to \term{false};
+in this case, the \macref{loop} \term{form} returns \nil.
+Otherwise, it provides a default return value of \t.
+ 
+The \loopref{never} construct takes one \term{form} and
+terminates the \macref{loop} if the \term{form} ever evaluates to \term{true};
+in this case, the \macref{loop} \term{form} returns \nil.
+Otherwise, it provides a default return value of \t.
+ 
+The \loopref{thereis} construct takes one \term{form} and
+terminates the \macref{loop} if the \term{form} ever evaluates to
+a \term{non-nil} \term{object};
+in this case, the \macref{loop} \term{form} returns that \term{object}.
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+Otherwise, it provides a default return value of \nil.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+
+%Added per Barmar:
+If multiple termination test clauses are specified, 
+the \macref{loop} \term{form} terminates if any are satisfied.
+
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+% Note also that the \macref{loop-finish} macro terminates iteration and returns any
+% accumulated result.  Any \loopref{finally} clauses that are supplied are evaluated.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+ 
+For more information, \seesection\LOOPTermTest.
+
+\endsubsubsubsection%{Summary of Termination Test Clauses}
+
+\beginsubsubsubsection{Summary of Unconditional Execution Clauses}
+ 
+The \loopref{do} (or \loopref{doing}) construct evaluates all \term{forms} in its clause.
+ 
+The \loopref{return} construct takes one 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+% \term{form} and returns its value.
+  \term{form}. Any \term{values} returned by the \term{form} are
+  immediately returned by the \macref{loop} form.
+%  It is equivalent to the clause \f{do (return \i{value})}.
+   It is equivalent to the clause
+   \f{do (return-from \i{block-name} \i{value})},
+   where \i{block-name} is the name specified in a \loopref{named}
+   clause, or \nil\ if there is no \loopref{named} clause.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+
+For more information, \seesection\LOOPUnconditional.
+
+\endsubsubsubsection%{Summary of Unconditional Execution Clauses}
+
+\beginsubsubsubsection{Summary of Conditional Execution Clauses}
+
+The \loopref{if} and \loopref{when} constructs take one \term{form} as a test 
+and a clause that is executed when the test \term{yields} \term{true}.
+The clause can be a value accumulation, unconditional, or 
+another conditional clause; it can also be any combination
+of such clauses connected by \theloopkeyword{and}.
+ 
+\Theloopconstruct{unless} is similar to \theloopconstruct{when}
+except that it complements the test result.
+
+\Theloopconstruct{else} provides an optional component of \loopref{if},
+\loopref{when}, and \loopref{unless} clauses that is executed 
+     when an \loopref{if} or \loopref{when} test \term{yields} \term{false}
+  or when an \loopref{unless} test \term{yields} \term{true}.
+The component is one of the clauses described under \loopref{if}.
+
+\Theloopconstruct{end} provides an optional component to mark the
+end of a conditional clause.
+ 
+For more information, \seesection\LOOPConditional.
+
+\endsubsubsubsection%{Summary of Conditional Execution Clauses}
+
+\beginsubsubsubsection{Summary of Miscellaneous Clauses}
+ 
+\Theloopconstruct{named} gives a name for the \term{block} of the loop.
+
+\Theloopconstruct{initially} causes its \term{forms} to be
+evaluated in the loop prologue, which precedes all \macref{loop} code
+except for initial settings supplied by the constructs \loopref{with},
+\loopref{for}, or \loopref{as}.
+ 
+\Theloopconstruct{finally} causes its \term{forms} to
+be evaluated in the loop epilogue after normal iteration terminates.
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+%  An unconditional clause can also follow \theloopkeyword{finally}.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX} 
+
+For more information, \seesection\LOOPMisc.
+
+\endsubsubsubsection%{Summary of Miscellaneous Clauses}
+
+\endsubsubsection%{Summary of Loop Clauses}
+
+\beginsubsubsection{Order of Execution}\idxtext{order of evaluation}\idxtext{evaluation order}
+
+ 
+%10
+  With the exceptions listed below, clauses are executed in the loop body
+  in the order in which they appear in the source.  Execution is repeated 
+  until a clause
+  terminates the \macref{loop} or until a \macref{return}, \specref{go},
+  or \specref{throw} form is encountered 
+%I added this next. -kmp 10-Feb-92
+which transfers control to a point outside of the loop.
+ The following actions are
+  exceptions to the linear order of execution:
+ 
+\beginlist
+
+\itemitem{\bull}  All variables are initialized first, 
+  regardless of where the establishing clauses appear in the
+  source.  The order of initialization follows the order of these clauses.
+                                    
+\itemitem{\bull}  The code for any \loopref{initially} clauses is collected
+  into one \specref{progn} in the order in which the clauses appear in
+  the source.  The collected code is executed once in the loop prologue
+  after any implicit variable initializations.
+ 
+\itemitem{\bull}    The code for any \loopref{finally} clauses is collected 
+  into one \specref{progn} in the order in which the clauses appear in
+  the source.  The collected code is executed once in the loop epilogue
+  before any implicit values from the accumulation clauses are returned.
+  Explicit returns anywhere in the source, however, will exit the 
+  \macref{loop} without executing the epilogue code.
+                     
+\itemitem{\bull}  A \loopref{with} clause introduces a variable \term{binding}
+  and an optional initial value.  The initial values are calculated 
+  in the order in which the \loopref{with} clauses occur.
+ 
+\itemitem{\bull}  
+  Iteration control clauses implicitly perform the following actions:
+ 
+\beginlist
+\itemitem{--}  initialize variables;
+ 
+\itemitem{--}  \term{step} variables, generally 
+between each execution of the loop body;
+ 
+\itemitem{--} perform termination tests, 
+generally just before the execution of the
+  loop body.
+ 
+  \endlist
+  \endlist
+ 
+\endsubsubsection%{Order of Execution}
+
+\beginsubsubsection{Destructuring}
+\DefineSection{DestructuringLOOPVars}
+
+The \param{d-type-spec} argument is used for destructuring.
+If the
+\param{d-type-spec} argument consists solely of \thetype{fixnum},
+\typeref{float}, \typeref{t}, or \nil, the \loopref{of-type} keyword is optional.
+The \loopref{of-type} construct is optional in these cases to provide backwards
+compatibility; thus, the following two expressions are the same:
+
+%!!! Barmar: Examples belong in the examples section
+\code
+;;; This expression uses the old syntax for type specifiers.
+ (loop for i fixnum upfrom 3 ...)
+ 
+;;; This expression uses the new syntax for type specifiers.
+ (loop for i of-type fixnum upfrom 3 ...)
+
+;; Declare X and Y to be of type VECTOR and FIXNUM respectively.
+ (loop for (x y) of-type (vector fixnum) 
+       in l do ...)
+\endcode
+ 
+A \term{type specifier} for a destructuring pattern is a \term{tree} of 
+\term{type specifiers} with the same shape as the \term{tree} of
+\term{variable} \term{names}, with the following exceptions:
+ 
+\beginlist 
+\itemitem{\bull}
+When aligning the \term{trees}, an \term{atom} in the
+\term{tree} of \term{type specifiers} that matches a \term{cons} 
+in the variable tree declares the same \term{type} for each variable
+in the subtree rooted at the \term{cons}.
+ 
+\itemitem{\bull} 
+A \term{cons} in the \term{tree} of \term{type specifiers} that 
+matches an \term{atom} in the \term{tree} of \term{variable} \term{names}
+is a \term{compound type specifer}.
+ 
+\endlist
+ 
+Destructuring allows \term{binding} of a set of variables to a corresponding
+set of values anywhere that a value can normally be bound to a single
+variable.  During \macref{loop} expansion, 
+each variable in the variable list
+is matched with the values in the values list.  If there are more variables
+in the variable list than there are values in the values list, the 
+remaining variables are given a value of \nil.  If there are more
+values than variables listed, the extra values are discarded.
+
+ 
+To assign values from a list to the variables \f{a},
+\f{b}, and \f{c}, the \loopref{for} clause could be used to
+bind the variable \f{numlist} to the 
+\term{car} of the supplied \param{form},
+and then another \loopref{for} clause could be used to bind the variables
+\f{a}, \f{b}, and \f{c} \term{sequentially}.  
+
+\issue{LOOP-AND-DISCREPANCY:NO-REITERATION}
+\code
+;; Collect values by using FOR constructs.
+ (loop for numlist in '((1 2 4.0) (5 6 8.3) (8 9 10.4))
+       for a of-type integer = (first numlist)
+       and b of-type integer = (second numlist)
+       and c of-type float = (third numlist)
+       collect (list c b a))
+\EV ((4.0 2 1) (8.3 6 5) (10.4 9 8))
+\endcode
+\endissue{LOOP-AND-DISCREPANCY:NO-REITERATION}
+ 
+Destructuring makes this process easier by allowing the variables to
+be bound in each loop iteration.  
+\term{Types} can be declared by using a 
+list of \param{type-spec} arguments.  If 
+all the \term{types}
+are the same, a shorthand destructuring syntax can be used, as the second
+example illustrates.
+
+\code
+;; Destructuring simplifies the process.
+ (loop for (a b c) of-type (integer integer float) in
+       '((1 2 4.0) (5 6 8.3) (8 9 10.4))
+       collect (list c b a))
+\EV ((4.0 2 1) (8.3 6 5) (10.4 9 8))
+ 
+
+;; If all the types are the same, this way is even simpler.
+ (loop for (a b c) of-type float in
+       '((1.0 2.0 4.0) (5.0 6.0 8.3) (8.0 9.0 10.4))
+       collect (list c b a))
+\EV ((4.0 2.0 1.0) (8.3 6.0 5.0) (10.4 9.0 8.0))
+\endcode
+ 
+ 
+ 
+If destructuring is used to declare or initialize a number of groups
+of variables into \term{types}, the \term{loop keyword} \loopref{and} can be used
+to simplify the process further.
+\issue{LOOP-AND-DISCREPANCY:NO-REITERATION} 
+\code
+;; Initialize and declare variables in parallel by using the AND construct.\kern-7pt
+ (loop with (a b) of-type float = '(1.0 2.0)
+       and (c d) of-type integer = '(3 4)
+       and (e f)
+       return (list a b c d e f))
+\EV (1.0 2.0 3 4 NIL NIL)
+\endcode
+\endissue{LOOP-AND-DISCREPANCY:NO-REITERATION} 
+ 
+ 
+If \nil\ is used in a destructuring list, no variable is provided for
+its place.
+ 
+\code
+ (loop for (a nil b) = '(1 2 3)
+       do (return (list a b)))
+\EV (1 3)
+\endcode
+ 
+Note that 
+%% Replaced per Moon #42 (first public review) -kmp 6-May-93
+%nonstandard lists
+\term{dotted lists}
+can specify destructuring.
+ 
+\code
+ (loop for (x . y) = '(1 . 2)
+       do (return y))
+\EV 2
+ (loop for ((a . b) (c . d)) of-type ((float . float) (integer . integer)) in
+       '(((1.2 . 2.4) (3 . 4)) ((3.4 . 4.6) (5 . 6)))
+       collect (list a b c d))
+\EV ((1.2 2.4 3 4) (3.4 4.6 5 6))
+\endcode
+ 
+An error \oftype{program-error} is signaled (at macro expansion time)
+if the same variable is bound twice in any variable-binding
+clause of a single \macref{loop} expression.  Such variables include
+local variables, iteration control variables, and variables found by
+destructuring.
+
+\endsubsubsection%{Destructuring}
+
+\beginsubsubsection{Restrictions on Side-Effects}
+
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+\Seesection\TraversalRules.
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\endsubsubsection%{Restrictions on Side-Effects}
+
+\endsubsection%{Overview of the Loop Facility}
+
+\beginsubsection{Variable Initialization and Stepping Clauses}
+\DefineSection{LOOPVarInitAndStep}
+ 
+\beginsubsubsection{Iteration Control}
+
+Iteration control clauses allow direction of \macref{loop} iteration.
+The \term{loop keywords} \loopref{for} and \loopref{as}
+%, and \loopref{repeat}
+designate iteration control clauses.
+Iteration control clauses differ with respect to the specification of
+termination tests and to the initialization and \term{stepping}\meaning{1}
+of loop variables.  Iteration clauses by themselves
+do not cause the Loop Facility to return values, but they
+can be used in conjunction with value-accumulation clauses to
+return values.  
+ 
+All variables are initialized in the loop prologue.  
+A \term{variable} \term{binding} has \term{lexical scope}
+unless it is proclaimed \declref{special};
+thus, by default, the variable can be \term{accessed} only by \term{forms} 
+that lie textually within the \macref{loop}.
+Stepping assignments are made in the loop body before any other \term{forms}
+are evaluated in the body.  
+ 
+The variable argument in iteration control clauses can be a 
+destructuring list.  A destructuring list
+is a \term{tree} whose \term{non-nil} \term{atoms} are \term{variable} \term{names}.
+\Seesection\DestructuringLOOPVars.
+ 
+The iteration control clauses \loopref{for}, \loopref{as},  and \loopref{repeat} 
+must precede any other loop clauses, except
+  \loopref{initially}, \loopref{with}, and \loopref{named},
+since they establish variable \term{bindings}.  
+When iteration control clauses are
+used in a \macref{loop},
+%Next line added for JonL:
+the corresponding
+termination tests in the loop body are evaluated
+before any other loop body code is executed.
+ 
+ 
+If multiple iteration clauses are used to control iteration, variable
+initialization and \term{stepping}\meaning{1} occur \term{sequentially} by default.  
+The \loopref{and} construct can be used to connect two or more
+iteration clauses when \term{sequential} \term{binding} and 
+\term{stepping}\meaning{1} are not necessary.
+The iteration behavior of clauses joined by \loopref{and}
+is analogous to the behavior of the macro \macref{do} with
+respect to \macref{do*}.
+
+The \loopref{for} and \loopref{as} clauses iterate by using one or more local 
+loop  variables that are initialized to some value and that 
+can be modified or \term{stepped}\meaning{1} after each iteration.  
+For these clauses, iteration terminates when a local
+variable reaches some supplied value or when some other loop clause
+terminates iteration.
+%!!! Barmar: These aren't the only ways for/as can step the variables.
+At each iteration, variables can be 
+   \term{stepped}\meaning{1} by an increment or a decrement
+or can be assigned a new value by the evaluation of a \term{form}).
+Destructuring can be used to assign 
+%% Removed per barmar--It is also used during stepping.
+%initial 
+values to variables during iteration. 
+
+The \loopref{for} and \loopref{as} keywords are synonyms; they can be used
+interchangeably.  There are seven syntactic formats for these constructs.
+In each syntactic format, the \term{type} of
+\param{var} can be supplied by the optional \param{type-spec}
+argument.  If \param{var} is a destructuring list, the \term{type}
+supplied by the \param{type-spec} argument must appropriately match
+the elements of the list.  
+%!!! Barmar: "conventions" belong in the "Notes" section.
+By convention, \loopref{for} introduces new iterations and \loopref{as}
+introduces iterations that depend on a previous iteration specification.
+
+\beginsubsubsubsection{The for-as-arithmetic subclause}
+
+In the \i{for-as-arithmetic} subclause, the \loopref{for} 
+or \loopref{as} construct iterates from the value supplied by
+\param{form1} to the value supplied by \param{form2} in increments or
+decrements denoted by \param{form3}. Each
+expression is evaluated only once and must evaluate to a \term{number}.  
+The variable \param{var} is bound to the value of 
+\param{form1} in the first iteration and is \term{stepped}\meaning{1}
+by the value of \param{form3} in each succeeding iteration,
+or by 1 if \param{form3} is not provided.  
+The following \term{loop keywords} serve as valid prepositions within this 
+syntax.
+At least one of the 
+%three classes of
+prepositions must be used; 
+and at most one from each line may be used in a single subclause.
+
+\beginlist                 
+ 
+\itemitem{\tt from | downfrom | upfrom}
+ 
+\itemitem{\tt to | downto | upto | below | above}
+ 
+\itemitem{\tt by}
+\endlist
+
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+The prepositional phrases in each subclause may appear in any order.
+For example, either ``\f{from x by y}'' or ``\f{by y from x}'' is permitted.
+However, because left-to-right order of evaluation is preserved,
+the effects will be different in the case of side effects.
+\idxtext{order of evaluation}\idxtext{evaluation order}%
+Consider:
+
+\code
+(let ((x 1)) (loop for i from x by (incf x) to 10 collect i))
+\EV (1 3 5 7 9)
+(let ((x 1)) (loop for i by (incf x) from x to 10 collect i))
+\EV (2 4 6 8 10)
+\endcode
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+ 
+The descriptions of the prepositions follow:
+ 
+\beginlist
+\itemitem{\tt from}
+ 
+The \term{loop keyword} \loopref{from} specifies the value from which
+\term{stepping}\meaning{1} begins, as supplied by \param{form1}.  
+\term{Stepping}\meaning{1} is incremental by default.  If 
+decremental \term{stepping}\meaning{1} is desired, 
+the preposition \loopref{downto} 
+or \loopref{above} must be used with \param{form2}.  For incremental
+\term{stepping}\meaning{1}, the default \loopref{from} value is 0.
+
+\itemitem{\tt downfrom, upfrom}
+ 
+The \term{loop keyword} \loopref{downfrom} 
+indicates that the variable \param{var} is decreased in decrements
+supplied by \param{form3}; the \term{loop keyword} \loopref{upfrom} indicates that 
+\param{var} is increased in increments supplied by \param{form3}.
+ 
+\itemitem{\tt to}
+                                                  
+The \term{loop keyword} \loopref{to} marks the end value
+for \term{stepping}\meaning{1} supplied in \param{form2}.
+\term{Stepping}\meaning{1} is incremental by default.
+If decremental \term{stepping}\meaning{1} is desired, 
+the preposition \loopref{downfrom} must be used with \param{form1},
+or else the preposition \loopref{downto} or \loopref{above} should be used instead
+   of \loopref{to} with \param{form2}.
+              
+\itemitem{\tt downto, upto}
+ 
+The \term{loop keyword} \loopref{downto} specifies decremental \term{stepping};
+the \term{loop keyword} \loopref{upto} specifies incremental \term{stepping}.
+In both cases, the amount of change on each step is specified by \param{form3},
+and the \macref{loop} terminates when the variable \param{var} passes 
+the value of \param{form2}.
+Since there is no default for \param{form1} in decremental \term{stepping}\meaning{1},
+a \param{form1} value must be supplied (using \loopref{from} or \loopref{downfrom})
+when \loopref{downto} is supplied.
+ 
+\itemitem{\tt below, above}
+ 
+The \term{loop keywords} \loopref{below} and \loopref{above} are analogous to
+\loopref{upto} and \loopref{downto} respectively.  These keywords stop
+iteration just before the value of the variable \param{var} reaches the value 
+supplied by \param{form2}; the end value of \param{form2} is not included.
+Since there is no default for \param{form1} in decremental \term{stepping}\meaning{1},
+a \param{form1} value must be supplied (using \loopref{from} or \loopref{downfrom})
+when \loopref{above} is supplied.
+ 
+\itemitem{\tt by}
+ 
+The \term{loop keyword} \loopref{by} marks the increment or decrement supplied by
+\param{form3}.  The value of \param{form3} can be any 
+%!!! Jonl wants to know why "positive" here.
+positive 
+\term{number}.
+The default value is 1.
+ 
+\endlist
+ 
+In an iteration control clause, the \loopref{for} or \loopref{as} construct
+causes termination when the supplied limit is reached.  That is,
+iteration continues until the value \param{var} is stepped to the
+exclusive or inclusive limit supplied by \param{form2}.  The range is
+exclusive if \param{form3} increases or decreases \param{var}
+to the value of \param{form2} without reaching that value; the loop
+keywords \loopref{below} and \loopref{above} provide exclusive limits.  An
+inclusive limit allows \param{var} to attain the value of
+\param{form2}; \loopref{to}, \loopref{downto}, and \loopref{upto} provide inclusive
+limits.  
+
+%!!! JonL wonders if we maybe shouldn't define "incremental" and "decremental" here.
+
+\beginsubsubsubsubsection{Examples of for-as-arithmetic subclause}
+
+\code
+;; Print some numbers.
+ (loop for i from 1 to 3
+       do (print i))
+\OUT 1
+\OUT 2
+\OUT 3
+\EV NIL
+ 
+;; Print every third number.
+ (loop for i from 10 downto 1 by 3
+       do (print i))
+\OUT 10 
+\OUT 7 
+\OUT 4 
+\OUT 1 
+\EV NIL
+ 
+;; Step incrementally from the default starting value.
+ (loop for i below 3
+       do (print i))
+\OUT 0
+\OUT 1
+\OUT 2
+\EV NIL
+\endcode
+ 
+\endsubsubsubsubsection%{Examples of for-as-arithmetic subclause}
+
+\endsubsubsubsection%{The for-as-arithmetic subclause}
+
+\beginsubsubsubsection{The for-as-in-list subclause}
+
+In the \i{for-as-in-list} subclause,
+the \loopref{for} 
+or \loopref{as} construct iterates over the contents of a 
+\term{list}.  It checks for 
+the end of the \term{list} as if by using \funref{endp}.  
+The variable \param{var} is bound to the successive elements  of 
+the \term{list} in \param{form1} before each
+iteration.  At the end of each iteration, the function \param{step-fun}
+is applied to the \term{list}; the default value for \param{step-fun} is
+\funref{cdr}.
+The \term{loop keywords} \loopref{in} and \loopref{by} serve as valid prepositions in
+this syntax.
+The \loopref{for} or \loopref{as} construct causes termination when the
+end of the \term{list} is reached.
+
+\beginsubsubsubsubsection{Examples of for-as-in-list subclause}
+
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+%Added OF-TYPE in the third example. -kmp 29-Apr-93
+\code
+;; Print every item in a list.
+ (loop for item in '(1 2 3) do (print item))
+\OUT 1
+\OUT 2
+\OUT 3
+\EV NIL
+ 
+;; Print every other item in a list.
+ (loop for item in '(1 2 3 4 5) by #'cddr
+       do (print item))
+\OUT 1
+\OUT 3
+\OUT 5
+\EV NIL
+ 
+;; Destructure a list, and sum the x values using fixnum arithmetic.
+ (loop for (item . x) of-type (t . fixnum) in '((A . 1) (B . 2) (C . 3))
+       unless (eq item 'B) sum x)
+\EV 4
+\endcode
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+ 
+\endsubsubsubsubsection%{Examples of for-as-in-list subclause}
+
+\endsubsubsubsection%{The for-as-in-list subclause}
+
+\beginsubsubsubsection{The for-as-on-list subclause}
+
+\issue{LOOP-FOR-AS-ON-TYPO:FIX-TYPO}
+In the \i{for-as-on-list} subclause, the \loopref{for} or \loopref{as}
+construct iterates over
+%the contents of
+a \term{list}. It checks for the
+end of the \term{list} as if by using \funref{atom}.
+\endissue{LOOP-FOR-AS-ON-TYPO:FIX-TYPO}
+The variable \param{var} is bound to the successive tails of the 
+\term{list} in 
+\param{form1}.  At the end of each iteration, the function \param{step-fun}
+ is applied to the \term{list}; the default value for \param{step-fun} is \funref{cdr}.
+ The \term{loop keywords} \loopref{on} and \loopref{by} serve as valid
+prepositions in this syntax.
+The \loopref{for} or \loopref{as} construct causes termination when the
+end of the \term{list} is reached.
+ 
+\beginsubsubsubsubsection{Examples of for-as-on-list subclause}
+
+\code
+;; Collect successive tails of a list.
+ (loop for sublist on '(a b c d)
+       collect sublist)
+\EV ((A B C D) (B C D) (C D) (D))
+ 
+;; Print a list by using destructuring with the loop keyword ON.
+ (loop for (item) on '(1 2 3)
+       do (print item))
+\OUT 1 
+\OUT 2 
+\OUT 3 
+\EV NIL
+ 
+\endcode
+
+\endsubsubsubsubsection%{Examples of for-as-on-list subclause}
+
+\endsubsubsubsection%{The for-as-on-list subclause}
+
+\beginsubsubsubsection{The for-as-equals-then subclause}
+
+In the \i{for-as-equals-then} subclause
+the \loopref{for} 
+or \loopref{as} construct 
+initializes the variable \param{var} by setting it to the
+  result of evaluating \param{form1} on the first iteration, then setting
+  it to the result of evaluating \param{form2} on the second and
+  subsequent iterations.  If \param{form2} is omitted, the construct
+  uses \param{form1} on the second and
+  subsequent iterations.  
+%When \param{form2} is omitted, the expanded
+%  code shows the following optimization:
+The \term{loop keywords} {$=$} and \loopref{then} serve as valid prepositions
+in this syntax. 
+This construct does not provide any termination tests.
+ 
+\beginsubsubsubsubsection{Examples of for-as-equals-then subclause}
+
+%\code
+%;; The original code:
+% (prog (...)
+%       (setq x (some-value))
+%   tag (print x)
+%       (setq x (some-value))
+%       (go tag))
+% 
+%;; The expanded code:
+% (prog (...)
+%   tag (setq x (some-value))
+%       (print x)
+%       (go tag))
+%\endcode
+\code
+;; Collect some numbers.
+ (loop for item = 1 then (+ item 10)
+       for iteration from 1 to 5
+       collect item)
+\EV (1 11 21 31 41)
+\endcode
+ 
+\endsubsubsubsubsection%{Examples of for-as-equals-then subclause}
+
+\endsubsubsubsection%{The for-as-equals-then subclause}
+
+\beginsubsubsubsection{The for-as-across subclause}
+
+  In the \i{for-as-across} subclause the \loopref{for} 
+  or \loopref{as} construct binds the variable \param{var} to the value of
+  each element in the array \param{vector}.
+  The \term{loop keyword} \loopref{across} marks the array \param{vector}; \loopref{across}
+  is used as a preposition in this syntax.
+  Iteration stops when there are no more elements in the supplied
+  \term{array} that can be referenced.
+  Some implementations might recognize a \specref{the} special form
+  in the \param{vector} form to produce more efficient code.
+ 
+\beginsubsubsubsubsection{Examples of for-as-across subclause}
+
+\code
+ (loop for char across (the simple-string (find-message channel))
+       do (write-char char stream))
+\endcode
+ 
+\endsubsubsubsubsection%{Examples of for-as-across subclause}
+
+\endsubsubsubsection%{The for-as-across subclause}
+
+\beginsubsubsubsection{The for-as-hash subclause}
+
+  In the \i{for-as-hash} subclause
+  the \loopref{for} 
+  or \loopref{as} construct 
+  iterates over the elements, keys, and values of a \term{hash-table}.
+  In this syntax, a compound preposition is used to designate access to a
+  \term{hash table}.
+  The variable \param{var} takes on the value of each hash key
+  or hash value in the supplied \param{hash-table}. 
+  The following \term{loop keywords} serve as valid prepositions within this syntax:
+ 
+\beginlist
+ 
+\itemitem{\loopref{being}}
+             
+The keyword \loopref{being} introduces either the Loop schema 
+\loopref{hash-key} or \loopref{hash-value}.
+ 
+\itemitem{\loopref{each}, \loopref{the}}
+ 
+The \term{loop keyword} \loopref{each}
+follows the \term{loop keyword} \loopref{being} when \loopref{hash-key} or
+\loopref{hash-value} is used.  The \term{loop keyword} {\tt the} is used with
+\loopref{hash-keys} and \loopref{hash-values} only for ease of reading.
+This agreement isn't required.
+ 
+\itemitem{\loopref{hash-key}, \loopref{hash-keys}}
+ 
+These \term{loop keywords} access each key entry of the \term{hash table}.  If 
+the name \loopref{hash-value} is supplied in a \loopref{using} construct with one
+of these Loop schemas, the iteration can optionally access the keyed
+value. The order in which the keys are accessed is undefined; empty
+slots in the \term{hash table} are ignored.  
+ 
+\itemitem{\loopref{hash-value}, \loopref{hash-values}}
+ 
+These \term{loop keywords} access each value entry of a 
+\term{hash table}.  If 
+the name \loopref{hash-key} is supplied in a \loopref{using} construct with one of
+these Loop schemas, the iteration can optionally access the key that
+corresponds to the value.  The order in which the keys are accessed is
+undefined; empty slots in the \term{hash table} are ignored. 
+ 
+\itemitem{\loopref{using}}
+ 
+The \term{loop keyword} \loopref{using} introduces 
+the optional key or the keyed value to
+be accessed.  It allows access to the hash key if iteration is over
+the hash values, and the hash value if 
+iteration is over the hash keys.
+ 
+\itemitem{\loopref{in}, \loopref{of}}
+ 
+These loop prepositions introduce \param{hash-table}.
+ 
+\endlist
+
+%!!! Barmar: What does this mean?
+In effect 
+
+\loopref{being}
+\curly{\loopref{each} | \loopref{the}}
+\curly{\loopref{hash-value}  |
+       \loopref{hash-values} |
+       \loopref{hash-key}    |
+       \loopref{hash-keys}}
+\curly{\loopref{in} | \loopref{of}}
+
+% \code
+% being \lbracket\ each|the\rbracket \lbracket\ hash-value|hash-values|hash-key|hash-key\rbracket \lbracket\ in|of\rbracket 
+% \endcode
+
+is a compound preposition.
+ 
+Iteration stops when there are no more hash keys or hash values to be
+referenced in the supplied \param{hash-table}.
+
+\endsubsubsubsection%{The for-as-hash subclause}
+
+\beginsubsubsubsection{The for-as-package subclause}
+
+In the \i{for-as-package} subclause
+the \loopref{for} 
+or \loopref{as} construct                    
+iterates over the \term{symbols} in a \term{package}.
+In this syntax, a compound preposition is used to designate access to a
+\term{package}.
+The variable \param{var} takes on the value of each \term{symbol}
+in the supplied \term{package}.  
+ The following \term{loop keywords} serve as valid prepositions within this syntax:
+ 
+\beginlist
+ 
+\itemitem{\loopref{being}}
+ 
+The keyword \loopref{being} introduces either the Loop schema 
+\loopref{symbol}, \loopref{present-symbol},  or \loopref{external-symbol}.
+ 
+\itemitem{\loopref{each}, \loopref{the}}
+ 
+The \term{loop keyword} \loopref{each}
+follows the \term{loop keyword} \loopref{being} when \loopref{symbol}, 
+\loopref{present-symbol}, or \loopref{external-symbol} is used.  
+The \term{loop keyword} \loopref{the} is used with \loopref{symbols}, 
+\loopref{present-symbols}, and \loopref{external-symbols} only for ease of reading.
+This agreement isn't required.
+ 
+\itemitem{\loopref{present-symbol}, \loopref{present-symbols}}
+ 
+These Loop schemas iterate over the \term{symbols} 
+\issue{LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS}
+that are \term{present} in a \term{package}.
+% but not \term{external symbols} of that \term{package}.
+\endissue{LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS}
+The \param{package} to be iterated over is supplied in the same way
+that \term{package} arguments to \funref{find-package} are supplied.  
+If the \param{package} for the iteration is not supplied, 
+the \term{current package} is used.  
+If a \param{package} that does not exist is supplied, 
+an error \oftype{package-error} is signaled.
+ 
+\itemitem{\loopref{symbol}, \loopref{symbols}}
+ 
+These Loop schemas iterate over \term{symbols} that are
+\term{accessible} in a given \param{package}.  
+The \param{package} to be iterated over is supplied in the same way
+that \term{package} arguments to \funref{find-package} are supplied.
+If the \param{package} for the iteration is not supplied, 
+the \term{current package} is used.
+If a \param{package} that does not exist is supplied, 
+an error \oftype{package-error} is signaled.
+ 
+\itemitem{\loopref{external-symbol}, \loopref{external-symbols}}
+ 
+These Loop schemas iterate over the \term{external symbols} of a \param{package}.
+The \param{package} to be iterated over is supplied in the same way
+that \term{package} arguments to \funref{find-package} are supplied.
+If the \param{package} for the iteration is not supplied, 
+the \term{current package} is used.
+If a \param{package} that does not exist is supplied, 
+an error \oftype{package-error} is signaled.
+ 
+\itemitem{\loopref{in}, \loopref{of}}
+ 
+These loop prepositions introduce \param{package}.
+ 
+\endlist
+
+%!!! Barmar: What does this mean?
+In effect 
+                                      
+\loopref{being}
+\curly{\loopref{each} | \loopref{the}}
+\curly{\loopref{symbol}          |
+       \loopref{symbols}         |
+       \loopref{present-symbol}  |
+       \loopref{present-symbols} |
+       \loopref{external-symbol} |
+       \loopref{external-symbols}}
+\curly{\loopref{in} | \loopref{of}}
+
+% \code
+% being \lbracket\ each|the\rbracket \lbracket\ \lbracket\ \lbracket\ 
+% present|external\rbracket\ symbol\rbracket | \lbracket\ 
+% \lbracket\ present|external\rbracket symbols\rbracket\rbracket \lbracket\ in|of\rbracket
+% \endcode
+
+is a compound preposition.
+
+Iteration stops when there are no more \term{symbols} to be referenced 
+in the supplied \param{package}.
+ 
+\beginsubsubsubsubsection{Examples of for-as-package subclause}
+
+\issue{LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS}
+\code
+ (let ((*package* (make-package "TEST-PACKAGE-1")))
+   ;; For effect, intern some symbols
+   (read-from-string "(THIS IS A TEST)")
+   (export (intern "THIS"))
+   (loop for x being each present-symbol of *package*
+          do (print x)))
+\OUT A 
+\OUT TEST 
+\OUT THIS
+\OUT IS 
+\EV NIL
+\endcode
+\endissue{LOOP-PRESENT-SYMBOLS-TYPO:FLUSH-WRONG-WORDS}
+
+\endsubsubsubsubsection%{Examples of for-as-package subclause}
+
+\endsubsubsubsection%{The for-as-package subclause}
+
+\endsubsubsection%{Iteration Control}
+
+\beginsubsubsection{Local Variable Initializations}
+ 
+When a \macref{loop} \term{form} is executed, the local variables are bound and are
+initialized to some value.  These local variables exist until \macref{loop}
+iteration terminates, at which point they cease to exist.  
+Implicit variables are also established by iteration control clauses and the
+\loopref{into} preposition of accumulation clauses.
+
+The \loopref{with} construct initializes variables that are local to 
+a loop.  The variables are initialized one time only.
+If the optional \param{type-spec} argument is supplied for the variable 
+\param{var}, but there is no related expression to be evaluated, \param{var}
+is initialized to an appropriate default value for its \term{type}.
+%!!! Barmar: How is this default specified for "wierd" types? e.g.,
+%     CLOS classes, DEFSTRUCT types, (OR ...), (AND ...), (SATISFIES ...), package, etc.
+For example, for the types \typeref{t}, \typeref{number}, 
+and \typeref{float},
+the default values are \nil, \f{0}, and \f{0.0} respectively.
+The consequences are undefined if a 
+\param{type-spec} argument is supplied for \param{var} if
+the related expression returns a value that is not of the supplied 
+\term{type}.
+By default, the \loopref{with} construct initializes variables
+\term{sequentially}; that is, one variable is assigned a value before the
+next expression is evaluated.  However, by using the \term{loop keyword} \loopref{and}
+to join several \loopref{with} clauses, 
+initializations can be forced to occur in \term{parallel}; that 
+is, all of the supplied
+\param{forms} are evaluated, and the results are bound to the respective
+variables simultaneously.
+
+%The optional \loopref{and} clause forces \term{parallel} rather than \term{sequential} 
+%initializations.
+\term{Sequential} \term{binding} is used when it is desireable for the initialization of
+some variables to depend on the values of previously bound variables.
+For example, suppose the variables \f{a}, \f{b}, and \f{c} are to be bound in sequence:
+ 
+\code
+ (loop with a = 1 
+       with b = (+ a 2) 
+       with c = (+ b 3)
+       return (list a b c))
+\EV (1 3 6)
+\endcode
+ 
+The execution of the above \macref{loop} is equivalent to the execution of
+the following code:
+ 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+%BLOCK moved to outside.
+\code
+ (block nil
+   (let* ((a 1)
+          (b (+ a 2))
+          (c (+ b 3)))
+     (tagbody
+         (next-loop (return (list a b c))
+                    (go next-loop)
+                    end-loop))))
+\endcode
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+
+If the values of previously bound variables are not needed
+for the initialization of other local variables, an 
+\loopref{and} clause can be used to 
+%force the bindings to occur in \term{parallel}:
+%% for JonL:
+specify that the bindings are to occur in \term{parallel}:
+ 
+\code
+ (loop with a = 1 
+       and b = 2 
+       and c = 3
+       return (list a b c))
+\EV (1 2 3)
+\endcode
+ 
+The execution of the above loop is equivalent to the execution of
+the following code:
+ 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+%BLOCK moved to outside.
+\code
+ (block nil
+   (let ((a 1)
+         (b 2)
+         (c 3))
+     (tagbody
+         (next-loop (return (list a b c))
+                    (go next-loop)
+                    end-loop))))
+\endcode
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+
+\beginsubsubsubsection{Examples of WITH clause}
+
+\code
+;; These bindings occur in sequence.
+ (loop with a = 1 
+       with b = (+ a 2) 
+       with c = (+ b 3)
+       return (list a b c))
+\EV (1 3 6)
+ 
+;; These bindings occur in parallel.
+ (setq a 5 b 10)
+\EV 10
+ (loop with a = 1
+       and b = (+ a 2)
+       and c = (+ b 3)
+       return (list a b c))
+\EV (1 7 13)
+ 
+;; This example shows a shorthand way to declare local variables 
+;; that are of different types.
+ (loop with (a b c) of-type (float integer float)
+       return (format nil "~A ~A ~A" a b c))
+\EV "0.0 0 0.0"
+ 
+;; This example shows a shorthand way to declare local variables 
+;; that are the same type.
+ (loop with (a b c) of-type float 
+       return (format nil "~A ~A ~A" a b c))
+\EV "0.0 0.0 0.0"
+\endcode
+
+\endsubsubsubsection%{Examples of WITH clause}
+
+\endsubsubsection%{Local Variable Initializations}
+
+\endsubsection%{Variable Initialization and Stepping Clauses}
+
+\beginsubsection{Value Accumulation Clauses}
+\DefineSection{LOOPValAcc}
+ 
+%!!! Moon (comment #40) thinks it would be nice to coalesce 
+%    the discussion of "into" here.
+
+The constructs \loopref{collect}, \loopref{collecting},
+\loopref{append}, \loopref{appending},
+\loopref{nconc}, \loopref{nconcing},
+\loopref{count}, \loopref{counting},
+\loopref{maximize}, \loopref{maximizing},
+\loopref{minimize}, \loopref{minimizing},
+\loopref{sum}, and \loopref{summing},
+allow values to be accumulated in a \macref{loop}.
+ 
+ 
+%Accumulating values during iteration and returning them from a loop
+%is often useful.  Some of these accumulations occur so
+%frequently that special loop clauses have been developed to handle them.
+ 
+The constructs \loopref{collect}, 
+\loopref{collecting}, \loopref{append}, \loopref{appending}, 
+\loopref{nconc}, and \loopref{nconcing}, 
+designate clauses that
+accumulate values in \term{lists} and return them.
+The constructs \loopref{count}, \loopref{counting}, 
+\loopref{maximize}, \loopref{maximizing}, \loopref{minimize}, \loopref{minimizing},
+\loopref{sum}, and \loopref{summing} designate clauses that accumulate and
+return numerical values.
+
+During each iteration,  the constructs
+\loopref{collect} and \loopref{collecting}
+collect the value of the supplied
+\param{form} into a \term{list}. 
+When iteration terminates, the \term{list} is returned.
+The argument \param{var} is 
+set to the \term{list} 
+of collected values; if \param{var} is supplied, the \macref{loop}
+does not return the final \term{list} automatically.  If 
+\param{var} is not
+supplied, it is equivalent to supplying an internal name for
+\param{var} and returning its value in a \loopref{finally} clause.
+The \param{var} argument
+is bound as if by the construct \loopref{with}.
+%A \term{type} cannot be supplied for \param{var};
+No mechanism is provided for declaring the \term{type} of \param{var};
+it must be \oftype{list}.
+ 
+%%Removed per Barmar. Fully redundant with next couple of paragraphs.
+% The \loopref{append} construct is similar to \loopref{collect} except the
+% values of the supplied \param{form} must be 
+% \term{lists}.  These \term{lists} are not modified
+% but are concatenated together into a single 
+% \term{list}, as if they were arguments
+% to \funref{append}.
+% The argument \param{var} is 
+% bound to the list of concatenated values; if \param{var} is supplied, the loop
+% does not return the final 
+% \term{list} automatically.  The \param{var} argument
+% is bound as if by the construct \loopref{with}.
+%  A \term{type} cannot be supplied for \param{var}; it must be \oftype{list}.
+
+
+The constructs \loopref{append}, \loopref{appending}, 
+\loopref{nconc}, and  \loopref{nconcing}
+are similar to \loopref{collect} except that the
+values of the supplied \param{form} must be \term{lists}.  
+ 
+\beginlist
+\itemitem{\bull}
+The \loopref{append} keyword causes its \term{list} values to be concatenated 
+into a single \term{list}, as if 
+they were arguments to \thefunction{append}.
+ 
+\itemitem{\bull}
+The \loopref{nconc} keyword causes its \term{list} values to be concatenated
+into a single \term{list},
+as if they were arguments to \thefunction{nconc}.  
+\endlist
+ 
+The argument \param{var} is 
+set to the \term{list} of 
+concatenated values; if \param{var} is supplied, 
+\macref{loop}
+does not return the final \term{list} automatically.  
+The \param{var} argument
+is bound as if by the construct \loopref{with}.
+ A \term{type} cannot be supplied for \param{var}; 
+it must be \oftype{list}.
+ The construct \loopref{nconc} 
+destructively modifies its argument \term{lists}.
+
+% Barmar: Is it required to coerce the sum to the specified type?
+%  Test case: (loop for x in '(a b c) count x into z of-type float finally (return z))
+%  Mail sent to Quinquevirate (issue LOOP-DECLARATION-VS-COERCION)
+The \loopref{count} construct counts the number of times 
+that the supplied \param{form} returns \term{true}.
+The argument \param{var} accumulates the number of occurrences; 
+if \param{var} is supplied, 
+\macref{loop} does not return the final count automatically.
+The \param{var} argument is bound as if by the construct \loopref{with} 
+%% Per Moon #40, First Public Review. -kmp 28-Jul-93
+to a zero of the appropriate type.
+%% Per X3J13. -kmp 05-Oct-93
+Subsequent values (including any necessary coercions) 
+are computed as if by the function \funref{1+}.
+If \loopref{into} \param{var} is used,
+a \term{type} can be supplied  for \param{var} with the \param{type-spec} argument;
+the consequences are unspecified if a nonnumeric \term{type} is supplied.           
+If there is no \loopref{into} variable,
+the optional \param{type-spec} argument
+applies to the internal variable that is keeping the count.  
+The default \term{type} is \term{implementation-dependent}; 
+but it must be
+%% Per Moon #40, First Public Review -kmp 28-Jul-93
+a \supertypeof{fixnum}.
+ 
+%Barmar: For these next three, is type-spec a declaration, coercion, or both?
+%  Test cases: (loop for x in '(1 2 3) minimize x into z of-type float finally (return z))
+% 	       (loop for x in '(1 2 3) sum x into z of-type float finally (return z))
+The \loopref{maximize} and 
+%% Per X3J13. -kmp 05-Oct-93
+%\loopref{minimum}
+\loopref{minimize} 
+constructs compare
+the value of the supplied \param{form} obtained during the first 
+iteration with values obtained in successive iterations.
+The maximum (for \loopref{maximize}) or minimum (for \loopref{minimize}) 
+value encountered is determined 
+%% Per Moon #40, First Public Review -kmp 28-Jul-93
+(as if by \thefunction{max} for \loopref{maximize} and
+ as if by \thefunction{min} for \loopref{minimize})
+and returned.
+%% Per Moon #40, First Public Review -kmp 28-Jul-93
+If the \loopref{maximize} or \loopref{minimize} clause
+is never executed, the accumulated value is unspecified.
+The argument \param{var} accumulates the maximum or minimum value;
+if \param{var} is supplied,
+\macref{loop} does not return the maximum or minimum automatically.
+The \param{var} argument is bound as if by the construct \loopref{with}.
+If \loopref{into} \param{var} is used,
+a \term{type} can be supplied for \param{var} with the \param{type-spec} argument;
+the consequences are unspecified if a nonnumeric \term{type} is supplied.           
+If there is no \loopref{into} variable,
+the optional \param{type-spec} argument applies to the internal variable 
+that is keeping the maximum or minimum value.  
+%% Per Moon #40, First Public Review -kmp 28-Jul-93
+The default \term{type} 
+%% Per X3J13. -kmp 05-Oct-93
+is \term{implementation-dependent}; but it
+must be a \supertypeof{real}.
+ 
+The \loopref{sum} construct forms a cumulative sum 
+of the successive \term{primary values} of the supplied \param{form}
+at each iteration.
+The argument \param{var} is used to accumulate the sum;
+if \param{var} is supplied,
+\macref{loop} does not return the final sum automatically.
+The \param{var} argument is bound as if by the construct \loopref{with}
+%% Per Moon #40, First Public Review -kmp 28-Jul-93
+to a zero of the appropriate type.
+Subsequent values (including any necessary coercions) are computed as if by \thefunction{+}.
+If \loopref{into} \param{var} is used,
+a \term{type} can be supplied for \param{var} with the \param{type-spec} argument;
+the consequences are unspecified if a nonnumeric \term{type} is supplied.           
+If there is no \loopref{into} variable,
+the optional \param{type-spec} argument applies to the internal variable
+that is keeping the sum.
+%% Per Moon #40, First Public Review -kmp 28-Jul-93
+The default \term{type}
+%% Per X3J13. -kmp 05-Oct-93
+is \term{implementation-dependent}; but it
+must be a \supertypeof{number}.
+ 
+%% Removed per barmar. Redundant with the above.
+% The loop preposition \loopref{into} can be used to name the 
+% variable used to hold partial accumulations.
+% The variable is bound as if by the loop
+% construct \loopref{with}. 
+If \loopref{into} is used,
+the construct does not provide a default return value;
+however, the variable is available
+for use in any \loopref{finally} clause.  
+     
+%These \term{loop keywords}
+%can also be spelled with the optional suffix {\tt ing}.
+ 
+%% Replaced per Moon #40, First Public Review -kmp 28-Jul-93
+% Value-returning accumulation clauses can be combined in a \macref{loop} if
+% all the clauses accumulate the same \term{type} of \term{object}.  
+% By default, the Loop Facility returns only one value;
+% thus, the \term{objects} collected by multiple accumulation clauses 
+% as return values must have compatible \term{types}. For example, since both
+% the \loopref{collect} and \loopref{append} constructs accumulate 
+% \term{objects} into a
+% \term{list} that is returned from a 
+% \macref{loop}, they can be combined safely.
+Certain kinds of accumulation clauses can be combined in a \macref{loop} 
+if their destination is the same 
+(the result of \macref{loop} or an \loopref{into} \param{var}) 
+because they are considered to accumulate conceptually compatible quantities.
+In particular, 
+any elements of following sets of accumulation clauses can be mixed
+with other elements of the same set for the same destination 
+in a \macref{loop} \term{form}:
+
+\beginlist
+\itemitem{\bull} \loopref{collect}, \loopref{append}, \loopref{nconc}
+
+\itemitem{\bull} \loopref{sum}, \loopref{count}
+
+\itemitem{\bull} \loopref{maximize}, \loopref{minimize}
+\endlist
+
+\code
+;; Collect every name and the kids in one list by using 
+;; COLLECT and APPEND.
+ (loop for name in '(fred sue alice joe june)
+       for kids in '((bob ken) () () (kris sunshine) ())
+       collect name
+       append kids)
+\EV (FRED BOB KEN SUE ALICE JOE KRIS SUNSHINE JUNE)
+\endcode
+ 
+%% Per X3J13. -kmp 05-Oct-93
+%Multiple
+Any two
+clauses that do not accumulate the same \term{type} of 
+\term{object} 
+can coexist in a \macref{loop} only 
+if each clause accumulates its values into 
+a different
+%% Removed per Barmar -- "some can still use the default" (i.e., not supply a var)
+%user-specified
+\term{variable}.  
+
+%Any number of values can
+%be returned from \macref{loop} if \thefunction{values} is used,
+%as the next example shows:
+% 
+%\code
+%;; Count and collect names and ages.
+% (loop for name in '(fred sue alice joe june)
+%       as age in '(22 26 19 20 10)
+%       append (list name age) into name-and-age-list
+%       count name into name-count
+%       sum age into total-age
+%       finally
+%       (return
+%        (values (round total-age name-count)
+%                 name-and-age-list)))
+%\EV 19, (FRED 22 SUE 26 ALICE 19 JOE 20 JUNE 10)
+%\endcode
+ 
+\beginsubsubsection{Examples of COLLECT clause}
+
+\code
+;; Collect all the symbols in a list.
+ (loop for i in '(bird 3 4 turtle (1 . 4) horse cat)
+       when (symbolp i) collect i)
+\EV (BIRD TURTLE HORSE CAT)
+ 
+;; Collect and return odd numbers.
+ (loop for i from 1 to 10
+       if (oddp i) collect i)
+\EV (1 3 5 7 9)
+ 
+;; Collect items into local variable, but don't return them.
+ (loop for i in '(a b c d) by #'cddr
+       collect i into my-list
+       finally (print my-list))
+\OUT (A C) 
+\EV NIL
+\endcode
+ 
+\endsubsubsection%{Examples of COLLECT clause}
+
+\beginsubsubsection{Examples of APPEND and NCONC clauses}
+
+\code
+;; Use APPEND to concatenate some sublists.
+  (loop for x in '((a) (b) ((c)))
+        append x)
+\EV (A B (C))
+ 
+;; NCONC some sublists together.  Note that only lists made by the
+;; call to LIST are modified.
+  (loop for i upfrom 0 
+        as x in '(a b (c))
+        nconc (if (evenp i) (list x) nil))
+\EV (A (C))
+\endcode
+
+\endsubsubsection%{Examples of APPEND and NCONC clauses}
+
+\beginsubsubsection{Examples of COUNT clause}
+
+\code
+ (loop for i in '(a b nil c nil d e)
+       count i)
+\EV 5
+\endcode
+ 
+\endsubsubsection%{Examples of COUNT clause}
+
+\beginsubsubsection{Examples of MAXIMIZE and MINIMIZE clauses}
+
+\code
+ (loop for i in '(2 1 5 3 4)
+       maximize i)
+\EV 5
+ (loop for i in '(2 1 5 3 4)
+       minimize i)
+\EV 1
+ 
+;; In this example, FIXNUM applies to the internal variable that holds
+;; the maximum value.
+ (setq series '(1.2 4.3 5.7))
+\EV (1.2 4.3 5.7)
+ (loop for v in series 
+       maximize (round v) of-type fixnum)
+\EV 6
+ 
+;; In this example, FIXNUM applies to the variable RESULT.
+ (loop for v of-type float in series
+       minimize (round v) into result of-type fixnum
+       finally (return result))
+\EV 1
+\endcode
+
+\endsubsubsection%{Examples of MAXIMIZE and MINIMIZE clauses}
+
+\beginsubsubsection{Examples of SUM clause}
+
+\code
+ (loop for i of-type fixnum in '(1 2 3 4 5)
+       sum i)
+\EV 15
+ (setq series '(1.2 4.3 5.7))
+\EV (1.2 4.3 5.7)
+ (loop for v in series 
+       sum (* 2.0 v))
+\EV 22.4
+\endcode
+
+\endsubsubsection%{Examples of SUM clause}
+
+\endsubsection%{Value Accumulation Clauses}
+
+\beginsubsection{Termination Test Clauses}
+\DefineSection{LOOPTermTest}
+
+The \loopref{repeat} construct causes iteration to terminate after a
+specified number of times.
+ The loop body executes \i{n} times, where \i{n} is the value 
+of the expression \param{form}.  The \param{form} argument is evaluated one time
+in the loop prologue.  If the expression evaluates to 0 or 
+to a negative \term{number}, the loop body is not evaluated.
+
+The constructs \loopref{always},
+\loopref{never},
+\loopref{thereis},
+\loopref{while},
+\loopref{until},
+and the macro \macref{loop-finish}
+allow conditional termination of iteration within
+a \macref{loop}.
+
+The constructs \loopref{always}, \loopref{never}, and \loopref{thereis} provide
+specific values to be returned when a \macref{loop} terminates.  
+Using \loopref{always}, \loopref{never}, or \loopref{thereis} in a loop with 
+value accumulation clauses that are not \loopref{into} causes 
+an error \oftype{program-error} to be signaled (at macro expansion time).
+Since \loopref{always}, \loopref{never}, and \loopref{thereis}
+use 
+\issue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+\thespecop{return-from}
+\endissue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+to terminate iteration,
+any \loopref{finally} clause that is supplied is not evaluated
+%Added for JonL
+when exit occurs due to any of these constructs.
+In all other respects these
+constructs behave like the \loopref{while} and \loopref{until} constructs.
+
+  The \loopref{always} construct takes one \term{form} and terminates the 
+\macref{loop}
+  if the \term{form} ever evaluates to \nil; in this case, it returns
+  \nil.  Otherwise, it provides a default return value of \t.
+If the value of the supplied \term{form} is never \nil, some other construct
+can terminate the iteration.
+ 
+%  The {\tt never} construct takes one 
+%\term{form} and terminates the \macref{loop}
+%  if the \term{form} ever evaluates to \term{non-nil}; in this case, it returns
+%  \nil.  Otherwise, it provides a default return value of {\tt t}.
+The \loopref{never} construct terminates iteration the first time that
+the value of the supplied \param{form} is \term{non-nil}; the \macref{loop} returns 
+\nil.                                         
+If the value of the supplied \param{form} is always  \nil, some other 
+construct can terminate the iteration.  
+Unless some other clause contributes 
+a return value, the default value returned is \t.
+ 
+%  The {\tt thereis} construct takes one \param{form} and terminates the 
+%\macref{loop}
+%  if the \param{form} ever evaluates to \term{non-nil}; in this case, it returns
+%  that value.        
+The \loopref{thereis} construct terminates iteration the first time that the
+value of the supplied \param{form} is \term{non-nil}; the \macref{loop} returns the
+value of the supplied \param{form}.
+If the value of the supplied \param{form} 
+is always  \nil, some other
+construct can terminate the iteration.  Unless some other clause contributes a 
+return value, the default value returned is \nil.
+ 
+ 
+%!!! Barmar: Combine this differences info with never/until below.
+There are two differences between the \loopref{thereis} and \loopref{until}
+constructs: 
+ 
+\beginlist
+\itemitem{\bull} The \loopref{until} construct does not return a value or 
+\nil\ based on the value of the supplied \param{form}.
+ 
+\itemitem{\bull} The \loopref{until} construct executes 
+any \loopref{finally} clause.
+Since \loopref{thereis} uses
+\issue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+\thespecop{return-from}
+\endissue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+to terminate iteration,
+any \loopref{finally} clause that is supplied is not evaluated
+%Added per JonL
+when exit occurs due to \loopref{thereis}.
+ 
+\endlist
+ 
+ 
+ 
+The \loopref{while} construct allows iteration to continue until the 
+supplied \param{form} 
+evaluates to \term{false}.  The supplied \param{form} 
+is reevaluated at the location of the \loopref{while} clause.
+ 
+The \loopref{until} construct is equivalent to 
+\f{while (not \param{form})\dots}.  If the value of the
+supplied \param{form} is \term{non-nil}, iteration terminates.
+
+%% Removed per X3J13. -kmp 4-Oct-93
+% The \loopref{while} and \loopref{until} constructs can be used
+% at any point in a \macref{loop}.  
+%% Next two lines (sentences) moved from farther down per X3J13.  -kmp 4-Oct-93
+Termination-test control constructs can be used anywhere within the loop body.
+The termination tests are used in the order in which they appear.
+If an \loopref{until} or \loopref{while} clause causes
+termination, any clauses that precede it in the source
+are still evaluated.  
+If the \loopref{until} and {\tt while} constructs cause termination,
+control is passed to the loop epilogue, where any \loopref{finally}
+clauses will be executed.  
+ 
+There are two differences between the \loopref{never} and \loopref{until}
+constructs: 
+ 
+\beginlist
+\itemitem{\bull} The \loopref{until} construct does not return 
+\t\ or \nil\ based on the value of the supplied \param{form}.
+                                                       
+\itemitem{\bull} 
+The \loopref{until} construct 
+%executes any \loopref{finally} clause.
+does not bypass any \loopref{finally} clauses.
+Since \loopref{never} uses 
+\issue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+\thespecop{return-from}
+\endissue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+to terminate iteration,
+any \loopref{finally} clause that is supplied is not evaluated
+%Added per JonL
+when exit occurs due to \loopref{never}. 
+\endlist
+
+%The macro \macref{loop-finish}
+%can be used at any time to cause normal
+%termination.  
+
+%The macro \macref{loop-finish} terminates iteration normally
+%and returns any accumulated result.  If specified, a {\tt finally} clause
+%is evaluated.
+
+
+In most cases it is not necessary to use \macref{loop-finish}
+because other loop control clauses terminate the \macref{loop}.  
+The macro \macref{loop-finish} is used to provide a normal exit
+from a nested conditional inside a \macref{loop}.
+%You can use \macref{loop-finish}
+%inside nested Lisp code to provide a normal exit from a loop.
+%% Removed per X3J13. -kmp 05-Oct-93
+% In normal termination, \loopref{finally} clauses are 
+% executed and default return values are returned.
+Since \macref{loop-finish} transfers control to the loop epilogue,
+using \macref{loop-finish} within a \loopref{finally} expression can cause
+infinite looping.
+%% This information is already available in the macro entry for LOOP-FINISH.
+% %  Implementations are allowed to provide \macref{loop-finish} 
+% %as a local macro
+% %  by using \specref{macrolet}.
+% It is \term{implementation-dependent} whether or not,
+% in a particular \macref{loop} invocation, \macref{loop-finish}
+% is implemented as a global \term{macro} or a local one (created as if by \specref{macrolet}).
+
+\beginsubsubsection{Examples of REPEAT clause}
+ 
+\code
+ (loop repeat 3
+       do (format t "~&What I say three times is true.~%"))
+\OUT What I say three times is true.
+\OUT What I say three times is true.
+\OUT What I say three times is true.
+\EV NIL
+ (loop repeat -15
+   do (format t "What you see is what you expect~%"))
+\EV NIL
+\endcode
+ 
+\endsubsubsection%{Examples of REPEAT clause}
+
+\beginsubsubsection{Examples of ALWAYS, NEVER, and THEREIS clauses}
+
+\code
+;; Make sure I is always less than 11 (two ways).
+;; The FOR construct terminates these loops.
+ (loop for i from 0 to 10
+       always (< i 11))
+\EV T
+ (loop for i from 0 to 10
+       never (> i 11))
+\EV T
+ 
+;; If I exceeds 10 return I; otherwise, return NIL.
+;; The THEREIS construct terminates this loop.
+ (loop for i from 0
+       thereis (when (> i 10) i) )
+\EV 11
+
+;;; The FINALLY clause is not evaluated in these examples.
+ (loop for i from 0 to 10
+       always (< i 9)
+       finally (print "you won't see this"))
+\EV NIL
+ (loop never t
+       finally (print "you won't see this"))
+\EV NIL
+ (loop thereis "Here is my value"
+       finally (print "you won't see this"))
+\EV "Here is my value"
+ 
+;; The FOR construct terminates this loop, so the FINALLY clause 
+;; is evaluated.
+ (loop for i from 1 to 10
+       thereis (> i 11)
+       finally (prin1 'got-here))
+\OUT GOT-HERE
+\EV NIL
+ 
+;; If this code could be used to find a counterexample to Fermat's
+;; last theorem, it would still not return the value of the
+;; counterexample because all of the THEREIS clauses in this example
+;; only return T.  But if Fermat is right, that won't matter
+;; because this won't terminate.
+ 
+ (loop for z upfrom 2
+       thereis
+         (loop for n upfrom 3 below (log z 2)
+               thereis
+                 (loop for x below z
+                       thereis
+                         (loop for y below z
+                               thereis (= (+ (expt x n) (expt y n))
+                                          (expt z n))))))
+\endcode
+
+\endsubsubsection%{Examples of ALWAYS, NEVER, and THEREIS clauses}
+
+\beginsubsubsection{Examples of WHILE and UNTIL clauses}
+
+\code
+ (loop while (hungry-p) do (eat))
+ 
+;; UNTIL NOT is equivalent to WHILE.
+ (loop until (not (hungry-p)) do (eat))
+ 
+;; Collect the length and the items of STACK.
+ (let ((stack '(a b c d e f)))
+   (loop for item = (length stack) then (pop stack)
+         collect item
+         while stack))
+\EV (6 A B C D E F)
+ 
+;; Use WHILE to terminate a loop that otherwise wouldn't terminate.
+;; Note that WHILE occurs after the WHEN.
+ (loop for i fixnum from 3
+       when (oddp i) collect i
+       while (< i 5))
+\EV (3 5)
+\endcode
+
+\endsubsubsection%{Examples of WHILE and UNTIL clauses}
+
+\endsubsection%{Termination Test Clauses}
+
+\beginsubsection{Unconditional Execution Clauses}
+\DefineSection{LOOPUnconditional}
+ 
+The \loopref{do} and \loopref{doing} constructs 
+evaluate the 
+supplied \param{forms} 
+wherever they occur in the expanded form of \macref{loop}.
+ The \param{form} argument can be any \term{compound form}.
+Each \param{form} is evaluated in every iteration.
+Because every loop clause must begin with a \term{loop keyword}, 
+the keyword \loopref{do} is used when no control action other than execution is 
+required.
+ 
+%!!! This was said somewhere already. -kmp 12-May-91
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+%The \loopref{return} construct takes one \term{form} and returns its \term{values}.
+ The \loopref{return} construct takes one \term{form}. 
+ Any \term{values} returned by the \term{form} 
+ are immediately returned by the \macref{loop} form.
+% It is equivalent to the clause \f{do (return \i{form})}.
+  It is equivalent to the clause
+  \f{do (return-from \i{block-name} \i{value})},
+  where \i{block-name} is the name specified in a \loopref{named}
+  clause, or \nil\ if there is no \loopref{named} clause.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+ 
+\beginsubsubsection{Examples of unconditional execution}
+
+\code
+;; Print numbers and their squares.
+;; The DO construct applies to multiple forms.
+ (loop for i from 1 to 3
+       do (print i)
+          (print (* i i)))
+\OUT 1 
+\OUT 1 
+\OUT 2 
+\OUT 4 
+\OUT 3 
+\OUT 9 
+\EV NIL
+
+\endcode
+
+\endsubsubsection%{Examples of unconditional execution}
+
+\endsubsection%{Unconditional Execution Clauses}
+
+\beginsubsection{Conditional Execution Clauses}
+\DefineSection{LOOPConditional}
+
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+% The  
+% \loopref{if}, \loopref{when}, and \loopref{unless}
+% constructs 
+% establish conditional control in a \macref{loop}.
+% If the supplied condition is \term{true}, the succeeding loop clause
+% is executed.  If the supplied condition is not true, the succeeding clause is
+% skipped, and program control moves to the clause that follows 
+% the \term{loop keyword} \loopref{else}.  If the supplied condition is not true and no
+% \loopref{else} clause is supplied, control is transferred to the 
+% clause or construct following the supplied condition.
+% %the entire conditional construct
+% %is skipped.
+% 
+% The constructs \loopref{if} and \loopref{when} allow execution of 
+% loop clauses conditionally.  These constructs are synonyms and
+% can be used interchangeably.
+%  If the value of the test expression \param{form} is \term{non-nil}, the expression
+% \param{clause1} is evaluated. If the test expression evaluates to \nil\
+% and an \loopref{else} construct is supplied, the \term{forms} that follow the
+% \loopref{else} are evaluated; otherwise, control passes to the next clause.
+%  If \loopref{if} or \loopref{when} clauses are nested, each \loopref{else} is
+% paired with the closest preceding \loopref{if} or \loopref{when} construct that has
+% no associated \loopref{else} or \loopref{end}.
+% 
+% The \loopref{unless} construct is equivalent to \f{when (not \param{form})}
+% and \f{if (not \param{form})}.
+% If the value of the test expression \param{form} is \nil, the expression
+% \param{clause1} is evaluated. If the test expression evaluates to 
+% \term{non-nil} and an \loopref{else} construct is supplied, the statements that follow the
+% \loopref{else} are evaluated; otherwise, no conditional statement is evaluated.
+%  The \param{clause} arguments must be either accumulation, unconditional,
+% or conditional clauses.  
+
+The \loopref{if}, \loopref{when}, and \loopref{unless} constructs
+establish conditional control in a \macref{loop}. If the test
+passes, the succeeding loop clause is executed. If the test does
+not pass, the succeeding clause is skipped, and program control
+moves to the clause that follows the \term{loop keyword}
+\loopref{else}. If the test does not pass and no \loopref{else}
+clause is supplied, control is transferred to the clause or
+construct following the entire conditional clause.
+
+If conditional clauses are nested, each \loopref{else} is paired
+with the closest preceding conditional clause that has no
+associated \loopref{else} or \loopref{end}. 
+
+In the \loopref{if} and \loopref{when} clauses, which are
+synonymous, the test passes if the value of \param{form} is
+\term{true}.
+
+%% Per X3J13. -kmp 05-Oct-93
+% The \loopref{unless} \param{form} construct 
+% is equivalent to \f{when (not \param{form})};
+% the test passes if the value of \param{form} is \term{false}.
+In the \loopref{unless} clause,
+the test passes if the value of \param{form} is \term{false}.
+
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+ 
+Clauses that follow the test expression can be grouped by using 
+the \term{loop keyword} \loopref{and} to produce a conditional block consisting of 
+a compound clause.
+ 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+% The \term{loop keyword} \loopref{it} can be used to refer to the result of the
+% test expression in a clause.  If multiple clauses are connected 
+% with \loopref{and},
+% the \loopref{it} construct must be in the first clause in the block.  Since \loopref{it}
+% is a \term{loop keyword}, \loopref{it} cannot be used as a local variable within
+% \macref{loop}.
+The \term{loop keyword} \loopref{it} can be used to refer to the result
+of the test expression in a clause.
+Use the \term{loop keyword} \loopref{it} in place of the form in a
+\loopref{return} clause or an \i{accumulation} clause that is
+inside a conditional execution clause.
+If multiple clauses are connected with \loopref{and}, the \loopref{it}
+construct must be in the first clause in the block.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+ 
+The optional \term{loop keyword} \loopref{end} marks the end of the clause.  If this
+keyword is not supplied, the next \term{loop keyword} marks the end.  The construct
+\loopref{end} can be used to distinguish the scoping of compound clauses.
+ 
+\beginsubsubsection{Examples of WHEN clause}
+
+\code
+;; Signal an exceptional condition.
+ (loop for item in '(1 2 3 a 4 5)
+       when (not (numberp item))
+        return (cerror "enter new value" "non-numeric value: ~s" item))
+Error: non-numeric value: A
+ 
+;; The previous example is equivalent to the following one.
+ (loop for item in '(1 2 3 a 4 5)
+       when (not (numberp item))
+        do (return 
+            (cerror "Enter new value" "non-numeric value: ~s" item)))
+Error: non-numeric value: A
+\endcode
+
+% Removed ";; The FINALLY clause prints the last value of I." per X3J13. -kmp 05-Oct-93
+\code
+;; This example parses a simple printed string representation from 
+;; BUFFER (which is itself a string) and returns the index of the
+;; closing double-quote character.
+ (let ((buffer "\\"a\\" \\"b\\""))
+   (loop initially (unless (char= (char buffer 0) #\\")
+                     (loop-finish))
+         for i of-type fixnum from 1 below (length (the string buffer))
+         when (char= (char buffer i) #\\")
+          return i))
+\EV 2
+ 
+;; The collected value is returned.
+ (loop for i from 1 to 10
+       when (> i 5)
+         collect i
+       finally (prin1 'got-here))
+\OUT GOT-HERE
+\EV (6 7 8 9 10) 
+
+;; Return both the count of collected numbers and the numbers.
+ (loop for i from 1 to 10
+       when (> i 5)
+         collect i into number-list
+         and count i into number-count
+       finally (return (values number-count number-list)))
+\EV 5, (6 7 8 9 10)
+\endcode
+ 
+\endsubsubsection%{Examples of WHEN clause}
+
+\endsubsection%{Conditional Execution Clauses}
+
+\beginsubsection{Miscellaneous Clauses}
+\DefineSection{LOOPMisc}
+                                          
+\beginsubsubsection{Control Transfer Clauses}
+
+The \loopref{named} construct
+establishes a name for an \term{implicit block} surrounding the 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+entire
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX} 
+\macref{loop} so that \thespecop{return-from} can be used to return 
+values from or to exit \macref{loop}.   
+Only one name per \macref{loop} \term{form} can be assigned.
+If used, the \loopref{named} construct must be the first clause in the loop expression.
+
+%!!! This is said already above (twice). Consolidate? -kmp 29-Apr-93
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+ The \loopref{return} construct takes one \term{form}. 
+ Any \term{values} returned by the \term{form} 
+ are immediately returned by the \macref{loop} form.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+This construct is similar to \thespecop{return-from} and \themacro{return}.
+% The Loop Facility supports the \loopref{return} construct for backwards
+%compatibility with older loop implementations.  
+The \loopref{return} construct 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+%returns immediately and
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+does not execute any \loopref{finally} clause that 
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+the \macref{loop} \term{form}
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+is given.
+                
+\beginsubsubsubsection{Examples of NAMED clause}
+
+\code
+;; Just name and return.
+ (loop named max
+       for i from 1 to 10
+       do (print i)
+       do (return-from max 'done))
+\OUT 1 
+\EV DONE
+\endcode
+
+\endsubsubsubsection%{Examples of NAMED clause}
+
+\endsubsubsection%{Control Transfer Clauses}
+
+\beginsubsubsection{Initial and Final Execution}
+ 
+The \loopref{initially} and \loopref{finally} constructs
+evaluate forms that occur before and after the loop body.
+
+The \loopref{initially} construct causes the supplied
+%% Per X3J13. -kmp 05-Oct-93
+% \param{form}
+\param{compound-forms}
+to be evaluated
+in the loop prologue, which precedes all loop code except for 
+initial settings supplied by constructs \loopref{with}, \loopref{for}, or
+\loopref{as}.
+  The code for any \loopref{initially} clauses is 
+%"collected into one \specref{progn}" => "executed" per barmar:
+%  They don't have to be collected into a real PROGN since the LOOP expands into a TAGBODY.
+% -kmp 31-Jul-91
+executed
+in the order in which the clauses appeared in
+  the \macref{loop}.  
+%The collected code is executed once in the loop prologue
+%  after any implicit variable initializations.
+%% Removed per X3J13. -kmp 05-Oct-93
+%The \param{form} argument can be any \term{compound form}.
+  
+The \loopref{finally} construct causes the supplied
+%% Per X3J13. -kmp 05-Oct-93
+%\param{form}
+\param{compound-forms}
+to be evaluated
+in the loop epilogue after normal iteration terminates.
+  The code for any \loopref{finally} clauses is 
+%collected into one \specref{progn}
+executed
+ in the order in which the clauses appeared in
+  the \macref{loop}.  The collected code is executed once in the loop epilogue
+  before any implicit values are returned from the accumulation clauses.
+%  Explicit \macref{return} \term{forms} in 
+An explicit transfer of control (\eg by \macref{return}, \specref{go}, or \specref{throw})
+from the loop body, however, will exit the 
+  \macref{loop} without executing the epilogue code.
+%% Removed per X3J13. -kmp 05-Oct-93
+% The \param{form} argument can be any \term{compound form}.
+ 
+Clauses such as \loopref{return}, \loopref{always}, \loopref{never}, and 
+\loopref{thereis}
+can bypass the \loopref{finally} clause.
+\issue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+\macref{return} (or \specref{return-from}, if the \loopref{named} option was supplied)
+\endissue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+can be used after \loopref{finally} to return values from a \macref{loop}.  
+\issue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+%The evaluation of the \macref{return} form 
+Such an \term{explicit return}
+\endissue{LOOP-NAMED-BLOCK-NIL:OVERRIDE}
+inside the
+\loopref{finally} clause takes precedence over returning the accumulation
+from clauses supplied by such keywords as \loopref{collect}, \loopref{nconc}, 
+\loopref{append}, \loopref{sum}, \loopref{count}, \loopref{maximize}, and 
+\loopref{minimize}; 
+the accumulation values for these preempted clauses are not returned by 
+\macref{loop} if \macref{return} or \specref{return-from} is used.
+ 
+%Clauses such as {\tt return}, {\tt always}, {\tt never}, and {\tt thereis}
+%defeat the {\tt finally} clause.
+
+%% Removed per Barmar: Said much earlier. 
+% The constructs \loopref{do}, \loopref{initially}, and \loopref{finally} are the
+% only \term{loop keywords} that take an arbitrary number of \term{forms} and group
+% them as if by using an \term{implicit progn}.  
+
+\endsubsubsection%{Initial and Final Execution}
+
+\endsubsection%{Miscellaneous Clauses}
+
+\beginsubSection{Examples of Miscellaneous Loop Features}
+
+\code
+ (let ((i 0))                     ; no loop keywords are used
+    (loop (incf i) (if (= i 3) (return i)))) \EV 3
+ (let ((i 0)(j 0))
+    (tagbody
+      (loop (incf j 3) (incf i) (if (= i 3) (go exit)))
+      exit)
+    j) \EV 9
+\endcode
+
+
+In the following example, the variable \f{x} is stepped
+before \f{y} is stepped; thus, the value of \f{y}
+reflects the updated value of \f{x}:
+ 
+\code
+ (loop for x from 1 to 10 
+       for y = nil then x 
+       collect (list x y))
+\EV ((1 NIL) (2 2) (3 3) (4 4) (5 5) (6 6) (7 7) (8 8) (9 9) (10 10))
+\endcode
+ 
+In this example, \f{x} and \f{y} are stepped in \term{parallel}:
+ 
+\code
+ (loop for x from 1 to 10 
+       and y = nil then x 
+       collect (list x y))
+\EV ((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))
+\endcode
+
+\beginsubsubsection{Examples of clause grouping}
+\code
+;; Group conditional clauses.
+ (loop for i in '(1 324 2345 323 2 4 235 252)
+       when (oddp i)
+         do (print i)
+         and collect i into odd-numbers
+         and do (terpri)
+       else                              ; I is even.
+         collect i into even-numbers
+       finally
+         (return (values odd-numbers even-numbers)))
+\OUT 1 
+\OUT 
+\OUT 2345 
+\OUT 
+\OUT 323 
+\OUT 
+\OUT 235 
+\EV (1 2345 323 235), (324 2 4 252)
+
+;; Collect numbers larger than 3.
+ (loop for i in '(1 2 3 4 5 6)
+       when (and (> i 3) i)
+       collect it)                      ; IT refers to (and (> i 3) i).
+\EV (4 5 6)
+ 
+;; Find a number in a list.
+ (loop for i in '(1 2 3 4 5 6)
+       when (and (> i 3) i)
+       return it)
+\EV 4
+     
+;; The above example is similar to the following one.
+ (loop for i in '(1 2 3 4 5 6)
+       thereis (and (> i 3) i))
+\EV 4
+
+\medbreak
+;; Nest conditional clauses.
+ (let ((list '(0 3.0 apple 4 5 9.8 orange banana)))
+   (loop for i in list
+         when (numberp i)
+           when (floatp i)
+             collect i into float-numbers
+           else                                  ; Not (floatp i)
+             collect i into other-numbers
+         else                                    ; Not (numberp i)
+           when (symbolp i) 
+             collect i into symbol-list
+           else                                  ; Not (symbolp i)
+             do (error "found a funny value in list ~S, value ~S~%" list i)
+         finally (return (values float-numbers other-numbers symbol-list))))
+\EV (3.0 9.8), (0 4 5), (APPLE ORANGE BANANA)
+
+;; Without the END preposition, the last AND would apply to the
+;; inner IF rather than the outer one.
+ (loop for x from 0 to 3 
+       do (print x)
+       if (zerop (mod x 2))
+         do (princ " a")
+          and if (zerop (floor x 2))
+                do (princ " b")
+                end
+          and do (princ " c"))
+\OUT 0  a b c
+\OUT 1 
+\OUT 2  a c
+\OUT 3 
+\EV NIL
+\endcode
+ 
+\endsubsubsection%{Examples of clause grouping}
+
+\endsubSection%{Examples of Miscellaneous Loop Features}
+
+\beginsubSection{Notes about Loop}
+
+\term{Types} can be supplied for loop variables.  
+It is not necessary to supply a \term{type} for any variable,
+but supplying the \term{type} 
+can ensure that the variable has a correctly typed initial value,
+and it can also enable compiler optimizations 
+(depending on the \term{implementation}).
+ 
+The clause \loopref{repeat} \i{n} ... is roughly equivalent to a clause such as 
+  
+\code
+ (loop for \i{internal-variable} downfrom (- \i{n} 1) to 0 ...)
+\endcode
+                                                            
+but in some \term{implementations},
+the \loopref{repeat} construct might be more efficient.
+
+Within the executable parts of the loop clauses and around the entire
+\macref{loop} form, variables can be bound by using \specref{let}.
+
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+Use caution when using a variable named {\tt IT} (in any \term{package})
+in connection with \macref{loop}, since \loopref{it} is a \term{loop keyword} 
+that can be used in place of a \term{form} in certain contexts.
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+
+There is
+%currently no specified portable
+\issue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+no
+\endissue{LOOP-MISCELLANEOUS-REPAIRS:FIX}
+\term{standardized}
+mechanism for users to add
+extensions to \macref{loop}.
+% The names \f{defloop} and \f{define-loop-method} 
+% have been suggested as candidates for such a method.
+
+\endsubSection%{Notes about Loop}

concept-macro-chars.tex

@@ -0,0 +1,1419 @@
+% -*- Mode: TeX -*-
+%% Standard Macro Characters
+
+%% 22.1.3 1
+If the reader encounters a \term{macro character},
+then its associated \term{reader macro function} 
+is invoked and may produce an \term{object} to be returned.
+This \term{function} may read the \term{characters} 
+following the \term{macro character} in the \term{stream} 
+in any syntax and return the \term{object} represented by that syntax.
+
+%% 22.1.3 2
+Any \term{character} can be made to be a \term{macro character}.
+The \term{macro characters} defined initially in a \term{conforming implementation}
+include
+the following:
+
+\beginsubsection{Left-Parenthesis}
+\DefineSection{LeftParen}\idxcode{(}\idxtext{Left-Parenthesis (reader macro)}\idxref{list}
+
+%% 22.1.3 3
+%% 2.4.0 3                    
+
+The \term{left-parenthesis} initiates reading of a \term{list}.
+\funref{read} is called recursively to read successive \term{objects}
+until a right parenthesis is found in the input \term{stream}.
+A \term{list} of the \term{objects} read is returned.  Thus
+
+\code
+ (a b c)
+\endcode
+is read as a \term{list} of three \term{objects}
+(the \term{symbols} \f{a}, \f{b}, and \f{c}).
+The right parenthesis need not immediately follow the printed representation of
+the last \term{object}; \term{whitespace}\meaning{2}                              
+characters and comments may precede it.
+
+%\code
+% (defun traffic-light (color)
+%   (case color
+%     (green)
+%     (red (stop))
+%     (amber (accelerate))      ;Insert more colors after this line.
+%     ))
+%\endcode
+
+%% 22.1.3 4
+If no \term{objects} precede the right parenthesis, 
+it reads as a \term{list} of zero \term{objects} 
+(the \term{empty list}).
+
+%% 22.1.3 5
+If a \term{token} that is just a dot\idxterm{dot}\idxcode{.}
+not immediately preceded by an escape character
+is read after some \term{object}
+then exactly one more \term{object} must follow the dot,
+possibly preceded or followed by \term{whitespace}\meaning{2} or a comment,
+followed by the right parenthesis:
+
+\code
+ (a b c . d)
+\endcode
+This means that the \term{cdr} of the last \term{cons} in the 
+\term{list} is not \nil,
+but rather the \term{object} whose representation followed the dot.
+The above example might have been the result of evaluating
+
+\code
+ (cons 'a (cons 'b (cons 'c 'd)))
+\endcode
+Similarly,
+
+\code
+ (cons 'this-one 'that-one) \EV (this-one . that-one)
+\endcode
+It is permissible for the \term{object} 
+following the dot to be a \term{list}:
+
+\code
+ (a b c d . (e f . (g))) \EQ (a b c d e f g)
+\endcode
+
+For information on how the \term{Lisp printer} prints \term{lists} and \term{conses},
+\seesection\PrintingListsAndConses.
+
+\endsubsection%{Left-Parenthesis}
+
+\beginsubsection{Right-Parenthesis}
+\idxcode{)}\idxtext{Right-Parenthesis (reader macro)}
+
+%% 22.1.3 6
+
+The \term{right-parenthesis} is invalid 
+except when used in conjunction with the left parenthesis character.
+For more information, \seesection\ReaderAlgorithm.
+
+\endsubsection%{Right-Parenthesis}
+
+\beginsubsection{Single-Quote}
+\DefineSection{QuoteMacro}
+\idxcode{'}\idxtext{Single-Quote (reader macro)}\idxtext{quotation (of forms)}\idxref{quote}
+
+\b{Syntax:}  \f{'\metaparam{exp}}
+
+%% 22.1.3 7
+
+A \term{single-quote} introduces an \term{expression} to be ``quoted.''
+\term{Single-quote} followed by an \term{expression} \param{exp} 
+is treated by the \term{Lisp reader} as an abbreviation for
+and is parsed identically to the \term{expression} \f{(quote \param{exp})}.
+\Seespec{quote}.
+
+\beginsubsubsection{Examples of Single-Quote}
+
+\code
+ 'foo \EV FOO
+ ''foo \EV (QUOTE FOO)
+ (car ''foo) \EV QUOTE
+\endcode
+
+\endsubsubsection%{Examples of Single-Quote}
+
+\endsubsection%{Single-Quote}
+
+\beginsubsection{Semicolon}
+\idxcode{;}\idxtext{Semicolon (reader macro)}\idxtext{comment}
+
+\b{Syntax:} \f{;\metaparam{text}}
+
+%% 22.1.3 8   
+
+A \term{semicolon} introduces \term{characters} that are to be ignored,
+such as comments.  The \term{semicolon} and all \term{characters} up to
+and including the next \term{newline} or end of file are ignored.
+
+\beginsubsubsection{Examples of Semicolon}
+
+\code
+ (+ 3 ; three
+    4)
+\EV 7    
+\endcode
+
+\endsubsubsection%{Examples of Semicolon}
+
+\beginsubsubsection{Notes about Style for Semicolon}
+
+Some text editors make assumptions about desired indentation based on
+the number of \term{semicolons} that begin a comment.  The following style 
+conventions are common, although not by any means universal.  
+
+\beginsubsubsubsection{Use of Single Semicolon}
+
+%% 22.1.3 9
+
+Comments that begin with a single \term{semicolon} are all aligned to 
+the same column at the right (sometimes called the ``comment column'').
+The text of such a comment generally applies only to the line on which it appears.
+Occasionally two or three contain a single sentence together;
+this is sometimes indicated by indenting all but the first with an additional
+space (after the \term{semicolon}).
+
+\endsubsubsubsection%{Use of Single Semicolon}
+
+\beginsubsubsubsection{Use of Double Semicolon}
+
+%% 22.1.3 10
+
+Comments that begin with a double \term{semicolon} are all aligned to
+the same level of indentation as a \term{form} would be at that same
+position in the \term{code}.
+%% I think this is a matter of personal taste,
+%% independent of the semicolon convention. -kmp 25-Jan-92
+% A space generally follows the two semicolons.
+The text of such a comment usually describes
+    the state of the \term{program} at the point where the comment occurs,
+    the \term{code} which follows the comment,
+ or both.
+
+\endsubsubsubsection%{Use of Double Semicolon}
+
+\beginsubsubsubsection{Use of Triple Semicolon}
+
+%% 22.1.3 11
+
+Comments that begin with a triple \term{semicolon} are all aligned to
+the left margin.  Usually they are used prior to a definition or set
+of definitions, rather than within a definition.
+
+\endsubsubsubsection%{Use of Triple Semicolon}
+
+%% 22.1.3 12
+
+\beginsubsubsubsection{Use of Quadruple Semicolon}
+
+Comments that begin with a quadruple \term{semicolon} are all aligned to
+the left margin, and generally contain only a short piece of text that
+serve as a title for the code which follows, and might be used in the
+header or footer of a program that prepares code for presentation as 
+a hardcopy document.
+
+\endsubsubsubsection%{Use of Quadruple Semicolon}
+
+\beginsubsubsubsection{Examples of Style for Semicolon}
+
+\code
+;;;; Math Utilities
+
+;;; FIB computes the the Fibonacci function in the traditional
+;;; recursive way.
+
+(defun fib (n)
+  (check-type n integer)
+  ;; At this point we're sure we have an integer argument.
+  ;; Now we can get down to some serious computation.
+  (cond ((< n 0)
+         ;; Hey, this is just supposed to be a simple example.
+         ;; Did you really expect me to handle the general case?
+         (error "FIB got ~D as an argument." n))
+        ((< n 2) n)             ;fib[0]=0 and fib[1]=1
+        ;; The cheap cases didn't work.
+        ;; Nothing more to do but recurse.
+        (t (+ (fib (- n 1))     ;The traditional formula
+              (fib (- n 2)))))) ; is fib[n-1]+fib[n-2].
+\endcode
+
+\endsubsubsubsection%{Examples of Style for Semicolon}
+
+\endsubsubsection%{Notes about Style for Semicolon}
+
+\endsubsection%{Semicolon}
+
+\beginsubsection{Double-Quote}
+\DefineSection{Doublequote}
+\idxtext{Double-Quote (reader macro)}\idxtext{quotation (of strings)}\idxref{string}
+
+\b{Syntax:} \f{"\metaparam{text}"}
+
+%% 22.1.3 14
+%% 2.5.2 1
+
+The \term{double-quote} is used to begin and end a \term{string}.
+When a \term{double-quote} is encountered,
+\term{characters} are read from the \term{input} \term{stream} 
+and accumulated until another \term{double-quote} is encountered.
+If a \term{single escape} \term{character} is seen,
+the \term{single escape} \term{character} is discarded,
+the next \term{character} is accumulated, and accumulation continues.
+%% 2.5.2 3
+The accumulated \term{characters} 
+up to but not including the matching \term{double-quote} 
+are made into a \term{simple string} and returned.
+\issue{CHARACTER-PROPOSAL:2-1-1}
+It is \term{implementation-dependent}
+which \term{attributes} of the accumulated characters are removed in this process.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+Examples of the use of the \term{double-quote} character are in \thenextfigure. 
+
+\showtwo{Examples of the use of double-quote}{
+\f{"Foo"}                          & ;A string with three characters in it \cr
+\f{""}			           & ;An empty string \cr
+\f{"\\"APL\\\\360?\\" he cried."}  & ;A string with twenty characters \cr
+\f{"|x| = |-x|"}                   & ;A ten-character string \cr
+}
+
+Note that to place a single escape character or a \term{double-quote} into a string,
+such a character must be preceded by a single escape character.
+Note, too, that a multiple escape character need not be quoted by a 
+single escape character within a string.
+
+%% 2.5.2 2
+%With the exception of unquoted escape characters,
+%the characters contained by the double-quotes, taken from left to right,
+%occupy locations within the string with increasing indices.
+%The leftmost character is string element number 0, the next one
+%is element number 1, and so on.
+
+For information on how the \term{Lisp printer} prints \term{strings},
+\seesection\PrintingStrings.
+
+\endsubsection%{Double-Quote}
+
+\beginsubsection{Backquote}
+\DefineSection{Backquote}
+\idxcode{`}\idxtext{Backquote (reader macro)}\idxtext{quotation (of forms)}
+\idxref{quote}\idxref{list}\idxref{cons}
+
+%% 22.1.3 15
+
+The \term{backquote} introduces a template of a data structure to be built.  
+For example, writing
+
+\code
+ `(cond ((numberp ,x) ,@y) (t (print ,x) ,@y))
+\endcode
+is roughly equivalent to writing
+
+\code
+ (list 'cond 
+       (cons (list 'numberp x) y) 
+       (list* 't (list 'print x) y))
+\endcode
+Where a comma
+occurs in the template, 
+the \term{expression}
+following the comma is to be evaluated to produce an \term{object} to
+be inserted at that point.  Assume \f{b} has the value 3, for example, then
+evaluating the \term{form} denoted by \f{`(a b ,b ,(+ b 1) b)} produces
+the result \f{(a b 3 4 b)}.
+
+
+%% 22.1.3 16
+If a comma is immediately followed by an \term{at-sign}, 
+then the \term{form} following the \term{at-sign}
+is evaluated to produce a \term{list} of \term{objects}.
+These \term{objects} are then ``spliced'' into place in the template.  For
+example, if \f{x} has the value \f{(a b c)}, then
+
+\code
+ `(x ,x ,@x foo ,(cadr x) bar ,(cdr x) baz ,@(cdr x))
+\EV (x (a b c) a b c foo b bar (b c) baz b c)
+\endcode
+%% 22.1.3 17
+The backquote syntax can be summarized formally as follows.
+
+\beginlist
+\itemitem{\bull}
+\f{`\param{basic}} is the same as \f{'\param{basic}},
+that is, \f{(quote \param{basic})}, for any \term{expression} 
+\param{basic} that is not a \term{list} or a general \term{vector}.
+
+%% 22.1.3 18
+\itemitem{\bull}
+\f{`,\param{form}} is the same as \param{form}, for any \param{form}, provided
+that the representation of \param{form} does not begin with \term{at-sign}
+or \term{dot}.  (A similar caveat holds for all occurrences of a form after a \term{comma}.)
+
+%% 22.1.3 19
+\itemitem{\bull}
+\f{`,@\param{form}} has undefined consequences.
+
+%% 22.1.3 20
+\itemitem{\bull}
+\f{`(x1 x2 x3 ... xn . atom)}
+may be interpreted to mean
+
+\code
+ (append \lbracket\ x1\rbracket \lbracket\ x2\rbracket \lbracket\ x3\rbracket ... \lbracket\ xn\rbracket (quote atom))
+\endcode
+where the brackets are used to indicate
+a transformation of an \param{xj} as follows:
+
+%% 22.1.3 21
+\beginlist
+\itemitem{--}
+\f{[\param{form}]} is interpreted as \f{(list `\param{form})}, 
+which contains a backquoted form that must then be further interpreted.
+
+%% 22.1.3 22
+\itemitem{--}
+\f{[,\param{form}]} is interpreted as \f{(list \param{form})}.
+
+%% 22.1.3 23
+\itemitem{--}
+\f{[,@\param{form}]} is interpreted as \param{form}.
+\endlist
+
+%% 22.1.3 24
+\itemitem{\bull}
+\f{`(x1 x2 x3 ... xn)} may be interpreted to mean
+the same as the backquoted form
+\f{`(x1 x2 x3 ... xn . \nil)},
+thereby reducing it to the previous case.
+
+%% 22.1.3 25
+\itemitem{\bull}
+\f{`(x1 x2 x3 ... xn . ,form)} may be interpreted to mean
+
+\code
+ (append \lbracket\ x1\rbracket \lbracket\ x2\rbracket \lbracket\ x3\rbracket ... \lbracket\ xn\rbracket form)
+\endcode
+where the brackets indicate a transformation of an {\tt xj} as described above.
+
+%% 22.1.3 26
+\itemitem{\bull}
+\f{`(x1 x2 x3 ... xn . ,@form)} has undefined consequences.
+
+%% 22.1.3 27
+\itemitem{\bull}
+\f{`\#(x1 x2 x3 ... xn)} may be interpreted to mean
+\f{(apply \#'vector `(x1 x2 x3 ... xn))}.
+\endlist
+
+
+%% 22.1.3 28
+Anywhere ``\f{,@}'' may be used, the syntax ``\f{,.}'' may be used instead
+to indicate that it is permissible to operate \term{destructively} on 
+the \term{list structure}  produced by the form following the ``\f{,.}'' 
+(in effect, to use \funref{nconc} instead of \funref{append}).
+
+%% 22.1.3 29
+If the backquote syntax is nested, the innermost backquoted form
+should be expanded first.  This means that if several commas occur
+in a row, the leftmost one belongs to the innermost \term{backquote}.
+
+%% 22.1.3 30
+
+% An implementation is free to interpret
+% a backquoted form as any form that, when evaluated, will produce a result
+% that is \funref{equal} to the result implied by the above definition.
+% % Barmar:
+% %  Except for the non-destructive nature of ,@.  
+% %  It must also cons a new top-level list if comma is used.  e.g.,
+% %  (defun foo (x) `'(,x))
+% %  (eq (foo 1) (foo 2)) => \term{false}
+% %  i.e., it can't cache a structure and then replac it each time.
+% %
+%% Rewritten for Barmar. -kmp 11-Feb-92
+An \term{implementation} is free to interpret a backquoted \term{form} $F\sub 1$
+as any \term{form} $F\sub 2$ that, when evaluated, will produce a result that is
+the \term{same} under \funref{equal} as the result implied by the above definition, 
+provided that the side-effect behavior of the substitute \term{form} $F\sub 2$ 
+is also consistent with the description given above.
+%End of rewrite.
+The constructed
+copy of the template might or might not share \term{list} structure with the
+template itself.  As an example, the above definition implies that
+
+\code
+ `((,a b) ,c ,@d)
+\endcode
+will be interpreted as if it were
+
+\code
+ (append (list (append (list a) (list 'b) '\nil)) (list c) d '\nil)
+\endcode
+but it could also be legitimately interpreted to mean any of the following:
+
+\code
+ (append (list (append (list a) (list 'b))) (list c) d)
+ (append (list (append (list a) '(b))) (list c) d)
+ (list* (cons a '(b)) c d)
+ (list* (cons a (list 'b)) c d)
+ (append (list (cons a '(b))) (list c) d)
+ (list* (cons a '(b)) c (copy-list d))
+\endcode
+               
+\beginsubsubsection{Notes about Backquote}
+
+Since the exact manner in which the \term{Lisp reader} will parse
+an \term{expression} involving the \term{backquote} \term{reader macro} 
+is not specified, an \term{implementation} is free to choose any
+representation that preserves the semantics described.
+
+Often an \term{implementation} will choose a representation that facilitates
+pretty printing of the expression, so that \f{(pprint `(a ,b))} will display
+\f{`(a ,b)} and not, for example, \f{(list 'a b)}.  However, this is not a
+requirement.
+
+Implementors who have no particular reason to make one choice or another
+might wish to refer to {\IEEEScheme}, which identifies a popular choice of
+representation for such expressions that might provide useful to be useful
+compatibility for some user communities.  There is no requirement, however,
+that any \term{conforming implementation} use this particular representation.
+This information is provided merely for cross-reference purposes.
+
+\endsubsubsection%{Notes about Backquote}
+
+\endsubsection%{Backquote}
+
+\beginsubsection{Comma}
+\idxcode{,}\idxtext{Comma (reader macro)}\idxtext{quotation (of forms)}
+\idxref{quote}\idxref{list}\idxref{cons}
+
+%% 22.1.3 31                               
+           
+The \term{comma} is part of the backquote syntax; \seesection\Backquote.
+\term{Comma} is invalid if used other than inside the body of a 
+backquote \term{expression} as described above.
+
+\endsubsection%{Comma}
+
+\beginsubsection{Sharpsign}
+\idxcode{\#}\idxtext{Sharpsign (reader macro)}
+
+%% 22.1.3 32
+%% 22.1.3 33
+
+\term{Sharpsign} is a \term{non-terminating} \term{dispatching macro character}.
+It reads an optional 
+%was "digit \term{string}". ugh. -kmp 10-Apr-91
+sequence of digits and then one more character,
+and uses that character to select a \term{function} to run as a
+\term{reader macro function}.
+
+%% 22.1.4 1
+The \term{standard syntax} includes constructs introduced by the \f{\#} character.
+The syntax of these constructs is as follows:
+a character that identifies the type of construct is 
+followed by arguments in some form.
+If the character is a letter, its \term{case} is not important;
+\f{\#O} and \f{\#o} are considered to be equivalent, for example.
+
+%% 22.1.4 2
+Certain \f{\#} constructs allow an unsigned decimal number to appear
+between the \f{\#} and the character.
+
+%% 22.1.4 4
+The \term{reader macros} associated with the \term{dispatching macro character} \f{\#}
+are described later in this section and summarized in \thenextfigure.
+
+%% 22.1.4 3
+
+% \boxfig
+% {        
+% \def\u{undefined}
+% \def\s{signals error}
+% \def\ia{infix argument}
+% \tabskip 1pc
+% \halign to \hsize {#\hfil\tabskip 1pc&#\hfil\tabskip 0pt plus 1fil
+% &#\hfil\tabskip 1pc&#\hfil\cr
+% \noalign{\vskip -9pt}   
+% \omit\bf character&\omit\bf purpose&\omit\bf character& \omit\bf purpose\cr
+% \omit\bf combination&\omit&\omit\bf  combination\cr
+% \noalign{\vskip 2pt\hrule\vskip 2pt}
+% Backspace&\s&\f{\{}&\u*\cr
+% Tab&\s&\f{\}}&\u*\cr
+% Newline&\s&+&read-time conditional\cr
+% Linefeed&\s&-&read-time conditional\cr
+% Page&\s&.&read-time evaluation\cr
+% Return&\s&/&\u\cr
+% Space&\s&A, a&array\cr
+% !&\u*&B, b&binary rational\cr
+% \f{"}&\u&C, c&complex number\cr
+% \#&reference to = label&D, d&\u\cr
+% \$&\u&E, e&\u\cr
+% \%&\u&F, f&\u\cr      
+% \&&\u&G, g&\u\cr
+% '&function abbreviation&H, h&\u\cr
+% (&simple vector&I, i&\u\cr
+% )&\s&J, j&\u\cr
+% {\tt *}&bit vector&K, k&\u\cr
+% ,&\u&L, l&\u\cr
+% :&uninterned symbol&M, m&\u\cr
+% ;&\u&N, n&\u\cr
+% \f{<}&\s&O, o&octal rational\cr
+% \f{=}&labels following object&P, p&pathname\cr
+% \f{>}&\u&Q, q&\u\cr
+% ?&\u*&R, r&radix-$n$ rational\cr
+% @&\u&S, s&structure\cr
+% [&\u*&T, t&\u\cr
+% \f{\\}&character object&U, u&\u\cr
+% ]&\u*&V, v&\u\cr
+% {\hat}&\u&W, w&\u\cr
+% \f{\_}&\u&X, x&hexadecimal rational\cr
+% `&\u&Y, y&\u\cr
+% \f{|}&balanced comment&Z, z&\u\cr
+% \f{~}&\u&Rubout&\u\cr
+% \noalign{\vskip -9pt}
+% }}            
+% \caption{Standard \# Dispatching Macro Character Syntax}
+% \endfig
+
+{\def\u{undefined}
+\def\s{signals error}
+\def\ia{infix argument}
+\tablefigfour{Standard \# Dispatching Macro Character Syntax}{dispatch char}{purpose}{dispatch char}{purpose}{
+Backspace&\s&\f{\{}&\u*\cr
+Tab&\s&\f{\}}&\u*\cr
+Newline&\s&+&read-time conditional\cr
+Linefeed&\s&-&read-time conditional\cr
+Page&\s&.&read-time evaluation\cr
+Return&\s&/&\u\cr
+Space&\s&A, a&array\cr
+!&\u*&B, b&binary rational\cr
+\f{"}&\u&C, c&complex number\cr
+\#&reference to = label&D, d&\u\cr
+\$&\u&E, e&\u\cr
+\%&\u&F, f&\u\cr      
+\&&\u&G, g&\u\cr
+'&function abbreviation&H, h&\u\cr
+(&simple vector&I, i&\u\cr
+)&\s&J, j&\u\cr
+{\tt *}&bit vector&K, k&\u\cr
+,&\u&L, l&\u\cr
+:&uninterned symbol&M, m&\u\cr
+;&\u&N, n&\u\cr
+\f{<}&\s&O, o&octal rational\cr
+\f{=}&labels following object&P, p&pathname\cr
+\f{>}&\u&Q, q&\u\cr
+?&\u*&R, r&radix-$n$ rational\cr
+@&\u&S, s&structure\cr
+[&\u*&T, t&\u\cr
+\f{\\}&character object&U, u&\u\cr
+]&\u*&V, v&\u\cr
+{\hat}&\u&W, w&\u\cr
+\f{\_}&\u&X, x&hexadecimal rational\cr
+`&\u&Y, y&\u\cr
+\f{|}&balanced comment&Z, z&\u\cr
+\f{~}&\u&Rubout&\u\cr
+}}
+
+%* The combinations marked by an asterisk are explicitly reserved to the
+% user and will never be defined by the \clisp\ standard.
+The combinations marked by an asterisk (*) are explicitly reserved to the
+user.  No \term{conforming implementation} defines them.
+
+Note also that \term{digits} do not appear in the preceding table.  This is
+because the notations {\tt \#0}, {\tt \#1}, ..., {\tt \#9} are
+reserved for another purpose which occupies the same syntactic space.
+When a \term{digit} follows a \term{sharpsign},
+it is not treated as a dispatch character.
+Instead, an unsigned integer argument is accumulated 
+and passed as an \term{argument} to the \term{reader macro} 
+for the \term{character} that follows the digits.
+For example,
+\f{\#2A((1 2) (3 4))} is a use of {\tt \#A} with an argument of \f{2}.
+
+%% 1.2.7 13
+%% 22.1.4 5
+
+\beginsubsubsection{Sharpsign Backslash}
+\DefineSection{SharpsignBackslash}
+\idxtext{Sharpsign Backslash (reader macro)}\idxtext{Backslash (sharpsign reader macro)}\idxref{character}
+
+\b{Syntax:} \f{\#\\\metaparam{x}}
+
+%% 2.2.0 3
+
+When the \term{token} \param{x} is a single \term{character} long, 
+this parses as the literal \term{character} \param{char}.
+%% 22.1.4 7
+\term{Uppercase} and \term{lowercase} letters are distinguished after \f{\#\\};
+\f{\#\\A} and \f{\#\\a} denote different \term{character} \term{objects}.
+Any single \term{character} works after \f{\#\\},
+even those that are normally special to \funref{read}, 
+such as \term{left-parenthesis} and \term{right-parenthesis}.
+
+%% 22.1.4 6
+In the single \term{character} case,
+the \param{x} must be followed by a non-constituent \term{character}.
+After \f{\#\\} is read,
+the reader backs up over the \term{slash} and then reads a \term{token},
+treating the initial \term{slash} as a \term{single escape} \term{character}
+(whether it really is or not in the \term{current readtable}).
+
+% When the \term{token} \param{x} is more than one \term{character} long,
+% %% 22.1.4 8
+% the \param{x} has the syntax of a \term{symbol},
+% and the \term{sharpsign} \term{backslash} notation
+% parses as the \term{character} whose \term{name} is \f{(string-upcase \param{x})};
+% \seesection\CharacterNames.
+
+When the \term{token} \param{x} is more than one \term{character} long,
+%% 22.1.4 8
+the \param{x} must have the syntax of a \term{symbol} 
+with no embedded \term{package markers}.
+In this case, the \term{sharpsign} \term{backslash} notation
+parses as the \term{character} whose \term{name} is \f{(string-upcase \param{x})};
+\seesection\CharacterNames.
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\issue{CHARACTER-LOOSE-ENDS:FIX}
+%% 22.1.4 18
+%% 2.2.4 2
+% Discussion of #n\x notation for font n removed.
+%% 2.2.4 3
+%%% 22.1.4 17
+% Discussion of bits \term{attribute} and stuff like #\Control-Meta-Return removed.
+\endissue{CHARACTER-LOOSE-ENDS:FIX}
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+For information about how the \term{Lisp printer} prints \term{character} \term{objects},
+\seesection\PrintingCharacters.
+
+\endsubsubsection%{Sharpsign Backslash}
+
+\beginsubsubsection{Sharpsign Single-Quote}
+\DefineSection{SharpsignQuote}
+\idxtext{Sharpsign Single-Quote (reader macro)}\idxtext{Single-Quote (sharpsign reader macro)}\idxref{function}
+
+%% 22.1.4 19
+%% 7.1.1 10
+
+% %\f{\#'\param{foo}} is an abbreviation for \f{(function \param{foo})}.
+% Any form \param{f} preceded by \f{\#'} (\f{\#} followed by an apostrophe)
+% is assumed to have \f{(function)} wrapped around it to make
+% {\tt (function \param{f})}.  For example,
+
+Any \param{expression} preceded by \f{\#'} 
+(\term{sharpsign} followed by \term{single-quote}),
+as in \f{\#'\param{expression}},
+is treated by the \term{Lisp reader} as an abbreviation for and parsed identically 
+to the \term{expression} \f{(function \param{expression})}.
+See \specref{function}.  For example,
+
+\code
+(apply #'+ l) \EQ (apply (function +) l)
+\endcode
+
+\endsubsubsection%{Sharpsign Single-Quote}
+                   
+\beginsubsubsection{Sharpsign Left-Parenthesis}
+\DefineSection{SharpsignLeftParen}
+\idxtext{Sharpsign Left-Parenthesis (reader macro)}\idxtext{Left-Parenthesis (sharpsign reader macro)}\idxref{vector}\idxref{simple-vector}
+
+%% 2.5.1 2                                  
+%% 22.1.4 20
+
+\f{\#(} and \f{)} are used to notate a \term{simple vector}. 
+
+%% 22.1.4 21
+If an unsigned decimal integer
+appears between the \f{\#} and \f{(},
+it specifies explicitly the length of the \term{vector}.  
+The consequences are undefined if the number of \term{objects} 
+specified before the closing \f{)}
+exceeds the unsigned decimal integer.
+If the number of \term{objects} supplied before the closing \f{)}
+is less than the unsigned decimal integer but greater than zero,
+the last \term{object}
+is used to fill all
+remaining elements of the \term{vector}.
+\editornote{Barmar: This should say "signals...".}
+The consequences are undefined if the unsigned decimal integer is non-zero and
+number of \term{objects} supplied before the closing \f{)}
+is zero.
+For example,
+
+\code
+ #(a b c c c c)
+ #6(a b c c c c)
+ #6(a b c)
+ #6(a b c c)
+\endcode
+
+all mean the same thing: a \term{vector} of length \f{6}
+with \term{elements} \f{a}, \f{b}, and four occurrences of \f{c}.  
+Other examples follow:
+
+\code
+ #(a b c)               ;A vector of length 3
+ #(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47)
+                        ;A vector containing the primes below 50
+ #()                    ;An empty vector
+\endcode
+The notation \f{\#()} denotes an empty \term{vector}, as does \f{\#0()}.
+
+For information on how the \term{Lisp printer} prints \term{vectors},
+see \secref\PrintingStrings,
+    \secref\PrintingBitVectors,
+ or \secref\PrintingOtherVectors.
+
+\endsubsubsection%{Sharpsign Left-Parenthesis}
+
+\beginsubsubsection{Sharpsign Asterisk}
+\DefineSection{SharpsignStar}
+\idxtext{Sharpsign Asterisk (reader macro)}\idxtext{Asterisk (sharpsign reader macro)}\idxref{bit-vector}\idxref{simple-bit-vector}
+
+%% 22.1.4 22
+%% 2.5.3 1
+\b{Syntax:} \f{\#*\metaparam{bits}}
+
+%% 2.5.3 2
+A \term{simple bit vector} is constructed containing the indicated \term{bits}
+(\f{0}'s and \f{1}'s), where the leftmost \param{bit} has index zero 
+and the subsequent \param{bits} have increasing indices.
+
+\b{Syntax:} \f{\#\metaparam{n}*\metaparam{bits}}
+
+%% 22.1.4 23
+With an argument \param{n},
+the \term{vector} to be created is of \term{length} \param{n}.
+If the number of \param{bits} is less than \param{n} but greater than zero,
+the last bit is used to fill all remaining bits of the \term{bit vector}.
+
+The notations \f{\#*} and \f{\#0*} each denote an empty \term{bit vector}.
+
+\issue{SHARP-STAR-DELIMITER:NORMAL-DELIMITER}
+Regardless of whether the optional numeric argument \param{n} is provided,
+the \term{token} that follows the \term{asterisk} is delimited by 
+a normal \term{token} delimiter.
+However, (unless \thevalueof{*read-suppress*} is \term{true})
+an error \oftype{reader-error} is signaled 
+     if that \term{token} is not composed entirely of \f{0}'s and \f{1}'s,
+  or if \param{n} was supplied 
+        and the \term{token} is composed of more than \param{n} \param{bits},
+  or if \param{n} is greater than one, but no \param{bits} were specified.
+Neither a \term{single escape} nor a \term{multiple escape} is permitted in this \term{token}.
+\endissue{SHARP-STAR-DELIMITER:NORMAL-DELIMITER}
+
+For information on how the \term{Lisp printer} prints \term{bit vectors},
+\seesection\PrintingBitVectors.
+
+\beginsubsubsubsection{Examples of Sharpsign Asterisk}
+
+For example, 
+\code
+  #*101111
+ #6*101111
+ #6*101
+ #6*1011
+\endcode
+all mean the same thing: a \term{vector} of length \f{6}
+with \term{elements} \f{1}, \f{0}, \f{1}, \f{1}, \f{1}, and \f{1}.
+
+For example:
+
+\code
+ #*         ;An empty bit-vector
+\endcode
+
+\endsubsubsubsection%{Examples of Sharpsign Asterisk}
+
+\endsubsubsection%{Sharpsign Asterisk}
+
+\beginsubsubsection{Sharpsign Colon}
+\DefineSection{SharpsignColon}
+\idxtext{Sharpsign Colon (reader macro)}\idxtext{Colon (sharpsign reader macro)}\idxref{symbol}
+
+%% 22.1.4 24 
+
+% \f{\#:\param{foo}} denotes an \term{uninterned} \term{symbol} 
+% whose \term{name} is \param{foo}.
+% Every time this syntax is encountered,
+% a \term{distinct} \term{uninterned} \term{symbol} is created.
+% \f{\#:} requires \param{foo} to have the syntax of a 
+% \term{symbol} name with no embedded \term{package markers}.
+%% Replaced:
+
+\b{Syntax:}  \f{\#:\metaparam{symbol-name}}
+
+\f{\#:} introduces an \term{uninterned} \term{symbol} whose \term{name} 
+is \param{symbol-name}.  Every time this syntax is encountered,
+a \term{distinct} \term{uninterned} \term{symbol} is created.
+The \param{symbol-name} must have the syntax of a \term{symbol} 
+with no \term{package prefix}.
+
+For information on how the \term{Lisp reader} 
+prints \term{uninterned} \term{symbols},
+\seesection\PrintingSymbols.
+
+\endsubsubsection%{Sharpsign Colon}
+
+\beginsubsubsection{Sharpsign Dot}
+\DefineSection{SharpsignDot}
+\idxtext{Sharpsign Dot (reader macro)}\idxtext{Dot (sharpsign reader macro)}\idxref{eval}\idxref{*read-eval*}
+
+%% 22.1.4 25
+
+\f{\#.\param{foo}} is read as the \term{object} resulting from the evaluation
+of the \term{object} represented by \param{foo}.
+The evaluation is done during the \funref{read} process,
+when the \f{\#.} notation is encountered.
+The \f{\#.} syntax therefore performs a read-time evaluation of \param{foo}.
+
+The normal effect of {\tt \#.} is inhibited when \thevalueof{*read-eval*} is \term{false}.
+%Barmar asked what error type gets signaled. I made it be PARSE-ERROR. -kmp 17-Oct-90
+%Oops. READER-ERROR. -kmp 15-Jan-91
+\issue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+In that situation, an error \oftype{reader-error} is signaled.
+\endissue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+
+%% 22.1.4 26
+For an \term{object}
+that does not have a convenient printed
+representation, a \term{form} that computes the \term{object} can be given using
+the \f{\#.} notation.
+\issue{SHARP-COMMA-CONFUSION:REMOVE}
+%% issue here
+%The following will be deleted.
+%
+%or {\tt \#,}.
+%End of deletion.
+\endissue{SHARP-COMMA-CONFUSION:REMOVE}
+
+\endsubsubsection%{Sharpsign Dot}
+
+\issue{SHARP-COMMA-CONFUSION:REMOVE}
+%% 22.1.4 27
+%\beginsubsubsection{Sharpsign Comma}
+% Discussion of Sharpsign Comma removed here.
+%\endsubsubsection%{Sharpsign Comma}
+\endissue{SHARP-COMMA-CONFUSION:REMOVE}
+
+\beginsubsubsection{Sharpsign B}
+\DefineSection{SharpsignB}
+\idxtext{Sharpsign B (reader macro)}\idxtext{B (sharpsign reader macro)}\idxref{*read-base*}
+
+%% 22.1.4 28
+
+\f{\#B}\param{rational} reads \param{rational} in binary (radix 2).
+For example, 
+
+\code
+ #B1101 \EQ 13 ;1101\ssst
+ #b101/11 \EQ 5/3
+\endcode
+
+\issue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+The consequences are undefined if the token immediately following
+the \f{\#B} does not have the syntax of a binary (\ie radix 2) \term{rational}.
+\endissue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+
+\endsubsubsection%{Sharpsign B}
+
+\beginsubsubsection{Sharpsign O}
+\DefineSection{SharpsignO}
+\idxtext{Sharpsign O (reader macro)}\idxtext{O (sharpsign reader macro)}\idxref{*read-base*}
+
+%% 22.1.4 29
+
+\f{\#O}\param{rational} reads \param{rational} in octal (radix 8).
+For example, 
+
+\code
+ #o37/15 \EQ 31/13
+ #o777 \EQ 511
+ #o105 \EQ 69 ;105\ssse
+\endcode
+
+\issue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+The consequences are undefined if the token immediately following
+the \f{\#O} does not have the syntax of an octal (\ie radix 8) \term{rational}.
+\endissue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+
+\endsubsubsection%{Sharpsign O}
+
+\beginsubsubsection{Sharpsign X}
+\DefineSection{SharpsignX}
+\idxtext{Sharpsign X (reader macro)}\idxtext{X (sharpsign reader macro)}\idxref{*read-base*}
+
+%% 22.1.4 30
+
+\f{\#X}\param{rational} reads \param{rational} in hexadecimal (radix 16).
+The digits above \f{9} are the letters \f{A} through \f{F} (the lowercase
+letters \f{a} through \f{f} are also acceptable).  For example,
+
+\code
+ #xF00 \EQ 3840             
+ #x105 \EQ 261 ;105\ssss
+\endcode
+
+\issue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+The consequences are undefined if the token immediately following
+the \f{\#X} does not have the syntax of a hexadecimal (\ie radix 16) \term{rational}.
+\endissue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+
+\endsubsubsection%{Sharpsign X}
+
+\beginsubsubsection{Sharpsign R}
+\DefineSection{SharpsignR}
+\idxtext{Sharpsign R (reader macro)}\idxtext{R (sharpsign reader macro)}\idxref{*read-base*}
+
+%% 22.1.4 31                 
+\f{\#\param{n}R}
+                                                             
+\f{\#\param{radix}R\param{rational}} reads \param{rational} in radix \param{radix}.
+\param{radix} must consist of only digits
+that are interpreted as an \term{integer}
+in decimal radix; its value must be between 2 and 36 (inclusive).
+Only valid digits
+for the specified radix may be used.
+
+%% 22.1.4 32
+For example, \f{\#3r102} is another way of writing \f{11} (decimal), 
+and \f{\#11R32}
+is another way of writing \f{35} (decimal).  
+For radices larger than 10, letters of
+the alphabet are used in order for the digits after \f{9}.
+No alternate \f{\#} notation exists for the decimal radix since a
+decimal point suffices.
+
+\Thenextfigure\ contains examples of the use of {\tt\#B},
+{\tt \#O}, {\tt \#X}, and {\tt \#R}.
+
+\showtwo{Radix Indicator Example}{
+\f{\#2r11010101}  & ;Another way of writing \f{213} decimal \cr
+\f{\#b11010101}   & ;Ditto                                  \cr
+\f{\#b+11010101}  & ;Ditto                                  \cr
+\f{\#o325}        & ;Ditto, in octal radix                  \cr
+\f{\#xD5}         & ;Ditto, in hexadecimal radix            \cr
+\f{\#16r+D5}      & ;Ditto                                  \cr
+\f{\#o-300}       & ;Decimal \f{-192}, written in base 8    \cr
+\f{\#3r-21010}    & ;Same thing in base 3                   \cr
+\f{\#25R-7H}      & ;Same thing in base 25                  \cr
+\f{\#xACCEDED}    & ;\f{181202413}, in hexadecimal radix    \cr
+}
+
+\issue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+The consequences are undefined if the token immediately following
+the \f{\#\param{n}R} does not have the syntax of a \term{rational} in radix \param{n}.
+\endissue{SHARP-O-FOOBAR:CONSEQUENCES-UNDEFINED}
+
+\endsubsubsection%{Sharpsign R}
+
+\beginsubsubsection{Sharpsign C}
+\DefineSection{SharpsignC}
+\idxtext{Sharpsign C (reader macro)}\idxtext{C (sharpsign reader macro)}\idxref{complex}
+
+\issue{READ-SUPPRESS-CONFUSING:GENERALIZE}
+% \f{\#C} followed by a \term{list} of the real and imaginary parts denotes
+% a \term{complex} number.
+\f{\#C} reads a following \term{object}, which must be a \term{list} of
+length two whose \term{elements} are both \term{reals}.
+These \term{reals} denote, respectively,
+the real and imaginary parts of a \term{complex} number.
+\endissue{READ-SUPPRESS-CONFUSING:GENERALIZE}
+%% 2.1.4 2
+If the two parts as notated are not of the same data type,
+then they are converted 
+according to the rules of floating-point \term{contagion}
+described in \secref\NumericContagionRules.
+
+\f{\#C(\param{real} \param{imag})} is equivalent to 
+\f{\#.(complex (quote \param{real}) (quote \param{imag}))},
+% I added this next phrase for clarity. -kmp 23-Aug-93
+except that \f{\#C} is not affected by \varref{*read-eval*}.
+\Seefun{complex}.
+
+\Thenextfigure\ contains examples of the use of {\tt \#C}.
+
+\showtwo{Complex Number Example}{
+\f{\#C(3.0s1 2.0s-1)} & ;A \term{complex} with \term{small float} parts.      \cr
+\f{\#C(5 -3)      }   & ;A ``Gaussian integer''                               \cr
+\f{\#C(5/3 7.0) }     & ;Will be converted internally to \f{\#C(1.66666 7.0)} \cr
+\f{\#C(0 1)}          & ;The imaginary unit; that is, i.                      \cr
+}
+
+For further information, 
+\seesection\PrintingComplexes\ and \secref\SyntaxOfComplexes.
+
+\endsubsubsection%{Sharpsign C}
+
+\beginsubsubsection{Sharpsign A}
+\DefineSection{SharpsignA}
+\idxtext{Sharpsign A (reader macro)}\idxtext{A (sharpsign reader macro)}\idxref{array}
+
+%% 22.1.4 33           
+\f{\#\param{n}A}
+
+\f{\#\param{n}\f{A}\param{object}} constructs an \param{n}-dimensional \term{array},
+using \param{object} as the value of the \kwd{initial-contents} argument
+to \funref{make-array}.
+
+%% 22.1.4 34                                                  
+For example, \f{\#2A((0 1 5) (foo 2 (hot dog)))} represents a 2-by-3 matrix:
+
+\code
+ 0       1       5
+ foo     2       (hot dog)
+\endcode
+In contrast, \f{\#1A((0 1 5) (foo 2 (hot dog)))} 
+represents a \term{vector} of \term{length} \f{2} 
+whose \term{elements} are \term{lists}:
+
+\code
+ (0 1 5) (foo 2 (hot dog))
+\endcode
+\f{\#0A((0 1 5) (foo 2 (hot dog)))} represents a zero-dimensional
+\term{array} whose sole element is a \term{list}:
+
+\code
+ ((0 1 5) (foo 2 (hot dog)))
+\endcode
+\f{\#0A foo} represents 
+a zero-dimensional \term{array} whose sole element is the 
+\term{symbol} \f{foo}.
+The notation \f{\#1A foo} is not valid because \f{foo} is
+not a \term{sequence}.
+
+If some \term{dimension} of the \term{array}
+whose representation is being parsed is found to be \f{0},
+all \term{dimensions} to the right 
+(\ie the higher numbered \term{dimensions})
+are also considered to be \f{0}.
+
+For information on how the \term{Lisp printer} prints \term{arrays},
+see \secref\PrintingStrings,
+    \secref\PrintingBitVectors,
+    \secref\PrintingOtherVectors,
+ or \secref\PrintingOtherArrays.
+
+\endsubsubsection%{Sharpsign A}
+
+\beginsubsubsection{Sharpsign S}
+\DefineSection{SharpsignS}
+\idxtext{Sharpsign S (reader macro)}\idxtext{S (sharpsign reader macro)}\idxref{structure}
+
+%% 22.1.4 35
+
+\f{\#s(name slot1 value1 slot2 value2 ...)}
+denotes a \term{structure}.  This is valid only if \param{name} is the name
+of a \term{structure} \term{type} already defined by \macref{defstruct} 
+and if the \term{structure} \term{type} has a standard constructor function.
+Let \param{cm} stand for the name of this constructor function;
+then this syntax is equivalent to
+
+\code
+ #.(cm keyword1 'value1 keyword2 'value2 ...)
+\endcode
+
+where each \param{keywordj} is the result of computing
+
+\code
+ (intern (string slotj) (find-package 'keyword))
+\endcode
+    
+The net effect is that the constructor function is called with the specified
+slots having the specified values. 
+\issue{STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS}
+(This coercion feature is deprecated; in the future, keyword names will 
+ be taken in the package they are read in, so \term{symbols} that are 
+ actually in \thepackage{keyword} should be used if that is what is desired.)
+\endissue{STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS}
+
+Whatever \term{object} the constructor function returns
+is returned by the \f{\#S} syntax.
+
+For information on how the \term{Lisp printer} prints \term{structures},
+\seesection\PrintingStructures.
+
+\endsubsubsection%{Sharpsign S}
+
+\beginsubsubsection{Sharpsign P}
+\DefineSection{SharpsignP}
+\idxtext{Sharpsign P (reader macro)}\idxtext{P (sharpsign reader macro)}\idxref{pathname}
+
+\issue{PATHNAME-PRINT-READ:SHARPSIGN-P}                  
+
+\f{\#P} reads a following \term{object}, which must be a \term{string}.
+
+% {\tt \#P"..."} is equivalent to 
+% {\tt  \#.(parse-namestring "...")}.
+\f{\#P\metaparam{expression}} is equivalent to 
+\f{\#.(parse-namestring '\metaparam{expression})},
+% I added this next phrase for clarity. -kmp 23-Aug-93
+except that \f{\#P} is not affected by \varref{*read-eval*}.
+
+For information on how the \term{Lisp printer} prints \term{pathnames},
+see \secref\PrintingPathnames.
+
+\endissue{PATHNAME-PRINT-READ:SHARPSIGN-P}                  
+
+\endsubsubsection%{Sharpsign P}
+
+\beginsubsubsection{Sharpsign Equal-Sign}
+\idxtext{Sharpsign Equal-Sign (reader macro)}\idxtext{Equal-Sign (sharpsign reader macro)}\idxref{*print-circle*}
+
+%% 22.1.4 36                      
+\f{\#\param{n}=}
+
+\f{\#\param{n}=\param{object}} reads as whatever \term{object}
+has \param{object} as its printed representation.  However, that \term{object}
+is labeled by \param{n}, a required unsigned decimal integer, for
+possible reference by the syntax \f{\#\param{n}\#}.
+The scope of the label is the \term{expression} being read by the outermost
+call to \funref{read}; within this \term{expression},
+the same label may not appear twice.
+
+\endsubsubsection%{Sharpsign Equal-Sign}
+
+\beginsubsubsection{Sharpsign Sharpsign}
+\idxtext{Sharpsign Sharpsign (reader macro)}\idxtext{Sharpsign (sharpsign reader macro)}\idxref{*print-circle*}
+
+%% 22.1.4 37                  
+\f{\#\param{n}\#}
+ 
+\f{\#\param{n}\#}, where \param{n} is a required unsigned decimal
+\term{integer},
+provides a reference to some \term{object} labeled by \f{\#\param{n}=};
+that is, \f{\#\param{n}\#} represents a pointer to the same 
+(\funref{eq}) \term{object} labeled by \f{\#\param{n}=}.
+For example, a structure created in the variable \f{y} by this code:
+
+\code
+ (setq x (list 'p 'q))
+ (setq y (list (list 'a 'b) x 'foo x))
+ (rplacd (last y) (cdr y))
+\endcode
+could be represented in this way:
+
+\code
+ ((a b) . #1=(#2=(p q) foo #2# . #1#))
+\endcode
+Without this notation, but with \varref{*print-length*} set to \f{10}
+and \varref{*print-circle*} set to \nil,
+the structure would print in this way:
+
+\code
+ ((a b) (p q) foo (p q) (p q) foo (p q) (p q) foo (p q) ...)
+\endcode
+A reference \f{\#\param{n}\#} may only occur after a label \f{\#\param{n}=};
+forward references are not permitted.  The reference
+may not appear as the labeled object itself (that is,
+\f{\#\param{n}=\#\param{n}\#}) may not be written 
+because the \term{object}
+labeled by \f{\#\param{n}=} is not well defined in this case.
+
+\endsubsubsection%{Sharpsign Sharpsign}
+
+\beginsubsubsection{Sharpsign Plus}
+\idxtext{Sharpsign Plus (reader macro)}\idxtext{Plus (sharpsign reader macro)}\idxref{*features*}
+
+%% 22.1.4 38
+
+\f{\#+} provides a read-time conditionalization facility;
+the syntax is \f{\#+\param{test} \param{expression}}.
+If the \term{feature expression} \param{test} succeeds,
+then this textual notation represents an \term{object}
+ whose printed representation is \param{expression}.
+If the \term{feature expression} \param{test} fails,
+then this textual notation is treated as \term{whitespace}\meaning{2}; 
+ that is, it is as if the ``\f{\#+} \param{test} \param{expression}'' 
+ did not appear and only a \term{space} appeared in its place.
+
+%% 22.1.4 39
+For a detailed description of success and failure in \term{feature expressions},
+\seesection\FeatureExpressions.
+
+%% 22.1.4 42
+\f{\#+} operates by first reading the \term{feature expression}
+and then skipping over the \param{form} if the \term{feature expression} fails.
+\issue{SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD}
+While reading the \param{test}, the \term{current package} is \thepackage{keyword}.
+\endissue{SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD}
+Skipping over the \param{form} is accomplished by \term{binding} 
+\varref{*read-suppress*} to \term{true} and then calling \funref{read}.
+
+For examples, \seesection\FeatureExpExamples.
+
+\endsubsubsection%{Sharpsign Plus}
+
+\beginsubsubsection{Sharpsign Minus}
+\idxtext{Sharpsign Minus (reader macro)}\idxtext{Minus (sharpsign reader macro)}\idxref{*features*}
+
+%% 22.1.4 43
+
+\f{\#-} is like \f{\#+} 
+except that it skips the \param{expression} if the \param{test} succeeds; 
+that is,
+
+\code
+#-\param{test} \param{expression} \EQ #+(not \param{test}) \param{expression}
+\endcode
+
+For examples, \seesection\FeatureExpExamples.
+
+\endsubsubsection%{Sharpsign Minus}
+
+\beginsubsubsection{Sharpsign Vertical-Bar}
+\idxtext{Sharpsign Vertical-Bar (reader macro)}\idxtext{Vertical-Bar (sharpsign reader macro)}\idxtext{comment}
+
+%% 22.1.4 44      
+
+\f{\#|...|\#} is treated as a comment by the reader.
+It must be balanced with respect to other occurrences of \f{\#|} and \f{|\#},
+but otherwise may contain any characters whatsoever.
+
+\beginsubsubsubsection{Examples of Sharpsign Vertical-Bar}
+
+The following are some examples that exploit the \f{\#|...|\#} notation:
+
+\code
+;;; In this example, some debugging code is commented out with #|...|#
+;;; Note that this kind of comment can occur in the middle of a line
+;;; (because a delimiter marks where the end of the comment occurs)
+;;; where a semicolon comment can only occur at the end of a line 
+;;; (because it comments out the rest of the line).
+ (defun add3 (n) #|(format t "~&Adding 3 to ~D." n)|# (+ n 3))
+\goodbreak
+;;; The examples that follow show issues related to #| ... |# nesting.
+
+;;; In this first example, #| and |# always occur properly paired,
+;;; so nesting works naturally.
+ (defun mention-fun-fact-1a ()
+   (format t "CL uses ; and #|...|# in comments."))
+\EV MENTION-FUN-FACT-1A
+ (mention-fun-fact-1a)
+\OUT CL uses ; and #|...|# in comments.
+\EV NIL
+ #| (defun mention-fun-fact-1b ()
+      (format t "CL uses ; and #|...|# in comments.")) |#
+ (fboundp 'mention-fun-fact-1b) \EV NIL
+\goodbreak
+;;; In this example, vertical-bar followed by sharpsign needed to appear
+;;; in a string without any matching sharpsign followed by vertical-bar
+;;; having preceded this.  To compensate, the programmer has included a
+;;; slash separating the two characters.  In case 2a, the slash is 
+;;; unnecessary but harmless, but in case 2b, the slash is critical to
+;;; allowing the outer #| ... |# pair match.  If the slash were not present,
+;;; the outer comment would terminate prematurely.
+ (defun mention-fun-fact-2a ()
+   (format t "Don't use |\\# unmatched or you'll get in trouble!"))
+\EV MENTION-FUN-FACT-2A
+ (mention-fun-fact-2a)
+\OUT Don't use |# unmatched or you'll get in trouble!
+\EV NIL
+ #| (defun mention-fun-fact-2b ()
+      (format t "Don't use |\\# unmatched or you'll get in trouble!") |#
+ (fboundp 'mention-fun-fact-2b) \EV NIL
+\goodbreak
+;;; In this example, the programmer attacks the mismatch problem in a
+;;; different way.  The sharpsign vertical bar in the comment is not needed
+;;; for the correct parsing of the program normally (as in case 3a), but 
+;;; becomes important to avoid premature termination of a comment when such 
+;;; a program is commented out (as in case 3b).
+ (defun mention-fun-fact-3a () ; #|
+   (format t "Don't use |# unmatched or you'll get in trouble!"))
+\EV MENTION-FUN-FACT-3A
+ (mention-fun-fact-3a)
+\OUT Don't use |# unmatched or you'll get in trouble!
+\EV NIL
+ #|
+ (defun mention-fun-fact-3b () ; #|
+   (format t "Don't use |# unmatched or you'll get in trouble!"))
+ |#
+ (fboundp 'mention-fun-fact-3b) \EV NIL
+\endcode
+
+\endsubsubsubsection%{Examples of Sharpsign Vertical-Bar}
+
+\beginsubsubsubsection{Notes about Style for Sharpsign Vertical-Bar}
+
+Some text editors that purport to understand Lisp syntax treat any \f{|...|}
+as balanced pairs that cannot nest (as if they were just balanced pairs of 
+the multiple escapes used in notating certain symbols).  To compensate for 
+this deficiency, some programmers use the notation \f{\#||...\#||...||\#...||\#}
+instead of \f{\#|...\#|...|\#...|\#}.   Note that this alternate usage is not
+a different \term{reader macro}; it merely exploits the fact that the additional
+vertical-bars occur within the comment in a way that tricks certain text editor
+into better supporting nested comments.  As such, one might sometimes see code
+like:
+
+\code
+ #|| (+ #|| 3 ||# 4 5) ||# 
+\endcode
+
+Such code is equivalent to:
+
+\code
+ #| (+ #| 3 |# 4 5) |#
+\endcode
+
+\endsubsubsubsection%{Notes about Style for Sharpsign Vertical-Bar}
+
+\endsubsubsection%{Sharpsign Vertical-Bar}
+
+\beginsubsubsection{Sharpsign Less-Than-Sign}
+\DefineSection{SharpsignLeftAngle}
+\idxtext{Sharpsign Less-Than-Sign (reader macro)}\idxtext{Less-Than-Sign (sharpsign reader macro)}
+
+%% 22.1.4 46      
+
+{\tt  \#<} is not valid reader syntax.
+The \term{Lisp reader} will signal an error 
+\issue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+\oftype{reader-error}
+\endissue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+on encountering \f{\#<}.
+This syntax is typically used in the printed representation 
+of \term{objects} that cannot be read back in.  
+
+\endsubsubsection%{Sharpsign Less-Than-Sign}
+
+\beginsubsubsection{Sharpsign Whitespace}
+\idxtext{Sharpsign Whitespace}
+
+%% 22.1.4 47
+
+%Used to explicitly mention Newline, Page, Return
+%but those are not chars in the standard syntax. -kmp 13-May-91
+
+\f{\#} followed immediately by \term{whitespace}\meaning{1} is not valid reader syntax.
+The \term{Lisp reader} will signal an error \oftype{reader-error} if it
+encounters the reader macro notation \f{\#\NewlineChar} or \f{\#\SpaceChar}.
+
+\endsubsubsection%{Sharpsign Whitespace}
+
+\beginsubsubsection{Sharpsign Right-Parenthesis}
+\idxtext{Sharpsign Right-Parenthesis}
+
+%% 22.1.4 48
+
+This is not valid reader syntax.
+
+%I added this.  It's alluded to elsewhere that it really signals. -kmp 15-Jan-91
+The \term{Lisp reader} will signal an error 
+\issue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+\oftype{reader-error}
+\endissue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+%(
+upon encountering \f{\#)}.
+
+\endsubsubsection%{Sharpsign Right-Parenthesis}
+
+\endsubsection%{Sharpsign}
+
+\beginsubsection{Re-Reading Abbreviated Expressions}
+\idxtext{Dot Dot}\idxcode{..}
+\idxtext{Dot Dot Dot}\idxcode{...}
+\idxtext{Sharpsign Whitespace}\idxtext{Sharpsign Right-Parenthesis}
+
+%% 22.1.6 53
+Note that the \term{Lisp reader} will 
+% Only generally because ".." due to print-lines in mid-string won't reliably signal.
+generally
+signal an error \oftype{reader-error}
+when reading an \term{expression}\meaning{2} that has been
+abbreviated because of length or level limits 
+(see \varref{*print-level*},
+     \varref{*print-length*},
+ and \varref{*print-lines*})
+due to restrictions on ``\f{..}'', ``\f{...}'', ``\f{\#}'' followed by \term{whitespace}\meaning{1},
+%(
+and ``\f{\#)}''.
+
+\endsubsection%{Re-Reading Abbreviated Expressions}

concept-meta-objects.tex

@@ -0,0 +1,72 @@
+% -*- Mode: TeX -*-
+% Meta-Objects
+
+
+
+The implementation of the \OS\ manipulates \term{classes}, \term{methods},
+and \term{generic functions}.  The \OS\ contains a set of 
+\term{generic functions} defined by \term{methods} on \term{classes}; 
+the behavior of those \term{generic functions} defines the behavior of
+the \OS.  The \term{instances} of the \term{classes} on which those
+\term{methods} are defined are called meta-objects.  
+%Programming
+%at the meta-object protocol level involves defining new classes of
+%meta-objects along with methods specialized on these classes.
+
+
+\beginsubsection{Standard Meta-objects}
+
+The \OS\ supplies a set of meta-objects, called standard meta-objects.
+These include \theclass{standard-object} and
+\term{instances} of the classes \typeref{standard-method}, 
+\typeref{standard-generic-function}, and \typeref{method-combination}.
+
+\beginlist
+
+\editornote{KMP: This is said redundantly in the definition of STANDARD-METHOD.}%!!!
+\itemitem{\bull} 
+\Theclass{standard-method} is the default \term{class} of 
+\term{methods} defined by the 
+ \macref{defmethod} and
+ \macref{defgeneric} \term{forms}.
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% \macref{generic-function},
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\issue{WITH-ADDED-METHODS:DELETE}
+%\specref{with-added-methods},
+\endissue{WITH-ADDED-METHODS:DELETE}%
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+%  \specref{generic-flet}, 
+% and
+%  \specref{generic-labels}.
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+
+\itemitem{\bull}
+\Theclass{standard-generic-function} is the default \term{class} of 
+\term{generic functions} defined by the forms
+  \macref{defmethod},
+  \macref{defgeneric},
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+% \macref{generic-function},
+% \specref{generic-flet},
+% \specref{generic-labels},
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\issue{WITH-ADDED-METHODS:DELETE}
+% \specref{with-added-methods},
+\endissue{WITH-ADDED-METHODS:DELETE}%
+ and
+  \macref{defclass}.
+
+\itemitem{\bull} The \term{class} named \typeref{standard-object} 
+is an \term{instance} of \theclass{standard-class} 
+and is a \term{superclass} of every \term{class} that is an
+\term{instance} of \typeref{standard-class} except itself and 
+\typeref{structure-class}.
+
+\itemitem{\bull} Every \term{method} combination object is 
+an \term{instance} of a \subclassof{method-combination}.
+
+\endlist
+
+\endsubsection%{Standard Meta-objects} 
+

concept-numbers.tex

@@ -0,0 +1,665 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Numeric Operations}
+\DefineSection{NumericOperations}
+
+\clisp\ provides a large variety of operations related to \term{numbers}.
+This section provides an overview of those operations by grouping them
+into categories that emphasize some of the relationships among them.
+
+\Thenextfigure\ shows \term{operators} relating to
+arithmetic operations.
+
+\displaythree{Operators relating to Arithmetic.}{
+*&1+&gcd\cr
++&1-&incf\cr
+-&conjugate&lcm\cr
+/&decf&\cr
+}
+
+\Thenextfigure\ shows \term{defined names} relating to
+exponential, logarithmic, and trigonometric operations.
+
+\displaythree{Defined names relating to Exponentials, Logarithms, and Trigonometry.}{
+abs&cos&signum\cr
+acos&cosh&sin\cr
+acosh&exp&sinh\cr
+asin&expt&sqrt\cr
+asinh&isqrt&tan\cr
+atan&log&tanh\cr
+atanh&phase&\cr
+cis&pi&\cr
+}
+
+\Thenextfigure\ shows \term{operators} relating to
+numeric comparison and predication.
+
+\displaythree{Operators for numeric comparison and predication.}{
+/=&>=&oddp\cr
+<&evenp&plusp\cr
+<=&max&zerop\cr
+=&min&\cr
+>&minusp&\cr
+}
+
+\Thenextfigure\ shows \term{defined names} relating to
+numeric type manipulation and coercion.
+
+\displaythree{Defined names relating to numeric type manipulation and coercion.}{
+ceiling&float-radix&rational\cr
+complex&float-sign&rationalize\cr
+decode-float&floor&realpart\cr
+denominator&fround&rem\cr
+fceiling&ftruncate&round\cr
+ffloor&imagpart&scale-float\cr
+float&integer-decode-float&truncate\cr
+float-digits&mod&\cr
+float-precision&numerator&\cr
+}
+
+\beginsubsubsection{Associativity and Commutativity in Numeric Operations}
+
+For functions that are mathematically associative (and possibly commutative),
+a \term{conforming implementation} may process the \term{arguments} in any manner 
+consistent with associative (and possibly commutative) rearrangement.  This does not
+affect the order in which the \term{argument} \term{forms} are \term{evaluated};
+for a discussion of evaluation order, \seesection\FunctionForms.
+What is unspecified is only the order in which the \term{parameter} \term{values}
+are processed.  This implies that \term{implementations} may differ in which 
+automatic \term{coercions} are applied; \seesection\NumericContagionRules.
+
+A \term{conforming program} can control the order of processing explicitly by 
+separating the operations into separate (possibly nested) \term{function forms},
+or by writing explicit calls to \term{functions} that perform coercions.
+
+\beginsubsubsubsection{Examples of Associativity and Commutativity in Numeric Operations}
+
+Consider the following expression, in which we assume that \f{1.0} and
+\f{1.0e-15} both denote \term{single floats}:
+
+\code
+ (+ 1/3 2/3 1.0d0 1.0 1.0e-15)
+\endcode
+
+One \term{conforming implementation} might
+process the \term{arguments} from left to right,
+first adding \f{1/3} and \f{2/3} to get \f{1}, 
+then converting that to a \term{double float} 
+for combination with \f{1.0d0},
+then successively converting and adding \f{1.0} and \f{1.0e-15}.
+
+Another \term{conforming implementation} might process the \term{arguments} from
+right to left, first performing a \term{single float} addition of \f{1.0} and
+\f{1.0e-15} (perhaps losing accuracy in the process), then converting the sum to 
+a \term{double float} and adding \f{1.0d0}, then converting \f{2/3} to a
+\term{double float} and adding it, and then converting \f{1/3} and adding that.
+
+A third \term{conforming implementation} might first scan all the \term{arguments},
+process all the \term{rationals} first to keep that part of the computation exact,
+then find an \term{argument} of the largest floating-point format among all the
+\term{arguments} and add that, and then add in all other \term{arguments}, converting
+each in turn (all in a perhaps misguided attempt to make the computation as accurate
+as possible).
+
+In any case, all three strategies are legitimate.
+
+A \term{conforming program} could control the order by writing, for example,
+
+\code
+ (+ (+ 1/3 2/3) (+ 1.0d0 1.0e-15) 1.0)
+\endcode
+
+\endsubsubsubsection%{Examples of Associativity and Commutativity in Numeric Operations}
+
+\endsubsubsection%{Associativity and Commutativity in Numeric Operations}
+
+\beginsubsubsection{Contagion in Numeric Operations}
+\DefineSection{NumericContagionRules}
+
+For information about the contagion rules for implicit coercions of \term{arguments} 
+in numeric operations, see
+     \secref\RuleOfFloatPrecisionContagion, 
+     \secref\RuleOfFloatAndRationalContagion,
+ and \secref\RuleOfComplexContagion.
+
+\endsubsubsection%{Contagion in Numeric Operations}
+
+\beginsubsubsection{Viewing Integers as Bits and Bytes}
+
+\beginsubsubsubsection{Logical Operations on Integers}
+
+%% 12.7.0 1
+%% 12.7.0 2
+Logical operations require \term{integers} as arguments;
+%!!! Is this a formal use of "should be signaled"? -kmp 13-May-91
+an error \oftype{type-error} should be signaled 
+if an argument is supplied that is not an \term{integer}.
+\term{Integer} arguments to logical operations are treated as if
+they were represented in two's-complement notation.
+%Internally an implementation 
+%might or might not use a two's-complement representation.
+
+
+\Thenextfigure\ shows \term{defined names} relating to
+logical operations on numbers.
+
+\displaythree{Defined names relating to logical operations on numbers.}{
+ash&boole-ior&logbitp\cr
+boole&boole-nand&logcount\cr
+boole-1&boole-nor&logeqv\cr
+boole-2&boole-orc1&logior\cr
+boole-and&boole-orc2&lognand\cr
+boole-andc1&boole-set&lognor\cr
+boole-andc2&boole-xor&lognot\cr
+boole-c1&integer-length&logorc1\cr
+boole-c2&logand&logorc2\cr
+boole-clr&logandc1&logtest\cr
+boole-eqv&logandc2&logxor\cr
+}                    
+                    
+\endsubsubsubsection%{Logical Operations on Integers}
+
+\beginsubsubsubsection{Byte Operations on Integers}
+
+%% 12.8.0 2
+The byte-manipulation \term{functions} use \term{objects} 
+called \term{byte specifiers} to designate the size and position
+of a specific \term{byte} within an \term{integer}.
+The representation of a \term{byte specifier} is \term{implementation-dependent};
+it might or might not be a \term{number}.
+\Thefunction{byte} will construct a \term{byte specifier},
+which various other byte-manipulation \term{functions} will accept.
+
+\Thenextfigure\ shows \term{defined names} relating to
+manipulating \term{bytes} of \term{numbers}.
+
+\displaythree{Defined names relating to byte manipulation.}{
+byte&deposit-field&ldb-test\cr
+byte-position&dpb&mask-field\cr
+byte-size&ldb&\cr
+}
+
+\endsubsubsubsection%{Byte Operations on Integers}
+
+\endsubsubsection%{Viewing Integers as Bits and Bytes}
+
+\endsubsection%{Numeric Operations}
+
+\beginSubsection{Implementation-Dependent Numeric Constants}
+
+\Thenextfigure\ shows \term{defined names} relating to
+\term{implementation-dependent} details about \term{numbers}.
+
+\displaytwo{Defined names relating to implementation-dependent details about numbers.}{
+double-float-epsilon&most-negative-fixnum\cr
+double-float-negative-epsilon&most-negative-long-float\cr
+least-negative-double-float&most-negative-short-float\cr
+least-negative-long-float&most-negative-single-float\cr
+least-negative-short-float&most-positive-double-float\cr
+least-negative-single-float&most-positive-fixnum\cr
+least-positive-double-float&most-positive-long-float\cr
+least-positive-long-float&most-positive-short-float\cr
+least-positive-short-float&most-positive-single-float\cr
+least-positive-single-float&short-float-epsilon\cr
+long-float-epsilon&short-float-negative-epsilon\cr
+long-float-negative-epsilon&single-float-epsilon\cr
+most-negative-double-float&single-float-negative-epsilon\cr
+}
+
+\endSubsection%{Implementation-Dependent Numeric Constants}
+\beginsubsection{Rational Computations}
+\DefineSection{RationalComputations}
+
+%% 12.1.0 2
+The rules in this section apply to \term{rational} computations.
+
+\beginsubsubsection{Rule of Unbounded Rational Precision}
+
+Rational computations cannot overflow in the usual sense 
+(though there may not be enough storage to represent a result), 
+since \term{integers} and \term{ratios} may in principle be of any magnitude.
+            
+\endsubsubsection%{Rule of Unbounded Rational Precision}
+
+\beginsubsubsection{Rule of Canonical Representation for Rationals}
+
+%% 2.1.2 2
+%% 12.1.0 5
+If any computation produces a result that is a mathematical ratio of two integers
+such that the denominator evenly divides the numerator, then the result is converted
+to the equivalent \term{integer}.  
+
+%% 2.1.2 1         
+%% This had been removed, but I couldn't figure out why,
+%% so I reinstated it. -kmp 19-Oct-91
+If the denominator does not evenly divide the numerator,
+the canonical representation of a \term{rational} number is as the \term{ratio}
+that numerator and that denominator, where the greatest common divisor of
+the numerator and denominator is one, and where the denominator is positive
+and greater than one.
+
+When used as input (in the default syntax),
+the notation \f{-0} always denotes the \term{integer} \f{0}.
+A \term{conforming implementation} must not have a
+representation of ``minus zero'' for \term{integers}
+that is distinct from its representation of zero for \term{integers}.
+However, such a distinction is possible for \term{floats}; 
+see \thetype{float}.
+
+\endsubsubsection%{Rule of Canonical Representation for Rationals}
+
+\beginsubsubsection{Rule of Float Substitutability}
+\DefineSection{FloatSubstitutability}
+
+%% 12.5.0 4
+When the arguments to an irrational mathematical \term{function} 
+\reviewer{Barmar: There should be a table of these functions.}
+are all \term{rational} and the true mathematical result
+is also (mathematically) rational, then unless otherwise noted
+an implementation is free to return either an accurate
+\term{rational} result
+or a \term{single float} approximation.
+If the arguments are all \term{rational} 
+but the result cannot be expressed
+as a \term{rational} number, then a \term{single float} 
+approximation is always returned.
+
+\issue{COMPLEX-RATIONAL-RESULT:EXTEND}
+If the arguments to 
+%% Added "irrational" per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+%a
+an irrational
+mathematical \term{function} are all of type
+  \f{(or rational (complex rational))} 
+and the true mathematical result is
+  (mathematically) a complex number with rational real and imaginary
+  parts, then unless otherwise noted an implementation is free to return
+  either an accurate result of type \f{(or rational (complex rational))} 
+or
+  a \term{single float}
+  (permissible only if the imaginary part of the true mathematical
+  result is zero) or \f{(complex single-float)}. If the arguments are
+  all of type \f{(or rational (complex rational))}
+but the result cannot be
+  expressed as a \term{rational} or \term{complex rational},
+then the returned
+  value will be \oftype{single-float} 
+(permissible only if the imaginary
+  part of the true mathematical result is zero) or \f{(complex single-float)}.
+\endissue{COMPLEX-RATIONAL-RESULT:EXTEND}
+ 
+%% Added per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+Float substitutability applies neither to the rational \term{functions} 
+      \funref{+},
+      \funref{-},
+      \funref{*},
+  and \funref{/} 
+nor to the related \term{operators} 
+      \funref{1+},
+      \funref{1-},
+      \macref{incf},
+      \macref{decf},
+  and \funref{conjugate}.
+For rational \term{functions},
+  if all arguments are \term{rational},
+    then the result is \term{rational}; 
+  if all arguments are of type \f{(or rational (complex rational))},
+    then the result is of type \f{(or rational (complex rational))}.
+
+\tablefigtwo{Functions Affected by Rule of Float Substitutability}%
+{Function}{Sample Results}{
+\funref{abs}    & \f{(abs \#c(3 4)) \EV\ 5 \i{or} 5.0} \cr
+\funref{acos}   & \f{(acos 1) \EV\ 0 \i{or} 0.0} \cr
+\funref{acosh}  & \f{(acosh 1) \EV\ 0 \i{or} 0.0} \cr
+\funref{asin}   & \f{(asin 0) \EV\ 0 \i{or} 0.0} \cr
+\funref{asinh}  & \f{(asinh 0) \EV\ 0 \i{or} 0.0} \cr
+\funref{atan}   & \f{(atan 0) \EV\ 0 \i{or} 0.0} \cr
+\funref{atanh}  & \f{(atanh 0) \EV\ 0 \i{or} 0.0} \cr
+%% #c(1 0) => 1 per Boyer/Kaufmann/Moore #14 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+\funref{cis}    & \f{(cis 0) \EV\ 1 \i{or} \#c(1.0 0.0)} \cr
+\funref{cos}    & \f{(cos 0) \EV\ 1 \i{or} 1.0} \cr
+\funref{cosh}   & \f{(cosh 0) \EV\ 1 \i{or} 1.0} \cr
+\funref{exp}    & \f{(exp 0) \EV\ 1 \i{or} 1.0} \cr
+\funref{expt}   & \f{(expt 8 1/3) \EV\ 2 \i{or} 2.0} \cr
+\funref{log}    & \f{(log 1) \EV\ 0 \i{or} 0.0} \cr
+                & \f{(log 8 2) \EV\ 3 \i{or} 3.0} \cr
+\funref{phase}  & \f{(phase 7) \EV\ 0 \i{or} 0.0} \cr
+\funref{signum} & \f{(signum \#c(3 4)) \EV\ \#c(3/5 4/5) \i{or} \#c(0.6 0.8)} \cr
+\funref{sin}    & \f{(sin 0) \EV\ 0 \i{or} 0.0} \cr
+\funref{sinh}   & \f{(sinh 0) \EV\ 0 \i{or} 0.0} \cr
+\funref{sqrt}   & \f{(sqrt 4) \EV\ 2 \i{or} 2.0} \cr
+                & \f{(sqrt 9/16) \EV\ 3/4 \i{or} 0.75} \cr
+\funref{tan}    & \f{(tan 0) \EV\ 0 \i{or} 0.0} \cr
+\funref{tanh}   & \f{(tanh 0) \EV\ 0 \i{or} 0.0} \cr
+}
+
+\endsubsubsection%{Rule of Float Substitutability}
+
+\endsubsection%{Rational Computations}
+\beginsubsection{Floating-point Computations}
+\DefineSection{FloatingPointComputations}
+
+The following rules apply to floating point computations.
+
+\issue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE}
+\beginsubsubsection{Rule of Float and Rational Contagion}
+\DefineSection{RuleOfFloatAndRationalContagion}
+%% Barmar noted that the following was said in two different places.
+%%  I've removed the most casually worded of the two.
+%%  Hopefully no useful info was lost in the process. -kmp 19-Oct-91
+% For \term{functions} that combine arguments of different \term{types},
+% when one argument is a \term{rational} and the other is a \term{float},
+% the \term{rational} is first converted to a \term{float} of the same format.  
+% For \term{functions} that compare arguments of different \term{types},
+% when one argument is a \term{rational} and the other is 
+% a \term{float}, \thefunction{rational} is effectively
+% called to convert the \term{float} to a \term{rational} and then an exact
+% comparison is performed. In the case of \term{complex} numbers, the real and 
+% imaginary parts are effectively handled individually.
+
+%% 12.1.0 3
+When \term{rationals} and \term{floats} are combined by a numerical function, 
+the \term{rational} is first converted to a \term{float} of the same format.
+For \term{functions} such as \funref{+} that take more than two arguments,
+it is permitted that part of the operation be carried out exactly using
+\term{rationals} and the rest be done using floating-point arithmetic.
+
+When \term{rationals} and \term{floats} are compared by a numerical function, 
+\thefunction{rational} is effectively called to convert the \term{float} 
+to a \term{rational} and then an exact
+comparison is performed. In the case of \term{complex} numbers,
+the real and imaginary parts are effectively handled individually.
+
+\beginsubsubsubsection{Examples of Rule of Float and Rational Contagion}
+
+\code
+ ;;;; Combining rationals with floats.
+ ;;; This example assumes an implementation in which 
+ ;;; (float-radix 0.5) is 2 (as in IEEE) or 16 (as in IBM/360),
+ ;;; or else some other implementation in which 1/2 has an exact 
+ ;;;  representation in floating point.
+ (+ 1/2 0.5) \EV 1.0
+ (- 1/2 0.5d0) \EV 0.0d0
+ (+ 0.5 -0.5 1/2) \EV 0.5
+
+ ;;;; Comparing rationals with floats.
+ ;;; This example assumes an implementation in which the default float 
+ ;;; format is IEEE single-float, IEEE double-float, or some other format
+ ;;; in which 5/7 is rounded upwards by FLOAT.
+ (< 5/7 (float 5/7)) \EV \term{true}
+ (< 5/7 (rational (float 5/7))) \EV \term{true}
+ (< (float 5/7) (float 5/7)) \EV \term{false}
+\endcode
+% (< 5/7 (rationalize (float 5/7))) \EV \term{implementation-dependent}
+% Moon: The rationalize example is screwy since the two lines preceding it are also 
+% implementation-dependent.  Also I don't think it sheds any light on
+% the issue at hand (see the name of the subsubsection), so flush it.
+
+\endsubsubsection%{Examples of Rule of Float and Rational Contagion}
+
+\endissue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE}
+
+\endsubsubsection%{Rule of Float and Rational Contagion}
+
+\beginsubsubsection{Rule of Float Approximation}
+%% 12.1.0 1
+%% 12.5.0 3
+Computations with \term{floats} are only approximate,
+although they are described as if the results
+were mathematically accurate. 
+Two mathematically identical
+expressions may be computationally different because of errors
+inherent in the floating-point approximation process.
+The precision of a \term{float} is not necessarily
+correlated with the accuracy of that number.
+For instance, 3.142857142857142857 is a more precise approximation
+to $\pi$ than 3.14159, but the latter is more accurate.
+The precision refers to the number of bits retained in the representation.
+When an operation combines a \term{short float} with a 
+\term{long float},
+the result will be a \term{long float}. 
+\clisp\ functions assume that the accuracy of
+arguments to them does not exceed their precision.  Therefore
+when two \term{small floats} 
+are combined, the result is a \term{small float}. 
+\clisp\ functions 
+never convert automatically from a larger size to a smaller one.
+\endsubsubsection%{Rule of Float Approximation}
+
+\beginsubsubsection{Rule of Float Underflow and Overflow}
+
+%% 12.1.0 2
+An error of \term{type} \typeref{floating-point-overflow}
+or \typeref{floating-point-underflow} should be signaled if a 
+floating-point computation causes exponent overflow or underflow, respectively.
+
+\endsubsubsection%{Rule of Float Underflow and Overflow}
+
+\beginsubsubsection{Rule of Float Precision Contagion} 
+\DefineSection{RuleOfFloatPrecisionContagion}
+
+%% The following was said in two different places.
+%%  I've removed the most casually worded of the two.
+%%  Hopefully no useful info was lost in the process. -kmp 19-Oct-91
+% When a shorter \term{float} is combined with a longer one in an operation,
+% the result will be of the \term{type} of the longer of the two \term{floats}.
+
+%% 12.1.0 5
+The result of a numerical function is a \term{float} of the 
+largest format among all the floating-point arguments to the \term{function}. 
+
+\endsubsubsection%{Rule of Float Precision Contagion} 
+
+\endsubsection%{Floating-point Computations}
+\beginsubsection{Complex Computations}
+\DefineSection{ComplexComputations}
+
+%% 12.1.0 6
+The following rules apply to \term{complex} computations:
+
+\beginsubsubsection{Rule of Complex Substitutability}
+
+%% Rewritten by KMP.
+% Except during the execution of irrational and transcendental \term{functions},
+% \term{complex} numbers never result from a numerical \term{function}
+% unless one or more of the \term{arguments} is \term{complex}.
+Except during the execution of irrational and transcendental \term{functions},
+no numerical \term{function} ever \term{yields} a \term{complex} unless 
+one or more of its \term{arguments} is a \term{complex}.
+
+\endsubsubsection%{Rule of Complex Substitutability}
+
+\beginsubsubsection{Rule of Complex Contagion}
+
+\DefineSection{RuleOfComplexContagion}
+% When a 
+% \issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+% \term{real}
+% \endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+% number 
+% \reviewer{Barmar: I don't like the word `meets' here.}
+% \editornote{KMP: This is all said redundantly in \secref\ComplexComputations\ below,
+% 	         so maybe we can merge the two, somehow.} %!!! 26-Dec-90
+% meets a \term{complex} number, the 
+% \issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+% \term{real}
+% \endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+% number is in effect first converted to a 
+% \term{complex} number by providing an
+% imaginary part of {\tt $0$}.
+When a 
+\issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+\term{real}
+\endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+and 
+a \term{complex} are both part of a computation, 
+the 
+\issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+\term{real}
+\endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+is first converted to a \term{complex} by providing an imaginary part of \f{0}.
+\endsubsubsection%{Rule of Complex Contagion}
+
+\beginsubsubsection{Rule of Canonical Representation for Complex Rationals}
+\DefineSection{RuleOfCanonRepForComplexRationals}
+
+%% 12.1.0 8
+If the result of any computation would be a \term{complex}
+number whose real part is \oftype{rational} and whose imaginary
+part is zero, the result is converted to the \term{rational} 
+which is the real part.
+This rule does not apply to \term{complex} numbers whose parts
+are \term{floats}. 
+For example, \f{\#C(5 0)} and \f{5} are not \term{different} \term{objects} in \clisp
+(they are always the \term{same} under \funref{eql});
+\f{\#C(5.0 0.0)} and \f{5.0} are always \term{different} \term{objects} in \clisp\
+(they are never the \term{same} under \funref{eql},
+although they are the \term{same} under \funref{equalp} and \funref{=}).
+
+\beginsubsubsubsection{Examples of Rule of Canonical Representation for Complex Rationals}
+
+\code
+ #c(1.0 1.0) \EV #C(1.0 1.0)
+ #c(0.0 0.0) \EV #C(0.0 0.0)
+ #c(1.0 1) \EV #C(1.0 1.0)
+ #c(0.0 0) \EV #C(0.0 0.0)
+ #c(1 1) \EV #C(1 1)
+ #c(0 0) \EV 0
+ (typep #c(1 1) '(complex (eql 1))) \EV \term{true}
+ (typep #c(0 0) '(complex (eql 0))) \EV \term{false}
+\endcode
+
+\endsubsubsubsection%{Examples of Rule of Canonical Representation for Complex Rationals}
+
+\endsubsubsection%{Rule of Canonical Representation for Complex Rationals}
+
+\beginsubsubsection{Principal Values and Branch Cuts}
+
+%% 12.5.3 1
+Many of the irrational and transcendental functions are multiply defined
+in the complex domain; for example, there are in general an infinite
+number of complex values for the logarithm function.  In each such
+case, a \term{principal} \term{value} must be chosen for the function to return.
+In general, such values cannot be chosen so as to make the range
+continuous; lines in the domain
+called branch cuts must be defined, which in turn
+define the discontinuities in the range.
+%% 12.5.3 2
+\clisp\ defines the branch cuts, \term{principal} \term{values}, and boundary
+conditions for the complex functions following ``{\PrincipalValues}.'' The branch
+cut rules that apply to each function are located with the description of
+that function.
+
+%% 12.5.3 17
+\Thenextfigure\ lists
+the identities that are obeyed
+throughout the applicable portion of the complex domain, even on
+the branch cuts:
+
+\showthree{Trigonometric Identities for Complex Domain}{
+sin i z = i sinh z  &  sinh i z = i sin z        &  arctan  i z = i arctanh z \cr
+cos i z = cosh z    &  cosh i z = cos z          &  arcsinh i z = i arcsin z  \cr
+tan i z = i tanh z  &  arcsin i z = i arcsinh z  &  arctanh i z = i arctan z  \cr
+}
+
+The quadrant numbers referred to in the discussions of branch cuts are as illustrated
+in \thenextfigure.
+
+% JGA requested this.
+% This is amazingly low-tex and the spacing of dots isn't quite right,
+% but I think it's good enough to be intelligible and will suffice until and
+% unless something better is devised. -kmp 3-Feb-92
+{\def\Qfont#1{{\tt #1}}
+$$\vbox{\halign{\hfil #\hfil\cr
+Positive\cr
+Imaginary Axis\cr
+\noalign{\vskip 5pt}
+\vbox{\halign{#&#&#\cr
+\hfil&\hfil$\vdots$\hfil&\hfil\cr
+\hfil\Qfont{II\quad}&$\vdots$&\Qfont{\quad I}\hfil\cr
+\hfil Negative Real Axis\quad$\cdots\cdots\cdots$& &$\cdots\cdots\cdots$\quad Positive Real Axis\hfil\cr
+\hfil\Qfont{III\quad}&$\vdots$&\Qfont{\quad IV}\hfil\cr
+\hfil&\hfil$\vdots$\hfil&\hfil\cr
+}}\cr
+\noalign{\vskip 5pt}
+Negative\cr
+Imaginary Axis\cr}}$$
+}
+\simplecaption{Quadrant Numbering for Branch Cuts}
+
+\endsubsubsection%{Principal Values and Branch Cuts}
+
+\endsubsection%{Complex Computations}
+
+\beginsubsection{Interval Designators}
+\DefineSection{IntervalDesignators}
+
+The \term{compound type specifier} form of the numeric \term{type specifiers}
+%% Removed per Boyer/Kaufmann/Moore #15 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+%in \thenextfigure\ 
+permit the user to specify an interval on the real number line
+which describe a \term{subtype} of the \term{type} which would be described by the
+corresponding \term{atomic type specifier}.  A \term{subtype} of some \term{type}
+\param{T} is specified using an ordered pair of \term{objects} called
+\term{interval designators} for \term{type} \param{T}.
+
+The first of the two \term{interval designators} for \term{type} \param{T} can be
+any of the following:
+
+\beginlist
+
+\itemitem{a number \param{N} of \term{type} \param{T}}
+
+This denotes a lower inclusive bound of \param{N}.  That is, \term{elements}
+of the \term{subtype} of \param{T} will be greater than or equal to \param{N}.
+
+\itemitem{a \term{singleton} \term{list} whose \term{element} is
+	  a number \param{M} of \term{type} \param{T}}
+
+This denotes a lower exclusive bound of \param{M}.  That is, \term{elements}
+of the \term{subtype} of \param{T} will be greater than \param{M}.
+
+\itemitem{the symbol \misc{*}}
+
+This denotes the absence of a lower bound on the interval.
+
+\endlist
+
+The second of the two \term{interval designators} for \term{type} \param{T} can be
+any of the following:
+
+\beginlist
+
+\itemitem{a number \param{N} of \term{type} \param{T}}
+
+This denotes an upper inclusive bound of \param{N}.  That is, \term{elements}
+of the \term{subtype} of \param{T} will be less than or equal to \param{N}.
+
+\itemitem{a \term{singleton} \term{list} whose \term{element} is
+	  a number \param{M} of \term{type} \param{T}}
+
+This denotes an upper exclusive bound of \param{M}.  That is, \term{elements}
+of the \term{subtype} of \param{T} will be less than \param{M}.
+
+\itemitem{the symbol \misc{*}}
+
+This denotes the absence of an upper bound on the interval.
+
+\endlist
+
+\endsubsection%{Interval Designators}
+
+\beginsubsection{Random-State Operations}
+
+\Thenextfigure\ lists some \term{defined names} that are applicable to \term{random states}.
+
+\displaythree{Random-state defined names}{
+*random-state*&random&\cr
+make-random-state&random-state-p&\cr
+}
+
+\endsubsection%{Random-State Operations}

concept-objects.tex

@@ -0,0 +1,636 @@
+% -*- Mode: TeX -*-
+
+%%2.5 objects
+                      
+The \term{generic function} \funref{make-instance} creates and returns a new
+\term{instance} of a \term{class}.  The first argument is a \term{class} or
+the \term{name} of a \term{class}, and the remaining arguments form an 
+\newterm{initialization argument list}.
+
+The initialization of a new \term{instance} consists of several distinct
+steps, including the following: combining the explicitly supplied initialization
+arguments with default values for the unsupplied initialization arguments, 
+checking the validity of the initialization arguments, allocating storage 
+for the \term{instance}, filling \term{slots} with
+values, and executing user-supplied \term{methods} that perform additional
+initialization.  Each step of \funref{make-instance} is implemented by a
+\term{generic function} to provide a mechanism for customizing that step.  
+In addition, \funref{make-instance} is itself a \term{generic function} 
+and thus also can be customized.
+
+The \OS\ specifies system-supplied primary \term{methods} for each step 
+and thus specifies a well-defined standard behavior for the entire
+initialization process.  The standard behavior provides four simple
+mechanisms for controlling initialization:
+
+\beginlist
+
+\itemitem{\bull} Declaring a \term{symbol} to be an initialization argument 
+for a \term{slot}.  An initialization argument is declared by using the
+\kwd{initarg} slot option to \macref{defclass}.  This provides a mechanism
+for supplying a value for a \term{slot} in a call to \funref{make-instance}.
+
+\itemitem{\bull} Supplying a default value form for an initialization argument.
+Default value forms for initialization arguments are defined by using the
+\kwd{default-initargs} class option to \macref{defclass}.  If an 
+initialization argument is not explicitly provided
+as an argument to \funref{make-instance}, the default value form is
+evaluated in the lexical environment of the \macref{defclass} form that
+defined it, and the resulting value is used as the value of the
+initialization argument.
+
+\itemitem{\bull} Supplying a default initial value form for a \term{slot}.  
+A default initial value form for a \term{slot} is defined by using the 
+\kwd{initform} slot option to \macref{defclass}.  If no initialization
+argument associated with that \term{slot} is given as an argument to 
+\funref{make-instance} or is defaulted by \kwd{default-initargs}, this
+default initial value form is evaluated in the lexical environment of
+the \macref{defclass} form that defined it, and the resulting value is
+stored in the \term{slot}.  The \kwd{initform} form for a
+\term{local slot} may be used when creating an \term{instance}, when 
+updating an \term{instance} to conform to a redefined \term{class}, 
+or when updating an \term{instance} to conform to the definition of a
+different \term{class}. The \kwd{initform} form for a
+\term{shared slot} may be used when defining or re-defining the \term{class}.
+                                                                       
+\itemitem{\bull} 
+Defining \term{methods} for \funref{initialize-instance} and
+\funref{shared-initialize}.  The slot-filling behavior described above is
+implemented by a system-supplied primary \term{method} for
+\funref{initialize-instance} which invokes \funref{shared-initialize}. The
+\term{generic function} \funref{shared-initialize} implements the parts of
+initialization shared by these four situations: when making an \term{instance}, 
+when re-initializing an \term{instance}, when updating an \term{instance}
+to conform to a redefined \term{class}, and when updating an \term{instance} 
+to conform to the definition of a different \term{class}. The system-supplied
+primary \term{method} for \funref{shared-initialize} directly implements the
+slot-filling behavior described above, and \funref{initialize-instance}
+simply invokes \funref{shared-initialize}.
+
+\endlist
+
+\beginsubsection{Initialization Arguments}
+
+An initialization argument controls \term{object} creation and
+initialization.  It is often convenient to use keyword \term{symbols}
+to name initialization arguments, but the \term{name} of an
+initialization argument can be any \term{symbol}, including \nil.  An
+initialization argument can be used in two ways: to fill a \term{slot}
+with a value or to provide an argument for an initialization
+\term{method}.  A single initialization argument can be used for both
+purposes.
+
+\issue{PLIST-DUPLICATES:ALLOW}
+An \term{initialization argument list} is a
+%list of alternating of
+\term{property list} of
+initialization argument names and values.
+Its structure is identical
+to a \term{property list} and also 
+to the portion of an argument list
+processed for \keyref{key} parameters.
+As in those lists,
+if an initialization
+argument name appears more than once in an initialization argument list,
+the leftmost occurrence supplies the value and the remaining occurrences
+are ignored.  The arguments to \funref{make-instance} (after the first
+argument) form an \term{initialization argument list}.
+\issue{INITIALIZATION-FUNCTION-KEYWORD-CHECKING}
+% Error-checking
+% of initialization argument names is disabled if the keyword argument
+% pair whose keyword is \kwd{allow-other-keys} and whose value is
+% \term{non-nil} appears in the \term{initialization argument list}.
+\endissue{INITIALIZATION-FUNCTION-KEYWORD-CHECKING}
+\endissue{PLIST-DUPLICATES:ALLOW}
+
+An initialization argument can be associated with a \term{slot}.  If
+the initialization argument has a value in the \term{initialization
+argument list}, the value is stored into the \term{slot} of the newly
+created \term{object}, overriding any \kwd{initform} form associated
+with the \term{slot}.  A single initialization argument can initialize
+more than one \term{slot}.  An initialization argument that initializes
+a \term{shared slot} stores its value into the \term{shared slot},
+replacing any previous value.
+
+An initialization argument can be associated with a \term{method}.  When
+an \term{object} is created and a particular initialization argument is
+supplied, the \term{generic functions} \funref{initialize-instance},
+\funref{shared-initialize}, and \funref{allocate-instance} are called
+with that initialization argument's name and value as a keyword argument
+pair.  If a value for the initialization argument is not supplied in the
+\term{initialization argument list}, the \term{method}'s 
+\term{lambda list} supplies a default value.
+
+Initialization arguments are used in four situations: when making an
+\term{instance}, when re-initializing an \term{instance}, when updating
+an \term{instance} to conform to a redefined \term{class}, and when
+updating an \term{instance} to conform to the definition of a different
+\term{class}.
+
+Because initialization arguments are used to control the creation and
+initialization of an \term{instance} of some particular \term{class},
+we say that an initialization argument is
+``an initialization argument for'' that \term{class}.
+
+\endsubsection%{Initialization Arguments}
+
+\beginsubsection{Declaring the Validity of Initialization Arguments}
+\DefineSection{DeclaringInitargValidity}
+
+Initialization arguments are checked for validity in each of the four
+situations that use them.  An initialization argument may be valid in
+one situation and not another. For example, the system-supplied     
+primary \term{method} for \funref{make-instance} defined for 
+\theclass{standard-class} checks the validity of its initialization arguments
+and signals an error if an initialization argument is supplied that is
+not declared as valid in that situation.
+
+
+There are two means for declaring initialization arguments valid.
+
+\beginlist
+
+\itemitem{\bull}
+Initialization arguments that fill \term{slots} are declared as valid
+by the \kwd{initarg} slot option to \macref{defclass}.  The
+\kwd{initarg} slot option is inherited from \term{superclasses}.  Thus
+the set of valid initialization arguments that fill \term{slots} for a
+\term{class} is the union of the initialization arguments that fill
+\term{slots} declared as valid by that \term{class} and its
+\term{superclasses}.  Initialization arguments that fill \term{slots}
+are valid in all four contexts.
+
+\itemitem{\bull}
+Initialization arguments that supply arguments to \term{methods} are
+declared as valid by defining those \term{methods}.  The keyword name of
+each keyword parameter specified in the \term{method}'s 
+\term{lambda list} becomes an initialization argument for all \term{classes} 
+for which the \term{method} is applicable.
+\issue{INITIALIZATION-FUNCTION-KEYWORD-CHECKING}
+The presence of {\allowotherkeys} in the
+\term{lambda list} of an applicable method disables validity checking of 
+initialization arguments.
+\endissue{INITIALIZATION-FUNCTION-KEYWORD-CHECKING}
+Thus \term{method} inheritance
+controls the set of valid initialization arguments that supply arguments
+to \term{methods}.  The \term{generic functions} for which \term{method}
+definitions serve to declare initialization arguments valid are as
+follows:
+\beginlist                                              
+\itemitem{--}
+Making an \term{instance} of a \term{class}:
+\funref{allocate-instance}, \funref{initialize-instance}, and
+\funref{shared-initialize}.  Initialization arguments declared as valid
+by these \term{methods} are valid when making 
+an \term{instance} of a \term{class}.
+
+\itemitem{--} Re-initializing an \term{instance}:
+\funref{reinitialize-instance} and \funref{shared-initialize}.
+Initialization arguments declared as valid by these \term{methods} are
+valid when re-initializing an \term{instance}.
+
+\itemitem{--}  Updating an \term{instance} to conform to a redefined \term{class}:
+\funref{update-instance-for-redefined-class} and \funref{shared-initialize}.
+Initialization arguments declared as valid by these \term{methods} are
+valid when updating an \term{instance} to conform to a redefined \term{class}.
+
+\itemitem{--} Updating an \term{instance} to conform to the definition of a
+different \term{class}:
+\funref{update-instance-for-different-class} and \funref{shared-initialize}.
+Initialization arguments declared as valid by these \term{methods} are
+valid when updating an \term{instance} to conform to the definition
+of a different \term{class}.
+
+\endlist
+\endlist
+
+The set of valid initialization arguments for a \term{class} is the set of
+valid initialization arguments that either fill \term{slots} or supply
+arguments to \term{methods}, along with the predefined initialization
+argument \kwd{allow-other-keys}.  The default value for 
+\kwd{allow-other-keys} is \nil.
+\issue{INITIALIZATION-FUNCTION-KEYWORD-CHECKING}
+% The meaning of 
+% \kwd{allow-other-keys} is the same as when it is passed to an ordinary
+% \term{function}.
+Validity checking of initialization arguments is disabled if the value of
+the initialization argument \kwd{allow-other-keys} is \term{true}.
+\endissue{INITIALIZATION-FUNCTION-KEYWORD-CHECKING}
+
+\endsubsection%{Declaring the Validity of Initialization Arguments}
+
+\beginsubsection{Defaulting of Initialization Arguments}
+
+A default value \term{form} can be supplied for an initialization
+argument by using the \kwd{default-initargs} \term{class} option.  If an
+initialization argument is declared valid by some particular \term{class},
+its default  value form might be specified by a different \term{class}. 
+In this case \kwd{default-initargs} is used to supply a default value
+for an inherited initialization argument.
+
+The \kwd{default-initargs} option is used only to provide default
+values for initialization arguments; it does not declare a \term{symbol} 
+as a valid initialization argument name.  Furthermore, 
+the \kwd{default-initargs} option is used only to provide default values for
+initialization arguments when making an \term{instance}.
+                     
+The argument to the \kwd{default-initargs} class 
+option is a list of
+alternating initialization argument names and \term{forms}.  
+Each \term{form} is the
+default  value form for the corresponding initialization
+argument.  The default  value \term{form} of an initialization
+argument is used and evaluated only if that initialization argument
+does not appear in the arguments to \funref{make-instance} and is not
+defaulted by a more specific \term{class}.  The default  value \term{form} is
+evaluated in the lexical environment of the \macref{defclass} form that
+supplied it; the resulting value is used as the initialization
+argument's value.
+                                          
+The initialization arguments supplied to \funref{make-instance} are combined
+with defaulted initialization arguments to produce a 
+\term{defaulted initialization argument list}. A 
+\term{defaulted initialization argument list}
+is a list of alternating initialization argument names and
+values in which unsupplied initialization arguments are defaulted and in
+which the explicitly supplied initialization arguments appear earlier in
+the list than the defaulted initialization arguments.  Defaulted
+initialization arguments are ordered according to the order in the 
+\term{class precedence list} of the \term{classes} that supplied the default values.
+                                                    
+There is a distinction between the purposes of the 
+\kwd{default-initargs} and the \kwd{initform} options with respect to the
+initialization of \term{slots}.  The \kwd{default-initargs} 
+class option
+provides a mechanism for the user to give a default  value \term{form}
+for an initialization argument without knowing whether the
+initialization argument initializes a \term{slot} 
+or is passed to a \term{method}.
+If that initialization argument is not explicitly supplied in a call
+to \funref{make-instance}, the default  value \term{form} is used, just
+as if it had been supplied in the call.  In contrast, the 
+\kwd{initform} slot option provides a mechanism for the user to give a
+default initial value form for a \term{slot}.  An \kwd{initform} form is
+used to initialize a \term{slot} only if no initialization argument
+associated with that \term{slot} is given as an argument to 
+\funref{make-instance} or is defaulted by \kwd{default-initargs}.
+
+\idxtext{order of evaluation}\idxtext{evaluation order}
+The order of evaluation of default value \term{forms} for initialization
+arguments and the order of evaluation of \kwd{initform} forms are
+undefined.  If the order of evaluation is important, 
+\funref{initialize-instance} or \funref{shared-initialize} \term{methods} 
+should be used
+instead.
+
+\endsubsection%{Defaulting of Initialization Arguments}
+
+\beginsubsection{Rules for Initialization Arguments}
+\DefineSection{InitargRules}
+     
+The \kwd{initarg} slot option may be specified more than
+once for a given \term{slot}.
+
+The following rules specify when initialization arguments may be
+multiply defined:
+
+\beginlist
+
+\itemitem{\bull} A given initialization argument can be used to
+initialize more than one \term{slot} if the same initialization argument name
+appears in more than one \kwd{initarg} slot option.
+
+\itemitem{\bull} A given initialization argument name can appear 
+in the \term{lambda list} of more than one initialization \term{method}.
+
+\itemitem{\bull} A given initialization argument name can
+appear both in an \kwd{initarg} slot option and 
+in the \term{lambda list}
+of an initialization \term{method}.
+
+\endlist
+
+\reviewer{The next three paragraphs could be replaced by ``If two or more
+initialization arguments that initialize the same slot appear in the
+\term{defaulted initialization argument list}, the leftmost of these supplies
+the value, even if they have different names.''  And the rest would follow
+from the rules above.}
+
+If two or more initialization arguments that initialize the same
+\term{slot} are given in the arguments to \funref{make-instance}, the
+leftmost of these initialization arguments in the \term{initialization
+argument list} supplies the value, even if the initialization arguments
+have different names.
+
+If two or more different initialization arguments that initialize the
+same \term{slot} have default values and none is given explicitly in the
+arguments to \funref{make-instance}, the initialization argument that
+appears in a \kwd{default-initargs} class option in the most specific
+of the \term{classes} supplies the value. If a single
+\kwd{default-initargs} class option specifies two or more initialization
+arguments that initialize the same \term{slot} and none is given
+explicitly in the arguments to \funref{make-instance}, the leftmost in
+the \kwd{default-initargs} class option supplies the value, and the
+values of the remaining default value \term{forms} are ignored.
+
+Initialization arguments given explicitly in the arguments to
+\funref{make-instance} appear to the left of defaulted initialization
+arguments. Suppose that the classes $C\sub 1$ and $C\sub 2$ supply the
+values of defaulted initialization arguments for different \term{slots},
+and suppose that $C\sub 1$ is more specific than $C\sub 2$; then the
+defaulted initialization argument whose value is supplied by $C\sub 1$
+is to the left of the defaulted initialization argument whose value is
+supplied by $C\sub 2$ in the \term{defaulted initialization argument
+list}.  If a single \kwd{default-initargs} class option supplies the
+values of initialization arguments for two different \term{slots}, the
+initialization argument whose value is specified farther to the left in
+the \kwd{default-initargs} class option appears farther to the left in
+the \term{defaulted initialization argument list}.
+
+\reviewer{Barmar: End of claim made three paragraphs back.}
+                                                        
+If a \term{slot} has both an \kwd{initform} form and an 
+\kwd{initarg} slot option, and the initialization argument is defaulted
+using \kwd{default-initargs} or is supplied to \funref{make-instance},
+the captured \kwd{initform} form is neither used nor evaluated.
+
+The following is an example of the above rules:
+
+\code
+ (defclass q () ((x :initarg a)))
+ (defclass r (q) ((x :initarg b))
+   (:default-initargs a 1 b 2))
+\endcode
+
+$$\vbox{\halign{\strut#\hfil&\quad\hfil#\hfil&\quad\hfil#\hfil\cr
+{}&\bf Defaulted&{}\cr
+\bf Form&\bf Initialization Argument List&\bf Contents of Slot X\cr
+\noalign{\hrule}
+{\tt (make-instance 'r)}&{\tt (a 1 b 2)}&{\tt 1}\cr
+{\tt (make-instance 'r 'a 3)}&{\tt (a 3 b 2)}&{\tt 3}\cr
+{\tt (make-instance 'r 'b 4)}&{\tt (b 4 a 1)}&{\tt 4}\cr
+{\tt (make-instance 'r 'a 1 'a 2)}&{\tt (a 1 a 2 b 2)}&{\tt 1}\cr}}$$
+
+\endsubsection%{Rules for Initialization arguments}
+
+\beginsubsection{Shared-Initialize}
+\DefineSection{SharedInitialize}
+                      
+The \term{generic function} \funref{shared-initialize} is used to fill the 
+\term{slots}
+of an \term{instance} 
+using initialization arguments and \kwd{initform}
+forms when an \term{instance} is created, when an 
+\term{instance} is re-initialized,
+when an \term{instance} 
+is updated to conform to a redefined \term{class}, and when
+an \term{instance} is updated to conform to a different \term{class}.
+It uses
+standard \term{method} combination. It takes the following arguments: the
+\term{instance} to be initialized, a 
+specification of a set of \term{names} of \term{slots}
+\term{accessible} in that \term{instance}, and any number of initialization
+arguments.  The arguments after the first two must form an
+\term{initialization argument list}.
+                        
+The second argument to \funref{shared-initialize} may be one of the following:
+
+\beginlist
+
+\itemitem{\bull} It can be a (possibly empty) \term{list} of \term{slot} names,
+which specifies the set of those \term{slot} names. 
+
+% \reviewer{Barmar: This next bullet item is redundant with the previous, 
+% since NIL -is- a LIST.  If there was some confusion, we could say ``(possibly empty)''
+% in the previous item.}
+% 
+% \itemitem{\bull} It can be \nil, which specifies the empty set of
+% \term{slot} names.
+
+\itemitem{\bull} It can be the symbol \t, which specifies the set of all of the \term{slots}.
+
+\endlist
+                                               
+There is a system-supplied primary \term{method} for \funref{shared-initialize}
+whose first \term{parameter specializer} is \theclass{standard-object}.
+This \term{method} behaves as follows on each \term{slot}, 
+whether shared or local:
+
+\beginlist
+
+\itemitem{\bull} If an initialization argument in the 
+\term{initialization argument list} specifies a value for that \term{slot}, 
+that value is stored
+into the \term{slot}, even if a value has already been stored in the \term{slot}
+before the \term{method} is run.  
+The affected \term{slots} are independent of which
+\term{slots} are indicated by the second argument to \funref{shared-initialize}.
+
+\itemitem{\bull} Any \term{slots} 
+indicated by the second argument that are still
+unbound at this point are initialized according to their 
+\kwd{initform} forms.  For any such \term{slot} 
+that has an \kwd{initform} form,
+that \term{form} is evaluated in the 
+lexical environment of its defining 
+\macref{defclass} form and the result is stored into the \term{slot}.  
+For example,
+if a \term{before method} stores a value in the 
+\term{slot}, the \kwd{initform} form will not be used to supply a value 
+for the \term{slot}.  If
+the second argument specifies a \term{name} that does not correspond to any
+\term{slots} \term{accessible} 
+in the \term{instance}, the results are unspecified.
+
+\itemitem{\bull} The rules mentioned in {\secref\InitargRules} are obeyed.
+
+\endlist
+                      
+The generic function \funref{shared-initialize} is called by the
+system-supplied primary \term{methods} 
+for \funref{reinitialize-instance},
+\funref{update-instance-for-different-class}, 
+\funref{update-instance-for-redefined-class}, and 
+\funref{initialize-instance}.  Thus, \term{methods} can be written for 
+\funref{shared-initialize} to specify actions that should be taken in all of
+these contexts.
+
+\endsubsection%{Shared-Initialize}
+
+\beginsubsection{Initialize-Instance}
+                      
+The \term{generic function} \funref{initialize-instance} is called by 
+\funref{make-instance} to initialize a newly created \term{instance}.
+It uses \term{standard method combination}.  \term{Methods} for 
+\funref{initialize-instance} can be defined in order to perform any
+initialization that cannot be achieved 
+%%This was the only case of a half-glossary-term in the entire spec. -kmp 1-Jan-91
+%with the simple \term{slot}-filling mechanisms.
+simply by supplying initial values for \term{slots}.
+
+                        
+During initialization, \funref{initialize-instance} is invoked
+after the following actions have been taken:
+
+\beginlist 
+
+\itemitem{\bull} The \term{defaulted initialization argument list} 
+has been computed by combining the supplied \term{initialization argument list} 
+with any default initialization arguments for the \term{class}.
+
+\itemitem{\bull} The validity of the \term{defaulted initialization argument list}
+has been checked.  If any of the initialization arguments has not
+been declared as valid, an error is signaled. 
+
+\itemitem{\bull} A new \term{instance} whose \term{slots} 
+are unbound has been created.
+
+\endlist
+                      
+The generic function \funref{initialize-instance} is called with the
+new \term{instance} and the defaulted initialization arguments.  There is
+a system-supplied primary \term{method} for \funref{initialize-instance}
+whose \term{parameter specializer} is \theclass{standard-object}.  This
+\term{method} calls the generic function 
+\funref{shared-initialize} to fill in
+the \term{slots} according to the initialization arguments and the 
+\kwd{initform} forms for the \term{slots}; the generic function 
+\funref{shared-initialize} is called with the following arguments: the \term{instance},
+\t, and the defaulted initialization arguments.
+           
+Note that \funref{initialize-instance} provides the 
+\term{defaulted initialization argument list} in its call to \funref{shared-initialize},
+so the first step performed by the system-supplied primary \term{method} for
+\funref{shared-initialize} takes into account both the initialization
+arguments provided in the call to \funref{make-instance} and the
+\term{defaulted initialization argument list}.
+
+\term{Methods} for \funref{initialize-instance} can be defined to specify
+actions to be taken when an \term{instance} is initialized.  
+If only \term{after methods} for \funref{initialize-instance} are defined, they will be
+run after the system-supplied primary \term{method} for initialization and
+therefore will not interfere with the default behavior of 
+\funref{initialize-instance}.
+
+The \OS\ provides two \term{functions} that are useful in the bodies of 
+\funref{initialize-instance} methods.  \Thefunction{slot-boundp}
+returns a \term{generic boolean} value that indicates whether a specified \term{slot} has a
+value; this provides a mechanism for writing \term{after methods} for
+\funref{initialize-instance} that initialize \term{slots} only if they have
+not already been initialized.  \Thefunction{slot-makunbound}
+causes the \term{slot} to have no value.
+
+\endsubsection%{INITIALIZE-INSTANCE}
+
+\beginsubsection{Definitions of Make-Instance and Initialize-Instance}
+                      
+The generic function \funref{make-instance} behaves as if it were defined as
+follows, except that certain optimizations are permitted:
+
+\code
+ (defmethod make-instance ((class standard-class) &rest initargs)
+   ...
+   (let ((instance (apply #'allocate-instance class initargs)))
+     (apply #'initialize-instance instance initargs)
+     instance))
+
+ (defmethod make-instance ((class-name symbol) &rest initargs)
+   (apply #'make-instance (find-class class-name) initargs))
+\endcode
+
+%This is the code:
+%(defmethod make-instance ((class standard-class) &rest initargs)
+%  (setq initargs (default-initargs class initargs))
+%  (let* ((proto (class-prototype class))
+%         (methods 
+%           (append
+%	      (compute-applicable-methods #'allocate-instance `(,class))
+%	      (compute-applicable-methods #'initialize-instance `(,proto))
+%	      (compute-applicable-methods #'shared-initialize `(,proto nil)))))
+%	 (unless
+%	   (subsetp
+%	     (let ((keys '()))
+%	       (do ((plist initargs (cddr plist)))
+%		   ((null plist) keys)
+%	 	 (push (car plist) keys)))
+%	     (union 
+%	       (class-slot-initargs class)
+%	       (reduce #'union (mapcar #'function-keywords methods))))
+%	   (error ...)))
+%  (let ((instance (apply #'allocate-instance class initargs)))
+%    (apply #'initialize-instance instance initargs)
+%    instance))
+                                      
+The elided code in the definition of \funref{make-instance} 
+%% Per X3J13. -kmp 05-Oct-93 
+augments the \f{initargs} with any \term{defaulted initialization arguments} and
+checks the
+%% Per X3J13. -kmp 05-Oct-93 
+%supplied
+resulting
+initialization arguments to determine whether an initialization
+argument was supplied that neither filled a \term{slot} nor supplied an argument
+to an applicable \term{method}. 
+%This check could be implemented using the generic functions
+% ???\funref{class-prototype},??? \funref{compute-applicable-methods},
+%\funref{function-keywords}, and ???\funref{class-slot-initargs}. ???
+%See Chapter~3 for a
+%description of this initialization argument check.
+                      
+The generic function \funref{initialize-instance} behaves as if it were
+defined as follows, except that certain optimizations are permitted:
+
+\code
+ (defmethod initialize-instance ((instance standard-object) &rest initargs)
+   (apply #'shared-initialize instance t initargs)))
+\endcode
+
+% Barmar complains that "Programmer Interface level" is not defined.
+%    Presumably it means "this specification".
+%    Ditto "the meta-object level" is not defined.
+%    Presumably it should just be omitted as beyond the scope of this standard,
+%    or else we should define the term somewhere (e.g., the glossary).
+% I decided to just trim it down to where glossary words weren't needed. -kmp 6-Jan-91
+These procedures can be customized.
+% at either the Programmer Interface level,
+% the meta-object level, or both.  
+                                                                  
+Customizing at the Programmer Interface level includes using the 
+\kwd{initform}, \kwd{initarg}, and \kwd{default-initargs} options to
+\macref{defclass}, as well as defining \term{methods}
+for \funref{make-instance}, 
+%% Per X3J13. -kmp 05-Oct-93
+\funref{allocate-instance},
+and \funref{initialize-instance}.  It is also possible to define
+\term{methods} for \funref{shared-initialize}, which would be invoked by the
+generic functions \funref{reinitialize-instance}, 
+\funref{update-instance-for-redefined-class}, 
+\funref{update-instance-for-different-class}, and 
+\funref{initialize-instance}.  
+The meta-object level supports additional
+customization.
+%by allowing methods to be defined on \funref{make-instance},                       
+%???\b{default-initargs}???, and \funref{allocate-instance}.  
+%Chapters~2 and~3 document each of these generic
+%functions and the system-supplied primary methods.
+                                                                
+Implementations are permitted to make certain optimizations to 
+\funref{initialize-instance} and \funref{shared-initialize}.  
+The description of \funref{shared-initialize} in Chapter~7 mentions the
+possible optimizations.
+
+%Because of optimization, the check for valid initialization arguments
+%might not be implemented using the generic functions 
+%???\funref{class-prototype},??? 
+%\funref{compute-applicable-methods}, \funref{function-keywords}, and 
+%???\funref{class-slot-initargs}???. In addition,
+%methods for the generic function 
+%???\funref{default-initargs},??? and the
+%system-supplied primary methods for 
+%???\funref{allocate-instance}???, 
+%\funref{initialize-instance}, and \funref{shared-initialize} might not be called on
+%every call to \funref{make-instance} or might not receive exactly the
+%arguments that would be expected.
+
+\endsubsection%{Definitions of MAKE-INSTANCE and Initialize-Instance}
+

concept-organization.tex

@@ -0,0 +1,48 @@
+%-*- Mode: TeX -*-
+%%%Organization of the Document
+
+This is a reference document, not a tutorial document.  Where possible
+and convenient, the order of presentation has been chosen so that the
+more primitive topics precede those that build upon them;  however,
+linear readability has not been a priority.
+
+This document is divided into chapters by topic.
+Any given chapter might contain conceptual material, dictionary entries, or both.
+
+\term{Defined names} within the dictionary portion of a chapter are
+grouped in a way that brings related topics into physical proximity.
+Many such groupings were possible,
+and no deep significance should be inferred from the particular grouping that was chosen.
+To see \term{defined names} grouped alphabetically, consult the index.
+For a complete list of \term{defined names}, \seesection\CLsymbols.
+
+In order to compensate for the sometimes-unordered portions of this document, 
+a glossary has been provided; \seechapter\Glossary.
+The glossary provides connectivity by providing easy access to 
+definitions of terms, and in some cases by providing examples or 
+cross references to additional conceptual material.
+
+For information about notational conventions used in this document,
+\seesection\Definitions.
+
+For information about conformance, \seesection\Conformance. 
+
+For information about extensions and subsets, \seesection\LanguageExtensions\
+and \secref\LanguageSubsets.
+
+For information about how \term{programs} in the language are parsed by the
+\term{Lisp reader}, \seechapter\Syntax.
+
+For information about how \term{programs} in the language are \term{compiled}
+and \term{executed}, \seechapter\EvaluationAndCompilation.
+
+For information about data types, \seechapter\TypesAndClasses.
+Not all \term{types} and \term{classes} are defined in this chapter;
+many are defined in chapter corresponding to their topic--for example,
+the numeric types are defined in \chapref\Numbers.
+For a complete list of \term{standardized} \term{types}, 
+\seefigure\StandardizedAtomicTypeSpecs.
+
+For information about general purpose control and data flow,
+\seechapter\DataAndControlFlow\ or \chapref\Iteration.
+

concept-packages.tex

@@ -0,0 +1,656 @@
+% -*- Mode: TeX -*-
+
+%!!! Barmar: Tell me why multiple packags are needed. 
+%    e.g., to prevent variable and function conflicts.
+
+\beginsubSection{Introduction to Packages}
+
+%% 10.0.0 7
+%% 11.0.0 4
+A \newterm{package} establishes a mapping from names to \term{symbols}. 
+At any given time, one \term{package} is current.
+The \newterm{current package} is the one that is \thevalueof{*package*}.
+When using the \term{Lisp reader},
+it is possible to refer to \term{symbols} in \term{packages} 
+other than the current one through the use of \term{package prefixes} in the 
+printed representation of the \term{symbol}.
+
+%% 11.2.0 5
+\Thenextfigure\ lists some \term{defined names} that are applicable
+to \term{packages}.
+%Shouldn't be needed.  This info is all explicit now. -kmp 29-Apr-91
+% For the \term{operators} listed here, all optional arguments named 
+% \param{package} default to the \term{current package}.
+Where an \term{operator} 
+takes an argument that is either a \term{symbol} or a \term{list} 
+of \term{symbols},
+an argument of \nil\ is treated as an empty \term{list} of \term{symbols}.
+Any \param{package} argument may be either a \term{string}, a \term{symbol}, or
+a \term{package}.  If a \term{symbol} is supplied, its name will be used
+as the \term{package} name.
+\issue{REQUIRE-PATHNAME-DEFAULTS:ELIMINATE}
+% \funref{provide}, \funref{require}, and \varref{*modules*} will
+% be removed from this table (and the language).
+%PROVIDE and REQUIRE need to be removed, right? -kmp 29-Apr-91
+%Nope! -kmp 13-Feb-92
+\displaythree{Some Defined Names related to Packages}{
+*modules*&import&provide\cr
+*package*&in-package&rename-package\cr
+defpackage&intern&require\cr
+do-all-symbols&list-all-packages&shadow\cr
+do-external-symbols&make-package&shadowing-import\cr
+do-symbols&package-name&unexport\cr
+export&package-nicknames&unintern\cr
+find-all-symbols&package-shadowing-symbols&unuse-package\cr
+find-package&package-use-list&use-package\cr
+find-symbol&package-used-by-list&\cr
+}
+\endissue{REQUIRE-PATHNAME-DEFAULTS:ELIMINATE}
+
+\beginsubsubsection{Package Names and Nicknames}
+
+%% 11.0.0 19
+Each \term{package} has a \term{name} (a \term{string}) and perhaps some \term{nicknames}
+(also \term{strings}).
+These are assigned when the \term{package} is created and can be changed later.  
+
+%% 11.0.0 20
+There is a single namespace for \term{packages}.  
+\Thefunction{find-package} translates a package
+\term{name} or \term{nickname} into the associated \term{package}.  
+\Thefunction{package-name} returns the \term{name} of a \term{package}.  
+\Thefunction{package-nicknames} returns 
+a \term{list} of all \term{nicknames} for a \term{package}.
+\funref{rename-package} removes a \term{package}'s
+current \term{name} and \term{nicknames} and replaces them with new ones
+specified by the caller.
+
+\endsubsubsection%{Package Names and Nicknames}
+
+\beginsubsubsection{Symbols in a Package}
+
+\beginsubsubsubsection{Internal and External Symbols}
+
+%% 11.0.0 5
+The mappings in a \term{package} are divided into two classes, external and internal.
+The \term{symbols} targeted by these different mappings 
+are called \term{external symbols} and \term{internal symbols}\idxterm{internal symbol} of the
+\term{package}. Within a \term{package}, a name refers to one
+\term{symbol} or to none; if it does refer
+to a \term{symbol}, then it is either external or internal in that
+\term{package}, but not both.
+%% 11.0.0 6
+\newtermidx{External symbols}{external symbol}
+are part of the package's public interface to other \term{packages}.
+\term{Symbols} become \term{external symbols} of a given
+\term{package} if they have been \term{exported} from that \term{package}.
+
+%% 11.0.0 7                                 
+A \term{symbol} has the same \term{name} no matter what \term{package} 
+it is \term{present} in, but it might be an \term{external symbol} of some \term{packages}
+and an \term{internal symbol} of others. 
+
+\endsubsubsubsection%{Internal and External Symbols}
+
+\beginsubsubsubsection{Package Inheritance}
+
+%% 11.0.0 9
+\term{Packages} can be built up in layers.  From one point of view,
+a \term{package} is a single collection
+of mappings from \term{strings} into \term{internal symbols} and 
+\term{external symbols}.
+However, some of these mappings might be established within the \term{package} 
+itself, while other mappings are inherited from other \term{packages} 
+via \funref{use-package}.
+A \term{symbol} is said to be \newterm{present} in a \term{package} 
+if the mapping is in the \term{package} itself and is
+not inherited from somewhere else.
+
+%% 11.4.0 
+There is no way to inherit the \term{internal symbols} of another \term{package};
+to refer to an \term{internal symbol} using the \term{Lisp reader}, 
+    a \term{package} containing the \term{symbol} 
+     must be made to be the \term{current package},
+    a \term{package prefix} must be used,
+ or the \term{symbol} must be \term{imported} into the \term{current package}.
+
+\endsubsubsubsection%{Package Inheritance}
+
+\beginsubsubsubsection{Accessibility of Symbols in a Package}
+
+A \term{symbol} becomes \newterm{accessible} in a \term{package} 
+    if that is its \term{home package} when it is created,
+ or if it is \term{imported} into that \term{package},
+ or by inheritance via \funref{use-package}.
+
+If a \term{symbol} is \term{accessible} in a \term{package},
+it can be referred to when using the \term{Lisp reader}
+without a \term{package prefix} when that \term{package} is the \term{current package},
+regardless of whether it is \term{present} or inherited.
+
+%???Move the following to \secref\Syntax???
+%A \term{symbol} will not necessarily always have the same
+%printed representation because the way \term{symbols} are printed
+%depends on whether or not they are \term{accessible} in the \term{current package}.
+
+%% 11.0.0 35
+\term{Symbols} from one \term{package} can be made \term{accessible} 
+in another \term{package} in two ways.
+
+%% 11.0.0 36
+\beginlist 
+\itemitem{--}
+Any individual \term{symbol} can be added to a \term{package} by use
+of \funref{import}.  After the call to \funref{import} the
+\term{symbol} is \term{present} in the importing \term{package}.
+The status of the \term{symbol} in the \term{package} 
+it came from (if any) is unchanged, and the \term{home package} for
+this \term{symbol} is unchanged.
+Once \term{imported}, a \term{symbol} is \term{present} in the
+importing \term{package}
+and can be removed only by calling \funref{unintern}.
+
+%% 11.4.0 4
+A \term{symbol} is \term{shadowed}\meaning{3} by another \term{symbol} 
+in some \term{package} if the first \term{symbol} would be \term{accessible}
+by inheritance if not for the presence of the second \term{symbol}.
+See \funref{shadowing-import}.
+
+%% 11.4.0 39
+%% 11.4.0 40
+\itemitem{--}
+The second mechanism for making \term{symbols} from one \term{package}
+\term{accessible} in another is provided by \funref{use-package}.  
+All of the \term{external symbols} of the used \term{package} are inherited
+by the using \term{package}.
+\Thefunction{unuse-package} undoes the effects of a previous \funref{use-package}.  
+\endlist
+
+\endsubsubsubsection%{Accessibility of Symbols in a Package}
+
+\beginsubsubsubsection{Locating a Symbol in a Package}
+
+%% 11.4.0 8
+When a \term{symbol} is to be located in a given \term{package} 
+the following occurs:
+\beginlist 
+\itemitem{--} The \term{external symbols} and \term{internal symbols} of the 
+\term{package} are searched for the \term{symbol}.
+\itemitem{--} The \term{external symbols} of the used \term{packages} are 
+searched
+in some unspecified order.  The
+order does not matter; see the rules for handling name
+conflicts listed below. 
+\endlist
+
+\endsubsubsubsection%{Locating a Symbol in a Package}
+
+\beginsubsubsubsection{Prevention of Name Conflicts in Packages}
+
+%% 11.0.0 46
+Within one \term{package}, any particular name can refer to at most one
+\term{symbol}.  A name conflict is said to occur when there would be more than
+one candidate \term{symbol}.  Any time a name conflict is about to occur,
+a \term{correctable} \term{error} is signaled.  
+
+The following rules apply to name conflicts:
+%% 11.0.0 47
+\beginlist
+%% 11.0.0 49
+\itemitem{--}
+Name conflicts are detected when they become possible, that is, when the
+package structure is altered.  Name
+conflicts are not checked during every name lookup.
+
+\itemitem{--}
+If the \term{same} \term{symbol} is \term{accessible} to a \term{package} 
+through more than one path, there is no name conflict.
+A \term{symbol} cannot conflict with itself. 
+Name conflicts occur only between \term{distinct} \term{symbols} with
+the same name (under \funref{string=}).
+
+%% 11.0.0 48
+\itemitem{--} Every \term{package} has a list of shadowing \term{symbols}.  
+A shadowing \term{symbol} takes precedence over any other \term{symbol} of
+the same name that would otherwise be \term{accessible} in the \term{package}.  
+A name conflict involving a shadowing symbol is always resolved in favor of
+the shadowing \term{symbol}, without signaling an error (except for one
+exception involving \funref{import}).
+See \funref{shadow} and \funref{shadowing-import}.
+
+%% 11.0.0 50
+\itemitem{--} 
+The functions \funref{use-package}, \funref{import}, and 
+\funref{export} check for name conflicts.  
+
+%% 11.0.0 52
+\itemitem{--} 
+\funref{shadow} and \funref{shadowing-import} 
+never signal a name-conflict error.
+
+%% 11.0.0 53
+\itemitem{--} 
+% \funref{unuse-package}, \funref{unexport}, and \funref{unintern} 
+% (when the \term{symbol} being uninterned is not a \term{shadowing symbol}) 
+% do not need to do any name-conflict checking.
+%% Rewording for JonL:
+\funref{unuse-package} and \funref{unexport}
+do not need to do any name-conflict checking.
+\funref{unintern} does name-conflict checking only when a \term{symbol} 
+being \term{uninterned} is a \term{shadowing symbol}\idxterm{shadowing symbol}.
+
+%% 11.0.0 54
+\itemitem{--} 
+Giving a shadowing symbol to \funref{unintern} 
+can uncover a name conflict that had
+previously been resolved by the shadowing.  
+
+%% 11.0.0 55
+%\itemitem{--} 
+%Aborting from a name-conflict error leaves the original \term{symbol} 
+%\term{accessible}.
+
+  \itemitem{--} 
+  Package functions signal name-conflict errors \oftype{package-error} before making any
+  change to the package structure.  When multiple changes are to be made,
+  it is
+  permissible for the implementation to process each change separately.
+  For example, when \funref{export} is given a 
+\term{list} of 
+\term{symbols},
+  aborting from a name
+  conflict caused by the second \term{symbol} 
+  in the \term{list} might still export the
+  first \term{symbol} in the \term{list}.  
+  However, a name-conflict error caused by \funref{export}
+  of a single \term{symbol} will be signaled before
+  that \term{symbol}'s \term{accessibility} in any \term{package} is changed.
+
+%% 11.0.0 56
+\itemitem{--} 
+Continuing from a name-conflict error must offer the user a chance to
+resolve the name conflict in favor of either of the candidates.  The
+\term{package} 
+structure should be altered to reflect the resolution of the
+name conflict, via \funref{shadowing-import}, 
+\funref{unintern},
+%!!! Barmar: The next two bullets don't mention "unexport".
+or \funref{unexport}.
+
+%% 11.0.0 57
+\itemitem{--} 
+A name conflict in \funref{use-package} between a \term{symbol} 
+%directly 
+\term{present} in the using \term{package} and an \term{external symbol} of the used 
+\term{package} is resolved in favor of the first \term{symbol} by making it a
+shadowing \term{symbol}, or in favor of the second \term{symbol} by uninterning
+the first \term{symbol} from the using \term{package}. 
+
+%% 11.0.0 60
+\itemitem{--} 
+A name conflict in \funref{export} or \funref{unintern} 
+due to a \term{package}'s inheriting two \term{distinct} \term{symbols} 
+with the \term{same} \term{name} (under \funref{string=})
+from two other \term{packages} can be resolved in
+favor of either \term{symbol} by importing it into the using
+\term{package} and making it a \term{shadowing symbol}\idxterm{shadowing symbol},
+just as with \funref{use-package}.
+\endlist
+
+\endsubsubsubsection%{Prevention of Name Conflicts in Packages}
+
+\endsubsubsection%{Symbols in a Package}
+
+\endsubSection%{Introduction to Packages}
+
+\beginsubSection{Standardized Packages}
+
+%% 11.6.0 1
+This section describes the \term{packages} that are available
+in every \term{conforming implementation}.  A summary of the
+\term{names} and \term{nicknames} of those \term{standardized} \term{packages} 
+is given in \thenextfigure.
+
+\tablefigtwo{Standardized Package Names}{Name}{Nicknames}{
+\packref{common-lisp}&\packref{cl}\cr
+\packref{common-lisp-user}&\packref{cl-user}\cr
+\packref{keyword}&\i{none}\cr
+}
+
+\issue{LISP-PACKAGE-NAME:COMMON-LISP}
+%% 11.6.0 2
+% Discussion of package LISP and USER removed. -kmp 15-Feb-92
+\endissue{LISP-PACKAGE-NAME:COMMON-LISP}
+
+\issue{PACKAGE-CLUTTER:REDUCE}
+%% 11.6.0 5
+% Discussion of the CLtL1 package named SYSTEM removed.
+\endissue{PACKAGE-CLUTTER:REDUCE}
+
+\beginsubsubsection{The COMMON-LISP Package} 
+\idxpackref{common-lisp}\idxpackref{cl}
+
+\issue{LISP-PACKAGE-NAME:COMMON-LISP}
+ 
+\Thepackage{common-lisp} contains the primitives of the \clisp\ system as
+defined by this specification.  Its \term{external} \term{symbols} include
+all of the \term{defined names} (except for \term{defined names} in
+\thepackage{keyword}) that are present in the \clisp\ system, 
+such as \funref{car}, \funref{cdr},  \varref{*package*}, etc.
+\Thepackage{common-lisp} has the \term{nickname} \packref{cl}.
+ 
+\issue{PACKAGE-CLUTTER:REDUCE}
+\Thepackage{common-lisp} has as \term{external} \term{symbols} those 
+symbols enumerated in the figures in \secref\CLsymbols, and no others.
+These \term{external} \term{symbols} are \term{present} in \thepackage{common-lisp}
+but their \term{home package} need not be \thepackage{common-lisp}.
+
+For example, the symbol \f{HELP} cannot be an \term{external symbol} of
+\thepackage{common-lisp} because it is not mentioned in \secref\CLsymbols.
+In contrast, the \term{symbol} \misc{variable}
+must be an \term{external symbol} of \thepackage{common-lisp} 
+even though it has no definition
+because it is listed in that section
+(to support its use as a valid second \term{argument} to \thefunction{documentation}). 
+
+% Moved this sentence out of previous paragraph.  --sjl 7 Mar 92
+\Thepackage{common-lisp} can have additional \term{internal symbols}.
+\endissue{PACKAGE-CLUTTER:REDUCE}
+
+\beginsubsubsubsection{Constraints on the COMMON-LISP Package for Conforming Implementations}
+
+\issue{PACKAGE-CLUTTER:REDUCE}
+In a \term{conforming implementation},
+an \term{external} \term{symbol} of \thepackage{common-lisp} can have
+   a \term{function}, \term{macro}, or \term{special operator} definition, 
+%top level value  ???
+   a \term{global variable} definition
+   (or other status as a \term{dynamic variable} 
+    due to a \declref{special} \term{proclamation}),
+or a \term{type} definition
+only if explicitly permitted in this standard.
+%% That's the definition of a conforming implementation. -kmp
+%that is, a \term{conforming program} may assume that this is true.
+For example,
+  \funref{fboundp} \term{yields} \term{false} 
+  for any \term{external symbol} of \thepackage{common-lisp} 
+  that is not the \term{name} of a \term{standardized} 
+   \term{function}, \term{macro} or \term{special operator},
+and
+  \funref{boundp} returns \term{false} 
+  for any \term{external symbol} of \thepackage{common-lisp} 
+  that is not the \term{name} of a \term{standardized} \term{global variable}.
+It also follows that
+  \term{conforming programs} can use \term{external symbols} of \thepackage{common-lisp} 
+  as the \term{names} of local \term{lexical variables} 
+  with confidence that those \term{names} have not been \term{proclaimed} \declref{special} 
+  by the \term{implementation}
+  unless those \term{symbols} are
+    \term{names} of \term{standardized} \term{global variables}.
+
+%%KMP: Initially or for all times? -kmp 2-Jan-91
+%%Sandra: The intent was to cover properties put there by the implementation, not the user.
+%%KMP: I double-checked the issues, and that seems to be right.
+% No \term{external symbols} of \thepackage{common-lisp} 
+% can have \term{properties} with \term{property indicators} 
+% that are either \term{external symbols} of any \term{standardized} \term{packages}
+% or otherwise \term{accessible} in \thepackage{common-lisp-user}.
+%% Rewritten. -kmp 15-Feb-92
+A \term{conforming implementation} must not place any \term{property} on
+an \term{external symbol} of \thepackage{common-lisp} using a \term{property indicator}
+that is either an \term{external symbol} of any \term{standardized} \term{package}
+or a \term{symbol} that is otherwise \term{accessible} in \thepackage{common-lisp-user}.
+ 
+%Valid programs
+%  can assume that the conformal Lisp implementation will not
+%  have prohibited properties.  The proposal LISP-SYMBOL-REDEFINITION
+%  addresses the converse; that is, what user programs are allowed
+%  to do.
+\endissue{PACKAGE-CLUTTER:REDUCE}
+\endsubsubsubsection%{Constraints on the COMMON-LISP Package for Conforming Implementations}
+ 
+\beginsubsubsubsection{Constraints on the COMMON-LISP Package for Conforming Programs}
+\idxtext{redefinition}
+\issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+Except where explicitly allowed, the consequences are undefined if any
+of the following actions are performed on an \term{external symbol} 
+of \thepackage{common-lisp}:
+
+\beginlist
+
+\itemitem{1.} \term{Binding} or altering its value (lexically or dynamically).
+	      (Some exceptions are noted below.)
+
+\itemitem{2.} Defining, 
+\issue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+	      undefining, 
+\endissue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+	  or \term{binding} it as a \term{function}.
+	      (Some exceptions are noted below.)
+
+\itemitem{3.} Defining,
+\issue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+	      undefining, 
+\endissue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+	   or \term{binding} it as a \term{macro}
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+	      or \term{compiler macro}.
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+	      (Some exceptions are noted below.)
+
+% added define-condition --sjl 7 Mar 92
+\itemitem{4.} Defining it as a \term{type specifier} 
+	      (via \macref{defstruct}, 
+		   \macref{defclass},
+		   \macref{deftype},
+		   \macref{define-condition}).
+
+\itemitem{5.} Defining it as a structure (via \macref{defstruct}).
+
+\itemitem{6.} Defining it as a \term{declaration} 
+	      with a \declref{declaration} \term{proclamation}.
+
+\itemitem{7.} Defining it as a \term{symbol macro}.
+
+%%Barmar notes that this can't be done to any symbols.
+%% Sandra complained, too.
+% \itemitem{n.} Altering its name. 
+
+\itemitem{8.} Altering its \term{home package}.
+
+\itemitem{9.} Tracing it  (via \macref{trace}).
+
+%What's this "or lexical" biz? -kmp 13-May-91
+\itemitem{10.} Declaring or proclaiming it
+%% we voted down the lexical declaration proposal.  --sjl 7 Mar 92
+%	       \declref{special} or lexical
+	       \declref{special}
+	       (via \misc{declare},
+\issue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+		    \specref{declaim},
+\endissue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+		 or \funref{proclaim}).
+
+\itemitem{11.} Declaring or proclaiming its \declref{type} or \declref{ftype}
+	       (via \misc{declare},
+\issue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+		    \macref{declaim},
+\endissue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+		 or \funref{proclaim}).
+	       (Some exceptions are noted below.)
+
+\itemitem{12.} Removing it from \thepackage{common-lisp}.
+
+\issue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+
+\itemitem{13.} Defining a \term{setf expander} for it 
+	       (via \funref{defsetf} or \funref{define-setf-method}).
+
+\itemitem{14.} Defining, undefining, or binding its \term{setf function name}.
+
+\itemitem{15.} Defining it as a \term{method combination} type 
+		(via \funref{define-method-combination}).
+
+\itemitem{16.} Using it as the class-name argument 
+	       to \funref{setf} of \funref{find-class}.
+
+\itemitem{17.} Binding it as a \term{catch tag}.
+
+\itemitem{18.} Binding it as a \term{restart} \term{name}.
+
+\itemitem{19.} Defining a \term{method} 
+	       for a \term{standardized} \term{generic function} 
+	       which is \term{applicable} when all of the \term{arguments}
+      	       are \term{direct instances} of \term{standardized} \term{classes}.
+
+\endissue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+
+\endlist 
+
+\beginsubsubsubsubsection{Some Exceptions to Constraints on the COMMON-LISP Package for Conforming Programs}
+
+If an \term{external symbol} of \thepackage{common-lisp}
+is not globally defined as a \term{standardized} \term{dynamic variable} 
+					      or \term{constant variable},
+it is allowed to lexically \term{bind} it 
+          and to declare the \declref{type} of that \term{binding}, 
+and
+it is allowed to locally \term{establish} it as a \term{symbol macro} 
+(\eg with \specref{symbol-macrolet}).
+
+%KMP: Maybe clarify that binding CL special variables is ok,
+%     but that their type decls are lexical.  Is that right?
+%%I implemented the first half of that suggestion. -kmp 15-Feb-92
+Unless explicitly specified otherwise,
+if an \term{external symbol} of \thepackage{common-lisp} 
+is globally defined as a \term{standardized} \term{dynamic variable},
+it is permitted to \term{bind} or \term{assign} that \term{dynamic variable}
+provided that the ``Value Type'' constraints on the \term{dynamic variable} 
+are maintained, and that the new \term{value} of the \term{variable} 
+is consistent with the stated purpose of the \term{variable}.
+
+If an \term{external symbol} of \thepackage{common-lisp} is not defined
+as a \term{standardized} \term{function}, \term{macro}, or \term{special operator},
+it is allowed to lexically \term{bind} it as a \term{function} (\eg with \specref{flet}),
+              to declare the \declref{ftype} of that \term{binding}, 
+          and 
+%KMP: Barmar wanted some explication here.  I think it was sandra who had 
+%     asked for this tracing feature just in case the implementation supported it.
+              (in \term{implementations} which provide the ability to do so)
+	      to \macref{trace} that \term{binding}.
+
+If an \term{external symbol} of \thepackage{common-lisp} is not defined
+as a \term{standardized} \term{function}, \term{macro}, or \term{special operator},
+it is allowed to lexically \term{bind} it as a \term{macro} (\eg with \specref{macrolet}).
+\endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+
+\endissue{LISP-PACKAGE-NAME:COMMON-LISP}
+
+\issue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+If an \term{external symbol} of \thepackage{common-lisp} is not defined 
+as a \term{standardized} \term{function}, \term{macro}, or \term{special operator},
+it is allowed to lexically \term{bind} its \term{setf function name}
+as a \term{function},
+and to declare the \declref{ftype} of that \term{binding}.
+\endissue{LISP-SYMBOL-REDEFINITION-AGAIN:MORE-FIXES}
+
+\endsubsubsubsubsection%{Some Exceptions to Constraints on the COMMON-LISP Package for Conforming Programs}
+
+\endsubsubsubsection%{Constraints on the COMMON-LISP Package for Conforming Programs}
+
+\endsubsubsection%{The COMMON-LISP Package} 
+
+\beginsubsubsection{The COMMON-LISP-USER Package}
+\idxpackref{common-lisp-user}\idxpackref{cl-user}
+
+\Thepackage{common-lisp-user} is the \term{current package} when 
+a \clisp\ system starts up.  This \term{package} \term{uses} \thepackage{common-lisp}.
+\Thepackage{common-lisp-user} has the \term{nickname} \packref{cl-user}.
+\issue{PACKAGE-CLUTTER:REDUCE}
+\Thepackage{common-lisp-user} can have additional \term{symbols} \term{interned} within it;
+it can \term{use} other \term{implementation-defined} \term{packages}.
+\endissue{PACKAGE-CLUTTER:REDUCE}
+ 
+\endsubsubsection%{The COMMON-LISP-USER Package}
+
+\beginsubsubsection{The KEYWORD Package}
+\idxpackref{keyword}
+
+%% 5.1.2 6
+%% 11.3.0 5
+% % KMP: This isn't a very apt description! 
+% % %% 11.6.0 4
+% \Thepackage{keyword} contains all of the \newterm{keywords}\meaning{1}
+% used by built-in or user-defined \term{functions}.  
+%% Replaced:
+\Thepackage{keyword} contains \term{symbols}, called \term{keywords}\meaning{1},
+that are typically used as special markers in \term{programs} 
+and their associated data \term{expressions}\meaning{1}.
+
+\term{Symbol} \term{tokens} that start with a \term{package marker} 
+are parsed by the \term{Lisp reader} as \term{symbols} 
+in \thepackage{keyword}; \seesection\SymbolTokens.
+This makes it notationally convenient to use \term{keywords}
+when communicating between programs in different \term{packages}.  
+For example, the mechanism for passing \term{keyword parameters} in a \term{call} uses 
+\term{keywords}\meaning{1} to name the corresponding \term{arguments};
+\seesection\OrdinaryLambdaLists.
+
+\term{Symbols} in \thepackage{keyword} are, by definition, \oftype{keyword}.
+
+\beginsubsubsubsection{Interning a Symbol in the KEYWORD Package}
+
+\Thepackage{keyword} is treated differently than other \term{packages}
+in that special actions are taken when a \term{symbol} is \term{interned} in it.
+In particular, when a \term{symbol} is \term{interned} in \thepackage{keyword},
+ it is automatically made to be an \term{external symbol} 
+and is automatically made to be a \term{constant variable} with itself as a \term{value}.
+
+%% Not really needed. This is documented adequately under SYMBOL-VALUE.
+% \Thefunction{symbol-value} can be used to
+% \term{access} the \term{value} of a \term{keyword}\meaning{1}.)
+
+\endsubsubsubsection%{Interning a Symbol in the KEYWORD Package}
+
+\beginsubsubsubsection{Notes about The KEYWORD Package}
+
+% name conflicts are not an issue because these \term{symbols}
+% are used only as labels, not to carry application-specific information.
+%% This isn't really true and is arguably confusing.
+%% I think the following is what it was getting at. -kmp 15-Feb-92
+
+It is generally best to confine the use of \term{keywords} to situations in which
+there are a finitely enumerable set of names to be selected between.  For example,
+if there were two states of a light switch, they might be called \kwd{on} and \kwd{off}.
+
+In situations where the set of names is not finitely enumerable
+(\ie where name conflicts might arise)
+it is frequently best to use \term{symbols} in some \term{package}
+other than \packref{keyword} so that conflicts will be naturally avoided.
+For example, it is generally not wise for a \term{program} to use a \term{keyword}\meaning{1} 
+as a \term{property indicator}, since if there were ever another \term{program}
+that did the same thing, each would clobber the other's data.
+
+\endsubsubsubsection%{Notes about The KEYWORD Package}
+
+\endsubsubsection%{The KEYWORD Package}
+
+\beginsubsubsection{Implementation-Defined Packages} 
+
+\issue{PACKAGE-CLUTTER:REDUCE}
+Other, \term{implementation-defined} \term{packages} might be present
+in the initial \clisp\ environment.
+%If it is appropriate, the standard might contain
+%  as an example that implementations might have a package named
+%  "SYSTEM".
+\endissue{PACKAGE-CLUTTER:REDUCE}
+
+It is recommended, but not required, that the documentation for a
+\term{conforming implementation} contain a full list of all \term{package} names
+initially present in that \term{implementation} but not specified in this specification.
+(See also the \term{function} \funref{list-all-packages}.)
+
+\endsubsubsection%{Implementation-Defined Packages} 
+
+\endsubSection%{Standardized Packages}
+

concept-pathnames.tex

@@ -0,0 +1,694 @@
+% -*- Mode: TeX -*-
+
+\beginSubsection{Pathname Components}
+\DefineSection{PathnameComponents}
+
+% \long\def\possiblecomponentvalues#1{\goodbreak
+% Possible values for this component:\par
+% \beginlist\par#1\par
+% \itemitem{\nil, \kwd{wild}, or \kwd{unspecific}}\par
+% See details and restrictions in \secref\SpecialComponentValues.\par
+% \endlist\par}
+%
+% \possiblecomponentvalues{\itemitem{...}\par...}
+
+A \term{pathname} has six components:
+     a host,
+     a device,
+     a directory,
+     a name,
+     a type,
+ and a version.
+
+%% 23.1.1 4
+%% 23.1.1 5
+%% 23.1.1 17
+
+\beginsubsubsection{The Pathname Host Component}
+
+The name of the file system on which the file resides,
+or the name of a \term{logical host}.
+
+%\possiblecomponentvalues{\itemitem{...}\par...}
+
+\endsubsubsection%{The Pathname Host Component}
+
+\beginsubsubsection{The Pathname Device Component}
+
+Corresponds to the ``device'' or ``file structure'' concept in many
+host file systems: the name of a logical or physical device containing files.
+
+%\possiblecomponentvalues{\itemitem{...}\par...}
+
+\endsubsubsection%{The Pathname Device Component}
+
+%% 23.1.1 6
+\beginsubsubsection{The Pathname Directory Component}
+
+Corresponds to the ``directory'' concept in many host file systems:
+the name of a group of related files.
+
+%\possiblecomponentvalues{\itemitem{...}\par...}
+
+\endsubsubsection%{The Pathname Directory Component}
+
+%% 23.1.1 7
+\beginsubsubsection{The Pathname Name Component}
+
+The ``name'' part of a group of \term{files} that can be thought of
+as conceptually related.
+
+%\possiblecomponentvalues{\itemitem{...}\par...}
+
+\endsubsubsection%{The Pathname Name Component}
+
+%% 23.1.1 8
+%% 23.1.1 15
+\beginsubsubsection{The Pathname Type Component}
+
+Corresponds to the ``filetype'' or ``extension'' concept in many host
+file systems.  This says what kind of file this is.  
+This component is always a \term{string}, \nil, \kwd{wild}, or \kwd{unspecific}.
+
+%\possiblecomponentvalues{\itemitem{...}\par...}
+
+\endsubsubsection%{The Pathname Type Component}
+
+%% 23.1.1 9
+%% 23.1.1 16  
+\beginsubsubsection{The Pathname Version Component}
+
+Corresponds to the ``version number'' concept in many host file systems.
+
+The version is either a positive \term{integer} 
+or a \term{symbol} from the following list:
+\nil, \kwd{wild}, \kwd{unspecific}, or \kwd{newest}
+(refers to the largest version number that already exists in 
+the file system when reading a file, or to
+a version number
+greater than any already existing in the file system
+when writing a new file).  Implementations 
+can define other special version \term{symbols}.
+
+%\possiblecomponentvalues{\itemitem{...}\par...}
+
+\endsubsubsection%{The Pathname Version Component}
+
+\endSubsection%{Pathname Components}
+
+\beginSubsection{Interpreting Pathname Component Values}
+
+\beginsubsubsection{Strings in Component Values}
+
+\issue{PATHNAME-COMPONENT-VALUE:SPECIFY}
+
+\beginsubsubsubsection{Special Characters in Pathname Components}
+
+\term{Strings} in \term{pathname} component values 
+never contain special \term{characters} that represent
+separation between \term{pathname} fields, 
+such as \term{slash} in \Unix\ \term{filenames}.
+Whether separator \term{characters} are permitted as 
+part of a \term{string} in a \term{pathname} component
+is \term{implementation-defined}; 
+however, if the \term{implementation} does permit it, 
+it must arrange to properly ``quote'' the character for the 
+\term{file system} when constructing a \term{namestring}.
+For example,
+
+\code
+ ;; In a TOPS-20 implementation, which uses {\hat}V to quote 
+ (NAMESTRING (MAKE-PATHNAME :HOST "OZ" :NAME "<TEST>"))
+\EV #P"OZ:PS:{\hat}V<TEST{\hat}V>"
+\NV #P"OZ:PS:<TEST>"
+\endcode
+
+%Such punctuation \term{characters} appear only in \term{namestrings}.
+%Characters used as punctuation can appear in \term{pathname} component values
+%with a non-punctuation meaning if the file system allows it 
+%(\eg a \Unix\ file name that begins with a dot).
+ 
+\endsubsubsubsection%{Special Characters in Pathname Components}
+
+\endissue{PATHNAME-COMPONENT-VALUE:SPECIFY}
+
+\issue{PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT}
+\beginsubsubsubsection{Case in Pathname Components}
+\DefineSection{PathnameComponentCase}
+
+\term{Namestrings} always use local file system \term{case} conventions, 
+but \clisp\ \term{functions} that manipulate \term{pathname} components
+allow the caller to select either of two conventions for representing
+\term{case} in component values by supplying a value for the
+\kwd{case} keyword argument.
+%Added per Loosemore #32, first public review -kmp 26-Jun-93
+\Thenextfigure\ lists the functions 
+relating to \term{pathnames} that permit a \kwd{case} argument:
+
+\DefineFigure{PathnameCaseFuns}
+\displaythree{Pathname functions using a :CASE argument}{
+make-pathname&pathname-directory&pathname-name\cr
+pathname-device&pathname-host&pathname-type\cr
+}
+
+\beginsubsubsubsubsection{Local Case in Pathname Components}
+
+For the functions in \figref\PathnameCaseFuns,
+a value of \kwd{local}\idxkwd{local} for the \kwd{case} argument 
+(the default for these functions)
+indicates that the functions should receive and yield \term{strings} in component values
+as if they were already represented according to the host \term{file system}'s 
+convention for \term{case}.
+
+If the \term{file system} supports both \term{cases}, \term{strings} given or received
+as \term{pathname} component values under this protocol are to be used exactly
+as written.  If the file system only supports one \term{case}, 
+the \term{strings} will be translated to that \term{case}.
+
+\endsubsubsubsubsection%{Local Case in Pathname Components}
+
+\beginsubsubsubsubsection{Common Case in Pathname Components}
+
+For the functions in \figref\PathnameCaseFuns,
+a value of \kwd{common}\idxkwd{common} for the \kwd{case} argument 
+that these \term{functions} should receive 
+and yield \term{strings} in component values according to the following conventions:
+
+\beginlist
+\itemitem{\bull}
+All \term{uppercase} means to use a file system's customary \term{case}.
+\itemitem{\bull}
+All \term{lowercase} means to use the opposite of the customary \term{case}.
+\itemitem{\bull}
+Mixed \term{case} represents itself.
+\endlist
+Note that these conventions have been chosen in such a way that translation
+from \kwd{local} to \kwd{common} and back to \kwd{local} is information-preserving.
+ 
+\endsubsubsubsubsection%{Common Case in Pathname Components}
+
+\endsubsubsubsection%{Case in Pathname Components}
+\endissue{PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT}
+
+\endsubsubsection%{Strings in Component Values}
+
+\beginsubsubsection{Special Pathname Component Values}
+\DefineSection{SpecialComponentValues}
+
+\beginsubsubsubsection{NIL as a Component Value}
+
+% Bullet 1 from ``Restrictions on Examining Pathname Components'' 
+% said something similar I've consolidated the two here. -kmp 30-Aug-93
+
+As a \term{pathname} component value,
+\nil represents that the component is ``unfilled'';
+\seesection\MergingPathnames.
+
+The value of any \term{pathname} component can be \nil.
+
+%% This came from bullet 1 of ``Restrictions on Constructing Pathnames''
+When constructing a \term{pathname},
+\nil\ in the host component might mean a default host
+rather than an actual \nil\ in some \term{implementations}.
+
+\endsubsubsubsection%{NIL as a Component Value}
+
+\issue{PATHNAME-COMPONENT-VALUE:SPECIFY}
+\beginsubsubsubsection{:WILD as a Component Value}
+\DefineSection{WildComponents}
+
+If \kwd{wild}\idxkwd{wild} is the value of a \term{pathname} component,
+that component is considered to be a wildcard, which matches anything.
+
+A \term{conforming program} must be prepared to encounter a value of \kwd{wild}
+as the value of any \term{pathname} component,
+or as an \term{element} of a \term{list} that is the value of the directory component.
+
+\issue{PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION}
+When constructing a \term{pathname},
+a \term{conforming program} may use \kwd{wild} as the value of any or all of
+the directory, name, type, 
+or version component, but must not use \kwd{wild} as the value of the host,
+%% "version" commented out per Barmar--
+%% PATHNAME-COMPONENT-VALUE:SPECIFY says that wild versions are permitted.
+%device, or version
+or device component.
+
+If \kwd{wild} is used as the value of the directory component in the construction
+of a \term{pathname}, the effect is equivalent to specifying the list
+\f{(:absolute :wild-inferiors)},
+or the same as \f{(:absolute :wild)} in a \term{file system} that does not support
+\kwd{wild-inferiors}.\idxkwd{wild-inferiors}
+\endissue{PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION}
+
+\endsubsubsubsection%{:WILD as a Component Value}
+\endissue{PATHNAME-COMPONENT-VALUE:SPECIFY}
+
+\issue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+\beginsubsubsubsection{:UNSPECIFIC as a Component Value}
+\DefineSection{UnspecificComponent}
+
+If \kwd{unspecific}\idxkwd{unspecific} is the value of a \term{pathname} component,
+the component is considered to be ``absent'' 
+% Part of bullet 2 of ``Restrictions on Examining Pathname Components''
+or to ``have no meaning''
+in the \term{filename} being represented by the \term{pathname}.
+
+Whether a value of \kwd{unspecific} is permitted for any component
+on any given \term{file system} accessible to the \term{implementation}
+is \term{implementation-defined}.
+A \term{conforming program} must never unconditionally use a
+\kwd{unspecific} as the value of a \term{pathname} component because
+such a value is not guaranteed to be permissible in all implementations.
+However, a \term{conforming program} can, if it is careful, 
+successfully manipulate user-supplied data 
+which contains or refers to non-portable \term{pathname} components.
+And certainly a \term{conforming program} should be prepared for the
+possibility that any components of a \term{pathname} could be \kwd{unspecific}.
+
+\issue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+% Part of bullet 2 of ``Restrictions on Examining Pathname Components''
+When \term{reading}\meaning{1} the value of any \term{pathname} component,
+\term{conforming programs} should be prepared for the value to be \kwd{unspecific}.
+\endissue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+
+\issue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+When \term{writing}\meaning{1} the value of any \term{pathname} component,
+the consequences are undefined if \kwd{unspecific} is given 
+for a \term{pathname} in a \term{file system} for which it does not make sense.
+\endissue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN} 
+
+\beginsubsubsubsubsection{Relation between component values NIL and :UNSPECIFIC}
+
+%% Redundant. -kmp 30-Aug-93
+% Note that this is similar to a value of \nil\ in that it
+% does not supply a value for the component, but it is different
+% because the component is considered to have been filled.
+
+%% Moved from bullet 2 of ``Restrictions on Examining Pathname Components''
+\issue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+If a \term{pathname} is converted to a \term{namestring}, 
+the \term{symbols} \nil\ and \kwd{unspecific}
+cause the field to be treated as if it were empty.
+That is,
+both \nil\ and \kwd{unspecific} 
+cause the component not to appear in the \term{namestring}.
+
+However, when merging a \term{pathname} with a set of defaults,
+only a \nil\ value for a component 
+will be replaced with the default for that component, 
+while a value of \kwd{unspecific}
+will be left alone as if the field were ``filled'';
+\seefun{merge-pathnames} and \secref\MergingPathnames.
+\endissue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+
+\endsubsubsubsubsection%{Relation between component values NIL and :UNSPECIFIC}
+
+\endsubsubsubsection%{:UNSPECIFIC as a Component Value}
+\endissue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+
+\endsubsubsection%{Special Pathname Component Values}
+
+\endsubsubsection%{Restrictions on Examining Pathname Components}
+
+\beginsubsubsection{Restrictions on Wildcard Pathnames}
+\DefineSection{WildcardRestrictions}
+
+  Wildcard \term{pathnames} can be used with \funref{directory} but not with 
+  \funref{open},
+%!!! Laddaga: LOAD?
+  and return true from \funref{wild-pathname-p}. When examining
+  wildcard components of a wildcard \term{pathname}, conforming programs
+  must be prepared to encounter any of the following additional values
+  in any component or any element of a \term{list} that is the directory component:
+ 
+\beginlist
+
+\itemitem{\bull} The \term{symbol} \kwd{wild}, which matches anything.
+ 
+\itemitem{\bull} A \term{string} containing \term{implementation-dependent} 
+		 special wildcard \term{characters}.
+ 
+\itemitem{\bull} Any \term{object},
+		 representing an \term{implementation-dependent} wildcard pattern.
+
+\endlist 
+
+\endsubsubsection%{Restrictions on Wildcard Pathnames}
+
+\issue{PATHNAME-COMPONENT-VALUE:SPECIFY}
+
+\beginsubsubsection{Restrictions on Examining Pathname Components}
+  
+The space of possible \term{objects} that a \term{conforming program} 
+must be prepared to \term{read}\meaning{1} 
+as the value of a \term{pathname} component
+is substantially larger than the space of possible \term{objects} 
+that a \term{conforming program} is permitted to \term{write}\meaning{1}
+into such a component.
+
+While the values discussed 
+    in the subsections of this section,
+    in {\secref\SpecialComponentValues},
+and in {\secref\WildcardRestrictions} 
+apply to values that might be seen when 
+reading the component values,
+substantially more restrictive rules apply to constructing pathnames;
+\seesection\ConstructingPathnames.
+
+When examining \term{pathname} components,
+\term{conforming programs} should be aware of the following restrictions.
+
+% \beginlist
+% 
+% %% Consolidated with ``NIL as a Component Value'' above.
+% % \itemitem{\bull} Any component can be \nil, ...
+%   
+% %% Consolidated with ``:UNSPECIFIC as a Component Value'' above.
+% % \issue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+% % \itemitem{\bull} Any component can be \kwd{unspecific}, ...
+% % \endissue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+%   
+% %% Moved to various sections below.
+% %\itemitem{\bull} The device, directory, name, and type can be \term{strings}.
+%   
+% %% Moved to new section farther down.
+% % \itemitem{\bull}
+% % It is \term{implementation-dependent} what \term{object}
+% % is used to represent the host. 
+%   
+% %% Moved to new section below.
+% % \itemitem{\bull}
+% % The directory can be a \term{list} of \term{strings} and \term{symbols}. 
+% % [...]
+%   
+% %% Moved to new section below.
+% % \itemitem{\bull} The version can be any \term{symbol} or any \term{integer}.  
+% 
+% \endlist 
+
+\beginsubsubsubsection{Restrictions on Examining a Pathname Host Component}
+
+It is \term{implementation-dependent} what \term{object} is used to represent the host. 
+
+\endsubsubsubsection%{Restrictions on Examining a Pathname Host Component}
+
+\beginsubsubsubsection{Restrictions on Examining a Pathname Device Component}
+
+%% From bullet 3 of ``Restrictions on Examining Pathname Components'' 
+%% the way it used to be arranged.
+The device might be a \term{string},
+% These came from other sections earlier -kmp 30-Aug-93
+\kwd{wild}, \kwd{unspecific}, or \nil.
+
+Note that \kwd{wild} might result from an attempt to \term{read}\meaning{1}
+the \term{pathname} component, even though portable programs are restricted
+from \term{writing}\meaning{1} such a component value; 
+\seesection\WildcardRestrictions\ and \secref\ConstructingPathnames.
+
+\endsubsubsubsection%{Restrictions on Examining a Pathname Device Component}
+
+\beginsubsubsubsection{Restrictions on Examining a Pathname Directory Component}
+
+%% From bullet 3 of ``Restrictions on Examining Pathname Components'' 
+%% the way it used to be arranged.
+The directory might be a \term{string},
+%%!!! Laddaga:
+%%  But cannot cannot contain directory separators.  Or, put another way, if
+%%  a directory component is a string, it can only name a simple level of 
+%%  directory structure?  This doesn't seem right, but otherwise rule 1 is violated.
+%%  Perhaps directory here is an error?
+%
+%% These came from other sections earlier -kmp 30-Aug-93
+\kwd{wild}, \kwd{unspecific}, or \nil.
+
+The directory can be a \term{list} of \term{strings} and \term{symbols}. 
+\issue{PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION}
+The \term{car} of the \term{list} is one of the symbols \kwd{absolute}\idxkwd{absolute} or 
+\kwd{relative}\idxkwd{relative}, meaning:
+
+\beginlist
+
+\item{\kwd{absolute}}
+
+  A \term{list} whose \term{car} is the symbol \kwd{absolute} represents 
+  a directory path starting from the root directory.  The list 
+  \f{(:absolute)} represents the root directory.  The list 
+  \f{(:absolute "foo" "bar" "baz")} represents the directory called
+  \f{"/foo/bar/baz"} in Unix (except possibly for \term{case}).
+ 
+\item{\kwd{relative}}
+
+  A \term{list} whose \term{car} is the symbol \kwd{relative} represents 
+  a directory path starting from a default directory.  
+  The list \f{(:relative)} has the same meaning as \nil\ and hence is not used.
+  The list {\tt (:relative "foo" "bar")} represents the directory named {\tt "bar"} 
+  in the directory named {\tt "foo"} in the default directory.
+
+\endlist
+
+Each remaining element of the \term{list} is a \term{string} or a \term{symbol}.
+
+Each \term{string} names a single level of directory structure.
+The \term{strings} should contain only the directory names 
+themselves---no punctuation characters.
+
+In place of a \term{string}, at any point in the \term{list}, \term{symbols} 
+can occur to indicate special file notations.
+\Thenextfigure\ lists the \term{symbols} that have standard meanings.
+Implementations are permitted to add additional \term{objects} 
+of any \term{type} that is disjoint from \typeref{string}
+if necessary to represent features of their file systems that cannot be
+represented with the standard \term{strings} and \term{symbols}.
+
+Supplying any non-\term{string}, including any of the \term{symbols} listed below, 
+to a file system for which it does not make sense
+signals an error \oftype{file-error}.
+For example, Unix does not support \kwd{wild-inferiors} in most implementations.
+ 
+\idxkwd{wild}\idxkwd{wild-inferiors}\idxkwd{up}\idxkwd{back}%
+\tablefigtwo{Special Markers In Directory Component}{Symbol}{Meaning}{
+\kwd{wild}           & Wildcard match of one level of directory structure \cr
+\kwd{wild-inferiors} & Wildcard match of any number of directory levels   \cr
+\kwd{up}             & Go upward in directory structure (semantic) \cr
+\kwd{back}           & Go upward in directory structure (syntactic) \cr
+}
+
+The following notes apply to the previous figure:
+
+\beginlist
+\item{Invalid Combinations}
+
+Using \kwd{absolute} or \kwd{wild-inferiors} 
+immediately followed by \kwd{up} or \kwd{back}
+signals an error \oftype{file-error}.
+ 
+\item{Syntactic vs Semantic}
+
+``Syntactic'' means that the action of \kwd{back} 
+depends only on the \term{pathname}
+and not on the contents of the file system.  
+
+``Semantic'' means that the action of \kwd{up} 
+depends on the contents of the file system; 
+to resolve a \term{pathname} containing 
+\kwd{up} to a \term{pathname} whose directory component
+contains only \kwd{absolute} and 
+\term{strings} requires probing the file system.
+
+\kwd{up} differs from 
+\kwd{back} only in file systems that support multiple
+  names for directories, perhaps via symbolic links.  For example,
+  suppose that there is a directory
+\f{(:absolute "X" "Y" "Z")}
+  linked to 
+\f{(:absolute "A" "B" "C")}
+  and there also exist directories
+\f{(:absolute "A" "B" "Q")} and 
+\f{(:absolute "X" "Y" "Q")}.
+Then
+\f{(:absolute "X" "Y" "Z" :up "Q")}
+  designates
+\f{(:absolute "A" "B" "Q")}
+  while
+\f{(:absolute "X" "Y" "Z" :back "Q")}
+  designates
+\f{(:absolute "X" "Y" "Q")}
+\endlist 
+
+\endissue{PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION}
+
+\beginsubsubsubsubsection{Directory Components in Non-Hierarchical File Systems}
+
+In non-hierarchical \term{file systems},
+the only valid \term{list} values for the directory component of a \term{pathname}
+are \f{(:absolute \term{string})} and \f{(:absolute :wild)}.
+\kwd{relative} directories and the keywords
+\kwd{wild-inferiors}, \kwd{up}, and \kwd{back} are not used 
+in non-hierarchical \term{file systems}.
+
+\endsubsubsubsubsection%{Directory Components in Non-Hierarchical File Systems}
+
+\endsubsubsubsection%{Restrictions on Examining a Pathname Directory Component}
+
+\beginsubsubsubsection{Restrictions on Examining a Pathname Name Component}
+
+%% From bullet 3 of ``Restrictions on Examining Pathname Components'' 
+%% the way it used to be arranged.
+The name might be a \term{string},
+%% These came from other sections earlier -kmp 30-Aug-93
+\kwd{wild}, \kwd{unspecific}, or \nil.
+
+\endsubsubsubsection%{Restrictions on Examining a Pathname Name Component}
+
+\beginsubsubsubsection{Restrictions on Examining a Pathname Type Component}
+
+%% From bullet 3 of ``Restrictions on Examining Pathname Components'' 
+%% the way it used to be arranged.
+The type might be a \term{string},
+%% These came from other sections earlier -kmp 30-Aug-93
+\kwd{wild}, \kwd{unspecific}, or \nil.
+
+\endsubsubsubsection%{Restrictions on Examining a Pathname Type Component}
+
+\beginsubsubsubsection{Restrictions on Examining a Pathname Version Component}
+
+The version can be any \term{symbol} or any \term{integer}.  
+
+The symbol \kwd{newest} refers to the largest version number 
+that already exists in the \term{file system}
+when reading, overwriting, appending, superseding, or directory listing 
+an existing \term{file}.
+The symbol \kwd{newest} refers to the smallest version number
+greater than any existing version number when creating a new file.
+
+The symbols \nil, \kwd{unspecific}, and \kwd{wild} have special meanings and
+restrictions; \seesection\SpecialComponentValues\ and \secref\ConstructingPathnames.
+
+Other \term{symbols} and \term{integers}
+have \term{implementation-defined} meaning.
+
+\beginsubsubsubsection{Notes about the Pathname Version Component}
+
+It is suggested, but not required, that implementations do the following:
+
+\beginlist
+
+\itemitem{\bull} Use positive \term{integers} starting at 1 as version numbers.
+
+\itemitem{\bull} Recognize the symbol \kwd{oldest}
+		 to designate the smallest existing version number.
+
+\itemitem{\bull} Use \term{keywords} for other special versions.
+
+\endlist
+
+\endsubsubsubsection%{Notes about the Pathname Version Component}
+
+\beginsubsubsection{Restrictions on Constructing Pathnames}
+\DefineSection{ConstructingPathnames}
+
+  When constructing a \term{pathname} from components, conforming programs
+  must follow these rules:
+  
+\beginlist
+
+\itemitem{\bull}
+  Any component can be \nil.
+  \nil\ in the host might mean a default host 
+  rather than an actual \nil\ in some implementations.
+           
+\itemitem{\bull}
+%!!! Laddaga questions the "directory" part here.
+  The host, device, directory, name, and type can be \term{strings}.  There
+  are \term{implementation-dependent} limits on the number and type of
+  \term{characters} in these \term{strings}.
+  
+\itemitem{\bull}
+  The directory can be a \term{list} of \term{strings} and \term{symbols}.
+  There are \term{implementation-dependent} limits on the \term{list}'s
+  length and contents.
+  
+\itemitem{\bull}
+  The version can be \kwd{newest}.
+ 
+\itemitem{\bull}
+  Any component can be taken 
+  from the corresponding component of another \term{pathname}.
+  When the two \term{pathnames} are for different file systems
+    (in implementations that support multiple file systems),
+  an appropriate translation occurs.
+  If no meaningful translation is possible,
+  an error is signaled.
+  The definitions of ``appropriate'' and ``meaningful'' 
+  are \term{implementation-dependent}.
+  
+\itemitem{\bull}
+  An implementation might support other values for some components,
+  but a portable program cannot use those values.
+  A conforming program can use \term{implementation-dependent} values
+  but this can make it non-portable;
+  for example, it might work only with \Unix\ file systems.
+\endlist                                   
+
+%%% 23.1.1 14 omitted.
+%%% 23.1.1 18 omitted.
+
+\endsubsubsection%{Restrictions on Constructing Pathnames}
+
+\endissue{PATHNAME-COMPONENT-VALUE:SPECIFY}
+
+\endSubsection%{Interpreting Pathname Component Values}
+
+\beginsubSection{Merging Pathnames}
+\DefineSection{MergingPathnames}
+
+Merging takes a \term{pathname} with unfilled components
+and supplies values for those components from a source of defaults.
+
+If a component's value is \nil, that component is considered to be unfilled.
+If a component's value is any \term{non-nil} \term{object}, 
+including \kwd{unspecific}, that component is considered to be filled.
+
+%% Replaced per X3J13
+% %% Moved from ``Restrictions on Examining Pathname Components''
+% %% Laddaga had complained that this was in the wrong place before.
+% %% This place may not be 100% better, but it's at least an improvement. -kmp 30-Aug-93
+% A relative directory in the \term{pathname} argument to a function such as
+% \funref{open} is merged with \varref{*default-pathname-defaults*} 
+% before accessing the file system.
+Except as explicitly specified otherwise,
+for functions that manipulate or inquire about \term{files} in the \term{file system},
+the pathname argument to such a function
+is merged with \funref{*default-pathname-defaults*} before accessing the \term{file system}
+(as if by \funref{merge-pathnames}).
+
+\beginsubsubsection{Examples of Merging Pathnames}
+
+Although the following examples are possible to execute only in
+\term{implementations} which permit \kwd{unspecific} in the indicated
+position andwhich permit four-letter type components, they serve to illustrate
+the basic concept of \term{pathname} merging.
+
+\medbreak
+\code
+ (pathname-type 
+   (merge-pathnames (make-pathname :type "LISP")
+                    (make-pathname :type "TEXT")))
+\EV "LISP"
+\smallbreak
+ (pathname-type 
+   (merge-pathnames (make-pathname :type nil)
+                    (make-pathname :type "LISP")))
+\EV "LISP"
+\smallbreak
+ (pathname-type 
+   (merge-pathnames (make-pathname :type :unspecific)
+                    (make-pathname :type "LISP")))
+\EV :UNSPECIFIC
+\endcode
+
+\endsubsubsection%{Examples of Merging Pathnames}
+
+\endsubSection%{Merging Pathnames}
+

concept-places.tex

@@ -0,0 +1,928 @@
+% -*- Mode: TeX -*-
+%% Generalized Reference
+
+%% Moon thinks terms "generalized reference" and "place" need to be rationalized throughout.
+%% Done! -kmp 16-Jul-93
+
+\beginsubSection{Overview of Places and Generalized Reference}
+
+A \newterm{generalized reference} is the use of a \term{form},
+sometimes called a \newterm{place},
+as if it were a \term{variable} that could be read and written.
+The \term{value} of a \term{place} is 
+the \term{object} to which the \term{place} \term{form} evaluates.
+The \term{value} of a \term{place} can be changed by using \macref{setf}.
+The concept of binding a \term{place} is not defined in \clisp,
+but an \term{implementation} is permitted to extend the language by defining this concept.
+
+\Thenextfigure\ contains examples of the use of \macref{setf}.
+Note that the values returned by evaluating the \term{forms} in column two 
+are not necessarily the same as those obtained by evaluating the 
+\term{forms} in column three.
+%% 7.2.0 18
+In general, the exact \term{macro expansion} of a \macref{setf} \term{form} is not guaranteed 
+and can even be \term{implementation-dependent};
+all that is guaranteed is 
+ that the expansion is an update form that works
+   for that particular \term{implementation},
+ that the left-to-right evaluation of \term{subforms} is preserved, 
+and
+%% 7.2.0 19
+ that the ultimate result of evaluating \macref{setf} is the value
+  or values being stored.
+
+\tablefigthree{Examples of setf}{Access function}{Update Function}{Update using \macref{setf}}{
+\f{x}                & \f{(setq x datum)}   & \f{(setf x datum)}                \cr
+\f{(car x)}          & \f{(rplaca x datum)} & \f{(setf (car x) datum)}          \cr
+\f{(symbol-value x)} & \f{(set x datum)}    & \f{(setf (symbol-value x) datum)} \cr}
+
+\Thenextfigure\ shows \term{operators} relating to
+\term{places} and \term{generalized reference}.
+
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+
+\displaythree{Operators relating to places and generalized reference.}{
+assert&defsetf&push\cr
+ccase&get-setf-expansion&remf\cr
+ctypecase&getf&rotatef\cr
+decf&incf&setf\cr
+define-modify-macro&pop&shiftf\cr
+define-setf-expander&psetf&\cr
+}
+%!!! Should defmethod be here for the sake of SETF methods?? -kmp 8-May-91
+
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+Some of the \term{operators} above manipulate \term{places}
+and some manipulate \term{setf expanders}.
+%% 7.2.0 57
+A \term{setf expansion} can be derived from any \term{place}.
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+%% 7.2.0 20
+New \term{setf expanders} can be defined by using \macref{defsetf} 
+and \macref{define-setf-expander}.
+
+
+%% Moon thinks this follows from rule 2 below, and asked that it be commented out.
+%
+% %% 7.2.0 29
+% %% 7.2.0 30                 
+% These operators evaluate the \term{subforms} of 
+% \term{places} exactly as many times as they appear in the source program,
+% and exactly in the same order (left-to-right) as they appear in the source.
+% \issue{PUSH-EVALUATION-ORDER:ITEM-FIRST}
+% %The left-to-right rule does not
+% %remove the obligation on writers of \term{macros} and 
+% %users of 
+% %\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+% %\macref{define-setf-expander}  
+% %\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+% %to ensure left-to-right order, however. 
+% \endissue{PUSH-EVALUATION-ORDER:ITEM-FIRST}
+% 
+% %% 7.2.0 31
+% For example, in 
+% 
+% {\tt (setf \param{reference} \param{value})}
+% 
+% \param{value}
+% will be evaluated after all the \term{subforms} of \param{reference} because
+% \param{value} appears to the right of them.
+
+%% 7.2.0 32
+%The expansion of these operators must consist of code that follows these
+%rules or has the same effect as such code.  This is accomplished by
+%introducing temporary variables bound to the 
+%\issue{PUSH-EVALUATION-ORDER:ITEM-FIRST}
+%\term{subforms} of the macro call.
+%\endissue{PUSH-EVALUATION-ORDER:ITEM-FIRST}
+%As an optimization in the implementation,
+%temporary variables can be eliminated whenever
+%removing them has no effect on the semantics of the program.
+%For example, a constant need never be saved in a temporary variable.
+%A variable or any \term{form} that does not have side effects need not be
+%saved in a temporary variable if it can be proven that its value will
+%not change within the scope of the \term{place}.
+
+\issue{PUSH-EVALUATION-ORDER:ITEM-FIRST}
+\beginsubsubsection{Evaluation of Subforms to Places}
+\DefineSection{GenRefSubFormEval}
+
+The following rules apply to the \term{evaluation} of \term{subforms} in a
+\term{place}:
+
+\beginlist
+\itemitem{1.}
+The evaluation ordering of \term{subforms} within a \term{place}
+is determined by the order specified by the second value returned by
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\funref{get-setf-expansion}. 
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+For all \term{places} defined by this specification
+%!!! Table??
+(\eg \funref{getf}, \funref{ldb}, $\ldots$),
+this order of evaluation is left-to-right.
+\idxtext{order of evaluation}\idxtext{evaluation order}%
+%!!! Barmar: Does the next sentence say the same thing as the one which follows it
+%            (i.e., the first sentence in the next paragraph)??
+When a \term{place} is derived from a macro expansion,
+this rule is applied after the macro is expanded to find the appropriate \term{place}. 
+
+\term{Places} defined by using \macref{defmacro} or
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\macref{define-setf-expander}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+use the evaluation order defined by those definitions.
+For example, consider the following:
+
+\code
+ (defmacro wrong-order (x y) `(getf ,y ,x))
+\endcode
+
+This following \term{form} evaluates \f{place2} first and
+then \f{place1} because that is the order they are evaluated in
+the macro expansion:
+
+\code
+ (push value (wrong-order place1 place2))
+\endcode
+
+\itemitem{2.}
+\issue{JUN90-TRIVIAL-ISSUES:4}
+For the \term{macros} that manipulate \term{places} 
+  (\macref{push},
+   \macref{pushnew},
+   \macref{remf},
+   \macref{incf},
+   \macref{decf}, 
+   \macref{shiftf},
+   \macref{rotatef},
+   \macref{psetf},
+   \macref{setf},
+   \macref{pop}, and those defined by \macref{define-modify-macro})
+the \term{subforms} of the macro call are evaluated exactly once
+in left-to-right order, with the \term{subforms} of the \term{places}
+evaluated in the order specified in (1).
+\endissue{JUN90-TRIVIAL-ISSUES:4}
+
+\macref{push}, \macref{pushnew}, \macref{remf}, 
+\macref{incf}, \macref{decf}, \macref{shiftf}, \macref{rotatef}, 
+\macref{psetf}, \macref{pop} evaluate all \term{subforms} before modifying
+any of the \term{place} locations.
+\macref{setf} (in the case when \macref{setf} has more than two arguments) 
+performs its operation on each pair in sequence. For example, in 
+
+\code
+ (setf place1 value1 place2 value2 ...)
+\endcode
+the \term{subforms} of \f{place1} and \f{value1} are evaluated, the location
+specified by 
+\f{place1} is modified to contain the value returned by 
+\f{value1}, and
+then the rest of the \macref{setf} form is processed in a like manner.
+
+\itemitem{3.}
+For \macref{check-type}, \macref{ctypecase}, and \macref{ccase},
+\term{subforms} of the \term{place} are evaluated once as in (1),
+but might be evaluated again if the
+type check fails in the case of \macref{check-type} 
+or none of the cases hold in
+\macref{ctypecase} and \macref{ccase}.
+
+\itemitem{4.}
+For \macref{assert}, the order of evaluation of the generalized 
+references is not specified.\idxtext{order of evaluation}\idxtext{evaluation order}
+% Barmar: There's only one place in \macref{assert}.
+% Moon: Not true!
+
+\endlist
+Rules 2, 3 and 4 cover all \term{standardized} \term{macros} that manipulate \term{places}.
+
+\beginsubsubsubsection{Examples of Evaluation of Subforms to Places}
+
+\code
+ (let ((ref2 (list '())))
+   (push (progn (princ "1") 'ref-1)
+         (car (progn (princ "2") ref2)))) 
+\OUT 12
+\EV (REF1)
+
+ (let (x)
+    (push (setq x (list 'a))
+          (car (setq x (list 'b))))
+     x)
+\EV (((A) . B))
+\endcode
+
+\macref{push} first evaluates {\tt (setq x (list 'a)) \EV\ (a)},
+ then evaluates {\tt (setq x (list 'b)) \EV\ (b)},
+ then modifies the \term{car} of this latest value to be {\tt ((a) . b)}.
+
+\endsubsubsubsection%{Examples of Evaluation of Subforms to Places}
+
+\endsubsubsection%{Evaluation of Subforms to Places}
+\endissue{PUSH-EVALUATION-ORDER:ITEM-FIRST}
+
+%!!! Uses of "access", "accessing", etc. here are suspect. -kmp 18-Apr-91
+
+\beginsubsubsection{Setf Expansions}
+\DefineSection{SetfExpansions}
+
+%% 7.2.0 59
+Sometimes it is possible to avoid evaluating \term{subforms} of a 
+\term{place} multiple times or in the wrong order.  A
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\term{setf expansion}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+for a given access form can be expressed as an ordered collection of five \term{objects}:
+
+%!!! Andy Latto is concerned about whether "temporaries" mustn't or might
+%    be proclaimed special.  And if they must not, must an implementation check?
+%    Would some elaboration of what a "temporary" is here be of help? -kmp 5-Dec-91
+
+%% 7.2.0 60
+\beginlist
+%% 7.2.0 64
+\itemitem{\b{List of temporary variables}}
+
+a list of symbols naming temporary variables to be bound
+sequentially, as if by \specref{let*}, to \term{values} 
+resulting from value forms.
+     
+\itemitem{\b{List of value forms}}
+
+a list of forms (typically, \term{subforms} of the
+\term{place}) which when evaluated 
+yield the values to which the corresponding temporary 
+variables should be bound.
+
+%% 7.2.0 61
+%% 7.2.0 65
+\itemitem{\b{List of store variables}}
+
+a list of symbols naming temporary store variables which are
+to hold the new values that will be assigned to the
+\term{place}.
+
+%% 7.2.0 62
+\itemitem{\b{Storing form}}
+
+a form which can reference both the temporary and the store variables,
+and which changes the \term{value} of the \term{place}
+and guarantees to return as its values the values of the store variables,
+which are the correct values for \macref{setf} to return.
+
+%% 7.2.0 63
+\itemitem{\b{Accessing form}}
+
+a \term{form} which can reference the temporary variables,
+and which returns the \term{value} of the \term{place}.
+\endlist
+
+%% 7.2.0 66
+The value returned by the accessing form is
+affected by execution of the storing form, but either of these
+forms might be evaluated any number of times.
+
+
+%% 7.2.0 67
+%% Redundant with next paragraph.
+% The temporary variables and the store variables must be generated
+% names (see \funref{gensym} or \funref{gentemp}).
+
+It is possible
+to do more than one \macref{setf} in parallel via
+\macref{psetf}, \macref{shiftf}, and \macref{rotatef}.  
+Because of this, the 
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\term{setf expander}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+must produce new temporary 
+and store variable names every time.  For examples of how to do this,
+see \funref{gensym}.
+% and \funref{gentemp}.
+
+\issue{SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES}
+For each \term{standardized} accessor function \param{F},
+unless it is explicitly documented otherwise,
+it is \term{implementation-dependent} whether the ability to 
+use an \param{F} \term{form} as a \macref{setf} \term{place}
+is implemented by a \term{setf expander} or a \term{setf function}.
+Also, it follows from this that it is \term{implementation-dependent} 
+whether the name \f{(setf \param{F})} is \term{fbound}.
+\endissue{SETF-FUNCTIONS-AGAIN:MINIMAL-CHANGES}
+
+\beginsubsubsubsection{Examples of Setf Expansions}
+
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+Examples of the contents of the constituents of \term{setf expansions}
+follow.
+
+%% 7.2.0 69
+For a variable \param{x}:
+
+\showtwo{Sample Setf Expansion of a Variable}{
+\f{()}                     & ;list of temporary variables \cr
+\f{()}                     & ;list of value forms         \cr
+\f{(g0001)}                & ;list of store variables     \cr
+\f{(setq \param{x} g0001)} & ;storing form                \cr
+\param{x}                  & ;accessing form              \cr
+}
+
+%% 7.2.0 70
+For {\tt (car \param{exp})}:
+
+\showtwo{Sample Setf Expansion of a CAR Form}{
+\f{(g0002)}                            & ;list of temporary variables \cr
+\f{(\param{exp})}                      & ;list of value forms         \cr
+\f{(g0003)}                            & ;list of store variables     \cr
+\f{(progn (rplaca g0002 g0003) g0003)} & ;storing form                \cr
+\f{(car g0002)}                        & ;accessing form              \cr
+}
+
+%% 7.2.0 71
+For \f{(subseq \param{seq} \param{s} \param{e})}:
+
+\showtwo{Sample Setf Expansion of a SUBSEQ Form}{
+\f{(g0004 g0005 g0006)}               & ;list of temporary variables    \cr
+\f{(\param{seq} \param{s} \param{e})} & ;list of value forms            \cr
+\f{(g0007)}                           & ;list of store variables        \cr
+\f{(progn (replace g0004 g0007 :start1 g0005 :end1 g0006) g0007)} \span \cr
+				      & ;storing form                   \cr
+\f{(subseq g0004 g0005 g0006)}        & ; accessing form                \cr
+}
+
+In some cases, if a \term{subform} of a \term{place} is itself
+a \term{place}, it is necessary to expand the \term{subform}
+in order to compute some of the values in the expansion of the outer
+\term{place}.  For \f{(ldb \param{bs} (car \param{exp}))}:
+
+\showtwo{Sample Setf Expansion of a LDB Form}{
+\f{(g0001 g0002)}	              & ;list of temporary variables    \cr
+\f{(\param{bs} \param{exp})}	      & ;list of value forms            \cr
+\f{(g0003)}                           & ;list of store variables        \cr
+\f{(progn (rplaca g0002 (dpb g0003 g0001 (car g0002))) g0003)} \span    \cr
+				      & ;storing form                   \cr
+\f{(ldb g0001 (car g0002))}           & ; accessing form                \cr
+}
+
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+
+\endsubsubsubsection%{Examples of Setf Expansions}
+
+\endsubsubsection%{Setf Expansions}
+
+\endsubSection%{Overview of Places and Generalized Reference}
+
+\beginsubSection{Kinds of Places}
+\DefineSection{KindsOfPlaces}
+
+%% 7.2.0 7
+Several kinds of \term{places} are defined by \clisp; 
+this section enumerates them.
+This set can be extended by \term{implementations} and by \term{programmer code}.
+
+%% 7.2.0 8
+
+\beginsubsubsection{Variable Names as Places}
+
+The name of a \term{lexical variable} or \term{dynamic variable} 
+can be used as a \term{place}.
+
+\endsubsubsection%{Variable Names as Places}
+
+%% 7.2.0 9
+\beginsubsubsection{Function Call Forms as Places}
+\DefineSection{FnFormsAsGenRefs}
+
+A \term{function form} can be used as a \term{place} if it falls
+into one of the following categories:
+
+\beginlist
+
+\itemitem{\bull}
+A function call form whose first element is the name of
+any one of the functions in \thenextfigure.
+%% Barmar: Unnecessary as binding these symbols is disallowed.
+% \issue{FUNCTION-NAME:LARGE}
+% The function name must refer to the global function definition, 
+% rather than a locally defined \term{function}.
+% \endissue{FUNCTION-NAME:LARGE}
+
+%!!! CLASS-NAME and DOCUMENTATION maybe deserve their own table,
+%    since they are the only two defined by setf method.
+\issue{CONDITION-ACCESSORS-SETFABLE:NO}
+
+\editornote{KMP: Note that what are in some places still called `condition accessors'
+		 are deliberately omitted from this table, and are not labeled as
+		 accessors in their entries.  I have not yet had time to do a full
+	         search for these items and eliminate stray references to them as `accessors',
+		 which they are not, but I will do that at some point.}%!!!
+
+\issue{PATHNAME-LOGICAL:ADD}
+\issue{AREF-1D}
+\issue{FUNCTION-NAME:LARGE}
+%Merged BIT, SBIT, CHAR, SCHAR, and SUBSEQ from next table on advice of Moon and others.
+% -kmp 13-Feb-92
+% I added COMPILER-MACRO-FUNCTION, READTABLE-CASE, and SLOT-VALUE, 
+% which were also missing.  --sjl 5 Mar 92
+\displaythree{Functions that setf can be used with---1}{
+aref&cdadr&get\cr
+bit&cdar&gethash\cr
+caaaar&cddaar&logical-pathname-translations\cr
+caaadr&cddadr&macro-function\cr
+caaar&cddar&ninth\cr
+caadar&cdddar&nth\cr
+caaddr&cddddr&readtable-case\cr
+caadr&cdddr&rest\cr
+caar&cddr&row-major-aref\cr
+cadaar&cdr&sbit\cr
+cadadr&char&schar\cr
+cadar&class-name&second\cr
+caddar&compiler-macro-function&seventh\cr
+cadddr&documentation&sixth\cr
+caddr&eighth&slot-value\cr
+cadr&elt&subseq\cr
+car&fdefinition&svref\cr
+cdaaar&fifth&symbol-function\cr
+cdaadr&fill-pointer&symbol-plist\cr
+cdaar&find-class&symbol-value\cr
+cdadar&first&tenth\cr
+cdaddr&fourth&third\cr
+}
+\endissue{FUNCTION-NAME:LARGE}
+\endissue{AREF-1D}
+\endissue{PATHNAME-LOGICAL:ADD}
+\endissue{CONDITION-ACCESSORS-SETFABLE:NO}
+
+%% This text used to belong after the next table, which is now commented out. -kmp 13-Feb-92
+In the case of \funref{subseq}, the replacement value must be a \term{sequence}
+whose elements might be contained by the sequence argument to \funref{subseq},
+but does not have to be a \term{sequence} of the same \term{type} 
+%!!! Moon thinks this next is awkward.
+as the \term{sequence} of which the subsequence is specified.
+If the length of the replacement value does not equal the length of
+the subsequence to be replaced, then the shorter length determines
+the number of elements to be stored, as for \funref{replace}.
+
+  
+\itemitem{\bull}
+%% 7.2.0 10
+A function call form whose first element is the name of
+a selector function constructed by \macref{defstruct}.
+%% Barmar: Unnecessary as binding these symbols is disallowed.
+%% KMP: I'm not so sure in this case.
+\issue{FUNCTION-NAME:LARGE}
+The function name must refer to the global function definition,
+rather than a locally defined \term{function}.
+\endissue{FUNCTION-NAME:LARGE}
+
+%% Moon:
+%%  The distinction between this and the previous table is strange. After all,
+%%  fill-pointer, symbol-function, and class-name have type restrictions, too.
+%%  Also, the text above this table seems garbled.  I would merge these into previous
+%%  and delete the text.
+%% KMP: Done. (13-Feb-92)
+% 
+% \itemitem{\bull}
+% %% 7.2.0 11
+% A function call form whose first element is the name of
+% any one of the functions in \thenextfigure, 
+% provided that the new value
+% is of the specified type so that it can be used to
+% place in the specified ``location'' (which is in each of these cases
+% not truly a \term{place}).
+% %% Barmar: Unnecessary as binding these symbols is disallowed.
+% % \issue{FUNCTION-NAME:LARGE}
+% % The function name must refer to the global 
+% % function definition, rather than a locally defined \term{function}.
+% % \endissue{FUNCTION-NAME:LARGE}
+% 
+% \issue{CHARACTER-PROPOSAL:2-1-1}
+% \tablefigtwo{Functions that setf can be used with---n}{Function name}{Required type}{
+% \funref{bit}&\typeref{bit}\cr
+% \funref{sbit}&\typeref{bit}\cr
+% \funref{char}&\typeref{character}\cr
+% \funref{schar}&\typeref{character}\cr
+% \funref{subseq}&\typeref{sequence}\cr
+% }
+% \endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\itemitem{\bull}
+%% 7.2.0 12
+A function call form whose first element is the name of
+any one of the functions in \thenextfigure, 
+provided that the supplied argument
+to that function is in turn a \term{place} form;
+in this case the new \term{place} has stored back into it the
+result of applying the supplied ``update'' function.
+%% Moon thought this next was just confusing.
+%(which is in each of these cases not a true update function).
+%% Barmar: Unnecessary as binding these symbols is disallowed.
+% \issue{FUNCTION-NAME:LARGE}
+% The function name must refer to the global function 
+% definition, rather than a locally defined \term{function}.
+% \endissue{FUNCTION-NAME:LARGE}
+
+\issue{SETF-SUB-METHODS:DELAYED-ACCESS-STORES}                        
+\tablefigthree{Functions that setf can be used with---2}{Function name}{Argument that is a \param{place}}{Update function used}{
+\funref{ldb}        & second & \funref{dpb}                     \cr
+\funref{mask-field} & second & \funref{deposit-field}           \cr
+\funref{getf}       & first  &  \term{implementation-dependent} \cr
+}
+%% Moon thinks this is redundant.
+% The \param{place} forms listed in the above figure admit other
+% \param{places} as arguments; these are called sub-recursive \param{places}.
+During the \macref{setf} expansion of these \term{forms}, it is necessary to call 
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\funref{get-setf-expansion} 
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+in order to figure out how the inner, nested generalized variable must be treated.  
+ 
+The information from
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\funref{get-setf-expansion}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+is used as follows.
+\beginlist
+\issue{CHARACTER-PROPOSAL:2-1-1} 
+%References to CHAR-BIT omitted.
+\endissue{CHARACTER-PROPOSAL:2-1-1} 
+\itemitem{\funref{ldb}}
+ 
+In a form such as:
+       
+{\tt (setf (ldb \param{byte-spec} \param{place-form}) \param{value-form})}
+ 
+the place referred to by the \param{place-form} must always be both \term{read} 
+and \term{written};  note that the update is to the generalized variable 
+specified by \param{place-form}, not to any object \oftype{integer}.
+       
+Thus this \macref{setf} should generate code to do the following:
+ 
+\beginlist
+\itemitem{1.} Evaluate \param{byte-spec} (and bind it into a temporary variable).
+\itemitem{2.} Bind the temporary variables for \param{place-form}.
+\itemitem{3.} Evaluate \param{value-form}  (and bind 
+\issue{SETF-MULTIPLE-STORE-VARIABLES:ALLOW}
+its value or values into the store variable).
+%% Moon: Can only be ONE store variable here.
+% or variables
+\endissue{SETF-MULTIPLE-STORE-VARIABLES:ALLOW}
+\itemitem{4.} Do the \term{read} from \param{place-form}.
+\itemitem{5.} Do the \term{write} into \param{place-form} with 
+the given bits of the \term{integer}
+       fetched in step 4 replaced with the value from step 3.
+\endlist 
+    If the evaluation of \param{value-form} 
+in step 3 alters what is found in \param{place-form},
+such as setting different bits of \term{integer},
+    then the change of the bits denoted by 
+\param{byte-spec} is to that 
+    altered \term{integer}, 
+because step 4 is done after the \param{value-form}
+    evaluation.  Nevertheless, the 
+    evaluations required for \term{binding} 
+the temporary variables are done in steps 1 and 
+    2, and thus the expected left-to-right evaluation order is seen.
+For example:
+
+\code
+ (setq integer #x69) \EV #x69
+ (rotatef (ldb (byte 4 4) integer) 
+          (ldb (byte 4 0) integer))
+ integer \EV #x96
+;;; This example is trying to swap two independent bit fields 
+;;; in an integer.  Note that the generalized variable of 
+;;; interest here is just the (possibly local) program variable
+;;; integer.
+\endcode
+ 
+\itemitem{\funref{mask-field}}
+ 
+   This case is the same as \funref{ldb} in all essential aspects.
+ 
+\itemitem{\funref{getf}}
+ 
+    In a form such as:
+ 
+\f{(setf (getf \param{place-form} \param{ind-form}) \param{value-form})}
+ 
+    the place referred to by \param{place-form} must always be both \term{read}
+    and \term{written};  note that the update is to the generalized variable 
+    specified by \param{place-form}, not necessarily to the particular 
+\term{list}
+that is the property list in question.
+ 
+    Thus this \macref{setf} should generate code to do the following:
+\beginlist
+\itemitem{1.} 
+Bind the temporary variables for \param{place-form}.
+\itemitem{2.} 
+Evaluate \param{ind-form} (and bind it into a temporary variable).
+\itemitem{3.} 
+Evaluate \param{value-form} (and bind 
+\issue{SETF-MULTIPLE-STORE-VARIABLES:ALLOW}
+its value or values into the store variable).
+%%Moon: Can only be one store variable
+% or variables
+\endissue{SETF-MULTIPLE-STORE-VARIABLES:ALLOW}
+\itemitem{4.} 
+Do the \term{read} from \param{place-form}.
+\itemitem{5.} 
+Do the \term{write} into \param{place-form} with a possibly-new property list
+       obtained by combining the values from steps 2, 3, and 4.  
+(Note that the phrase ``possibly-new property list'' can mean that 
+    the former property list is somehow destructively re-used, or it can 
+    mean partial or full copying of it.  
+Since either copying or destructive re-use can occur, 
+the treatment of the resultant value for the 
+    possibly-new property list must proceed as if it were a different copy
+    needing to be stored back into the generalized variable.)
+\endlist 
+    If the evaluation of \param{value-form} 
+in step 3 alters what is found in
+\param{place-form}, such as setting a different named property in the list,
+    then the change of the property denoted by \param{ind-form} 
+is to that 
+    altered list, because step 4 is done after the 
+\param{value-form}
+    evaluation.  Nevertheless, the 
+    evaluations required for \term{binding} 
+the temporary variables  are done in steps 1 and 
+    2,  and thus the expected left-to-right evaluation order is seen.
+
+For example:
+
+\code
+ (setq s (setq r (list (list 'a 1 'b 2 'c 3)))) \EV ((a 1 b 2 c 3))
+ (setf (getf (car r) 'b) 
+       (progn (setq r nil) 6)) \EV 6
+ r \EV NIL
+ s \EV ((A 1 B 6 C 3))
+;;; Note that the (setq r nil) does not affect the actions of 
+;;; the SETF because the value of R had already been saved in 
+;;; a temporary variable as part of the step 1. Only the CAR
+;;; of this value will be retrieved, and subsequently modified 
+;;; after the value computation.
+\endcode
+ 
+\endlist
+\endlist
+ 
+\endissue{SETF-SUB-METHODS:DELAYED-ACCESS-STORES}                        
+
+\endsubsubsection%{Function Call Forms as Places}
+
+
+% This section added.  --sjl 4 Mar 92
+\issue{SETF-OF-VALUES:ADD}
+\beginsubsubsection{VALUES Forms as Places}
+\DefineSection{SETFofVALUES}
+
+A \funref{values} \term{form} can be used as a \term{place},
+provided that each of its \term{subforms} is also a \term{place} form.
+
+A form such as
+
+{\tt (setf (values \param{place-1} \dots \param{place-n}) \param{values-form})}
+
+does the following:
+
+\beginlist
+\itemitem{1.} The \term{subforms} of each nested \param{place} are evaluated
+in left-to-right order.
+\itemitem{2.} The \param{values-form} is evaluated, and the first store
+variable from each \param{place} is bound to its return values as if by 
+\macref{multiple-value-bind}.  
+\itemitem{3.} If the \term{setf expansion} for any \param{place} 
+involves more than one store variable, then the additional
+store variables are bound to \nil.
+\itemitem{4.} The storing forms for each \param{place} are evaluated in
+left-to-right order.
+\endlist
+
+The storing form in the \term{setf expansion} of \funref{values}
+returns as \term{multiple values}\meaning{2} the values of the store
+variables in step 2.  That is, the number of values returned is the
+same as the number of \term{place} forms.  This may be more or fewer
+values than are produced by the \param{values-form}.
+
+% There probably ought to be some examples here.
+
+\endsubsubsection%{VALUES Forms as Places}
+\endissue{SETF-OF-VALUES:ADD}
+
+
+\beginsubsubsection{THE Forms as Places}
+
+%% 7.2.0 13
+A \specref{the} \term{form} can be used as a \term{place},
+in which case the declaration is transferred to the \param{newvalue} form,
+and the resulting \macref{setf} is analyzed.  For example,
+
+\code
+ (setf (the integer (cadr x)) (+ y 3))
+\endcode
+is processed as if it were
+
+\code
+ (setf (cadr x) (the integer (+ y 3)))
+\endcode
+
+\endsubsubsection%{THE Forms as Places}
+     
+\issue{SETF-APPLY-EXPANSION:IGNORE-EXPANDER}
+\issue{SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS}
+\issue{JUN90-TRIVIAL-ISSUES:27}
+\beginsubsubsection{APPLY Forms as Places}
+\DefineSection{SETFofAPPLY}
+
+The following situations involving \macref{setf} of \funref{apply} must be supported:
+
+\beginlist
+\itemitem{\bull} \f{(setf (apply \#'aref \param{array}
+				        \starparam{subscript}
+					\param{more-subscripts})
+			  \param{new-element})}
+\itemitem{\bull} \f{(setf (apply \#'bit \param{array} 
+				       \starparam{subscript}
+				       \param{more-subscripts})
+			  \param{new-element})}
+\itemitem{\bull} \f{(setf (apply \#'sbit \param{array} 
+					\starparam{subscript}
+					\param{more-subscripts}) 
+			  \param{new-element})}
+\endlist
+
+In all three cases, the \term{element} of \param{array} designated
+by the concatenation of \param{subscripts} and \param{more-subscripts}
+(\ie the same \term{element} which would be \term{read} by the call to
+     \term{apply} if it were not part of a \macref{setf} \term{form})
+is changed to have the \term{value} given by \param{new-element}.
+\issue{FUNCTION-NAME:LARGE}
+For these usages, the function name (\funref{aref}, \funref{bit}, or \funref{sbit})
+must refer to the global function definition, rather than a locally defined
+\term{function}.
+\endissue{FUNCTION-NAME:LARGE}
+
+No other \term{standardized} \term{function} is required to be supported,
+but an \term{implementation} may define such support.
+An \term{implementation} may also define support 
+for \term{implementation-defined} \term{operators}.
+
+If a user-defined \term{function} is used in this context,
+the following equivalence is true, except that care is taken
+to preserve proper left-to-right evaluation of argument \term{subforms}:
+
+\code
+ (setf (apply \#'\param{name} \starparam{arg}) \param{val})
+ \EQ (apply \#'(setf \param{name}) \param{val} \starparam{arg})
+\endcode
+
+% Removed reference to (setf (apply #'name a1 a2 ...) (values v1 v2 ...)) as bogus.
+
+\endsubsubsection%{APPLY Forms as Places}
+\endissue{JUN90-TRIVIAL-ISSUES:27}
+\endissue{SETF-OF-APPLY:ONLY-AREF-AND-FRIENDS}
+\endissue{SETF-APPLY-EXPANSION:IGNORE-EXPANDER}
+
+\beginsubsubsection{Setf Expansions and Places}
+% \issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+% \itemitem{\macref{defsetf} or \macref{define-setf-expander} declarations}
+% \endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+
+%% 7.2.0 17
+Any \term{compound form} for which the \term{operator} has a
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\term{setf expander}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+defined can be used as a \term{place}.
+\issue{FUNCTION-NAME:LARGE}
+The 
+% function name that is the \param{access-fn} 
+% argument to \macref{defsetf} or 
+% \issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+% \macref{define-setf-expander}
+% \endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+%% previous phrase replaced by Moon as just "operator" -kmp 4-Dec-91
+\term{operator}
+must refer to the global function definition,
+rather than a locally defined \term{function} or \term{macro}.
+\endissue{FUNCTION-NAME:LARGE}
+
+\issue{FUNCTION-NAME:LARGE}
+
+\endsubsubsection%{Setf Expansions and Places}
+
+%% 7.2.0 16
+\beginsubsubsection{Macro Forms as Places}
+
+A \term{macro form} can be used as a \term{place}, 
+in which case \clisp\ expands the \term{macro form}
+\issue{FUNCTION-NAME:LARGE}
+as if by \funref{macroexpand-1}
+\endissue{FUNCTION-NAME:LARGE}
+and then uses the \term{macro expansion} in place of the original \term{place}.
+\issue{SETF-MACRO-EXPANSION:LAST}
+%This is true for GET-SETF-EXPANSION, too, but there's no obvious place to say that.
+% -kmp 5-Jun-91
+Such \term{macro expansion} is attempted only after exhausting all other possibilities
+other than expanding into a call to a function named \f{(setf \param{reader})}.
+\endissue{SETF-MACRO-EXPANSION:LAST}
+
+\endsubsubsection%{Macro Forms as Places}
+
+
+% I moved this section here from below.  --sjl 5 Mar 92
+\issue{SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM}
+\beginsubsubsection{Symbol Macros as Places}
+
+A reference to a \term{symbol} that has been \term{established} as a \term{symbol macro} 
+can be used as a \term{place}.  In this case,
+\macref{setf} expands the reference and then analyzes the resulting \term{form}.
+\endissue{SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM}
+
+\endsubsubsection%{Symbol Macros as Places}
+
+\beginsubsubsection{Other Compound Forms as Places}
+
+For any other \term{compound form} for which the \term{operator} is a
+\term{symbol} \param{f},
+the \macref{setf} \term{form} expands into a call 
+to the \term{function} named \f{(setf \param{f})}.
+The first \term{argument} in the newly constructed \term{function form}
+is \param{newvalue} and the
+     remaining \term{arguments} are the remaining \term{elements} of
+     \param{place}.
+This expansion occurs regardless of whether \param{f} or \f{(setf \param{f})}
+is defined as a \term{function} locally, globally, or not at all.
+For example,
+
+\f{(setf (\param{f} \param{arg1} \param{arg2} ...) \param{new-value})}
+
+expands into a form with the same effect and value as
+
+\code
+ (let ((#:temp-1 arg1)          ;force correct order of evaluation
+       (#:temp-2 arg2)
+       ...
+       (#:temp-0 \param{new-value}))
+   (funcall (function (setf \param{f})) #:temp-0 #:temp-1 #:temp-2...))
+\endcode
+
+A \term{function} named \f{(setf \param{f})} must return its first argument
+as its only value in order to preserve the semantics of \macref{setf}.
+
+\endissue{FUNCTION-NAME:LARGE}
+
+\endsubsubsection%{Other Compound Forms as Places}
+
+% I moved the symbol macro section up to be with the ordinary macro
+% section.  --sjl 5 Mar 92
+
+\endsubSection%{Kinds of Places}
+
+\beginsubSection{Treatment of Other Macros Based on SETF}
+
+\issue{READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES}
+
+For each of the ``read-modify-write'' \term{operators} in \thenextfigure, 
+and for any additional \term{macros} 
+defined by the \term{programmer} using \macref{define-modify-macro},
+an exception is made to the normal rule of left-to-right evaluation of arguments.
+Evaluation of \term{argument} \term{forms} occurs in left-to-right order,
+with the exception that for the \param{place} \term{argument}, the actual
+\term{read} of the ``old value'' from that \param{place} happens 
+after all of the \term{argument} \term{form} \term{evaluations}, 
+and just before a ``new value'' is computed and \term{written} back into the \param{place}.
+
+Specifically, each of these \term{operators} can be viewed as involving a
+\term{form} with the following general syntax:
+
+\code
+ (\term{operator} \starparam{preceding-form} \param{place} \starparam{following-form})
+\endcode
+
+The evaluation of each such \term{form} proceeds like this:
+
+\beginlist
+\itemitem{1.} \term{Evaluate} each of the \param{preceding-forms}, in left-to-right order.
+\itemitem{2.} \term{Evaluate} the \term{subforms} of the \param{place},
+ in the order specified by the second value of the \term{setf expansion}
+ for that \param{place}.
+\itemitem{3.} \term{Evaluate} each of the \param{following-forms}, in left-to-right order.
+\itemitem{4.} \term{Read} the old value from \param{place}.
+\itemitem{5.} Compute the new value.
+\itemitem{6.} Store the new value into \param{place}.
+\endlist
+
+\displaythree{Read-Modify-Write Macros}{
+decf&pop&pushnew\cr
+incf&push&remf\cr
+}
+
+\endissue{READ-MODIFY-WRITE-EVALUATION-ORDER:DELAYED-ACCESS-STORES}
+
+\endsubSection%{Treatment of Other Macros Based on SETF}

concept-pprint.tex

@@ -0,0 +1,573 @@
+% -*- Mode: TeX -*-
+
+\issue{PRETTY-PRINT-INTERFACE}
+
+\beginsubSection{Pretty Printer Concepts}
+
+The facilities provided by the \newterm{pretty printer} permit
+\term{programs} to redefine the way in which \term{code} is displayed, 
+and allow the full power of \term{pretty printing} to be applied 
+to complex combinations of data structures.
+
+Whether any given style of output is in fact ``pretty'' is inherently a
+somewhat subjective issue.  However, since the effect of the 
+\term{pretty printer} can be customized by \term{conforming programs},
+the necessary flexibility is provided for individual \term{programs}
+to achieve an arbitrary degree of aesthetic control.
+
+By providing direct access to the mechanisms within the pretty printer
+that make dynamic decisions about layout, the macros and functions
+\macref{pprint-logical-block}, \funref{pprint-newline}, and
+\funref{pprint-indent} make it possible to specify pretty printing
+layout rules as a part of any function that produces output.  They also
+make it very easy for the detection of circularity and sharing, and
+abbreviation based on length and nesting depth to be supported by the
+function.
+
+The \term{pretty printer} is driven entirely by dispatch based on
+\thevalueof{*print-pprint-dispatch*}.
+\Thefunction{set-pprint-dispatch} makes it possible
+for \term{conforming programs} to associate new pretty printing 
+functions with a \term{type}.
+
+\beginsubsubsection{Dynamic Control of the Arrangement of Output}
+\DefineSection{DynamicControlofOutput}
+ 
+The actions of the \term{pretty printer} when a piece of output is too
+large to fit in the space available can be precisely controlled.
+Three concepts underlie 
+the way these operations work---\newterm{logical blocks},
+			        \newterm{conditional newlines},
+			    and \newterm{sections}.
+Before proceeding further, it is important to define these terms.
+ 
+The first line of \thenextfigure\ shows a schematic piece of output.  Each of
+the characters in the output is represented by ``\f{-}''.  The positions of
+conditional newlines are indicated by digits.  The beginnings and ends of
+logical blocks are indicated by ``\f{<}'' and ``\f{>}'' respectively.
+ 
+The output as a whole is a logical block and the outermost section.  This
+section is indicated by the \f{0}'s on the second line of Figure 1.  Logical
+blocks nested within the output are specified by the macro
+\macref{pprint-logical-block}.  Conditional newline positions are specified 
+by calls to \funref{pprint-newline}.  Each conditional newline defines 
+two sections (one before it and one after it) and is associated with a 
+third (the section immediately containing it).
+ 
+The section after a conditional newline consists of: all the output up to,
+but not including, (a) the next conditional newline immediately contained
+in the same logical block; or if (a) is not applicable, (b) the next
+newline that is at a lesser level of nesting in logical blocks; or if (b)
+is not applicable, (c) the end of the output.
+ 
+The section before a conditional newline consists of: all the output back
+to, but not including, (a) the previous conditional newline that is
+immediately contained in the same logical block; or if (a) is not
+applicable, (b) the beginning of the immediately containing logical block.
+The last four lines in Figure 1 indicate the sections before and after the
+four conditional newlines.
+ 
+The section immediately containing a conditional newline is the shortest
+section that contains the conditional newline in question.  In \thenextfigure,
+the first conditional newline is immediately contained in the section
+marked with \f{0}'s, the second and third conditional newlines are immediately
+contained in the section before the fourth conditional newline, and the
+fourth conditional newline is immediately contained in the section after
+the first conditional newline.
+ 
+\code
+ <-1---<--<--2---3->--4-->->
+ 000000000000000000000000000
+ 11 111111111111111111111111
+           22 222
+              333 3333
+        44444444444444 44444
+\endcode
+\simplecaption{Example of Logical Blocks, Conditional Newlines, and Sections}
+ 
+Whenever possible, the pretty printer displays the entire contents of a
+section on a single line.  However, if the section is too long to fit in
+the space available, line breaks are inserted at conditional newline
+positions within the section.
+
+\endsubsubsection%{Dynamic Control of the Arrangement of Output}
+
+\beginsubsubsection{Format Directive Interface}
+
+The primary interface to operations for dynamically determining the
+arrangement of output is provided through the functions and macros of the
+pretty printer.  \Thenextfigure\ shows the defined names related to \term{pretty printing}.
+
+\displaythree{Defined names related to pretty printing.}{
+*print-lines*&pprint-dispatch&pprint-pop\cr
+*print-miser-width*&pprint-exit-if-list-exhausted&pprint-tab\cr
+*print-pprint-dispatch*&pprint-fill&pprint-tabular\cr
+*print-right-margin*&pprint-indent&set-pprint-dispatch\cr
+copy-pprint-dispatch&pprint-linear&write\cr
+format&pprint-logical-block&\cr
+formatter&pprint-newline&\cr
+}
+
+\Thenextfigure\ identifies a set of \term{format directives} which serve
+as an alternate interface to the same pretty printing operations in a 
+more textually compact form.
+
+%%Only of interest historically. -kmp
+%In addition, it permits one would have to abandon the use of \funref{format}
+%when interacting with the pretty printer.
+ 
+\displaythree{Format directives related to Pretty Printing}{
+\formatOp{I}&\formatOp{W}&\formatOp{<...~:>}\cr
+\formatOp{:T}&\formatOp{/.../}&\formatOp{_}\cr
+}
+
+\endsubsubsection%{Format Directive Interface}
+
+\beginsubsubsection{Compiling Format Strings}
+\DefineSection{CompilingFormatStrings}
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+A \term{format string} is essentially a program in a special-purpose language
+that performs printing, and that is interpreted by \thefunction{format}.
+\Themacro{formatter} provides the efficiency of using a \term{compiled function} 
+to do that same printing but without losing the textual compactness of \term{format strings}.
+
+A \newterm{format control} is either a \term{format string} or a \term{function}
+that was returned by the \themacro{formatter}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\endsubsubsection%{Compiling Format Strings}
+
+\beginsubsubsection{Pretty Print Dispatch Tables}
+\DefineSection{PPrintDispatchTables}
+ 
+\issue{GENERALIZE-PRETTY-PRINTER:UNIFY}
+
+%KAB: Are all type specifiers really valid?
+%Waters: Yes.
+%KMP: Actually, CONS was not originally valid, but has been added due to a cleanup.
+A \newterm{pprint dispatch table} is a mapping from keys to pairs of values.  
+Each key is a \term{type specifier}.  
+The values associated with a key are
+     a ``function'' (specifically, a \term{function designator} or \nil)
+%% Per X3J13. -kmp 05-Oct-93
+% and a ``numerical priorities'' (specifically, a \term{real}).
+ and a ``numerical priority'' (specifically, a \term{real}).
+Basic insertion and retrieval is done based on the keys with the equality
+of keys being tested by \funref{equal}.
+
+When \varref{*print-pretty*} is \term{true}, 
+the \newterm{current pprint dispatch table} (in \varref{*print-pprint-dispatch*})
+controls how \term{objects} are printed.
+The information in this table takes precedence over
+all other mechanisms for specifying how to print \term{objects}.
+In particular, it 
+%overrides
+has priority over
+user-defined \funref{print-object} \term{methods} 
+\issue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+%and print functions for \term{structures} 
+\endissue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+because the \term{current pprint dispatch table} is consulted first.
+
+%%Just trying to simplify wording to fit context. -kmp 27-Aug-93
+%The function to use when \term{pretty printing} an \term{object} is chosen 
+The function is chosen from the \term{current pprint dispatch table}
+by finding the highest priority function 
+%% Again, this should follow from context.
+%from the \term{current pprint dispatch table} 
+that is associated with a \term{type specifier} that matches the \term{object};
+%KAB: What if there are several matches with equal priority?
+%Waters: It's not well-defined.
+%KMP: I've added this text to clarify that point:
+if there is more than one such function, 
+it is \term{implementation-dependent} which is used.
+
+However, if there is no 
+%% better parallel construction. -kmp 27-Aug-93
+%specification
+information in the table
+about how to \term{pretty print} a particular kind of \term{object}, 
+% it is then printed using the standard mechanisms as if
+% \varref{*print-pretty*} were \term{false}.
+a \term{function} is invoked which uses \funref{print-object} to print the \term{object}.
+The value of \varref{*print-pretty*} is still \term{true} 
+when this function is \term{called},
+and individual methods for \funref{print-object} might still elect to
+produce output in a special format conditional on \thevalueof{*print-pretty*}.
+\endissue{GENERALIZE-PRETTY-PRINTER:UNIFY}
+
+\endsubsubsection%{Pretty Print Dispatch Tables}
+
+\beginsubsubsection{Pretty Printer Margins}
+
+A primary goal of pretty printing is to keep the output between a pair of
+margins. 
+%This used to say:
+%  The left margin is set at the column where the output begins.
+%KMP asked:
+%  Does this mean that
+%   a. the cursor is moved 
+%   b. the position at the cursor is assumed to be zero
+%   c. that the position at the cursor becomes the new left margin?
+%Waters replied (c), so the following new sentence was made:
+The column where the output begins is taken as the left margin.
+%This used to say:
+%  If this cannot be determined, the left margin is set to zero.
+%KMP asked:
+%  Does this mean ``assumed to be''
+%Waters replied yes, so the following new sentence was made:
+If the current column cannot be determined at the time output begins,
+the left margin is assumed to be zero.
+The right margin is controlled by \varref{*print-right-margin*}.
+
+\endsubsubsection%{Pretty Printer Margins}
+
+\endsubSection%{Pretty Printer Concepts}
+
+\beginsubSection{Examples of using the Pretty Printer}
+\DefineSection{PrettyPrinterExamples}
+
+As an example of the interaction of logical blocks, conditional newlines,
+and indentation, consider the function \f{simple-pprint-defun} below.  This
+function prints out lists whose \term{cars} are \macref{defun} in the 
+standard way assuming that the list has exactly length \f{4}.
+ 
+\code
+(defun simple-pprint-defun (*standard-output* list)
+  (pprint-logical-block (*standard-output* list :prefix "(" :suffix ")")
+    (write (first list))
+    (write-char #\\Space)
+    (pprint-newline :miser)
+    (pprint-indent :current 0)
+    (write (second list))
+    (write-char #\\Space)
+    (pprint-newline :fill)
+    (write (third list))
+    (pprint-indent :block 1)
+    (write-char #\\Space)
+    (pprint-newline :linear)
+    (write (fourth list))))
+\endcode
+
+Suppose that one evaluates the following:
+
+\code
+(simple-pprint-defun *standard-output* '(defun prod (x y) (* x y)))
+\endcode
+ 
+If the line width available is greater than or equal to \f{26}, then all of the
+output appears on one line.  If the line width available is reduced to \f{25},
+a line break is inserted at the 
+linear-style conditional newline\idxtext{linear-style conditional newline}
+before the
+\term{expression} \f{(* x y)}, producing the output shown.  The
+\f{(pprint-indent :block 1)} causes \f{(* x y)} to be printed at a relative
+indentation of \f{1} in the logical block.
+ 
+\code
+ (DEFUN PROD (X Y) 
+   (* X Y))
+\endcode 
+
+If the line width available is \f{15}, a line break is also inserted at the
+fill style conditional newline before the argument list.  The call on
+\f{(pprint-indent :current 0)} causes the argument list to line up under the
+function name.
+ 
+\code
+(DEFUN PROD
+       (X Y)
+  (* X Y))
+\endcode
+ 
+If \varref{*print-miser-width*} were greater than or equal to 14, the example 
+output above would have been as follows, because all indentation changes 
+are ignored in miser mode and line breaks are inserted at 
+miser-style conditional newlines.\idxtext{miser-style conditional newline}
+ 
+\code
+ (DEFUN
+  PROD
+  (X Y)
+  (* X Y))
+\endcode 
+
+As an example of a per-line prefix, consider that evaluating the following
+produces the output shown with a line width of \f{20} and
+\varref{*print-miser-width*} of \nil.
+ 
+\code
+ (pprint-logical-block (*standard-output* nil :per-line-prefix ";;; ")
+   (simple-pprint-defun *standard-output* '(defun prod (x y) (* x y))))
+ 
+ ;;; (DEFUN PROD
+ ;;;        (X Y)
+ ;;;   (* X Y))
+\endcode
+ 
+As a more complex (and realistic) example, consider the function \f{pprint-let}
+below.  This specifies how to print a \specref{let} \term{form} in the traditional
+style.  It is more complex than the example above, because it has to deal with
+nested structure.  Also, unlike the example above it contains complete code to 
+readably print any possible list that begins with the \term{symbol} \specref{let}.
+The outermost \macref{pprint-logical-block} \term{form} handles the printing of
+the input list as a whole and specifies that parentheses should be printed in the
+output.  The second \macref{pprint-logical-block} \term{form} handles the list 
+of binding pairs.  Each pair in the list is itself printed by the innermost
+\macref{pprint-logical-block}.  (A \macref{loop} \term{form} is used instead of
+merely decomposing the pair into two \term{objects} so that readable output will
+be produced no matter whether the list corresponding to the pair has one element,
+two elements, or (being malformed) has more than two elements.)   
+A space and a 
+fill-style conditional newline\idxtext{fill-style conditional newline}
+are placed after
+each pair except the last.  The loop at the end of the topmost
+\macref{pprint-logical-block} \term{form} prints out the forms in the body
+of the \specref{let} \term{form} separated by spaces and 
+linear-style conditional newlines.
+ 
+\code
+ (defun pprint-let (*standard-output* list)
+   (pprint-logical-block (nil list :prefix "(" :suffix ")")
+     (write (pprint-pop))
+     (pprint-exit-if-list-exhausted)
+     (write-char #\\Space)
+     (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
+       (pprint-exit-if-list-exhausted)
+       (loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
+               (pprint-exit-if-list-exhausted)
+               (loop (write (pprint-pop))
+                     (pprint-exit-if-list-exhausted)
+                     (write-char #\\Space)
+                     (pprint-newline :linear)))
+             (pprint-exit-if-list-exhausted)
+             (write-char #\\Space)
+             (pprint-newline :fill)))
+     (pprint-indent :block 1)
+     (loop (pprint-exit-if-list-exhausted)
+           (write-char #\\Space)
+           (pprint-newline :linear)
+           (write (pprint-pop)))))
+\endcode
+ 
+Suppose that one evaluates the following with \varref{*print-level*} being 4, 
+and \varref{*print-circle*} being \term{true}.
+
+\code
+ (pprint-let *standard-output*
+             '#1=(let (x (*print-length* (f (g 3))) 
+                       (z . 2) (k (car y)))
+                   (setq x (sqrt z)) #1#))
+\endcode
+ 
+If the line length is greater than or equal to \f{77}, the output produced
+appears on one line.  However, if the line length is \f{76}, line breaks are
+inserted at the linear-style conditional newlines separating the forms in
+the body and the output below is produced.  Note that, the degenerate
+binding pair \f{x} is printed readably even though it fails to be a list; a
+depth abbreviation marker is printed in place of \f{(g 3)}; the binding pair
+\f{(z . 2)} is printed readably even though it is not a proper list; and
+appropriate circularity markers are printed.
+
+\code
+ #1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y))) 
+      (SETQ X (SQRT Z))
+      #1#)
+\endcode
+
+If the line length is reduced to \f{35}, a line break is inserted at one of the
+fill-style conditional newlines separating the binding pairs.
+ 
+\code
+ #1=(LET (X (*PRINT-PRETTY* (F #))
+          (Z . 2) (K (CAR Y)))
+      (SETQ X (SQRT Z))
+      #1#)
+\endcode
+ 
+Suppose that the line length is further reduced to \f{22} and \varref{*print-length*} is
+set to \f{3}. In this situation, line breaks are inserted after both the first
+and second binding pairs.  In addition, the second binding pair is itself
+broken across two lines.  Clause (b) of the description of fill-style
+conditional newlines (\seefun{pprint-newline}) 
+prevents the binding pair \f{(z . 2)} from being printed
+at the end of the third line.  Note that the length abbreviation hides the
+circularity from view and therefore the printing of circularity markers
+disappears.
+ 
+\code
+ (LET (X
+       (*PRINT-LENGTH*
+        (F #))
+       (Z . 2) ...)
+   (SETQ X (SQRT Z))
+   ...)
+\endcode
+ 
+The next function prints a vector using ``\f{\#(...)}'' notation.
+      
+\code
+(defun pprint-vector (*standard-output* v)
+  (pprint-logical-block (nil nil :prefix "#(" :suffix ")")
+    (let ((end (length v)) (i 0))
+      (when (plusp end)
+        (loop (pprint-pop)
+              (write (aref v i))
+              (if (= (incf i) end) (return nil))
+              (write-char #\\Space)
+              (pprint-newline :fill))))))
+\endcode
+
+Evaluating the following with a line length of 15 produces the output shown.
+ 
+\code
+ (pprint-vector *standard-output* '#(12 34 567 8 9012 34 567 89 0 1 23))
+ 
+ #(12 34 567 8 
+   9012 34 567 
+   89 0 1 23)
+\endcode
+
+As examples of the convenience of specifying pretty printing with 
+\term{format strings}, consider that the functions \f{simple-pprint-defun}
+and \f{pprint-let} used as examples above can be compactly defined as follows.
+(The function \f{pprint-vector} cannot be defined using \funref{format}
+because the data structure it traverses is not a list.)
+ 
+\code
+(defun simple-pprint-defun (*standard-output* list)
+  (format T "~:<~W ~@_~:I~W ~:_~W~1I ~_~W~:>" list))
+
+(defun pprint-let (*standard-output* list)
+  (format T "~:<~W~{\hat}~:<~@\{~:<~@\{~W~{\hat}~_~\}~:>~{\hat}~:_~\}~:>~1I~@\{~{\hat}~_~W~\}~:>" list)) 
+\endcode
+
+In the following example, the first \term{form} restores
+\varref{*print-pprint-dispatch*} to the equivalent of its initial value.
+The next two forms then set up a special way to pretty print ratios.
+Note that the more specific \term{type specifier} has to be associated
+with a higher priority.
+ 
+\code
+ (setq *print-pprint-dispatch* (copy-pprint-dispatch nil))
+
+ (set-pprint-dispatch 'ratio
+   #'(lambda (s obj)
+       (format s "#.(/ ~W ~W)" 
+                 (numerator obj) (denominator obj))))
+
+ (set-pprint-dispatch '(and ratio (satisfies minusp))
+   #'(lambda (s obj)
+       (format s "#.(- (/ ~W ~W))" 
+               (- (numerator obj)) (denominator obj)))
+   5)
+
+ (pprint '(1/3 -2/3))
+ (#.(/ 1 3) \#.(- (/ 2 3)))
+\endcode
+
+The following two \term{forms} illustrate the definition of 
+pretty printing functions for types of \term{code}.  The first
+\term{form} illustrates how to specify the traditional method 
+for printing quoted objects using \term{single-quote}.  Note
+the care taken to ensure that data lists that happen to begin
+with \misc{quote} will be printed readably.  The second form 
+specifies that lists beginning with the symbol \f{my-let}
+should print the same way that lists beginning with \specref{let}
+print when the initial \term{pprint dispatch table} is in effect.
+ 
+\code
+ (set-pprint-dispatch '(cons (member quote)) () 
+   #'(lambda (s list)
+       (if (and (consp (cdr list)) (null (cddr list)))
+          (funcall (formatter "'~W") s (cadr list))
+          (pprint-fill s list))))
+ 
+ (set-pprint-dispatch '(cons (member my-let)) 
+                      (pprint-dispatch '(let) nil))
+\endcode
+ 
+The next example specifies a default method for printing lists that do not
+correspond to function calls.  Note that the functions \funref{pprint-linear},
+\funref{pprint-fill}, and \funref{pprint-tabular} are all defined with
+optional \param{colon-p} and \param{at-sign-p} arguments so that they can 
+be used as \funref{pprint dispatch functions} as well as \formatOp{/.../} 
+functions.
+
+\code
+ (set-pprint-dispatch '(cons (not (and symbol (satisfies fboundp))))
+                      #'pprint-fill -5)
+ 
+ ;; Assume a line length of 9
+ (pprint '(0 b c d e f g h i j k))
+ (0 b c d
+  e f g h
+  i j k)
+\endcode 
+
+This final example shows how to define a pretty printing function for a
+user defined data structure.
+ 
+\code
+ (defstruct family mom kids)
+ 
+ (set-pprint-dispatch 'family
+   #'(lambda (s f)
+       (funcall (formatter "~@<#<~;~W and ~2I~_~/pprint-fill/~;>~:>")
+               s (family-mom f) (family-kids f))))
+\endcode
+ 
+The pretty printing function for the structure \f{family} specifies how to
+adjust the layout of the output so that it can fit aesthetically into
+a variety of line widths.  In addition, it obeys 
+the printer control variables \varref{*print-level*},
+\varref{*print-length*}, \varref{*print-lines*},
+\varref{*print-circle*}
+%% There's no such var.  (Flanagan pointed this out in private mail.) -kmp 26-Jul-93
+%, \varref{*print-shared*}
+and \varref{*print-escape*},
+and can tolerate several different kinds of malformity in the data structure.
+The output below shows what is printed out with a right margin of \f{25},
+\varref{*print-pretty*} being \term{true}, \varref{*print-escape*} being \term{false},
+and a malformed \f{kids} list.
+ 
+\code
+ (write (list 'principal-family
+              (make-family :mom "Lucy"
+                           :kids '("Mark" "Bob" . "Dan")))
+        :right-margin 25 :pretty T :escape nil :miser-width nil)
+ (PRINCIPAL-FAMILY
+  #<Lucy and
+      Mark Bob . Dan>)
+\endcode
+  
+\issue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+Note that a pretty printing function for a structure is different from
+%the structure's print function.
+the structure's \funref{print-object} \term{method}.
+While
+%print functions
+\funref{print-object} \term{methods}
+are permanently associated with a structure,
+pretty printing functions are stored in 
+\term{pprint dispatch tables} and can be rapidly changed to reflect 
+different printing needs.  If there is no pretty printing function for 
+a structure in the current \term{pprint dispatch table},
+% the print function (if any) 
+its \funref{print-object} \term{method}
+is used instead.
+\endissue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+
+\endsubSection%{Examples of using the Pretty Printer}
+
+\beginsubsection{Notes about the Pretty Printer's Background}
+
+For a background reference to the abstract concepts detailed in this
+section, see \XPPaper.  The details of that paper are not binding on
+this document, but may be helpful in establishing a conceptual basis for
+understanding this material.
+
+\endsubsection%{Notes about the Pretty Printer's Background}
+
+\endissue{PRETTY-PRINT-INTERFACE}

concept-print.tex

@@ -0,0 +1,1085 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Overview of The Lisp Printer}
+
+%% 22.1.0 1
+\clisp\ provides a representation of most \term{objects} in the form 
+of printed text called the printed representation.
+Functions such as \funref{print} take an \term{object} 
+and send the characters of its printed representation to a \term{stream}. 
+The collection of routines that does this is known as the (\clisp) printer.  
+
+%% 22.1.0 2
+Reading a printed representation 
+%Added qualifier, since clearly this is just rule of thumb.
+%e.g., Waters complained that this is mostly only true for `simple things'
+typically
+produces an \term{object} that is \funref{equal} to the
+originally printed \term{object}.
+
+\beginsubsubsection{Multiple Possible Textual Representations}
+
+%% 22.1.0 3
+Most \term{objects} have more than one possible textual representation.
+For example, the positive \term{integer} with a magnitude of twenty-seven
+can be textually expressed in any of these ways:
+
+\code
+ 27    27.    #o33    #x1B    #b11011    #.(* 3 3 3)    81/3
+\endcode
+
+A list containing the two symbols \f{A} and \f{B} can also be textually
+expressed in a variety of ways:
+
+\code
+ (A B)    (a b)    (  a  b )    (\\A |B|) 
+(|\\A|
+  B
+)
+\endcode
+
+In general,
+\issue{PRINTER-WHITESPACE:JUST-ONE-SPACE}
+%% Added extra constraint about reader to make it clear that we aren't 
+%% trying to override other printer behavior specified elsewhere.
+%% -kmp 22-Aug-93
+from the point of view of the \term{Lisp reader},
+\endissue{PRINTER-WHITESPACE:JUST-ONE-SPACE}
+wherever \term{whitespace} is permissible in a textual representation,
+any number of \term{spaces} and \term{newlines} can appear in \term{standard syntax}.
+
+%% 22.1.0 4
+When a function such as \funref{print} produces a printed representation,
+it must choose 
+%% It's not totally arbitrary! -kmp 22-Aug-93
+%arbitrarily
+from among many possible textual representations.
+In most cases, it chooses a 
+%Waters thought this meant human-readable, so I added the qualifier "program",
+%and then some exposition which follows here. -kmp 11-Feb-91
+program readable representation,
+but in certain cases it might use a more compact notation that is not 
+program-readable.
+
+A number of option variables, called
+\newtermidx{printer control variables}{printer control variable},
+are provided to permit control of individual aspects of the 
+printed representation of \term{objects}.
+\Thenextfigure\ shows the \term{standardized} \term{printer control variables};
+there might also be \term{implementation-defined} \term{printer control variables}.
+
+\DefineFigure{StdPrinterControlVars}
+\displaythree{Standardized Printer Control Variables}{
+*print-array*&*print-gensym*&*print-pprint-dispatch*\cr
+*print-base*&*print-length*&*print-pretty*\cr
+*print-case*&*print-level*&*print-radix*\cr
+*print-circle*&*print-lines*&*print-readably*\cr
+*print-escape*&*print-miser-width*&*print-right-margin*\cr
+}
+
+In addition to the \term{printer control variables}, 
+the following additional \term{defined names} 
+relate to or affect the behavior of the \term{Lisp printer}:
+
+\displaythree{Additional Influences on the Lisp printer.}{
+*package*&*read-eval*&readtable-case\cr
+*read-default-float-format*&*readtable*&\cr
+}
+
+\beginsubsubsubsection{Printer Escaping}
+
+\Thevariable{*print-escape*} controls whether the \term{Lisp printer}
+tries to produce notations such as escape characters and package prefixes.
+
+\Thevariable{*print-readably*} can be used to override
+many of the individual aspects controlled by the other 
+\term{printer control variables} when program-readable output
+is especially important.
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+One of the many effects of making \thevalueof{*print-readably*} be \term{true}
+is that the \term{Lisp printer} behaves as if \varref{*print-escape*} were also \term{true}.
+For notational convenience, we say that 
+if the value of either \varref{*print-readably*} or \varref{*print-escape*} is \term{true}, 
+then \newterm{printer escaping} is ``enabled'';
+and we say that
+if the values of both \varref{*print-readably*} and \varref{*print-escape*} are \term{false}, 
+then \term{printer escaping} is ``disabled''.
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+
+\endsubsubsubsection%{Printer Escaping}
+
+\endsubsubsection%{Multiple Possible Textual Representations}
+
+\endsubsection%{Overview of The Lisp Printer}
+
+\beginsubsection{Printer Dispatching}
+\DefineSection{PrinterDispatch}
+
+\issue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+% The \term{Lisp printer} makes its determination of how to print an
+% \term{object} as follows:
+% 
+% If \thevalueof{*print-pretty*} is \term{true}:
+% 
+% \beginlist 
+%   \item{} Printing is controlled by the \term{pprint dispatch table}
+%           contained in the variable \varref{*print-pprint-dispatch*};
+%           \seesection\PPrintDispatchTables.
+% \endlist
+% 
+% Otherwise (if \thevalueof{*print-pretty*} is \term{false}):
+% 
+% \beginlist
+% \item{} If the \term{object} is a \term{structure} for which a
+%         \kwd{print-function} option is in effect (either directly or by inheritance),
+%         that function is used; \seefun{defstruct}.
+% 
+% \item{} Otherwise (if the \term{object} is not a \term{structure} or
+% 	if it is a \term{structure} but has no \kwd{print-function} option in effect),
+% 	its \funref{print-object} method is used; \seesection\DefaultPrintObjMeths.
+% \endlist
+
+The \term{Lisp printer} makes its determination of how to print an
+\term{object} as follows:
+
+If \thevalueof{*print-pretty*} is \term{true}, 
+printing is controlled by the \term{current pprint dispatch table};
+%contained in the variable \varref{*print-pprint-dispatch*};
+\seesection\PPrintDispatchTables.
+
+Otherwise (if \thevalueof{*print-pretty*} is \term{false}),
+the object's \funref{print-object} method is used;
+\seesection\DefaultPrintObjMeths.
+\endissue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+
+\endsubsection%{Printer Dispatching}
+
+\beginsubsection{Default Print-Object Methods}
+\DefineSection{DefaultPrintObjMeths}
+
+%% 22.1.6 3
+% How an expression is printed depends on its \term{type},
+% as described in the following sections.
+This section describes the default behavior of 
+\funref{print-object} methods for the \term{standardized} \term{types}.
+
+\beginsubsubsection{Printing Numbers}
+
+\beginsubsubsubsection{Printing Integers}
+\DefineSection{PrintingIntegers}
+%% 22.1.6 4
+
+\term{Integers} are printed in the radix specified by the \term{current output base}
+in positional notation, most significant digit first.
+If appropriate, a radix specifier can be printed; see \varref{*print-radix*}.
+If an \term{integer} is negative, a minus sign is printed and then the
+absolute value of the \term{integer} is printed.
+The \term{integer} zero is represented
+by the single digit \f{0} and never has a sign.
+A decimal point might be printed, 
+depending on \thevalueof{*print-radix*}.
+
+For related information about the syntax of an \term{integer},
+\seesection\SyntaxOfIntegers.
+
+\endsubsubsubsection%{Printing Integers}
+\beginsubsubsubsection{Printing Ratios}
+\DefineSection{PrintingRatios}\idxref{ratio}
+%% 22.1.6 5
+
+\term{Ratios} are printed as follows:
+the absolute value of the numerator is printed, as for an \term{integer};
+then a \f{/}; then the denominator.  The numerator and denominator are
+both printed in the radix specified by the \term{current output base}; 
+they are obtained as if by
+\funref{numerator} and \funref{denominator}, and so \term{ratios}
+are printed in reduced form (lowest terms).
+If appropriate, a radix specifier can be printed; see 
+\varref{*print-radix*}.
+If the ratio is negative, a minus sign is printed before the numerator.
+
+For related information about the syntax of a \term{ratio},
+\seesection\SyntaxOfRatios.
+
+\endsubsubsubsection%{Printing Ratios}
+\beginsubsubsubsection{Printing Floats}
+\DefineSection{PrintingFloats}\idxref{float}
+%% 22.1.6 6
+
+If the magnitude of the \term{float} is either zero or between $10^{-3}$ (inclusive)
+and $10^7$ (exclusive), it is printed as the integer part of the number,
+then a decimal point,
+followed by the fractional part of the number;
+there is always at least one
+digit on each side of the decimal point.    
+If the sign of the number
+(as determined by \funref{float-sign})
+is negative, then a minus sign is printed before the number.
+If the format of the number
+does not match that specified by
+\varref{*read-default-float-format*}, then the \term{exponent marker} for
+that format and the digit \f{0} are also printed.
+For example, the base of the natural logarithms as a \term{short float}
+might be printed as \f{2.71828S0}.
+
+%% 22.1.6 7
+For non-zero magnitudes outside of the range $10^{-3}$ to $10^7$,
+a \term{float} is printed in computerized scientific notation.
+The representation of the number is scaled to be between
+1 (inclusive) and 10 (exclusive) and then printed, with one digit
+before the decimal point and at least one digit after the decimal point.
+Next the \term{exponent marker} for the format is printed,
+except that
+if the format of the number matches that specified by 
+\varref{*read-default-float-format*}, then the \term{exponent marker} \f{E}
+is used.
+Finally, the power of ten by which the fraction must be multiplied
+to equal the original number is printed as a decimal integer.
+For example, Avogadro's number as a \term{short float} 
+is printed as \f{6.02S23}.
+
+For related information about the syntax of a \term{float},
+\seesection\SyntaxOfFloats.
+
+\endsubsubsubsection%{Printing Floats}
+\beginsubsubsubsection{Printing Complexes}
+\DefineSection{PrintingComplexes}\idxref{complex}
+%% 22.1.6 8
+
+A \term{complex} is printed as \f{\#C}, an open parenthesis,
+the printed representation of its real part, a space,
+the printed representation of its imaginary part, and finally
+a close parenthesis.
+
+For related information about the syntax of a \term{complex},
+\seesection\SyntaxOfComplexes\ and \secref\SharpsignC.
+
+\endsubsubsubsection%{Printing Complexes}
+\beginsubsubsubsection{Note about Printing Numbers}
+
+The printed representation of a number must not contain \term{escape} \term{characters};
+\seesection\EscCharsAndPotentialNums.
+
+\endsubsubsubsection%{Note about Printing Numbers}
+\endsubsubsection%{Printing Numbers}
+\beginsubsubsection{Printing Characters}
+\DefineSection{PrintingCharacters}
+%% 22.1.6 9
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%When \varref{*print-escape*} is \term{false},
+When \term{printer escaping} is disabled,
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+a \term{character} prints as itself;
+it is sent directly to the output \term{stream}.
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%When \varref{*print-escape*} is \term{true},
+When \term{printer escaping} is enabled,
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+then \f{\#\\} syntax is used.
+
+%% 22.1.4 16
+%% Some wording clarifications here per Loosemore #16 (first public review). -kmp 15-May-93
+When the printer types out the name of a \term{character},
+it uses the same table as the \f{\#\\} \term{reader macro} would use;
+therefore any \term{character} name that is typed out
+is acceptable as input (in that \term{implementation}).
+If a \term{non-graphic} \term{character} has a \term{standardized} \term{name}\meaning{5},
+that \term{name} is preferred over non-standard \term{names}
+for printing in \f{\#\\} notation.
+For the \term{graphic} \term{standard characters},
+the \term{character} itself is always used
+for printing in \f{\#\\} notation---even if 
+the \term{character} also has a \term{name}\meaning{5}.
+
+For details about the \f{\#\\} \term{reader macro}, \seesection\SharpsignBackslash.
+
+\endsubsubsection%{Printing Characters}
+\beginsubsubsection{Printing Symbols}
+\DefineSection{PrintingSymbols}
+%% 22.1.6 10 
+
+%!!! Is this affected by READ-CASE-SENSITIVITY? -kmp 14-May-91
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%When \varref{*print-escape*} is \term{false},
+When \term{printer escaping} is disabled,
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+only the characters of the \term{symbol}'s \term{name} are output 
+% 22.1.6 17
+\issue{PRINT-CASE-BEHAVIOR:CLARIFY}
+%(but the case in which to print any uppercase characters in the \term{name} is 
+%controlled by \thevariable{*print-case*}).
+(but the case in which to print characters in the \term{name} is
+controlled by \varref{*print-case*};
+\seesection\ReadtableCasePrintEffect).
+\endissue{PRINT-CASE-BEHAVIOR:CLARIFY}
+
+%% 22.1.6 11
+The remainder of \thissection\ applies only 
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%when \varref{*print-escape*} is \term{true}.
+when \term{printer escaping} is enabled.
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+
+%% 22.1.6 12
+\issue{SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY}
+% \term{Backslashes} and \term{vertical-bars} are included as required.  
+% The \term{current output base} at the time of printing might be relevant.
+% For example, if \thevalueof{*print-base*} were \f{16} 
+% when printing the symbol \f{face}, it would have to be printed as
+% \f{\\FACE} or \f{\\Face} or \f{|FACE|}, 
+% because the token \f{face} would be read as a hexadecimal
+% number (decimal value 64206) if \thevalueof{*read-base*} were \f{16}.
+When printing a \term{symbol}, the printer inserts enough 
+\term{single escape} and/or \term{multiple escape}
+characters (\term{backslashes} and/or \term{vertical-bars}) so that if
+\funref{read} were called with the same \varref{*readtable*} and
+with \varref{*read-base*} bound to the \term{current output base}, it
+would return the same \term{symbol} (if it is not 
+\term{apparently uninterned}) or an \term{uninterned} \term{symbol}
+with the same \term{print name} (otherwise).
+
+For example, if \thevalueof{*print-base*} were \f{16} 
+when printing the symbol \f{face}, it would have to be printed as
+\f{\\FACE} or \f{\\Face} or \f{|FACE|}, 
+because the token \f{face} would be read as a hexadecimal
+number (decimal value 64206) if \thevalueof{*read-base*} were \f{16}.
+
+For additional restrictions concerning characters with  nonstandard
+\term{syntax types} in the \term{current readtable}, \seevar{*print-readably*} 
+\endissue{SYMBOL-PRINT-ESCAPE-BEHAVIOR:CLARIFY}
+
+For information about how the \term{Lisp reader} parses \term{symbols},
+\seesection\SymbolTokens\ and \secref\SharpsignColon.
+
+%!!! Somewhat redundant with what's above--also, is this also affected
+%    by READ-CASE-SENSITIVITY? -kmp 14-May-91
+%% 22.1.6 13
+% already said above.  --sjl 16 Mar 92
+%The case in which to print any uppercase characters in the \term{symbol}'s \term{name} is 
+%controlled by \varref{*print-case*}.
+\nil\ might be printed as \f{()} 
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%when \varref{*print-escape*} and \varref{*print-pretty*} are both \term{true}.
+when \varref{*print-pretty*} is \term{true}
+and \term{printer escaping} is enabled.
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+
+\beginsubsubsubsection{Package Prefixes for Symbols}
+
+%% 22.1.6 14
+%% 11.0.0 28
+\term{Package prefixes} are printed if necessary.
+The rules for \term{package prefixes} are as follows.
+When the \term{symbol} is printed, if it is in \thepackage{keyword}, 
+% should this be ``colon'' or ``package marker''?  --sjl 16 Mar 92
+then it is printed with a preceding \term{colon}; otherwise, if
+it is \term{accessible} in the \term{current package}, it is printed without any
+\term{package prefix}; otherwise, it is printed with a \term{package prefix}.
+
+%% 22.1.6 15
+A \term{symbol} that is \term{apparently uninterned} is printed
+preceded by ``\f{\#:}'' 
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+% if \varref{*print-gensym*} and \varref{*print-escape*} are both \term{non-nil};
+% if either is \nil,
+if \varref{*print-gensym*} is \term{true} and \term{printer escaping} is enabled;
+if \varref{*print-gensym*} is \term{false} or \term{printer escaping} is disabled,
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+then the \term{symbol} is printed without a prefix,
+as if it were in the \term{current package}.
+
+%% 22.1.6 16
+Because the \f{\#:} syntax does not intern the
+following symbol, it is necessary to use circular-list syntax
+if \varref{*print-circle*} is \term{true} and
+the same uninterned symbol appears several times in an expression
+to be printed.  For example, the result of
+
+\code
+ (let ((x (make-symbol "FOO"))) (list x x))
+\endcode
+would be printed as \f{(\#:foo \#:foo)} if \varref{*print-circle*}
+were \term{false}, but as \f{(\#1=\#:foo \#1\#)} if \varref{*print-circle*}
+were \term{true}.
+
+A summary of the preceding package prefix rules follows:
+
+\beginlist
+\itemitem{\f{foo:bar}}
+
+\f{foo:bar} is printed when \term{symbol} \f{bar} 
+is external in its \term{home package} \f{foo} 
+and is not \term{accessible} in the \term{current package}.
+         
+\itemitem{\f{foo::bar}}
+
+\f{foo::bar} is printed when \f{bar} is internal in its \term{home package}
+\f{foo} and is not \term{accessible} in the \term{current package}.
+         
+\itemitem{\f{:bar}}
+
+\f{:bar} is printed when the home package of \f{bar} is \thepackage{keyword}.
+                
+\itemitem{\tt \#:bar}  
+
+\f{\#:bar} is printed when \f{bar} is \term{apparently uninterned},
+even in the pathological case that \f{bar} 
+has no \term{home package} but is nevertheless somehow \term{accessible} 
+in the \term{current package}.
+\endlist
+
+% Waters points out that this was already said above.
+% %% 22.1.6 17
+% The case in which symbols are printed is controlled by 
+% \varref{*print-case*}.
+
+\endsubsubsubsection%{Package Prefixes for Symbols}
+
+\beginsubsubsubsection{Effect of Readtable Case on the Lisp Printer}
+\DefineSection{ReadtableCasePrintEffect}
+
+\issue{PRINT-CASE-BEHAVIOR:CLARIFY}
+% When \term{escape} syntax is not being used,
+When 
+%both \varref{*print-escape*} and \varref{*print-readably*} are \term{false},
+\term{printer escaping} is disabled,
+or the characters under consideration are not already 
+quoted specifically by \term{single escape} or \term{multiple escape}
+syntax,
+\endissue{PRINT-CASE-BEHAVIOR:CLARIFY}
+the \term{readtable case} of the \term{current readtable} 
+affects the way the \term{Lisp printer} writes \term{symbols}
+in the following ways:
+ 
+\beginlist
+\itemitem{\kwd{upcase}}
+
+ When the \term{readtable case} is \kwd{upcase},
+ \term{uppercase} \term{characters}
+ are printed in the case specified by \varref{*print-case*}, and
+ \term{lowercase} \term{characters} are printed in their own case.
+ 
+\itemitem{\kwd{downcase}}
+
+ When the \term{readtable case} is \kwd{downcase},
+ \term{uppercase} \term{characters} are printed in their own case, and
+ \term{lowercase} \term{characters}
+ are printed in the case specified by \varref{*print-case*}.
+ 
+\itemitem{\kwd{preserve}}
+
+ When the \term{readtable case} is \kwd{preserve},
+ all \term{alphabetic} \term{characters} are printed in their own case.
+ 
+\itemitem{\kwd{invert}}
+
+ When the \term{readtable case} is \kwd{invert},
+ the case of all \term{alphabetic} \term{characters} 
+ in single case symbol names is inverted.
+ Mixed-case symbol names are printed as is.
+\endlist 
+
+The rules for escaping \term{alphabetic} \term{characters} in symbol names are affected by
+the \funref{readtable-case} 
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%if \varref{*print-escape*} is \term{true}.
+if \term{printer escaping} is enabled.
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+\term{Alphabetic} \term{characters} are escaped as follows:                
+\beginlist
+\itemitem{\kwd{upcase}}
+
+When the \term{readtable case} is \kwd{upcase},
+all \term{lowercase} \term{characters} must be escaped.
+
+\itemitem{\kwd{downcase}}
+
+When the \term{readtable case} is \kwd{downcase},
+all \term{uppercase} \term{characters} must be escaped.
+
+\itemitem{\kwd{preserve}}
+
+When the \term{readtable case} is \kwd{preserve}, 
+no \term{alphabetic} \term{characters} need be escaped.
+
+\itemitem{\kwd{invert}}
+
+When the \term{readtable case} is \kwd{invert},
+no \term{alphabetic} \term{characters} need be escaped.
+
+\endlist    
+
+\beginsubsubsubsubsection{Examples of Effect of Readtable Case on the Lisp Printer}
+\DefineSection{ReadtableCasePrintExamples}
+
+\code
+ (defun test-readtable-case-printing ()
+   (let ((*readtable* (copy-readtable nil))
+         (*print-case* *print-case*))
+     (format t "READTABLE-CASE *PRINT-CASE*  Symbol-name  Output~
+              ~%--------------------------------------------------~
+              ~%")
+     (dolist (readtable-case '(:upcase :downcase :preserve :invert))
+       (setf (readtable-case *readtable*) readtable-case)
+       (dolist (print-case '(:upcase :downcase :capitalize))
+         (dolist (symbol '(|ZEBRA| |Zebra| |zebra|))
+           (setq *print-case* print-case)
+           (format t "~&:~A~15T:~A~29T~A~42T~A"
+                   (string-upcase readtable-case)
+                   (string-upcase print-case)
+                   (symbol-name symbol)
+                   (prin1-to-string symbol)))))))
+\endcode
+  The output from \f{(test-readtable-case-printing)} should be as follows:
+
+\code
+    READTABLE-CASE *PRINT-CASE*  Symbol-name  Output
+    --------------------------------------------------
+    :UPCASE        :UPCASE       ZEBRA        ZEBRA
+    :UPCASE        :UPCASE       Zebra        |Zebra|
+    :UPCASE        :UPCASE       zebra        |zebra|
+    :UPCASE        :DOWNCASE     ZEBRA        zebra
+    :UPCASE        :DOWNCASE     Zebra        |Zebra|
+    :UPCASE        :DOWNCASE     zebra        |zebra|
+    :UPCASE        :CAPITALIZE   ZEBRA        Zebra
+    :UPCASE        :CAPITALIZE   Zebra        |Zebra|
+    :UPCASE        :CAPITALIZE   zebra        |zebra|
+    :DOWNCASE      :UPCASE       ZEBRA        |ZEBRA|
+    :DOWNCASE      :UPCASE       Zebra        |Zebra|
+    :DOWNCASE      :UPCASE       zebra        ZEBRA
+    :DOWNCASE      :DOWNCASE     ZEBRA        |ZEBRA|
+    :DOWNCASE      :DOWNCASE     Zebra        |Zebra|
+    :DOWNCASE      :DOWNCASE     zebra        zebra
+    :DOWNCASE      :CAPITALIZE   ZEBRA        |ZEBRA|
+    :DOWNCASE      :CAPITALIZE   Zebra        |Zebra|
+    :DOWNCASE      :CAPITALIZE   zebra        Zebra
+    :PRESERVE      :UPCASE       ZEBRA        ZEBRA
+    :PRESERVE      :UPCASE       Zebra        Zebra
+    :PRESERVE      :UPCASE       zebra        zebra
+    :PRESERVE      :DOWNCASE     ZEBRA        ZEBRA
+    :PRESERVE      :DOWNCASE     Zebra        Zebra
+    :PRESERVE      :DOWNCASE     zebra        zebra
+    :PRESERVE      :CAPITALIZE   ZEBRA        ZEBRA
+    :PRESERVE      :CAPITALIZE   Zebra        Zebra
+    :PRESERVE      :CAPITALIZE   zebra        zebra
+    :INVERT        :UPCASE       ZEBRA        zebra
+    :INVERT        :UPCASE       Zebra        Zebra
+    :INVERT        :UPCASE       zebra        ZEBRA
+    :INVERT        :DOWNCASE     ZEBRA        zebra
+    :INVERT        :DOWNCASE     Zebra        Zebra
+    :INVERT        :DOWNCASE     zebra        ZEBRA
+    :INVERT        :CAPITALIZE   ZEBRA        zebra
+    :INVERT        :CAPITALIZE   Zebra        Zebra
+    :INVERT        :CAPITALIZE   zebra        ZEBRA
+\endcode
+
+\endsubsubsubsubsection%{Examples of Effect of Readtable Case on the Lisp Printer}
+
+\endsubsubsubsection%{Effect of Readtable Case on the Lisp Printer}
+
+\endsubsubsection%{Printing Symbols}
+\beginsubsubsection{Printing Strings}
+\DefineSection{PrintingStrings}
+%% 22.1.6 18
+
+The characters of the \term{string} are output in order.
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%If \varref{*print-escape*} is \term{true},
+If \term{printer escaping} is enabled,
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+a \term{double-quote} is output before and after, and all
+\term{double-quotes} and \term{single escapes} are preceded by \term{backslash}.
+The printing of \term{strings} is not affected by \varref{*print-array*}.
+Only the \term{active} \term{elements} of the \term{string} are printed.
+
+For information on how the \term{Lisp reader} parses \term{strings},
+\seesection\Doublequote.
+
+\endsubsubsection%{Printing Strings}
+\beginsubsubsection{Printing Lists and Conses}
+\DefineSection{PrintingListsAndConses}
+%% 22.1.6 19
+
+Wherever possible, list notation is preferred over dot notation.  
+Therefore the following algorithm is used to print a \term{cons} $x$:
+
+\goodbreak
+\beginlist
+\item{1.} A \term{left-parenthesis} is printed.
+
+\medbreak
+\item{2.} The \term{car} of $x$ is printed. 
+
+\medbreak
+\item{3.} If the \term{cdr} of $x$ is itself a \term{cons},
+          it is made to be the current \term{cons} 
+	  (\ie $x$ becomes that \term{cons}), 
+\issue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+	  a \term{space}
+%         \term{whitespace}\meaning{1} 
+\endissue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+	  is printed,
+          and step 2 is re-entered.
+
+\medbreak
+\item{4.} If the \term{cdr} of $x$ is not \term{null}, 
+\issue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+	  a \term{space},
+%         \term{whitespace}\meaning{1},
+\endissue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+          a \term{dot},
+\issue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+	  a \term{space},
+%         \term{whitespace}\meaning{1},
+\endissue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+          and the \term{cdr} of $x$ are printed.
+
+\medbreak
+\item{5.} A \term{right-parenthesis} is printed.
+\endlist
+
+\issue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+Actually, the above algorithm is only used when \varref{*print-pretty*}
+is \term{false}.  When \varref{*print-pretty*} is \term{true} (or 
+when \funref{pprint} is used),
+additional \term{whitespace}\meaning{1} 
+may replace the use of a single \term{space},
+and a more elaborate algorithm with similar goals but more presentational 
+flexibility is used; \seesection\PrinterDispatch.
+\endissue{PRINT-WHITESPACE:JUST-ONE-SPACE}
+
+%% 2.4.0 6
+%% 22.1.6 20
+Although the two expressions below are equivalent,
+and the reader accepts
+either one and 
+%% Per X3J13. -kmp 05-Oct-93
+%produce
+produces
+the same \term{cons}, the printer
+always prints such a \term{cons} in the second form.
+
+\code
+ (a . (b . ((c . (d . nil)) . (e . nil))))
+ (a b (c d) e)
+\endcode
+The printing of \term{conses} is affected by \varref{*print-level*},
+\varref{*print-length*}, and \varref{*print-circle*}.
+
+
+\goodbreak         
+Following are examples of printed representations of \term{lists}:
+
+\code
+ (a . b)     ;A dotted pair of a and b
+ (a.b)       ;A list of one element, the symbol named a.b
+ (a. b)      ;A list of two elements a. and b
+ (a .b)      ;A list of two elements a and .b
+ (a b . c)   ;A dotted list of a and b with c at the end; two conses
+ .iot        ;The symbol whose name is .iot
+ (. b)       ;Invalid -- an error is signaled if an attempt is made to read 
+             ;this syntax.
+ (a .)       ;Invalid -- an error is signaled.
+ (a .. b)    ;Invalid -- an error is signaled.
+ (a . . b)   ;Invalid -- an error is signaled.
+ (a b c ...) ;Invalid -- an error is signaled.
+ (a \\. b)    ;A list of three elements a, ., and b
+ (a |.| b)   ;A list of three elements a, ., and b
+ (a \\... b)  ;A list of three elements a, ..., and b
+ (a |...| b) ;A list of three elements a, ..., and b
+\endcode
+
+For information on how the \term{Lisp reader} parses \term{lists} and \term{conses},
+\seesection\LeftParen. 
+     
+\endsubsubsection%{Printing Lists and Conses}
+\beginsubsubsection{Printing Bit Vectors}
+\DefineSection{PrintingBitVectors}
+%% 22.1.6 21
+
+A \term{bit vector} is printed as \f{\#*} followed by the bits of the \term{bit vector}
+in order.  If \varref{*print-array*} is \term{false}, then the \term{bit vector} is
+printed in a format (using \f{\#<}) that is concise but not readable.
+Only the \term{active} \term{elements} of the \term{bit vector} are printed.
+
+\reviewer{Barrett: Need to provide for \f{\#5*0} as an alternate 
+  	  notation for \f{\#*00000}.}%!!!
+
+%% Reworded to avoid awkward line break. -kmp 24-Apr-93
+For information on \term{Lisp reader} parsing of \term{bit vectors},
+\seesection\SharpsignStar.
+
+\endsubsubsection%{Printing Bit Vectors}
+\beginsubsubsection{Printing Other Vectors}
+\DefineSection{PrintingOtherVectors}
+%% 22.1.6 22
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%Any
+If \varref{*print-array*} is \term{true} 
+and \varref{*print-readably*} is \term{false},
+any
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+\term{vector} 
+other than a \term{string} or \term{bit vector} is printed using
+general-vector syntax; this means that information
+about specialized vector representations does not appear.
+The printed representation of a zero-length \term{vector} is \f{\#()}.
+The printed representation of a non-zero-length \term{vector} begins with \f{\#(}.
+Following that, the first element of the \term{vector} is printed.  
+\issue{PRINTER-WHITESPACE:JUST-ONE-SPACE}
+If there are any other elements, they are printed in turn, with 
+each such additional element preceded by
+a \term{space} if \varref{*print-pretty*} is \term{false},
+or \term{whitespace}\meaning{1} if \varref{*print-pretty*} is \term{true}.
+\endissue{PRINTER-WHITESPACE:JUST-ONE-SPACE}
+A \term{right-parenthesis} after the last element
+terminates the printed representation of the \term{vector}. 
+The printing of \term{vectors} 
+is affected by \varref{*print-level*} and \varref{*print-length*}.
+If the \term{vector} has a \term{fill pointer}, 
+then only those elements below
+the \term{fill pointer} are printed.
+
+%% 22.1.6 23
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%If \varref{*print-array*} is \term{false}
+If both \varref{*print-array*} and \varref{*print-readably*} are \term{false},
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+the \term{vector} is not printed as described above,
+but in a format (using \f{\#<}) that is concise but not readable.
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+If \varref{*print-readably*} is \term{true},
+the \term{vector} prints in an \term{implementation-defined} manner;
+\seevar{*print-readably*}.
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+
+For information on how the \term{Lisp reader} parses these ``other \term{vectors},''
+\seesection\SharpsignLeftParen.
+
+\endsubsubsection%{Printing Other Vectors}
+\beginsubsubsection{Printing Other Arrays}
+\DefineSection{PrintingOtherArrays}
+%% 22.1.6 24 
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%Any
+If  \varref{*print-array*} is \term{true} 
+and \varref{*print-readably*} is \term{false},
+any
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+\term{array} other than a \term{vector} is printed
+using \f{\#}\f{n}\f{A} format.
+Let \f{n} be the \term{rank} of the \term{array}.
+Then \f{\#} is printed, then \f{n} as a decimal integer,
+then \f{A}, then \f{n} open parentheses.  
+Next the \term{elements} are scanned in row-major order,
+% Added for Barmar:
+using \funref{write} on each \term{element}, 
+and separating \term{elements} from each other with \term{whitespace}\meaning{1}.
+%% Barrett didn't like the odometer thing (probably for good reason).
+%% I've rewritten it. -kmp 12-Oct-91
+The array's dimensions are numbered 0 to \f{n}-1 from left to right,
+and are enumerated with the rightmost index changing fastest.
+%Imagine the \term{array} indices being enumerated in odometer fashion,
+%recalling that the dimensions are numbered from 0 to \f{n}-1.
+Every time the index for dimension \f{j} is incremented,
+the following actions are taken:
+
+%% 22.1.6 25
+\beginlist
+\itemitem{\bull}
+If \f{j} < \f{n}-1, then a close parenthesis is printed.
+
+%% 22.1.6 26
+\itemitem{\bull}
+If incrementing the index for dimension \f{j} caused it to equal
+dimension \f{j}, that index is reset to zero and the
+index for dimension \f{j}-1 is incremented (thereby performing these three steps recursively),
+unless \f{j}=0, in which case the entire algorithm is terminated.
+If incrementing the index for dimension \f{j} did not cause it to
+equal dimension \f{j}, then a space is printed.
+
+%% 22.1.6 27
+\itemitem{\bull}
+If \f{j} < \f{n}-1, then an open parenthesis is printed.
+\endlist
+
+This causes the contents to be printed in a format suitable for
+\kwd{initial-contents} to \funref{make-array}.
+The lists effectively printed by this procedure are subject to
+truncation by \varref{*print-level*} and \varref{*print-length*}.
+
+%% 22.1.6 28
+If the \term{array} 
+is of a specialized \term{type}, containing bits or characters,
+then the innermost lists generated by the algorithm given above can instead
+be printed using bit-vector or string syntax, provided that these innermost
+lists would not be subject to truncation by \varref{*print-length*}.  
+%For example,
+%a 3-by-2-by-4 \term{array} 
+%of characters that would ordinarily be printed as
+%
+%\code
+% #3A(
+% ((#\\s #\\t #\\o #\\p) (#\\s #\\p #\\o #\\t))
+% ((#\\p #\\o #\\s #\\t) (#\\p #\\o #\\t #\\s))
+% ((#\\t #\\o #\\p #\\s) (#\\o #\\p #\\t #\\s)))
+%\endcode
+%
+%may instead be printed more concisely as
+%                                                                               
+%\code
+% #3A(("stop" "spot") ("post" "pots") ("tops" "opts"))
+%\endcode
+
+%% 22.1.6 29
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%If \varref{*print-array*} is \term{false},
+If both \varref{*print-array*} and \varref{*print-readably*} are \term{false},
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+then the \term{array} is printed
+in a format (using \f{\#<}) that is concise but not readable.
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+If \varref{*print-readably*} is \term{true},
+the \term{array} prints in an \term{implementation-defined} manner; 
+\seevar{*print-readably*}.
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%% Per X3J13. -kmp 05-Oct-93
+In particular,
+this may be important for arrays having some dimension \f{0}.
+
+For information on how the \term{Lisp reader} parses these ``other \term{arrays},''
+see \secref\SharpsignA.
+
+\beginsubsubsection{Examples of Printing Arrays}
+
+\code
+ (let ((a (make-array '(3 3)))
+       (*print-pretty* t)
+       (*print-array* t))
+   (dotimes (i 3) (dotimes (j 3) (setf (aref a i j) (format nil "<~D,~D>" i j))))
+   (print a)
+   (print (make-array 9 :displaced-to a)))
+\OUT #2A(("<0,0>" "<0,1>" "<0,2>") 
+\OUT     ("<1,0>" "<1,1>" "<1,2>") 
+\OUT     ("<2,0>" "<2,1>" "<2,2>")) 
+\OUT #("<0,0>" "<0,1>" "<0,2>" "<1,0>" "<1,1>" "<1,2>" "<2,0>" "<2,1>" "<2,2>") 
+\EV #<ARRAY 9 indirect 36363476>
+\endcode
+
+\endsubsubsection%{Examples of Printing Arrays}
+
+\endsubsubsection%{Printing Other Arrays}
+\beginsubsubsection{Printing Random States}
+\DefineSection{PrintingRandomStates}
+%% 12.9.0 18
+%% 22.1.6 30 
+                                                                       
+A specific syntax for printing \term{objects} \oftype{random-state} is
+not specified. However, every \term{implementation}
+must arrange to print a \term{random state} \term{object} in such a way that,
+within the same implementation, \funref{read}
+can construct from the printed representation a copy of the 
+\term{random state}
+object as if the copy had been made by \funref{make-random-state}.
+
+If the type \term{random state} is effectively implemented 
+by using the machinery for \macref{defstruct},
+the usual structure syntax can then be used for printing 
+\term{random state}
+objects; one might look something like
+
+% Use of non-keyword #S keywords is deprecated.  --sjl 16 Mar 92
+%\code
+% #S(RANDOM-STATE DATA #(14 49 98436589 786345 8734658324 ... ))
+%\endcode
+\code
+ #S(RANDOM-STATE :DATA #(14 49 98436589 786345 8734658324 ... ))
+\endcode
+where the components are \term{implementation-dependent}.
+
+\endsubsubsection%{Printing Random States}
+\beginsubsubsection{Printing Pathnames}
+\DefineSection{PrintingPathnames}
+%% 22.1.6 31 
+
+\issue{PATHNAME-PRINT-READ:SHARPSIGN-P}
+ 
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%When \varref{*print-escape*} is \term{true},
+When \term{printer escaping} is enabled,
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+the syntax \f{\#P"..."} is how a
+\term{pathname} is printed by \funref{write} and the other functions herein described.
+%!!! Probably "a" rather than "the" would go better here?? -kmp 11-Feb-91
+The \f{"..."} is the namestring representation of the pathname.
+ 
+%% !!! I'm thinking about adding the following.
+%%     Mail sent to get other opinions. -kmp 11-Feb-92
+%
+% If a suitable \term{namestring} representation for the \term{pathname} cannot be
+% constructed (\eg for pathname that is missing components required by 
+% the \term{file system}), an \term{implementation} is permitted (but not required)
+% to use an alternate (\term{implementation-dependent}) printed representation, 
+% such as \f{\#S(PATHNAME ...)}.
+
+\issue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+%When \varref{*print-escape*} is \term{false},
+When \term{printer escaping} is disabled,
+\endissue{PRINT-READABLY-BEHAVIOR:CLARIFY}
+\funref{write} writes a \term{pathname} \i{P}
+by writing \f{(namestring \i{P})} instead.
+
+% The following will be deleted:
+% 
+% A specific syntax for printing \term{objects} \oftype{pathname} is not specified.
+% However, every implementation must arrange to print a \term{pathname} in such a way that,
+% within the same implementation of \clisp, 
+% \funref{read} can construct from the printed representation an equivalent
+% instance of the \term{pathname} \term{object}.
+% 
+% The printed representation of a pathname
+% typically designates \kwd{wild} by an asterisk; however, this is
+% \term{implementation-dependent}.    
+% 
+% End of deletion.
+
+For information on how the \term{Lisp reader} parses \term{pathnames},
+see \secref\SharpsignP.
+
+\endissue{PATHNAME-PRINT-READ:SHARPSIGN-P}
+
+\endsubsubsection%{Printing Pathnames}
+\beginsubsubsection{Printing Structures}
+\DefineSection{PrintingStructures}
+
+\issue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+%% 19.1.0 10
+%% 22.1.6 32
+% \term{Structures} defined by \macref{defstruct} are printed under the
+% control of the keyword \kwd{print-function} to \macref{defstruct}.
+% A default printing \term{function} is supplied that prints the 
+% \term{structure} using \f{\#S} syntax.
+By default, a \term{structure} of type $S$ is printed using \f{\#S} syntax.
+This behavior can be customized by specifying a \kwd{print-function} 
+or \kwd{print-object} option to the \macref{defstruct} \term{form} that defines $S$,
+or by writing a \funref{print-object} \term{method} 
+that is \term{specialized} for \term{objects} of type $S$.
+\endissue{DEFSTRUCT-PRINT-FUNCTION-AGAIN:X3J13-MAR-93}
+
+\issue{STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS}
+%% 2.12.0 2
+Different structures might print out in different ways;
+the default notation for structures is:
+
+\code
+ #S(\param{structure-name} \star{\curly{\param{slot-key} \param{slot-value}}})
+\endcode
+where \f{\#S} indicates structure syntax,
+\param{structure-name} is a \term{structure name},
+each \param{slot-key} is an initialization argument \term{name}
+for a \term{slot} in the \term{structure},
+and each corresponding \param{slot-value} is a representation
+of the \term{object} in that \term{slot}.
+%The slot names need not be written with \term{package prefixes}.
+\endissue{STRUCTURE-READ-PRINT-SYNTAX:KEYWORDS}
+
+For information on how the \term{Lisp reader} parses \term{structures},
+see \secref\SharpsignS.
+
+\endsubsubsection%{Printing Structures}
+\beginsubsubsection{Printing Other Objects}
+\DefineSection{PrintingOtherObjects}
+
+%% 2.14.0 1
+%% 22.1.6 33
+Other \term{objects} are printed in an \term{implementation-dependent} manner.
+It is not required that an \term{implementation} print those \term{objects}
+\term{readably}.
+
+For example, \term{hash tables}, 
+	     \term{readtables},
+             \term{packages},
+             \term{streams},
+         and \term{functions}
+might not print \term{readably}.
+
+A common notation to use in this circumstance is \f{\#<...>}.
+Since \f{\#<} is not readable by the \term{Lisp reader},
+the precise format of the text which follows is not important,
+but a common format to use is that provided by \themacro{print-unreadable-object}.
+
+For information on how the \term{Lisp reader} treats this notation,
+\seesection\SharpsignLeftAngle.
+For information on how to notate \term{objects} that cannot be printed \term{readably},
+\seesection\SharpsignDot.
+
+\endsubsubsection%{Printing Other Objects}
+
+\endsubsection%{Default Print-Object Methods}
+
+%% 22.1.6 34
+%% this paragraph left out
+
+\beginsubSection{Examples of Printer Behavior}
+
+\code
+ (let ((*print-escape* t)) (fresh-line) (write #\\a))
+\OUT #\\a
+\EV #\\a
+ (let ((*print-escape* nil) (*print-readably* nil))
+   (fresh-line)
+   (write #\\a))
+\OUT a
+\EV #\\a
+ (progn (fresh-line) (prin1 #\\a))
+\OUT #\\a
+\EV #\\a
+ (progn (fresh-line) (print #\\a))
+\OUT 
+\OUT #\\a
+\EV #\\a
+ (progn (fresh-line) (princ #\\a))
+\OUT a
+\EV #\\a
+\medbreak
+ (dolist (val '(t nil))
+   (let ((*print-escape* val) (*print-readably* val))
+     (print '#\\a) 
+     (prin1 #\\a) (write-char #\\Space)
+     (princ #\\a) (write-char #\\Space)
+     (write #\\a)))
+\OUT #\\a #\\a a #\\a
+\OUT #\\a #\\a a a
+\EV NIL
+\medbreak
+ (progn (fresh-line) (write '(let ((a 1) (b 2)) (+ a b))))
+\OUT (LET ((A 1) (B 2)) (+ A B))
+\EV (LET ((A 1) (B 2)) (+ A B))
+\medbreak
+ (progn (fresh-line) (pprint '(let ((a 1) (b 2)) (+ a b))))
+\OUT (LET ((A 1)
+\OUT       (B 2))               
+\OUT   (+ A B))
+\EV (LET ((A 1) (B 2)) (+ A B))
+\medbreak
+ (progn (fresh-line) 
+        (write '(let ((a 1) (b 2)) (+ a b)) :pretty t))
+\OUT (LET ((A 1)
+\OUT       (B 2))
+\OUT   (+ A B))                 
+\EV (LET ((A 1) (B 2)) (+ A B))
+\medbreak
+ (with-output-to-string (s)  
+    (write 'write :stream s)
+    (prin1 'prin1 s))
+\EV "WRITEPRIN1"
+\endcode
+
+\endsubSection%{Examples of Printer Behavior}
+

concept-reader-algorithm.tex

@@ -0,0 +1,225 @@
+%-*- Mode: TeX -*-
+%% Reader Algorithm
+
+%% 22.1.1 5
+This section describes the algorithm used by the \term{Lisp reader}
+to parse \term{objects} from an \term{input} \term{character} \term{stream},
+including how the \term{Lisp reader} processes \term{macro characters}.
+
+When dealing with \term{tokens}, the reader's basic function is to distinguish
+representations of \term{symbols} from those of \term{numbers}.
+%%Barmar didn't like the double negatives:
+% When a \term{token} is
+% accumulated, it is assumed to be a \term{number} unless it does
+% not satisfy the Syntax for Numbers listed in \figref\SyntaxForNumericTokens.
+When a \term{token} is accumulated, it is assumed to represent a \term{number} if it
+satisfies the syntax for numbers listed in \figref\SyntaxForNumericTokens.
+%%Ditto:
+% If it is not a \term{number}, it is then assumed to be a potential
+% number unless it does not satisfy the rules governing the syntax for a
+% \term{potential number}.
+If it does not represent a \term{number},
+it is then assumed to be a \term{potential number} 
+if it satisfies the rules governing the syntax for a \term{potential number}.
+If a valid \term{token} is neither a representation of a \term{number} 
+			       nor a \term{potential number},
+it represents a \term{symbol}.
+
+The algorithm performed by the \term{Lisp reader} is as follows:
+
+%% 22.1.1 6
+\beginlist
+\item{1.}            
+If at end of file, end-of-file processing is performed as specified
+in \funref{read}.
+Otherwise,
+one \term{character}, \param{x},  is read from the \term{input} \term{stream}, and
+dispatched according to the \term{syntax type} of \param{x} to one
+of steps 2 to 7.
+
+%% 22.1.1 7
+\item{2.}                                          
+If \param{x} is an \term{invalid} \term{character},
+an error \oftype{reader-error} is signaled.
+
+%% 22.1.1 8
+\item{3.}
+If \param{x} is a \term{whitespace}\meaning{2} \term{character},
+then it is discarded and step 1 is re-entered.
+
+%% 22.1.1 9
+\item{4.}
+If \param{x} is a \term{terminating} or \term{non-terminating} \term{macro character}
+then its associated \term{reader macro function} is called with two \term{arguments},
+the \term{input} \term{stream} and \param{x}.
+
+%% 22.1.1 10
+The \term{reader macro function} may read \term{characters} 
+from the \term{input} \term{stream}; 
+if it does, it will see those \term{characters} following the \term{macro character}.
+The \term{Lisp reader} may be invoked recursively from the \term{reader macro function}.
+
+%% 22.1.5 16
+The \term{reader macro function} must not have any side effects other than on the
+\term{input} \term{stream};
+because of backtracking and restarting of the \funref{read} operation,
+front ends to the \term{Lisp reader} (\eg ``editors'' and ``rubout handlers'') 
+may cause the \term{reader macro function} to be called repeatedly during the
+reading of a single \term{expression} in which \param{x} only appears once.
+
+%% 22.1.1 11
+The \term{reader macro function} may return zero values or one value.
+If one value is returned,
+then that value is returned as the result of the read operation;
+the algorithm is done.
+If zero values are returned, then step 1 is re-entered.
+
+%% 22.1.1 12
+\item{5.}
+If \param{x} is a \term{single escape} \term{character}
+then the next \term{character}, \param{y}, is read, or an error \oftype{end-of-file} 
+is signaled if at the end of file.
+\param{y} is treated as if it is a \term{constituent} 
+whose only \term{constituent trait} is \term{alphabetic}\meaning{2}.
+\param{y} is used to begin a \term{token}, and step 8 is entered.
+
+%% 22.1.1 13
+\item{6.}
+If \param{x} is a \term{multiple escape} \term{character}
+then a \term{token} (initially
+containing no \term{characters}) is  begun and step 9 is entered.
+
+%% 22.1.1 14
+\item{7.}
+If \param{x} is a \term{constituent} \term{character}, then it begins a \term{token}.
+After the \term{token} is read in, it will be interpreted
+either as a \Lisp\ \term{object} or as being of invalid syntax.
+If the \term{token} represents an \term{object},
+that \term{object} is returned as the result of the read operation.
+If the \term{token} is of invalid syntax, an error is signaled.
+% If \param{x} is a \term{lowercase} \term{character},
+% it is replaced with the corresponding \term{uppercase} \term{character}.
+%% Tentatively replaced with the following to satisfy Sandra:
+If \param{x} is a \term{character} with \term{case},
+it might be replaced with the corresponding \term{character} of the opposite \term{case}, 
+depending on the \term{readtable case} of the \term{current readtable},
+as outlined in \secref\ReadtableCaseReadEffect.
+\param{X} is used to begin a \term{token}, and step 8 is entered.
+
+%% 22.1.1 15
+%% 22.1.1 16
+%% 22.1.1 17
+\item{8.}
+At this point a \term{token} is being accumulated, and an even number
+of \term{multiple escape} \term{characters} have been encountered.
+If at end of file, step 10 is entered.
+Otherwise, a \term{character}, \param{y}, is read, and
+one of the following actions is performed according to its \term{syntax type}:
+
+\beginlist
+\itemitem{\bull}
+If \param{y} is a \term{constituent} or \term{non-terminating} \term{macro character}:
+\beginlist
+\itemitem{--}
+% If \param{y} is a \term{lowercase} \term{character}, it is replaced with the
+% corresponding \term{uppercase} \term{character}.
+%% Tentatively replaced with the following to satisfy Sandra:
+If \param{y} is a \term{character} with \term{case},
+it might be replaced with the corresponding \term{character} of the opposite \term{case}, 
+depending on the \term{readtable case} of the \term{current readtable},
+as outlined in \secref\ReadtableCaseReadEffect.
+\itemitem{--}
+\param{Y} is appended to the \term{token} being built.
+\itemitem{--}
+Step 8 is repeated.
+\endlist
+
+%% 22.1.1 18
+\itemitem{\bull}
+If \param{y} is a \term{single escape} \term{character}, then the next \term{character},
+\param{z}, is read, or an error \oftype{end-of-file} is signaled if at end of file.
+\param{Z} is treated as if it is a \term{constituent} 
+whose only \term{constituent trait} is \term{alphabetic}\meaning{2}.
+\param{Z} is appended to the \term{token} being built,
+and step 8 is repeated.
+
+%% 22.1.1 19
+\itemitem{\bull}
+If \param{y} is a \term{multiple escape} \term{character},
+then step 9 is entered.
+
+%% 22.1.1 20
+\itemitem{\bull}
+If \param{y} is an \term{invalid} \term{character},
+an error \oftype{reader-error} is signaled.
+
+%% 22.1.1 21
+\itemitem{\bull}
+If \param{y} is a \term{terminating} \term{macro character},
+then it terminates the \term{token}.
+First the \term{character} \param{y} is unread (see \funref{unread-char}),
+and then step 10 is entered.
+
+%% 22.1.1 22
+\itemitem{\bull}
+If \param{y} is a \term{whitespace}\meaning{2} \term{character}, then it terminates
+the \term{token}.  First the \term{character} \param{y} is unread
+if appropriate (see \funref{read-preserving-whitespace}),
+and then step 10 is entered.
+\endlist
+
+%% 22.1.1 23
+%% 22.1.1 24
+\item{9.}
+At this point a \term{token} is being accumulated, and an odd number
+of \term{multiple escape} \term{characters} have been encountered.
+If at end of file, an error \oftype{end-of-file} is signaled.
+Otherwise, a \term{character}, \param{y}, is read, and
+one of the following actions is performed according to its \term{syntax type}:
+
+%% 22.1.1 25
+\beginlist
+\itemitem{\bull}
+If \param{y} is a \term{constituent}, macro, or \term{whitespace}\meaning{2} \term{character},
+\param{y} is treated as a \term{constituent} 
+whose only \term{constituent trait} is \term{alphabetic}\meaning{2}.             
+\param{Y} is appended to the \term{token} being built, and step 9 is repeated.
+
+%% 22.1.1 26
+\itemitem{\bull}
+If \param{y} is a \term{single escape} \term{character}, then the next \term{character},
+\param{z}, is read, or an error \oftype{end-of-file} is signaled if at end of file.
+\param{Z} is treated as a \term{constituent}
+whose only \term{constituent trait} is \term{alphabetic}\meaning{2}.
+\param{Z} is appended to the \term{token} being built,
+and step 9 is repeated.
+
+%% 22.1.1 27
+\itemitem{\bull}
+If \param{y} is a \term{multiple escape} \term{character},
+then step 8 is entered.
+
+%% 22.1.1 28
+\itemitem{\bull}
+If \param{y} is an \term{invalid} \term{character},
+an error \oftype{reader-error} is signaled.
+\endlist
+
+%% 22.1.1 29
+\item{10.}
+An entire \term{token} has been accumulated.
+The \term{object} represented by the \term{token} is returned 
+as the result of the read operation,
+or an error \oftype{reader-error} is signaled if the \term{token} is not of valid syntax.
+\endlist
+
+%% 22.1.1 30
+%% 22.1.1 31
+%%Barmar observes that this is said elsewhere, and in any case is
+%%implied by the algorithm above:
+% \term{Single escape} and \term{multiple escape} \term{characters}
+% can be included in a \term{token} when
+% preceded by another \term{single escape} \term{character}.
+
+
+

concept-reader.tex

@@ -0,0 +1,209 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Dynamic Control of the Lisp Reader}
+
+Various aspects of the \term{Lisp reader} can be controlled dynamically.
+\Seesection\Readtables\ and \secref\ReaderVars.
+
+\endsubsection%{Dynamic Control of the Lisp Reader}
+ 
+\beginsubsection{Effect of Readtable Case on the Lisp Reader}
+\DefineSection{ReadtableCaseReadEffect}
+
+The \term{readtable case} of the \term{current readtable} affects the \term{Lisp reader}
+in the following ways:
+
+\beginlist
+\itemitem{\kwd{upcase}}
+
+ When the \term{readtable case} is \kwd{upcase},
+ unescaped constituent \term{characters} are converted to \term{uppercase},
+ as specified in \secref\ReaderAlgorithm.
+
+\itemitem{\kwd{downcase}}
+
+ When the \term{readtable case} is \kwd{downcase},
+ unescaped constituent \term{characters} are converted to \term{lowercase}.
+
+\itemitem{\kwd{preserve}}
+
+When the \term{readtable case} is \kwd{preserve},
+ the case of all \term{characters} remains unchanged.
+
+\itemitem{\kwd{invert}}
+
+When the \term{readtable case} is \kwd{invert},
+ then if all of the unescaped letters in the extended token are of the same \term{case}, 
+ those (unescaped) letters are converted to the opposite \term{case}.
+
+\endlist
+
+\beginsubsubsection{Examples of Effect of Readtable Case on the Lisp Reader}
+\DefineSection{ReadtableCaseReadExamples}
+
+\code
+ (defun test-readtable-case-reading ()
+   (let ((*readtable* (copy-readtable nil)))
+     (format t "READTABLE-CASE  Input   Symbol-name~
+              ~%-----------------------------------~
+              ~%")
+     (dolist (readtable-case '(:upcase :downcase :preserve :invert))
+       (setf (readtable-case *readtable*) readtable-case)
+       (dolist (input '("ZEBRA" "Zebra" "zebra"))
+         (format t "~&:~A~16T~A~24T~A"
+                 (string-upcase readtable-case)
+                 input
+                 (symbol-name (read-from-string input)))))))
+\endcode
+ 
+The output from \f{(test-readtable-case-reading)} should be as follows:
+
+\code
+ READTABLE-CASE     Input Symbol-name
+ -------------------------------------
+    :UPCASE         ZEBRA   ZEBRA
+    :UPCASE         Zebra   ZEBRA
+    :UPCASE         zebra   ZEBRA
+    :DOWNCASE       ZEBRA   zebra
+    :DOWNCASE       Zebra   zebra
+    :DOWNCASE       zebra   zebra
+    :PRESERVE       ZEBRA   ZEBRA
+    :PRESERVE       Zebra   Zebra
+    :PRESERVE       zebra   zebra
+    :INVERT         ZEBRA   zebra
+    :INVERT         Zebra   Zebra
+    :INVERT         zebra   ZEBRA
+\endcode
+
+\endsubsubsection%{Examples of Effect of Readtable Case on the Lisp Reader}
+
+\endsubsection%{Effect of Readtable Case on the Lisp Reader}
+
+\beginsubsection{Argument Conventions of Some Reader Functions}
+
+\beginsubsubsection{The EOF-ERROR-P argument}
+
+%% 22.2.1 2
+
+\param{Eof-error-p} in input function calls
+controls what happens if input is from a file (or any other
+input source that has a definite end) and the end of the file is reached.
+If \param{eof-error-p} is \term{true} (the default), 
+an error \oftype{end-of-file} is signaled
+at end of file.  If it is \term{false}, then no error is signaled, and instead
+the function returns \param{eof-value}.
+
+Functions such as \funref{read} that read the representation
+of an \term{object} rather than a single
+character always signals an error, regardless of \param{eof-error-p}, if
+the file ends in the middle of an object representation.
+For example, if a file does
+not contain enough right parentheses to balance the left parentheses in
+it, \funref{read} signals an error.  If a file ends in a 
+\term{symbol} or a \term{number}
+immediately followed by end-of-file, \funref{read} reads the 
+\term{symbol} or
+\term{number} 
+successfully and when called again will
+%%Barmar thought this wasn't needed:
+% see the end-of-file and
+% only then
+act according to \param{eof-error-p}.
+Similarly, \thefunction{read-line}
+successfully reads the last line of a file even if that line
+is terminated by end-of-file rather than the newline character.
+Ignorable text, such as lines containing only \term{whitespace}\meaning{2} or comments,
+are not considered to begin an \term{object}; 
+if \funref{read} begins to read an \term{expression} but sees only such
+ignorable text, it does not consider the file to end in the middle of an \term{object}.
+Thus an \param{eof-error-p} argument controls what happens
+when the file ends between \term{objects}.
+
+\endsubsubsection%{The EOF-ERROR-P argument}
+
+\beginsubsubsection{The RECURSIVE-P argument}
+
+%% 22.2.1 4
+
+If \param{recursive-p} is supplied and not \nil, it specifies that
+this function call is not an outermost call to \funref{read} but an 
+embedded call, typically from a \term{reader macro function}.
+It is important to distinguish such recursive calls for three reasons.
+
+%% 22.2.1 5
+\beginlist
+\itemitem{1.}
+An outermost call establishes the context within which the
+\f{\#\param{n}=} and \f{\#\param{n}\#} syntax is scoped.  Consider, for example,
+the expression
+
+\code
+ (cons '#3=(p q r) '(x y . #3#))
+\endcode
+If the \term{single-quote} \term{reader macro} were defined in this way:
+
+\code
+ (set-macro-character #\\'       ;incorrect
+    #'(lambda (stream char)
+         (declare (ignore char))
+         (list 'quote (read stream))))
+\endcode
+
+% then the expression could not be read properly, because there would be no way
+% to know when \funref{read} is called recursively by the first
+% occurrence of \f{'} that the label \f{\#3=} would be referred to
+% later in the containing expression.
+% There would be no way to know because \funref{read}
+% could not determine that it was called by a \term{reader macro function}
+% rather than from an outermost form.
+%% per JonL:
+then each call to the \term{single-quote} \term{reader macro function} would establish
+independent contexts for the scope of \funref{read} information, including the scope of
+identifications between markers like ``\f{\#3=}'' and ``\f{\#3\#}''.  However, for
+this expression, the scope was clearly intended to be determined by the outer set 
+of parentheses, so such a definition would be incorrect.
+The correct way to define the \term{single-quote}
+\term{reader macro} uses \param{recursive-p}: 
+
+\code
+ (set-macro-character #\\'       ;correct
+    #'(lambda (stream char)
+         (declare (ignore char))
+         (list 'quote (read stream t nil t))))
+\endcode
+
+%% 22.2.1 6
+\itemitem{2.}
+A recursive call does not alter whether the reading process
+is to preserve \term{whitespace}\meaning{2} or not (as determined by whether the
+outermost call was to \funref{read} or \funref{read-preserving-whitespace}).
+Suppose again that \term{single-quote} 
+% had the first, incorrect, \term{reader macro}
+% definition shown above.
+%% per JonL:
+were to be defined as shown above in the incorrect definition.
+Then a call to \funref{read-preserving-whitespace}
+that read the expression \f{'foo\SpaceChar} would fail to preserve the space
+character following the symbol \f{foo} because the \term{single-quote}
+\term{reader macro function} calls \funref{read}, 
+not \funref{read-preserving-whitespace},
+to read the following expression (in this case \f{foo}).
+The correct definition, which passes the value \term{true} for \param{recursive-p}
+to \funref{read}, allows the outermost call to determine
+whether \term{whitespace}\meaning{2} is preserved.
+
+%% 22.2.1 8
+\itemitem{3.}
+When end-of-file is encountered and the \param{eof-error-p} argument
+is not \nil, the kind of error that is signaled may depend on the value
+of \param{recursive-p}.  If \param{recursive-p} 
+is \term{true}, then the end-of-file
+is deemed to have occurred within the middle of a printed representation;
+if \param{recursive-p} is \term{false}, then the end-of-file may be deemed to have
+occurred between \term{objects} rather than within the middle of one.
+
+\endlist
+
+\endsubsubsection%{The EOF-ERROR-P argument}
+
+\endsubsection%{Argument Conventions of Some Reader Functions}

concept-references.tex

@@ -0,0 +1,106 @@
+%-*- Mode: TeX -*-
+%%Referenced Publications
+
+\beginlist
+
+\item{\bull} {\AnatomyOfLisp},
+        John Allen, McGraw-Hill, Inc., 1978.
+
+% JonL wanted this added.  See entry for HASH-TABLE. -kmp 5-Feb-92
+\item{\bull} {\KnuthVolThree},
+             Donald E. Knuth, Addison-Wesley Company (Reading, MA), 1973.
+
+\item{\bull} {\MetaObjectProtocol},
+	Kiczales et al., MIT Press (Cambridge, MA), 1991.
+
+\item{\bull} ``\CLOSPaper,''
+        D. Bobrow, L. DiMichiel, R.P. Gabriel, S. Keene, G. Kiczales, D. Moon,
+        \i{SIGPLAN Notices} V23, September, 1988.
+
+\item{\bull} {\CLtL},
+        Guy L. Steele Jr., Digital Press (Burlington, MA), 1984.
+
+\item{\bull} {\CLtLTwo},
+        Guy L. Steele Jr., Digital Press (Bedford, MA), 1990.
+
+\item{\bull} {\CondSysPaper},
+	Kent M. Pitman,
+	{\it Proceedings of the First European Conference
+	     on the Practical Application of LISP\/}
+        (EUROPAL '90),
+	Churchill College, Cambridge, England,
+	March 27-29, 1990.
+
+\item{\bull} {\FlavorsPaper},
+	Howard I. Cannon, 1982.
+
+\item{\bull} {\IEEEFloatingPoint},
+        ANSI/IEEE Std 754-1985,
+        Institute of Electrical and Electronics Engineers, Inc. (New York), 1985.
+
+\item{\bull} {\IEEEScheme},
+	IEEE Std 1178-1990,
+	Institute of Electrical and Electronic Engineers, Inc. (New York), 1991.
+
+\item{\bull} {\InterlispManual}, Third Revision,
+	Teitelman, Warren, et al,
+	Xerox Palo Alto Research Center (Palo Alto, CA), 1978.
+
+\item{\bull} \ISOChars,
+	\i{Information processing---Coded character sets 
+           for text communication---Part 2: Latin alphabetic and non-alphabetic
+           graphic characters}, 
+	ISO, 1983.
+
+\item{\bull} {\LispOnePointFive},
+	John McCarthy, MIT Press (Cambridge, MA), August, 1962.
+
+\item{\bull} {\Chinual},
+	D.L. Weinreb and D.A. Moon,
+	Artificial Intelligence Laboratory, MIT (Cambridge, MA), July, 1981.
+
+\item{\bull} {\Moonual},
+	David A. Moon, Project MAC (Laboratory for Computer Science),
+        MIT (Cambridge, MA), March, 1974.
+
+\item{\bull} ``{\NILReport},'' 
+        JonL White, \i{Macsyma User's Conference}, 1979.
+
+\item{\bull} {\GabrielBenchmarks},
+	Richard P. Gabriel, MIT Press (Cambridge, MA), 1985.
+
+\item{\bull} ``{\PrincipalValues},'' 
+        Paul Penfield Jr., \i{APL 81 Conference Proceedings},
+        ACM SIGAPL (San Francisco, September 1981), 248-256.
+        Proceedings published as \i{APL Quote Quad 12}, 1 (September 1981).
+
+\item{\bull} {\Pitmanual},
+	Kent M. Pitman, 
+	Technical Report 295,
+	Laboratory for Computer Science, MIT (Cambridge, MA), May 1983.
+
+\item{\bull} ``{\RevisedCubedScheme},''
+        Jonathan Rees and William Clinger (editors), 
+        \i{SIGPLAN Notices} V21, \#12, December, 1986.
+
+\item{\bull} ``\SOneCLPaper,''
+	R.A. Brooks, R.P. Gabriel, and G.L. Steele,
+	\i{Conference Record of the 1982 ACM Symposium on Lisp and Functional Programming},
+	108-113, 1982.
+
+\item{\bull} \SmalltalkBook,
+        A. Goldberg and D. Robson, Addison-Wesley, 1983.
+
+\item{\bull} ``{\StandardLispReport},''
+        J.B. Marti, A.C. Hearn, M.L. Griss, and C. Griss,
+        \i{SIGPLAN Notices} V14, \#10, October, 1979.
+
+\item{\bull} {\WebstersDictionary},
+	Merriam Webster (Springfield, MA), 1986.
+
+\item{\bull} \XPPaper,
+        R.C. Waters,
+	Memo 1102a,
+	Artificial Intelligence Laboratory, MIT (Cambridge, MA), September 1989.
+
+\endlist

concept-reinit.tex

@@ -0,0 +1,41 @@
+% -*- Mode: TeX -*-
+                      
+The generic function \funref{reinitialize-instance} may be used to change
+the values of \term{slots} according to initialization arguments.
+
+The process of reinitialization changes the values of some \term{slots} and
+performs any user-defined actions.  It does not modify the structure
+of an \term{instance} to add or delete \term{slots}, 
+and it does not use any \kwd{initform} forms to initialize \term{slots}.
+
+The generic function \funref{reinitialize-instance} may be called
+directly.  It takes one required argument, the \term{instance}.  It also
+takes any number of initialization arguments to be used by \term{methods} for
+\funref{reinitialize-instance} or for \funref{shared-initialize}. The
+arguments after the required \term{instance} must form an 
+\term{initialization argument list}.
+                                               
+There is a system-supplied primary \term{method} for 
+\funref{reinitialize-instance} whose \term{parameter specializer} is 
+\theclass{standard-object}.  First this \term{method} checks the validity of
+initialization arguments and signals an error if an initialization
+argument is supplied that is not declared as valid. 
+(For more information, \seesection\DeclaringInitargValidity.)
+Then it calls the generic function 
+\funref{shared-initialize} with the following arguments: the \term{instance},
+\nil, and the initialization arguments it received.
+
+\beginsubsection{Customizing Reinitialization}             
+
+\term{Methods} for \funref{reinitialize-instance} may be defined to specify
+actions to be taken when an \term{instance} is updated.  If only
+\term{after methods} for \funref{reinitialize-instance} are defined, 
+they will be run after the system-supplied primary \term{method} for 
+initialization and therefore will not interfere with the default behavior of 
+\funref{reinitialize-instance}.
+
+\term{Methods} for \funref{shared-initialize} may be defined to customize 
+\term{class} redefinition.  For more information, \seesection\SharedInitialize.
+
+\endsubsection%{Customizing Reinitialization}
+

concept-sequences.tex

@@ -0,0 +1,45 @@
+% -*- Mode: TeX -*-
+
+A \newterm{sequence} is an ordered collection of \term{elements},
+implemented as either a \term{vector} or a \term{list}.
+
+\term{Sequences} can be created by \thefunction{make-sequence},
+as well as other \term{functions} that create \term{objects} 
+of \term{types} that are \term{subtypes} of \typeref{sequence} 
+(\eg \funref{list}, \funref{make-list}, \funref{mapcar}, and \funref{vector}).
+
+A \newterm{sequence function} is a \term{function} 
+   defined by this specification
+or added as an extension by the \term{implementation} 
+that operates on one or more \term{sequences}.
+%% 14.0.0 19
+Whenever a \term{sequence function} must construct and return
+a new \term{vector}, it always returns a \term{simple vector}.
+Similarly, any \term{strings} constructed will be \term{simple strings}.
+
+\DefineFigure{SequenceFunctions}
+\displaythree{Standardized Sequence Functions}{
+concatenate&length&remove\cr
+copy-seq&map&remove-duplicates\cr
+count&map-into&remove-if\cr
+count-if&merge&remove-if-not\cr
+count-if-not&mismatch&replace\cr
+delete&notany&reverse\cr
+delete-duplicates&notevery&search\cr
+delete-if&nreverse&some\cr
+delete-if-not&nsubstitute&sort\cr
+elt&nsubstitute-if&stable-sort\cr
+every&nsubstitute-if-not&subseq\cr
+fill&position&substitute\cr
+find&position-if&substitute-if\cr
+find-if&position-if-not&substitute-if-not\cr
+find-if-not&reduce&\cr
+}
+
+\beginsubsection{General Restrictions on Parameters that must be Sequences}
+
+In general, \term{lists} (including \term{association lists} and \term{property lists})
+that are treated as \term{sequences} must be \term{proper lists}.
+
+\endsubsection%{General Restrictions on Parameters that must be Sequences}
+

concept-slots.tex

@@ -0,0 +1,247 @@
+% -*- Mode: TeX -*-
+
+\beginsubSection{Introduction to Slots}
+                    
+An \term{object} \ofmetaclass{standard-class} has zero or more named
+\term{slots}.  The \term{slots} of an \term{object} are determined 
+by the \term{class} of the \term{object}.  Each \term{slot} can hold
+one value.
+\reviewer{Barmar: All symbols are valid variable names.  Perhaps this means
+                  to preclude the use of named constants?  We have a terminology
+		  problem to solve.}%!!!
+The \term{name} of a \term{slot} is a \term{symbol} that is syntactically
+valid for use as a variable name.
+
+When a \term{slot} does not have a value, the \term{slot} is said to be 
+\term{unbound}.  When an unbound \term{slot} is read,
+\reviewer{Barmar: from an object whose metaclass is standard-class?}
+the \term{generic function} \funref{slot-unbound} is invoked. The 
+system-supplied primary \term{method} 
+for \funref{slot-unbound} 
+%Barmar: on STANDARD-CLASS or T?
+%KMP: It said T in the signature info for SLOT-UNBOUND so I copied that to here.
+on \term{class} \typeref{t} signals an error.
+\issue{SLOT-MISSING-VALUES:SPECIFY}
+If \funref{slot-unbound} returns, its \term{primary value} 
+is used that time as the \term{value} of the \term{slot}.
+\endissue{SLOT-MISSING-VALUES:SPECIFY}
+
+The default initial value form for a \term{slot} is defined by
+the \kwd{initform} slot option.  When the \kwd{initform} form is used to
+supply a value, it is evaluated in the lexical environment in which
+the \macref{defclass} form was evaluated. The \kwd{initform} along with
+the lexical environment in which the \macref{defclass} form was evaluated
+is called a \term{captured initialization form}. 
+For more details, \seesection\ObjectCreationAndInit.
+             
+A \term{local slot} is defined to be a \term{slot} that is
+%Barmar says: ``Poor wording.  It's "visible" to anyone calling SLOT-VALUE.''
+%    Perhaps we mean to be saying "accessible in"? -kmp 11-Oct-90
+%%Ok. I'll substitute accessible. -kmp 6-Jan-91
+%visible
+\term{accessible}
+to exactly one \term{instance}, 
+namely the one in which the \term{slot} is allocated.  
+A \term{shared slot} is defined to be a \term{slot} that is visible to more than one
+\term{instance} of a given \term{class} and its \term{subclasses}.
+
+A \term{class} is said to define a \term{slot} with a given \term{name} when
+the \macref{defclass} form for that \term{class} contains a \term{slot specifier} with
+that \term{name}.  Defining a \term{local slot} does not immediately create 
+a \term{slot}; it causes a \term{slot} to be created each time 
+an \term{instance} of the \term{class} is created.
+Defining a \term{shared slot} immediately creates a \term{slot}.
+                                                    
+The \kwd{allocation} slot option to \macref{defclass} controls the kind
+of \term{slot} that is defined.  If the value of the \kwd{allocation} slot
+option is \kwd{instance}, a \term{local slot} is created.  If the value of
+\kwd{allocation} is \kwd{class}, a \term{shared slot} is created.
+
+A \term{slot} is said to be \term{accessible} in an \term{instance} 
+of a \term{class} if
+the \term{slot} is defined by the \term{class} 
+of the \term{instance} or is inherited from
+a \term{superclass} of that \term{class}.  
+At most one \term{slot} of a given \term{name} can be
+\term{accessible} in an \term{instance}.  
+A \term{shared slot} defined by a \term{class} is
+\term{accessible} in all \term{instances} 
+of that \term{class}.  
+A detailed explanation of the inheritance of \term{slots} is given in 
+\secref\SlotInheritance.
+
+\endsubSection%{Slots}
+\beginsubSection{Accessing Slots}
+
+\term{Slots} can be \term{accessed} in two ways: by use of the primitive function
+\funref{slot-value} and by use of \term{generic functions} generated by
+the \macref{defclass} form.
+
+\Thefunction{slot-value} can be used with any of the \term{slot}
+names specified in the \macref{defclass} form to \term{access} a specific
+\term{slot} \term{accessible} in an \term{instance} of the given \term{class}.
+
+The macro \macref{defclass} provides syntax for generating \term{methods} to
+read and write \term{slots}.  If a reader \term{method} is requested, 
+a \term{method} is automatically generated for reading the value of the
+\term{slot}, but no \term{method} for storing a value into it is generated.
+If a writer \term{method} is requested, a \term{method} is automatically 
+generated for storing a value into the \term{slot}, but no \term{method} 
+for reading its value is generated.  If an accessor \term{method} is 
+requested, a \term{method} for reading the value of the \term{slot} and a
+\term{method} for storing a value into the \term{slot} are automatically
+generated.  Reader and writer \term{methods} are implemented using
+\funref{slot-value}.
+
+When a reader or writer \term{method} is specified for a \term{slot}, the
+name of the \term{generic function} to which the generated \term{method}
+belongs is directly specified.  If the \term{name} specified for the writer
+\term{method} is the symbol \f{name}, the \term{name} of the
+\term{generic function} for writing the \term{slot} is the symbol
+\f{name}, and the \term{generic function} takes two arguments: the new
+value and the \term{instance}, in that order.  If the \term{name} specified
+for the accessor \term{method} is the symbol \f{name}, the \term{name} of
+the \term{generic function} for reading the \term{slot} is the symbol 
+\f{name}, and the \term{name} of the \term{generic function} for writing 
+the \term{slot} is the list \f{(setf name)}.
+
+A \term{generic function} created or modified by supplying \kwd{reader},
+\kwd{writer}, or \kwd{accessor} \term{slot} options can be treated exactly
+as an ordinary \term{generic function}.
+           
+Note that \funref{slot-value} can be used to read or write the value of a
+\term{slot} whether or not reader or writer \term{methods} exist for that
+\term{slot}.  When \funref{slot-value} is used, no reader or writer
+\term{methods} are invoked.
+
+The macro \macref{with-slots} can be used to establish a 
+\term{lexical environment} in which specified \term{slots} are lexically
+available as if they were variables.  The macro \macref{with-slots} 
+invokes \thefunction{slot-value} to \term{access} the specified \term{slots}.
+
+The macro \macref{with-accessors} can be used to establish a lexical
+environment in which specified \term{slots} are lexically available through
+their accessors as if they were variables.  The macro \macref{with-accessors}
+invokes the appropriate accessors to \term{access} the specified \term{slots}. 
+%Symbolics thinks this sentence is not meaningful:
+%Any accessors specified by \macref{with-accessors} must
+%already have been defined before they are used.
+
+\endsubSection%{Accessing Slots}
+\beginsubsection{Inheritance of Slots and Slot Options}
+\DefineSection{SlotInheritance}
+
+The set of the \term{names} of all \term{slots} \term{accessible} 
+in an \term{instance} of a \term{class} $C$ is the union of 
+the sets of \term{names} of \term{slots} defined by $C$ and its
+\term{superclasses}. The structure of an \term{instance} is
+the set of \term{names} of \term{local slots} in that \term{instance}.
+
+In the simplest case, only one \term{class} among $C$ and its \term{superclasses}
+defines a \term{slot} with a given \term{slot} name.  
+If a \term{slot} is defined by a \term{superclass} of $C$\negthinspace, 
+the \term{slot} is said to be inherited.  The characteristics 
+of the \term{slot} are determined by the \term{slot specifier}
+of the defining \term{class}.
+Consider the defining \term{class} for
+a slot $S$\negthinspace.  If the value of the \kwd{allocation} 
+slot
+option is \kwd{instance}, then $S$ is a \term{local slot} and each 
+\term{instance}
+of $C$ has its own \term{slot} named $S$ that stores its own value.  If the
+value of the \kwd{allocation} slot 
+option is \kwd{class}, then $S$
+is a \term{shared slot}, the \term{class} 
+that defined $S$ stores the value, and all
+\term{instances} of $C$ can \term{access} that single \term{slot}.  
+If the \kwd{allocation} slot option is omitted, \kwd{instance} is used.
+
+In general, more than one \term{class} among $C$ and its 
+\term{superclasses} can
+define a \term{slot} with a given \term{name}.  
+In such cases, only one \term{slot} with
+the given name is \term{accessible} in an \term{instance} 
+of $C$\negthinspace, and
+the characteristics of that \term{slot} are 
+a combination of the several \term{slot}
+specifiers, computed as follows:
+
+\beginlist
+
+\itemitem{\bull} All the \term{slot specifiers} for a given \term{slot} name
+are ordered from most specific to least specific, according to the order in $C$'s
+\term{class precedence list} of the \term{classes} that define them. All references
+to the specificity of \term{slot specifiers} immediately below refers to this
+ordering.
+
+\itemitem{\bull} The allocation of a \term{slot} is controlled by the most 
+specific \term{slot specifier}.  If the most specific \term{slot specifier} 
+does not contain an \kwd{allocation} slot option, \kwd{instance} is used.
+Less specific \term{slot specifiers} do not affect the allocation.
+
+\itemitem{\bull} The default initial value form for a \term{slot} 
+is the value of the \kwd{initform} slot option in the most specific
+\term{slot specifier} that contains one.  If no \term{slot specifier}
+contains an \kwd{initform} slot option, the \term{slot} 
+has no default initial value form.
+
+\itemitem{\bull} The contents of a \term{slot} will always be of type 
+\f{(and $T\sub 1$ $\ldots$ $T\sub n$)} where $T\sub 1 \ldots T\sub n$ are
+the values of the \kwd{type} slot options contained in all of the
+\term{slot specifiers}.  If no \term{slot specifier} contains the
+\kwd{type} slot option, the contents of the \term{slot} will always be 
+\oftype{t}. The consequences of attempting to store in a \term{slot}
+a value that does not satisfy the \term{type} of the \term{slot} are undefined.
+
+\itemitem{\bull} The set of initialization arguments that initialize a 
+given \term{slot} is the union of the initialization arguments declared in
+the \kwd{initarg} slot options in all the \term{slot specifiers}.
+
+\itemitem{\bull} The \term{documentation string} for a \term{slot} is the value of
+the \kwd{documentation} slot option in the most specific \term{slot}
+specifier that contains one.  If no \term{slot specifier} contains a
+\kwd{documentation} slot option, the \term{slot} has no \term{documentation string}.
+
+\endlist
+
+A consequence of the allocation rule is that a \term{shared slot} can be
+\term{shadowed}.  For example, if a class $C\sub 1$ defines 
+a \term{slot} named $S$
+whose value for the \kwd{allocation} slot option is \kwd{class},
+that \term{slot} is \term{accessible} 
+in \term{instances} of $C\sub 1$ and all of its
+\term{subclasses}.  However, if $C\sub 2$ is a \term{subclass} 
+of $C\sub 1$ and also
+defines a \term{slot} named $S$\negthinspace, $C\sub 1$'s 
+\term{slot} is not shared
+by \term{instances} of $C\sub 2$ and its \term{subclasses}. When a class
+$C\sub 1$ defines a \term{shared slot}, any subclass $C\sub 2$ of $C\sub
+1$ will share this single \term{slot} 
+unless the \macref{defclass} form for
+$C\sub 2$ specifies a \term{slot} of the same 
+\term{name} or there is a \term{superclass}
+of $C\sub 2$ that precedes $C\sub 1$ in the \term{class precedence list} of
+$C\sub 2$ that defines a \term{slot} of the same name.
+
+A consequence of the type rule is that the value of a \term{slot}
+satisfies the type constraint of each \term{slot specifier} that
+contributes to that \term{slot}.  Because the result of attempting to
+store in a \term{slot} a value that does not satisfy the type
+constraint for the \term{slot} is undefined, the value in a \term{slot}
+might fail to satisfy its type constraint.
+     
+The \kwd{reader}, \kwd{writer}, and \kwd{accessor} slot options
+create \term{methods} rather than define the characteristics of a \term{slot}.
+Reader and writer \term{methods} are inherited in the sense described in
+\secref\MethodInheritance.
+
+\term{Methods} that \term{access} \term{slots} use only the name of the
+\term{slot} and the \term{type} of the \term{slot}'s value.  Suppose
+a \term{superclass} provides a \term{method} that expects to \term{access} a
+\term{shared slot} of a given \term{name}, and a \term{subclass} defines
+a \term{local slot} with the same \term{name}.  If the \term{method} provided 
+by the \term{superclass} is used on an \term{instance} of the \term{subclass}, 
+the \term{method} \term{accesses} the \term{local slot}.
+
+\endsubsection%{Inheritance of Slots and Slot Options}
+

concept-streams.tex

@@ -0,0 +1,290 @@
+% -*- Mode: TeX -*-
+
+\beginsubSection{Introduction to Streams}
+
+%% 22.0.0 3
+%All input/output operations are performed on \term{streams} of various kinds.
+
+A \newterm{stream} is an \term{object} that can be used with an input or output
+function to identify an appropriate source or sink of \term{characters} or 
+\term{bytes} for that operation.
+%% 21.0.0 3
+%% 21.0.0 4
+A \newterm{character} \newterm{stream} is a source or sink of \term{characters}.
+A \newterm{binary} \newterm{stream} is a source or sink of \term{bytes}.
+
+Some operations may be performed on any kind of \term{stream};
+\thenextfigure\ provides a list of \term{standardized} operations
+that are potentially useful with any kind of \term{stream}.
+
+\displaytwo{Some General-Purpose Stream Operations}{
+close&stream-element-type\cr
+input-stream-p&streamp\cr
+interactive-stream-p&with-open-stream\cr
+output-stream-p&\cr
+}
+
+Other operations are only meaningful on certain \term{stream} \term{types}.
+For example, \funref{read-char} is only defined for \term{character} \term{streams}
+and \funref{read-byte} is only defined for \term{binary} \term{streams}.
+
+\beginsubsubsection{Abstract Classifications of Streams}
+
+\beginsubsubsubsection{Input, Output, and Bidirectional Streams}
+
+%% 21.0.0 3
+A \term{stream}, whether a \term{character} \term{stream} or a \term{binary} \term{stream},
+can be an \newterm{input} \newterm{stream} (source of data),
+       an \newterm{output} \newterm{stream} (sink for data),
+       both, 
+    or (\eg when ``\f{:direction :probe}'' is given to \funref{open}) neither.
+
+\Thenextfigure\ shows \term{operators} relating to
+\term{input} \term{streams}.
+
+\DefineFigure{InputStreamOps}
+\displaythree{Operators relating to Input Streams.}{
+clear-input&read-byte&read-from-string\cr
+listen&read-char&read-line\cr
+peek-char&read-char-no-hang&read-preserving-whitespace\cr
+read&read-delimited-list&unread-char\cr
+}
+
+\Thenextfigure\ shows \term{operators} relating to
+\term{output} \term{streams}.
+
+\DefineFigure{OutputStreamOps}
+\displaythree{Operators relating to Output Streams.}{
+clear-output&prin1&write\cr
+finish-output&prin1-to-string&write-byte\cr
+force-output&princ&write-char\cr
+format&princ-to-string&write-line\cr
+fresh-line&print&write-string\cr
+pprint&terpri&write-to-string\cr
+}
+
+A \term{stream} that is both an \term{input} \term{stream} and an \term{output} \term{stream}
+is called a \newterm{bidirectional} \newterm{stream}.
+\Seefuns{input-stream-p} and \funref{output-stream-p}.
+
+Any of the \term{operators} listed in \figref\InputStreamOps\ or \figref\OutputStreamOps\
+can be used with \term{bidirectional} \term{streams}.  In addition, \thenextfigure\
+shows a list of \term{operators} that relate specificaly to 
+\term{bidirectional} \term{streams}.
+
+\displaythree{Operators relating to Bidirectional Streams.}{
+y-or-n-p&yes-or-no-p&\cr
+}
+
+\endsubsubsubsection%{Input, Output, and Bidirectional Streams}
+
+\beginsubsubsubsection{Open and Closed Streams}
+\DefineSection{OpenAndClosedStreams}
+
+\term{Streams} are either \newterm{open} or \newterm{closed}.  
+
+Except as explicitly specified otherwise,
+operations that create and return \term{streams} return \term{open} \term{streams}.
+
+The action of \term{closing} a \term{stream} marks the end of its use as a source
+or sink of data, permitting the \term{implementation} to reclaim its internal data
+structures, and to free any external resources which might have been locked by the
+\term{stream} when it was opened.
+
+Except as explicitly specified otherwise,
+the consequences are undefined when a \term{closed} \term{stream} 
+is used where a \term{stream} is called for.
+
+Coercion of \term{streams} to \term{pathnames} 
+is permissible for \term{closed} \term{streams};
+in some situations, such as for a \term{truename} computation, 
+the result might be different for an \term{open} \term{stream}
+and for that same \term{stream} once it has been \term{closed}.
+
+\endsubsubsubsection%{Open and Closed Streams}
+
+\beginsubsubsubsection{Interactive Streams}
+\DefineSection{InteractiveStreams}
+
+An \newterm{interactive stream} is one on which it makes sense to perform
+interactive querying.
+
+The precise meaning of an \term{interactive stream} is
+\term{implementation-defined}, and may depend on the underlying
+operating system.  Some examples of the things that an
+\term{implementation} might choose to use as identifying characteristics
+of an \term{interactive stream} include:
+
+\beginlist
+
+\itemitem{\bull} 
+  The \term{stream} is connected to a person (or equivalent) in such a way
+  that the program can prompt for information and expect to receive different
+  input depending on the prompt.
+
+\itemitem{\bull}
+  The program is expected to prompt for input and support ``normal input editing''.
+
+\itemitem{\bull} 
+  \funref{read-char} might wait for the user to type something before returning
+  instead of immediately returning a character or end-of-file. 
+
+\endlist 
+
+The general intent of having some \term{streams} be classified as
+\term{interactive streams} is to allow them to be distinguished from
+streams containing batch (or background or command-file) input.
+Output to batch streams is typically discarded or saved for later viewing, 
+so interactive queries to such streams might not have the expected effect.
+
+\term{Terminal I/O} might or might not be an \term{interactive stream}.
+
+\endsubsubsubsection%{Interactive Streams}
+
+\beginsubsubsection{Abstract Classifications of Streams}
+
+\beginsubsubsubsection{File Streams}
+
+%% 23.2.0 1
+Some \term{streams}, called \newtermidx{file streams}{file stream}, provide access to \term{files}.
+An \term{object} \ofclass{file-stream} is used to represent a \term{file stream}.
+
+The basic operation for opening a \term{file} is \funref{open},
+which typically returns a \term{file stream} 
+(see its dictionary entry for details).
+The basic operation for closing a \term{stream} is \funref{close}.
+The macro \macref{with-open-file} is useful 
+to express the common idiom of opening a \term{file} 
+for the duration of a given body of \term{code}, 
+and assuring that the resulting \term{stream} is closed upon exit from that body.
+
+\endsubsubsubsection%{File Streams}
+
+\beginsubsubsection{Other Subclasses of Stream}
+
+\Theclass{stream} has a number of \term{subclasses} defined 
+by this specification.  \Thenextfigure\ shows some information 
+about these subclasses.
+
+\tablefigtwo{Defined Names related to Specialized Streams}{Class}{Related Operators}{
+ \typeref{broadcast-stream}    & \funref{make-broadcast-stream}        \cr
+                               & \funref{broadcast-stream-streams}     \cr
+ \typeref{concatenated-stream} & \funref{make-concatenated-stream}     \cr
+                               & \funref{concatenated-stream-streams}  \cr
+ \typeref{echo-stream}         & \funref{make-echo-stream}             \cr
+                               & \funref{echo-stream-input-stream}     \cr
+                               & \funref{echo-stream-output-stream}    \cr
+ \typeref{string-stream}       & \funref{make-string-input-stream}     \cr
+                               & \funref{with-input-from-string}       \cr
+                               & \funref{make-string-output-stream}    \cr
+                               & \funref{with-output-to-string}        \cr
+                               & \funref{get-output-stream-string}     \cr
+ \typeref{synonym-stream}      & \funref{make-synonym-stream}          \cr
+                               & \funref{synonym-stream-symbol}        \cr
+ \typeref{two-way-stream}      & \funref{make-two-way-stream}          \cr
+                               & \funref{two-way-stream-input-stream}  \cr
+                               & \funref{two-way-stream-output-stream} \cr
+}
+
+\endsubsubsection%{Other Subclasses of Stream}
+
+\endsubSection%{Introduction to Streams}
+
+\beginsubSection{Stream Variables}
+
+\term{Variables} whose \term{values} must be \term{streams} are sometimes called 
+\newtermidx{stream variables}{stream variable}.
+
+Certain \term{stream variables} are defined by this specification 
+to be the proper source of input or output in various \term{situations} 
+where no specific \term{stream} has been specified instead.
+A complete list of such \term{standardized} \term{stream variables}
+appears in \thenextfigure.  
+%Added by agreement of Barrett, Loosemore, and KMP. -kmp 14-Feb-92
+The consequences are undefined if at any time
+the \term{value} of any of these \term{variables} is not an \term{open} \term{stream}.
+
+\DefineFigure{StandardizedStreamVars}
+\tablefigtwo{Standardized Stream Variables}{Glossary Term}{Variable Name}{
+ \term{debug I/O}       & \varref{*debug-io*}        \cr
+ \term{error output}    & \varref{*error-output*}    \cr
+ \term{query I/O}       & \varref{*query-io*}        \cr
+ \term{standard input}  & \varref{*standard-input*}  \cr
+ \term{standard output} & \varref{*standard-output*} \cr
+ \term{terminal I/O}    & \varref{*terminal-io*}     \cr
+ \term{trace output}    & \varref{*trace-output*}    \cr
+}
+
+Note that, by convention, \term{standardized} \term{stream variables} have names 
+    ending in ``\f{-input*}''  if they must be \term{input} \term{streams},
+    ending in ``\f{-output*}'' if they must be \term{output} \term{streams},
+ or ending in ``\f{-io*}''     if they must be \term{bidirectional} \term{streams}.
+
+User programs may \term{assign} or \term{bind} any \term{standardized} \term{stream variable}
+except \varref{*terminal-io*}.
+
+\endsubSection%{Stream Variables}
+
+\beginsubSection{Stream Arguments to Standardized Functions}
+\DefineSection{StreamArgsToStandardizedFns}
+
+%This list conjured by KMP, Barrett, and Loosemore. -kmp 14-Feb-92
+The \term{operators} in \thenextfigure\ accept \term{stream} \term{arguments} that
+might be either \term{open} or \term{closed} \term{streams}.
+
+\DefineFigure{OpenOrClosedStreamOps}
+\displaythree{Operators that accept either Open or Closed Streams}{
+broadcast-stream-streams&file-author&pathnamep\cr
+close&file-namestring&probe-file\cr
+compile-file&file-write-date&rename-file\cr
+compile-file-pathname&host-namestring&streamp\cr
+concatenated-stream-streams&load&synonym-stream-symbol\cr
+delete-file&logical-pathname&translate-logical-pathname\cr
+directory&merge-pathnames&translate-pathname\cr
+directory-namestring&namestring&truename\cr
+dribble&open&two-way-stream-input-stream\cr
+echo-stream-input-stream&open-stream-p&two-way-stream-output-stream\cr
+echo-stream-ouput-stream&parse-namestring&wild-pathname-p\cr
+ed&pathname&with-open-file\cr
+enough-namestring&pathname-match-p&\cr
+}
+
+%This list conjured by KMP, Barrett, and Loosemore. -kmp 14-Feb-92
+The \term{operators} in \thenextfigure\ accept \term{stream} \term{arguments} that
+must be \term{open} \term{streams}.
+
+\displaythree{Operators that accept Open Streams only}{
+clear-input&output-stream-p&read-char-no-hang\cr
+clear-output&peek-char&read-delimited-list\cr
+file-length&pprint&read-line\cr
+file-position&pprint-fill&read-preserving-whitespace\cr
+file-string-length&pprint-indent&stream-element-type\cr
+finish-output&pprint-linear&stream-external-format\cr
+force-output&pprint-logical-block&terpri\cr
+format&pprint-newline&unread-char\cr
+fresh-line&pprint-tab&with-open-stream\cr
+get-output-stream-string&pprint-tabular&write\cr
+input-stream-p&prin1&write-byte\cr
+interactive-stream-p&princ&write-char\cr
+listen&print&write-line\cr
+make-broadcast-stream&print-object&write-string\cr
+make-concatenated-stream&print-unreadable-object&y-or-n-p\cr
+make-echo-stream&read&yes-or-no-p\cr
+make-synonym-stream&read-byte&\cr
+make-two-way-stream&read-char&\cr
+}
+ 
+\endsubSection%{Stream Arguments to Standardized Functions}
+
+\beginsubSection{Restrictions on Composite Streams}
+
+%KMP, Loosemore, and Barrett thought this stuff should be made explicit. -kmp 14-Feb-92
+
+The consequences are undefined if any \term{component} of a \term{composite stream}
+is \term{closed} before the \term{composite stream} is \term{closed}.
+
+The consequences are undefined if the \term{synonym stream symbol} is not \term{bound}
+to an \term{open} \term{stream} from the time of the \term{synonym stream}'s creation
+until the time it is \term{closed}.
+
+\endsubSection%{Restrictions on Composite Streams}

concept-strings.tex

@@ -0,0 +1,34 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Implications of Strings Being Arrays}
+\DefineSection{StringsAreArrays}
+
+Since all \term{strings} are \term{arrays}, all rules which apply
+generally to \term{arrays} also apply to \term{strings}.
+\Seesection\ArrayConcepts.
+
+For example,
+     \term{strings} can have \term{fill pointers},
+ and \term{strings} are also subject to the rules of \term{element type} \term{upgrading}
+        that apply to \term{arrays}.
+
+\endsubsection%{Implications of Strings Being Arrays}
+
+\beginsubsection{Subtypes of STRING}
+\issue{CHARACTER-PROPOSAL:2}
+% All functions defined to operate on \term{strings} treat
+% \term{base strings} uniformly with 
+% other \term{strings} with the following
+% caveat: for any function that inserts a \term{character} 
+% into a \term{string}, the consequences are undefined
+% if an \term{extended character} is inserted 
+% into a \term{base string}.
+All functions that operate on \term{strings} 
+will operate on \term{subtypes} of \term{string} as well.
+
+However,
+the consequences are undefined if a \term{character} is inserted into a \term{string}
+for which the \term{element type} of the \term{string} does not include that \term{character}.
+
+\endissue{CHARACTER-PROPOSAL:2}
+\endsubsection%{Subtypes of STRING}

concept-subsets.tex

@@ -0,0 +1,16 @@
+%-*- Mode: TeX -*-
+%%Language Subsets
+
+\issue{SUBSETTING-POSITION:NONE}
+The language described in this standard contains no subsets,
+though subsets are not forbidden.
+\endissue{SUBSETTING-POSITION:NONE}
+
+For a language to be considered a subset,
+it must have the property that any valid \term{program} in that language
+has equivalent semantics and will run directly
+(with no extralingual pre-processing, and no special compatibility packages)
+in any \term{conforming implementation} of the full language.
+
+A language that conforms to this requirement shall be described
+as being a ``subset of \clisp\ as specified by ANSI \metavar{standard number}.''

concept-symbols.tex

@@ -0,0 +1,18 @@
+% -*- Mode: TeX -*-
+
+\Thenextfigure\ lists some
+\term{defined names} that are applicable to the \term{property lists} of \term{symbols}.
+
+\displaythree{Property list defined names}{
+get&remprop&symbol-plist\cr
+}
+                    
+\Thenextfigure\ lists some \term{defined names} that are applicable 
+to the creation of and inquiry about \term{symbols}.
+
+\displaythree{Symbol creation and inquiry defined names}{
+copy-symbol&keywordp&symbol-package\cr
+gensym&make-symbol&symbol-value\cr
+gentemp&symbol-name&\cr
+}
+

concept-syntax.tex

@@ -0,0 +1,616 @@
+%-*- Mode: TeX -*-
+%% Character Syntax
+
+%% 2.2.1 1
+%% 2.2.1 2
+%% 22.1.5 1
+
+The \term{Lisp reader} takes \term{characters} from a \term{stream}, 
+interprets them as a printed representation of an \term{object},
+constructs that \term{object}, and returns it.
+
+\DefineSection{TheStandardSyntax}
+The syntax described by this chapter is called the \newterm{standard syntax}.
+Operations are provided by \clisp\ so that
+various aspects of the syntax information represented by a \term{readtable} 
+can be modified under program control; \seechapter\Reader.
+Except as explicitly stated otherwise, 
+the syntax used throughout this document is \term{standard syntax}.
+
+\beginSubsection{Readtables}
+\DefineSection{Readtables}
+
+Syntax information for use by the \term{Lisp reader} is embodied in an
+\term{object} called a \newterm{readtable}.  Among other things, 
+the \term{readtable} contains the association between \term{characters} 
+and \term{syntax types}.
+
+\Thenextfigure\ lists some \term{defined names} that are applicable to
+\term{readtables}.
+
+\displaythree{Readtable defined names}{
+*readtable*&readtable-case\cr
+copy-readtable&readtablep\cr
+get-dispatch-macro-character&set-dispatch-macro-character\cr
+get-macro-character&set-macro-character\cr
+make-dispatch-macro-character&set-syntax-from-char\cr
+}
+
+
+\beginsubsubsection{The Current Readtable}
+\DefineSection{CurrentReadtable}
+
+Several \term{readtables} describing different syntaxes can exist,
+but at any given time only one, called the \newterm{current readtable}, 
+affects the way in which \term{expressions}\meaning{2} are parsed 
+into \term{objects} by the \term{Lisp reader}.
+The \term{current readtable} in a given \term{dynamic environment}
+is \thevalueof{*readtable*} in that \term{environment}.
+To make a different \term{readtable} become the \term{current readtable},
+\varref{*readtable*} can be \term{assigned} or \term{bound}.
+
+\endsubsubsection%{The Current Readtable}
+
+\beginsubsubsection{The Standard Readtable}
+
+The \newterm{standard readtable} conforms to \term{standard syntax}.
+The consequences are undefined if an attempt is made
+to modify the \term{standard readtable}.
+%% 22.1.5 3
+To achieve the effect of altering or extending \term{standard syntax},
+a copy of the \term{standard readtable} can be created; \seefun{copy-readtable}.
+
+The \term{readtable case} of the \term{standard readtable} is \kwd{upcase}.
+
+\endsubsubsection%{The Standard Readtable}
+
+\beginsubsubsection{The Initial Readtable}
+
+The \newterm{initial readtable} is
+the \term{readtable} that is the \term{current readtable}
+at the time when the \term{Lisp image} starts.
+At that time, it conforms to \term{standard syntax}.
+The \term{initial readtable} is \term{distinct} 
+from the \term{standard readtable}.
+It is permissible for a \term{conforming program} 
+to modify the \term{initial readtable}.
+
+\endsubsubsection%{The Initial Readtable}
+
+\endSubsection%{Readtables}
+
+\beginsubsection{Variables that affect the Lisp Reader}
+\DefineSection{ReaderVars}
+
+The \term{Lisp reader} is influenced not only by the \term{current readtable},
+but also by various \term{dynamic variables}.  \Thenextfigure\ lists
+the \term{variables} that influence the behavior of the \term{Lisp reader}.
+
+\displaythree{Variables that influence the Lisp reader.}{
+*package*&*read-default-float-format*&*readtable*\cr
+*read-base*&*read-suppress*&\cr
+}
+
+\endsubsection%{Variables that affect the Lisp Reader}
+
+\beginSubsection{Standard Characters}
+\DefineSection{StandardChars}
+
+%% Redundant.
+% \clisp\ \term{characters} are used for writing programs 
+% that can be read by a \clisp\ implementation, and for data.
+\issue{CHARACTER-PROPOSAL:2-2-1}
+All \term{implementations} must support a \term{character} \term{repertoire}
+called \typeref{standard-char}; \term{characters} that are members of that
+\term{repertoire} are called \newtermidx{standard characters}{standard character}.
+
+The \typeref{standard-char} \term{repertoire} consists of
+the \term{non-graphic} \term{character} \term{newline},
+the \term{graphic} \term{character} \term{space},
+and the following additional
+ninety-four \term{graphic} \term{characters} or their equivalents:
+ 
+\tablefigsix{Standard Character Subrepertoire (Part 1 of 3: Latin Characters)}%
+{Graphic ID}{Glyph}{Description}%
+{Graphic ID}{Glyph}{Description}{
+  LA01  &  \f{a}  &  small a    &
+  LN01  &  \f{n}  &  small n    \cr
+  LA02  &  \f{A}  &  capital A  &
+  LN02  &  \f{N}  &  capital N  \cr
+  LB01  &  \f{b}  &  small b    &
+  LO01  &  \f{o}  &  small o    \cr
+  LB02  &  \f{B}  &  capital B  &
+  LO02  &  \f{O}  &  capital O  \cr
+  LC01  &  \f{c}  &  small c    &
+  LP01  &  \f{p}  &  small p    \cr
+  LC02  &  \f{C}  &  capital C  &
+  LP02  &  \f{P}  &  capital P  \cr
+  LD01  &  \f{d}  &  small d    &
+  LQ01  &  \f{q}  &  small q    \cr
+  LD02  &  \f{D}  &  capital D  &
+  LQ02  &  \f{Q}  &  capital Q  \cr
+  LE01  &  \f{e}  &  small e    &
+  LR01  &  \f{r}  &  small r    \cr
+  LE02  &  \f{E}  &  capital E  &
+  LR02  &  \f{R}  &  capital R  \cr
+  LF01  &  \f{f}  &  small f    &
+  LS01  &  \f{s}  &  small s    \cr
+  LF02  &  \f{F}  &  capital F  &
+  LS02  &  \f{S}  &  capital S  \cr
+  LG01  &  \f{g}  &  small g    &
+  LT01  &  \f{t}  &  small t    \cr
+  LG02  &  \f{G}  &  capital G  &
+  LT02  &  \f{T}  &  capital T  \cr
+  LH01  &  \f{h}  &  small h    &
+  LU01  &  \f{u}  &  small u    \cr
+  LH02  &  \f{H}  &  capital H  &
+  LU02  &  \f{U}  &  capital U  \cr
+  LI01  &  \f{i}  &  small i    &
+  LV01  &  \f{v}  &  small v    \cr
+  LI02  &  \f{I}  &  capital I  &
+  LV02  &  \f{V}  &  capital V  \cr
+  LJ01  &  \f{j}  &  small j    &
+  LW01  &  \f{w}  &  small w    \cr
+  LJ02  &  \f{J}  &  capital J  &
+  LW02  &  \f{W}  &  capital W  \cr
+  LK01  &  \f{k}  &  small k    &
+  LX01  &  \f{x}  &  small x    \cr
+  LK02  &  \f{K}  &  capital K  &
+  LX02  &  \f{X}  &  capital X  \cr
+  LL01  &  \f{l}  &  small l    &
+  LY01  &  \f{y}  &  small y    \cr
+  LL02  &  \f{L}  &  capital L  &
+  LY02  &  \f{Y}  &  capital Y  \cr
+  LM01  &  \f{m}  &  small m    &
+  LZ01  &  \f{z}  &  small z    \cr
+  LM02  &  \f{M}  &  capital M  &
+  LZ02  &  \f{Z}  &  capital Z  \cr
+}
+
+\tablefigsix{Standard Character Subrepertoire (Part 2 of 3: Numeric Characters)}%
+{Graphic ID}{Glyph}{Description}%
+{Graphic ID}{Glyph}{Description}{
+  ND01  &  \f{1}  &  digit 1 &
+  ND06  &  \f{6}  &  digit 6 \cr
+  ND02  &  \f{2}  &  digit 2 &
+  ND07  &  \f{7}  &  digit 7 \cr
+  ND03  &  \f{3}  &  digit 3 &
+  ND08  &  \f{8}  &  digit 8 \cr
+  ND04  &  \f{4}  &  digit 4 &
+  ND09  &  \f{9}  &  digit 9 \cr
+  ND05  &  \f{5}  &  digit 5 &
+  ND10  &  \f{0}  &  digit 0 \cr
+}
+
+\DefineFigure{StdCharsThree}
+\tablefigthree{Standard Character Subrepertoire (Part 3 of 3: Special Characters)}%
+{Graphic ID}{Glyph}{Description}{
+  SP02  &  \f{!}        &  exclamation mark                        \cr
+  SC03  &  \f{\$}       &  dollar sign                             \cr
+  SP04  &  \f{"}        &  quotation mark, or double quote         \cr
+  SP05  &  \f{'}        &  apostrophe, or \brac{single} quote      \cr
+  SP06  &  \f{(}        &  left parenthesis, or open parenthesis   \cr
+  SP07  &  \f{)}        &  right parenthesis, or close parenthesis \cr
+  SP08  &  \f{,}        &  comma                                   \cr
+  SP09  &  \f{_}        &  low line, or underscore                 \cr
+  SP10  &  \f{-}        &  hyphen, or minus \brac{sign}            \cr
+  SP11  &  \f{.}        &  full stop, period, or dot               \cr
+  SP12  &  \f{/}        &  solidus, or slash                       \cr
+  SP13  &  \f{:}        &  colon                                   \cr
+  SP14  &  \f{;}        &  semicolon                               \cr
+  SP15  &  \f{?}        &  question mark                           \cr
+  SA01  &  \f{+}        &  plus \brac{sign}                        \cr
+  SA03  &  \f{<}        &  less-than \brac{sign}                   \cr
+  SA04  &  \f{=}        &  equals \brac{sign}                      \cr
+  SA05  &  \f{>}        &  greater-than \brac{sign}                \cr
+  SM01  &  \f{\#}       &  number sign, or sharp\brac{sign}        \cr
+  SM02  &  \f{\%}       &  percent \brac{sign}                     \cr
+  SM03  &  \f{\&}       &  ampersand			           \cr
+  SM04  &  \f{*}        &  asterisk, or star                       \cr
+  SM05  &  \f{@}        &  commercial at, or at-sign               \cr
+  SM06  &  \f{[}        &  left \brac{square} bracket              \cr
+  SM07  &  \f{\\}       &  reverse solidus, or backslash           \cr
+  SM08  &  \f{]}        &  right \brac{square} bracket             \cr
+  SM11  &  \f{\{}       &  left curly bracket, or left brace       \cr
+  SM13  &  \f{|}        &  vertical bar                            \cr
+  SM14  &  \f{\}}       &  right curly bracket, or right brace     \cr
+  SD13  &  \f{`}        &  grave accent, or backquote              \cr
+  SD15  &  \f{\hat}     &  circumflex accent                       \cr
+  SD19  &  \f{~}        &  tilde                                   \cr
+}
+
+The graphic IDs are not used within \clisp,
+but are provided for cross reference purposes with {\ISOChars}.
+Note that the first letter of the graphic ID 
+categorizes the character as follows:
+L---Latin, N---Numeric, S---Special.
+
+\endSubsection%{Standard Characters}
+
+\endissue{CHARACTER-PROPOSAL:2-2-1}
+
+\beginSubsection{Character Syntax Types}
+\DefineSection{CharacterSyntaxTypes}
+
+%% 22.1.1 1
+
+The \term{Lisp reader} constructs an \term{object} 
+from the input text by interpreting each \term{character} 
+according to its \term{syntax type}.
+The \term{Lisp reader} cannot accept as input 
+everything that the \term{Lisp printer} produces,
+and the \term{Lisp reader} has features that are not used by the \term{Lisp printer}.
+The \term{Lisp reader} can be used as a lexical analyzer 
+for a more general user-written parser.
+
+%% 22.1.1 2
+%% 22.1.1 3
+When the \term{Lisp reader} is invoked, it reads a single character from 
+the \term{input} \term{stream} and dispatches according to the
+\newterm{syntax type} of that \term{character}.
+Every \term{character} that can appear in the \term{input} \term{stream}
+is of one of the \term{syntax types} shown in \figref\PossibleSyntaxTypes.
+
+\DefineFigure{PossibleSyntaxTypes}
+\showthree{Possible Character Syntax Types}{
+\term{constituent}&\term{macro character}&\term{single escape}\cr
+\term{invalid}&\term{multiple escape}&\term{whitespace}\meaning{2}\cr
+}
+
+The \term{syntax type} of a \term{character} in a \term{readtable}
+determines how that character is interpreted by the \term{Lisp reader}
+while that \term{readtable} is the \term{current readtable}.
+At any given time, every character has exactly one \term{syntax type}.
+
+%% 22.1.1 4
+%% 2.3.0 5
+\Figref\CharSyntaxTypesInStdSyntax\ 
+lists the \term{syntax type} of each \term{character} in \term{standard syntax}.
+
+\DefineFigure{CharSyntaxTypesInStdSyntax}
+%% 22.1.1 36
+{\def\w{\term{whitespace}\meaning{2}}
+\def\n{\term{non-terminating} \term{macro char}} %cheat on "char" => "character" to make fit
+\def\t{\term{terminating} \term{macro char}}     %ditto
+\def\c{\term{constituent}}
+\def\C{\term{constituent}*}
+\def\SE{\term{single escape}}
+\def\ME{\term{multiple escape}}
+\tablefigfour{Character Syntax Types in Standard Syntax}{character}{syntax type}{character}{syntax type}{
+Backspace&\c&0--9&\c\cr
+Tab&\w&:&\c\cr
+Newline&\w&;&\t\cr
+Linefeed&\w&{\tt<}&\c\cr
+Page&\w&=&\c\cr
+Return&\w&{\tt>}&\c\cr
+Space&\w&?&\C\cr
+!&\C&{\tt @}&\c\cr
+{\tt"}&\t&A--Z&\c\cr
+\#&\n&\f{[}&\C\cr
+\$&\c&\f{\\}&\SE\cr
+\%&\c&\f{]}&\C\cr
+\&&\c&\hat&\c\cr
+'&\t&\f{\_}&\c\cr
+(&\t&`&\t\cr
+)&\t&a--z&\c\cr
+{\tt*}&\c&\f{\{}&\C\cr
++&\c&\f{|}&\ME\cr
+,&\t&\f{\}}&\C\cr
+-&\c&\f{~}&\c\cr
+.&\c&Rubout&\c\cr
+/&\c\cr
+}}
+
+%% The next two paragraphs were mutually redundant, so I collapsed them into one. -kmp 17-Jan-92
+The characters marked with an asterisk (*) are initially \term{constituents},
+% but are reserved to the user for use as \term{macro characters} or for any other
+% desired purpose.
+%                     
+% Brackets (\f{[} and \f{]}),
+% braces   (\f{\{}, \f{\}}),
+% question mark (\f{?}),
+% and exclamation point (\f{!})
+% are defined to be constituents, 
+but they are not used in any standard \clisp\ notations.
+%!!! Maybe make a glossary term out of "reserved to the programmer"
+%    and discuss the issue of who the "programmer" is in the face of
+%    cascaded/layered/embedded implementations, some of which are conforming
+%    and some of which are not.
+These characters are explicitly reserved to the \term{programmer}.
+\f{~} is not used in \clisp, and reserved to implementors.
+\f{\$} and \f{\%} are \term{alphabetic}\meaning{2} \term{characters},
+but are not used in the names of any standard \clisp\ \term{defined names}.
+
+\term{Whitespace}\meaning{2} characters serve as separators but are otherwise
+ignored.  \term{Constituent} and \term{escape} \term{characters} are accumulated
+to make a \term{token}, which is then interpreted as a \term{number} or \term{symbol}.
+\term{Macro characters} trigger the invocation of \term{functions} (possibly
+user-supplied) that can perform arbitrary parsing actions.
+\term{Macro characters} are divided into two kinds,
+\term{terminating} and \term{non-terminating},
+depending on whether or not they terminate a \term{token}.
+The following are descriptions of each kind of \term{syntax type}.
+
+\beginsubsubsection{Constituent Characters}
+\DefineSection{ConstituentChars}
+
+\term{Constituent} \term{characters} are used in \term{tokens}.
+%% Sandra didn't like this wording, and wanted "representation of" added. -kmp 19-Nov-91
+%A \term{token} is a \term{number} or a \term{symbol} name.
+A \newterm{token} is a representation of a \term{number} or a \term{symbol}.  
+Examples of \term{constituent} \term{characters} are letters and digits.
+
+%% 2.3.0 6
+Letters in symbol names are sometimes converted to 
+letters in the opposite \term{case} when the name is read;
+\seesection\ReadtableCaseReadEffect.
+\term{Case} conversion can be suppressed by the use 
+of \term{single escape} or \term{multiple escape} characters.
+%% Moved to the section "Case in Symbols" -kmp 25-Jan-92
+% The \term{symbols} that correspond to \clisp\ \term{defined names}
+% have uppercase names even though their names generally appear
+% in lowercase in this document.
+
+\beginsubsubsection{Constituent Traits}
+\DefineSection{ConstituentTraits}
+
+Every \term{character} has one or more \term{constituent traits}
+that define how the \term{character} is to be interpreted by the \term{Lisp reader}
+when the \term{character} is a \term{constituent} \term{character}.
+These \term{constituent traits} are 
+     \term{alphabetic}\meaning{2},                  
+     digit,
+     \term{package marker},
+     plus sign,
+     minus sign, 
+     dot,
+     decimal point,
+     \term{ratio marker},
+     \term{exponent marker},
+ and \term{invalid}.
+\Figref\ConstituentTraitsOfStdChars\ shows the \term{constituent traits}
+of the \term{standard characters}
+and of certain \term{semi-standard} \term{characters};
+% I added this next to clarify.  It effectively says the same thing in SET-SYNTAX-FROM-CHAR.
+% -kmp 28-Jan-92
+no mechanism is provided for changing the \term{constituent trait} of a \term{character}.
+Any \term{character} with the alphadigit \term{constituent trait}
+in that figure is a digit if the \term{current input base} is greater
+than that character's digit value,
+otherwise the \term{character} is \term{alphabetic}\meaning{2}.  
+%\term{Alphabetic}\meaning{2} \term{constituents} are valid
+%\term{characters} for \term{symbol} \term{names}.  
+Any \term{character} quoted by a \term{single escape} 
+is treated as an \term{alphabetic}\meaning{2} constituent, regardless of its normal syntax.
+
+\DefineFigure{ConstituentTraitsOfStdChars}
+\boxfig
+{\dimen0=.75pc
+\def\a{\term{alphabetic}\meaning{2}}
+\def\ad{alphadigit}
+\def\i{\term{invalid}}
+\def\pm{\term{package marker}}
+\tabskip \dimen0
+\halign to \hsize {#\hfil\tabskip \dimen0&#\hfil\tabskip 0pt plus 1fil
+&#\hfil\tabskip \dimen0&#\hfil\cr
+\noalign{\vskip -9pt}
+\bf constituent&\bf traits&\bf constituent&\bf traits\cr
+\bf character&&\bf character\cr
+\noalign{\vskip 2pt\hrule\vskip 2pt}
+Backspace&\i&\f{\{}&\a\cr
+Tab&\i*&\f{\}}&\a\cr
+Newline&\i*&+&\a, plus sign\cr
+Linefeed&\i*&-&\a, minus sign\cr
+Page&\i*&.&\a, dot, decimal point\cr
+Return&\i*&/&\a, \term{ratio marker}\cr
+Space&\i*&A, a&\ad\cr
+! &\a&B, b&\ad\cr
+{\tt "}&\a*&C, c&\ad\cr
+\#&\a*&D, d&\ad, double-float \term{exponent marker}\cr
+\$&\a&E, e&\ad, float \term{exponent marker}\cr
+\%&\a&F, f&\ad, single-float \term{exponent marker}\cr
+\&&\a&G, g&\ad\cr
+'&\a*&H, h&\ad\cr
+(&\a*&I, i&\ad\cr
+)&\a*&J, j&\ad\cr
+{\tt *}&\a&K, k&\ad\cr
+,&\a*&L, l&\ad, long-float \term{exponent marker}\cr
+0-9&\ad&M, m&\ad\cr
+:&\pm&N, n&\ad\cr
+;&\a*&O, o&\ad\cr
+{\tt<}&\a&P, p&\ad\cr
+=&\a&Q, q&\ad\cr
+{\tt>}&\a&R, r&\ad\cr
+?&\a&S, s&\ad, short-float \term{exponent marker}\cr
+\f{@}&\a&T, t&\ad\cr
+\f{[}&\a&U, u&\ad\cr
+\f{\\}&\a*&V, v&\ad\cr
+\f{]}&\a&W, w&\ad\cr
+\hat&\a&X, x&\ad\cr
+\f{\_}&\a&Y, y&\ad\cr
+`&\a*&Z, z&\ad\cr
+\f{|}&\a*&Rubout&\i\cr
+\f{~}&\a\cr
+\noalign{\vskip -9pt}
+}}
+\caption{Constituent Traits of Standard Characters and Semi-Standard Characters}
+\endfig
+                   
+The interpretations in this table apply only to \term{characters}
+whose \term{syntax type} is \term{constituent}.
+Entries marked with an asterisk (*) are normally \term{shadowed}\meaning{2} 
+because the indicated \term{characters} are of \term{syntax type}
+\term{whitespace}\meaning{2},
+\term{macro character},
+\term{single escape},
+or \term{multiple escape};
+these \term{constituent traits} apply to them only if their \term{syntax types} 
+are changed to \term{constituent}.
+
+\endsubsubsection%{Constituent Traits}
+
+\endsubsubsection%{Constituent Characters}
+ 
+\beginsubsubsection{Invalid Characters}
+\DefineSection{InvalidChars}
+
+\term{Characters} with the \term{constituent trait} \term{invalid} 
+cannot ever appear in a \term{token} 
+except under the control of a \term{single escape} \term{character}.
+If an \term{invalid} \term{character} is encountered while an \term{object} is
+being read, an error \oftype{reader-error} is signaled.
+If an \term{invalid} \term{character} is preceded by a \term{single escape} \term{character},
+it is treated as an \term{alphabetic}\meaning{2} \term{constituent} instead.
+
+\endsubsubsection%{Invalid Characters}
+
+\beginsubsubsection{Macro Characters}
+\DefineSection{MacroChars}
+
+When the \term{Lisp reader} encounters a \term{macro character} 
+on an \term{input} \term{stream},
+special parsing of subsequent \term{characters} 
+on the \term{input} \term{stream} 
+is performed.
+
+A \term{macro character} has an associated \term{function}
+called a \newterm{reader macro function} that implements its specialized parsing behavior.
+An association of this kind can be established or modified under control of
+a \term{conforming program} by using 
+\thefunctions{set-macro-character} and \funref{set-dispatch-macro-character}.
+
+Upon encountering a \term{macro character}, the \term{Lisp reader} calls its
+\term{reader macro function}, which parses one specially formatted object 
+from the \term{input} \term{stream}.
+The \term{function} either returns the parsed \term{object},
+or else it returns no \term{values} 
+    to indicate that the characters scanned by the \term{function}
+    are being ignored (\eg in the case of a comment).
+Examples of \term{macro characters}
+are \term{backquote}, \term{single-quote}, \term{left-parenthesis}, and 
+\term{right-parenthesis}.
+
+A \term{macro character} is either \term{terminating} or \term{non-terminating}.
+The difference between \term{terminating} and \term{non-terminating} \term{macro characters} 
+lies in what happens when such characters occur in the middle of a \term{token}.  
+If a \newterm{non-terminating} \term{macro character} occurs in the middle of a \term{token},
+the \term{function} associated 
+with the \term{non-terminating} \term{macro character} is not called,
+and the
+\term{non-terminating} \term{macro character} does not terminate the \term{token}'s name; it
+becomes part of the name as if the \term{macro character} were really a constituent
+character.  A \newterm{terminating} \term{macro character} terminates any \term{token},
+and its associated \term{reader macro function}
+is called no matter where the \term{character} appears.
+The only \term{non-terminating} \term{macro character} in \term{standard syntax} 
+is \term{sharpsign}.
+
+If a \term{character} is a \term{dispatching macro character} $C\sub 1$,
+its \term{reader macro function} is a \term{function} supplied by the \term{implementation}.
+This \term{function} reads decimal \term{digit} \term{characters} until a non-\term{digit}
+$C\sub 2$ is read.
+If any \term{digits} were read,
+they are converted into a corresponding \term{integer} infix parameter $P$;
+otherwise, the infix parameter $P$ is \nil.  
+The terminating non-\term{digit} $C\sub 2$ is a \term{character} 
+(sometimes called a ``sub-character'' to emphasize its subordinate role in the dispatching)
+that is looked up in the dispatch table associated with
+the \term{dispatching macro character} $C\sub 1$.
+The \term{reader macro function} associated with the sub-character $C\sub 2$ 
+is invoked with three arguments:
+     the \term{stream},
+     the sub-character $C\sub 2$,
+ and the infix parameter $P$.
+For more information about dispatch characters,
+\seefun{set-dispatch-macro-character}.
+
+For information about the \term{macro characters} 
+that are available in \term{standard syntax},
+\seesection\StandardMacroChars.
+
+\endsubsubsection%{Macro Characters}
+
+\beginsubsubsection{Multiple Escape Characters}
+\DefineSection{MultipleEscapeChar}
+
+A pair of \newterm{multiple escape} \term{characters}
+is used to indicate that an enclosed sequence of characters,
+including possible \term{macro characters} and \term{whitespace}\meaning{2} \term{characters},
+are to be treated as \term{alphabetic}\meaning{2} \term{characters} 
+with \term{case} preserved.
+Any \term{single escape} and \term{multiple escape} \term{characters} 
+that are to appear in the sequence must be preceded by a \term{single escape} 
+\term{character}.  
+
+\term{Vertical-bar} is a \term{multiple escape} \term{character}
+in \term{standard syntax}.
+
+\beginsubsubsubsection{Examples of Multiple Escape Characters}
+
+\code
+ ;; The following examples assume the readtable case of *readtable* 
+ ;; and *print-case* are both :upcase.
+ (eq 'abc 'ABC) \EV \term{true}
+ (eq 'abc '|ABC|) \EV \term{true}
+ (eq 'abc 'a|B|c) \EV \term{true}
+ (eq 'abc '|abc|) \EV \term{false}
+\endcode
+
+\endsubsubsubsection%{Examples of Multiple Escape Characters}
+
+\endsubsubsection%{Multiple Escape Characters}
+
+\beginsubsubsection{Single Escape Character}
+\DefineSection{SingleEscapeChar}
+
+A \newterm{single escape} is used to indicate that 
+the next \term{character} is to be treated as 
+an \term{alphabetic}\meaning{2} \term{character}
+with its \term{case} preserved,
+no matter what the \term{character} is 
+or which \term{constituent traits} it has.  
+
+%% "slash" => "backslash" as an editorial change per Boyer/Kaufmann/Moore #4.
+%% This was right everywhere else in the manual--shame for it to be wrong here.
+%% -kmp 9-May-94
+\term{Backslash} is a \term{single escape} \term{character} in \term{standard syntax}.
+
+\beginsubsubsubsection{Examples of Single Escape Characters}
+
+\code
+ ;; The following examples assume the readtable case of *readtable* 
+ ;; and *print-case* are both :upcase.
+ (eq 'abc '\\A\\B\\C) \EV \term{true}
+ (eq 'abc 'a\\Bc) \EV \term{true}
+ (eq 'abc '\\ABC) \EV \term{true}
+ (eq 'abc '\\abc) \EV \term{false}
+\endcode
+
+\endsubsubsubsection%{Examples of Single Escape Characters}
+
+\endsubsubsection%{Single Escape Character}
+
+\beginsubsubsection{Whitespace Characters}
+\DefineSection{WhitespaceChars}
+
+\term{Whitespace}\meaning{2} \term{characters} are used to separate \term{tokens}.
+
+\term{Space} and \term{newline} are \term{whitespace}\meaning{2} \term{characters}
+in \term{standard syntax}.
+
+\beginsubsubsubsection{Examples of Whitespace Characters}
+
+\code
+ (length '(this-that)) \EV 1
+ (length '(this - that)) \EV 3
+ (length '(a
+           b)) \EV 2
+ (+ 34) \EV 34
+ (+ 3 4) \EV 7
+\endcode
+
+\endsubsubsubsection%{Examples of Whitespace Characters}
+
+\endsubsubsection%{Whitespace Characters}
+
+\endSubsection%{Character Syntax Types}

concept-systems.tex

@@ -0,0 +1,130 @@
+% -*- Mode: TeX -*-
+
+\beginsubsection{Loading}
+
+%% 23.4.0 1
+To \funref{load} a \term{file} is to treat its contents as \term{code}
+and \term{execute} that \term{code}.
+The \term{file} may contain \newterm{source code} or \newterm{compiled code}.
+
+A \term{file} containing \term{source code} is called a \newterm{source file}.
+\term{Loading} a \term{source file} is accomplished essentially 
+by sequentially \term{reading}\meaning{2} the \term{forms} in the file,
+\term{evaluating} each immediately after it is \term{read}.
+
+%% 23.4.0 2
+A \term{file} containing \term{compiled code} is called a \newterm{compiled file}.
+\term{Loading} a \term{compiled file} is similar to \term{loading} a \term{source file},
+except that the \term{file} does not contain text but rather an
+\term{implementation-dependent} representation of pre-digested \term{expressions}
+created by the \term{compiler}.  Often, a \term{compiled file} can be \term{loaded}
+more quickly than a \term{source file}.
+\Seesection\Compilation.
+
+The way in which a \term{source file} is distinguished from a \term{compiled file} 
+is \term{implementation-dependent}.
+
+\endsubsection%{Loading}
+
+\beginsubsection{Features}
+\DefineSection{Features}
+
+A \newterm{feature} is an aspect or attribute
+     of \clisp, 
+     of the \term{implementation},
+  or of the \term{environment}.
+A \term{feature} is identified by a \term{symbol}.
+
+A \term{feature} is said to be \newterm{present} in a \term{Lisp image}
+if and only if the \term{symbol} naming it is an \term{element} of the
+\term{list} held by \thevariable{*features*}, 
+which is called the \newterm{features list}.
+
+\beginsubsubsection{Feature Expressions}
+\DefineSection{FeatureExpressions}
+
+Boolean combinations of \term{features}, called \newtermidx{feature expressions}{feature expression},
+are used by the \f{\#+} and \f{\#-} \term{reader macros} in order to
+direct conditional \term{reading} of \term{expressions} by the \term{Lisp reader}.
+
+The rules for interpreting a \term{feature expression} are as follows:
+
+\beginlist
+
+\itemitem{\term{feature}}
+
+If a \term{symbol} naming a \term{feature} is used as a \term{feature expression},
+the \term{feature expression} succeeds if that \term{feature} is \term{present};
+otherwise it fails.
+
+\itemitem{\f{(not \param{feature-conditional})}}
+
+A \misc{not} \term{feature expression} succeeds 
+if its argument \param{feature-conditional} fails;
+otherwise, it succeeds.
+
+\itemitem{\f{(and \starparam{feature-conditional})}}
+
+An \misc{and} \term{feature expression} succeeds 
+if all of its argument \param{feature-conditionals} succeed;
+otherwise, it fails.
+
+\itemitem{\f{(or \starparam{feature-conditional})}}
+
+An \misc{or} \term{feature expression} succeeds 
+if any of its argument \param{feature-conditionals} succeed;
+otherwise, it fails.
+
+\endlist
+
+\beginsubsubsubsection{Examples of Feature Expressions}
+\DefineSection{FeatureExpExamples}
+%% 22.1.4 40
+For example, suppose that
+ in \term{implementation} A, the \term{features} \f{spice} and \f{perq} are \term{present},
+			     but the \term{feature} \f{lispm} is not \term{present};
+ in \term{implementation} B, the feature \f{lispm} is \term{present},
+			     but the \term{features} \f{spice} and \f{perq} are
+			      not \term{present};
+ and 
+ in \term{implementation} C, none of the features \f{spice}, \term{lispm}, or \f{perq} are
+			     \term{present}.
+\Thenextfigure\ shows some sample \term{expressions}, and how they would be 
+\term{read}\meaning{2} in these \term{implementations}.
+
+\showtwo{Features examples}{
+\f{(cons \#+spice "Spice" \#-spice "Lispm" x)} \span \cr
+\noalign{\vskip 2pt}
+\quad in \term{implementation} A $\ldots$ & \f{(CONS "Spice" X)} \cr
+\quad in \term{implementation} B $\ldots$ & \f{(CONS "Lispm" X)} \cr
+\quad in \term{implementation} C $\ldots$ & \f{(CONS "Lispm" X)} \cr
+\noalign{\vskip 5pt}
+\f{(cons \#+spice "Spice" \#+LispM "Lispm" x)} \span \cr
+\noalign{\vskip 2pt}
+\quad in \term{implementation} A $\ldots$ & \f{(CONS "Spice" X)} \cr
+\quad in \term{implementation} B $\ldots$ & \f{(CONS "Lispm" X)} \cr
+\quad in \term{implementation} C $\ldots$ & \f{(CONS X)} \cr
+\noalign{\vskip 5pt}
+\f{(setq a '(1 2 \#+perq 43 \#+(not perq) 27))} \span \cr
+\noalign{\vskip 2pt}
+\quad in \term{implementation} A $\ldots$ & \f{(SETQ A '(1 2 43))} \cr
+\quad in \term{implementation} B $\ldots$ & \f{(SETQ A '(1 2 27))} \cr
+\quad in \term{implementation} C $\ldots$ & \f{(SETQ A '(1 2 27))} \cr
+\noalign{\vskip 5pt}
+\f{(let ((a 3) \#+(or spice lispm) (b 3)) (foo a))} \span \cr
+\noalign{\vskip 2pt}
+\quad in \term{implementation} A $\ldots$ & \f{(LET ((A 3) (B 3)) (FOO A))} \cr
+\quad in \term{implementation} B $\ldots$ & \f{(LET ((A 3) (B 3)) (FOO A))} \cr
+\quad in \term{implementation} C $\ldots$ & \f{(LET ((A 3)) (FOO A))} \cr
+\noalign{\vskip 5pt}
+\f{(cons \#+Lispm "\#+Spice" \#+Spice "foo" \#-(or Lispm Spice) 7 x)} \span \cr
+\noalign{\vskip 2pt}
+\quad in \term{implementation} A $\ldots$ & \f{(CONS "foo" X)}      \cr
+\quad in \term{implementation} B $\ldots$ & \f{(CONS "\#+Spice" X)} \cr
+\quad in \term{implementation} C $\ldots$ & \f{(CONS 7 X)}          \cr
+}
+\endsubsubsubsection%{Examples of Feature Expressions}
+
+\endsubsubsection%{Feature Expressions}
+
+\endsubsection%{Features}

concept-tests.tex

@@ -0,0 +1,157 @@
+% -*- Mode: TeX -*-
+%% Rules about Test Functions
+
+\beginsubsection{Satisfying a Two-Argument Test}
+\DefineSection{SatisfyingTheTwoArgTest}
+
+When an \term{object} $O$ is being considered iteratively 
+against each \term{element} $E\sub i$
+of a \term{sequence} $S$
+by an \term{operator} $F$ listed in \thenextfigure,
+it is sometimes useful to control the way in which the presence of $O$ 
+is tested in $S$ is tested by $F$.
+This control is offered on the basis of a \term{function} designated with 
+either a \kwd{test} or \kwd{test-not} \term{argument}.
+
+%!!! Sandra wonders if this table is complete.
+\displaythree{Operators that have Two-Argument Tests to be Satisfied}{
+adjoin&nset-exclusive-or&search\cr
+assoc&nsublis&set-difference\cr
+count&nsubst&set-exclusive-or\cr
+delete&nsubstitute&sublis\cr
+find&nunion&subsetp\cr
+intersection&position&subst\cr
+member&pushnew&substitute\cr
+mismatch&rassoc&tree-equal\cr
+nintersection&remove&union\cr
+nset-difference&remove-duplicates&\cr
+}
+
+The object $O$ might not be compared directly to $E\sub i$.
+If a \kwd{key} \term{argument} is provided,
+it is a \term{designator} for a \term{function} of one \term{argument} 
+to be called with each $E\sub i$ as an \term{argument}, 
+and \term{yielding} an \term{object} $Z\sub i$ to be used for comparison.
+(If there is no \kwd{key} \term{argument}, $Z\sub i$ is $E\sub i$.)
+
+% Added per Barmar. -kmp 16-Feb-92
+The \term{function} designated by \thekeyarg{key} is never called on $O$ itself.
+However, if the function operates on multiple sequences
+(\eg as happens in \funref{set-difference}), $O$
+will be the result of calling the \kwd{key} function on an
+\term{element} of the other sequence.  
+
+A \kwd{test} \term{argument}, if supplied to $F$,
+is a \term{designator} for a  \term{function}
+of two \term{arguments}, $O$ and $Z\sub i$.
+An $E\sub i$ is said (or, sometimes, an $O$ and an $E\sub i$ are said)
+to \newterm{satisfy the test} 
+if this \kwd{test} \term{function} returns a \term{generalized boolean} representing 
+\term{true}.
+
+A \kwd{test-not} \term{argument}, if supplied to $F$, 
+is \term{designator} for a \term{function} 
+of two \term{arguments}, $O$ and $Z\sub i$.
+An $E\sub i$ is said (or, sometimes, an $O$ and an $E\sub i$ are said)
+to \newterm{satisfy the test} 
+if this \kwd{test-not} \term{function}
+returns a \term{generalized boolean} representing \term{false}.
+
+If neither a \kwd{test} nor a \kwd{test-not} \term{argument} is supplied, 
+it is as if a \kwd{test} argument of \f{\#'eql} was supplied.
+
+The consequences are unspecified if both a \kwd{test} and a \kwd{test-not} \term{argument}
+are supplied in the same \term{call} to $F$.
+
+\beginsubsubsection{Examples of Satisfying a Two-Argument Test}
+
+\code
+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'equal)
+\EV (foo bar "BAR" "foo" "bar")
+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'equalp)
+\EV (foo bar "BAR" "bar")
+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'string-equal)
+\EV (bar "BAR" "bar")
+ (remove "FOO" '(foo bar "FOO" "BAR" "foo" "bar") :test #'string=)
+\EV (BAR "BAR" "foo" "bar")
+
+ (remove 1 '(1 1.0 #C(1.0 0.0) 2 2.0 #C(2.0 0.0)) :test-not #'eql)
+\EV (1)
+ (remove 1 '(1 1.0 #C(1.0 0.0) 2 2.0 #C(2.0 0.0)) :test-not #'=)
+\EV (1 1.0 #C(1.0 0.0))
+ (remove 1 '(1 1.0 #C(1.0 0.0) 2 2.0 #C(2.0 0.0)) :test (complement #'=))
+\EV (1 1.0 #C(1.0 0.0))
+
+ (count 1 '((one 1) (uno 1) (two 2) (dos 2)) :key #'cadr) \EV 2
+
+ (count 2.0 '(1 2 3) :test #'eql :key #'float) \EV 1
+
+ (count "FOO" (list (make-pathname :name "FOO" :type "X")  
+                    (make-pathname :name "FOO" :type "Y"))
+        :key #'pathname-name
+        :test #'equal)
+\EV 2
+\endcode
+
+\endsubsubsection%{Examples of Satisfying a Two-Argument Test}
+
+\endsubsection%{Satisfying a Two-Argument Test}
+
+\beginsubsection{Satisfying a One-Argument Test}
+\DefineSection{SatisfyingTheOneArgTest}
+
+When using one of the \term{functions} in \thenextfigure,
+the elements $E$ of a \term{sequence} $S$ are filtered
+not on the basis of the presence or absence of an object $O$ 
+under a two \term{argument} \term{predicate},
+as with the \term{functions} described in \secref\SatisfyingTheTwoArgTest,
+but rather on the basis of a one \term{argument} \term{predicate}.
+
+%!!! KMP wonders if this table is complete.
+\displaythree{Operators that have One-Argument Tests to be Satisfied}{
+assoc-if&member-if&rassoc-if\cr
+assoc-if-not&member-if-not&rassoc-if-not\cr
+count-if&nsubst-if&remove-if\cr
+count-if-not&nsubst-if-not&remove-if-not\cr
+delete-if&nsubstitute-if&subst-if\cr
+delete-if-not&nsubstitute-if-not&subst-if-not\cr
+find-if&position-if&substitute-if\cr
+find-if-not&position-if-not&substitute-if-not\cr
+}
+
+The element $E\sub i$ might not be considered directly.
+If a \kwd{key} \term{argument} is provided,
+it is a \term{designator} for a \term{function} of one \term{argument} 
+to be called with each $E\sub i$ as an \term{argument}, 
+and \term{yielding} an \term{object} $Z\sub i$ to be used for comparison.
+(If there is no \kwd{key} \term{argument}, $Z\sub i$ is $E\sub i$.)
+
+\term{Functions} defined in this specification and having a name that
+ends in ``\f{-if}'' accept a first \term{argument} that is a \term{designator} for a 
+\term{function} of one \term{argument}, $Z\sub i$.
+An $E\sub i$ is said to \newterm{satisfy the test} if this \kwd{test} \term{function}
+returns a \term{generalized boolean} representing \term{true}.
+
+\term{Functions} defined in this specification and having a name that
+ends in ``\f{-if-not}'' accept a first \term{argument} that is a \term{designator} for a 
+\term{function} of one \term{argument}, $Z\sub i$.
+An $E\sub i$ is said to \newterm{satisfy the test} if this \kwd{test} \term{function}
+returns a \term{generalized boolean} representing \term{false}.
+
+\beginsubsubsection{Examples of Satisfying a One-Argument Test}
+
+\code
+ (count-if #'zerop '(1 #C(0.0 0.0) 0 0.0d0 0.0s0 3)) \EV 4
+
+ (remove-if-not #'symbolp '(0 1 2 3 4 5 6 7 8 9 A B C D E F))
+\EV (A B C D E F)
+ (remove-if (complement #'symbolp) '(0 1 2 3 4 5 6 7 8 9 A B C D E F))
+\EV (A B C D E F)
+
+ (count-if #'zerop '("foo" "" "bar" "" "" "baz" "quux") :key #'length)
+\EV 3
+\endcode
+
+\endsubsubsection%{Examples of Satisfying a One-Argument Test}
+
+\endsubsection%{Satisfying a One-Argument Test}

concept-tokens.tex

@@ -0,0 +1,672 @@
+% -*- Mode: TeX -*-
+%% Interpretation of Tokens
+
+\beginsubsection{Numbers as Tokens}
+
+%% 22.1.2 1
+%% 22.1.2 2
+When a \term{token} is read,
+it is interpreted as a \term{number} or \term{symbol}.
+The \term{token} is interpreted as a \term{number} if it satisfies
+the syntax for numbers specified in \thenextfigure.
+%\term{Whitespace}\meaning{2}, macro, and escape
+%characters are treated as \term{alphabetic}\meaning{2} within an extended \term{token}
+%unless preceded by an escape character.
+
+\DefineFigure{SyntaxForNumericTokens}
+%% 2.1.2 3
+%% 2.1.2 4
+%% 22.1.2 3
+\boxfig
+{\advance\baselineskip by 2.5pt
+\halign{{\hskip 2pc}#\hfil&#\hfil&#\hfil\cr
+ \param{numeric-token}   & ::$=$ & \down{integer} $\vert$ 
+				   \down{ratio}   $\vert$
+				   \down{float}   \cr
+ \param{integer}         & ::$=$ & \ttbrac{\param{sign}} 
+				   \plusparam{decimal-digit} 
+				   \param{decimal-point} $\vert$
+				   \ttbrac{\param{sign}} 
+				   \plusparam{digit} \cr
+%  \param{integer}         & ::$=$ & \ttbrac{\param{sign}} 
+% 				   \plus{\curly{\param{digit}}}
+% 				   \ttbrac{\param{decimal-point}} \cr
+ \param{ratio}           & ::$=$ & \ttbrac{\param{sign}}
+				   \plus{\curly{\param{digit}}}
+				   \param{slash} 
+				   \plus{\curly{\param{digit}}}   \cr
+ \param{float}           & ::$=$ & \ttbrac{\param{sign}}
+				   \star{\curly{\param{decimal-digit}}}
+				   \param{decimal-point}
+				   \plus{\curly{\param{decimal-digit}}}
+				   \ttbrac{\down{exponent}}      \cr
+		         &       & $\vert\;$
+				   \ttbrac{\param{sign}}
+				   \plus{\curly{\param{decimal-digit}}} 
+				   \ttbrac{\param{decimal-point} 
+					   \star{\curly{\param{decimal-digit}}}}
+				   \down{exponent} \cr
+ \param{exponent}        & ::$=$ & \param{exponent-marker}
+				   \ttbrac{\param{sign}}
+				   \plus{\curly{\param{digit}}}   \cr
+ \noalign{\vskip 5pt}
+ \param{sign}---a \term{sign}.\span\span\cr
+ \param{slash}---a \term{slash}\span\span\cr
+ \param{decimal-point}---a \term{dot}.\span\span\cr
+ \param{exponent-marker}---an \term{exponent marker}.\span\span\cr
+ \param{decimal-digit}---a \term{digit} in \term{radix} \f{10}.\span\span\cr
+ \param{digit}---a \term{digit} in the \term{current input radix}.\span\span\cr
+}}
+\caption{Syntax for Numeric Tokens}
+\endfig
+
+\beginsubsubsection{Potential Numbers as Tokens}
+\DefineSection{PotentialNumbersAsTokens}
+
+%% 22.1.2 3
+%% 22.1.2 4
+To allow implementors and future \clisp\ standards
+to extend the syntax of numbers, a
+syntax for \term{potential numbers} is defined that is
+more general than the syntax for numbers.
+A \term{token} is a \term{potential number} if it satisfies all of the following
+requirements:
+
+%% 22.1.2 5
+\beginlist
+\item{1.}
+The \term{token} consists entirely of 
+  \term{digits},
+  \term{signs},
+  \term{ratio markers},
+  decimal points (\f{.}),
+  extension characters (\hat\ or \f{\_}),
+  and number markers.
+A number marker is a letter. 
+Whether a letter may be treated as a number marker depends on context,
+but no letter that is adjacent to another letter may ever be treated as a number marker.
+\term{Exponent markers} are number markers.
+
+%% 22.1.2 6
+\item{2.}
+The \term{token} contains at least one digit.  Letters may be considered to be
+digits, depending on the \term{current input base}, but only
+in \term{tokens} containing no decimal points.
+
+
+%% 22.1.2 7
+\item{3.}
+The \term{token} begins with a \term{digit}, \term{sign}, decimal point, or extension character,
+\issue{COLON-NUMBER}
+\reviewer{Barmar: This section is unnecessary because the first bullet already 
+		  omits discussion of a colon (\term{package marker}).}%!!!
+but not a 
+%colon.
+\term{package marker}.
+The syntax involving a leading 
+%colon
+\term{package marker} followed by a \term{potential number} is
+not well-defined. The consequences of the use 
+of notation such as \f{:1}, \f{:1/2}, and \f{:2{\hat}3} in a
+position where an expression appropriate for \funref{read} 
+is expected are unspecified.
+\endissue{COLON-NUMBER}
+
+%% 22.1.2 8
+\item{4.}
+The \term{token} does not end with a sign.
+\endlist
+
+%% 22.1.2 10
+If a \term{potential number} has number syntax, 
+a \term{number} of the appropriate type is constructed and returned, 
+if the \term{number} is representable in an implementation.
+A \term{number} will not be representable in an implementation 
+if it is outside the boundaries set by the \term{implementation-dependent} 
+constants for \term{numbers}.
+For example, specifying too large or too small an exponent for a \term{float}
+may make the \term{number} impossible to represent in the implementation.
+A \term{ratio} with denominator zero (such as \f{-35/000})
+is not represented in any implementation.
+When a \term{token} with the syntax of a number cannot be converted to an internal
+\term{number}, an error \oftype{reader-error} is signaled.  An error
+must not be signaled for specifying too many significant digits
+for a \term{float}; a truncated or rounded value should be produced.
+
+%% 22.1.2 11
+%% 22.1.2 12
+If there is an ambiguity as to whether
+a letter should be treated as a digit or as a number marker,
+the letter is treated as a digit.
+
+\beginsubsubsubsection{Escape Characters and Potential Numbers}
+\DefineSection{EscCharsAndPotentialNums}
+%% This section moved from 22.1.2 per Loosemore #11 (first public review). -kmp 10-May-93
+
+%% 22.1.2 9
+%The printed representation for
+A \term{potential number} cannot contain any \term{escape}
+\term{characters}.  An \term{escape} \term{character} robs the following
+\term{character} of all syntactic qualities, forcing it to be strictly
+\term{alphabetic}\meaning{2} and therefore unsuitable for use in a
+\term{potential number}.  For example, all of the following
+representations are interpreted as \term{symbols}, not \term{numbers}:
+
+\code
+ \\256   25\\64   1.0\\E6   |100|   3\\.14159   |3/4|   3\\/4   5||
+\endcode
+
+In each case, removing the \term{escape} \term{character} (or \term{characters}) 
+would 
+%% Kent and Sandra agreed that the following word change was editorial
+%% and would de-mystify the intent. -kmp 12-May-93
+%allow the token to be treated as a \term{number}.
+cause the token to be a \term{potential number}.
+
+\endsubsubsubsection%{Escape Characters and Potential Numbers}
+
+\beginsubsubsubsection{Examples of Potential Numbers}
+
+As examples, the \term{tokens} in \thenextfigure\ are \term{potential numbers},
+but they are not actually numbers, and so are reserved \term{tokens};
+a \term{conforming implementation} is permitted, but not required,
+to define their meaning.
+
+\showfive{Examples of reserved tokens}{
+\f{1b5000}    & \f{777777q}     & \f{1.7J} & \f{-3/4+6.7J} & \f{12/25/83}\cr
+\f{27{\hat}19} & \f{3{\hat}4/5}   & \f{6//7} & \f{3.1.2.6}   & \f{{\hat}-43\hat}\cr
+\f{3.141_592_653_589_793_238_4} & \f{-3.7+2.6i-6.17j+19.6k}\cr
+}
+
+
+The \term{tokens} in \thenextfigure\ are not \term{potential numbers}; 
+they are always treated as \term{symbols}:
+
+\showfive{Examples of symbols}{
+\f{/}    & \f{/5}    & \f{+}  & \f{1+}   & \f{1-}\cr
+\f{foo+} & \f{ab.cd} & \f{\_} & \f{\hat} & \f{{\hat}/-}\cr
+}
+                                  
+The \term{tokens} in \thenextfigure\ are \term{potential numbers}
+if the \term{current input base} is \f{16}, 
+but they are always treated as \term{symbols} if the \term{current input base} is \f{10}. 
+
+\showfive{Examples of symbols or potential numbers}{
+\f{bad-face} & \f{25-dec-83} & \f{a/b} & \f{fad_cafe} & \f{f{\hat}}\cr
+}
+
+\endsubsubsubsection%{Examples of Potential Numbers}
+
+\endsubsubsection%{Potential Numbers}
+
+\endsubsection%{Numbers as Tokens}
+
+\beginsubsection{Constructing Numbers from Tokens}
+\DefineSection{NumsFromTokens}
+
+A \term{real} is constructed directly from a corresponding numeric \term{token};
+\seefigure\SyntaxForNumericTokens.
+
+A \term{complex} is notated as a \f{\#C} (or \f{\#c}) followed by a \term{list}
+of two \term{reals}; \seesection\SharpsignC.
+
+The \term{reader macros} \f{\#B}, \f{\#O}, \f{\#X}, and \f{\#R} may also be useful
+in controlling the input \term{radix} in which \term{rationals} are parsed;
+ \seesection\SharpsignB,
+     \secref\SharpsignO,
+     \secref\SharpsignX,
+ and \secref\SharpsignR.
+
+This section summarizes the full syntax for \term{numbers}.
+
+\beginsubsubsection{Syntax of a Rational}
+
+\beginsubsubsubsection{Syntax of an Integer}
+\DefineSection{SyntaxOfIntegers}
+
+%% 2.1.2 3
+
+% \term{Integers} can be written as a sequence of digits, optionally
+% preceded by a sign and optionally followed by a decimal point;
+% \seefigure\SyntaxForNumericTokens.
+
+\term{Integers} can be written as a sequence of \term{digits}, 
+optionally preceded by a \term{sign} and optionally followed by a decimal point;
+\seefigure\SyntaxForNumericTokens.
+When a decimal point is used,
+the \term{digits} are taken to be in \term{radix} \f{10};
+when no decimal point is used,
+the \term{digits} are taken to be in radix given by the \term{current input base}.
+
+For information on how \term{integers} are printed, \seesection\PrintingIntegers.
+
+\endsubsubsubsection%{Syntax of an Integer}
+
+\beginsubsubsubsection{Syntax of a Ratio}
+\DefineSection{SyntaxOfRatios}
+
+\term{Ratios} can be written as an optional \term{sign} followed by two
+non-empty sequences of \term{digits} separated by a \term{slash};
+\seefigure\SyntaxForNumericTokens.
+%% 2.1.2 4
+The second sequence may not consist
+entirely of zeros.
+%The same radix specifiers
+%(one of \f{\#\param{nn}R}, \f{\#O}, \f{\#B}, or \f{\#X}) as for 
+%\term{integers}
+%are used to notate \term{ratios} in radices other than ten.
+Examples of \term{ratios} are in \thenextfigure.
+
+\showtwo{Examples of Ratios}{
+\f{2/3}                & ;This is in canonical form                   \cr
+\f{4/6}                & ;A non-canonical form for 2/3                \cr
+\f{-17/23}             & ;A ratio preceded by a sign                  \cr
+\f{-30517578125/32768} & ;This is $(-5/2)^{15}$                       \cr
+\f{10/5}               & ;The canonical form for this is \f{2}        \cr
+\f{\#o-101/75}         & ;Octal notation for $-65/61$                 \cr
+\f{\#3r120/21}         & ;Ternary notation for $15/7$                 \cr
+\f{\#Xbc/ad}           & ;Hexadecimal notation for $188/173$          \cr
+\f{\#xFADED/FACADE}    & ;Hexadecimal notation for $1027565/16435934$ \cr
+}
+
+\reviewer{Barmar: \#o, \#3r, \#X, and \#x mentioned above 
+		  are not in the syntax rules defined just above that.}
+%!!! Maybe they don't belong here? -kmp 17-Oct-90
+
+For information on how \term{ratios} are printed,
+\seesection\PrintingRatios.
+
+\endsubsubsubsection%{Syntax of a Ratio}
+
+\endsubsubsection%{Syntax of a Rational}
+
+\beginsubsubsection{Syntax of a Float}
+\DefineSection{SyntaxOfFloats}
+
+%% 2.1.3 7                   
+\term{Floats} can be 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 \term{exponent marker},
+an optional sign, and a non-empty sequence of digits.
+If no exponent specifier is present, or if the \term{exponent marker} \f{e}
+(or \f{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 value,
+the format specified
+by \varref{*read-default-float-format*} is used.
+\Seefigure\SyntaxForNumericTokens.
+
+%% 2.1.3 1
+An implementation may provide one or more kinds of \term{float}
+that collectively make up \thetype{float}.
+%% 2.1.3 8
+The letters \f{s}, \f{f}, \f{d}, and \f{l} (or their
+respective uppercase equivalents) explicitly specify the
+use of the \term{types} \typeref{short-float}, \typeref{single-float}, 
+\typeref{double-float}, and \typeref{long-float}, respectively.
+                                                
+%% 2.1.3 9
+The internal format used for an external representation depends only
+on the \term{exponent marker}, and not on the number of decimal digits
+in the external representation.
+
+\Thenextfigure\ contains examples of notations for \term{floats}: 
+                                   
+\showtwo{Examples of Floating-point numbers}{
+ \f{0.0}      & ;Floating-point zero in default format                          \cr
+ \f{0E0}      & ;As input, this is also floating-point zero in default format.  \cr
+	      & ;As output, this would appear as \f{0.0}.			\cr
+ \f{0e0}      & ;As input, this is also floating-point zero in default format.  \cr
+	      & ;As output, this would appear as \f{0.0}.			\cr
+ \f{-.0}      & ;As input, this might be a zero or a minus zero,                \cr
+              & ; depending on whether the implementation supports              \cr
+              & ; a distinct minus zero.                                        \cr
+              & ;As output, \f{0.0} is zero and \f{-0.0} is minus zero.         \cr
+ \f{0.}       & ;On input, the integer zero---\i{not} a floating-point number!  \cr
+	      & ;Whether this appears as \f{0} or \f{0.} on output depends	\cr
+	      & ;on \thevalueof{*print-radix*}.					\cr
+ \f{0.0s0}    & ;A floating-point zero in short format                          \cr
+ \f{0s0}      & ;As input, this is a floating-point zero in short format.       \cr
+              & ;As output, such a zero would appear as \f{0.0s0}               \cr
+              & ; (or as \f{0.0} if \misc{short-float} was the default format). \cr
+ \f{6.02E+23} & ;Avogadro's number, in default format                           \cr
+ \f{602E+21}  & ;Also Avogadro's number, in default format                      \cr
+}
+
+For information on how \term{floats} are printed,
+\seesection\PrintingFloats.
+
+\endsubsubsection%{Syntax of a Float}
+
+%!!! Barmar: This next is out of place because it isn't really syntax-related.}
+%    KMP: Where to move it to? -kmp
+
+\beginsubsubsection{Syntax of a Complex}
+\DefineSection{SyntaxOfComplexes}
+
+A \term{complex} has a Cartesian structure, 
+with a real part and an imaginary part each of which is a 
+\issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+\term{real}.
+\endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+The parts of a \term{complex} are not necessarily \term{floats} 
+but both parts must be of the same \term{type}: 
+\editornote{KMP: This is not the same as saying they must be the same type.
+                 Maybe we mean they are of the same `precision' or `format'?
+		 GLS had suggestions which are not yet merged.}%!!! 4-Jan-91
+either both are \term{rationals}, or both are of the same \term{float} \term{subtype}.
+When constructing a \term{complex}, if the specified parts are not the
+same \term{type}, the parts are converted to be the same \term{type}
+internally (\ie the \term{rational} part is converted to a \term{float}). 
+An \term{object} of type \f{(complex rational)} is converted internally
+and represented thereafter as a \term{rational} if its imaginary part is an 
+\term{integer} whose value is 0.
+
+For further information, \seesection\SharpsignC\ and \secref\PrintingComplexes.
+
+\endsubsubsection%{Syntax of a Complex}
+
+\endsubsection%{Constructing Numbers from Tokens}
+
+\beginsubsection{The Consing Dot}
+
+%% 22.1.2 13
+If a \term{token} consists solely of dots (with no escape characters),
+then an error \oftype{reader-error} is signaled,
+except in one circumstance:
+if the \term{token} is a single \term{dot}
+and appears in a situation where \term{dotted pair} notation permits a \term{dot},
+then it is accepted as part of such syntax and no error is signaled. 
+\Seesection\LeftParen.
+
+\endsubsection%{The Consing Dot}
+
+\beginsubSection{Symbols as Tokens}
+\DefineSection{SymbolTokens}
+
+Any \term{token} that is not a \term{potential number},
+%next line added per Barmar:
+does not contain a \term{package marker},
+and does not consist entirely of dots
+will always be interpreted as a \term{symbol}.
+Any \term{token} that is a \term{potential number} but does not fit the       
+number syntax is a reserved \term{token} and
+has an \term{implementation-dependent} interpretation.
+%% 22.1.2 14
+%% 11.3.0 7
+%% 2.3.0 4
+In all other cases, the \term{token} is construed to be the name of a \term{symbol}.
+
+Examples of the printed representation of \term{symbols} are in \thenextfigure. 
+For presentational simplicity,
+these examples assume that
+the \term{readtable case} of the \term{current readtable} is \kwd{upcase}.
+
+%% 2.3.0 7                                        
+\showtwo{Examples of the printed representation of symbols (Part 1 of 2)}{
+\f{FROBBOZ}                        & The \term{symbol} whose \term{name} is \f{FROBBOZ}. \cr
+\f{frobboz}                        & Another way to notate the same \term{symbol}.       \cr
+\f{fRObBoz}                        & Yet another way to notate it.                       \cr
+\f{unwind-protect}                 & A \term{symbol} with a hyphen in its \term{name}.   \cr
+\f{+\$}                            & The \term{symbol} named \f{+\$}.                    \cr
+\f{1+}                             & The \term{symbol} named \f{1+}.                     \cr
+\f{+1}                             & This is the \term{integer} \f{1},
+				     not a \term{symbol}.                                \cr
+\f{pascal\_style}                  & This \term{symbol} has an underscore 
+				     in its \term{name}.                                 \cr
+\f{file.rel.43}                    & This \term{symbol} has periods in its \term{name}.  \cr
+\f{\\(}				   & The \term{symbol} whose \term{name} is \f{(}.       \cr%))
+\f{\\+1}                           & The \term{symbol} whose \term{name} is \f{+1}.      \cr
+\f{+\\1}                           & Also the \term{symbol} whose \term{name} is \f{+1}. \cr
+\f{\\frobboz}                      & The \term{symbol} whose \term{name} is \f{fROBBOZ}. \cr
+\f{3.14159265\\s0}                 & The \term{symbol} whose \term{name}
+				     is \f{3.14159265s0}.                                \cr
+\f{3.14159265\\S0}                 & A different \term{symbol}, 
+				     whose \term{name} is \f{3.14159265S0}.              \cr
+\f{3.14159265s0}                   & A possible \term{short float} 
+				     approximation to $\pi$.                             \cr
+}
+
+% This is sort of an artificial division, but addresses the fact that this table is pretty
+% big and makes for awkward-looking page break if the table is left all one piece.
+% -kmp 31-Jan-92
+
+\showtwo{Examples of the printed representation of symbols (Part 2 of 2)}{
+\f{APL\\\\360}                     & The \term{symbol} whose \term{name} 
+				     is \f{APL\\360}.                                    \cr
+\f{apl\\\\360}                     & Also the \term{symbol} whose \term{name} 
+				     is \f{APL\\360}.                                    \cr
+\f{\\(b{\hat}2\\)\\ -\\ 4*a\f{*c}} & The \term{name} is \f{(B{\hat}2) - 4*A*C}.          \cr
+				   & Parentheses and two spaces in it.                   \cr
+\f{\\(\\b{\hat}2\\)\\ -\\4*\\a*\\c} & The \term{name} is \f{(b{\hat}2) - 4*a*c}.         \cr
+				   & Letters explicitly lowercase.                       \cr
+\f{|"|}                            & The same as writing \f{\\"}.                        \cr
+\f{|(b{\hat}2) - 4*a*c|}           & The \term{name} is \f{(b{\hat}2) - 4*a*c}.          \cr
+\f{|frobboz|}                      & The \term{name} is \f{frobboz}, not \f{FROBBOZ}.    \cr
+\f{|APL\\360|}                     & The \term{name} is \f{APL360}.                      \cr
+\f{|APL\\\\360|}                   & The \term{name} is \f{APL\\360}.                    \cr
+\f{|apl\\\\360|}                   & The \term{name} is \f{apl\\360}.                    \cr
+\f{|\\|\\||}                       & Same as \f{\\|\\|} ---the \term{name} is \f{||}.    \cr
+\f{|(B{\hat}2) - 4*A*C|}           & The \term{name} is \f{(B{\hat}2) - 4*A*C}.          \cr
+				   & Parentheses and two spaces in it.                   \cr
+\f{|(b{\hat}2) - 4*a*c|}           & The \term{name} is \f{(b{\hat}2) - 4*a*c}.          \cr
+}
+
+%!!! Presumably this means "other than the code attribute." sigh... -kmp 25-Jan-92
+\issue{CHARACTER-PROPOSAL:2-1-1}
+In the process of parsing a \term{symbol},
+it is \term{implementation-dependent} which
+%\term{attributes} are removed from \term{symbol} \term{names}.
+%% Sandra didn't like the above wording. She suggested this:
+\term{implementation-defined} \term{attributes} are removed
+from the \term{characters} forming a \term{token} that represents a \term{symbol}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+%% 11.3.0 2      
+% When the \term{Lisp reader} has, by parsing, obtained a string of characters
+% %!!! RPG: "thought"? oh well.
+% thought to name a \term{symbol}, 
+% that name is looked up in the \term{current package}.
+%% Rewritten for RPG's sake:
+When parsing the syntax for a \term{symbol},
+the \term{Lisp reader} looks up the \term{name} of that \term{symbol} 
+in the \term{current package}.
+This lookup may involve looking in other 
+\term{packages} whose \term{external symbols}
+are inherited by the \term{current package}.  If the name is found,
+the corresponding \term{symbol} is returned.  If the name is not found
+(that is, there is no \term{symbol} 
+of that name \term{accessible} in the \term{current package}),
+a new \term{symbol} is created and is placed in the \term{current package}
+as an \term{internal symbol}.  The \term{current package} becomes the owner
+(\term{home package}) of the \term{symbol}, 
+and the \term{symbol} becomes interned in the \term{current package}.
+If the name is later read again while this same \term{package} is
+current, the same \term{symbol} will be found and returned.
+
+\endsubSection%{Symbols as Tokens}
+
+\beginsubSection{Valid Patterns for Tokens}
+
+The valid patterns for \term{tokens} are summarized in \thenextfigure. 
+
+\showtwo{Valid patterns for tokens}{
+\f{\i{nnnnn}}                     & a \term{number} \cr
+\f{\i{xxxxx}}                     & a \term{symbol} in the \term{current package} \cr
+\f{:\i{xxxxx}}                    & a \term{symbol} in the \thepackage{keyword} \cr
+\f{\i{ppppp}:\i{xxxxx}}           & an \term{external symbol} 
+				    in the \i{ppppp} \term{package} \cr
+\f{\i{ppppp}::\i{xxxxx}}          & a (possibly internal) \term{symbol} 
+				    in the \i{ppppp} \term{package} \cr
+\f{:\i{nnnnn}}                    & undefined \cr
+\f{\i{ppppp}:\i{nnnnn}}           & undefined \cr
+\f{\i{ppppp}::\i{nnnnn}}          & undefined \cr
+\f{::\i{aaaaa}}                   & undefined \cr
+\f{\i{aaaaa}:}                    & undefined \cr
+\f{\i{aaaaa}:\i{aaaaa}:\i{aaaaa}} & undefined \cr
+}
+
+Note that \i{nnnnn} has number syntax,
+          neither \i{xxxxx} nor \i{ppppp} has number syntax,
+      and \i{aaaaa} has any syntax.
+
+%% 11.0.0 30
+A summary of rules concerning \term{package markers} follows.
+In each case, examples are offered to illustrate the case;
+for presentational simplicity, the examples assume that
+the \term{readtable case} of the \term{current readtable} is \kwd{upcase}.
+
+%% 22.1.2 15
+%% 11.0.0 33
+\beginlist                                           
+\item{1.}
+If there is a single \term{package marker}, and it occurs at the beginning of the
+\term{token}, then the \term{token} is interpreted as a \term{symbol} in \thepackage{keyword}.
+It also sets the \funref{symbol-value} of the newly-created \term{symbol} to that
+same \term{symbol} so that the \term{symbol} will self-evaluate.
+
+For example, 
+\f{:bar}, when read, interns \f{BAR} as an \term{external symbol} in \thepackage{keyword}.
+
+%% 22.1.2 16
+%% 11.0.0 31
+%% 11.0.0 29
+\item{2.}
+If there is a single \term{package marker} not at the beginning or end of the
+\term{token}, then it divides the \term{token} into two parts.  The first part
+specifies a \term{package}; 
+the second part is the name of an \term{external symbol}
+available in that package.  
+
+For example, 
+\f{foo:bar}, when read, looks up \f{BAR} among the \term{external symbols} of
+the \term{package} named \f{FOO}.
+%\f{\#:bar}, when read, creates a new, \term{uninterned} \term{symbol} 
+%named \f{BAR}.
+%\funref{import} and \funref{unintern} can create a \term{symbol} 
+%that has no
+%recorded \term{home package},
+%but that in fact is \term{accessible} in some \term{package}.
+%The implementation 
+%does not check for this pathological case, and such \term{symbols}
+%are printed preceded by \f{\#:}.
+
+%% 22.1.2 17
+%% 11.0.0 32
+%% 11.0.0 26
+\item{3.}
+If there are two adjacent \term{package markers} not at the beginning or end of the
+\term{token}, then they divide the \term{token} into two parts.  The first part
+specifies a \term{package};
+the second part is the name of a \term{symbol} within
+that \term{package} (possibly an \term{internal symbol}).
+
+For example, 
+\f{foo::bar}, when read, interns \f{BAR} in the \term{package} named \f{FOO}.
+
+%% 22.1.2 18
+\item{4.}
+If the \term{token} contains no \term{package markers}, 
+and does not have \term{potential number} syntax,
+then the entire \term{token} is the name of the \term{symbol}.
+The \term{symbol} is looked up in the \term{current package}.
+
+For example, 
+\f{bar}, when read, interns \f{BAR} in the \term{current package}.
+
+%% 22.1.2 19
+%% 11.0.0 34
+\item{5.}
+The consequences are unspecified if any other pattern of \term{package markers}
+in a \term{token} is used.
+All other uses of \term{package markers} within names of \term{symbols} 
+are not defined by this standard 
+but are reserved for \term{implementation-dependent} use.
+\endlist
+
+%% 11.0.0 25
+For example,
+assuming the \term{readtable case} of the \term{current readtable} is \kwd{upcase},
+\f{editor:buffer} refers to the \term{external symbol} 
+named \f{BUFFER} present in the \term{package} named \f{editor},
+regardless of whether there is a \term{symbol} named \f{BUFFER} in
+the \term{current package}.  If there is no \term{package} named
+\f{editor}, or if no \term{symbol} named \f{BUFFER}
+is present in \f{editor}, or if \f{BUFFER} is not exported by
+\f{editor}, the reader signals
+a correctable error.
+%!!! Error type?
+If \f{editor::buffer} is seen, the effect is exactly the same as
+reading \f{buffer} with \thepackage{editor} being the \term{current package}.
+
+\endsubSection%{Valid Patterns for Tokens}
+
+\beginsubSection{Package System Consistency Rules}
+\DefineSection{PackageSysConsistencyRules}
+
+%% 11.0.0 14
+The following rules apply to the package system as long as 
+\thevalueof{*package*} is not changed:
+
+%% 11.0.0 15
+\beginlist
+\itemitem{\b{Read-read consistency}}
+
+
+%!!! Is "same" meaning "string=" here?
+Reading the same \term{symbol} \term{name}
+% "same (eq)" => "\term{same}" for simplicity. -kmp 10-Apr-91
+always results in the \term{same} \term{symbol}.
+
+%% 11.0.0 16
+\itemitem{\b{Print-read consistency}}
+
+% "same (eq)" => "\term{same}" for simplicity. -kmp 10-Apr-91
+An \term{interned symbol} always prints as a sequence of characters that, 
+when read back in, yields the \term{same} \term{symbol}.
+
+For information about how the \term{Lisp printer} treats \term{symbols},
+\seesection\PrintingSymbols.
+
+%% 11.0.0 17
+\itemitem{\b{Print-print consistency}}
+
+% "same (eq)" => "\term{same}" for simplicity. -kmp 10-Apr-91
+If two interned \term{symbols} are not the \term{same},
+then their printed representations will be different sequences of characters.
+\endlist
+
+%% 11.0.0 18
+These rules are true regardless of any implicit interning.
+As long as the \term{current package} is not changed,
+results are reproducible regardless of the order of \term{loading} files 
+or the exact history of what \term{symbols} were typed in when.  
+If \thevalueof{*package*} is changed and then changed back to the previous value,
+consistency is maintained.
+The rules can be violated by
+    changing \thevalueof{*package*},
+    forcing a change to \term{symbols} 
+                  or to \term{packages} 
+    	          or to both
+    by continuing from an error,
+or calling one of the following \term{functions}:
+    \funref{unintern},
+    \funref{unexport},
+    \funref{shadow},
+    \funref{shadowing-import},
+ or \funref{unuse-package}.
+
+An inconsistency only applies if one of the restrictions is violated
+between two of the named \term{symbols}.
+\funref{shadow}, \funref{unexport}, \funref{unintern},
+and \funref{shadowing-import} can only affect the consistency of
+\term{symbols} with the same \term{names} (under \funref{string=})
+as the ones supplied as arguments.
+
+\endsubsection%{Package System Consistency Rules}

concept-traversal.tex

@@ -0,0 +1,49 @@
+% -*- Mode: TeX -*-
+% Traversal Rules and Side Effects
+
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+ 
+The consequences are undefined 
+% (but in general no error will be signaled) 
+when \term{code} executed during an \term{object-traversing} operation
+%!!! Barmar wants them listed.
+destructively modifies the \term{object} in a way that might affect the
+ongoing traversal operation.
+In particular, the following rules apply.
+\beginlist
+\itemitem{\b{List traversal}}
+ 
+ For \term{list} traversal operations, the \term{cdr} chain of the
+ \term{list} is not allowed to be destructively modified.
+ 
+\itemitem{\b{Array traversal}}
+
+  For \term{array} traversal operations, the \term{array} is not allowed 
+  to be adjusted and its \term{fill pointer}, if any, is not allowed to 
+  be changed.
+ 
+\itemitem{\b{Hash-table traversal}}
+
+  For \term{hash table} traversal operations, new elements may not be added
+  or deleted except that the element corresponding to the current hash key 
+  may be changed or removed.
+ 
+\itemitem{\b{Package traversal}}
+
+%KMP: Isn't this already said in general for object-traversal elsewhere?
+%Barmar: Loop?
+%KMP: With-package-iterator?
+%RPG: Leave it here.
+  For \term{package} traversal operations (\eg \macref{do-symbols}),
+  new \term{symbols} may not be \term{interned} in or \term{uninterned} 
+  from the \term{package} being traversed 
+  or any \term{package} that it uses except that the 
+  current \term{symbol} may be \term{uninterned} from the \term{package} 
+  being traversed.
+
+\endlist 
+%These rules only apply to 
+%\term{object} manipulators that are not inherently
+%  destructive. 
+
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}

concept-type-intro.tex

@@ -0,0 +1,55 @@
+% -*- Mode: TeX -*-
+%% Introduction to Objects and Types
+
+%% 2.0.0 4
+%% 6.2.1 1
+A \term{type} is a (possibly infinite) set of \term{objects}.
+An \term{object} can belong to more than one \term{type}.  
+\term{Types} are never explicitly represented as \term{objects} by \clisp.
+Instead, they are referred to indirectly by the use of \term{type specifiers},
+which are \term{objects} that denote \term{types}.
+
+New \term{types} can be defined using \macref{deftype}, \macref{defstruct}, 
+\macref{defclass}, and \macref{define-condition}.
+
+\Thefunction{typep}, a set membership test, is used to determine
+whether a given \term{object} is of a given \term{type}.  The function
+\funref{subtypep}, a subset test, is used to determine whether a
+given \term{type} is a \term{subtype} of another given \term{type}.  The
+function \funref{type-of} returns a particular \term{type} to
+which a given \term{object} belongs, even though that \term{object}
+must belong to one or more other \term{types} as well.
+(For example, every \term{object} is \oftype{t}, 
+ but \funref{type-of} always returns a \term{type specifier}
+ for a \term{type} more specific than \typeref{t}.)
+
+%% 2.0.0 1
+\term{Objects}, not \term{variables}, have \term{types}.
+Normally, any \term{variable} can have any \term{object} as its \term{value}.
+It is possible to declare that a \term{variable} takes on only 
+values of a given \term{type} by making an explicit \term{type declaration}.
+%% 2.0.0 5
+\term{Types} are arranged in a directed acyclic graph, except
+for the presence of equivalences. 
+
+\term{Declarations} can be made about \term{types} using \misc{declare}, 
+\funref{proclaim}, \macref{declaim}, or \specref{the}.
+For more information about \term{declarations},
+\seesection\Declarations.
+
+Among the fundamental \term{objects} of the \CLOS\ are \term{classes}.
+A \term{class} determines the structure and behavior of a set of
+other \term{objects}, which are called its \term{instances}. 
+Every \term{object} is a \term{direct instance} of a \term{class}.
+The \term{class} of an \term{object} determines the set of
+operations that can be performed on the \term{object}.
+For more information, \seesection\Classes.
+
+It is possible to write \term{functions} that have behavior \term{specialized}
+to the class of the \term{objects} which are their \term{arguments}.
+For more information, \seesection\GFsAndMethods.
+
+The \term{class} of the \term{class} of an \term{object} 
+is called its \newterm{metaclass}.
+For more information about \term{metaclasses},
+\seesection\MetaObjects.

concept-types.tex

@@ -0,0 +1,400 @@
+% -*- Mode: TeX -*-
+
+% At Barmar's suggestion, and by consensus of Quinquevirate, the type hierarchy
+% diagrams, which were quite hard to maintain and anyway unnecessary, were removed.
+% The removed text is in
+%   Stony-Brook.SCRC.Symbolics.COM:>ANSI-CL>spec>archive>source>type-hierarchy-diagrams.tex
+% -kmp 10-Jun-91
+
+\beginsubSection{Data Type Definition}
+
+%% No longer true.
+%Following is a description of each \clisp\ \term{type}.
+
+% %This kind of info belongs in the descriptions of the ftype{...} labels.
+% %New. -kmp
+% % Barmar: Relate to the use of "Type" vs "System Class" in following descriptions.
+% % Barrett: Perhaps safer to say "Where explicitly noted..."
+% % KMP: In fact, I think the paragraph should just disappear, since in all cases where 
+% %  something is both a type and a class, there is a Class Precedence List section
+% %  in its definition, and the ordering info is already well-defined.
+% % Barmar: If there's always a CPL given, then I agree.
+%% Removed. -kmp 15-Feb-92
+% Except as otherwise noted,
+% every \term{symbol} naming a \term{type} 
+% defined in this specification is also the name of a \term{class} that implements
+% the \term{type}.  In cases where there is a corresponding \term{class},
+% the order of its \term{class precedence list} is consistent with the order
+% of the subtype relationships given for the \term{type}.
+
+Information about \term{type} usage is located in 
+the sections specified in \figref\TypeInfoXrefs. 
+\figref\ObjectSystemClasses\ lists some \term{classes} 
+that are particularly relevant to the \CLOS.
+\figref\StandardizedConditionTypes\ lists the defined \term{condition} \term{types}.
+
+\DefineFigure{TypeInfoXrefs}
+\showtwo{Cross-References to Data Type Information}{
+\hfil\b{Section} & Data Type \cr
+\noalign{\vskip 2pt\hrule\vskip 2pt}
+\secref\Classes                 & Object System types                \cr
+\secref\Slots                   & Object System types                \cr
+\secref\Objects                 & Object System types                \cr
+\secref\GFsAndMethods           & Object System types                \cr
+\secref\ConditionSystemConcepts & Condition System types             \cr
+\chapref\TypesAndClasses        & Miscellaneous types		     \cr
+\chapref\Syntax                 & All types---read and print syntax  \cr
+%Nothing really useful here. -kmp 17-Oct-91
+%\secref\ReaderConcepts         & All types---read syntax            \cr
+\secref\TheLispPrinter          & All types---print syntax           \cr
+\secref\Compilation             & All types---compilation issues     \cr
+}
+
+%!!! Insert table of Type Specifiers like AND, OR, NOT... 
+%    from top of DICT-TYPES ? -kmp 17-Oct-91
+
+\endsubSection%{Data Type Definition}
+
+\beginsubSection{Type Relationships}
+\DefineSection{TypeRelationships}
+
+\beginlist
+
+\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
+\itemitem{\bull}
+\Thetypes{cons}, \typeref{symbol}, \typeref{array}, \typeref{number},
+\typeref{character}, \typeref{hash-table}, 
+\issue{FUNCTION-TYPE:X3J13-MARCH-88}
+\typeref{function},
+\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
+\typeref{readtable}, \typeref{package}, \typeref{pathname}, \typeref{stream}, 
+\typeref{random-state}, \typeref{condition}, \typeref{restart},
+and any single other \term{type} created by \macref{defstruct},
+%Added per suggestion of Barrett:
+\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+\issue{CLOS-CONDITIONS:INTEGRATE}
+\macref{define-condition},
+\endissue{CLOS-CONDITIONS:INTEGRATE}
+\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+or \macref{defclass} are \term{pairwise} \term{disjoint}, 
+except for type relations explicitly established by specifying 
+\term{superclasses} in \macref{defclass} 
+\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+\issue{CLOS-CONDITIONS:INTEGRATE}
+or \macref{define-condition}
+\endissue{CLOS-CONDITIONS:INTEGRATE}
+\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+or the \kwd{include} option of \macref{destruct}.
+
+%The following will be left out of the standard.
+%% 2.15.0 6
+%\itemitem{\bull} \typeref{Cons}, \typeref{symbol},
+%\typeref{array}, \typeref{number}, and \typeref{character}
+%are \term{pairwise} \term{disjoint}.
+\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
+
+\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
+%The following will be left out of the standard.
+%% 2.15.0 27
+%\itemitem{\bull}  \typeref{hash-table}, \typeref{readtable}, 
+%\typeref{package}, \typeref{pathname},
+%\typeref{stream}, and \typeref{random-state} are 
+%\term{pairwise} \term{disjoint}.
+\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
+
+%% 2.15.0 28
+\itemitem{\bull} Any two \term{types} created by \macref{defstruct} are 
+\term{disjoint} unless
+one is a \term{supertype} of the other by virtue of
+the \macref{defstruct} \kwd{include} option.
+
+\editornote{KMP: The comments in the source say gray suggested some change
+from ``common superclass'' to ``common subclass'' in the following, but the
+result looks suspicious to me.}
+%!!! Barrett says: It fits the glossary definition of disjoint, i.e., no common
+% elements.  However, I think that is broken.
+%
+% In places where we have specified disjointness requirements, all we really seem to
+% be intendeing is that two types C1 and C2 are disjoint if neither is a subtype of
+% the other.
+
+\itemitem{\bull}
+Any two \term{distinct} \term{classes} created by \macref{defclass} 
+% added --sjl 7 Mar 92
+or \macref{define-condition}
+are \term{disjoint} unless they have a common \term{subclass} or
+one \term{class} is a \term{subclass} of the other.
+%% The preceding text by Moon replaces the following...
+% %% "common superclass" changed to "common subclass" as suggested by Gray
+% \itemitem{\bull} Any two \term{classes} created by \macref{defclass} 
+% are \term{disjoint} unless they have a common \term{subclass} or
+% one \term{class} is a \term{superclass} of the other.
+% %Any two \term{classes}
+% %created by \macref{defclass} are \term{disjoint}
+% %unless they have a common \term{superclass}."  {That assumes that
+% %our definition of superclass says every class is a superclass of
+% %itself, which I think is the case, but did not check.}
+% %
+% %RPG suggestion follows:
+% %\itemitem{\bull} Any type created by defstruct or defclass is guaranteed
+% %to be disjoint from all other types unless subclass or :include is used.
+
+\issue{COMMON-TYPE:REMOVE}
+%The following will be deleted from the standard:
+%
+%% 2.15.0 29
+%\itemitem{\bull} An \term{exhaustive union} for 
+%\thetype{common} is formed by \typeref{cons}, \typeref{symbol},
+%\f{(array x)} where \f{x} is either \typeref{t} or a \term{subtype} of \typeref{common},
+%\typeref{string}, \typeref{fixnum}, \typeref{bignum}, \typeref{ratio},
+%\typeref{short-float}, \typeref{single-float}, \typeref{double-float}, \typeref{long-float},
+%\f{(complex x)} where \f{x} is a \term{subtype} of \typeref{common},
+%\typeref{standard-char}, \typeref{hash-table}, \typeref{readtable}, 
+%\typeref{package}, \typeref{pathname},
+%\typeref{stream}, \typeref{random-state},
+%and all \term{types} created by the user via \macref{defstruct}.
+%An implementation cannot add \term{subtypes} to \typeref{common}.
+\endissue{COMMON-TYPE:REMOVE}
+
+%% Following is suggested by Moon, rewording of a clause in 88-002R.
+\itemitem{\bull} 
+An implementation may be extended to add other \term{subtype}
+relationships between the specified \term{types}, as long as they do
+not violate the type relationships and disjointness requirements
+specified here.  An implementation may define additional \term{types}
+that are \term{subtypes} or \term{supertypes} of any
+specified \term{types}, as long as each additional \term{type} is
+a \subtypeof{t} and a \supertypeof{nil} and the disjointness requirements
+are not violated.
+ 
+\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+At the discretion of the implementation, either \typeref{standard-object}
+or \typeref{structure-object} might appear in any class precedence list
+for a \term{system class} that does not already specify either 
+\typeref{standard-object} or \typeref{structure-object}.  If it does,
+it must precede \theclass{t} and follow all other \term{standardized} \term{classes}.
+\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+
+\endlist                                     
+
+\endsubSection%{Type relationships}
+
+%% Type Specifiers
+\beginsubSection{Type Specifiers}
+\DefineSection{TypeSpecifiers}
+
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+%Discussion of difference between "type specifiers for declaration"
+%and "type specifiers for discrimination" removed.
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+%% 4.1.0 1
+\term{Type specifiers} can be \term{symbols}, \term{classes}, or \term{lists}.
+\figref\StandardizedAtomicTypeSpecs\ lists \term{symbols} that are
+  \term{standardized} \term{atomic type specifiers}, and
+\figref\StandardizedCompoundTypeSpecNames\ lists
+ \term{standardized} \term{compound type specifier} \term{names}.
+For syntax information, see the dictionary entry for the corresponding \term{type specifier}.
+It is possible to define new \term{type specifiers} using
+ \macref{defclass},
+ \macref{define-condition},
+ \macref{defstruct}, 
+or
+ \macref{deftype}.
+
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+\issue{STREAM-ACCESS:ADD-TYPES-ACCESSORS}
+
+\DefineFigure{StandardizedAtomicTypeSpecs}
+%% 4.3.0 4
+\displaythree{Standardized Atomic Type Specifiers}{
+arithmetic-error&function&simple-condition\cr
+array&generic-function&simple-error\cr
+atom&hash-table&simple-string\cr
+base-char&integer&simple-type-error\cr
+base-string&keyword&simple-vector\cr
+bignum&list&simple-warning\cr
+bit&logical-pathname&single-float\cr
+bit-vector&long-float&standard-char\cr
+broadcast-stream&method&standard-class\cr
+built-in-class&method-combination&standard-generic-function\cr
+cell-error&nil&standard-method\cr
+character&null&standard-object\cr
+class&number&storage-condition\cr
+compiled-function&package&stream\cr
+complex&package-error&stream-error\cr
+concatenated-stream&parse-error&string\cr
+condition&pathname&string-stream\cr
+cons&print-not-readable&structure-class\cr
+control-error&program-error&structure-object\cr
+division-by-zero&random-state&style-warning\cr
+double-float&ratio&symbol\cr
+echo-stream&rational&synonym-stream\cr
+end-of-file&reader-error&t\cr
+error&readtable&two-way-stream\cr
+extended-char&real&type-error\cr
+file-error&restart&unbound-slot\cr
+file-stream&sequence&unbound-variable\cr
+fixnum&serious-condition&undefined-function\cr
+float&short-float&unsigned-byte\cr
+floating-point-inexact&signed-byte&vector\cr
+floating-point-invalid-operation&simple-array&warning\cr
+floating-point-overflow&simple-base-string&\cr
+floating-point-underflow&simple-bit-vector&\cr
+}
+
+\endissue{STREAM-ACCESS:ADD-TYPES-ACCESSORS}
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+
+\indent               
+%% 4.2.0 1         
+If a \term{type specifier} is a \term{list}, the \term{car} of the \term{list} 
+is a \term{symbol}, and the rest of the \term{list} is subsidiary
+\term{type} information.  Such a \term{type specifier} is called 
+a \newterm{compound type specifier}.
+Except as explicitly stated otherwise,
+the subsidiary items can be unspecified.
+The unspecified subsidiary items are indicated
+by writing \f{*}.  For example, to completely specify
+a \term{vector}, the \term{type} of the elements
+and the length of the \term{vector} must be present.
+
+\code
+ (vector double-float 100)
+\endcode
+The following leaves the length unspecified:
+
+\code
+ (vector double-float *)
+\endcode
+The following leaves the element type unspecified:
+
+\code
+ (vector * 100)                                      
+\endcode
+Suppose that two \term{type specifiers} are the same except that the first
+has a \f{*} where the second has a more explicit specification.
+Then the second denotes a \term{subtype} 
+of the \term{type} denoted by the first.
+
+%% 4.2.0 2
+If a \term{list} has one or more unspecified items at the end, 
+those items can be dropped.
+If dropping all occurrences of \f{*} results in a \term{singleton} \term{list},
+then the parentheses can be dropped as well (the list can be replaced
+by the \term{symbol} in its \term{car}).  
+For example,                       
+{\tt (vector double-float *)}                    
+can be abbreviated to {\tt (vector double-float)},               
+and {\tt (vector * *)} can be abbreviated to {\tt (vector)} 
+and then to 
+{\tt vector}.
+
+\issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+%Syntax info removed to make the document smaller and more modular. -kmp 20-Oct-91
+%Added CONS per Dalton #10 (first public review). -kmp 10-May-93
+\DefineFigure{StandardizedCompoundTypeSpecNames}
+\displaythree{Standardized Compound Type Specifier Names}{
+and&long-float&simple-base-string\cr
+array&member&simple-bit-vector\cr
+base-string&mod&simple-string\cr
+bit-vector&not&simple-vector\cr
+complex&or&single-float\cr
+cons&rational&string\cr
+double-float&real&unsigned-byte\cr
+eql&satisfies&values\cr
+float&short-float&vector\cr
+function&signed-byte&\cr
+integer&simple-array&\cr
+}
+\endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}
+
+\Thenextfigure\ show the \term{defined names} that can be used as 
+\term{compound type specifier} \term{names}
+but that cannot be used as \term{atomic type specifiers}.
+
+\displaythree{Standardized Compound-Only Type Specifier Names}{
+and&mod&satisfies\cr
+eql&not&values\cr
+member&or&\cr
+}
+
+
+%% 4.7.0 1
+New \term{type specifiers} can come into existence in two ways.
+\beginlist
+\itemitem{\bull} 
+ Defining a structure by using \macref{defstruct} without using
+ the \kwd{type} specifier or defining a \term{class} by using 
+ \macref{defclass} 
+% added --sjl 7 Mar 92
+ or \macref{define-condition}
+ automatically causes the name of the structure 
+ or class to be a new \term{type specifier} \term{symbol}.
+\itemitem{\bull} 
+ \macref{deftype} can be used to define \newtermidx{derived type specifiers}{derived type specifier},
+ which act as `abbreviations' for other \term{type specifiers}.
+\endlist
+
+A \term{class} \term{object} can be used as a \term{type specifier}. 
+When used this way, it denotes the set of all members of that \term{class}.
+
+\Thenextfigure\ shows some \term{defined names} relating to 
+\term{types} and \term{declarations}.
+
+% I added SUBTYPEP, TYPEP, DEFINE-CONDITION.  --sjl 7 Mar 92
+\DefineFigure{TypesAndDeclsNames}
+\displaythree{Defined names relating to types and declarations.}{
+coerce&defstruct&subtypep\cr
+declaim&deftype&the\cr
+declare&ftype&type\cr
+defclass&locally&type-of\cr
+define-condition&proclaim&typep\cr
+}
+
+\Thenextfigure\ shows all \term{defined names} that are \term{type specifier} \term{names},
+whether for \term{atomic type specifiers} or \term{compound type specifiers};
+this list is the union of the lists in \figref\StandardizedAtomicTypeSpecs\ 
+and \figref\StandardizedCompoundTypeSpecNames.
+
+\DefineFigure{StandardizedTypeSpecifierNames}
+\displaythree{Standardized Type Specifier Names}{
+and&function&simple-array\cr
+arithmetic-error&generic-function&simple-base-string\cr
+array&hash-table&simple-bit-vector\cr
+atom&integer&simple-condition\cr
+base-char&keyword&simple-error\cr
+base-string&list&simple-string\cr
+bignum&logical-pathname&simple-type-error\cr
+bit&long-float&simple-vector\cr
+bit-vector&member&simple-warning\cr
+broadcast-stream&method&single-float\cr
+built-in-class&method-combination&standard-char\cr
+cell-error&mod&standard-class\cr
+character&nil&standard-generic-function\cr
+class&not&standard-method\cr
+compiled-function&null&standard-object\cr
+complex&number&storage-condition\cr
+concatenated-stream&or&stream\cr
+condition&package&stream-error\cr
+cons&package-error&string\cr
+control-error&parse-error&string-stream\cr
+division-by-zero&pathname&structure-class\cr
+double-float&print-not-readable&structure-object\cr
+echo-stream&program-error&style-warning\cr
+end-of-file&random-state&symbol\cr
+eql&ratio&synonym-stream\cr
+error&rational&t\cr
+extended-char&reader-error&two-way-stream\cr
+file-error&readtable&type-error\cr
+file-stream&real&unbound-slot\cr
+fixnum&restart&unbound-variable\cr
+float&satisfies&undefined-function\cr
+floating-point-inexact&sequence&unsigned-byte\cr
+floating-point-invalid-operation&serious-condition&values\cr
+floating-point-overflow&short-float&vector\cr
+floating-point-underflow&signed-byte&warning\cr
+}
+
+\endsubSection%{Type Specifiers}
+

dict-arrays.tex

@@ -0,0 +1,2800 @@
+% -*- Mode: TeX -*-
+
+% Arrays
+%  Vectors
+%   Bit Vectors
+%   Strings
+
+%-------------------- Array types --------------------
+
+%% 2.5.0 1
+\begincom{array}\ftype{System Class}
+
+\label Class Precedence List::
+\typeref{array},
+\typeref{t}
+
+\label Description::
+
+An \term{array} contains \term{objects} arranged according to a
+Cartesian coordinate system.
+%% 2.5.1 4
+% {Symbolics rewrote the following}
+An \term{array} provides mappings from a set of
+\issue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+\term{fixnums}
+\endissue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+$\left\{i\sub{0},i\sub{1},\dots,i\sub{r-1}\right\}$ to corresponding \term{elements}
+of the \term{array}, 
+where $0 \le i\sub{j} < d\sub{j}$,
+$r$ is the rank of the array, and $d\sub{j}$ is the size of \term{dimension} $j$ of
+the array.
+
+When an \term{array} is created, the program requesting its creation may
+declare that all \term{elements} are of a particular \term{type}, 
+called the \term{expressed array element type}.
+The implementation is permitted to \term{upgrade} this type in order to 
+produce the \term{actual array element type},
+which is the \term{element type} for the \term{array} is actually \term{specialized}.
+\Seefun{upgraded-array-element-type}.
+
+\label Compound Type Specifier Kind::
+
+Specializing.
+
+\label Compound Type Specifier Syntax::
+
+\Deftype{array}{\ttbrac{\curly{element-type | \misc{*}} \brac{dimension-spec}}}
+
+\auxbnf{dimension-spec}{rank | \misc{*} | \paren{\star{\curly{dimension | \misc{*}}}}}
+
+\label Compound Type Specifier Arguments::
+
+\param{dimension}---a \term{valid array dimension}.
+
+\param{element-type}---a \term{type specifier}.
+
+\issue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+\param{rank}---a non-negative \term{fixnum}.
+\endissue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+
+\label Compound Type Specifier Description::
+
+%% 4.5.0 6
+%% 4.5.0 7
+
+This denotes the set of \term{arrays} whose
+  \term{element type},  \term{rank},  and \term{dimensions}
+match any given
+  \param{element-type}, \param{rank}, and \param{dimensions}.
+Specifically:
+
+If \param{element-type} is the \term{symbol} \misc{*},
+\term{arrays} are not excluded on the basis of their \term{element type}.
+Otherwise, only those \param{arrays} are included whose \term{actual array element type}
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+is the result of \term{upgrading} \param{element-type};
+\seesection\ArrayUpgrading.
+%The following will be left out:
+%\param{element-type}
+%% The following seems redundant. -kmp 20-Oct-91
+% {\tt (array \param{type-specifier})}
+% refers only to those \term{arrays} 
+% that can result from giving \param{type-specifier} as the
+% \kwd{element-type} argument to \funref{make-array}.  
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+If the \param{dimension-spec} is a \param{rank},
+the set includes only those \param{arrays} having that \term{rank}.
+If the \param{dimension-spec} is a \term{list} of \param{dimensions},
+the set includes only those \param{arrays} having a \term{rank}
+given by the \term{length} of the \param{dimensions},
+and having the indicated \param{dimensions}; 
+in this case, \misc{*} matches any value for the corresponding \term{dimension}.
+If the \param{dimension-spec} is the \term{symbol} \misc{*},
+the set is not restricted on the basis of \term{rank} or \term{dimension}.
+
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+%The following will be left out:
+%
+%For declaration purposes, this \term{type} encompasses those 
+%\term{arrays}
+%that can result by supplying \param{element-type} as the element type
+%to \thefunction{make-array}; this might be different
+%from what the \term{type} means for discrimination purposes.
+%For example:
+%
+%\code
+% (array integer 3)       ;Three-dimensional arrays of integers
+% (array integer (* * *)) ;Three-dimensional arrays of integers
+% (array * (4 5 6))       ;4-by-5-by-6 arrays
+% (array character (3 *)) ;Two-dimensional arrays of characters that have 
+%                         ;three rows
+% (array short-float \empty)   ;Zero-rank arrays of short-floats
+%\endcode
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+\label See Also::
+
+\varref{*print-array*},
+\funref{aref},
+\funref{make-array},
+\typeref{vector},
+{\secref\SharpsignA},
+{\secref\PrintingOtherArrays}
+
+\label Notes::
+
+Note that the type {\tt (array t)}     
+is a proper \term{subtype} of the type {\tt (array *)}.
+The reason is that the type {\tt (array t)} is the set of \term{arrays} 
+that can
+hold any \term{object} (the \term{elements} are \oftype{t},  which includes
+all \term{objects}).
+On the other hand, the type {\tt (array *)}
+is the set of all \term{arrays} whatsoever, including for example
+\term{arrays} that can hold only \term{characters}. 
+%% possible issue here that: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS says that
+%%this example only works in implementations that have specialized arrays for
+%%elements of type character, not required in CL. But char committee may
+%%require them.
+The type {\tt (array character)} 
+is not a \term{subtype} of the type {\tt (array t)}; 
+the two sets                                              
+are \term{disjoint} because the type {\tt (array character)} is not the
+set of all \term{arrays} that can hold 
+\term{characters}, but rather the set of
+\term{arrays} 
+that are specialized to hold precisely \term{characters} and no
+other \term{objects}. 
+
+%The following expression cannot be used to determine if
+%array \f{foo} can hold a \term{character}:
+%
+%\code
+% (typep foo '(array character))
+%\endcode
+%The following expression can be used to determine if
+%array \f{foo} can hold a \term{character}:
+%
+%\code
+% (subtypep 'character (array-element-type foo))
+%\endcode
+
+
+\endcom%{array}\ftype{System Class}
+%% 2.5.0 9
+\begincom{simple-array}\ftype{Type}
+
+\label Supertypes:: 
+
+\typeref{simple-array},
+%% 2.15.0 20
+\typeref{array},
+\typeref{t}
+
+\label Description::
+
+%Per Symbolics comments, this is reworded to clarify that this only defines
+%things that might be simple, not what must be:
+%An \term{array}
+%that is not displaced to another \term{array}, has no \term{fill pointer},
+%and is not to have its size adjusted dynamically after
+%creation is a \term{simple array}.
+The \term{type} of an \term{array} that is not displaced 
+to another \term{array}, has no \term{fill pointer}, and is
+% \reviewer{Barrett: Reexamine in light of ADJUST-ARRAY-NOT-ADJUSTABLE--specifically,
+%  all arrays are now valid to adjust-array--they just don't all get changed by side-effect.}
+not
+\term{expressly adjustable} is a \subtypeof{simple-array}.
+The concept of a \term{simple array}
+exists to allow the implementation to use a specialized representation
+and to allow the user to declare that certain values will always be
+\term{simple arrays}. 
+
+%% 2.15.0 21
+The \term{types} \typeref{simple-vector},
+		 \typeref{simple-string},
+             and \typeref{simple-bit-vector}
+are \term{disjoint} \subtypesof{simple-array}, 
+for they respectively mean \f{(simple-array t (*))},
+		           the union of all \f{(simple-array \i{c} (*))} 
+ 			    for any \i{c} being a \subtypeof{character},
+			and \f{(simple-array bit (*))}.
+
+\label Compound Type Specifier Kind::
+
+Specializing.
+
+%% 4.5.0 8
+\label Compound Type Specifier Syntax::
+
+\Deftype{simple-array}{\ttbrac{\curly{element-type | \misc{*}} \brac{dimension-spec}}}
+
+\auxbnf{dimension-spec}{rank | \misc{*} | \paren{\star{\curly{dimension | \misc{*}}}}}
+
+\label Compound Type Specifier Arguments::
+
+\param{dimension}---a \term{valid array dimension}.
+
+\param{element-type}---a \term{type specifier}.
+
+\issue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+\param{rank}---a non-negative \term{fixnum}.
+\endissue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+
+\label Compound Type Specifier Description::
+                   
+This \term{compound type specifier} is treated exactly as the corresponding
+\term{compound type specifier} for \term{type} \typeref{array} would be treated,
+except that the set is further constrained to include only \term{simple arrays}.
+
+% This denotes the set of \term{simple arrays} whose elements are all of \term{type}
+% \issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+% {\penalty-50}\f{(upgraded-array-element-type \param{element-type})}
+% %The following will be left out:
+% %\param{element-type}
+% \endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+% and whose dimensions are \param{dimensions}.
+% \param{Element-type} must be a valid \term{type specifier} or \misc{*}.
+% \issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+% \param{Dimensions} must be a non-negative \term{fixnum},
+% \endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+% which is the number
+% of dimensions, or a \term{list} of \term{valid array dimensions}
+% representing the length of each dimension (any dimension
+% can be \misc{*} instead), or it can be \misc{*}.
+
+\label Notes::
+
+It is \term{implementation-dependent} 
+whether \term{displaced arrays},
+        \term{vectors} with \term{fill pointers},
+     or arrays that are \term{actually adjustable}
+  are \term{simple arrays}.
+
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+{\tt (simple-array *)} refers to all \term{simple arrays} 
+regardless of element type, {\tt (simple-array \param{type-specifier})}
+refers only to those \term{simple arrays}
+that can result from giving \param{type-specifier} as the
+\kwd{element-type} argument to \funref{make-array}.  
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+\endcom%{simple-array}\ftype{Type}
+%% 2.5.1 1
+\begincom{vector}\ftype{System Class}
+
+\label Class Precedence List::
+\typeref{vector},
+\typeref{array},
+\typeref{sequence},
+\typeref{t}
+
+\label Description::
+
+Any one-dimensional \term{array} is a \term{vector}.
+
+%% 2.15.0 19
+\Thetype{vector} is a \subtypeof{array}; 
+for all \term{types} \f{x}, {\tt (vector x)} is the same as {\tt (array x (*))}.
+
+%% 2.15.0 18
+The \term{type} {\tt (vector t)}, \thetype{string}, and \thetype{bit-vector}
+are \term{disjoint} \subtypesof{vector}.
+
+\label Compound Type Specifier Kind::
+
+Specializing.
+
+\label Compound Type Specifier Syntax::
+
+%% 4.5.0 9
+\Deftype{vector}{\ttbrac{\curly{element-type | \misc{*}} \brac{\curly{size | \misc{*}}}}}
+
+\label Compound Type Specifier Arguments::
+
+\issue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+\param{size}---a non-negative \term{fixnum}.
+\endissue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+
+\param{element-type}---a \term{type specifier}.
+
+\label Compound Type Specifier Description::
+
+This denotes the set of specialized \term{vectors}
+whose \term{element type} and \param{dimension} match the specified values.
+Specifically:
+
+If \param{element-type} is the \term{symbol} \misc{*},
+\term{vectors} are not excluded on the basis of their \term{element type}.
+Otherwise, only those \param{vectors} are included whose \term{actual array element type}
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+is the result of \term{upgrading} \param{element-type};
+\seesection\ArrayUpgrading.
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+If a \param{size} is specified,
+the set includes only those \param{vectors} whose only \term{dimension}
+is \param{size}.
+If the \term{symbol} \misc{*} is specified instead of a \param{size},
+the set is not restricted on the basis of \term{dimension}.
+
+\label See Also::
+
+{\secref\RequiredSpecializedArrays},
+{\secref\SharpsignLeftParen},
+{\secref\PrintingOtherVectors},
+{\secref\SharpsignA}
+
+\label Notes::
+
+The \term{type} \f{(vector \param{e} \param{s})} 
+is equivalent to the \term{type} \f{(array \param{e} (\param{s}))}.
+
+The type \f{(vector bit)} has the name \typeref{bit-vector}.
+
+The union of all \term{types} \f{(vector $C$)}, 
+where $C$ is any \term{subtype} of \typeref{character},
+has the name \typeref{string}.
+%Every implementation of \clisp\ must provide distinct representations for
+%these as distinct specialized \term{types}.
+
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+{\tt (vector *)} refers to all \term{vectors} 
+regardless of element type, {\tt (vector \param{type-specifier})}
+refers only to those \term{vectors} 
+that can result from giving \param{type-specifier} as the
+\kwd{element-type} argument to \funref{make-array}.  
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+\endcom%{vector}\ftype{System Class}
+\begincom{simple-vector}\ftype{Type}
+
+\label Supertypes::
+
+\typeref{simple-vector},
+\typeref{vector},
+\typeref{simple-array},
+\typeref{array},
+\typeref{sequence},
+\typeref{t}
+
+\label Description::
+
+% This sentence replaced per Symbolics comments:
+% A \term{vector} that is not displaced to another \term{array}, has no
+% \term{fill pointer}, is able to hold elements of any \term{type},
+% and is not to have its size adjusted dynamically after creation is a
+% \term{simple vector}.
+The \term{type} of a \term{vector} that is not displaced to another
+\term{array}, has no \term{fill pointer}, is not 
+%to have its size adjusted dynamically after creation, 
+\term{expressly adjustable}
+and is able to hold 
+elements of any \term{type} is a \subtypeof{simple-vector}.
+
+%% 2.15.0 22                       
+\Thetype{simple-vector} is a \subtypeof{vector},
+and is a \term{subtype} of \term{type} \f{(vector t)}.
+
+\label Compound Type Specifier Kind::
+
+Specializing.
+
+\label Compound Type Specifier Syntax::
+
+\Deftype{simple-vector}{\ttbrac{size}}
+
+\label Compound Type Specifier Arguments::
+
+\issue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+\param{size}---a non-negative \term{fixnum},
+	    or the \term{symbol} \misc{*}.
+  \Default{the \term{symbol} \misc{*}}
+\endissue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+
+\label Compound Type Specifier Description::
+
+%% 4.5.0 10                            
+%\itemitem{\tt (simple-vector \param{size})}
+
+This is the same as {\tt (simple-array t (\param{size}))}.
+%This is the same as {\tt (and (vector t \param{size}) simple-array)}.
+
+% This is the same                
+% as the type \f{(vector t \param{size})}
+% except that \typeref{simple-vector} also specifies
+% that its members are \term{simple arrays}.
+
+\endcom%{simple-vector}\ftype{Type}
+\begincom{bit-vector}\ftype{System Class}
+
+\label Class Precedence List::
+\typeref{bit-vector},
+\typeref{vector},
+\typeref{array},
+\typeref{sequence},
+\typeref{t}
+
+\label Description::
+
+A \term{bit vector} is a \term{vector} the \term{element type} of which is \term{bit}.
+
+%% 2.15.0 17
+\Thetype{bit-vector} is a \subtypeof{vector}, 
+for \typeref{bit-vector} means \f{(vector bit)}.
+
+\label Compound Type Specifier Kind::
+
+Abbreviating.
+
+\label Compound Type Specifier Syntax::
+
+%% 4.6.0 12
+\Deftype{bit-vector}{\ttbrac{size}}
+
+\label Compound Type Specifier Arguments::
+
+\issue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+\param{size}---a non-negative \term{fixnum},
+	    or the \term{symbol} \misc{*}.
+\endissue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+
+\label Compound Type Specifier Description::
+                                                        
+This denotes the same \term{type} as the \term{type} {\tt (array bit (\param{size}))};
+that is, the set of \term{bit vectors} of size \param{size}.
+
+\label See Also::
+
+{\secref\SharpsignStar},
+{\secref\PrintingBitVectors},
+{\secref\RequiredSpecializedArrays}
+
+\endcom%{bit-vector}\ftype{System Class}
+\begincom{simple-bit-vector}\ftype{Type}
+
+\label Supertypes:: 
+
+\typeref{simple-bit-vector},
+%% 2.15.0 25
+\typeref{bit-vector},
+\typeref{vector},
+\typeref{simple-array},
+\typeref{array},
+\typeref{sequence},
+\typeref{t}
+
+\label Description::
+
+% Reworded per Symbolics comments:
+%   A \term{bit vector} that is not displaced to another
+% \term{array}, has no \term{fill pointer}, and is not to have its
+% size adjusted dynamically after creation is a \term{simple bit vector}.
+The \term{type} of a \term{bit vector} that is not displaced
+to another \term{array}, has no \term{fill pointer}, and is 
+not
+%to have its size adjusted dynamically after creation 
+\term{expressly adjustable}
+is a
+\subtypeof{simple-bit-vector}.
+
+\label Compound Type Specifier Kind::
+
+Abbreviating.
+
+\label Compound Type Specifier Syntax::
+
+%% 4.6.0 13
+\Deftype{simple-bit-vector}{\ttbrac{size}}
+
+\label Compound Type Specifier Arguments::
+
+\issue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+\param{size}---a non-negative \term{fixnum},
+	    or the \term{symbol} \misc{*}.
+  \Default{the \term{symbol} \misc{*}}
+\endissue{ARRAY-DIMENSION-IMPLICATIONS:ALL-FIXNUM}
+
+\label Compound Type Specifier Description::
+
+This denotes the same type as the \term{type}
+\f{(simple-array bit (\param{size}))}; 
+that is, the set of \term{simple bit vectors} of size \param{size}.
+
+\endcom%{simple-bit-vector}\ftype{Type}
+
+
+%-------------------- Arrays --------------------
+
+%%% ========== MAKE-ARRAY
+\begincom{make-array}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValuesNewline make-array
+			{dimensions {\key} \vtop{\hbox{element-type}
+                                                 \hbox{initial-element}
+                                                 \hbox{initial-contents}
+                                                 \hbox{adjustable}
+                                                 \hbox{fill-pointer}
+                                                 \hbox{displaced-to}
+                                                 \hbox{displaced-index-offset}}}
+		 	{new-array}
+
+\label Arguments and Values::
+
+%% 17.1.0 3
+\param{dimensions}---a \term{designator} for a \term{list} of \term{valid array dimensions}.
+
+%% 17.1.0 6
+\param{element-type}---a \term{type specifier}. 
+ \Default{\typeref{t}}
+
+\param{initial-element}---an \term{object}.
+
+\param{initial-contents}---an \term{object}.
+%Per Barmar, remove (or sequence vector) because 0-dimension case doesn't care. -kmp 24-Jul-91
+
+\param{adjustable}---a \term{generalized boolean}.
+ \Default{\nil}
+
+%!!! Is there a designator for this?
+\param{fill-pointer}---a \term{valid fill pointer} for the \term{array} to be created,
+		       or \t\ or \nil.
+ \Default{\nil}
+
+%% 17.1.0 11
+\param{displaced-to}---an \term{array} or \nil.
+ \Default{\nil}
+ This option must not be supplied if either \param{initial-element}
+ or \param{initial-contents} is supplied.
+
+%% 17.1.0 12
+\param{displaced-index-offset}---a \term{valid array row-major index} 
+ for \param{displaced-to}. \Default{\f{0}}
+ This option must not be supplied unless a \term{non-nil} \param{displaced-to} is supplied.
+
+\param{new-array}---an \term{array}.
+
+\label Description::
+
+Creates and returns an \term{array} constructed of the most \term{specialized}
+\term{type} that can accommodate elements of \term{type} given by \param{element-type}.
+If \param{dimensions} is \nil\ then a zero-dimensional \term{array} is created.
+
+\param{Dimensions} represents the dimensionality of the new \term{array}.
+
+\param{element-type} indicates the \term{type} of the elements intended to be stored
+in the \param{new-array}.  The \param{new-array} can actually store any \term{objects}
+of the \term{type} which results from \term{upgrading} \param{element-type};
+\seesection\ArrayUpgrading.
+                                                                       
+%% 17.1.0 7
+If \param{initial-element} is supplied, 
+it is used to initialize each \term{element} of \param{new-array}. 
+If \param{initial-element} is supplied,
+it must be of the \term{type} given by \param{element-type}.
+\param{initial-element} cannot be supplied if either the \kwd{initial-contents} option
+is supplied or \param{displaced-to} is \term{non-nil}.
+If \param{initial-element} is not supplied,
+\issue{UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED}
+%% This issue finally did pass at the March-93 meeting. -kmp 5-May-93
+% the initial values of the \term{array} \term{elements} are 
+% %%Rewritten to conform to the fact that issue UNINITIALIZED-ELEMENTS failed
+% %%to clarify this in the other direction because consensus was that this was well-defined
+% %%already. -kmp 15-Jan-92
+% %undefined 
+% \term{implementation-dependent} 
+the consequences of later reading an uninitialized \term{element} of \param{new-array}
+are undefined
+\endissue{UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED}
+unless either \param{initial-contents} is supplied 
+or \param{displaced-to} is \term{non-nil}.
+
+
+%% 17.1.0 8
+\param{initial-contents} is used to initialize the contents of \term{array}.
+For example:
+
+\code
+ (make-array '(4 2 3) :initial-contents
+             '(((a b c) (1 2 3))
+              ((d e f) (3 1 2))
+              ((g h i) (2 3 1))
+              ((j k l) (0 0 0))))
+\endcode
+
+%!!! Is ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY fully merged?
+
+\param{initial-contents} is composed of a nested structure of \term{sequences}. 
+The numbers of levels in the structure must equal the rank of \term{array}.
+Each leaf of the nested structure must be of the \term{type} given by \param{element-type}. 
+If \term{array} is zero-dimensional, then \param{initial-contents} specifies the single
+\term{element}.  Otherwise, \param{initial-contents} must be a \term{sequence}
+whose length is equal to the first dimension; each element must be a nested 
+structure for an \term{array} whose dimensions are the remaining dimensions, 
+and so on.
+\param{Initial-contents} cannot be supplied if either 
+\param{initial-element} is supplied
+or \param{displaced-to} is \term{non-nil}.
+If \param{initial-contents} is not supplied,
+\issue{UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED}
+%% This issue finally did pass at the March-93 meeting. -kmp 5-May-93
+% the initial values of the \term{array} \term{elements} are 
+% %%Rewritten to conform to the fact that issue UNINITIALIZED-ELEMENTS failed
+% %%to clarify this in the other direction because consensus was that this was well-defined
+% %%already. -kmp 15-Jan-92
+% %undefined
+% \term{implementation-dependent}
+the consequences of later reading an uninitialized \term{element} of \param{new-array}
+are undefined
+\endissue{UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED}
+unless either \param{initial-element} is supplied
+or \param{displaced-to} is \term{non-nil}.
+
+%% KMP's rewrite:
+% %% 17.1.0 9
+% If \param{adjustable} is \term{non-nil},
+% the array is both \term{expressly adjustable} 
+% 	      and \term{actually adjustable};
+% otherwise, the array is not \term{expressly adjustable} 
+%        and it is \term{implementation-dependent} whether 
+% 	    the array is \term{actually adjustable}.
+%% To which Barrett suggested:
+% If \param{adjustable} is \term{non-nil},
+% the array is \term{expressly adjustable};
+% otherwise, it is \term{implementation-dependent} whether 
+%   the array is \term{actually adjustable}.
+%% We have compromised on:
+%% 17.1.0 9
+If \param{adjustable} is \term{non-nil},
+the array is \term{expressly adjustable} 
+	      (and so \term{actually adjustable});
+otherwise, the array is not \term{expressly adjustable} 
+       (and it is \term{implementation-dependent} whether 
+	    the array is \term{actually adjustable}).
+% ...
+% it is possible to alter the \term{array}'s size dynamically after it is created.
+%\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY}
+%and \funref{adjustable-array-p} will be true.
+%If \param{adjustable} is not supplied or \nil, 
+%\term{array} is not required to be
+%adjustable, but a non-adjustable \term{array} is not guaranteed.
+%\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY}
+
+%% 17.1.0 10
+If \param{fill-pointer} is \term{non-nil},
+the \term{array} must be one-dimensional;
+that is, the \term{array} must be a \term{vector}.
+If \param{fill-pointer} is \t,
+the length of the \term{vector} is used to initialize the \term{fill pointer}.
+If \param{fill-pointer} is an \term{integer},
+it becomes the initial \term{fill pointer} for the \term{vector}.
+
+If \param{displaced-to} is \term{non-nil},
+\funref{make-array} will create a \term{displaced array} 
+and \param{displaced-to} is the \term{target} of that \term{displaced array}. 
+In that case, the consequences are undefined if the \term{actual array element type} of 
+\param{displaced-to} is not \term{type equivalent} to the \term{actual array element type}
+of the \term{array} being created.
+If \param{displaced-to} is \nil, the \term{array} is not a \term{displaced array}.
+
+%!!! should "index offset" or "displaced index offset" be a formal term?
+The \param{displaced-index-offset} is made to be the index offset of the \term{array}.
+%% 17.1.0 13
+When an array A is given as
+\thekeyarg{displaced-to} to \funref{make-array} 
+when creating array B,
+then array B is said to be displaced to array A.  The
+total number of elements in an \term{array}, 
+called the total size of the \term{array},
+is calculated as the product of all the dimensions.
+It is required that the total size of A be no smaller than the sum
+of the total size of B plus the offset \f{n} supplied by
+the \param{displaced-index-offset}.
+The effect of displacing is that array B does not have any
+elements of its own, but instead maps \term{accesses} to itself into
+\term{accesses} to array A.  The mapping treats both \term{arrays} as if they
+were one-dimensional by taking the elements in row-major order,
+and then maps an \term{access} to element \f{k} of array B to an \term{access} to element
+\f{k}+\f{n} of array A.
+
+%% 17.1.0 14
+If \funref{make-array} is called with \param{adjustable}, \param{fill-pointer},
+and \param{displaced-to} each \nil, 
+then the result is a \term{simple array}.
+\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+If \funref{make-array} is called with one or more of \param{adjustable},
+\param{fill-pointer}, or \param{displaced-to} being \term{true}, whether the
+resulting \term{array} is a \term{simple array} is \term{implementation-dependent}.
+\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+
+%% 17.1.0 13
+  When an array A is given as \thekeyarg{displaced-to} to
+  \funref{make-array} when creating array B, then array B is said to
+  be displaced to array A.  The total number of elements in an \term{array}, 
+  called the total size of the \term{array}, is calculated as the product
+  of all the dimensions.
+The consequences are unspecified if
+the total size of A is smaller than the sum
+of the total size of B plus the offset \f{n} supplied by
+the \param{displaced-index-offset}.
+The effect of displacing is that array B does not have any
+elements of its own, but instead maps \term{accesses} to itself into
+\term{accesses} to array A.  The mapping treats both \term{arrays} as if they
+were one-dimensional by taking the elements in row-major order,
+and then maps an \term{access} to element \f{k} of array B to an \term{access} 
+to \term{element} \f{k}+\f{n} of array A.
+
+%% Redundant with previous paragraph.
+% When \kwd{displaced-to} is supplied to \funref{make-array},
+% the \param{displaced-index-offset} is made to be the
+% index offset of the \term{array}.
+%% Redundant with Arguments and Values above.
+% If the \param{displaced-index-offset} is not supplied,
+% the index offset is zero.
+
+\label Examples::
+%% 17.1.0 15
+\code
+
+ (make-array 5) ;; Creates a one-dimensional array of five elements.
+ (make-array '(3 4) :element-type '(mod 16)) ;; Creates a 
+                ;;two-dimensional array, 3 by 4, with four-bit elements.
+ (make-array 5 :element-type 'single-float) ;; Creates an array of single-floats.
+\endcode
+
+\code
+ (make-array nil :initial-element nil) \EV #0ANIL
+ (make-array 4 :initial-element nil) \EV #(NIL NIL NIL NIL)
+ (make-array '(2 4) 
+              :element-type '(unsigned-byte 2) 
+              :initial-contents '((0 1 2 3) (3 2 1 0)))
+\EV #2A((0 1 2 3) (3 2 1 0))
+ (make-array 6
+              :element-type 'character 
+              :initial-element #\\a 
+              :fill-pointer 3) \EV "aaa"
+\endcode
+
+The following is an example of making a \term{displaced array}.
+
+\code
+ (setq a (make-array '(4 3))) 
+\EV #<ARRAY 4x3 simple 32546632>
+ (dotimes (i 4)
+   (dotimes (j 3)
+     (setf (aref a i j) (list i 'x j '= (* i j)))))
+\EV NIL
+ (setq b (make-array 8 :displaced-to a
+                       :displaced-index-offset 2))
+\EV #<ARRAY 8 indirect 32550757>
+ (dotimes (i 8)
+   (print (list i (aref b i))))
+\OUT (0 (0 X 2 = 0)) 
+\OUT (1 (1 X 0 = 0)) 
+\OUT (2 (1 X 1 = 1)) 
+\OUT (3 (1 X 2 = 2)) 
+\OUT (4 (2 X 0 = 0)) 
+\OUT (5 (2 X 1 = 2)) 
+\OUT (6 (2 X 2 = 4)) 
+\OUT (7 (3 X 0 = 0)) 
+\EV NIL
+\endcode
+The last example depends on the fact that \term{arrays} are, in effect,
+stored in row-major order. 
+
+\code
+ (setq a1 (make-array 50))
+\EV #<ARRAY 50 simple 32562043>
+ (setq b1 (make-array 20 :displaced-to a1 :displaced-index-offset 10))
+\EV #<ARRAY 20 indirect 32563346>
+ (length b1) \EV 20
+
+ (setq a2 (make-array 50 :fill-pointer 10))
+\EV #<ARRAY 50 fill-pointer 10 46100216>
+ (setq b2 (make-array 20 :displaced-to a2 :displaced-index-offset 10))
+\EV #<ARRAY 20 indirect 46104010>
+ (length a2) \EV 10
+ (length b2) \EV 20
+
+ (setq a3 (make-array 50 :fill-pointer 10))
+\EV #<ARRAY 50 fill-pointer 10 46105663>
+ (setq b3 (make-array 20 :displaced-to a3 :displaced-index-offset 10
+                         :fill-pointer 5))
+\EV #<ARRAY 20 indirect, fill-pointer 5 46107432>
+ (length a3) \EV 10
+ (length b3) \EV 5
+\endcode
+  
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{adjustable-array-p},
+\funref{aref},
+\funref{arrayp},
+\funref{array-element-type},
+\conref{array-rank-limit},
+\conref{array-dimension-limit},
+\funref{fill-pointer},
+\funref{upgraded-array-element-type}
+
+\label Notes::
+
+\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+There is no specified way to create an \term{array} 
+for which \funref{adjustable-array-p} definitely
+returns \term{false}.
+There is no specified way to create an \term{array} 
+that is not a \term{simple array}.
+\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+ 
+\endcom
+
+
+%%% ========== ADJUST-ARRAY
+\begincom{adjust-array}\ftype{Function}
+
+%!!! Barmar's review comments of this were made on the basis of document that
+%    did not include various cleanups.  This should be re-reviewed carefully later.
+%    -kmp 17-Dec-90
+
+\label Syntax::
+
+\DefunWithValuesNewline adjust-array
+			{array new-dimensions {\key} \vtop{\hbox{element-type}
+                                                           \hbox{initial-element}
+                                                           \hbox{initial-contents}
+                                                           \hbox{fill-pointer}
+                                                           \hbox{displaced-to}
+                                                           \hbox{displaced-index-offset}}}
+			{adjusted-array}
+
+\label Arguments and Values:: 
+                                  
+\param{array}---an \term{array}.
+
+\param{new-dimensions}---a \term{valid array dimension} 
+   		      or a \term{list} of \term{valid array dimensions}.
+
+%% 17.6.0 6
+\param{element-type}---a \term{type specifier}.
+%!!! Not sure how to express the default.  Mail sent to Quinquevirate asking for thoughts.
+
+%% 17.6.0 7
+\param{initial-element}---an \term{object}.
+  \param{Initial-element} must not be supplied if either 
+  \param{initial-contents} or \param{displaced-to} is supplied.
+%!!! How to express this default??
+
+%!!! "array contents designator" ? -kmp 14-May-91
+\param{initial-contents}---an \term{object}.
+ If \term{array} has rank greater than zero, then \param{initial-contents}
+ is composed of nested \term{sequences}, the depth of which must equal
+ the rank of \param{array}.  Otherwise, \term{array} is zero-dimensional and
+ \param{initial-contents} supplies the single element.
+ \param{initial-contents} must not be supplied if either 
+ \param{initial-element} or \param{displaced-to} is given.
+
+%% 17.6.0 8
+\param{fill-pointer}---a \term{valid fill pointer} for the
+ \term{array} to be created, or \t, or \nil.
+ \Default{\nil}
+
+\param{displaced-to}---an \term{array} or \nil.
+ \param{initial-elements} and \param{initial-contents} must not be supplied
+ if \param{displaced-to} is supplied.
+%!!! Default?
+
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\param{displaced-index-offset}---an \objectoftype{(fixnum 0 \i{n})} 
+ where \i{n} is {\tt (array-total-size \param{displaced-to})}.
+ \param{displaced-index-offset} may be supplied only if \param{displaced-to} is supplied.
+%!!! Default?
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\param{adjusted-array}---an \term{array}.
+
+\label Description::
+
+%% 17.6.0 3
+\funref{adjust-array} changes the dimensions or elements of \param{array}.
+The result is an \term{array} of the same \term{type} and rank as \param{array},
+%% 17.6.0 4
+%% 17.6.0 9
+that is either the modified \param{array},
+or a newly created \term{array} to which
+\param{array} can be displaced, and that has 
+the given \param{new-dimensions}.
+
+%% Sandra points out that this is implied by the definition of "valid array dimension".
+% The total number of elements that \param{array} 
+% can contain (as given by the
+% product of all \param{new-dimensions}) must be less than 
+% \conref{array-total-size-limit}.                         
+
+\param{New-dimensions} specify the size of each \term{dimension} of \param{array}. 
+
+\param{Element-type} specifies the \term{type} of the \term{elements}
+of the resulting \term{array}.  If \param{element-type} is supplied,
+% % the consequences are unspecified if it is not a \term{type}
+% % %What does "compatible" mean here?? -kmp 29-Apr-91
+% % %Sandra's curious, too. -kmp 14-Feb-92
+% % that is compatible with {\tt (array-element-type \param{array})}.
+% %% Sandra's suggested rewrite:
+% the consequences are unspecified if
+% \f{(upgraded-array-element-type \param{element-type})}
+% is not the same as {\tt (array-element-type \param{array})}.
+%% KMP's rewrite
+the consequences are unspecified if
+the \term{upgraded array element type} of \param{element-type}
+is not the same as the \term{actual array element type} of \param{array}.
+%% Sandra thinks this is redundant.
+% If the resulting \term{array} is a displaced \term{array},
+% the consequences are unspecified if \param{element-type}
+% is not compatible with the \term{element type} of the \term{array} 
+% that the resulting \term{array} shares elements with.
+%% Redundant with Arguments and Values.
+%If \kwd{element-type} is not supplied, the elements are of type \t.
+
+If \param{initial-contents} is supplied, it is treated as for
+\funref{make-array}.  In this case none of the original contents of
+\param{array} appears in the resulting \term{array}.
+
+\issue{ADJUST-ARRAY-FILL-POINTER}
+If \param{fill-pointer} is an \term{integer},
+it becomes the \term{fill pointer} for the resulting \term{array}.
+If \param{fill-pointer} is the symbol \t,
+it indicates that the size of the resulting \term{array} 
+should be used as the \term{fill pointer}.
+If \param{fill-pointer} is \nil,
+it indicates that the \term{fill pointer} should be left as it is.
+\endissue{ADJUST-ARRAY-FILL-POINTER}
+
+If \param{displaced-to}
+%is supplied and
+\term{non-nil}, a \term{displaced array}
+is created. The resulting \term{array} shares its contents with the \term{array} given by
+\param{displaced-to}.
+The resulting \term{array} cannot contain more elements than the \term{array}
+it is displaced to.  
+If \param{displaced-to} is not supplied or \nil,
+the resulting \term{array} is not a \term{displaced array}.
+If array $A$ is created displaced to array $B$ and subsequently
+array $B$ is given to \funref{adjust-array}, array $A$ will still be
+displaced to array $B$.
+Although \param{array} might be a \term{displaced array}, 
+the resulting \term{array} is not a \term{displaced array} unless
+\param{displaced-to} is supplied and not \nil.
+\issue{ADJUST-ARRAY-DISPLACEMENT}
+The interaction between \funref{adjust-array} and 
+displaced \term{arrays} 
+is as follows given three \term{arrays}, {\tt A}, {\tt B}, and~{\tt C}:
+
+\beginlist
+\itemitem{{\tt A} is not displaced before or after the call}
+
+\code
+ (adjust-array A ...)
+\endcode
+
+The dimensions of {\tt A} are altered, and the
+contents rearranged as appropriate.  
+Additional elements of {\tt A} are taken from
+\param{initial-element}.  
+The use of \param{initial-contents} causes all old contents to be
+discarded.
+
+\itemitem{{\tt A} is not displaced before, but is displaced to 
+{\tt C} after the call}  
+
+\code
+ (adjust-array A ... :displaced-to C)
+\endcode
+               
+None of the original contents of {\tt A} appears in 
+{\tt A} afterwards; {\tt A} now contains
+the contents of {\tt C}, without any rearrangement of {\tt C}.
+
+\itemitem{{\tt A} is displaced to {\tt B} 
+before the call, and is displaced to {\tt C} after 
+the call}
+
+\code
+ (adjust-array A ... :displaced-to B)
+ (adjust-array A ... :displaced-to C)
+\endcode
+
+{\tt B} and {\tt C} might be the same. The contents of {\tt B} do not appear in 
+{\tt A} afterward unless such contents also happen to be in {\tt C}  If
+\param{displaced-index-offset} 
+is not supplied in the \funref{adjust-array} call, it defaults
+to zero; the old offset into {\tt B} is not retained.
+                                  
+%% 17.6.0 11
+\itemitem{{\tt A} is displaced to {\tt B} before the call, but not displaced
+afterward.}  
+
+\code
+ (adjust-array A ... :displaced-to B)
+ (adjust-array A ... :displaced-to nil)
+\endcode
+{\tt A} gets a
+new ``data region,'' and contents of {\tt B} are copied into it as appropriate to
+maintain the existing old contents; additional elements of {\tt A} 
+are taken from
+\param{initial-element} if supplied.  However, 
+the use of \param{initial-contents} causes all old contents
+to be discarded.
+%If \param{array} is displaced
+%to another array \f{x} when \funref{adjust-array}
+%is applied to \param{array}, then afterwards neither 
+%\param{array} nor the returned
+%result is displaced to \f{x} unless such displacement is explicitly
+%re-specified in the call to \funref{adjust-array}.
+\endlist
+\endissue{ADJUST-ARRAY-DISPLACEMENT}
+                      
+If \param{displaced-index-offset} is supplied,
+it specifies the offset
+of the resulting \term{array} from the beginning of 
+the \term{array} that it is displaced to.           
+If \param{displaced-index-offset} is not supplied, the offset is~0.  
+The size of the resulting \term{array} plus the 
+offset value cannot exceed the size of
+the \term{array} that it is displaced to.
+
+%% 17.6.0 5
+If only \param{new-dimensions}
+and an \param{initial-element} argument are supplied,
+those elements of \param{array} that
+are still in bounds appear in the resulting \term{array}. The elements of
+the resulting \term{array} that are not in the bounds of 
+\term{array} are initialized
+to \param{initial-element}; if \param{initial-element} is not provided,
+\issue{UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED}
+%% This issue finally did pass at the March-93 meeting. -kmp 5-May-93
+% then the initial contents of any resulting \term{elements}
+% %%Rewritten to conform to the fact that issue UNINITIALIZED-ELEMENTS failed
+% %%to clarify this in the other direction because consensus was that this was well-defined
+% %%already. -kmp 15-Jan-92
+% %are undefined.
+% is \term{implementation-dependent}.
+the consequences of later reading any such new \term{element} of \param{new-array}
+before it has been initialized
+are undefined.
+\endissue{UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED}
+
+If \param{initial-contents} or \param{displaced-to} is supplied,
+then none of the original contents of \param{array} appears in the new \term{array}.
+
+%% 17.6.0 10
+
+\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+%The following will be deleted:
+%
+%The consequences are unspecified
+%if \funref{adjust-array} is invoked with an \param{array} argument
+%that is not adjustable.
+
+\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+%If \param{fill-pointer} is \nil,
+%then the consequences are unspecified if
+%\param{array} has a \term{fill pointer}.
+The consequences are unspecified if \param{array} is adjusted 
+to a size smaller than its \term{fill pointer} without supplying
+the \param{fill-pointer} argument so that its \term{fill-pointer}
+is properly adjusted in the process.
+
+If {\tt A} is displaced to {\tt B}, the consequences are unspecified 
+if {\tt B} is adjusted in such a way that it no longer has enough elements
+to satisfy {\tt A}.  
+
+\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+
+If \funref{adjust-array} is applied to an \term{array} that is \term{actually adjustable},
+the \term{array} returned is \term{identical} to \param{array}.
+%% This was only needed when "\term{expressly adjustable}" was used in the previous sentence.
+% It is \term{implementation-dependent} whether \funref{adjust-array} 
+% returns an \term{array} that is \term{identical} to its first argument for any
+% other \term{arrays}.
+If the \term{array} returned by \funref{adjust-array} 
+is \term{distinct} from \param{array}, then the argument \param{array} is unchanged.
+\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+ 
+Note that if an \term{array} $A$ is displaced to another \term{array} $B$,
+and $B$ is displaced to another \term{array} $C$, and $B$ is altered by
+\funref{adjust-array}, $A$ must now refer to the adjust contents of $B$.
+This means that an implementation cannot collapse the chain to make $A$
+refer to $C$ directly and forget that the chain of reference passes through
+$B$.  However, caching techniques are permitted as long as they preserve the 
+semantics specified here.
+
+\label Examples::
+
+\code
+ (adjustable-array-p
+  (setq ada (adjust-array
+              (make-array '(2 3)
+                          :adjustable t
+                          :initial-contents '((a b c) (1 2 3)))
+              '(4 6)))) \EV T 
+ (array-dimensions ada) \EV (4 6) 
+ (aref ada 1 1) \EV 2 
+ (setq beta (make-array '(2 3) :adjustable t))
+\EV #2A((NIL NIL NIL) (NIL NIL NIL)) 
+ (adjust-array beta '(4 6) :displaced-to ada)
+\EV #2A((A B C NIL NIL NIL)
+       (1 2 3 NIL NIL NIL)
+       (NIL NIL NIL NIL NIL NIL) 
+       (NIL NIL NIL NIL NIL NIL))
+ (array-dimensions beta) \EV (4 6)
+ (aref beta 1 1) \EV 2 
+\endcode
+
+%% 17.6.0 11
+Suppose that the 4-by-4 array in \f{m} looks like this:
+
+\code
+#2A(( alpha     beta      gamma     delta )
+    ( epsilon   zeta      eta       theta )
+    ( iota      kappa     lambda    mu    )
+    ( nu        xi        omicron   pi    ))
+\endcode
+Then the result of
+
+\code
+ (adjust-array m '(3 5) :initial-element 'baz)
+\endcode
+is a 3-by-5 array with contents       
+
+\code
+#2A(( alpha     beta      gamma     delta     baz )
+    ( epsilon   zeta      eta       theta     baz )
+    ( iota      kappa     lambda    mu        baz ))
+\endcode
+
+\label Affected By:\None!
+
+%%I don't think this sort of thing is worthwhile to note. -kmp 7-Jan-91
+%How \param{array} was created.
+
+\label Exceptional Situations::
+
+An error \oftype{error} is signaled if \param{fill-pointer} is supplied
+and \term{non-nil} but \param{array} has no \term{fill pointer}.
+
+%\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY}
+%An error \oftype{error} is signaled if an attempt
+%  is made to adjust an \param{array} that is not adjustable (that is, an
+%  \param{array} for which \funref{adjustable-array-p} returns \term{false}).
+% 
+%\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY}
+\label See Also::
+
+\funref{adjustable-array-p},    \funref{make-array},
+\funref{array-dimension-limit}, \funref{array-total-size-limit},
+\typeref{array}
+
+\label Notes:\None.
+
+%\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY}
+%\funref{adjustable-array-p} is an appropriate
+%  predicate to determine whether \funref{adjust-array} will reliably succeed.
+%\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKE Y}
+
+%% Sandra thinks this is redundant.
+% \issue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+% The value returned by \funref{adjust-array} might not be \term{identical} 
+% to the argument \param{array}.
+% \endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+
+\endcom                 
+
+%%% ========== ADJUSTABLE-ARRAY-P
+\begincom{adjustable-array-p}\ftype{Function}
+
+%!!! Barmar's review comments of this were made on the basis of document that
+%    did not include various cleanups.  This should be re-reviewed carefully later.
+%    -kmp 17-Dec-90
+
+\label Syntax::
+
+\DefunWithValues adjustable-array-p {array} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+
+%% 17.3.0 13
+Returns true if and only if \funref{adjust-array} could return a \term{value}
+which is \term{identical} to \param{array} when given that \term{array} as its
+first \term{argument}.
+\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY}
+
+\label Examples::
+
+\code
+ (adjustable-array-p 
+   (make-array 5
+               :element-type 'character 
+               :adjustable t 
+               :fill-pointer 3)) \EV \term{true}
+ (adjustable-array-p (make-array 4)) \EV \term{implementation-dependent}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+Should signal an error \oftype{type-error} if its argument is not an \term{array}.
+
+\label See Also::
+
+\funref{adjust-array}, \funref{make-array}
+
+\label Notes:\None.
+%\issue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY}
+%
+%  
+%  An \term{array} ``is adjustable'' 
+%if {\tt (adjustable-array-p \term{array})} is \term{true}.
+%  The adjustability of an \term{array} has no necessary
+%  relation to any value that was given (or not given) by the \kwd{adjustable} 
+%  \term{argument}
+%  in the call to \funref{make-array} that created the \term{array}.
+%
+%  There is no portable way to create a non-adjustable
+%  \term{array} (that is, an \term{array} for which \funref{adjustable-array-p} is
+%  guaranteed to return \term{false}).
+%\endissue{ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY}
+\endcom
+
+%%% ========== AREF
+\begincom{aref}\ftype{Accessor}
+
+\label Syntax::
+
+\DefunWithValues aref {array {\rest} subscripts} {element}
+\Defsetf         aref {array {\rest} subscripts} {new-element}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\param{subscripts}---a \term{list} of \term{valid array indices} for the \param{array}.
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\param{element}, \param{new-element}---an \term{object}.
+
+\label Description::
+
+%% 17.2.0 3
+\term{Accesses} the \param{array} \term{element} specified by the \param{subscripts}.
+If no \param{subscripts} are supplied and \param{array} is zero rank,
+\funref{aref} \term{accesses} the sole element of \param{array}.
+
+%% 17.2.0 4
+\funref{aref} ignores \term{fill pointers}.
+It is permissible to use \funref{aref} 
+to \term{access} any \param{array} \term{element},
+whether \term{active} or not.
+
+%% This is implied by the use of "access" above.
+% %% 17.2.0 5
+% \macref{setf} can be used with \funref{aref} to destructively replace
+% an \term{array} element with a new value.
+
+\label Examples::
+
+%% 2.5.0 6
+If the variable \f{foo} names a 3-by-5 array,
+then the first index could be 0, 1, or 2, and then second index
+could be 0, 1, 2, 3, or 4.  The array elements can be referred to by using
+\thefunction{aref}; for example, \f{(aref foo 2 1)}
+refers to element (2, 1) of the array.  
+
+\code
+ (aref (setq alpha (make-array 4)) 3) \EV \term{implementation-dependent}
+ (setf (aref alpha 3) 'sirens) \EV SIRENS
+ (aref alpha 3) \EV SIRENS
+ (aref (setq beta (make-array '(2 4) 
+                    :element-type '(unsigned-byte 2)
+                    :initial-contents '((0 1 2 3) (3 2 1 0))))
+        1 2) \EV 1
+ (setq gamma '(0 2))
+ (apply #'aref beta gamma) \EV 2
+ (setf (apply #'aref beta gamma) 3) \EV 3
+ (apply #'aref beta gamma) \EV 3
+ (aref beta 0 2) \EV 3
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{bit},
+\funref{char},
+\funref{elt},
+\funref{row-major-aref},
+\funref{svref},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification}
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ARRAY-DIMENSION
+\begincom{array-dimension}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-dimension {array axis-number} {dimension}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\param{axis-number}---an \term{integer} greater than or equal to zero
+		      and less than the \term{rank} of the \param{array}.
+
+% Barmar observes that nothing requires the implementation to enforce ARRAY-DIMENSION-LIMIT.
+% It's a requirement on the user to be prepared to lose if he exceeds it,
+% but it is not a requirement on the implementation to make him lose in that case.
+\param{dimension}---a non-negative \term{integer}.
+
+\label Description::
+
+%!!! (array-dimension (make-array nil) ??)
+
+%% 17.3.0 6
+\funref{array-dimension} returns the \param{axis-number} 
+\term{dimension}\meaning{1} of \param{array}.
+%This next is implied by the definition of dimension, but retained for now for safety. -kmp
+(Any \term{fill pointer} is ignored.)
+
+\label Examples::
+
+\code
+ (array-dimension (make-array 4) 0) \EV 4
+ (array-dimension (make-array '(2 3)) 1) \EV 3
+\endcode
+
+
+\label Affected By::    
+None.
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{array-dimensions}, \funref{length}
+
+\label Notes::
+\code
+ (array-dimension array n) \EQ (nth n (array-dimensions array))
+\endcode
+\endcom
+
+%%% ========== ARRAY-DIMENSIONS
+\begincom{array-dimensions}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-dimensions {array} {dimensions}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+% Barmar observes that nothing requires the implementation to enforce ARRAY-DIMENSION-LIMIT.
+% It's a requirement on the user to be prepared to lose if he exceeds it,
+% but it is not a requirement on the implementation to make him lose in that case.
+\param{dimensions}---a \term{list} of \term{integers}.
+
+\label Description::                    
+
+%% 17.3.0 8
+Returns a \term{list} of the \term{dimensions} of \param{array}.
+(If \param{array} is a \term{vector} with a \term{fill pointer}, 
+ that \term{fill pointer} is ignored.)
+
+\label Examples::
+
+\code
+ (array-dimensions (make-array 4)) \EV (4)
+ (array-dimensions (make-array '(2 3))) \EV (2 3)
+ (array-dimensions (make-array 4 :fill-pointer 2)) \EV (4)
+\endcode
+
+\label Affected By:\None!
+
+\label Exceptional Situations::
+
+Should signal an error \oftype{type-error} if its argument is not an \term{array}.
+
+\label See Also::
+
+\funref{array-dimension}
+
+%% Per X3J13. -kmp 05-Oct-93
+\label Notes:\None.
+                                
+\endcom
+
+%%% ========== ARRAY-ELEMENT-TYPE
+\begincom{array-element-type}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-element-type {array} {typespec}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\param{typespec}---a \term{type specifier}.
+
+\label Description::
+
+%% 17.3.0 3
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+Returns a \term{type specifier} which represents the \term{actual array element type}
+of the array, which is the set of \term{objects} that such an \param{array} can hold.
+%Barmar points out that this is redundant.
+% after upgrading.
+(Because of \term{array} \term{upgrading}, this \term{type specifier} can in
+some cases denote a \term{supertype} of the \term{expressed array element type}
+of the \param{array}.)
+%\term{type} requested by the user when \param{array} was created.
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+
+\label Examples::
+
+\code
+ (array-element-type (make-array 4)) \EV T
+ (array-element-type (make-array 12 :element-type '(unsigned-byte 8))) 
+\EV \term{implementation-dependent}
+ (array-element-type (make-array 12 :element-type '(unsigned-byte 5)))
+\EV \term{implementation-dependent}
+\endcode
+
+\code
+ (array-element-type (make-array 5 :element-type '(mod 5)))
+\endcode
+could be \f{(mod 5)}, \f{(mod 8)}, \f{fixnum}, \f{t}, or any other
+type of which \f{(mod 5)} is a \term{subtype}.
+
+\label Affected By::
+
+The \term{implementation}.
+
+\label Exceptional Situations::
+
+Should signal an error \oftype{type-error} if its argument is not an \term{array}.
+
+\label See Also::
+
+\typeref{array},
+\funref{make-array},
+\funref{subtypep},
+\funref{upgraded-array-element-type}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ARRAY-HAS-FILL-POINTER-P
+\begincom{array-has-fill-pointer-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-has-fill-pointer-p {array} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 17.5.0 5
+Returns \term{true} if \param{array} has a \term{fill pointer};
+otherwise returns \term{false}.
+
+\label Examples::
+
+\code
+ (array-has-fill-pointer-p (make-array 4)) \EV \term{implementation-dependent}
+ (array-has-fill-pointer-p (make-array '(2 3))) \EV \term{false}
+ (array-has-fill-pointer-p
+   (make-array 8 
+               :fill-pointer 2 
+               :initial-element 'filler)) \EV \term{true}
+\endcode
+
+\label Affected By:\None!
+
+\label Exceptional Situations::
+
+Should signal an error \oftype{type-error} if its argument is not an \term{array}.
+
+\label See Also::
+
+\funref{make-array}, \funref{fill-pointer}
+
+\label Notes::
+
+Since \term{arrays} of \term{rank} other than one cannot have a \term{fill pointer},
+\funref{array-has-fill-pointer-p} always returns \nil\ when its argument
+is such an array.
+
+\endcom
+
+%--------------------
+
+\begincom{array-displacement}\ftype{Function}
+
+\issue{DISPLACED-ARRAY-PREDICATE:ADD}
+
+\label Syntax::
+
+\DefunWithValues array-displacement {array} {displaced-to, displaced-index-offset}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\param{displaced-to}---an \param{array} or \nil.
+
+\param{displaced-index-offset}---a non-negative \term{fixnum}.
+
+\label Description::
+
+If the \param{array} is a \term{displaced array},
+returns the \term{values} of the \kwd{displaced-to} and \kwd{displaced-index-offset}
+options
+for the \term{array} (\seefuns{make-array} and \funref{adjust-array}).
+If the \param{array} is not a \term{displaced array},
+\nil\ and \f{0} are returned.
+
+If \funref{array-displacement} is called on an \param{array}
+for which a \term{non-nil} \term{object} was provided as the
+\kwd{displaced-to} \term{argument} to \funref{make-array} 
+or \funref{adjust-array}, it must return that \term{object}
+as its first value. It is \term{implementation-dependent}
+whether \funref{array-displacement} returns a \term{non-nil}
+\term{primary value} for any other \param{array}.
+
+\label Examples::
+
+\code
+ (setq a1 (make-array 5)) \EV #<ARRAY 5 simple 46115576>
+ (setq a2 (make-array 4 :displaced-to a1
+                        :displaced-index-offset 1))
+\EV #<ARRAY 4 indirect 46117134>
+ (array-displacement a2)
+\EV #<ARRAY 5 simple 46115576>, 1
+ (setq a3 (make-array 2 :displaced-to a2
+                        :displaced-index-offset 2))
+\EV #<ARRAY 2 indirect 46122527>
+ (array-displacement a3)
+\EV #<ARRAY 4 indirect 46117134>, 2
+\endcode
+
+\label Affected By:\None!
+
+\label Exceptional Situations::
+
+\Shouldchecktype{array}{an \term{array}}
+
+\label See Also::
+
+\funref{make-array}
+
+%% Per X3J13. -kmp 05-Oct-93
+\label Notes:\None.
+\endissue{DISPLACED-ARRAY-PREDICATE:ADD}
+
+\endcom
+
+
+%%% ========== ARRAY-IN-BOUNDS-P
+\begincom{array-in-bounds-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-in-bounds-p {array {\rest} subscripts} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+% Note that they needn't be valid array indices, 
+% since that would make this function a lot less interesting!
+\param{subscripts}---a list of \term{integers} 
+		     of length equal to the \term{rank} of the \term{array}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 17.3.0 10
+Returns \term{true} if the \param{subscripts} are all in bounds for \param{array};
+otherwise returns \term{false}.
+(If \param{array} is a \term{vector} with a \term{fill pointer}, 
+ that \term{fill pointer} is ignored.)
+
+\label Examples::
+\code
+ (setq a (make-array '(7 11) :element-type 'string-char))
+ (array-in-bounds-p a 0  0) \EV \term{true}
+ (array-in-bounds-p a 6 10) \EV \term{true}
+ (array-in-bounds-p a 0 -1) \EV \term{false}
+ (array-in-bounds-p a 0 11) \EV \term{false}
+ (array-in-bounds-p a 7  0) \EV \term{false}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{array-dimensions}
+
+\label Notes::
+\code
+ (array-in-bounds-p array subscripts)   
+ \EQ (and (not (some #'minusp (list subscripts)))
+         (every #'< (list subscripts) (array-dimensions array)))
+\endcode
+\endcom
+
+%%% ========== ARRAY-RANK
+\begincom{array-rank}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-rank {array} {rank}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+% Barmar observes that nothing requires the implementation to enforce ARRAY-RANK-LIMIT.
+% It's a requirement on the user to be prepared to lose if he exceeds it,
+% but it is not a requirement on the implementation to make him lose in that case.
+\param{rank}---a non-negative \term{integer}.
+
+\label Description::
+
+%% 17.3.0 4                                         
+Returns the number of \term{dimensions} of \param{array}.
+                                     
+\label Examples::
+
+\code
+ (array-rank (make-array '())) \EV 0
+ (array-rank (make-array 4)) \EV 1
+ (array-rank (make-array '(4))) \EV 1
+ (array-rank (make-array '(2 3))) \EV 2
+\endcode
+
+\label Affected By:\None.
+                          
+\label Exceptional Situations::
+
+Should signal an error \oftype{type-error} if its argument is not an \term{array}.
+
+\label See Also::
+
+\conref{array-rank-limit}, \funref{make-array}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ARRAY-ROW-MAJOR-INDEX
+\begincom{array-row-major-index}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-row-major-index {array {\rest} subscripts} {index}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\param{subscripts}---a \term{list} of \term{valid array indices} for the \param{array}.
+
+\param{index}---a \term{valid array row-major index} for the \param{array}.
+
+\label Description::
+
+%% 17.3.0 11
+Computes the position according to the row-major ordering of \param{array}
+for the element that is specified by \param{subscripts}, and returns the
+offset of the element in the computed position from the beginning of \param{array}.
+
+For a one-dimensional \param{array}, 
+the result of \funref{array-row-major-index}
+equals \param{subscript}.
+
+\funref{array-row-major-index} ignores \term{fill pointers}.
+
+\label Examples::
+
+\code
+ (setq a (make-array '(4 7) :element-type '(unsigned-byte 8)))
+ (array-row-major-index a 1 2) \EV 9
+ (array-row-major-index 
+    (make-array '(2 3 4) 
+                :element-type '(unsigned-byte 8)
+                :displaced-to a
+                :displaced-index-offset 4)
+    0 2 1) \EV 9
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also:\None.
+
+\label Notes::
+
+%% 17.3.0 12
+A possible definition of \funref{array-row-major-index}, 
+with no error-checking, is
+
+\code
+ (defun array-row-major-index (a &rest subscripts)
+   (apply #'+ (maplist #'(lambda (x y)
+                            (* (car x) (apply #'* (cdr y))))
+                       subscripts
+                       (array-dimensions a))))
+\endcode
+
+\endcom
+
+%%% ========== ARRAY-TOTAL-SIZE
+\begincom{array-total-size}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues array-total-size {array} {size}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+% Barmar observes that nothing requires the implementation to enforce ARRAY-TOTAL-SIZE-LIMIT.
+% It's a requirement on the user to be prepared to lose if he exceeds it,
+% but it is not a requirement on the implementation to make him lose in that case.
+\param{size}---a non-negative \term{integer}.
+
+\label Description::
+
+%% 17.3.0 9
+Returns the \term{array total size} of the \param{array}.
+
+\label Examples::
+
+\code
+ (array-total-size (make-array 4)) \EV 4
+ (array-total-size (make-array 4 :fill-pointer 2)) \EV 4
+ (array-total-size (make-array 0)) \EV 0
+ (array-total-size (make-array '(4 2))) \EV 8
+ (array-total-size (make-array '(4 0))) \EV 0
+ (array-total-size (make-array '())) \EV 1
+\endcode
+
+\label Affected By:\None!
+
+\label Exceptional Situations::
+
+Should signal an error \oftype{type-error} if its argument is not an \term{array}.
+
+\label See Also::
+
+\funref{make-array}, \funref{array-dimensions}
+
+\label Notes::
+
+If the \param{array} is a \term{vector} with a \term{fill pointer},
+the \term{fill pointer} is ignored when calculating the \term{array total size}.
+
+Since the product of no arguments is one, the \term{array total size} of a
+zero-dimensional \term{array} is one.
+
+\code
+ (array-total-size x)
+    \EQ (apply #'* (array-dimensions x))
+    \EQ (reduce #'* (array-dimensions x))
+\endcode
+
+\endcom
+
+%%% ========== ARRAYP
+\begincom{arrayp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues arrayp {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 24
+\TypePredicate{object}{array}
+       
+\label Examples::
+
+\code
+ (arrayp (make-array '(2 3 4) :adjustable t)) \EV \term{true}
+ (arrayp (make-array 6)) \EV \term{true}
+ (arrayp #*1011) \EV \term{true}
+ (arrayp "hi") \EV \term{true}
+ (arrayp 'hi) \EV \term{false}
+ (arrayp 12) \EV \term{false}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\funref{typep}
+
+\label Notes::
+
+\code
+ (arrayp \param{object}) \EQ (typep \param{object} 'array)
+\endcode
+
+\endcom
+
+%%% ========== FILL-POINTER
+\begincom{fill-pointer}\ftype{Accessor}
+
+\label Syntax::
+
+%% 17.5.0 7
+\DefunWithValues fill-pointer {vector} {fill-pointer}
+\Defsetf         fill-pointer {vector} {new-fill-pointer}
+
+\label Arguments and Values::
+
+\param{vector}---a \term{vector} with a \term{fill pointer}.
+
+\param{fill-pointer}, \param{new-fill-pointer}---a \term{valid fill pointer} 
+  for the \param{vector}.
+
+\label Description::
+
+%% 17.5.0 6
+\term{Accesses} the \term{fill pointer} of \param{vector}.
+
+\label Examples::
+
+\code
+ (setq a (make-array 8 :fill-pointer 4)) \EV #(NIL NIL NIL NIL)
+ (fill-pointer a) \EV 4
+ (dotimes (i (length a)) (setf (aref a i) (* i i))) \EV NIL
+ a \EV #(0 1 4 9)
+ (setf (fill-pointer a) 3) \EV 3
+ (fill-pointer a) \EV 3
+ a \EV #(0 1 4)
+ (setf (fill-pointer a) 8) \EV 8
+ a \EV #(0 1 4 9 NIL NIL NIL NIL)
+\endcode
+
+\label Side Effects:\None!
+
+\label Affected By:\None!
+
+\label Exceptional Situations::
+
+\Shouldchecktype{vector}{a \term{vector} with a \term{fill pointer}}
+
+\label See Also::
+
+\funref{make-array}, \funref{length}
+
+\label Notes::
+
+There is no \term{operator} that will remove a \term{vector}'s \term{fill pointer}.
+
+\endcom
+
+%%% ========== ROW-MAJOR-AREF
+\begincom{row-major-aref}\ftype{Accessor}
+\issue{AREF-1D}
+
+\label Syntax:: 
+
+\DefunWithValues row-major-aref {array index} {element}
+\Defsetf         row-major-aref {array index} {new-element}
+
+\label Arguments and Values::
+
+\param{array}---an \term{array}.
+
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\param{index}---a \term{valid array row-major index} for the \param{array}.
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+
+\param{element}, \param{new-element}---an \term{object}.
+
+\label Description::
+
+Considers \term{array} as a \term{vector} by viewing its \term{elements}
+in row-major order, and returns the \term{element} of that \term{vector} 
+which is referred to by the given \param{index}.
+
+\funref{row-major-aref} is valid for use with \macref{setf}.
+
+\label Examples:\None.
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{aref},
+\funref{array-row-major-index}
+
+\label Notes::
+
+\code
+ (row-major-aref array index) \EQ
+   (aref (make-array (array-total-size array)
+                     :displaced-to array
+                     :element-type (array-element-type array))
+         index)
+
+ (aref array i1 i2 ...) \EQ
+     (row-major-aref array (array-row-major-index array i1 i2))
+\endcode
+
+\endissue{AREF-1D}
+
+\endcom
+
+
+%%% ========== UPGRADED-ARRAY-ELEMENT-TYPE
+\begincom{upgraded-array-element-type}\ftype{Function}
+
+\issue{SUBTYPEP-ENVIRONMENT:ADD-ARG}
+\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+\label Syntax::
+
+\DefunWithValues upgraded-array-element-type {typespec {\opt} environment}
+		 {upgraded-typespec}
+
+\label Arguments and Values::
+
+\param{typespec}---a \term{type specifier}.
+
+\param{environment}---an \term{environment} \term{object}.
+  \Default{\nil, denoting the \term{null lexical environment}
+	   and the current \term{global environment}}
+%!!! Need to say what happens with the environment.
+
+\param{upgraded-typespec}---a \term{type specifier}.
+
+\label Description::
+
+Returns the \term{element type} of 
+the most \term{specialized} \term{array} representation capable of 
+holding items of the \term{type} denoted by \param{typespec}.
+
+%Added by KMP in response to a Barmar comment. -kmp 29-Jul-91
+The \param{typespec} is a \term{subtype} of 
+(and possibly \term{type equivalent} to)
+the \param{upgraded-typespec}.
+
+If \param{typespec} is \typeref{bit},
+ the result is \term{type equivalent} to \f{bit}.
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+If \param{typespec} is \typeref{base-char},
+ the result is \term{type equivalent} to \f{base-char}.
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+If \param{typespec} is \typeref{character},
+ the result is \term{type equivalent} to \f{character}.
+
+The purpose of \funref{upgraded-array-element-type} is to reveal how
+an implementation does its \term{upgrading}.
+
+The \param{environment} is used to expand any \term{derived type specifiers}
+that are mentioned in the \param{typespec}.
+
+\label Examples:\None.
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{array-element-type},
+\funref{make-array}
+
+\label Notes::
+
+Except for storage allocation consequences and dealing correctly with the
+optional \param{environment} \term{argument},
+\funref{upgraded-array-element-type} could be defined as:
+
+\code
+ (defun upgraded-array-element-type (type &optional environment)
+   (array-element-type (make-array 0 :element-type type)))
+\endcode
+                                                     
+\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
+\endissue{SUBTYPEP-ENVIRONMENT:ADD-ARG}
+
+\endcom
+
+%%% ========== ARRAY-DIMENSION-LIMIT
+\begincom{array-dimension-limit}\ftype{Constant Variable}
+
+\label Constant Value::
+
+A positive
+\issue{FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION}
+\term{fixnum},
+\endissue{FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION}
+the exact magnitude of which is \term{implementation-dependent},
+but which is not less than \f{1024}.
+
+\label Description::
+
+%% 17.1.0 18
+The upper exclusive bound on each individual \term{dimension} of an \term{array}.
+
+\label Examples:\None.
+
+\label See Also::
+
+\funref{make-array}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ARRAY-RANK-LIMIT
+\begincom{array-rank-limit}\ftype{Constant Variable}
+
+\label Constant Value::
+
+A positive
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\term{fixnum},
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+the exact magnitude of which is \term{implementation-dependent},
+but which is not less than \f{8}.
+
+\label Description::
+
+%% 17.1.0 17
+The upper exclusive bound on the \term{rank} of an \term{array}.
+
+\label Examples:\None.
+
+\label See Also::
+
+\funref{make-array}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ARRAY-TOTAL-SIZE-LIMIT
+\begincom{array-total-size-limit}\ftype{Constant Variable}
+
+\label Constant Value::
+
+A positive
+\issue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+\term{fixnum},
+\endissue{ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM}
+the exact magnitude of which is \term{implementation-dependent},
+but which is not less than \f{1024}.
+
+\label Description::
+
+%% 17.1.0 19
+The upper exclusive bound on the \term{array total size} of an \term{array}.
+
+%% 17.1.0 20
+The actual limit on the \term{array total size} 
+imposed by the \term{implementation}
+might vary according the \term{element type} of the \term{array};
+in this case, the value of \conref{array-total-size-limit} 
+will be the smallest of these possible limits.
+
+\label Examples:\None.
+
+\label See Also::
+
+\funref{make-array}, \funref{array-element-type}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Vectors --------------------
+
+%%% ========== SIMPLE-VECTOR-P
+\begincom{simple-vector-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues simple-vector-p {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 21
+\TypePredicate{object}{simple-vector}.
+
+\label Examples::        
+
+\code
+ (simple-vector-p (make-array 6)) \EV \term{true}
+ (simple-vector-p "aaaaaa") \EV \term{false}
+ (simple-vector-p (make-array 6 :fill-pointer t)) \EV \term{false}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also:: 
+
+\typeref{simple-vector}
+
+\label Notes::
+
+\code
+ (simple-vector-p \param{object}) \EQ (typep \param{object} 'simple-vector)
+\endcode
+
+\endcom
+
+%%% ========== SVREF
+\begincom{svref}\ftype{Accessor}
+
+\label Syntax::
+
+\DefunWithValues svref {simple-vector index} {element}
+\Defsetf         svref {simple-vector index} {new-element}
+                                                            
+\label Arguments and Values::
+
+\param{simple-vector}---a \term{simple vector}.
+
+\param{index}---a \term{valid array index} for the \param{simple-vector}.
+
+\param{element}, \param{new-element}---an \term{object}
+  (whose \term{type} is a \term{subtype} 
+   of the \term{array element type} of the \param{simple-vector}).
+
+\label Description::
+
+%% 17.2.0 7
+\term{Accesses} the \term{element} of \param{simple-vector} specified by \param{index}.
+
+%% Implied by use of "Access". -kmp 15-Jan-92
+% %% 17.2.0 7
+% \macref{setf} may be used with \funref{svref} to destructively replace
+% a \term{simple vector} element with a new value.
+
+\label Examples::
+
+\code
+ (simple-vector-p (setq v (vector 1 2 'sirens))) \EV \term{true}
+ (svref v 0) \EV 1
+ (svref v 2) \EV SIRENS
+ (setf (svref v 1) 'newcomer) \EV NEWCOMER               
+ v \EV #(1 NEWCOMER SIRENS)
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{aref},
+\funref{sbit},
+\funref{schar},
+\funref{vector},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification}
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+
+\label Notes::
+
+%% 17.2.0 8
+\funref{svref} is identical to \funref{aref} 
+except that it requires its first argument to be a \term{simple vector}.  
+
+\code
+ (svref \param{v} \param{i}) \EQ (aref (the simple-vector \param{v}) \param{i})
+\endcode
+
+\endcom
+
+%%% ========== VECTOR
+\begincom{vector}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues vector {{\rest} objects} {vector}
+
+\label Arguments and Values:: 
+
+\param{object}---an \term{object}.
+
+\param{vector}---a \term{vector} of \term{type} \f{(vector t {\tt *})}.
+
+\label Description::
+
+%% 17.1.0 21
+Creates a \term{fresh} \term{simple general vector} whose size
+corresponds to the number of \param{objects}. 
+
+The \term{vector} is initialized to contain the \param{objects}.
+
+\label Examples::
+
+\code
+ (arrayp (setq v (vector 1 2 'sirens))) \EV \term{true}
+ (vectorp v) \EV \term{true}
+ (simple-vector-p v) \EV \term{true}         
+ (length v) \EV 3
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\funref{make-array}
+
+\label Notes::
+
+\funref{vector} is analogous to \funref{list}.
+
+\code
+ (vector a\ssso a\ssst ... a\sssn)
+  \EQ (make-array (list \i{n}) :element-type t
+                          :initial-contents 
+                            (list a\ssso a\ssst ... a\sssn))
+\endcode
+\endcom
+
+%%% ========== VECTOR-POP
+\begincom{vector-pop}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues vector-pop {vector} {element}
+
+\label Arguments and Values::
+
+\param{vector}---a \term{vector} with a \term{fill pointer}.
+
+\param{element}---an \term{object}.
+
+\label Description::
+
+%% 17.5.0 10
+Decreases the \term{fill pointer} of \param{vector} by one, 
+and retrieves the \term{element} of \param{vector} that is
+designated by the new \term{fill pointer}.
+
+\label Examples::
+
+\code
+ (vector-push (setq fable (list 'fable))
+              (setq fa (make-array 8
+                                   :fill-pointer 2
+                                   :initial-element 'sisyphus))) \EV 2 
+ (fill-pointer fa) \EV 3 
+ (eq (vector-pop fa) fable) \EV \term{true}
+ (vector-pop fa) \EV SISYPHUS 
+ (fill-pointer fa) \EV 1 
+\endcode
+
+\label Side Effects::
+
+The \term{fill pointer} is decreased by one.
+
+\label Affected By::
+
+The value of the \term{fill pointer}.
+
+\label Exceptional Situations::
+
+An error \oftype{type-error} is signaled if \param{vector} does not have a \term{fill pointer}.
+
+If the \term{fill pointer} is zero, \funref{vector-pop} signals an error \oftype{error}.
+
+\label See Also::
+
+\funref{vector-push}, \funref{vector-push-extend}, \funref{fill-pointer}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== VECTOR-PUSH
+%%% ========== VECTOR-PUSH-EXTEND
+\begincom{vector-push, vector-push-extend}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues vector-push {new-element vector} {new-index-p}
+
+\DefunWithValues vector-push-extend {new-element vector {\opt} extension} {new-index}
+
+\label Arguments and Values::
+
+\param{new-element}---an \term{object}.
+
+\param{vector}---a \term{vector} with a \term{fill pointer}.
+
+\param{extension}---a positive \term{integer}.
+ \Default{\term{implementation-dependent}}
+
+\param{new-index-p}---a \term{valid array index} for \param{vector}, or \nil.
+
+\param{new-index}---a \term{valid array index} for \param{vector}.
+
+\label Description::
+
+%% 17.5.0 8
+\funref{vector-push} and \funref{vector-push-extend} store 
+\param{new-element} in \param{vector}.
+\funref{vector-push} attempts to store
+\param{new-element} 
+in the element of \param{vector} designated by the \term{fill pointer},
+and to increase the \term{fill pointer} by one.  If the 
+\f{(>= (fill-pointer \param{vector}) (array-dimension \param{vector} 0))},
+neither \param{vector} nor its \term{fill pointer} are affected.
+Otherwise, the store and increment take
+place and \funref{vector-push} 
+returns the former value of the \term{fill pointer}
+which is one less than the one it leaves in \param{vector}.
+
+%% 17.5.0 9
+\funref{vector-push-extend} is just like \funref{vector-push} except
+that if the \term{fill pointer} gets too large, \param{vector} is extended using
+\funref{adjust-array} so that it can contain more elements.
+\param{Extension}
+is the minimum number of elements to be added to \param{vector} if it
+must be extended.
+
+\funref{vector-push} and 
+\funref{vector-push-extend} return the index of \param{new-element} in \param{vector}.
+If \f{(>= (fill-pointer \param{vector}) (array-dimension \param{vector} 0))},
+\funref{vector-push} returns \nil.
+
+\label Examples::
+
+\code
+ (vector-push (setq fable (list 'fable))
+              (setq fa (make-array 8 
+                                   :fill-pointer 2
+                                   :initial-element 'first-one))) \EV 2 
+ (fill-pointer fa) \EV 3 
+ (eq (aref fa 2) fable) \EV \term{true}
+ (vector-push-extend #\\X
+                    (setq aa 
+                          (make-array 5
+                                      :element-type 'character
+                                      :adjustable t
+                                      :fill-pointer 3))) \EV 3 
+ (fill-pointer aa) \EV 4 
+ (vector-push-extend #\\Y aa 4) \EV 4 
+ (array-total-size aa) \EV at least 5 
+ (vector-push-extend #\\Z aa 4) \EV 5 
+ (array-total-size aa) \EV 9 ;(or more)
+\endcode
+
+\label Affected By::
+The value of the \term{fill pointer}.
+
+How \param{vector} was created.
+
+\label Exceptional Situations::         
+
+An error \oftype{error} is signaled by \funref{vector-push-extend}
+if it tries to extend \param{vector} and \param{vector} is not \term{actually adjustable}.
+
+An error \oftype{error} is signaled if \param{vector} does not 
+have a \term{fill pointer}.
+
+\label See Also::
+
+\funref{adjustable-array-p}, \funref{fill-pointer}, \funref{vector-pop}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== VECTORP
+\begincom{vectorp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues vectorp {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 20
+\TypePredicate{object}{vector}
+
+\label Examples::
+
+\code
+ (vectorp "aaaaaa") \EV \term{true}
+ (vectorp (make-array 6 :fill-pointer t)) \EV \term{true}
+ (vectorp (make-array '(2 3 4))) \EV \term{false}
+ (vectorp #*11) \EV \term{true}
+ (vectorp #b11) \EV \term{false}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also:\None.
+
+\label Notes::
+\code
+ (vectorp \param{object}) \EQ (typep \param{object} 'vector)
+\endcode
+
+\endcom
+
+%-------------------- Bit Vectors --------------------
+
+%%% ========== BIT
+%%% ========== SBIT
+\begincom{bit, sbit}\ftype{Accessor}
+
+\label Syntax::
+
+\DefunMultiWithValues {bit-array {\rest} subscripts} {bit}
+   {\entry{bit}
+    \entry{sbit}}
+\DefsetfMulti         {bit-array {\rest} subscripts} {new-bit}
+   {\entry{bit}
+    \entry{sbit}}
+
+\label Arguments and Values::
+
+\param{bit-array}---for \funref{bit},  a \term{bit array};
+		    for \funref{sbit}, a \term{simple bit array}.
+
+\param{subscripts}---a \term{list} of \term{valid array indices} 
+		     for the \param{bit-array}.
+
+\param{bit}---a \term{bit}.
+
+\label Description::
+
+%% 17.4.0 3
+%% 17.4.0 4
+\funref{bit} and \funref{sbit} \term{access} the \param{bit-array} 
+\term{element} specified by \param{subscripts}.
+
+%!!! Is this necessary to say? How is it said elsewhere?
+These \term{functions} ignore the \term{fill pointer} when \term{accessing} \term{elements}.
+
+%% This is implied by "access" above.
+% %% 17.4.0 6
+% \macref{setf} can be used with \funref{bit} or \funref{sbit} to destructively 
+% replace a \term{bit array} \term{element} with a new value.
+
+\label Examples::
+
+\code
+ (bit (setq ba (make-array 8 
+                            :element-type 'bit 
+                            :initial-element 1))
+       3) \EV 1
+ (setf (bit ba 3) 0) \EV 0
+ (bit ba 3) \EV 0
+ (sbit ba 5) \EV 1
+ (setf (sbit ba 5) 1) \EV 1
+ (sbit ba 5) \EV 1
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{aref},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification}
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+
+\label Notes::
+
+%% 17.4.0 7
+\funref{bit} and \funref{sbit} are like \funref{aref}
+except that they require \param{arrays} to be
+a \term{bit array} and a \term{simple bit array}, respectively.
+
+%% 17.4.0 5
+\funref{bit} and \funref{sbit}, unlike \funref{char} and \funref{schar},
+allow the first argument to be an \term{array} of any \term{rank}.
+
+\endcom
+
+%%% ========== BIT-AND
+%%% ========== BIT-ANDC1
+%%% ========== BIT-ANDC2
+%%% ========== BIT-EQV
+%%% ========== BIT-IOR
+%%% ========== BIT-NAND
+%%% ========== BIT-NOR
+%%% ========== BIT-NOT
+%%% ========== BIT-ORC1
+%%% ========== BIT-ORC2
+%%% ========== BIT-XOR
+\begincom{bit-and, bit-andc1, bit-andc2, bit-eqv,
+	  bit-ior, bit-nand, bit-nor, bit-not, bit-orc1, bit-orc2, bit-xor}\ftype{Function}
+
+\label Syntax::
+
+\DefunMultiWithValues {bit-array1 bit-array2 {\opt} opt-arg} {resulting-bit-array}
+  {\entry{bit-and}
+   \entry{bit-andc1}
+   \entry{bit-andc2}
+   \entry{bit-eqv}
+   \entry{bit-ior}
+   \entry{bit-nand}
+   \entry{bit-nor}
+   \entry{bit-orc1}
+   \entry{bit-orc2}
+   \entry{bit-xor}}
+
+\DefunWithValues bit-not {bit-array {\opt} opt-arg} {resulting-bit-array}
+
+\label Arguments and Values::
+
+\param{bit-array}, \param{bit-array1}, \param{bit-array2}---a \term{bit array}.
+
+\param{Opt-arg}---a \term{bit array}, or \t, or \nil.
+ \Default{\nil}
+
+%!!! This needs work. -kmp 24-May-91
+\param{Bit-array}, \param{bit-array1}, \param{bit-array2}, and \param{opt-arg}
+(if an \term{array}) must all be of the same \term{rank} and \term{dimensions}.  
+
+\param{resulting-bit-array}---a \term{bit array}.
+                 
+\label Description::
+
+%% 17.4.0 8
+These functions perform 
+bit-wise logical operations on \param{bit-array1} and \param{bit-array2}
+and return an \term{array} 
+of matching \term{rank} and \term{dimensions},
+such that any given bit of the result
+is produced by operating on corresponding bits from each of the arguments.
+
+%% 17.4.0 11
+In the case of \funref{bit-not}, an \term{array}
+of \term{rank} and \term{dimensions} matching \param{bit-array}
+is returned that contains a copy of \param{bit-array} 
+with all the bits inverted.
+
+%% 17.4.0 9
+%% 17.4.0 12
+If \param{opt-arg} is of type \f{(array bit)} the contents of the 
+result are destructively placed into \param{opt-arg}.
+If \param{opt-arg} is the symbol \t,
+\param{bit-array} or \param{bit-array1} is replaced with the result; 
+if \param{opt-arg} is \nil\ or omitted, a new \term{array} is created
+to contain the result.  
+
+%% 17.4.0 10
+\Thenextfigure\ indicates the logical operation
+performed by each of the \term{functions}.
+
+\boxfig 
+{\dimen0=2pc
+\tabskip 2\dimen0
+\halign to \hsize {#\hfil\tabskip \dimen0&#\hfil\tabskip 0pt plus 1fil\cr
+\noalign{\vskip -9pt}
+{\bf Function}&{\bf Operation}\cr
+\noalign{\vskip 2pt\hrule\vskip 2pt}
+\cr
+\funref{bit-and}&and\cr
+\funref{bit-eqv}&equivalence (exclusive nor)\cr
+\funref{bit-not}&complement\cr
+\funref{bit-ior}&inclusive or\cr
+\funref{bit-xor}&exclusive or\cr
+\funref{bit-nand}&complement of \param{bit-array1} and \param{bit-array2}\cr
+\funref{bit-nor}&complement of \param{bit-array1} or \param{bit-array2}\cr
+\funref{bit-andc1}&and complement of \param{bit-array1} with \param{bit-array2}\cr
+\funref{bit-andc2}&and \param{bit-array1} with complement of \param{bit-array2}\cr
+\funref{bit-orc1}&or complement of \param{bit-array1} with \param{bit-array2}\cr
+\funref{bit-orc2}&or \param{bit-array1} with complement of \param{bit-array2}\cr
+\noalign{\vskip -9pt}
+\caption{Bit-wise Logical Operations on Bit Arrays}\cr
+}}
+\endfig
+
+\label Examples::
+\code
+ (bit-and (setq ba #*11101010) #*01101011) \EV #*01101010
+ (bit-and #*1100 #*1010) \EV #*1000      
+ (bit-andc1 #*1100 #*1010) \EV #*0010
+ (setq rba (bit-andc2 ba #*00110011 t)) \EV #*11001000
+ (eq rba ba) \EV \term{true}
+ (bit-not (setq ba #*11101010)) \EV #*00010101
+ (setq rba (bit-not ba 
+                     (setq tba (make-array 8 
+                                           :element-type 'bit))))
+\EV #*00010101
+ (equal rba tba) \EV \term{true}
+ (bit-xor #*1100 #*1010) \EV #*0110
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{lognot}, \funref{logand}
+                
+\label Notes:\None.
+
+\endcom
+
+%%% ========== BIT-VECTOR-P
+\begincom{bit-vector-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues bit-vector-p {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 19
+\TypePredicate{object}{bit-vector}
+
+\label Examples::
+
+\code
+ (bit-vector-p (make-array 6 
+                           :element-type 'bit 
+                           :fill-pointer t)) \EV \term{true}
+ (bit-vector-p #*) \EV \term{true}
+ (bit-vector-p (make-array 6)) \EV \term{false}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also::                  
+
+\funref{typep}
+
+\label Notes::
+
+\code
+ (bit-vector-p \param{object}) \EQ (typep \param{object} 'bit-vector)
+\endcode
+
+\endcom
+
+%%% ========== SIMPLE-BIT-VECTOR-P
+\begincom{simple-bit-vector-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues simple-bit-vector-p {object} {generalized-boolean}
+
+\label Arguments and Values::             
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 23
+\TypePredicate{object}{simple-bit-vector}
+
+\label Examples::           
+\code
+ (simple-bit-vector-p (make-array 6)) \EV \term{false}
+ (simple-bit-vector-p #*) \EV \term{true}
+\endcode
+
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also:: 
+
+\funref{simple-vector-p}
+
+\label Notes::
+\code
+ (simple-bit-vector-p \param{object}) \EQ (typep \param{object} 'simple-bit-vector)
+\endcode
+
+\endcom
+

dict-characters.tex

@@ -0,0 +1,1314 @@
+% -*- Mode: TeX -*-
+
+% Character Comparison
+% Character Types
+% Character Roles
+% Character Casification
+% Character Codes
+% Character Names
+
+%-------------------- Character Types --------------------
+
+%%% ========== CHARACTER (System Class)
+\begincom{character}\ftype{System Class}
+
+\label Class Precedence List::
+\typeref{character},
+\typeref{t}
+
+\label Description::
+
+A \term{character} is an \term{object} that 
+represents a unitary token in an aggregate quantity of text;
+\seesection\CharacterConcepts.
+
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+\issue{CHARACTER-PROPOSAL:2-3-1}
+\Thetypes{base-char} and \typeref{extended-char}
+form an \term{exhaustive partition} of \thetype{character}.
+\endissue{CHARACTER-PROPOSAL:2-3-1}
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+
+\label See Also::
+
+{\secref\CharacterConcepts},
+{\secref\SharpsignBackslash},
+{\secref\PrintingCharacters}
+
+\endcom%{character}\ftype{System Class}
+\begincom{base-char}\ftype{Type}
+
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+
+\label Supertypes::
+
+\typeref{base-char},
+\typeref{character},
+\typeref{t}
+
+\label Description::
+
+\Thetype{base-char} is defined as the \term{upgraded array element type} 
+of \typeref{standard-char}.
+An \term{implementation} can support additional \subtypesof{character}
+(besides the ones listed in this standard) 
+that might or might not be \supertypesof{base-char}.
+In addition, an \term{implementation} can define \typeref{base-char}
+to be the \term{same} \term{type} as \typeref{character}.
+ 
+\term{Base characters} are distinguished in the following respects:
+\beginlist
+\itemitem{1.} \Thetype{standard-char} is a \term{subrepertoire} of \thetype{base-char}.
+\itemitem{2.} The selection of \term{base characters} that are not \term{standard characters}
+	      is implementation defined.
+\itemitem{3.} Only \term{objects} of \thetype{base-char} can be 
+	     \term{elements} of a \term{base string}.
+\itemitem{4.}
+No upper bound is specified for the number of characters in the 
+\typeref{base-char} \term{repertoire}; the size of that \term{repertoire}
+is %\term{implementation-dependent}
+\term{implementation-defined}.
+The lower bound is~96, the number of \term{standard characters}.
+%defined for \clisp. 
+\endlist
+ 
+%The distinction of base characters is largely a pragmatic
+%choice.  It permits efficient handling of common situations, may
+%be privileged for host system I/O, and can serve as an
+%intermediate basis for portability, less general than the standard
+%characters, but possibly more useful across a narrower range of
+%implementations.
+% 
+%Many computers have some "base" character representation which
+%is a function of hardware instructions for dealing with characters,
+%as well as the organization of the file system.  The base character
+%representation is likely to be the smallest transaction unit permitted
+%for text file and terminal I/O operations.  On a system with a record
+%based I/O paradigm, the base character representation is likely to
+%be the smallest record quantum.  On many computer systems,
+%this representation is a byte.
+ 
+Whether a character is a \term{base character} depends on the way 
+that an \term{implementation} represents \term{strings}, 
+and not any other properties of the \term{implementation} or the host operating system.  
+For example, one implementation might encode all \term{strings} 
+as characters having 16-bit encodings, and another might have
+two kinds of \term{strings}: those with characters having 8-bit 
+encodings and those with characters having 16-bit encodings.  In the
+first \term{implementation}, \thetype{base-char} is equivalent to
+\thetype{character}: there is only one kind of \term{string}.
+In the second \term{implementation}, the \term{base characters} might be 
+those \term{characters} that could be stored in a \term{string} of \term{characters}
+having 8-bit encodings.  In such an implementation,
+\thetype{base-char} is a \term{proper subtype} of \thetype{character}.
+%KMP: Note that I think there could be implementations in which the 8-bit strings
+%are -not- base characters, if all the standard-chars were not 
+%representable using the 8-bit encoding scheme.  In such a case,
+%it might be that (upgraded-array-element-type 'standard-char) returned
+%the 16-bit representation.  It might be that the 8-bit representation
+%was something else entirely.
+ 
+%% 2.15.0 15              
+\Thetype{standard-char} is a 
+\issue{CHARACTER-PROPOSAL:2-3-1}
+\subtypeof{base-char}.
+%This text will be deleted:
+%subtype of \typeref{character}.
+\endissue{CHARACTER-PROPOSAL:2-3-1}
+%\thetype{string-char} is a \subtypeof{character}.
+
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+
+\endcom%{base-char}\ftype{Type}
+\begincom{standard-char}\ftype{Type}
+
+\issue{STANDARD-REPERTOIRE-GRATUITOUS:RENAME}
+
+\label Supertypes::
+
+\typeref{standard-char},
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+\typeref{base-char},
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+\typeref{character},
+\typeref{t}
+
+\label Description::
+
+A fixed set of 96 \term{characters} required to be present in all 
+\term{conforming implementations}.  \term{Standard characters} are 
+defined in \secref\StandardChars.
+
+%%% 13.2.0 4
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+Any \term{character} that is not \term{simple} is not a \term{standard character}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\endissue{STANDARD-REPERTOIRE-GRATUITOUS:RENAME}
+
+\label See Also::
+
+{\secref\StandardChars}
+
+\endcom%{standard-char}\ftype{Type}
+\begincom{extended-char}\ftype{Type}
+
+\issue{CHARACTER-PROPOSAL:2-3-1}
+\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+
+\label Supertypes::
+
+\typeref{extended-char},
+\typeref{character},
+\typeref{t}
+
+\label Description::
+
+\Thetype{extended-char} is equivalent to the \term{type} \f{(and character (not base-char))}.
+
+%% 2.3.0 1
+%% 2.3.0 2
+
+\label Notes::
+
+%This next paragraph as added per Barrett's suggestion:
+\Thetype{extended-char} might 
+%be equivalent to \thetype{nil}
+%% Replaced as controversial. -kmp 4-Feb-92
+have no \term{elements}\meaning{4}
+in \term{implementations} in which all \term{characters} are \oftype{base-char}.
+
+\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
+\endissue{CHARACTER-PROPOSAL:2-3-1}
+
+\endcom%{extended-char}\ftype{Type}
+
+
+%-------------------- Character Comparison --------------------
+
+%%% ========== CHAR-EQUAL
+%%% ========== CHAR-NOT-EQUAL
+%%% ========== CHAR-LESSP
+%%% ========== CHAR-GREATERP
+%%% ========== CHAR-NOT-LESSP
+%%% ========== CHAR-NOT-GREATERP
+%%% ========== CHAR=
+%%% ========== CHAR/=
+%%% ========== CHAR<
+%%% ========== CHAR>
+%%% ========== CHAR>=
+%%% ========== CHAR<=
+\begincom{char=, char/=, char<, char>, char<=, char>=, 
+          char-equal, char-not-equal, char-lessp, char-greaterp, char-not-greaterp,
+          char-not-lessp}\ftype{Function}
+
+\label Syntax::
+
+\DefunMultiWithValues {{\rest} \plus{characters}}
+		      {generalized-boolean}
+{\entry{{char$=$}}
+ \entry{{char$/=$}}
+ \entry{{char$<$}}
+ \entry{{char$>$}}
+ \entry{{char$<=$}}
+ \entry{{char$>=$}}
+ \noalign{\vskip 5pt}
+ \entry{char-equal}
+ \entry{char-not-equal}
+ \entry{char-lessp}
+ \entry{char-greaterp}
+ \entry{char-not-greaterp}
+ \entry{char-not-lessp}}
+
+\label Arguments and Values::
+
+\param{character}---a \term{character}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+                         
+\label Description::
+
+These predicates compare \term{characters}.
+
+\funref{char=} returns \term{true} if all \param{characters} are the \term{same};
+otherwise, it returns \term{false}.
+\issue{CHARACTER-PROPOSAL:2-1-1}
+If two \param{characters} differ 
+in any \term{implementation-defined} \term{attributes},
+then they are not \funref{char=}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\funref{char/=} returns \term{true} if all \param{characters} are different;
+otherwise, it returns \term{false}.
+
+\funref{char<} returns \term{true} if the \param{characters} are monotonically increasing; 
+otherwise, it returns \term{false}.
+\issue{CHARACTER-PROPOSAL:2-1-1}
+If two \term{characters} 
+have \term{identical} \term{implementation-defined} \term{attributes}, 
+then their ordering by \funref{char<} is 
+consistent with the numerical ordering by the predicate \f{<} on their \term{codes}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\funref{char>} returns \term{true} if the \param{characters} are monotonically decreasing; 
+otherwise, it returns \term{false}.
+\issue{CHARACTER-PROPOSAL:2-1-1}
+If two \term{characters} have 
+\term{identical} \term{implementation-defined} \term{attributes},
+then their ordering by \funref{char>} is 
+consistent with the numerical ordering by the predicate \f{>} on their \term{codes}. 
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\funref{char<=} returns \term{true} 
+if the \param{characters} are monotonically nondecreasing; 
+otherwise, it returns \term{false}.
+\issue{CHARACTER-PROPOSAL:2-1-1}
+If two \term{characters} have
+\term{identical} \term{implementation-defined} \term{attributes},
+then their ordering by \funref{char<=} is
+consistent with the numerical ordering by the predicate \f{<=} on their \term{codes}. 
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+                               
+\funref{char>=} returns \term{true} 
+if the \param{characters} are monotonically nonincreasing; 
+otherwise, it returns \term{false}.
+\issue{CHARACTER-PROPOSAL:2-1-1}
+If two \term{characters} have
+\term{identical} \term{implementation-defined} \term{attributes},
+then their ordering by \funref{char>=} is 
+consistent with the numerical ordering by the predicate \f{>=} on their \term{codes}. 
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+    \funref{char-equal},
+    \funref{char-not-equal},
+    \funref{char-lessp},
+    \funref{char-greaterp},
+    \funref{char-not-greaterp},
+and \funref{char-not-lessp}
+are similar to 
+    \funref{char=},
+    \funref{char/=},
+    \funref{char<},
+    \funref{char>},
+    \funref{char<=},
+    \funref{char>=},
+respectively,
+except that they ignore differences in \term{case} and
+\issue{CHARACTER-PROPOSAL:2-1-1}
+% that the effect, if any, of each \term{implementation-defined} \term{attribute} 
+% must be specified as part of the definition of that \term{attribute}.
+%% Sandra thought the above was awkward. Trying again. -kmp 26-Jan-92
+might have an \term{implementation-defined} behavior 
+for \term{non-simple} \term{characters}.
+% For example, an implementation might define that certain 
+% \term{implementation-defined} \term{attributes} are ignored by
+% \funref{char-equal}, \i{etc.}
+%% More rewording to soothe awkwardness. -kmp 26-Jan-92
+For example, an \term{implementation} might define that 
+\funref{char-equal}, \i{etc.} ignore certain 
+\term{implementation-defined} \term{attributes}.
+The effect, if any, 
+of each \term{implementation-defined} \term{attribute}
+upon these functions must be specified as part of the definition of that \term{attribute}.
+%% This part has been moved to the notes.
+% %% 13.2.0 char-equal
+% This means that for the \term{standard characters}, the ordering used by
+% \funref{char-equal}, \etc. is such that
+% \f{A=a}, \f{B=b}, and so on, up to \f{Z=z}, and furthermore either
+% \f{9<A} or \f{Z<0}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+%% 13.2.0 31
+
+\label Examples::
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\code
+ (char= #\\d #\\d) \EV \term{true}
+ (char= #\\A #\\a) \EV \term{false}
+ (char= #\\d #\\x) \EV \term{false}
+ (char= #\\d #\\D) \EV \term{false}
+ (char/= #\\d #\\d) \EV \term{false}
+ (char/= #\\d #\\x) \EV \term{true}
+ (char/= #\\d #\\D) \EV \term{true}
+ (char= #\\d #\\d #\\d #\\d) \EV \term{true}
+ (char/= #\\d #\\d #\\d #\\d) \EV \term{false}
+ (char= #\\d #\\d #\\x #\\d) \EV \term{false}
+ (char/= #\\d #\\d #\\x #\\d) \EV \term{false}
+ (char= #\\d #\\y #\\x #\\c) \EV \term{false}
+ (char/= #\\d #\\y #\\x #\\c) \EV \term{true}
+ (char= #\\d #\\c #\\d) \EV \term{false}
+ (char/= #\\d #\\c #\\d) \EV \term{false}
+ (char< #\\d #\\x) \EV \term{true}
+ (char<= #\\d #\\x) \EV \term{true}
+ (char< #\\d #\\d) \EV \term{false}
+ (char<= #\\d #\\d) \EV \term{true}
+ (char< #\\a #\\e #\\y #\\z) \EV \term{true}
+ (char<= #\\a #\\e #\\y #\\z) \EV \term{true}
+ (char< #\\a #\\e #\\e #\\y) \EV \term{false}
+ (char<= #\\a #\\e #\\e #\\y) \EV \term{true}
+ (char> #\\e #\\d) \EV \term{true}
+ (char>= #\\e #\\d) \EV \term{true}
+ (char> #\\d #\\c #\\b #\\a) \EV \term{true}
+ (char>= #\\d #\\c #\\b #\\a) \EV \term{true}
+ (char> #\\d #\\d #\\c #\\a) \EV \term{false}
+ (char>= #\\d #\\d #\\c #\\a) \EV \term{true}
+ (char> #\\e #\\d #\\b #\\c #\\a) \EV \term{false}
+ (char>= #\\e #\\d #\\b #\\c #\\a) \EV \term{false}
+ (char> #\\z #\\A) \EV \term{implementation-dependent}
+ (char> #\\Z #\\a) \EV \term{implementation-dependent}
+ (char-equal #\\A #\\a) \EV \term{true}
+ (stable-sort (list #\\b #\\A #\\B #\\a #\\c #\\C) #'char-lessp)
+\EV (#\\A #\\a #\\b #\\B #\\c #\\C)
+ (stable-sort (list #\\b #\\A #\\B #\\a #\\c #\\C) #'char<)
+\EV (#\\A #\\B #\\C #\\a #\\b #\\c) ;Implementation A
+\EV (#\\a #\\b #\\c #\\A #\\B #\\C) ;Implementation B
+\EV (#\\a #\\A #\\b #\\B #\\c #\\C) ;Implementation C
+\EV (#\\A #\\a #\\B #\\b #\\C #\\c) ;Implementation D
+\EV (#\\A #\\B #\\a #\\b #\\C #\\c) ;Implementation E
+\endcode
+%GLS observes that there are 15 other possibilities here:
+% (#\\A #\\a #\\b #\\c #\\B #\\C)
+% (#\\A #\\B #\\a #\\b #\\c #\\C)
+% (#\\a #\\A #\\b #\\B #\\C #\\c)
+% (#\\a #\\A #\\B #\\b #\\C #\\c)
+% (#\\a #\\A #\\b #\\c #\\B #\\C)
+% (#\\a #\\A #\\B #\\b #\\c #\\C)
+% (#\\a #\\A #\\B #\\C #\\b #\\c)
+% (#\\A #\\a #\\B #\\b #\\c #\\C)
+% (#\\A #\\a #\\B #\\C #\\b #\\c)
+% (#\\A #\\B #\\a #\\C #\\b #\\c)
+% (#\\a #\\b #\\A #\\c #\\B #\\C)
+% (#\\a #\\b #\\A #\\B #\\c #\\C)
+% (#\\a #\\b #\\A #\\B #\\C #\\c)
+% (#\\A #\\a #\\b #\\B #\\c #\\C)
+% (#\\A #\\a #\\b #\\B #\\C #\\c)
+%But I think readers will get the idea from those I've specified. -kmp 27-May-91
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldcheckplus{character}
+
+\label See Also::
+
+{\secref\CharacterSyntax},
+{\secref\ImplementationDefinedScripts}
+
+\label Notes::
+
+If characters differ in their \term{code} \term{attribute} 
+or any \term{implementation-defined} \term{attribute},
+they are considered to be different by \funref{char=}.
+
+%% 13.2.0 33
+There is no requirement that \f{(eq c1 c2)} be true merely because
+\f{(char= c1 c2)} is \term{true}.  While \funref{eq} can distinguish two 
+\term{characters}
+that \funref{char=} does not, it is distinguishing them not
+as \term{characters}, but in some sense on the basis of a lower level
+implementation characteristic.
+If \f{(eq c1 c2)} is \term{true},
+then \f{(char= c1 c2)} is also true.
+\funref{eql} and \funref{equal}
+compare \term{characters} in the same
+way that \funref{char=} does.
+
+The manner in which \term{case} is used by 
+     \funref{char-equal},
+     \funref{char-not-equal},
+     \funref{char-lessp},
+     \funref{char-greaterp},
+     \funref{char-not-greaterp},
+ and \funref{char-not-lessp}
+implies an ordering for \term{standard characters} such that
+\f{A=a}, \f{B=b}, and so on, up to \f{Z=z}, and furthermore either
+\f{9<A} or \f{Z<0}.
+
+\endcom
+
+%-------------------- Character Types --------------------
+
+%%% ========== CHARACTER (Function)
+\begincom{character}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues character {character} {denoted-character}
+
+\label Arguments and Values:: 
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+\param{character}---a \term{character designator}.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\param{denoted-character}---a \term{character}.
+
+\label Description::
+
+%% 13.4.0 3
+Returns the \term{character} denoted by the \param{character} \term{designator}.
+
+\label Examples::
+
+\code
+ (character #\\a) \EV #\\a
+ (character "a") \EV #\\a
+ (character 'a) \EV #\\A
+ (character '\\a) \EV #\\a
+ (character 65.) is an error.
+ (character 'apple) is an error.
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{object}{a \term{character designator}}
+
+\label See Also::
+
+\funref{coerce}
+
+\label Notes::
+
+\code
+ (character \param{object}) \EQ (coerce \param{object} 'character)
+\endcode
+
+\endcom
+
+%%% ========== CHARACTERP
+\begincom{characterp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues characterp {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 17
+\TypePredicate{object}{character}
+
+\label Examples::                  
+
+\code
+ (characterp #\\a) \EV \term{true}
+ (characterp 'a) \EV \term{false}
+ (characterp "a") \EV \term{false}
+ (characterp 65.) \EV \term{false}
+ (characterp #\\Newline) \EV \term{true}
+ ;; This next example presupposes an implementation 
+ ;; in which #\\Rubout is an implementation-defined character.
+ (characterp #\\Rubout) \EV \term{true}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\funref{character} (\term{type} and \term{function}), \funref{typep}
+
+\label Notes::
+
+\code
+ (characterp \param{object}) \EQ (typep \param{object} 'character)
+\endcode
+
+\endcom
+
+%-------------------- Character Roles --------------------
+
+%%% ========== ALPHA-CHAR-P
+\begincom{alpha-char-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues alpha-char-p {character} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{character}---a \term{character}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 13.2.0 9
+\Predicate{character}{an \term{alphabetic}\meaning{1} \term{character}}
+
+\label Examples::
+
+\def\alfa{$\alpha$}
+\code
+ (alpha-char-p #\\a) \EV \term{true}
+ (alpha-char-p #\\5) \EV \term{false}
+ (alpha-char-p #\\Newline) \EV \term{false}
+ ;; This next example presupposes an implementation
+ ;; in which #\\\alfa is a defined character.
+ (alpha-char-p #\\\alfa) \EV \term{implementation-dependent}
+\endcode
+
+\label Affected By::
+
+None.
+(In particular, the results of this predicate are independent 
+of any special syntax which might have been enabled in the \term{current readtable}.)
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also::
+
+\funref{alphanumericp},
+{\secref\ImplementationDefinedScripts}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ALPHANUMERICP
+\begincom{alphanumericp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues alphanumericp {character} {generalized-boolean}
+
+\label Arguments and Values:: 
+
+\param{character}---a \term{character}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 13.2.0 22
+\Predicate{character}{an \term{alphabetic}\meaning{1} \term{character} 
+		   or a  \term{numeric}    \term{character}}
+
+\label Examples::
+
+\code
+ (alphanumericp #\\Z) \EV \term{true}
+ (alphanumericp #\\9) \EV \term{true}
+ (alphanumericp #\\Newline) \EV \term{false}
+ (alphanumericp #\\#) \EV \term{false}
+\endcode
+
+\label Affected By::
+
+None.
+(In particular, the results of this predicate are independent 
+of any special syntax which might have been enabled in the \term{current readtable}.)
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also::
+
+\funref{alpha-char-p}, \funref{graphic-char-p}, \funref{digit-char-p}
+
+\label Notes::
+
+Alphanumeric characters are graphic
+as defined by \funref{graphic-char-p}.
+The alphanumeric characters are a subset of the graphic characters.
+%The bits \term{attribute} of any alphanumeric character is 0.
+%% 13.2.0 24
+The standard characters \f{A} through \f{Z},
+		        \f{a} through \f{z},
+		    and \f{0} through \f{9} are alphanumeric characters.
+
+\code
+ (alphanumericp x)
+   \EQ (or (alpha-char-p x) (not (null (digit-char-p x))))
+\endcode
+\endcom
+
+%%% ========== DIGIT-CHAR
+\begincom{digit-char}\ftype{Function}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+
+%% 13.4.0 7
+\label Syntax::
+
+\DefunWithValues digit-char {weight {\opt} radix} {char}
+
+\label Arguments and Values::
+
+\param{weight}---a non-negative \term{integer}.
+
+\param{radix}---a \term{radix}.
+ \Default{\f{10}}
+
+\param{char}---a \term{character} or \term{false}.
+
+\label Description::   
+
+%% 13.4.0 8
+%% 13.4.0 9
+%% 13.4.0 10
+
+% I reorganized this description in a major way because once bits 
+% were removed, it seemed to have a simpler description. -kmp 23-Apr-91
+
+If \param{weight} is less than \param{radix},
+\funref{digit-char} returns a \term{character} which has that \param{weight}
+when considered as a digit in the specified radix.
+If the resulting \term{character} is to be an \term{alphabetic}\meaning{1} \term{character},
+it will be an uppercase \term{character}.
+
+If \param{weight} is greater than or equal to \param{radix},
+\funref{digit-char} returns \term{false}.
+
+
+\label Examples::
+
+\code
+ (digit-char 0) \EV #\\0
+ (digit-char 10 11) \EV #\\A
+ (digit-char 10 10) \EV \term{false}
+ (digit-char 7) \EV #\\7
+ (digit-char 12) \EV \term{false}
+ (digit-char 12 16) \EV #\\C  ;not #\\c
+ (digit-char 6 2) \EV \term{false}
+ (digit-char 1 2) \EV #\\1
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{digit-char-p},
+\funref{graphic-char-p},
+{\secref\CharacterSyntax}
+
+\label Notes::
+
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\endcom
+
+%%% ========== DIGIT-CHAR-P
+\begincom{digit-char-p}\ftype{Function}
+
+%% 13.2.0 18
+\label Syntax::
+
+\DefunWithValues digit-char-p {char {\opt} radix} {weight}
+
+\label Arguments and Values::
+
+\param{char}---a \term{character}.
+
+\param{radix}---a \term{radix}.
+ \Default{\f{10}}
+
+\param{weight}---either a non-negative \term{integer} less than \param{radix}, 
+		 or \term{false}.
+
+\label Description::
+
+Tests whether \param{char} is a digit in the specified \param{radix}
+%% 13.2.0 20
+(\ie with a weight less than \param{radix}).
+If it is a digit in that \param{radix},
+its weight is returned as an \term{integer}; 
+otherwise \nil\ is returned.
+                          
+\label Examples::
+
+\code
+ (digit-char-p #\\5)    \EV 5
+ (digit-char-p #\\5 2)  \EV \term{false}
+ (digit-char-p #\\A)    \EV \term{false}
+ (digit-char-p #\\a)    \EV \term{false}
+ (digit-char-p #\\A 11) \EV 10
+ (digit-char-p #\\a 11) \EV 10
+ (mapcar #'(lambda (radix) 
+             (map 'list #'(lambda (x) (digit-char-p x radix)) 
+                  "059AaFGZ"))
+         '(2 8 10 16 36))
+ \EV ((0 NIL NIL NIL NIL NIL NIL NIL)
+     (0 5 NIL NIL NIL NIL NIL NIL)
+     (0 5 9 NIL NIL NIL NIL NIL)
+     (0 5 9 10 10 15 NIL NIL)
+     (0 5 9 10 10 15 16 35))
+\endcode
+%In the above, recall that \EV's arrow takes up about two column positions,
+%rather than three characters "\EV" -- so the grinding looks funny here in
+%the source, but better on paper.
+
+\label Affected By::
+
+None.
+(In particular, the results of this predicate are independent 
+of any special syntax which might have been enabled in the \term{current readtable}.)
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{alphanumericp}
+
+\label Notes::
+
+%% 13.2.0 19                   
+Digits are \term{graphic} \term{characters}.
+
+\endcom
+
+%%% ========== GRAPHIC-CHAR-P
+\begincom{graphic-char-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues graphic-char-p {char} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{char}---a \term{character}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 13.2.0 5
+\Predicate{character}{a \term{graphic} \term{character}}
+
+\label Examples::                   
+
+\code
+ (graphic-char-p #\\G) \EV \term{true}
+ (graphic-char-p #\\#) \EV \term{true}
+ (graphic-char-p #\\Space) \EV \term{true}
+ (graphic-char-p #\\Newline) \EV \term{false}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also::
+
+\funref{read},
+{\secref\CharacterSyntax},
+{\secref\ImplementationDefinedScripts}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== STANDARD-CHAR-P
+\begincom{standard-char-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues standard-char-p {character} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{character}---a \term{character}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 13.2.0 3
+\TypePredicate{character}{standard-char}
+
+\label Examples::                
+
+\code
+ (standard-char-p #\\Space) \EV \term{true}
+ (standard-char-p #\\~) \EV \term{true}
+ ;; This next example presupposes an implementation
+ ;; in which #\\Bell is a defined character.
+ (standard-char-p #\\Bell) \EV \term{false}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Character Casification --------------------
+
+%%% ========== CHAR-DOWNCASE
+%%% ========== CHAR-UPCASE
+\begincom{char-upcase, char-downcase}\ftype{Function}
+
+\label Syntax::
+
+\DefunMultiWithValues {character} {corresponding-character} 
+   {\entry{char-upcase}
+    \entry{char-downcase}}
+
+\label Arguments and Values:: 
+
+\param{character}, \param{corresponding-character}---a \term{character}.
+
+\label Description::
+
+%% 13.4.0 5
+
+If \param{character} is a \term{lowercase} \term{character},
+\funref{char-upcase} returns the corresponding \term{uppercase} \term{character}.
+Otherwise, \funref{char-upcase} just returns the given \param{character}.
+
+If \param{character} is an \term{uppercase} \term{character},
+\funref{char-downcase} returns the corresponding \term{lowercase} \term{character}.
+Otherwise, \funref{char-downcase} just returns the given \param{character}.
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+The result only ever differs from \param{character} 
+in its \term{code} \term{attribute};
+all \term{implementation-defined} \term{attributes} are preserved.
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\label Examples::
+
+\code
+ (char-upcase #\\a) \EV #\\A
+ (char-upcase #\\A) \EV #\\A
+ (char-downcase #\\a) \EV #\\a
+ (char-downcase #\\A) \EV #\\a
+ (char-upcase #\\9) \EV #\\9
+ (char-downcase #\\9) \EV #\\9
+ (char-upcase #\\@) \EV #\\@
+ (char-downcase #\\@) \EV #\\@
+ ;; Note that this next example might run for a very long time in 
+ ;; some implementations if CHAR-CODE-LIMIT happens to be very large
+ ;; for that implementation.
+ (dotimes (code char-code-limit)
+   (let ((char (code-char code)))
+     (when char
+       (unless (cond ((upper-case-p char) (char= (char-upcase (char-downcase char)) char))
+                     ((lower-case-p char) (char= (char-downcase (char-upcase char)) char))
+                     (t (and (char= (char-upcase (char-downcase char)) char)
+                             (char= (char-downcase (char-upcase char)) char))))
+         (return char)))))
+\EV NIL
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also::
+
+\funref{upper-case-p},
+\funref{alpha-char-p},
+{\secref\CharactersWithCase},
+{\secref\ImplementationDefinedScripts}
+
+\label Notes::
+
+If the \param{corresponding-char} is \term{different} than \param{character},
+then both the \param{character} and the \param{corresponding-char} have \term{case}.
+
+Since \funref{char-equal} ignores the \term{case} of the \term{characters} it compares,
+the \param{corresponding-character} is always the \term{same} as \param{character}
+under \funref{char-equal}.
+
+\endcom
+
+%%% ========== LOWER-CASE-P
+%%% ========== BOTH-CASE-P
+%%% ========== UPPER-CASE-P
+\begincom{upper-case-p, lower-case-p, both-case-p}\ftype{Function}
+
+\label Syntax::
+
+\DefunMultiWithValues {character} {generalized-boolean}
+  {\entry{upper-case-p}
+   \entry{lower-case-p}
+   \entry{both-case-p}}
+
+\label Arguments and Values::
+
+\param{character}---a \term{character}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+These functions test the case of a given \param{character}.
+
+%% 13.2.0 13
+\NamedPredicate{upper-case-p}{character}{an \term{uppercase} \term{character}}
+
+%% 13.2.0 14
+\NamedPredicate{lower-case-p}{character}{a \term{lowercase} \term{character}}
+
+%% 13.2.0 15
+\NamedPredicate{both-case-p}{character}{a \term{character} with \term{case}}
+
+\label Examples::
+
+\code
+ (upper-case-p #\\A) \EV \term{true}
+ (upper-case-p #\\a) \EV \term{false}
+ (both-case-p #\\a) \EV \term{true}
+ (both-case-p #\\5) \EV \term{false}
+ (lower-case-p #\\5) \EV \term{false}
+ (upper-case-p #\\5) \EV \term{false}
+ ;; This next example presupposes an implementation 
+ ;; in which #\\Bell is an implementation-defined character.
+ (lower-case-p #\\Bell) \EV \term{false}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also::
+
+\funref{char-upcase},
+\funref{char-downcase},
+{\secref\CharactersWithCase},
+{\secref\ImplementationDefinedScripts}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Character Codes --------------------
+
+%%% ========== CHAR-CODE
+\begincom{char-code}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues char-code {character} {code}
+
+\label Arguments and Values:: 
+
+\param{character}---a \term{character}.
+
+\param{code}---a \term{character code}.
+
+\label Description::
+
+%% 13.3.0 3
+\funref{char-code} returns the \term{code} \term{attribute} of \param{character}.
+
+\label Examples::
+
+\code
+;; An implementation using ASCII character encoding 
+;; might return these values:
+(char-code #\\$) \EV 36
+(char-code #\\a) \EV 97
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also::
+                          
+\funref{char-code-limit}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== CHAR-INT
+\begincom{char-int}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues char-int {character} {integer}
+
+\label Arguments and Values:: 
+
+\param{character}---a \term{character}.
+
+\param{integer}---a non-negative \term{integer}.
+
+\label Description::
+
+%% 13.4.0 11
+\issue{CHARACTER-PROPOSAL:2-1-2}
+Returns a non-negative \term{integer} encoding the \param{character} object.
+The manner in which the \term{integer} is computed is \term{implementation-dependent}.
+In contrast to \funref{sxhash}, the result is not guaranteed to be independent 
+of the particular \term{Lisp image}.
+\endissue{CHARACTER-PROPOSAL:2-1-2}
+
+%% 13.4.0 12
+If \param{character} has no \term{implementation-defined} \term{attributes},
+the results of \funref{char-int} and \funref{char-code} are the same. 
+
+\code
+ (char= \i{c1} \i{c2}) \EQ (= (char-int \i{c1}) (char-int \i{c2}))
+\endcode
+for characters \i{c1} and \i{c2}.
+
+\label Examples::
+
+\code
+ (char-int #\\A) \EV 65       ; implementation A
+ (char-int #\\A) \EV 577      ; implementation B
+ (char-int #\\A) \EV 262145   ; implementation C
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{char-code}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== CODE-CHAR
+\begincom{code-char}\ftype{Function}
+
+\issue{CHARACTER-PROPOSAL:2-1-1}
+
+\label Syntax::
+
+\DefunWithValues code-char {code} {char-p}
+
+\label Arguments and Values::
+
+\param{code}---a \term{character code}.
+
+\param{char-p}---a \term{character} or \nil.
+
+\label Description::
+
+%% 13.3.0 6
+Returns a \term{character} with the \term{code} \term{attribute} given by \param{code}.
+If no such \term{character} exists and one cannot be created, \nil\ is returned.
+
+\label Examples::
+
+\code
+(code-char 65.) \EV #\\A  ;in an implementation using ASCII codes
+(code-char (char-code #\\Space)) \EV #\\Space  ;in any implementation
+\endcode
+
+%% 13.3.0 7
+% Removed per suggestion of Barmar -- used old-style bits/fonts.
+
+\label Affected By::
+
+The \term{implementation}'s character encoding.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{char-code}
+
+\label Notes::
+
+\endissue{CHARACTER-PROPOSAL:2-1-1}
+
+\endcom
+
+%%% ========== CHAR-CODE-LIMIT
+\begincom{char-code-limit}\ftype{Constant Variable}
+
+\label Constant Value::
+
+A non-negative \term{integer}, the exact magnitude of which
+is \term{implementation-dependent}, but which is not less
+than \f{96} (the number of \term{standard characters}).
+
+\label Description::
+
+%% 13.1.0 2
+The upper exclusive bound on the \term{value} returned by 
+the \term{function} \funref{char-code}.
+
+\label See Also::
+
+\funref{char-code}
+
+\label Notes::
+
+% Sandra wanted this added.
+\Thevalueof{char-code-limit} might be larger than the actual
+number of \term{characters} supported by the \term{implementation}.
+
+\endcom
+
+%-------------------- Character Names --------------------
+
+%%% ========== CHAR-NAME
+\begincom{char-name}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues char-name {character} {name}
+
+\label Arguments and Values::
+
+\param{character}---a \term{character}.
+
+\param{name}---a \term{string} or \nil.
+
+\label Description::
+
+Returns a \term{string} that is the \term{name} of the \param{character},
+or \nil\ if the \param{character} has no \term{name}.
+
+%% 13.4.0 20
+% \funref{char-name} will only locate ``simple'' character names;
+% it will not construct names on the basis of
+% the \param{character}'s \term{implementation-dependent} \term{attributes}.
+
+All \term{non-graphic} characters are required to have \term{names}
+unless they have some \term{implementation-defined} \term{attribute}
+which is not \term{null}.  Whether or not other \term{characters}
+have \term{names} is \term{implementation-dependent}.
+
+\issue{CHAR-NAME-CASE:X3J13-MAR-91}
+%% I added this next phrase to highlight why there are two lists here. -kmp 14-May-93
+The \term{standard characters}
+\NewlineChar\ and \SpaceChar\ have the respective names \f{"Newline"} and \f{"Space"}.
+%% Ditto. -kmp 14-May-93
+The \term{semi-standard} \term{characters}
+\TabChar, \PageChar, \RuboutChar, \LinefeedChar, \ReturnChar, and \BackspaceChar\ 
+%% Next parenthetical remark added for emphasis. -kmp 14-May-93
+(if they are supported by the \term{implementation})
+have the respective names
+\f{"Tab"},  \f{"Page"},  \f{"Rubout"},  \f{"Linefeed"},  \f{"Return"}, and \f{"Backspace"}
+(in the indicated case, even though name lookup by ``\f{\#\\}'' 
+and by \thefunction{name-char} is not case sensitive).
+\endissue{CHAR-NAME-CASE:X3J13-MAR-91}
+
+\label Examples::
+
+\code
+ (char-name #\\ ) \EV "Space"
+ (char-name #\\Space) \EV "Space"
+ (char-name #\\Page) \EV "Page"
+
+ (char-name #\\a)
+\EV NIL
+\OV "LOWERCASE-a"
+\OV "Small-A"
+\OV "LA01"
+
+ (char-name #\\A)
+\EV NIL
+\OV "UPPERCASE-A"
+\OV "Capital-A"
+\OV "LA02"
+
+ ;; Even though its CHAR-NAME can vary, #\\A prints as #\\A
+ (prin1-to-string (read-from-string (format nil "#\\\\~A" (or (char-name #\\A) "A"))))
+\EV "#\\\\A"
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{character}{a \term{character}}
+
+\label See Also::
+
+\funref{name-char},
+{\secref\PrintingCharacters}
+
+\label Notes::
+
+%% Added "non-graphic" to cover objection by Sandra:
+%%  Does this mean that if (char-name #\A) = "Capital-A"
+%%   (print #\A) prints
+%%   #\Capital-A
+%%  instead of #\A ???
+%%  Or does this apply only to non-standard characters.
+\term{Non-graphic} 
+\term{characters} having \term{names} are written by the \term{Lisp printer}
+as ``\f{\#\\}'' followed by the their \term{name}; \seesection\PrintingCharacters.
+
+\endcom
+
+%%% ========== NAME-CHAR
+\begincom{name-char}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues name-char {name} {char-p}
+
+\label Arguments and Values::
+
+%% 13.4.0 17
+%% 13.4.0 18
+\param{name}---a \term{string designator}.
+
+\param{char-p}---a \term{character} or \nil.
+
+\label Description::
+
+%% 13.4.0 21                          
+Returns the \term{character} \term{object} whose \term{name} is
+\param{name} (as determined by \funref{string-equal}---\ie lookup is not case sensitive).
+If such a \term{character} does not exist, \nil\ is returned.
+
+\label Examples::
+
+\code
+(name-char 'space) \EV #\\Space
+(name-char "space") \EV #\\Space
+(name-char "Space") \EV #\\Space
+(let ((x (char-name #\\a)))
+  (or (not x) (eql (name-char x) #\\a))) \EV \term{true}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{name}{a \term{string designator}}
+
+\label See Also::
+
+\funref{char-name}
+
+\label Notes:\None.
+
+\endcom

dict-conditions.tex

@@ -0,0 +1,4080 @@
+% -*- Mode: TeX -*-
+
+% Conditions
+%  Conditions
+%   Signaling
+%   Debugger
+%   Handling
+%   Condition Types
+%    Condition Type Definition
+%    Condition Instantiation
+%    Condition Types/Accessors
+%  Restarts
+%   PreDefined Restarts
+
+
+%%% ========== CONDITION
+\begincom{condition}\ftype{Condition Type}
+
+\issue{CONDITION-RESTARTS:BUGGY}
+\reviewer{Barrett: I think CONDITION-RESTARTS is not fully integrated.}
+\endissue{CONDITION-RESTARTS:BUGGY}
+
+%!!! Barrett notes of the condition types:
+%  There is little discussion in this descriptions of what the values 
+%  of the initargs ought to be.  For example, package-error permits name
+%  or package object.
+
+\label Class Precedence List::
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+All types of \term{conditions}, whether error or
+non-error, must inherit from this \term{type}.
+\issue{CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET}
+\issue{CLOS-CONDITIONS:INTEGRATE}
+%%As noted by Symbolics, these just repeat the obvious:
+%All types of \term{conditions} are \term{classes}.  
+%All \term{condition} \term{objects} are \term{generalized instances} of one
+%or more \term{classes}.
+%    Barmar thinks the next statement is unnecessary and incomplete.
+%    I think there's also a later cleanup issue which undoes it.  Work on this more. -kmp
+%    Barrett also asks what about SLOT-VALUE and its setf.
+%% Removed. This is explained better below.  -kmp 1-Oct-91
+% \term{Slots} in \term{condition} \term{objects} can be accessed
+% using \macref{with-slots}.
+\endissue{CLOS-CONDITIONS:INTEGRATE}
+\endissue{CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET}
+
+% %!!! Barrett points out that these look a little lonely all by themselves. -kmp 23-Oct-90
+% %    (Well, they used to be somewhere different, so maybe they are not so 
+% %    lonely now, but I'll leave the comment and think more about it later. -kmp 13-Nov-90)
+% %!!! Barrett thinks this "disjointness" is probably false  and in any case uninteresting.
+%% Finally commented out for Barrett. -kmp 2-Feb-92
+% The \term{types} \typeref{simple-condition}, \typeref{warning}, 
+% and \typeref{serious-condition} are \term{pairwise} \term{disjoint}.
+
+No additional \term{subtype} relationships among the specified \subtypesof{condition}
+are allowed, except when explicitly mentioned in the text; however
+implementations are permitted to introduce additional \term{types}
+and one of these \term{types} can be a \term{subtype} of any
+number of the \subtypesof{condition}.
+
+\issue{CONDITION-SLOTS:HIDDEN}
+Whether a user-defined \term{condition} \term{type} has \term{slots} 
+that are accessible by \term{with-slots} is \term{implementation-dependent}.
+Furthermore, even in an \term{implementation} 
+in which user-defined \term{condition} \term{types} would have \term{slots}, 
+it is \term{implementation-dependent} whether any \term{condition}
+\term{types} defined in this document have such \term{slots} or, 
+if they do, what their \term{names} might be;
+only the reader functions documented by this specification may be relied
+upon by portable code.
+\endissue{CONDITION-SLOTS:HIDDEN}
+
+\issue{CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET}
+\term{Conforming code} must observe the following restrictions related to
+\term{conditions}:
+
+\beginlist
+\itemitem{\bull}
+ \macref{define-condition}, not \macref{defclass}, must be used
+ to define new \term{condition} \term{types}.
+
+\itemitem{\bull}
+ \macref{make-condition}, not \funref{make-instance}, must be used to
+ create \term{condition} \term{objects} explicitly.
+
+\itemitem{\bull}
+ The \kwd{report} option of \macref{define-condition}, not \macref{defmethod}
+ for \funref{print-object}, must be used to define a condition reporter.
+
+\itemitem{\bull}
+ \funref{slot-value}, \funref{slot-boundp}, \funref{slot-makunbound},
+ and \macref{with-slots} must not be used on \term{condition} \term{objects}.
+ Instead, the appropriate accessor functions (defined by \macref{define-condition})
+ should be used.
+\endlist
+\endissue{CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET}
+
+\endcom%{condition}\ftype{Condition Type}
+
+\begincom{warning}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{warning},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{warning} consists of all types of warnings.
+
+\label See Also::
+
+\typeref{style-warning}
+
+\endcom%{warning}\ftype{Condition Type}
+
+\issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+\begincom{style-warning}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{style-warning},
+\typeref{warning},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{style-warning} includes those \term{conditions} 
+that represent \term{situations} involving \term{code} 
+that is \term{conforming code} but that is nevertheless 
+considered to be faulty or substandard.
+
+\label See Also::
+
+\funref{muffle-warning}
+
+\label Notes::
+
+An \term{implementation} might signal such a \term{condition}
+if it encounters \term{code}
+     that uses deprecated features 
+  or that appears unaesthetic or inefficient.
+
+An `unused variable' warning must be \oftype{style-warning}.
+
+In general, the question of whether \term{code} is faulty or substandard
+is a subjective decision to be made by the facility processing that \term{code}.
+The intent is that whenever such a facility wishes to complain about
+\term{code} on such subjective grounds, it should use this 
+\term{condition} \term{type} so that any clients who wish to redirect or
+muffle superfluous warnings can do so without risking that they will be
+redirecting or muffling other, more serious warnings.
+
+\endcom%{style-warning}\ftype{Condition Type}
+\endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+
+\begincom{serious-condition}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{serious-condition},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+All \term{conditions} serious enough to require interactive intervention 
+if not handled should inherit from \thetype{serious-condition}.
+This condition type is provided
+%for terminological convenience.
+primarily so that it may be included as
+a \term{superclass} of other \term{condition} \term{types};
+it is not intended to be signaled directly.
+
+\label Notes::
+
+% It is
+% conventional to use \funref{error} (or something built on
+% \funref{error}) to \term{signal} \term{conditions} that are \oftype{serious-condition},
+% and to use \funref{signal} to \term{signal} \term{conditions} 
+% that are not of this \term{type}.
+
+Signaling a \term{serious condition} does not itself force entry into
+the debugger.   However, except in the unusual situation where the
+programmer can assure that no harm will come from failing to
+\term{handle} a \term{serious condition}, such a \term{condition} is
+usually signaled with \funref{error} rather than \funref{signal} in
+order to assure that the program does not continue without
+\term{handling} the \term{condition}.  (And conversely, it is
+conventional to use \funref{signal} rather than \funref{error} to signal
+conditions which are not \term{serious conditions}, since normally the
+failure to handle a non-serious condition is not reason enough for the
+debugger to be entered.)
+
+\endcom%{serious-condition}\ftype{Condition Type}
+
+\begincom{error}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{error},
+\typeref{serious-condition},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{error} consists of all \term{conditions} that represent \term{errors}.
+
+\endcom%{error}\ftype{Condition Type}
+
+\begincom{cell-error}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{cell-error},
+\typeref{error},
+\typeref{serious-condition},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{cell-error} consists of error conditions that occur during 
+a location \term{access}.   The name of the offending cell is initialized by 
+\theinitkeyarg{name} to \funref{make-condition},
+and is \term{accessed} by \thefunction{cell-error-name}.
+
+\label See Also::
+
+\funref{cell-error-name}
+
+\endcom%{cell-error}\ftype{Condition Type}
+
+%%% ========== CELL-ERROR-NAME
+\begincom{cell-error-name}\ftype{Function}
+
+\issue{ACCESS-ERROR-NAME}
+
+\label Syntax::
+
+\DefunWithValues cell-error-name {condition} {name}
+
+\label Arguments and Values::
+
+\param{condition}---a \term{condition} \oftype{cell-error}.
+
+\param{name}---an \term{object}.
+
+\label Description::
+
+Returns the \term{name} of the offending cell involved in the \term{situation}
+represented by \param{condition}.
+
+The nature of the result depends on the specific \term{type} of \param{condition}.
+For example,
+    if the \param{condition} is \oftype{unbound-variable}, the result is
+     the \term{name} of the \term{unbound variable} which was being \term{accessed},
+    if the \param{condition} is \oftype{undefined-function}, this is
+     the \term{name} of the \term{undefined function} which was being \term{accessed},
+and if the \param{condition} is \oftype{unbound-slot}, this is
+     the \term{name} of the \term{slot} which was being \term{accessed}.
+
+\label Examples:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\typeref{cell-error},
+\typeref{unbound-slot},
+\typeref{unbound-variable},
+\typeref{undefined-function},
+{\secref\ConditionSystemConcepts}
+
+\label Notes:\None.
+
+%Barmar: This should be ``consequences are unspecified.''
+%Shouldn't be needed anyway--we don't provide an operator.
+%It is an error to use \macref{setf} with \funref{cell-error-name}.
+
+\endissue{ACCESS-ERROR-NAME}
+
+\endcom
+
+\begincom{parse-error}\ftype{Condition Type}
+
+\issue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+\issue{READER-ERROR:NEW-TYPE}
+
+\label Class Precedence List::
+
+\typeref{parse-error},
+\typeref{error},
+\typeref{serious-condition},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{parse-error} consists of 
+error conditions that are related to parsing.
+
+\label See Also::
+
+\funref{parse-namestring},
+\funref{reader-error}
+
+\endissue{READER-ERROR:NEW-TYPE}
+\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+\endissue{PARSE-ERROR-STREAM:SPLIT-TYPES}
+
+\endcom%{parse-error}\ftype{Condition Type}
+
+\begincom{storage-condition}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{storage-condition},
+\typeref{serious-condition},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{storage-condition} consists of serious conditions that 
+relate to problems with memory management that are potentially due to
+\term{implementation-dependent} limits rather than semantic errors
+in \term{conforming programs}, and that typically warrant entry to the 
+debugger if not handled.  Depending on the details of the \term{implementation}, 
+these might include such problems as 
+  stack overflow,
+  memory region overflow, 
+and
+  storage exhausted.
+
+\label Notes::
+
+While some \clisp\ operations might signal \term{storage-condition}
+because they are defined to create \term{objects},
+it is unspecified whether operations that are not defined to create
+\term{objects} create them anyway 
+and so might also signal \typeref{storage-condition}.
+Likewise, the evaluator itself might create \term{objects}
+and so might signal \typeref{storage-condition}.
+(The natural assumption might be that such 
+\term{object} creation is naturally inefficient, 
+but even that is \term{implementation-dependent}.)
+In general, the entire question of how storage allocation is done is
+\term{implementation-dependent}, 
+and so any operation might signal \typeref{storage-condition} at any time.
+Because such a \term{condition} is indicative of a limitation 
+   of the \term{implementation} 
+or of the \term{image}
+rather than an error in a \term{program},
+\term{objects} \oftype{storage-condition} are not \oftype{error}.
+
+\endcom%{storage-condition}\ftype{Condition Type}
+
+%-------------------- Signaling --------------------
+
+%%% ========== ASSERT
+\begincom{assert}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValuesNewline assert 
+		  	 {test-form \brac{\paren{\starparam{place}}
+                                          \brac{datum-form
+                                                \starparam{argument-form}}}}
+		         {\nil}
+
+\label Arguments and Values:: 
+
+\param{test-form}---a \term{form}; always evaluated.
+
+\param{place}---a \term{place}; evaluated if an error is signaled.
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\param{datum-form}---a \term{form} that evaluates to a \param{datum}.
+  Evaluated each time an error is to be signaled, 
+  or not at all if no error is to be signaled.
+
+\param{argument-form}---a \term{form} that evaluates to an \param{argument}.
+  Evaluated each time an error is to be signaled, 
+  or not at all if no error is to be signaled.
+
+\issue{ASSERT-ERROR-TYPE:ERROR}
+\param{datum}, \param{arguments}---\term{designators} for a \term{condition} 
+ of default type \typeref{error}.  (These \term{designators} are the
+ result of evaluating \param{datum-form} and each of the \param{argument-forms}.)
+\endissue{ASSERT-ERROR-TYPE:ERROR}
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+
+\label Description::
+
+\funref{assert} assures that \param{test-form} evaluates to \term{true}.
+If \param{test-form} evaluates to \term{false}, \macref{assert} signals a
+\term{correctable} \term{error} (denoted by \param{datum} and \param{arguments}).
+Continuing from this error using \therestart{continue} makes it possible
+for the user to alter the values of the \param{places} before
+\macref{assert} evaluates \param{test-form} again.
+If the value of \param{test-form} is \term{non-nil},
+\funref{assert} returns \nil.
+
+The \param{places} are \term{generalized references} to data
+upon which \param{test-form} depends, 
+whose values can be changed by the user in attempting to correct the error.
+\term{Subforms} of each \param{place} are only evaluated if an error is signaled, 
+and might be re-evaluated if the error is re-signaled (after continuing without
+actually fixing the problem).
+\issue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+The order of evaluation of the \param{places} is not specified;
+\seesection\GenRefSubFormEval.\idxtext{order of evaluation}\idxtext{evaluation order}
+\endissue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+\issue{SETF-MULTIPLE-STORE-VARIABLES:ALLOW}
+If a \param{place} \term{form} is supplied that produces more values than there
+are store variables, the extra values are ignored. If the supplied 
+\term{form} produces fewer values than there are store variables, 
+the missing values are set to \nil.
+\endissue{SETF-MULTIPLE-STORE-VARIABLES:ALLOW}
+                                                        
+\label Examples::
+\code
+ (setq x (make-array '(3 5) :initial-element 3))
+\EV #2A((3 3 3 3 3) (3 3 3 3 3) (3 3 3 3 3))
+ (setq y (make-array '(3 5) :initial-element 7))
+\EV #2A((7 7 7 7 7) (7 7 7 7 7) (7 7 7 7 7))
+ (defun matrix-multiply (a b)
+   (let ((*print-array* nil))
+     (assert (and (= (array-rank a) (array-rank b) 2)
+                  (= (array-dimension a 1) (array-dimension b 0)))
+             (a b)
+             "Cannot multiply ~S by ~S." a b)
+            (really-matrix-multiply a b))) \EV MATRIX-MULTIPLY
+ (matrix-multiply x y)
+\OUT Correctable error in MATRIX-MULTIPLY: 
+\OUT Cannot multiply #<ARRAY ...> by #<ARRAY ...>.
+\OUT Restart options:
+\OUT  1: You will be prompted for one or more new values.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\OUT Value for A: \IN{x}
+\OUT Value for B: \IN{(make-array '(5 3) :initial-element 6)}
+\EV #2A((54 54 54 54 54)
+       (54 54 54 54 54)
+       (54 54 54 54 54)
+       (54 54 54 54 54)
+       (54 54 54 54 54))
+\endcode
+
+\code
+ (defun double-safely (x) (assert (numberp x) (x)) (+ x x))
+ (double-safely 4) 
+\EV 8
+ 
+ (double-safely t)
+\OUT Correctable error in DOUBLE-SAFELY: The value of (NUMBERP X) must be non-NIL.
+\OUT Restart options:
+\OUT  1: You will be prompted for one or more new values.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\OUT Value for X: \IN{7}
+\EV 14
+\endcode
+
+\label Affected By::
+
+\varref{*break-on-signals*}
+% Barrett thinks that \varref{*debug-io*} and others don't belong here because
+% debugger might not be reached, and anyway it is a full turing machine and might
+% depend on virtually anything.
+
+The set of active \term{condition handlers}.
+
+\label Exceptional Situations:\None.
+
+%% Barrett says, and I agree, that this isn't an exceptional situation.
+%% Anyway, it's said above. -kmp 2-Sep-91
+% If the value of \param{test-form} is \nil,
+% \macref{assert} signals a user-specified \term{condition},
+% which defaults to \typeref{simple-error}.
+
+\label See Also::
+
+\funref{check-type}, \funref{error}, {\secref\GeneralizedReference}
+
+\label Notes::
+
+The debugger need not include the \param{test-form} in the error message,
+and the \param{places} should not be included in the message, but they
+should be made available for the user's perusal.  If the user gives the
+``continue'' command, the values of any of the references can be altered.
+The details of this depend on the implementation's style of user interface.
+\endcom
+
+%%% ========== ERROR
+\begincom{error}\ftype{Function}
+
+\label Syntax::
+
+\DefunNoReturn error {datum {\rest} arguments}
+
+\label Arguments and Values:: 
+
+\param{datum}, \param{arguments}---\term{designators} for a \term{condition} 
+ of default type \typeref{simple-error}.
+
+\label Description::
+
+\funref{error} effectively invokes \funref{signal} on the denoted \term{condition}.
+
+If the \term{condition} is not handled, \f{(invoke-debugger \i{condition})} is done.  
+As a consequence of calling \funref{invoke-debugger}, \funref{error} 
+cannot directly return; the only exit from \funref{error}
+can come by non-local transfer of control in a handler or by use of
+an interactive debugging command.
+
+\label Examples::
+
+\code
+ (defun factorial (x)
+   (cond ((or (not (typep x 'integer)) (minusp x))
+          (error "~S is not a valid argument to FACTORIAL." x))
+         ((zerop x) 1)
+         (t (* x (factorial (- x 1))))))
+\EV FACTORIAL
+(factorial 20)
+\EV 2432902008176640000
+(factorial -1)
+\OUT Error: -1 is not a valid argument to FACTORIAL.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Return to Lisp Toplevel.
+\OUT Debug> 
+\endcode
+
+\code
+ (setq a 'fred)
+\EV FRED
+ (if (numberp a) (1+ a) (error "~S is not a number." A))
+\OUT Error: FRED is not a number.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Return to Lisp Toplevel.
+\OUT Debug> \IN{:Continue 1}
+\OUT Return to Lisp Toplevel.
+ 
+ (define-condition not-a-number (error) 
+                   ((argument :reader not-a-number-argument :initarg :argument))
+   (:report (lambda (condition stream)
+              (format stream "~S is not a number."
+                      (not-a-number-argument condition)))))
+\EV NOT-A-NUMBER
+ 
+ (if (numberp a) (1+ a) (error 'not-a-number :argument a))
+\OUT Error: FRED is not a number.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Return to Lisp Toplevel.
+\OUT Debug> \IN{:Continue 1}
+\OUT Return to Lisp Toplevel.
+\endcode
+
+\label Side Effects::
+
+\term{Handlers} for the specified condition, if any, are invoked 
+and might have side effects.
+Program execution might stop, and the debugger might be entered.
+
+\label Affected By::
+
+Existing handler bindings.
+
+\varref{*break-on-signals*}
+%\varref{*debug-io*}.
+
+\label Exceptional Situations:\None.
+
+%% Not exceptional.
+% The reason for using \funref{error} is to signal a \term{condition},
+% the exact nature of which is specified by the arguments;  however,
+% that situation is not considered exceptional.
+
+\Checktypes{\param{datum} and \param{arguments}}{\term{designators} for a \term{condition}}
+
+\label See Also::
+
+\funref{cerror}, \funref{signal}, \funref{format}, 
+\macref{ignore-errors}, \varref{*break-on-signals*}, 
+\macref{handler-bind}, {\secref\ConditionSystemConcepts}
+
+\label Notes::
+
+Some implementations may provide debugger
+commands for interactively returning from individual stack frames.
+However, it should be possible for the programmer to feel confident
+about writing code like:
+
+\code
+ (defun wargames:no-win-scenario ()
+   (if (error "pushing the button would be stupid."))
+   (push-the-button))
+\endcode
+In this scenario, there should be no chance that
+\funref{error} will return
+and the button will get pushed.
+ 
+While the meaning of this program is clear and it might be proven `safe'
+by a formal theorem prover, such a proof is no guarantee that the
+program is safe to execute.  Compilers have been known to have bugs,
+computers to have signal glitches, and human beings to manually
+intervene in ways that are not always possible to predict.  Those kinds
+of errors, while beyond the scope of the condition system to formally
+model, are not beyond the scope of things that should seriously be
+considered when writing code that could have the kinds of sweeping
+effects hinted at by this example.
+
+\endcom
+
+%%% ========== CERROR
+\begincom{cerror}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues cerror {continue-format-control datum {\rest} arguments} {\nil}
+
+\label Arguments and Values:: 
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\param{Continue-format-control}---a \term{format control}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\reviewer{Barmar: What is continue-format-control used for??}
+
+\param{datum}, \param{arguments}---\term{designators} for a \term{condition} 
+ of default type \typeref{simple-error}.
+
+\label Description::
+
+\funref{cerror} effectively invokes \funref{error} on the
+\term{condition} named by \param{datum}.  As with any function that
+implicitly calls \funref{error}, if the \term{condition} is not handled,
+\f{(invoke-debugger \i{condition})} is executed.  While signaling is going on,
+and while in the debugger if it is reached, it is possible to continue
+code execution (\ie to return from \funref{cerror}) using \therestart{continue}.
+% If the debugger is interactively instructed to continue,
+% the call to \funref{cerror} returns \nil.
+
+If \param{datum} is a \term{condition}, \param{arguments} can be supplied,
+but are used only in conjunction with the \param{continue-format-control}.
+
+\label Examples::
+
+%!!! I don't like the debugger typeout format here. -kmp 3-Sep-91
+\code
+ (defun real-sqrt (n)
+   (when (minusp n)
+     (setq n (- n))
+     (cerror "Return sqrt(~D) instead." "Tried to take sqrt(-~D)." n))
+   (sqrt n))
+
+ (real-sqrt 4)
+\EV 2.0
+
+ (real-sqrt -9)
+\OUT Correctable error in REAL-SQRT: Tried to take sqrt(-9).
+\OUT Restart options:
+\OUT  1: Return sqrt(9) instead.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\EV 3.0
+ 
+ (define-condition not-a-number (error)
+   ((argument :reader not-a-number-argument :initarg :argument))
+   (:report (lambda (condition stream)
+              (format stream "~S is not a number." 
+                      (not-a-number-argument condition)))))
+ 
+ (defun assure-number (n)
+   (loop (when (numberp n) (return n))
+         (cerror "Enter a number."
+                 'not-a-number :argument n)
+         (format t "~&Type a number: ")
+         (setq n (read))
+         (fresh-line)))
+
+ (assure-number 'a)
+\OUT Correctable error in ASSURE-NUMBER: A is not a number.
+\OUT Restart options:
+\OUT  1: Enter a number.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\OUT Type a number: \IN{1/2}
+\EV 1/2
+
+ (defun assure-large-number (n)
+   (loop (when (and (numberp n) (> n 73)) (return n))
+         (cerror "Enter a number~:[~; a bit larger than ~D~]."
+                 "~*~A is not a large number." 
+                 (numberp n) n)
+         (format t "~&Type a large number: ")
+         (setq n (read))
+         (fresh-line)))
+ 
+ (assure-large-number 10000)
+\EV 10000
+
+ (assure-large-number 'a)
+\OUT Correctable error in ASSURE-LARGE-NUMBER: A is not a large number.
+\OUT Restart options:
+\OUT  1: Enter a number.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\OUT Type a large number: \IN{88}
+\EV 88
+
+ (assure-large-number 37)
+\OUT Correctable error in ASSURE-LARGE-NUMBER: 37 is not a large number.
+\OUT Restart options:
+\OUT  1: Enter a number a bit larger than 37.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\OUT Type a large number: \IN{259}
+\EV 259
+ 
+ (define-condition not-a-large-number (error)
+   ((argument :reader not-a-large-number-argument :initarg :argument))
+   (:report (lambda (condition stream)
+              (format stream "~S is not a large number." 
+                      (not-a-large-number-argument condition)))))
+ 
+ (defun assure-large-number (n)
+   (loop (when (and (numberp n) (> n 73)) (return n))
+         (cerror "Enter a number~3*~:[~; a bit larger than ~*~D~]."
+                 'not-a-large-number
+                 :argument n 
+                 :ignore (numberp n)
+                 :ignore n
+                 :allow-other-keys t)
+         (format t "~&Type a large number: ")
+         (setq n (read))
+         (fresh-line)))
+ 
+
+ (assure-large-number 'a)
+\OUT Correctable error in ASSURE-LARGE-NUMBER: A is not a large number.
+\OUT Restart options:
+\OUT  1: Enter a number.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\OUT Type a large number: \IN{88}
+\EV 88
+ 
+ (assure-large-number 37)
+\OUT Correctable error in ASSURE-LARGE-NUMBER: A is not a large number.
+\OUT Restart options:
+\OUT  1: Enter a number a bit larger than 37.
+\OUT  2: Top level.
+\OUT Debug> \IN{:continue 1}
+\OUT Type a large number: \IN{259}
+\EV 259
+\endcode
+
+\label Affected By::
+
+\varref{*break-on-signals*}.
+%\varref{*debug-io*}.
+
+Existing handler bindings.
+
+\label Exceptional Situations:\None.
+
+% The reason for using \funref{cerror} is to signal a \term{condition},
+% the exact nature of which is specified by the arguments.
+
+%!!! Was this saying anything useful??? -kmp 3-Sep-91
+% An error \oftype{type-error} is signaled if the \term{condition} 
+% named by \param{datum} is not handled.
+
+\label See Also::
+
+\funref{error}, \funref{format}, \macref{handler-bind},
+\varref{*break-on-signals*}, \typeref{simple-type-error}
+
+\label Notes::
+
+If \param{datum} is a \term{condition} \term{type} rather than a 
+\term{string}, the \funref{format} directive {\tt ~*} may be especially
+useful in the \param{continue-format-control} in order to ignore the
+\term{keywords} in the \term{initialization argument list}.  For example:
+ 
+\code
+(cerror "enter a new value to replace ~*~s" 
+        'not-a-number
+        :argument a)
+\endcode
+ 
+\endcom
+
+%%% ========== CHECK-TYPE
+\begincom{check-type}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues check-type {place typespec {\brac{\param{string}}}} {\nil}
+
+\label Arguments and Values:: 
+
+\param{place}---a \term{place}.
+
+\param{typespec}---a \term{type specifier}.
+
+\param{string}---a \term{string}; \eval. %!!! Really??
+
+\label Description::
+
+\funref{check-type} signals a \term{correctable} \term{error} 
+\oftype{type-error} if the contents of \param{place} are not 
+of the type \param{typespec}.
+
+\macref{check-type} can return only if \therestart{store-value} is invoked,
+either explicitly from a handler 
+    or implicitly as one of the options offered by the debugger.
+If \therestart{store-value} is invoked,
+\macref{check-type} stores the new value 
+that is the argument to the \term{restart} invocation 
+(or that is prompted for interactively by the debugger)
+in \param{place} and starts over, 
+checking the type of the new value
+and signaling another error if it is still not of the desired \term{type}.
+
+% This used to say:
+%   The \term{subforms} of \param{place} are evaluated once in the 
+%   order specified as follows: ...
+% Barmar said this is wrong. The first time the PLACE is evaluated, it is
+% evaluated using normal evaluation.  It is only evaluated as a SETF place if
+% the type check fails and \therestart{store-value} is used.
+% Barrett concurs.  Rewritten...
+
+The first time \param{place} is \term{evaluated}, 
+it is \term{evaluated} by normal evaluation rules.
+It is later \term{evaluated} as a \term{place} 
+if the type check fails and \therestart{store-value} is used;
+\seesection\GenRefSubFormEval.
+
+%% I think this is now unnecessary due to the previous paragraph. -kmp 21-Nov-91
+% The \param{place} and its \term{subforms} might be evaluated again if
+% the type check fails.
+
+\term{string} should be an English description of the type, 
+starting with an indefinite article (``a'' or ``an'').
+If \term{string} is not supplied,
+it is computed automatically from \param{typespec}.
+The automatically generated message mentions
+      \param{place},
+      its contents,
+  and the desired type.
+An implementation may choose to generate 
+a somewhat differently worded error message 
+if it recognizes that \param{place} is of a particular form, 
+such as one of the arguments to the function that called \macref{check-type}.
+\term{string} is allowed because some applications of \macref{check-type} 
+may require a more specific description of what is wanted
+than can be generated automatically from \param{typespec}.
+
+\label Examples::
+
+\code
+ (setq aardvarks '(sam harry fred))
+\EV (SAM HARRY FRED)
+ (check-type aardvarks (array * (3)))
+\OUT Error: The value of AARDVARKS, (SAM HARRY FRED),
+\OUT        is not a 3-long array.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Specify a value to use instead.
+\OUT  2: Return to Lisp Toplevel.
+\OUT Debug> \IN{:CONTINUE 1}
+\OUT Use Value: \IN{#(SAM FRED HARRY)}
+\EV NIL
+ aardvarks
+\EV #<ARRAY-T-3 13571>
+ (map 'list #'identity aardvarks)
+\EV (SAM FRED HARRY)
+ (setq aardvark-count 'foo)
+\EV FOO
+ (check-type aardvark-count (integer 0 *) "A positive integer")
+\OUT Error: The value of AARDVARK-COUNT, FOO, is not a positive integer.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Specify a value to use instead.
+\OUT  2: Top level.
+\OUT Debug> \IN{:CONTINUE 2}
+\endcode
+
+\code
+ (defmacro define-adder (name amount)
+   (check-type name (and symbol (not null)) "a name for an adder function")
+   (check-type amount integer)
+   `(defun ,name (x) (+ x ,amount)))
+  
+ (macroexpand '(define-adder add3 3))
+\EV (defun add3 (x) (+ x 3))
+ 
+ (macroexpand '(define-adder 7 7))
+\OUT Error: The value of NAME, 7, is not a name for an adder function.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Specify a value to use instead.
+\OUT  2: Top level.
+\OUT Debug> \IN{:Continue 1}
+\OUT Specify a value to use instead.
+\OUT Type a form to be evaluated and used instead: \IN{'ADD7}
+\EV (defun add7 (x) (+ x 7))
+ 
+ (macroexpand '(define-adder add5 something))
+\OUT Error: The value of AMOUNT, SOMETHING, is not an integer.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Specify a value to use instead.
+\OUT  2: Top level.
+\OUT Debug> \IN{:Continue 1}
+\OUT Type a form to be evaluated and used instead: \IN{5}
+\EV (defun add5 (x) (+ x 5))
+ 
+\endcode
+ 
+Control is transferred to a handler.
+
+\label Side Effects::
+
+The debugger might be entered.
+
+\label Affected By::
+
+\varref{*break-on-signals*}
+%\varref{*debug-io*}
+
+The implementation.
+
+\label Exceptional Situations:\None.
+
+%% Barrett: Not exceptional.
+% An error \oftype{type-error} is signaled 
+% if the contents of \param{place} are not 
+% of the \term{type} specified by \param{typespec}.
+
+\label See Also::
+
+{\secref\ConditionSystemConcepts}
+
+\label Notes::
+
+\code
+ (check-type \param{place} \param{typespec})
+ \EQ (assert (typep \param{place} '\param{typespec}) (\param{place})
+            'type-error :datum \param{place} :expected-type '\param{typespec})
+\endcode
+
+\endcom
+
+\begincom{simple-error}\ftype{Condition Type}
+
+\label Class Precedence List::
+
+\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+\typeref{simple-error},
+\typeref{simple-condition},
+\typeref{error},
+\typeref{serious-condition},
+\typeref{condition},
+\typeref{t}
+\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+
+\label Description::
+
+\Thetype{simple-error} consists of \term{conditions} that
+are signaled by \funref{error} or \funref{cerror} when a
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}%
+\term{format control}
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}%
+is supplied as the function's first argument.
+%The default condition type for \funref{error} and 
+%\funref{cerror} is \typeref{simple-error}.
+
+\endcom%{simple-error}\ftype{Condition Type}
+
+
+%%% ========== INVALID-METHOD-ERROR
+\begincom{invalid-method-error}\ftype{Function}
+ 
+\label Syntax::
+ 
+\DefunWithValues invalid-method-error 
+	         {method format-control {\rest} args}
+		 {\term{implementation-dependent}}
+
+\label Arguments and Values::
+ 
+\param{method}---a \term{method}.
+ 
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\param{format-control}---a \term{format control}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+ 
+\param{args}---\term{format arguments} for the \param{format-control}.
+ 
+\label Description::
+ 
+\Thefunction{invalid-method-error} is used to signal an error \oftype{error}
+when there is an applicable \term{method} whose \term{qualifiers} are not valid for
+the method combination type.  The error message is constructed by
+using the \param{format-control} suitable for \funref{format}
+and any \param{args} to it.  Because an
+implementation may need to add additional contextual information to
+the error message, \funref{invalid-method-error} should be called only
+within the dynamic extent of a method combination function.
+ 
+\Thefunction{invalid-method-error} is called automatically when a
+\term{method} fails to satisfy every \term{qualifier} pattern and predicate in a
+\macref{define-method-combination} \term{form}.  A method combination function
+that imposes additional restrictions should call 
+\funref{invalid-method-error} explicitly if it encounters a \term{method} 
+it cannot accept.
+ 
+%!!! What does this mean? -kmp 13-Feb-91
+Whether \funref{invalid-method-error} returns to its caller or exits via
+\specref{throw} is \term{implementation-dependent}.
+
+\label Examples:\None.
+ 
+\label Side Effects::
+
+The debugger might be entered.
+
+\label Affected By::
+
+\varref{*break-on-signals*}
+ 
+\label Exceptional Situations:\None.
+ 
+\label See Also:: 
+ 
+\macref{define-method-combination}
+                           
+%% Per X3J13. -kmp 05-Oct-93
+\label Notes:\None.
+ 
+\endcom
+
+%%% ========== METHOD-COMBINATION-ERROR
+\begincom{method-combination-error}\ftype{Function}
+ 
+\label Syntax::
+ 
+\DefunWithValues {method-combination-error} 
+		 {format-control {\rest} args}
+	         {\term{implementation-dependent}}
+
+\label Arguments and Values:: 
+ 
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\param{format-control}---a \term{format control}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+ 
+\param{args}---\term{format arguments} for \param{format-control}.
+ 
+\label Description::
+ 
+\Thefunction{method-combination-error} is used to signal an error
+in method combination.  
+ 
+The error message is constructed by using a \param{format-control} suitable
+for \funref{format} and any \param{args} to it.  Because an implementation may
+need to add additional contextual information to the error message,
+\funref{method-combination-error} should be called only within the
+dynamic extent of a method combination function.
+ 
+%!!! What does this mean? -kmp 13-Feb-91
+Whether \funref{method-combination-error} returns to its caller or exits
+via \specref{throw} is \term{implementation-dependent}.
+
+%% Per X3J13. -kmp 05-Oct-93
+\label Examples:\None.
+ 
+\label Side Effects::
+
+The debugger might be entered.
+
+\label Affected By::
+
+\varref{*break-on-signals*}
+ 
+\label Exceptional Situations:\None.
+ 
+\label See Also:: 
+ 
+\macref{define-method-combination}
+ 
+%% Per X3J13. -kmp 05-Oct-93
+\label Notes:\None.
+ 
+\endcom
+
+%%% ========== SIGNAL
+\begincom{signal}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues signal {datum {\rest} arguments} {\nil}
+
+\label Arguments and Values::                                               
+
+\param{datum}, \param{arguments}---\term{designators} for a \term{condition} 
+ of default type \typeref{simple-condition}.
+
+\label Description::
+
+\term{Signals} the \term{condition} denoted by the given \param{datum} and \param{arguments}.
+If the \term{condition} is not handled, \funref{signal} returns \nil.
+
+\label Examples::
+
+\code
+ (defun handle-division-conditions (condition)
+   (format t "Considering condition for division condition handling~%")
+   (when (and (typep condition 'arithmetic-error)
+              (eq '/ (arithmetic-error-operation condition)))
+     (invoke-debugger condition)))
+HANDLE-DIVISION-CONDITIONS
+ (defun handle-other-arithmetic-errors (condition)
+   (format t "Considering condition for arithmetic condition handling~%")
+   (when (typep condition 'arithmetic-error)
+     (abort)))
+HANDLE-OTHER-ARITHMETIC-ERRORS
+ (define-condition a-condition-with-no-handler (condition) ())
+A-CONDITION-WITH-NO-HANDLER
+ (signal 'a-condition-with-no-handler)
+NIL
+ (handler-bind ((condition #'handle-division-conditions)
+                  (condition #'handle-other-arithmetic-errors))
+   (signal 'a-condition-with-no-handler))
+Considering condition for division condition handling
+Considering condition for arithmetic condition handling
+NIL
+ (handler-bind ((arithmetic-error #'handle-division-conditions)
+                  (arithmetic-error #'handle-other-arithmetic-errors))
+   (signal 'arithmetic-error :operation '* :operands '(1.2 b)))
+Considering condition for division condition handling
+Considering condition for arithmetic condition handling
+Back to Lisp Toplevel
+\endcode
+
+\label Side Effects::
+
+The debugger might be entered due to \varref{*break-on-signals*}.
+
+Handlers for the condition being signaled might transfer control.
+
+\label Affected By::
+
+Existing handler bindings.
+
+\varref{*break-on-signals*}
+%\varref{*debug-io*}
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\varref{*break-on-signals*},
+\funref{error},
+\typeref{simple-condition},
+{\secref\CondSignalHandle}
+
+\label Notes::
+
+If \f{(typep \param{datum} *break-on-signals*)} \term{yields} \term{true},
+the debugger is entered prior to beginning the signaling process.  
+\Therestart{continue} can be used to continue with the signaling process.
+This is also true for all other \term{functions} and \term{macros} that
+should, might, or must \term{signal} \term{conditions}.
+
+\endcom
+
+%----------------------------------------
+
+\begincom{simple-condition}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{simple-condition},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{simple-condition} represents \term{conditions} that are
+signaled by \funref{signal} whenever a \param{format-control} is
+supplied as the function's first argument.
+%The default \term{condition} \term{type} for \funref{signal} 
+%and \funref{warn} is \typeref{simple-condition}.
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+The \term{format control} and \term{format arguments} are initialized with 
+\theinitkeyargs{format-control} 
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+and \kwd{format-arguments} to \funref{make-condition}, and are
+\term{accessed} by the \term{functions}
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\funref{simple-condition-format-control}
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+and \funref{simple-condition-format-arguments}.
+If format arguments are not supplied to \funref{make-condition},
+\nil\ is used as a default.
+
+\label See Also::
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\funref{simple-condition-format-control},
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\funref{simple-condition-format-arguments}
+
+\endcom%{simple-condition}\ftype{Condition Type}
+
+%%% ========== SIMPLE-CONDITION-FORMAT-ARGUMENTS
+\begincom{simple-condition-format-control, simple-condition-format-arguments}\ftype{Function}
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\label Syntax::
+
+\DefunWithValues simple-condition-format-control {condition} {format-control}
+\DefunWithValues simple-condition-format-arguments {condition} {format-arguments}
+
+\label Arguments and Values:: 
+
+\param{condition}---a \term{condition} of \term{type} \typeref{simple-condition}.
+%% Barmar: These are all subtypes of simple-condition...
+% 				    or \typeref{simple-warning}
+% 				    or \typeref{simple-error}
+% 				    or \typeref{simple-type-error}.
+
+\param{format-control}---a \term{format control}.
+
+\param{format-arguments}---a \term{list}.
+
+\label Description::
+
+\funref{simple-condition-format-control} returns the \term{format control} needed to 
+process the \param{condition}'s \term{format arguments}.
+
+\funref{simple-condition-format-arguments} returns a \term{list} of \term{format arguments} 
+needed to process the \param{condition}'s \term{format control}.
+
+\label Examples::
+
+\code
+ (setq foo (make-condition 'simple-condition
+                          :format-control "Hi ~S"
+                          :format-arguments '(ho)))
+\EV #<SIMPLE-CONDITION 26223553>
+ (apply #'format nil (simple-condition-format-control foo)
+                     (simple-condition-format-arguments foo))
+\EV "Hi HO"
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{simple-condition},
+{\secref\ConditionSystemConcepts}
+
+%% Per X3J13. -kmp 05-Oct-93
+\label Notes:\None.
+
+%% Shouldn't be needed. -kmp 1-Sep-91
+%It is an error to use \macref{setf} with \funref{simple-condition-format-arguments}.
+%It is an error to use \macref{setf} with \funref{simple-condition-format-control}.
+
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\endcom
+
+%%% ========== WARN
+\begincom{warn}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues warn {datum {\rest} arguments} {\nil}
+
+\label Arguments and Values:: 
+
+\param{datum}, \param{arguments}---\term{designators} for a \term{condition} 
+ of default type \typeref{simple-warning}.
+
+\label Description::
+
+\term{Signals} a \term{condition} \oftype{warning}.
+If the \term{condition} is not \term{handled},
+reports the \term{condition} to \term{error output}.
+
+The precise mechanism for warning is as follows:
+
+\issue{BREAK-ON-WARNINGS-OBSOLETE:REMOVE}
+%Discussion of *BREAK-ON-WARNINGS* removed.
+\endissue{BREAK-ON-WARNINGS-OBSOLETE:REMOVE}
+
+%!!! Barret wonders whether stylistically it wouldn't be better to have just
+%    normal text instead of this indented stuff.
+\beginlist
+
+\itemitem{{\bf The warning condition is signaled}}
+
+While the \typeref{warning} \term{condition} is being signaled,
+\therestart{muffle-warning} is established for use by a \term{handler}.
+If invoked, this \term{restart} bypasses further action by \funref{warn},
+which in turn causes \funref{warn} to immediately return \nil.
+
+\itemitem{{\bf If no handler for the warning condition is found}}
+
+If no handlers for the warning condition are found,
+or if all such handlers decline,
+then the \term{condition} is reported to \term{error output}
+by \funref{warn} in an \term{implementation-dependent} format.
+%% Barrett points out that the details of this are already said elsewhere in
+%% the concept info for conditions.
+% (with possible implementation-specific extra
+% output such as motion to a fresh line before and/or after the display
+% of the warning, or supplying some introductory text that might mention
+% the name of the function which called \funref{warn} 
+% and/or the fact that this is a warning).
+
+\itemitem{{\bf \nil\ is returned}}
+
+The value returned by \funref{warn} if it returns is \nil.
+\endlist
+
+\label Examples::
+
+\code
+  (defun foo (x)
+    (let ((result (* x 2)))
+      (if (not (typep result 'fixnum))
+          (warn "You're using very big numbers."))
+      result))
+\EV FOO
+ 
+  (foo 3)
+\EV 6
+ 
+  (foo most-positive-fixnum)
+\OUT Warning: You're using very big numbers.
+\EV 4294967294
+ 
+  (setq *break-on-signals* t)
+\EV T
+ 
+  (foo most-positive-fixnum)
+\OUT Break: Caveat emptor.
+\OUT To continue, type :CONTINUE followed by an option number.
+\OUT  1: Return from Break.
+\OUT  2: Abort to Lisp Toplevel.
+\OUT Debug> :continue 1
+\OUT Warning: You're using very big numbers.
+\EV 4294967294
+\endcode
+ 
+\label Side Effects::
+
+A warning is issued.  The debugger might be entered.
+
+\label Affected By::
+
+Existing handler bindings.
+
+\varref{*break-on-signals*},
+\varref{*error-output*}.         
+
+\label Exceptional Situations::
+
+If \param{datum} is a \term{condition}
+and if the \term{condition} is not \oftype{warning},
+or \param{arguments} is \term{non-nil}, an error \oftype{type-error} is signaled.
+
+If \param{datum} is a condition type, 
+the result of {\tt (apply #'make-condition datum arguments)} 
+must be \oftype{warning} or an error \oftype{type-error} is signaled.
+
+\label See Also::
+
+\varref{*break-on-signals*},
+\funref{muffle-warning},
+\funref{signal}
+
+\label Notes:\None.
+
+\endcom
+
+\begincom{simple-warning}\ftype{Condition Type}
+
+\label Class Precedence List::
+
+\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+\typeref{simple-warning},
+\typeref{simple-condition},
+\typeref{warning},
+\typeref{condition},
+\typeref{t}
+\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
+
+\label Description::
+
+\Thetype{simple-warning} represents \term{conditions} that 
+are signaled by \funref{warn} whenever a 
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\term{format control} 
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+is supplied as the function's first argument.
+
+\endcom%{simple-warning}\ftype{Condition Type}
+
+%-------------------- Debugger --------------------
+
+%%% ========== INVOKE-DEBUGGER
+\begincom{invoke-debugger}\ftype{Function}
+
+\label Syntax::
+
+\DefunNoReturn invoke-debugger {condition}
+
+\label Arguments and Values:: 
+
+\param{condition}---a \term{condition} \term{object}.
+
+\label Description::
+
+\funref{invoke-debugger} attempts to enter the debugger with \param{condition}.
+
+If \varref{*debugger-hook*} is not \nil, it should be a \term{function} 
+(or the name of a \term{function}) to be called prior to entry to 
+the standard debugger.  The \term{function} is called with
+\varref{*debugger-hook*} bound to \nil, and the \term{function} 
+must accept two arguments: the \param{condition} 
+and \thevalueof{*debugger-hook*} prior to binding it to \nil. 
+If the \term{function} returns normally,
+the standard debugger is entered.
+ 
+%!!! KMP: Maybe make glossary term of "standard debugger"?
+The standard debugger never directly returns.  Return can occur only by a
+non-local transfer of control, such as the use of a restart function.
+
+\label Examples::
+
+\code
+ (ignore-errors ;Normally, this would suppress debugger entry
+   (handler-bind ((error #'invoke-debugger)) ;But this forces debugger entry
+     (error "Foo.")))
+Debug: Foo.
+To continue, type :CONTINUE followed by an option number:
+ 1: Return to Lisp Toplevel.
+Debug>
+\endcode
+ 
+
+\label Side Effects::
+
+\varref{*debugger-hook*} is bound to \nil,
+program execution is discontinued,
+and the debugger is entered.
+
+\label Affected By::
+
+\varref{*debug-io*} and \varref{*debugger-hook*}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{error}, \funref{break}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== BREAK
+\begincom{break}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues break {{\opt} format-control {\rest} format-arguments} {\nil}
+
+\label Arguments and Values:: 
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\param{format-control}---a \term{format control}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+ \Default{\term{implementation-dependent}}
+
+\param{format-arguments}---\term{format arguments} for the \param{format-control}.
+
+\label Description::
+
+%% 24.0.0 29
+
+\funref{break} \term{formats} \param{format-control} and \param{format-arguments}
+and then goes directly into the debugger without allowing any possibility of
+interception by programmed error-handling facilities.
+
+If \therestart{continue} is used while in the debugger,
+\funref{break} immediately returns \nil\ without taking any unusual recovery action.
+
+\issue{DEBUGGER-HOOK-VS-BREAK:CLARIFY}
+\funref{break} binds \varref{*debugger-hook*} to \nil\ 
+before attempting to enter the debugger.
+\endissue{DEBUGGER-HOOK-VS-BREAK:CLARIFY}
+
+\label Examples::
+
+\code
+ (break "You got here with arguments: ~:S." '(FOO 37 A))
+\OUT BREAK: You got here with these arguments: FOO, 37, A.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Return from BREAK.
+\OUT  2: Top level.
+\OUT Debug> :CONTINUE 1
+\OUT Return from BREAK.
+\EV NIL
+ 
+\endcode
+ 
+\label Side Effects::
+
+The debugger is entered.
+
+\label Affected By::
+
+\varref{*debug-io*}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{error}, \funref{invoke-debugger}.
+
+\label Notes::
+
+%% 24.0.0 30
+\funref{break} is used as a way of inserting temporary debugging
+``breakpoints'' in a program, not as a way of signaling errors.  
+For this reason, \funref{break} does not take the \param{continue-format-control}
+\term{argument} that \funref{cerror} takes.
+This and the lack of any possibility of interception by
+\term{condition} \term{handling} are the only program-visible 
+differences between \funref{break} and \funref{cerror}.
+
+The user interface aspects of \funref{break} and \funref{cerror} are
+permitted to vary more widely, in order to accomodate the interface
+needs of the \term{implementation}. For example, it is permissible for a
+\term{Lisp read-eval-print loop} to be entered by \funref{break} rather
+than the conventional debugger.
+
+\funref{break} could be defined by:
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\code
+ (defun break (&optional (format-control "Break") &rest format-arguments)
+   (with-simple-restart (continue "Return from BREAK.")
+     (let ((*debugger-hook* nil))
+       (invoke-debugger
+           (make-condition 'simple-condition
+                           :format-control format-control
+                           :format-arguments format-arguments))))
+   nil)
+\endcode
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\endcom
+
+%%% ========== *DEBUGGER-HOOK*
+\begincom{*debugger-hook*}\ftype{Variable}
+
+\label Value Type::
+
+%!!! Barrett: What if this is invoked directly instead of from invoke-debugger?
+a \term{designator} for a \term{function} of two \term{arguments}
+  (a \term{condition} and \thevalueof{*debugger-hook*} at the time 
+   the debugger was entered),
+or \nil.
+
+\label Initial Value::
+
+\nil.
+
+\label Description::
+
+When \thevalueof{*debugger-hook*} is \term{non-nil}, it is called prior to
+normal entry into the debugger, either due to a call to \funref{invoke-debugger} 
+or due to automatic entry into the debugger from a call to \funref{error} 
+or \funref{cerror} with a condition that is not handled.  
+The \term{function} may either handle the \term{condition}
+(transfer control) or return normally (allowing the standard debugger to run).
+To minimize recursive errors while debugging,
+\varref{*debugger-hook*} is bound to \nil\ by \funref{invoke-debugger} 
+prior to calling the \term{function}.
+
+\label Examples::
+
+\code
+ (defun one-of (choices &optional (prompt "Choice"))
+   (let ((n (length choices)) (i))
+     (do ((c choices (cdr c)) (i 1 (+ i 1)))
+         ((null c))
+       (format t "~&[~D] ~A~%" i (car c)))
+     (do () ((typep i `(integer 1 ,n)))
+       (format t "~&~A: " prompt)
+       (setq i (read))
+       (fresh-line))
+     (nth (- i 1) choices)))
+
+ (defun my-debugger (condition me-or-my-encapsulation)
+   (format t "~&Fooey: ~A" condition)
+   (let ((restart (one-of (compute-restarts))))
+     (if (not restart) (error "My debugger got an error."))
+     (let ((*debugger-hook* me-or-my-encapsulation))
+       (invoke-restart-interactively restart))))
+ 
+ (let ((*debugger-hook* #'my-debugger))
+   (+ 3 'a))
+\OUT Fooey: The argument to +, A, is not a number.
+\OUT  [1] Supply a replacement for A.
+\OUT  [2] Return to Cloe Toplevel.
+\OUT Choice: 1
+\OUT  Form to evaluate and use: (+ 5 'b)
+\OUT  Fooey: The argument to +, B, is not a number.
+\OUT  [1] Supply a replacement for B.
+\OUT  [2] Supply a replacement for A.
+\OUT  [3] Return to Cloe Toplevel.
+\OUT Choice: 1
+\OUT  Form to evaluate and use: 1
+\EV 9
+\endcode
+
+\label Affected By::
+
+\funref{invoke-debugger}
+
+\label See Also:\None.
+
+\label Notes::
+
+When evaluating code typed in by the user interactively, it is sometimes
+useful to have the hook function bind \varref{*debugger-hook*} to the
+\term{function} that was its second argument so that recursive errors
+can be handled using the same interactive facility.
+                                            
+\endcom
+
+%%% ========== *BREAK-ON-SIGNALS*
+\begincom{*break-on-signals*}\ftype{Variable}
+ 
+\label Value Type::
+
+a \term{type specifier}.
+
+\label Initial Value::
+
+\nil.
+
+\label Description::
+
+%!!! Does this get involved in *debugger-hook*?  What kind of break is entered?
+When \f{(typep \i{condition} *break-on-signals*)} returns \term{true},
+calls to \funref{signal}, and to other \term{operators} such as \funref{error}
+that implicitly call \funref{signal}, enter the debugger prior to
+\term{signaling} the \term{condition}.
+
+\Therestart{continue} can be used to continue with the normal
+\term{signaling} process when a break occurs process due to
+\varref{*break-on-signals*}.
+
+\label Examples::
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\code
+ *break-on-signals* \EV NIL
+ (ignore-errors (error 'simple-error :format-control "Fooey!"))
+\EV NIL, #<SIMPLE-ERROR 32207172>
+
+ (let ((*break-on-signals* 'error))
+   (ignore-errors (error 'simple-error :format-control "Fooey!")))
+\OUT Break: Fooey!
+\OUT BREAK entered because of *BREAK-ON-SIGNALS*.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Continue to signal.
+\OUT  2: Top level.
+\OUT Debug> \IN{:CONTINUE 1}
+\OUT Continue to signal.
+\EV NIL, #<SIMPLE-ERROR 32212257>
+
+ (let ((*break-on-signals* 'error))
+   (error 'simple-error :format-control "Fooey!"))
+\OUT Break: Fooey!
+\OUT BREAK entered because of *BREAK-ON-SIGNALS*.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Continue to signal.
+\OUT  2: Top level.
+\OUT Debug> \IN{:CONTINUE 1}
+\OUT Continue to signal.
+\OUT Error: Fooey!
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Top level.
+\OUT Debug> \IN{:CONTINUE 1}
+\OUT Top level.
+\endcode
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\label Affected By:\None.
+
+\label See Also::
+
+\funref{break},
+\funref{signal}, \funref{warn}, \funref{error}, 
+\funref{typep}, 
+{\secref\ConditionSystemConcepts}
+
+\label Notes::
+
+\varref{*break-on-signals*} is intended primarily for use in debugging code that
+does signaling.   When setting \varref{*break-on-signals*}, the user is
+encouraged to choose the most restrictive specification that suffices.
+Setting \varref{*break-on-signals*} effectively violates the modular handling of 
+\term{condition} signaling.  In practice, the complete effect of setting
+\varref{*break-on-signals*} might be unpredictable in some cases since the user
+might not be aware of the variety or number of calls to \funref{signal} 
+that are used in code called only incidentally.
+
+\issue{BREAK-ON-WARNINGS-OBSOLETE:REMOVE}
+% Reference to *BREAK-ON-WARNINGS* removed.
+\endissue{BREAK-ON-WARNINGS-OBSOLETE:REMOVE}
+
+\varref{*break-on-signals*} enables an early entry to the debugger but such an
+entry does not preclude an additional entry to the debugger in the case of
+operations such as \funref{error} and \funref{cerror}.
+
+\endcom
+
+%-------------------- Handling --------------------
+
+%%% ========== HANDLER-BIND
+\begincom{handler-bind}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues handler-bind
+		  {\paren{\stardown{binding}} 
+		   \starparam{form}}
+		  {\starparam{result}}
+
+\auxbnf{binding}{\paren{type handler}}
+
+\label Arguments and Values:: 
+
+\param{type}---a \term{type specifier}.
+
+\param{handler}---a \term{form}; evaluated to produce a \param{handler-function}.
+                     
+\param{handler-function}---a \term{designator} for a \term{function} of one \term{argument}.
+
+\param{forms}---an \term{implicit progn}.
+
+\param{results}---the \term{values} returned by the \term{forms}.
+
+\label Description::
+
+Executes \param{forms} in a \term{dynamic environment} where the indicated
+\param{handler} \term{bindings} are in effect.
+
+Each \param{handler} should evaluate to a \term{handler-function},
+which is used to handle \term{conditions} of the given \param{type}
+during execution of the \param{forms}.  This \term{function} should
+take a single argument, the \term{condition} being signaled.
+
+%!!! Barmar: The next two paragraphs belong in description of signaling,
+%      not handling. [I agree. -kmp]
+If more than one \param{handler} \term{binding} is supplied, 
+the \param{handler} \term{bindings} are searched sequentially from 
+top to bottom in search of a match (by visual analogy with \macref{typecase}).  
+If an appropriate \term{type} is found, 
+the associated handler is run in a \term{dynamic environment} where none of these
+\param{handler} bindings are visible (to avoid recursive errors).  
+If the \term{handler} \term{declines}, the search continues for another \term{handler}.
+
+If no appropriate \term{handler} is found, other \term{handlers} are sought
+from dynamically enclosing contours.  If no \term{handler} is found outside, 
+then \funref{signal} returns or \funref{error} enters the debugger. 
+
+\label Examples::
+ 
+%Here's an example to think about as a possible replacement for the next
+%couple of paragraphs...
+% (defun test (x)
+%   (handler-bind ((unbound-variable #'(lambda (c) (use-value 'unbound c)))
+%                  (undefined-function 
+%                    #'(lambda (c) 
+%                        (use-value #'(lambda (&rest x) (cons (cell-error-name c) x)) c))))
+%     (eval x)))
+% (test '(frob (+ 1 2) hunoz))
+
+In the following code, if an unbound variable error is
+signaled in the body (and not handled by an intervening handler), 
+the first function is called.  
+
+\code
+ (handler-bind ((unbound-variable #'(lambda ...))
+                (error #'(lambda ...)))
+   ...)
+\endcode
+
+If any other kind of error is signaled, the second function is called.
+In either case, neither handler is active while executing the code
+in the associated function.
+
+\code
+ (defun trap-error-handler (condition)
+   (format *error-output* "~&~A~&" condition)
+   (throw 'trap-errors nil))
+
+ (defmacro trap-errors (&rest forms)
+   `(catch 'trap-errors
+      (handler-bind ((error #'trap-error-handler))
+        ,@forms)))
+ 
+ (list (trap-errors (signal "Foo.") 1)
+       (trap-errors (error  "Bar.") 2)
+       (+ 1 2))
+\OUT Bar.
+\EV (1 NIL 3)
+\endcode
+
+Note that ``Foo.'' is not printed because the condition made
+by \funref{signal} is a \term{simple condition}, which is not \oftype{error}, 
+so it doesn't trigger the handler for \typeref{error} set up by \f{trap-errors}.
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{handler-case}
+
+\label Notes:\None.
+
+\endcom
+
+
+%%% ========== HANDLER-CASE
+\begincom{handler-case}\ftype{Macro}
+
+\issue{DECLS-AND-DOC}
+
+\label Syntax::
+ 
+%!!! "expression" is a bad var name to use here.
+\DefmacWithValues handler-case
+		  {\param{expression}
+		   \interleave{\stardown{error-clause} | \down{no-error-clause}}}
+		  {\starparam{result}}
+ 
+\auxbnf{clause}{\down{error-clause} | \down{no-error-clause}}
+\auxbnf{error-clause}{\paren{typespec \paren{\ttbrac{var}} 
+		      \starparam{declaration} \starparam{form}}}
+\auxbnf{no-error-clause}{\paren{\kwd{no-error} \param{lambda-list} 
+			 \starparam{declaration} \starparam{form}}}
+
+%This should follow from the above BNF.
+%Note: There can be no more than one \i{no-error-clause}.
+
+\label Arguments and Values::
+
+\param{expression}---a \term{form}.
+
+\param{typespec}---a \term{type specifier}.
+
+\param{var}---a \term{variable} \term{name}. 
+
+\param{lambda-list}---an \term{ordinary lambda list}.
+
+\param{declaration}---a \misc{declare} \term{expression}; \noeval.
+
+\param{form}---a \term{form}.
+
+\param{results}---In the normal situation, the values returned are those that result from
+   the evaluation of \param{expression};
+   in the exceptional situation when control is transferred to a \param{clause},
+   the value of the last \param{form} in that \param{clause} is returned.
+ 
+\label Description::
+
+\macref{handler-case} executes \param{expression} in a \term{dynamic environment} where
+various handlers are active.  Each \i{error-clause} specifies how to 
+handle a \term{condition} matching the indicated \param{typespec}. 
+A \i{no-error-clause} allows the specification of a particular action
+if control returns normally.
+ 
+%!!! It would be nice if this reference to (TYPEP ...) and all others
+%    were rewritten in text fashion.
+If a \term{condition} is signaled for which there is an appropriate
+\i{error-clause} during the execution of \param{expression}
+(\ie one for which \f{(typep \term{condition} '\param{typespec})}
+returns \term{true}) and if there is no intervening handler for a 
+\term{condition} of that \term{type}, then control is transferred to
+the body of the relevant \i{error-clause}.  In this case, the 
+dynamic state is unwound appropriately (so that the handlers established
+around the \param{expression} are no longer active), and \param{var} is bound to
+the \term{condition} that had been signaled.
+%!!! Barmar: HANDLER-BIND describes this better...
+If more than one case is provided, those cases are made accessible
+in parallel.  That is, in
+ 
+\code
+  (handler-case \i{form}
+    (\i{typespec1} (\i{var1}) \i{form1})
+    (\i{typespec2} (\i{var2}) \i{form2}))
+\endcode
+
+if the first \i{clause} (containing \i{form1}) has been selected, 
+the handler for the second is no longer visible (or vice versa).
+ 
+   The \i{clauses}
+are searched sequentially from top to bottom. If there is \term{type}
+   overlap between \param{typespecs}, 
+the earlier of the \i{clauses} is selected.
+ 
+   If \param{var} 
+is not needed, it can be omitted. That is, a \i{clause} such as:
+
+\code
+  (\param{typespec} (\param{var}) (declare (ignore \param{var})) \param{form})
+\endcode
+
+can be written
+ \f{(\param{typespec} () \param{form})}.
+ 
+%% Per X3J13. -kmp 05-Oct-93
+%% 3 uses of HANDLER-BIND to be replaced by HANDLER-CASE in last para on page.
+   If there are no \param{forms} in a selected \i{clause}, the case, and therefore
+   \macref{handler-case}, returns \nil.
+    If execution of \param{expression} 
+returns normally and no \i{no-error-clause}
+   exists, the values returned by 
+\param{expression} are returned by \macref{handler-case}.
+   If execution of 
+\param{expression} returns normally and a \i{no-error-clause}
+   does exist, the values returned are used as arguments to the function
+   described by constructing
+ \f{(lambda \param{lambda-list} \starparam{form})}
+   from the \i{no-error-clause}, and the \term{values} of that function call are
+   returned by \macref{handler-case}.
+%The following was added to make Barmar happy. -kmp 1-Sep-91
+The handlers which were established around the \param{expression} are no longer active at the time of this call.
+
+\label Examples::
+
+\code
+ (defun assess-condition (condition)
+   (handler-case (signal condition)
+     (warning () "Lots of smoke, but no fire.")
+     ((or arithmetic-error control-error cell-error stream-error)
+        (condition)
+       (format nil "~S looks especially bad." condition))
+     (serious-condition (condition)
+       (format nil "~S looks serious." condition))
+     (condition () "Hardly worth mentioning.")))
+\EV ASSESS-CONDITION
+ (assess-condition (make-condition 'stream-error :stream *terminal-io*))
+\EV "#<STREAM-ERROR 12352256> looks especially bad."
+ (define-condition random-condition (condition) () 
+   (:report (lambda (condition stream)
+              (declare (ignore condition))
+              (princ "Yow" stream))))
+\EV RANDOM-CONDITION
+ (assess-condition (make-condition 'random-condition))
+\EV "Hardly worth mentioning."
+\endcode
+ 
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{handler-bind},
+\macref{ignore-errors},
+{\secref\ConditionSystemConcepts}
+
+\label Notes::
+
+\code
+ (handler-case form
+   (\i{type1} (\i{var1}) . \i{body1})
+   (\i{type2} (\i{var2}) . \i{body2}) ...)
+\endcode
+is approximately equivalent to:
+
+\code
+ (block #1=#:g0001
+   (let ((#2=#:g0002 nil))
+     (tagbody
+       (handler-bind ((\i{type1} #'(lambda (temp)
+                                       (setq #1# temp)
+                                       (go #3=#:g0003)))
+                      (\i{type2} #'(lambda (temp)
+                                       (setq #2# temp)
+                                       (go #4=#:g0004))) ...)
+       (return-from #1# form))
+         #3# (return-from #1# (let ((\i{var1} #2#)) . \i{body1}))
+         #4# (return-from #1# (let ((\i{var2} #2#)) . \i{body2})) ...)))
+\endcode
+
+\code
+ (handler-case form
+   (\i{type1} \i{(var1)} . \i{body1})
+   ...
+   (:no-error (\i{varN-1} \i{varN-2} ...) . \i{bodyN}))
+\endcode
+is approximately equivalent to:
+
+\code
+
+ (block #1=#:error-return
+  (multiple-value-call #'(lambda (\i{varN-1} \i{varN-2} ...) . \i{bodyN})
+     (block #2=#:normal-return
+       (return-from #1#
+         (handler-case (return-from #2# form)
+           (\i{type1} (\i{var1}) . \i{body1}) ...)))))
+\endcode
+
+\endissue{DECLS-AND-DOC}
+
+\endcom
+
+%%% ========== IGNORE-ERRORS
+\begincom{ignore-errors}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues ignore-errors 
+		  {\starparam{form}}
+		  {\starparam{result}}
+
+\label Arguments and Values::
+
+\param{forms}---an \term{implicit progn}.
+ 
+\param{results}---In the normal situation,
+		  the \term{values} of the \term{forms} are returned;
+		  in the exceptional situation,
+		  two values are returned: \nil\ and the \term{condition}.
+
+\label Description::
+
+\macref{ignore-errors} is used to prevent \term{conditions} \oftype{error}
+from causing entry into the debugger.
+
+Specifically, \macref{ignore-errors} \term{executes} \term{forms}
+in a \term{dynamic environment} where a \term{handler} for 
+\term{conditions} \oftype{error} has been established;
+if invoked, it \term{handles} such \term{conditions} by
+returning two \term{values}, \nil\ and the \term{condition} that was \term{signaled},
+from the \macref{ignore-errors} \term{form}.
+
+If a \term{normal return} from the \term{forms} occurs, 
+any \term{values} returned are returned by \macref{ignore-errors}.
+
+\label Examples::
+
+\code
+ (defun load-init-file (program)
+   (let ((win nil))
+     (ignore-errors ;if this fails, don't enter debugger
+       (load (merge-pathnames (make-pathname :name program :type :lisp)
+                              (user-homedir-pathname)))
+       (setq win t))
+     (unless win (format t "~&Init file failed to load.~%"))
+     win))
+ 
+ (load-init-file "no-such-program")
+\OUT Init file failed to load.
+NIL
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{handler-case}, {\secref\ConditionSystemConcepts}
+
+\label Notes::
+
+\code
+ (ignore-errors . \i{forms})
+\endcode
+ 
+   is equivalent to:
+ 
+\code
+ (handler-case (progn . \i{forms})
+   (error (condition) (values nil condition)))
+\endcode
+
+Because the second return value is a \term{condition}
+in the exceptional case, it is common (but not required) to arrange
+for the second return value in the normal case to be missing or \nil\ so
+that the two situations can be distinguished.
+ 
+\endcom
+
+%-------------------- Condition Type Definition --------------------
+
+%%% ========== DEFINE-CONDITION
+\begincom{define-condition}\ftype{Macro}
+
+\issue{DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY}
+
+\editornote{KMP: This syntax stuff is still very confused and needs lots of work.}
+
+\label Syntax::
+
+%!!! Consider renaming "parent-type" to "supertype".
+\DefmacWithValuesNewline define-condition
+		  {name \paren{\starparam{parent-type}}
+	                \paren{\stardown{slot-spec}}
+                        \starparam{option}}
+		  {name}
+
+\auxbnf{slot-spec}{slot-name | \paren{slot-name \down{slot-option}}}
+\auxbnf{slot-option}{\begininterleave
+		     \star{\curly{\kwd{reader}     \term{symbol}}}         | \CR
+		     \star{\curly{\kwd{writer}     \down{function-name}}}  | \CR
+		     \star{\curly{\kwd{accessor}   \term{symbol}}}         | \CR
+		           \curly{\kwd{allocation} \down{allocation-type}} | \CR
+		     \star{\curly{\kwd{initarg}    \term{symbol}}}         | \CR
+                           \curly{\kwd{initform}   \term{form}}            | \CR
+		           \curly{\kwd{type}       \param{type-specifier}} 
+		     \endinterleave}
+\auxbnf{option}{\begininterleave
+		\paren{\kwd{default-initargs} \f{.} \param{initarg-list}} | \CR
+		\paren{\kwd{documentation} \term{string}} | \CR
+		\paren{\kwd{report}        \i{report-name}} \endinterleave}
+\auxbnf{function-name}{\curly{\term{symbol} | {\tt (setf \term{symbol})}}}
+\auxbnf{allocation-type}{\kwd{instance} | \kwd{class}}
+\auxbnf{report-name}{\term{string} | \term{symbol} | \term{lambda expression}}
+
+\label Arguments and Values::
+
+\param{name}---a \term{symbol}.
+
+%% Reworded per Barmar #9, First Public Review.
+\param{parent-type}---a \term{symbol} naming a \term{condition} \term{type}.
+  If no \param{parent-types} are supplied,
+  the \param{parent-types} default to \f{(condition)}.
+                     
+\param{default-initargs}---a \term{list} of \term{keyword/value pairs}.
+
+\editornote{KMP: This is all mixed up as to which is a slot option and which is
+		 a main option.  I'll sort that out.  Also, some of this is implied
+		 by the bnf and needn't be stated explicitly.}%!!!
+
+\issue{CLOS-CONDITIONS:INTEGRATE}
+
+\param{Slot-spec} -- the \term{name} of a \term{slot} or a \term{list}
+consisting of the \param{slot-name} followed by zero or more \param{slot-options}.
+ 
+\param{Slot-name} -- a slot name (a \term{symbol}), 
+the \term{list} of a slot name, or the 
+\term{list} of slot name/slot form pairs.
+ 
+\param{Option} -- Any of the following:
+ 
+\beginlist
+ 
+\itemitem{\kwd{reader}}
+            
+\kwd{reader} can be supplied more than once for a given \term{slot} 
+and cannot be \nil.
+ 
+\itemitem{\kwd{writer}}
+          
+\kwd{writer} can be supplied more than once for a given \term{slot}
+and must name a \term{generic function}.
+ 
+\itemitem{\kwd{accessor}}
+ 
+\kwd{accessor} can be supplied more than once for a given \term{slot}
+and cannot be \nil.
+ 
+\itemitem{\kwd{allocation}}
+ 
+\kwd{allocation} can be supplied once at most for a given \term{slot}.
+The default if \kwd{allocation} is not supplied is \kwd{instance}.
+ 
+\itemitem{\kwd{initarg}} 
+                                                           
+\kwd{initarg} can be supplied more than once for a given \term{slot}.  
+ 
+\itemitem{\kwd{initform}}  
+     
+\kwd{initform} can be supplied once at most for a given \term{slot}.  
+ 
+\itemitem{\kwd{type}} 
+ 
+\kwd{type} can be supplied once at most for a given \term{slot}. 
+ 
+\itemitem{\kwd{documentation}} 
+ 
+\kwd{documentation} can be supplied once at most for a given \term{slot}. 
+
+\itemitem{\kwd{report}}
+
+\kwd{report} can be supplied once at most.
+
+% Removed:
+%  \itemitem{\kwd{conc-name}} ...
+%  \itemitem{\kwd{documentation}} ...
+\endlist
+\endissue{CLOS-CONDITIONS:INTEGRATE}
+
+\label Description::
+
+%!!! Barrett: Some of this stuff
+\macref{define-condition} defines a new condition type called \param{name}, 
+which is a \term{subtype} of 
+\issue{CLOS-CONDITIONS:INTEGRATE}
+the \term{type} or \term{types} named by
+  \param{parent-type}.  
+Each \param{parent-type} argument specifies a direct \term{supertype}
+of the new \term{condition}. The new \term{condition}
+inherits \term{slots} and \term{methods} from each of its direct
+\term{supertypes}, and so on.
+\endissue{CLOS-CONDITIONS:INTEGRATE}
+%% Redundant. -kmp 3-Sep-91
+% \term{Objects} of this \term{condition} type have all of the 
+% indicated \param{slots}, plus
+%   any additional slots that would be available in \term{objects}
+% of type \param{parent-type}.
+
+  If a slot name/slot form pair is supplied,
+the slot form is a \term{form} that 
+can be evaluated by \funref{make-condition} to
+  produce a default value when an explicit value is not provided.  If no 
+slot form
+is supplied, the contents of the \param{slot} 
+is initialized in an 
+  \term{implementation-dependent} way.  
+
+  If the \term{type} being defined and some other 
+\term{type} from which it inherits
+  have a slot by the same name, only one slot is allocated in the
+  \term{condition}, 
+but the supplied slot form overrides any slot form
+  that might otherwise have been inherited from a \param{parent-type}.  If no 
+slot form is supplied, the inherited slot form (if any) is still visible.
+
+%% This looks suspicious to me. -kmp 14-May-91
+%  Barrett agrees. -kmp 3-Sep-91
+% Once the \term{condition} is defined,
+% \funref{make-condition} accepts keywords (from \thepackage{keyword}) with the
+% \term{name} of any of the designated \param{slots},
+% and will initialize the corresponding \param{slots} in \term{conditions} it creates.
+
+Accessors are created according to the same rules as used by 
+%\macref{defstruct}.
+\macref{defclass}.
+
+A description of \param{slot-options} follows:
+
+\issue{CLOS-CONDITIONS:INTEGRATE}
+
+%!!! Isn't there a way of contracting this?
+
+\beginlist
+   
+\itemitem{\kwd{reader}}
+
+The \kwd{reader} slot option specifies that an \term{unqualified method} is
+to be defined on the \term{generic function} named by the argument
+to \kwd{reader} to read the value of the given \term{slot}.
+ 
+% Removed:
+% \itemitem{\kwd{writer}} 
+% \itemitem{\kwd{accessor}} 
+% \itemitem{\kwd{allocation}} 
+
+\itemitem{\bull} The \kwd{initform} slot option is used to provide a default
+initial value form to be used in the initialization of the \term{slot}.  This
+\term{form} is evaluated every time it is used to initialize the 
+\term{slot}.  The
+\term{lexical environment} 
+in which this \term{form} is evaluated is the lexical
+\term{environment} in which the \macref{define-condition} 
+form was evaluated.
+Note that the \term{lexical environment} refers both to variables and to
+\term{functions}.  
+For \term{local slots}, the \term{dynamic environment} is the dynamic
+\term{environment} 
+in which \funref{make-condition} was called; for 
+\term{shared slots}, the \term{dynamic environment} 
+is the \term{dynamic environment} in which the
+\macref{define-condition} form was evaluated.  
+%\Seesection\ObjectCreationAndInit.
+ 
+\reviewer{Barmar: Issue CLOS-CONDITIONS doesn't say this.}
+No implementation is permitted to extend the syntax of \macref{define-condition}
+to allow \f{(\param{slot-name} \param{form})} as an abbreviation for
+\f{(\param{slot-name} :initform \param{form})}.
+ 
+\itemitem{\kwd{initarg}}
+
+The \kwd{initarg} slot option declares an initialization
+argument named by its \term{symbol} argument
+and specifies that this
+initialization argument initializes the given \term{slot}.  If the
+initialization argument has a value in the call to 
+\funref{initialize-instance}, the value is stored into the given \term{slot},
+and the slot's \kwd{initform} slot option, if any, is not
+evaluated.  If none of the initialization arguments specified for a
+given \term{slot} has a value, the \term{slot} is initialized according to the
+\kwd{initform} slot option, if specified.  
+ 
+\itemitem{\kwd{type}}
+
+The \kwd{type} slot option specifies that the contents of the
+\term{slot} is always of the specified \term{type}.  It effectively
+declares the result type of the reader generic function when applied
+to an \term{object} of this \term{condition} type.  
+The consequences of attempting to store in a
+\term{slot} a value that 
+does not satisfy the type of the \term{slot} is undefined.
+%The \kwd{type} slot option is further discussed in \secref\SlotInheritance.
+ 
+\itemitem{\kwd{default-initargs}}
+
+\editornote{KMP: This is an option, not a slot option.}%!!!
+
+This option is treated the same as it would be \macref{defclass}.
+
+\itemitem{\kwd{documentation}}
+
+\editornote{KMP: This is both an option and a slot option.}%!!!
+
+The \kwd{documentation} slot option provides a \term{documentation string}
+for the \term{slot}.
+
+%Removed:
+%  \itemitem{\kwd{documentation}} ...
+%  \itemitem{\kwd{conc-name}} ...
+\endissue{CLOS-CONDITIONS:INTEGRATE}
+\itemitem{\kwd{report}}
+
+\editornote{KMP: This is an option, not a slot option.}%!!!
+
+\term{Condition} reporting is mediated through the \funref{print-object}
+method for the \term{condition} type in question, with \varref{*print-escape*}
+always being \nil. Specifying \f{(:report \param{report-name})} 
+in the definition of a condition type \f{C} is equivalent to:
+
+\code
+ (defmethod print-object ((x c) stream)
+   (if *print-escape* (call-next-method) (\param{report-name} x stream)))
+\endcode
+ 
+     If the value supplied by the argument to \kwd{report} (\param{report-name})
+is a \term{symbol} or a \term{lambda expression}, 
+it must be acceptable to 
+     \specref{function}. \f{(function \param{report-name})} 
+is evaluated
+     in the current \term{lexical environment}.  
+It should return a \term{function} 
+of two
+     arguments, a \term{condition} and a \term{stream}, 
+that prints on the \term{stream} a
+     description of the \term{condition}. 
+ This \term{function} is called whenever the
+     \term{condition} is printed while \varref{*print-escape*} is \nil.
+
+If \param{report-name} is a \term{string}, it is a shorthand for 
+
+\code
+ (lambda (condition stream)
+   (declare (ignore condition))
+   (write-string \param{report-name} stream))
+\endcode
+
+This option is processed after the new \term{condition} type has been defined,
+so use of the \param{slot} accessors within the \kwd{report} function is permitted.
+If this option is not supplied, information about how to report this
+type of \term{condition} is inherited from the \param{parent-type}.
+
+\endlist
+
+% !!! Barmar: This is redundant because CLOS already says this.
+%     KMP: I think that until the connection between conditions and standard-class is
+%          clearer, it doesn't hurt to say it redundantly.
+The consequences are unspecifed if an attempt is made to \term{read} a 
+\param{slot} that has not been explicitly initialized and that has not 
+been given a default value.
+
+The consequences are unspecified if an attempt is made to assign the
+\param{slots} by using \macref{setf}.
+
+\issue{COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY}
+% added qualification about top-level-ness  --sjl 5 Mar 92
+If a \macref{define-condition} \term{form} appears as a \term{top level form},
+the \term{compiler} must make \param{name} recognizable as a valid \term{type} name,
+and it must be possible to reference the \term{condition} \term{type} as the
+\param{parent-type} of another \term{condition} \term{type} in a subsequent
+\macref{define-condition} \term{form} in the \term{file} being compiled.
+\endissue{COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY}
+
+\label Examples::
+
+The following form defines a condition of \term{type} 
+\f{peg/hole-mismatch} which inherits from a condition type
+called \f{blocks-world-error}:
+
+\code
+(define-condition peg/hole-mismatch 
+                  (blocks-world-error)
+                  ((peg-shape  :initarg :peg-shape
+                               :reader peg/hole-mismatch-peg-shape)
+                   (hole-shape :initarg :hole-shape
+                               :reader peg/hole-mismatch-hole-shape))
+  (:report (lambda (condition stream)
+             (format stream "A ~A peg cannot go in a ~A hole."
+                     (peg/hole-mismatch-peg-shape  condition)
+                     (peg/hole-mismatch-hole-shape condition)))))
+\endcode
+
+The new type has slots \f{peg-shape} and \f{hole-shape}, 
+so \funref{make-condition} accepts \f{:peg-shape} and \f{:hole-shape} keywords.  
+The \term{readers} \f{peg/hole-mismatch-peg-shape} and \f{peg/hole-mismatch-hole-shape} 
+apply to objects of this type, as illustrated in the \kwd{report} information.
+
+The following form defines a \term{condition} \term{type} named \f{machine-error}
+which inherits from \typeref{error}: 
+
+\code
+(define-condition machine-error 
+                  (error)
+                  ((machine-name :initarg :machine-name
+                                 :reader machine-error-machine-name))
+  (:report (lambda (condition stream)
+             (format stream "There is a problem with ~A."
+                     (machine-error-machine-name condition)))))
+\endcode
+
+Building on this definition, a new error condition can be defined which
+is a subtype of \f{machine-error} for use when machines are not available: 
+
+\code
+(define-condition machine-not-available-error (machine-error) ()
+  (:report (lambda (condition stream)
+             (format stream "The machine ~A is not available."
+                     (machine-error-machine-name condition)))))
+\endcode
+
+This defines a still more specific condition, built upon 
+\f{machine-not-available-error}, which provides a slot initialization form
+for \f{machine-name} but which does not provide any new slots or report
+information.  It just gives the \f{machine-name} slot a default initialization:
+
+\code
+(define-condition my-favorite-machine-not-available-error
+                  (machine-not-available-error)
+  ((machine-name :initform "mc.lcs.mit.edu")))
+\endcode
+
+Note that since no \kwd{report} clause was given, the information 
+inherited from \f{machine-not-available-error} is used to
+report this type of condition.
+
+\code
+ (define-condition ate-too-much (error) 
+     ((person :initarg :person :reader ate-too-much-person)
+      (weight :initarg :weight :reader ate-too-much-weight)
+      (kind-of-food :initarg :kind-of-food
+                    :reader :ate-too-much-kind-of-food)))
+\EV ATE-TOO-MUCH
+ (define-condition ate-too-much-ice-cream (ate-too-much)
+   ((kind-of-food :initform 'ice-cream)
+    (flavor       :initarg :flavor
+                  :reader ate-too-much-ice-cream-flavor
+                  :initform 'vanilla ))
+   (:report (lambda (condition stream)
+              (format stream "~A ate too much ~A ice-cream"
+                      (ate-too-much-person condition)
+                      (ate-too-much-ice-cream-flavor condition)))))
+\EV ATE-TOO-MUCH-ICE-CREAM
+ (make-condition 'ate-too-much-ice-cream
+                 :person 'fred
+                 :weight 300
+                 :flavor 'chocolate)
+\EV #<ATE-TOO-MUCH-ICE-CREAM 32236101>
+ (format t "~A" *)
+\OUT FRED ate too much CHOCOLATE ice-cream
+\EV NIL
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{make-condition}, \macref{defclass}, {\secref\ConditionSystemConcepts}
+
+%% Per X3J13. -kmp 05-Oct-93
+\label Notes:\None.
+
+\endissue{DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS+EMPHASIZE-READ-ONLY}
+
+\endcom
+
+%-------------------- Condition Instantiation --------------------
+
+%%% ========== MAKE-CONDITION
+\begincom{make-condition}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues make-condition {type {\rest} slot-initializations} {condition}
+
+\label Arguments and Values::
+
+%Barmar: a condition type or condition type name ?
+%Barrett worried about the same thing.  I think the intent was that it be a subtype of
+%condition, so I've required that explicitly. -kmp 3-Sep-91
+\param{type}---a \term{type specifier} (for a \term{subtype} of \typeref{condition}).
+
+\param{slot-initializations}---an \term{initialization argument list}.
+
+\param{condition}---a \term{condition}.
+
+\label Description::
+
+Constructs and returns a \term{condition} of type \param{type} 
+using \param{slot-initializations} for the initial values of the slots.  
+The newly created \term{condition} is returned.
+
+\label Examples::
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\code
+ (defvar *oops-count* 0)
+
+ (setq a (make-condition 'simple-error
+                         :format-control "This is your ~:R error."
+                         :format-arguments (list (incf *oops-count*))))
+\EV #<SIMPLE-ERROR 32245104>
+ 
+ (format t "~&~A~%" a)
+\OUT This is your first error.
+\EV NIL
+ 
+ (error a)
+\OUT Error: This is your first error.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Return to Lisp Toplevel.
+\OUT Debug> 
+\endcode
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\label Side Effects:\None.
+
+%% Sandra thinks this is excessive.
+%Creates a \term{condition}.
+
+\label Affected By::
+
+The set of defined \term{condition} \term{types}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{define-condition}, {\secref\ConditionSystemConcepts}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Restarts --------------------
+
+\begincom{restart}\ftype{System Class}
+
+\label Class Precedence List::
+\typeref{restart},
+\typeref{t}
+
+\label Description::
+
+An \term{object} \oftype{restart} represents a \term{function} that can be
+called to perform some form of recovery action, usually a transfer of control 
+to an outer point in the running program.
+
+An \term{implementation} is free to implement a \term{restart} in whatever 
+manner is most convenient; a \term{restart} has only \term{dynamic extent}
+relative to the scope of the binding \term{form} which \term{establishes} it.
+
+\endcom%{restart}\ftype{System Class}
+
+%%% ========== COMPUTE-RESTARTS
+\begincom{compute-restarts}\ftype{Function}
+
+\label Syntax::
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\DefunWithValues compute-restarts {{\opt} condition} {restarts}
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\label Arguments and Values::
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\param{condition}---a \term{condition} \term{object}, or \nil.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\param{restarts}---a \term{list} of \term{restarts}.
+
+\label Description::
+
+\funref{compute-restarts} uses the dynamic state of the program to compute 
+a \term{list} of the \term{restarts} which are currently active.
+
+The resulting \term{list} is ordered so that the innermost
+(more-recently established) restarts are nearer the head of the \term{list}.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+When \param{condition} is \term{non-nil}, only those \term{restarts}
+are considered that are either explicitly associated with that \param{condition},
+or not associated with any \term{condition}; that is, the excluded \term{restarts} 
+are those that are associated with a non-empty set of \term{conditions} of 
+which the given \param{condition} is not an \term{element}.
+If \param{condition} is \nil, all \term{restarts} are considered.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\funref{compute-restarts} returns all 
+%"valid" -> "applicable" per Barrett
+\term{applicable restarts}, 
+including anonymous ones, even if some of them have the same name as 
+others and would therefore not be found by \funref{find-restart} 
+when given a \term{symbol} argument.
+
+Implementations are permitted, but not required, to return \term{distinct}
+\term{lists} from repeated calls to \funref{compute-restarts} while in
+the same dynamic environment.  
+The consequences are undefined if the \term{list} returned by
+\funref{compute-restarts} is every modified.
+
+\label Examples::
+
+\code
+ ;; One possible way in which an interactive debugger might present
+ ;; restarts to the user.
+ (defun invoke-a-restart ()
+   (let ((restarts (compute-restarts)))
+     (do ((i 0 (+ i 1)) (r restarts (cdr r))) ((null r))
+       (format t "~&~D: ~A~%" i (car r)))
+     (let ((n nil) (k (length restarts)))
+       (loop (when (and (typep n 'integer) (>= n 0) (< n k))
+               (return t))
+             (format t "~&Option: ")
+             (setq n (read))
+             (fresh-line))
+       (invoke-restart-interactively (nth n restarts)))))
+
+ (restart-case (invoke-a-restart)
+   (one () 1)
+   (two () 2)
+   (nil () :report "Who knows?" 'anonymous)
+   (one () 'I)
+   (two () 'II))
+\OUT 0: ONE
+\OUT 1: TWO
+\OUT 2: Who knows?
+\OUT 3: ONE
+\OUT 4: TWO
+\OUT 5: Return to Lisp Toplevel.
+\OUT Option: \IN{4}
+\EV II
+ 
+ ;; Note that in addition to user-defined restart points, COMPUTE-RESTARTS
+ ;; also returns information about any system-supplied restarts, such as
+ ;; the "Return to Lisp Toplevel" restart offered above.
+ 
+\endcode
+ 
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+Existing restarts.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{find-restart},
+\funref{invoke-restart},
+\funref{restart-bind}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== FIND-RESTART
+\begincom{find-restart}\ftype{Function}
+
+\label Syntax::
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\Defun find-restart {identifier {\opt} condition} {restart}
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\label Arguments and Values::
+
+\param{identifier}---a \term{non-nil} \term{symbol}, or a \term{restart}.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\param{condition}---a \term{condition} \term{object}, or \nil.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\param{restart}---a \term{restart} or \nil.
+
+\label Description::
+
+\funref{find-restart} searches for a particular \term{restart} in the 
+current \term{dynamic environment}.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+When \param{condition} is \term{non-nil}, only those \term{restarts}
+are considered that are either explicitly associated with that \param{condition},
+or not associated with any \term{condition}; that is, the excluded \term{restarts} 
+are those that are associated with a non-empty set of \term{conditions} of 
+which the given \param{condition} is not an \term{element}.
+If \param{condition} is \nil, all \term{restarts} are considered.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+If \param{identifier} is a \term{symbol}, then the innermost 
+(most recently established) \term{applicable restart} with that \term{name} is returned.
+\nil\ is returned if no such restart is found.
+
+If \param{identifier} is a currently active restart, then it is returned.
+Otherwise, \nil\ is returned.
+
+\label Examples::
+
+\code
+ (restart-case
+     (let ((r (find-restart 'my-restart)))
+       (format t "~S is named ~S" r (restart-name r)))
+   (my-restart () nil))
+\OUT #<RESTART 32307325> is named MY-RESTART
+\EV NIL
+ (find-restart 'my-restart)
+\EV NIL
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+Existing restarts.
+
+\macref{restart-case}, \macref{restart-bind}, \macref{with-condition-restarts}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{compute-restarts}
+
+\label Notes::
+
+\code
+ (find-restart \param{identifier})
+ \EQ (find \param{identifier} (compute-restarts) :key :restart-name)
+\endcode
+
+Although anonymous restarts have a name of \nil,
+the consequences are unspecified if \nil\ is given as an \param{identifier}.  
+Occasionally, programmers lament that \nil\ is not permissible as an
+\param{identifier} argument.  In most such cases, \funref{compute-restarts}
+can probably be used to simulate the desired effect.
+
+\endcom
+
+%%% ========== INVOKE-RESTART
+\begincom{invoke-restart}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues invoke-restart
+		 {restart {\rest} arguments}
+		 {\starparam{result}}
+
+\label Arguments and Values::
+
+\param{restart}---a \term{restart designator}.
+
+\param{argument}---an \term{object}.
+
+\param{results}---the \term{values} returned by the \term{function}
+		   associated with \param{restart}, if that \term{function} returns.
+
+\label Description::
+
+Calls the \term{function} associated with \param{restart},
+passing \param{arguments} to it.  
+\param{Restart} must be valid in the current \term{dynamic environment}.  
+
+\label Examples::
+\code
+ (defun add3 (x) (check-type x number) (+ x 3))
+ 
+ (foo 'seven)
+\OUT Error: The value SEVEN was not of type NUMBER.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Specify a different value to use.
+\OUT  2: Return to Lisp Toplevel.
+\OUT Debug> \IN{(invoke-restart 'store-value 7)}
+\EV 10
+\endcode
+
+\label Side Effects::
+
+%!!! Barmar: This is true whenever calling random functions.
+A non-local transfer of control might be done by the restart.
+
+\label Affected By::
+
+Existing restarts.
+
+\label Exceptional Situations::
+
+If \param{restart} is not valid, an error \oftype{control-error} is signaled.
+
+\label See Also::
+
+\funref{find-restart},
+\macref{restart-bind},
+\macref{restart-case},
+\funref{invoke-restart-interactively}
+
+\label Notes::
+
+The most common use for \funref{invoke-restart} is in a \term{handler}.
+It might be used explicitly, or implicitly through \funref{invoke-restart-interactively}
+or a \term{restart function}.
+
+\term{Restart functions} call \funref{invoke-restart}, not vice versa.  That is,
+\term{invoke-restart} provides primitive functionality, and \term{restart functions}
+are non-essential ``syntactic sugar.''
+
+\endcom
+
+%%% ========== INVOKE-RESTART-INTERACTIVELY
+\begincom{invoke-restart-interactively}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues invoke-restart-interactively {restart} {\starparam{result}}
+
+\label Arguments and Values::
+
+\param{restart}---a \term{restart designator}.
+
+\param{results}---the \term{values} returned by the \term{function} 
+		   associated with \param{restart}, if that \term{function} returns.
+
+\label Description::
+
+\funref{invoke-restart-interactively} calls the \term{function} associated
+with \param{restart}, prompting for any necessary arguments. 
+If \param{restart} is a name, it must be valid in the current \term{dynamic environment}.  
+
+  \funref{invoke-restart-interactively} 
+prompts for arguments by executing
+  the code provided in the \kwd{interactive} keyword to 
+\macref{restart-case} or 
+  \kwd{interactive-function} keyword to \macref{restart-bind}.
+
+%!!! Barrett: Make consistent with wrong # of args errors.
+If no such options have been supplied in the corresponding
+\macref{restart-bind} or \macref{restart-case}, 
+then the consequences are undefined if the \param{restart} takes
+  required arguments.  If the arguments are optional, an argument list of
+  \nil\ is used.
+
+  Once the arguments have been determined, 
+\funref{invoke-restart-interactively}
+  executes the following:
+
+\code
+ (apply #'invoke-restart \i{restart} \i{arguments})
+\endcode
+ 
+
+\label Examples::
+
+\code
+ (defun add3 (x) (check-type x number) (+ x 3))
+ 
+ (add3 'seven)
+\OUT Error: The value SEVEN was not of type NUMBER.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Specify a different value to use.
+\OUT  2: Return to Lisp Toplevel.
+\OUT Debug> \IN{(invoke-restart-interactively 'store-value)}
+\OUT Type a form to evaluate and use: \IN{7}
+\EV 10
+\endcode
+ 
+\label Side Effects::
+
+If prompting for arguments is necesary,
+some typeout may occur (on \term{query I/O}).
+ 
+%!!! Barmar: This is true whenever calling random functions.
+A non-local transfer of control might be done by the restart.
+
+\label Affected By::
+
+\varref{*query-io*}, active \term{restarts}
+
+\label Exceptional Situations::
+
+If \param{restart} is not valid, an error \oftype{control-error}
+is signaled.
+
+\label See Also::
+
+\funref{find-restart},
+\funref{invoke-restart},
+\macref{restart-case},
+\macref{restart-bind}
+
+\label Notes::
+
+\funref{invoke-restart-interactively} is used internally by the debugger
+and may also be useful in implementing other portable, interactive debugging 
+tools.
+
+\endcom
+
+%%% ========== RESTART-BIND
+\begincom{restart-bind}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValuesNewline restart-bind 
+		  {\paren{\curly{\paren{name function
+				        \stardown{key-val-pair}}}}
+		   \starparam{form}}
+		  {\starparam{result}}
+
+%!!! Barmar: Somehow indicate that each may be supplied at most once.
+\auxbnf{key-val-pair}{\kwd{interactive-function} {interactive-function} | \CR
+		      \kwd{report-function} {report-function}           | \CR
+		      \kwd{test-function} {test-function}}
+
+\label Arguments and Values::
+
+\param{name}---a \term{symbol}; \noeval.
+
+\param{function}---a \term{form}; \eval.
+
+\param{forms}---an \term{implicit progn}.
+
+\param{interactive-function}---a \term{form}; \eval.
+
+\param{report-function}---a \term{form}; \eval.
+
+\param{test-function}---a \term{form}; \eval.
+
+\param{results}---the \term{values} returned by the \term{forms}.
+
+\label Description::
+
+\macref{restart-bind} executes the body of \param{forms} 
+in a \term{dynamic environment} where \term{restarts} with the given \param{names} are in effect.
+ 
+If a \param{name} is \nil, it indicates an anonymous restart;
+if a \param{name} is a \term{non-nil} \term{symbol}, it indicates a named restart.
+ 
+The \param{function}, \param{interactive-function}, and \param{report-function}
+are unconditionally evaluated in the current lexical and dynamic environment
+prior to evaluation of the body. Each of these \term{forms} must evaluate to
+a \term{function}.
+ 
+If \funref{invoke-restart} is done on that restart,
+the \term{function} which resulted from evaluating \param{function} 
+is called, in the \term{dynamic environment} of the \funref{invoke-restart},
+with the \term{arguments} given to \funref{invoke-restart}. 
+The \term{function} may either perform a non-local transfer of control or may return normally.
+ 
+If the restart is invoked interactively from the debugger 
+(using \funref{invoke-restart-interactively}), 
+the arguments are defaulted by calling the \term{function} 
+which resulted from evaluating \param{interactive-function}.
+That \term{function} may optionally prompt interactively on \term{query I/O}, 
+and should return a \term{list} of arguments to be used by
+\funref{invoke-restart-interactively} when invoking the restart. 
+ 
+If a restart is invoked interactively but no \param{interactive-function} is used,
+then an argument list of \nil\ is used. In that case, the \term{function}
+must be compatible with an empty argument list.
+ 
+If the restart is presented interactively (\eg by the debugger),
+the presentation is done by calling the \term{function} which resulted
+from evaluating \param{report-function}.
+This \term{function} must be a \term{function} of one argument, a \term{stream}. 
+It is expected to print a description of the action that the restart takes
+to that \term{stream}. 
+This \term{function} is called any time the restart is printed 
+while \varref{*print-escape*} is \nil.
+ 
+In the case of interactive invocation, 
+the result is dependent on the value of \kwd{interactive-function}
+as follows.
+
+\beginlist
+\itemitem{\kwd{interactive-function}}
+
+  \param{Value} is evaluated in the current lexical environment and
+  should return a \term{function} of no arguments which constructs a 
+  \term{list} of arguments to be used by \funref{invoke-restart-interactively} 
+  when invoking this restart.  The \term{function} may prompt interactively
+  using \term{query I/O} if necessary.
+
+\itemitem{\kwd{report-function}}
+
+  \param{Value} is evaluated in the current lexical environment and
+  should return a \term{function} of one argument, a \term{stream}, which
+  prints on the \term{stream} a summary of the action that this restart
+  takes.  This \term{function} is called whenever the restart is
+  reported (printed while \varref{*print-escape*} is \nil).
+% This next was added for Barmar. -kmp 1-Sep-91
+  If no \kwd{report-function} option is provided, the manner in which the
+  \term{restart} is reported is \term{implementation-dependent}.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\itemitem{\kwd{test-function}}
+
+  \param{Value} is evaluated in the current lexical environment and
+  should return a \term{function} of one argument, a \term{condition}, which
+  returns \term{true} if the restart is to be considered visible.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\endlist
+
+% \label Examples::
+% 
+%\code
+% (defun choose-an-interactive-restart ()
+%   (restart-bind
+%       ((optional-value
+%          #'(lambda (&optional (x 'default)) x)
+%          :report-function #'(lambda (stream)
+%                               (format stream "Return an optional value")))\kern-3pt
+%        (return-value
+%          #'identity
+%          :report-function #'(lambda (stream)
+%                               (format stream "Return the given value"))
+%          :interactive-function #'(lambda ()
+%                                    (format t "Enter a value to return: ")
+%                                  (list (eval (read))))))
+%     (let ((cases (compute-restarts))
+%           (*print-structure* t)
+%           (index -1))
+%       (dolist (case cases)
+%         (format t "~&~D: ~A~%" (incf index) case))
+%       (format t "Please enter restart to invoke: ")
+%       (invoke-restart-interactively (nth (eval (read)) cases)))))
+%\EV\ CHOOSE-AN-INTERACTIVE-RESTART
+% (choose-an-interactive-restart)
+%\EV\ 0: Return an optional value
+%1: Return the given value
+%2: Abort to Lisp Top Level
+%Please enter restart to invoke: 0
+%DEFAULT
+% (choose-an-interactive-restart)
+%\EV\ 0: Return an optional value
+%1: Return the given value
+%2: Abort to Lisp Top Level
+%Please enter restart to invoke: 1
+%Enter a value to return: t
+%T
+%\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+\varref{*query-io*}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{restart-case}, \macref{with-simple-restart}
+
+\label Notes::
+
+\macref{restart-bind} is primarily intended to be used to implement
+\macref{restart-case} and  might be useful in implementing other
+macros. Programmers who are uncertain about whether to use \macref{restart-case}
+or \macref{restart-bind} should prefer \macref{restart-case} for the cases where
+it is powerful enough, using \macref{restart-bind} only in cases where its full
+generality is really needed.
+ 
+\endcom
+
+%%% ========== RESTART-CASE
+\begincom{restart-case}\ftype{Macro}
+
+\issue{DECLS-AND-DOC}
+
+\label Syntax::
+
+\DefmacWithValues restart-case 
+		  {restartable-form {\curly{\down{clause}}}}
+		  {\starparam{result}}
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\auxbnf{clause}{\lparen case-name lambda-list			       \CR
+	        \ \interleave{\kwd{interactive} interactive-expression |
+		      	      \kwd{report} report-expression           |
+			      \kwd{test} test-expression}              \CR
+		\ \starparam{declaration} \starparam{form}\rparen}
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\label Arguments and Values::
+
+\param{restartable-form}---a \term{form}.
+
+\param{case-name}---a \term{symbol} or \nil.
+
+\param{lambda-list}---an \term{ordinary lambda list}.
+
+\param{interactive-expression}---a \term{symbol} or a \term{lambda expression}.
+
+\param{report-expression}---a \term{string},
+			     a \term{symbol},
+			     or a \term{lambda expression}.                                 
+
+\param{test-expression}---a \term{symbol} or a \term{lambda expression}.
+
+\param{declaration}---a \misc{declare} \term{expression}; \noeval.
+
+\param{form}---a \term{form}.
+
+\param{results}---the \term{values} resulting from the \term{evaluation}
+		   of \param{restartable-form}, 
+		  or the \term{values} returned by the last \param{form}
+		   executed in a chosen \term{clause},
+		  or \nil.
+
+\label Description::
+
+\macref{restart-case} evaluates \param{restartable-form} in a \term{dynamic environment}
+where the clauses have special meanings as points to which control may be transferred.  
+If \param{restartable-form} finishes executing and returns any values, 
+all values returned are returned by \macref{restart-case} and 
+processing has completed. While \param{restartable-form} is executing, any code may
+  transfer control to one of the clauses (see \funref{invoke-restart}).  
+If a transfer
+  occurs, the forms in the body of that clause is evaluated and any values
+  returned by the last such form are returned by 
+\macref{restart-case}.
+In this case, the 
+dynamic state is unwound appropriately (so that the restarts established
+around the \param{restartable-form} are no longer active) prior to execution of the
+clause.
+
+  If there are no \param{forms} 
+in a selected clause, \macref{restart-case} returns \nil.
+
+If \param{case-name} is a \term{symbol}, it names this restart.
+
+It is possible to have more than one clause use the same \param{case-name}.
+In this case, the first clause with that name is found by \funref{find-restart}.  
+The other clauses are accessible using \funref{compute-restarts}.
+
+Each \param{arglist} is an \term{ordinary lambda list} to be bound during the 
+execution of its corresponding \param{forms}.  These parameters are used 
+by the \macref{restart-case} clause to receive any necessary data from a call
+to \funref{invoke-restart}.
+
+By default, \funref{invoke-restart-interactively} passes no arguments and
+all arguments must be optional in order to accomodate interactive
+restarting.  However, the arguments need not be optional if the
+\kwd{interactive} 
+keyword has been used to inform \funref{invoke-restart-interactively}
+  about how to compute a proper argument list.
+
+\param{Keyword} options have the following meaning.
+\beginlist
+\itemitem{\kwd{interactive}}
+   
+The \param{value} supplied by \f{:interactive \param{value}}
+must be a suitable argument to \specref{function}. 
+\f{(function \param{value})} is evaluated in the current lexical
+    environment.  It should return a \term{function} of no arguments which 
+    returns arguments to be used by 
+\funref{invoke-restart-interactively} when it is invoked.
+\funref{invoke-restart-interactively} 
+is called in the dynamic
+    environment available prior to any restart attempt, and uses 
+\term{query I/O} for user interaction.
+
+    If a restart is invoked interactively but no \kwd{interactive} option
+    was supplied, the argument list used in the invocation is the empty
+    list.
+
+\itemitem{\kwd{report}}
+
+If the \param{value} supplied by \f{:report \param{value}}
+is a \term{lambda expression} or a \term{symbol}, it 
+must be acceptable to \specref{function}.
+\f{(function \param{value})} is evaluated in the current lexical
+environment.  It should return a \term{function} of one
+argument, a \term{stream}, which prints on the \term{stream} a 
+description of the restart.  This \term{function} is called 
+whenever the restart is printed while \varref{*print-escape*} is \nil.
+
+If \param{value} is a \term{string}, it is a shorthand for
+
+\code
+ (lambda (stream) (write-string value stream))
+\endcode
+
+    If a named restart is asked to report but no report information has been
+    supplied, the name of the restart is used in generating default report text.
+  
+    When \varref{*print-escape*} is \nil, the 
+printer uses the report information for
+    a restart.  For example, a debugger might announce the action of typing
+    a ``continue'' command by:
+
+\code
+ (format t "~&~S -- ~A~%" ':continue some-restart)
+\endcode
+    which might then display as something like:
+
+\code
+ :CONTINUE -- Return to command level
+\endcode
+
+The consequences are unspecified if an unnamed restart is specified
+but no \kwd{report} option is provided.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\itemitem{\kwd{test}}
+
+The \param{value} supplied by \f{:test \param{value}}
+must be a suitable argument to \specref{function}. 
+\f{(function \param{value})} is evaluated in the current lexical
+    environment.  It should return a \term{function} of one \term{argument}, the
+\term{condition}, that
+returns \term{true} if the restart is to be considered visible.
+
+The default for this option is equivalent to \f{(lambda (c) (declare (ignore c)) t)}.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\endlist
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+If the \param{restartable-form} is a \term{list} whose \term{car} is any of
+the \term{symbols} \funref{signal}, \funref{error}, \funref{cerror},
+or \funref{warn} (or is a \term{macro form} which macroexpands into such a
+\term{list}), then \macref{with-condition-restarts} is used implicitly
+to associate the indicated \term{restarts} with the \term{condition} to be
+signaled.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\label Examples::
+
+\code
+ (restart-case
+     (handler-bind ((error #'(lambda (c)
+                             (declare (ignore condition))
+                             (invoke-restart 'my-restart 7))))
+       (error "Foo."))
+   (my-restart (&optional v) v))
+\EV 7
+
+ (define-condition food-error (error) ())
+\EV FOOD-ERROR
+ (define-condition bad-tasting-sundae (food-error) 
+   ((ice-cream :initarg :ice-cream :reader bad-tasting-sundae-ice-cream)
+    (sauce :initarg :sauce :reader bad-tasting-sundae-sauce)
+    (topping :initarg :topping :reader bad-tasting-sundae-topping))
+   (:report (lambda (condition stream)
+              (format stream "Bad tasting sundae with ~S, ~S, and ~S"
+                      (bad-tasting-sundae-ice-cream condition)
+                      (bad-tasting-sundae-sauce condition)
+                      (bad-tasting-sundae-topping condition)))))
+\EV BAD-TASTING-SUNDAE
+ (defun all-start-with-same-letter (symbol1 symbol2 symbol3)
+   (let ((first-letter (char (symbol-name symbol1) 0)))
+     (and (eql first-letter (char (symbol-name symbol2) 0))
+          (eql first-letter (char (symbol-name symbol3) 0)))))
+\EV ALL-START-WITH-SAME-LETTER
+ (defun read-new-value ()
+   (format t "Enter a new value: ")
+   (multiple-value-list (eval (read))))
+\EV READ-NEW-VALUE\eject
+ (defun verify-or-fix-perfect-sundae (ice-cream sauce topping)
+   (do ()
+      ((all-start-with-same-letter ice-cream sauce topping))
+     (restart-case
+       (error 'bad-tasting-sundae
+              :ice-cream ice-cream
+              :sauce sauce
+              :topping topping)
+       (use-new-ice-cream (new-ice-cream)
+         :report "Use a new ice cream."
+         :interactive read-new-value  
+         (setq ice-cream new-ice-cream))
+       (use-new-sauce (new-sauce)
+         :report "Use a new sauce."
+         :interactive read-new-value
+         (setq sauce new-sauce))
+       (use-new-topping (new-topping)
+         :report "Use a new topping."
+         :interactive read-new-value
+         (setq topping new-topping))))
+   (values ice-cream sauce topping))
+\EV VERIFY-OR-FIX-PERFECT-SUNDAE
+ (verify-or-fix-perfect-sundae 'vanilla 'caramel 'cherry)
+\OUT Error: Bad tasting sundae with VANILLA, CARAMEL, and CHERRY.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Use a new ice cream.
+\OUT  2: Use a new sauce.
+\OUT  3: Use a new topping.
+\OUT  4: Return to Lisp Toplevel.
+\OUT Debug> \IN{:continue 1}
+\OUT Use a new ice cream.
+\OUT Enter a new ice cream: \IN{'chocolate}
+\EV CHOCOLATE, CARAMEL, CHERRY
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{restart-bind}, \macref{with-simple-restart}.
+
+\label Notes::
+
+\code
+ (restart-case \i{expression}
+    (\i{name1} \i{arglist1} ...\i{options1}... . \i{body1})
+    (\i{name2} \i{arglist2} ...\i{options2}... . \i{body2}))
+\endcode
+  is essentially equivalent to
+
+\code
+ (block #1=#:g0001
+   (let ((#2=#:g0002 nil))
+        (tagbody
+        (restart-bind ((name1 #'(lambda (&rest temp)
+                                (setq #2# temp)
+                                (go #3=#:g0003))
+                          ...\i{slightly-transformed-options1}...)
+                       (name2 #'(lambda (&rest temp)
+                                (setq #2# temp)
+                                (go #4=#:g0004))
+                          ...\i{slightly-transformed-options2}...))
+        (return-from #1# \i{expression}))
+          #3# (return-from #1#
+                  (apply #'(lambda \i{arglist1} . \i{body1}) #2#))
+          #4# (return-from #1#
+                  (apply #'(lambda \i{arglist2} . \i{body2}) #2#)))))
+\endcode
+
+Unnamed restarts are generally only useful interactively
+    and an interactive option which has no description is of little value.
+    Implementations are encouraged to warn if 
+an unnamed restart is used and no report information
+    is provided
+at compilation    time.  
+At runtime, this error might be noticed when entering
+      the debugger.  Since signaling an error would probably cause recursive
+      entry into the debugger (causing yet another recursive error, etc.) it is
+      suggested that the debugger print some indication of such problems when
+      they occur but not actually signal errors.
+  
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\code
+ (restart-case (signal fred)
+   (a ...)
+   (b ...))
+ \EQ
+ (restart-case
+     (with-condition-restarts fred 
+                              (list (find-restart 'a) 
+                                    (find-restart 'b))
+       (signal fred))
+   (a ...)
+   (b ...))
+\endcode
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\endissue{DECLS-AND-DOC}
+
+\endcom 
+
+%%% ========== RESTART-NAME
+\begincom{restart-name}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues restart-name {restart} {name}
+
+\label Arguments and Values:: 
+
+\param{restart}---a \term{restart}.
+
+\param{name}---a \term{symbol}.
+
+\label Description::
+
+Returns the name of the \param{restart},
+or \nil\ if the \param{restart} is not named.
+
+\label Examples::
+
+\code
+ (restart-case 
+     (loop for restart in (compute-restarts)
+               collect (restart-name restart))
+   (case1 () :report "Return 1." 1)
+   (nil   () :report "Return 2." 2)
+   (case3 () :report "Return 3." 3)
+   (case1 () :report "Return 4." 4))
+\EV (CASE1 NIL CASE3 CASE1 ABORT)
+ ;; In the example above the restart named ABORT was not created
+ ;; explicitly, but was implicitly supplied by the system.
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{compute-restarts}
+\funref{find-restart}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== WITH-CONDITION-RESTARTS
+
+\begincom{with-condition-restarts}\ftype{Macro}
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\label Syntax::
+
+\DefmacWithValuesNewline with-condition-restarts
+		  {condition-form restarts-form \starparam{form}}
+		  {\starparam{result}}
+
+\label Arguments and Values::
+ 
+\param{condition-form}---a \term{form}; \term{evaluated} to produce a \param{condition}.
+
+\param{condition}---a \term{condition} \term{object} resulting from the 
+		    \term{evaluation} of \param{condition-form}.
+
+\param{restart-form}---a \term{form}; \term{evaluated} to produce a \param{restart-list}.
+
+\param{restart-list}---a \term{list} of \term{restart} \term{objects} resulting 
+		       from the \term{evaluation} of \param{restart-form}.
+
+\param{forms}---an \term{implicit progn}; \eval.
+
+\param{results}---the \term{values} returned by \param{forms}.
+
+\label Description::
+
+First, the \param{condition-form} and \param{restarts-form} are \term{evaluated}
+in normal left-to-right order; the \term{primary values} yielded by these
+\term{evaluations} are respectively called the \param{condition} 
+and the \param{restart-list}.
+
+Next, the \param{forms} are \term{evaluated} in a \term{dynamic environment}
+in which each \term{restart} in \param{restart-list} is associated with
+the \param{condition}.  \Seesection\AssocRestartWithCond.
+
+\label Examples:\None.
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{restart-case}
+
+\label Notes::
+
+Usually this \term{macro} is not used explicitly in code, 
+since \macref{restart-case} handles most of the common cases
+in a way that is syntactically more concise.
+
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\endcom
+
+
+%%% ========== WITH-SIMPLE-RESTART
+\begincom{with-simple-restart}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValuesNewline with-simple-restart 
+		  {\paren{name format-control \starparam{format-argument}}
+		   \starparam{form}}
+		  {\starparam{result}}
+
+\label Arguments and Values::
+
+\param{name}---a \term{symbol}.
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\param{format-control}---a \term{format control}.
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+\param{format-argument}---an \term{object} (\ie a \term{format argument}).
+
+\param{forms}---an \term{implicit progn}.
+ 
+\param{results}---in the normal situation,
+   the \term{values} returned by the \param{forms};
+   in the exceptional situation where the \term{restart} named \param{name} is invoked,
+   two values---\nil\ and \t.
+ 
+\label Description::
+
+\macref{with-simple-restart} establishes a restart.  
+
+If the restart designated by \param{name} is not invoked while executing \param{forms},
+all values returned by the last of \param{forms} are returned. 
+If the restart designated by \param{name} is invoked,
+control is transferred to \macref{with-simple-restart},
+which returns two values, \nil\ and \t.
+
+If \param{name} is \nil, an anonymous restart is established.
+
+The \param{format-control} and \param{format-arguments} are used 
+report the \term{restart}.
+
+\label Examples::
+
+\code
+ (defun read-eval-print-loop (level)
+   (with-simple-restart (abort "Exit command level ~D." level)
+     (loop
+       (with-simple-restart (abort "Return to command level ~D." level)
+         (let ((form (prog2 (fresh-line) (read) (fresh-line))))
+           (prin1 (eval form)))))))
+\EV READ-EVAL-PRINT-LOOP
+ (read-eval-print-loop 1)
+ (+ 'a 3)
+\OUT Error: The argument, A, to the function + was of the wrong type.
+\OUT        The function expected a number.
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Specify a value to use this time.
+\OUT  2: Return to command level 1.
+\OUT  3: Exit command level 1.
+\OUT  4: Return to Lisp Toplevel.
+\endcode
+
+\code
+ (defun compute-fixnum-power-of-2 (x)
+   (with-simple-restart (nil "Give up on computing 2{\hat}~D." x)
+     (let ((result 1))
+       (dotimes (i x result)
+         (setq result (* 2 result))
+         (unless (fixnump result)
+           (error "Power of 2 is too large."))))))
+COMPUTE-FIXNUM-POWER-OF-2
+ (defun compute-power-of-2 (x)
+   (or (compute-fixnum-power-of-2 x) 'something big))
+COMPUTE-POWER-OF-2
+ (compute-power-of-2 10)
+1024
+ (compute-power-of-2 10000)
+\OUT Error: Power of 2 is too large.
+\OUT To continue, type :CONTINUE followed by an option number.
+\OUT  1: Give up on computing 2{\hat}10000.
+\OUT  2: Return to Lisp Toplevel
+\OUT Debug> \IN{:continue 1}
+\EV SOMETHING-BIG
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{restart-case}
+
+\label Notes::
+
+\macref{with-simple-restart} is shorthand for one of the most
+common uses of \macref{restart-case}.
+
+\macref{with-simple-restart} could be defined by:
+
+\issue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+\code
+ (defmacro with-simple-restart ((restart-name format-control
+                                              &rest format-arguments)
+                                &body forms)
+   `(restart-case (progn ,@forms)
+      (,restart-name ()
+          :report (lambda (stream)
+                    (format stream ,format-control ,@format-arguments))
+         (values nil t))))
+\endcode
+\endissue{FORMAT-STRING-ARGUMENTS:SPECIFY}
+
+Because the second return value is \t\ in the exceptional case,
+it is common (but not required) to arrange for the second return value
+in the normal case to be missing or \nil\ so that the two situations
+can be distinguished.
+
+\endcom
+
+%-------------------- Pre-Defined Restarts --------------------
+
+
+%%% ========== ABORT
+\begincom{abort}\ftype{Restart}
+
+\label Data Arguments Required::
+
+None.
+
+\label Description::
+
+The intent of the \misc{abort} restart is to allow return to the
+innermost ``command level.''  Implementors are encouraged to make 
+sure that there is always a restart named \funref{abort} 
+around any user code so that user code can call \funref{abort} 
+at any time and expect something reasonable to happen;
+exactly what the reasonable thing is may vary somewhat.  Typically,
+in an interactive listener, the invocation of \funref{abort}
+returns to the \term{Lisp reader} phase of the \term{Lisp read-eval-print loop},
+though in some batch or multi-processing
+situations there may be situations in which having it kill the running 
+process is more appropriate.
+
+\label See Also::
+
+\secref\Restarts,
+{\secref\InterfacesToRestarts},
+\funref{invoke-restart},
+\funref{abort} (\term{function})
+
+\endcom%{abort}
+
+%%% ========== CONTINUE
+\begincom{continue}\ftype{Restart}
+
+\label Data Arguments Required::
+
+None.
+
+\label Description::
+
+\Therestart{continue} is generally part of protocols where there is
+  a single ``obvious'' way to continue, such as in 
+\funref{break} and \funref{cerror}.  Some
+  user-defined protocols may also wish to incorporate it for similar reasons.
+  In general, however, it is more reliable to design a special purpose restart
+  with a name that more directly suits the particular application.
+
+\label Examples::
+
+\code
+ (let ((x 3))
+   (handler-bind ((error #'(lambda (c)
+                             (let ((r (find-restart 'continue c)))
+                               (when r (invoke-restart r))))))
+     (cond ((not (floatp x))
+            (cerror "Try floating it." "~D is not a float." x)
+            (float x))
+           (t x)))) \EV 3.0
+\endcode   
+
+\label See Also::
+
+\secref\Restarts,
+{\secref\InterfacesToRestarts},
+\funref{invoke-restart},
+\funref{continue} (\term{function}),
+\macref{assert},
+\funref{cerror}
+
+\endcom%{continue}
+
+%%% ========== MUFFLE-WARNING
+\begincom{muffle-warning}\ftype{Restart}
+
+\label Data Arguments Required::
+
+None.
+
+\label Description::
+
+This \term{restart} is established by \funref{warn} so that \term{handlers}
+of \typeref{warning} \term{conditions} have a way to tell \funref{warn} 
+that a warning has already been dealt with and that no further action is warranted.
+
+\label Examples::
+
+\code
+ (defvar *all-quiet* nil) \EV *ALL-QUIET*
+ (defvar *saved-warnings* '()) \EV *SAVED-WARNINGS*
+ (defun quiet-warning-handler (c)
+   (when *all-quiet*
+     (let ((r (find-restart 'muffle-warning c)))
+       (when r 
+         (push c *saved-warnings*)
+         (invoke-restart r)))))
+\EV CUSTOM-WARNING-HANDLER
+ (defmacro with-quiet-warnings (&body forms)
+   `(let ((*all-quiet* t)
+          (*saved-warnings* '()))
+      (handler-bind ((warning #'quiet-warning-handler))
+        ,@forms
+        *saved-warnings*)))
+\EV WITH-QUIET-WARNINGS
+ (setq saved
+   (with-quiet-warnings
+     (warn "Situation #1.")
+     (let ((*all-quiet* nil))
+       (warn "Situation #2."))
+     (warn "Situation #3.")))
+\OUT Warning: Situation #2.
+\EV (#<SIMPLE-WARNING 42744421> #<SIMPLE-WARNING 42744365>)
+ (dolist (s saved) (format t "~&~A~%" s))
+\OUT Situation #3.
+\OUT Situation #1.
+\EV NIL
+\endcode
+
+\label See Also::
+
+\secref\Restarts,
+{\secref\InterfacesToRestarts},
+\funref{invoke-restart},
+\funref{muffle-warning} (\term{function}),
+\funref{warn}
+
+\endcom%{muffle-warning}
+
+%%% ========== STORE-VALUE
+\begincom{store-value}\ftype{Restart}
+
+\label Data Arguments Required::
+
+a value to use instead (on an ongoing basis).
+
+\label Description::
+
+\Therestart{store-value} is generally used by \term{handlers}
+trying to recover from errors of \term{types} such as \typeref{cell-error} 
+or \typeref{type-error}, which may wish to supply a replacement datum to
+be stored permanently.
+
+\label Examples::
+
+\code
+ (defun type-error-auto-coerce (c)
+   (when (typep c 'type-error)
+     (let ((r (find-restart 'store-value c)))
+       (handler-case (let ((v (coerce (type-error-datum c)
+                                      (type-error-expected-type c))))
+                       (invoke-restart r v))
+         (error ()))))) \EV TYPE-ERROR-AUTO-COERCE
+ (let ((x 3))
+   (handler-bind ((type-error #'type-error-auto-coerce))
+     (check-type x float)
+     x)) \EV 3.0
+\endcode   
+
+\label See Also::
+
+{\secref\Restarts},
+{\secref\InterfacesToRestarts},
+\funref{invoke-restart},
+\funref{store-value} (\term{function}),
+\macref{ccase},
+\macref{check-type},
+\macref{ctypecase},
+\funref{use-value} (\term{function} and \term{restart})
+
+\endcom%{store-value}
+
+
+%%% ========== USE-VALUE
+\begincom{use-value}\ftype{Restart}
+
+\label Data Arguments Required::
+
+a value to use instead (once).
+
+\label Description::
+
+\Therestart{use-value} is generally used by \term{handlers} trying 
+to recover from errors of \term{types} such as \typeref{cell-error}, 
+where the handler may wish to supply a replacement datum for one-time use.
+
+\label See Also::
+
+{\secref\Restarts},
+{\secref\InterfacesToRestarts},
+\funref{invoke-restart},
+\funref{use-value} (\term{function}),
+\funref{store-value} (\term{function} and \term{restart})
+
+\endcom%{use-value}
+
+%%% ========== ABORT
+%%% ========== CONTINUE
+%%% ========== MUFFLE-WARNING
+%%% ========== STORE-VALUE
+%%% ========== USE-VALUE
+\begincom{abort, continue, muffle-warning, store-value, use-value}\ftype{Function}
+\idxref{abort}\idxref{continue}\idxref{muffle-warning}\idxref{store-value}\idxref{use-value}
+
+\label Syntax::
+
+%!!! KMP: Issue CONDITION-RESTARTS forgot to add the condition argument here,
+%         but I have added it tentatively (pending x3j13 approval) since I'm 
+%         sure it was intended.  (MUFFLE-WARNING-CONDITION-ARGUMENT was the technical
+%         issue that was raised to fix this, but it was never voted upon.)
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\DefunNoReturn abort {{\opt} condition}
+\DefunWithValues continue {{\opt} condition} {\nil}
+\DefunNoReturn muffle-warning {{\opt} condition}
+\DefunWithValues store-value {value {\opt} condition} {\nil}
+\DefunWithValues use-value {value {\opt} condition} {\nil}
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\label Arguments and Values::
+
+\param{value}---an \term{object}.
+
+\issue{MUFFLE-WARNING-CONDITION-ARGUMENT}
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\param{condition}---a \term{condition} \term{object}, or \nil.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+\endissue{MUFFLE-WARNING-CONDITION-ARGUMENT}
+
+\label Description::
+
+Transfers control to the most recently established \term{applicable restart}
+having the same name as the function.  That is,
+  \thefunction{abort}    searches for an \term{applicable} \misc{abort}    \term{restart}, 
+  \thefunction{continue} searches for an \term{applicable} \misc{continue} \term{restart},
+and so on.
+
+If no such \term{restart} exists, 
+the functions
+     \funref{continue},
+     \funref{store-value}, 
+ and \funref{use-value}
+return \nil, and 
+the functions
+     \funref{abort}
+ and \funref{muffle-warning}
+signal an error \oftype{control-error}.
+
+\issue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+When \param{condition} is \term{non-nil},
+only those \term{restarts} are considered that are 
+  either explicitly associated with that \param{condition},
+      or not associated with any \term{condition};
+that is, the excluded \term{restarts} are 
+those that are associated with a non-empty set of \term{conditions}
+of which the given \param{condition} is not an \term{element}.
+If \param{condition} is \nil, all \term{restarts} are considered.
+\endissue{CONDITION-RESTARTS:PERMIT-ASSOCIATION}
+
+\label Examples::
+
+\code
+;;; Example of the ABORT retart
+
+ (defmacro abort-on-error (&body forms)
+   `(handler-bind ((error #'abort))
+      ,@forms)) \EV ABORT-ON-ERROR
+ (abort-on-error (+ 3 5)) \EV 8
+ (abort-on-error (error "You lose."))
+\OUT Returned to Lisp Top Level.
+
+;;; Example of the CONTINUE restart
+
+ (defun real-sqrt (n)
+   (when (minusp n)
+     (setq n (- n))
+     (cerror "Return sqrt(~D) instead." "Tried to take sqrt(-~D)." n))
+   (sqrt n))
+
+ (real-sqrt 4) \EV 2
+ (real-sqrt -9)
+\OUT Error: Tried to take sqrt(-9).
+\OUT To continue, type :CONTINUE followed by an option number:
+\OUT  1: Return sqrt(9) instead.
+\OUT  2: Return to Lisp Toplevel.
+\OUT Debug> \IN{(continue)}
+\OUT Return sqrt(9) instead.
+\EV 3
+ 
+ (handler-bind ((error #'(lambda (c) (continue))))
+   (real-sqrt -9)) \EV 3
+
+;;; Example of the MUFFLE-WARNING restart
+
+ (defun count-down (x)
+   (do ((counter x (1- counter)))
+       ((= counter 0) 'done)
+     (when (= counter 1)
+       (warn "Almost done"))
+     (format t "~&~D~%" counter)))
+\EV COUNT-DOWN
+ (count-down 3)
+\OUT 3
+\OUT 2
+\OUT Warning: Almost done
+\OUT 1
+\EV DONE
+ (defun ignore-warnings-while-counting (x)
+   (handler-bind ((warning #'ignore-warning))
+     (count-down x)))
+\EV IGNORE-WARNINGS-WHILE-COUNTING
+ (defun ignore-warning (condition)
+   (declare (ignore condition))
+   (muffle-warning))
+\EV IGNORE-WARNING
+ (ignore-warnings-while-counting 3)
+\OUT 3
+\OUT 2
+\OUT 1
+\EV DONE
+
+;;; Example of the STORE-VALUE and USE-VALUE restarts
+
+ (defun careful-symbol-value (symbol)
+   (check-type symbol symbol)
+   (restart-case (if (boundp symbol)
+                     (return-from careful-symbol-value 
+                                  (symbol-value symbol))
+                     (error 'unbound-variable
+                            :name symbol))
+     (use-value (value)
+       :report "Specify a value to use this time."
+       value)
+     (store-value (value)
+       :report "Specify a value to store and use in the future."
+       (setf (symbol-value symbol) value))))
+ (setq a 1234) \EV 1234
+ (careful-symbol-value 'a) \EV 1234
+ (makunbound 'a) \EV A
+ (careful-symbol-value 'a)
+\OUT Error: A is not bound.
+\OUT To continue, type :CONTINUE followed by an option number.
+\OUT  1: Specify a value to use this time.
+\OUT  2: Specify a value to store and use in the future.
+\OUT  3: Return to Lisp Toplevel.
+\OUT Debug> \IN{(use-value 12)}
+\EV 12
+ (careful-symbol-value 'a)
+\OUT Error: A is not bound.
+\OUT To continue, type :CONTINUE followed by an option number.
+\OUT   1: Specify a value to use this time.
+\OUT   2: Specify a value to store and use in the future.
+\OUT   3: Return to Lisp Toplevel.
+\OUT Debug> \IN{(store-value 24)}
+\EV 24
+ (careful-symbol-value 'a)
+\EV 24
+
+;;; Example of the USE-VALUE restart
+
+ (defun add-symbols-with-default (default &rest symbols)
+   (handler-bind ((sys:unbound-symbol
+                    #'(lambda (c)
+                        (declare (ignore c)) 
+                        (use-value default))))
+     (apply #'+ (mapcar #'careful-symbol-value symbols))))
+\EV ADD-SYMBOLS-WITH-DEFAULT
+ (setq x 1 y 2) \EV 2
+ (add-symbols-with-default 3 'x 'y 'z) \EV 6
+
+
+\endcode
+ 
+\label Side Effects::
+
+A transfer of control may occur if an appropriate \term{restart} is available,
+or (in the case of \thefunction{abort} or \thefunction{muffle-warning})
+execution may be stopped.
+
+\label Affected By::
+
+Each of these functions can be affected by 
+the presence of a \term{restart} having the same name.
+
+\label Exceptional Situations::
+
+If an appropriate \misc{abort} \term{restart}
+ is not available for \thefunction{abort},
+or an appropriate \misc{muffle-warning} \term{restart} 
+ is not available for \thefunction{muffle-warning},
+an error \oftype{control-error} is signaled.
+
+\label See Also::
+
+\funref{invoke-restart},
+{\secref\Restarts},
+{\secref\InterfacesToRestarts},
+\macref{assert},
+\macref{ccase},
+\funref{cerror},
+\macref{check-type},
+\macref{ctypecase},
+\funref{use-value},
+\funref{warn}
+
+\label Notes::
+
+\code
+ (abort condition) \EQ (invoke-restart 'abort)
+ (muffle-warning)  \EQ (invoke-restart 'muffle-warning)
+ (continue)        \EQ (let ((r (find-restart 'continue))) (if r (invoke-restart r)))
+ (use-value \param{x}) \EQ (let ((r (find-restart 'use-value))) (if r (invoke-restart r \param{x})))
+ (store-value x) \EQ (let ((r (find-restart 'store-value))) (if r (invoke-restart r \param{x})))
+\endcode
+
+No functions defined in this specification are required to provide
+a \misc{use-value} \term{restart}.
+
+\endcom

dict-conses.tex

@@ -0,0 +1,4662 @@
+% -*- Mode: TeX -*-
+
+\def\SatisfyTest#1#2{The \param{test}, \param{test-not}, and \param{key} 
+affect how it is determined whether \param{#1} is the same as #2.
+For details, \seesection\SatisfyingTheTwoArgTest.\par}
+
+% Cons
+%  Trees
+%  Lists
+%   List Elements
+%   List Tails
+%   List Mapping
+%   Alists
+%   Plists
+%   Sets
+
+%-------------------- Conses, lists, atoms, ... --------------------
+
+\begincom{list}\ftype{System Class}
+
+\label Class Precedence List::
+
+\typeref{list},
+\typeref{sequence},
+\typeref{t}
+
+\label Description::
+
+A \newterm{list} is a chain of \term{conses} in which the \term{car} of each
+\term{cons} is an \term{element} of the \term{list}, and the \term{cdr} of
+each \term{cons} is either the next link in the chain or a terminating
+\term{atom}.
+
+A \newterm{proper list} is a chain of \term{conses} terminated by 
+the \newterm{empty list}, \empty, which is  itself a \term{proper list}.
+A \newterm{dotted list} is a \term{list} which has a terminating \term{atom} 
+that is not the \term{empty list}.
+A \newterm{circular list} is a chain of \term{conses} that has no termination
+because some \term{cons} in the chain is the \term{cdr} of a later \term{cons}.
+
+\term{Dotted lists} and \term{circular lists} are also \term{lists}, but usually
+the unqualified term ``list'' within this specification means \term{proper list}.
+Nevertheless, \thetype{list} unambiguously includes \term{dotted lists} 
+and \term{circular lists}.
+
+For each \term{element} of a \term{list} there is a \term{cons}.
+The \term{empty list} has no \term{elements} and is not a \term{cons}.
+
+%% 2.15.0 14
+\Thetypes{cons} and \typeref{null} form an \term{exhaustive partition} 
+of the \term{type} \typeref{list}.
+
+\label See Also::
+
+{\secref\LeftParen},
+{\secref\PrintingListsAndConses}
+
+\endcom%{list}\ftype{System Class}
+
+\begincom{null}\ftype{System Class}
+
+\label Class Precedence List::
+\typeref{null},
+\typeref{symbol},
+\typeref{list},
+\typeref{sequence},
+\typeref{t}
+
+\label Description::
+
+%% 2.15.0 13
+The only \term{object} \oftype{null} is \nil, 
+which represents the \term{empty list} and can also be notated \empty.
+
+\label See Also::
+
+{\secref\SymbolTokens},
+{\secref\LeftParen},
+{\secref\PrintingSymbols}
+
+\endcom%{null}\ftype{System Class}
+\begincom{cons}\ftype{System Class}
+
+\label Class Precedence List::
+\typeref{cons},
+\typeref{list},
+\typeref{sequence},
+\typeref{t}
+
+\label Description::
+
+A \term{cons} is a compound \term{object} having two components,
+called the \term{car} and \term{cdr}. These form a \term{dotted pair}.
+Each component can be any \term{object}.
+
+\issue{CONS-TYPE-SPECIFIER:ADD}
+
+\label Compound Type Specifier Kind::
+
+Specializing.
+
+\label Compound Type Specifier Syntax::
+
+\Deftype{cons}{\ttbrac{car-typespec \brac{cdr-typespec}}}
+
+\label Compound Type Specifier Arguments::
+
+\param{car-typespec}---a \term{type specifier},
+		    or the \term{symbol} \misc{*}.
+  \Default{the \term{symbol} \misc{*}}
+
+\param{cdr-typespec}---a \term{type specifier},
+		    or the \term{symbol} \misc{*}.
+  \Default{the \term{symbol} \misc{*}}
+
+\label Compound Type Specifier Description::
+
+This denotes the set of \term{conses} 
+whose \term{car} is constrained to be of \term{type} \param{car-typespec} and
+whose \term{cdr} is constrained to be of \term{type} \param{cdr-typespec}.
+(If either \param{car-typespec} or \param{cdr-typespec} is \misc{*},
+ it is as if \thetype{t} had been denoted.)
+
+\endissue{CONS-TYPE-SPECIFIER:ADD}
+
+\label See Also::
+
+{\secref\LeftParen},
+{\secref\PrintingListsAndConses}
+
+\endcom%{cons}\ftype{System Class}
+\begincom{atom}\ftype{Type}
+
+%Added per Barrett's suggestion. -kmp 23-Oct-90
+
+\label Supertypes:: 
+
+\typeref{atom},
+\typeref{t}
+
+\label Description::
+
+It is equivalent to {\tt (not cons)}.  
+
+\endcom%{atom}\ftype{Type}
+
+
+%-------------------- Cons --------------------
+
+%%% ========== CONS
+\begincom{cons}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues cons {object-1 object-2} {cons}
+
+\label Arguments and Values::
+
+\param{object-1}---an \term{object}.
+
+\param{object-2}---an \term{object}.
+
+\param{cons}---a \term{cons}.
+
+\label Description::
+
+%% 15.1.0 8
+Creates a \term{fresh} \term{cons}, the \term{car} of which is \param{object-1}
+and the \term{cdr} of which is \param{object-2}.
+
+\label Examples::
+
+\code
+ (cons 1 2) \EV (1 . 2)
+ (cons 1 nil) \EV (1)
+ (cons nil 2) \EV (NIL . 2)
+ (cons nil nil) \EV (NIL)
+ (cons 1 (cons 2 (cons 3 (cons 4 nil)))) \EV (1 2 3 4)
+ (cons 'a 'b) \EV (A . B)
+ (cons 'a (cons 'b (cons 'c '\empty))) \EV (A B C)
+ (cons 'a '(b c d)) \EV (A B C D)
+\endcode
+
+\label Side Effects:\None.
+
+%% Sandra thinks this is excessive.
+%Creates an \term{object}.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+%% Sandra thinks this is excessive.
+%Might signal \typeref{storage-condition}.
+
+\label See Also::
+
+\funref{list}
+
+\label Notes::
+If \param{object-2} is a \term{list}, \funref{cons} can be thought of as
+producing a new \term{list} which is like it but has \param{object-1} prepended.
+\endcom
+
+
+%%% ========== CONSP
+\begincom{consp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues consp {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 8
+\TypePredicate{object}{cons}
+
+\label Examples::
+\code
+ (consp nil) \EV \term{false}
+ (consp (cons 1 2)) \EV \term{true}
+\endcode
+
+The \term{empty list} is not a \term{cons}, so
+
+\code
+ (consp '()) \EQ (consp 'nil) \EV \term{false}
+\endcode
+
+\label Side Effects:\None!
+
+\label Affected By:\None!
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\funref{listp}
+
+\label Notes::
+
+\code
+ (consp \param{object}) \EQ (typep \param{object} 'cons) \EQ (not (typep \param{object} 'atom)) \EQ (typep \param{object} '(not atom))
+\endcode
+
+\endcom
+
+%%% ========== ATOM
+\begincom{atom}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues atom {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 6
+\TypePredicate{object}{atom}
+
+\label Examples::
+\code
+ (atom 'sss) \EV \term{true}
+ (atom (cons 1 2)) \EV \term{false}
+ (atom nil) \EV \term{true}
+ (atom '()) \EV \term{true}
+ (atom 3) \EV \term{true}
+\endcode
+
+\label Affected By:\None!
+
+\label Exceptional Situations:\None!
+
+\label See Also:\None.
+
+\label Notes::
+
+\code
+ (atom \param{object}) \EQ (typep \param{object} 'atom) \EQ (not (consp \param{object}))
+ \EQ (not (typep \param{object} 'cons)) \EQ (typep \param{object} '(not cons))
+\endcode
+
+\endcom
+
+%%% ========== RPLACA
+%%% ========== RPLACD
+\begincom{rplaca, rplacd}\ftype{Function}
+
+\label Syntax::
+
+\DefunMultiWithValues {cons object} {cons}
+ {\entry{rplaca}
+  \entry{rplacd}}
+
+\label Pronunciation::
+
+\funref{rplaca}: \pronounced{\stress{r\harde}\Stress{plak}\schwa}
+	      or \pronounced{\stress{r\schwa}\Stress{plak}\schwa}
+
+\funref{rplacd}: \pronounced{\stress{r\harde}\Stress{plak}d\schwa}
+	      or \pronounced{\stress{r\schwa}\Stress{plak}d\schwa}
+	      or \pronounced{\stress{r\harde}\Stress{plak}d\harde}
+	      or \pronounced{\stress{r\schwa}\Stress{plak}d\harde}
+
+\label Arguments and Values::
+
+\param{cons}---a \term{cons}.
+
+\param{object}---an \term{object}.
+
+\label Description::
+
+%% 15.3.0 4
+\funref{rplaca} replaces the \term{car} of the \param{cons} with \param{object}.
+%and then returns the modified \param{cons}.
+
+\funref{rplacd} replaces the \term{cdr} of the \param{cons} with \param{object}.
+%and then returns the modified \param{cons}.
+
+\label Examples::
+%% 15.3.0 3
+\code
+ (defparameter *some-list* (list* 'one 'two 'three 'four)) \EV *some-list*
+ *some-list* \EV (ONE TWO THREE . FOUR)
+ (rplaca *some-list* 'uno) \EV (UNO TWO THREE . FOUR)
+ *some-list* \EV (UNO TWO THREE . FOUR)
+ (rplacd (last *some-list*) (list 'IV)) \EV (THREE IV)
+ *some-list* \EV (UNO TWO THREE IV)
+\endcode
+
+\label Side Effects::
+%% 15.3.0 1
+%% 15.3.0 2
+                   
+The \param{cons} is modified. 
+
+\label Affected By:\None!
+
+\label Exceptional Situations:\None.
+
+%!!! Issue: read-only structure might be enforced. -kmp
+
+\Shouldchecktype{cons}{a \term{cons}}
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+%%What else would they be used for? -kmp 15-Feb-91
+% \funref{rplaca} and \funref{rplacd} may be used to make alterations 
+% in an already existing list structure, that is, 
+% to change the \term{car} or \term{cdr} of an existing \term{cons}.
+
+\endcom
+
+%%% ========== CAR
+%%% ========== CDR
+%%% ========== CAAR
+%%% ========== CADR
+%%% ========== CDAR
+%%% ========== CDDR
+%%% ========== CAAAR
+%%% ========== CAADR
+%%% ========== CADAR
+%%% ========== CADDR
+%%% ========== CDAAR
+%%% ========== CDADR
+%%% ========== CDDAR
+%%% ========== CDDDR
+%%% ========== CAAAAR
+%%% ========== CAAADR
+%%% ========== CAADAR
+%%% ========== CAADDR
+%%% ========== CADAAR
+%%% ========== CADADR
+%%% ========== CADDAR
+%%% ========== CADDDR
+%%% ========== CDAAAR
+%%% ========== CDAADR
+%%% ========== CDADAR
+%%% ========== CDADDR
+%%% ========== CDDAAR
+%%% ========== CDDADR
+%%% ========== CDDDAR 
+%%% ========== CDDDDR 
+\begincom{car,    cdr,
+          caar,   cadr,   cdar,   cddr,
+	  caaar,  caadr,  cadar,  caddr,  cdaar,  cdadr,  cddar,  cdddr,
+          caaaar, caaadr, caadar, caaddr, cadaar, cadadr, caddar, cadddr,
+          cdaaar, cdaadr, cdadar, cdaddr, cddaar, cddadr, cdddar, cddddr}\ftype{Accessor}
+
+\label Syntax::
+
+\DefunMultiAccessorWithValues {x} {object} {new-object}
+ {\entry{car}
+  \entry{cdr}
+  \blankline
+  \entry{caar}
+  \entry{cadr}
+  \entry{cdar}
+  \entry{cddr}
+  \blankline
+  \entry{caaar}
+  \entry{caadr}
+  \entry{cadar}
+  \entry{caddr}
+  \entry{cdaar}
+  \entry{cdadr}
+  \entry{cddar}
+  \entry{cdddr}
+  \blankline
+  \entry{caaaar}
+  \entry{caaadr}
+  \entry{caadar}
+  \entry{caaddr}
+  \entry{cadaar}
+  \entry{cadadr}
+  \entry{caddar}
+  \entry{cadddr}
+  \entry{cdaaar}
+  \entry{cdaadr}
+  \entry{cdadar}
+  \entry{cdaddr}
+  \entry{cddaar}
+  \entry{cddadr}
+  \entry{cdddar}
+  \entry{cddddr}}
+
+\label Pronunciation::
+
+\funref{cadr}: \pronounced{\Stress{ka}\stress{d\schwa r}}
+
+\funref{caddr}: \pronounced{\Stress{kad}\schwa \stress{d\schwa r}}
+  	     or \pronounced{\Stress{ka}\stress{d\.ud\schwa r}}
+
+\funref{cdr}: \pronounced{\Stress{k\.u}\stress{d\schwa r}}
+
+\funref{cddr}: \pronounced{\Stress{k\.ud}\schwa \stress{d\schwa r}}
+  	    or \pronounced{\Stress{k\schwa}\stress{d\.ud\schwa r}}
+
+\label Arguments and Values::
+
+\param{x}---a \term{list}.
+
+\param{object}---an \term{object}.
+
+\param{new-object}---an \term{object}.
+
+\label Description::
+
+%% 15.1.0 3
+If \param{x} is a \term{cons}, \funref{car} returns the \term{car} 
+of that \term{cons}.  If \param{x} is \nil, \funref{car} returns \nil.
+
+%% 15.1.0 4
+If \param{x} is a \term{cons}, \funref{cdr} returns the \term{cdr} 
+of that \term{cons}.  If \param{x} is \nil, \funref{cdr} returns \nil.
+
+\term{Functions} are provided which perform compositions of up to four
+\funref{car} and \funref{cdr} operations.  Their \term{names} consist of 
+a \f{C}, followed by two, three, or four occurrences of \f{A} or \f{D}, 
+and finally an \f{R}.  The series of \f{A}'s and \f{D}'s in each
+\term{function}'s \term{name} is chosen to identify the series of 
+\funref{car} and \funref{cdr} operations that is performed by the function.
+The order in which the \f{A}'s and \f{D}'s appear is the inverse of the
+order in which the corresponding operations are performed.  \Thenextfigure\ 
+defines the relationships precisely.
+
+\tablefigtwo{CAR and CDR variants}{This \term{place} $\ldots$}{Is equivalent to this \term{place} $\ldots$}{
+\f{(caar \param{x})}&\f{(car (car \param{x}))}\cr
+\f{(cadr \param{x})}&\f{(car (cdr \param{x}))}\cr
+\f{(cdar \param{x})}&\f{(cdr (car \param{x}))}\cr
+\f{(cddr \param{x})}&\f{(cdr (cdr \param{x}))}\cr
+\f{(caaar \param{x})}&\f{(car (car (car \param{x})))}\cr
+\f{(caadr \param{x})}&\f{(car (car (cdr \param{x})))}\cr
+\f{(cadar \param{x})}&\f{(car (cdr (car \param{x})))}\cr
+\f{(caddr \param{x})}&\f{(car (cdr (cdr \param{x})))}\cr
+\f{(cdaar \param{x})}&\f{(cdr (car (car \param{x})))}\cr
+\f{(cdadr \param{x})}&\f{(cdr (car (cdr \param{x})))}\cr
+\f{(cddar \param{x})}&\f{(cdr (cdr (car \param{x})))}\cr
+\f{(cdddr \param{x})}&\f{(cdr (cdr (cdr \param{x})))}\cr
+\f{(caaaar \param{x})}&\f{(car (car (car (car \param{x}))))}\cr
+\f{(caaadr \param{x})}&\f{(car (car (car (cdr \param{x}))))}\cr
+\f{(caadar \param{x})}&\f{(car (car (cdr (car \param{x}))))}\cr
+\f{(caaddr \param{x})}&\f{(car (car (cdr (cdr \param{x}))))}\cr
+\f{(cadaar \param{x})}&\f{(car (cdr (car (car \param{x}))))}\cr
+\f{(cadadr \param{x})}&\f{(car (cdr (car (cdr \param{x}))))}\cr
+\f{(caddar \param{x})}&\f{(car (cdr (cdr (car \param{x}))))}\cr
+\f{(cadddr \param{x})}&\f{(car (cdr (cdr (cdr \param{x}))))}\cr
+\f{(cdaaar \param{x})}&\f{(cdr (car (car (car \param{x}))))}\cr
+\f{(cdaadr \param{x})}&\f{(cdr (car (car (cdr \param{x}))))}\cr
+\f{(cdadar \param{x})}&\f{(cdr (car (cdr (car \param{x}))))}\cr
+\f{(cdaddr \param{x})}&\f{(cdr (car (cdr (cdr \param{x}))))}\cr
+\f{(cddaar \param{x})}&\f{(cdr (cdr (car (car \param{x}))))}\cr
+\f{(cddadr \param{x})}&\f{(cdr (cdr (car (cdr \param{x}))))}\cr
+\f{(cdddar \param{x})}&\f{(cdr (cdr (cdr (car \param{x}))))}\cr
+\f{(cddddr \param{x})}&\f{(cdr (cdr (cdr (cdr \param{x}))))}\cr
+}
+
+\macref{setf} can also be used with any of these functions to change an
+existing component of \param{x}, but \macref{setf} will not make new
+components.  So, for example, the \term{car} of a \term{cons} 
+can be assigned with \macref{setf} of \funref{car},
+but the \term{car} of \nil\ cannot be assigned with \macref{setf} of \funref{car}.
+Similarly, the \term{car} of the \term{car} of a \term{cons} whose \term{car}
+is a \term{cons} can be assigned with \macref{setf} of \funref{caar},
+but neither \nil nor a \term{cons} whose car is \nil\ can be assigned
+with \macref{setf} of \funref{caar}.
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+The argument \param{x} is permitted to be a \term{dotted list} 
+or a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label Examples::
+
+\code
+ (car nil) \EV NIL  
+ (cdr '(1 . 2)) \EV 2
+ (cdr '(1 2)) \EV (2)
+ (cadr '(1 2)) \EV 2 
+ (car '(a b c)) \EV A
+ (cdr '(a b c)) \EV (B C)
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+The functions \funref{car} and \funref{cdr} 
+should signal \typeref{type-error} if they receive an argument which is not a
+\term{list}.  The other functions (\funref{caar}, \funref{cadr},
+$\ldots$ \funref{cddddr}) should behave for the purpose of
+error checking as if defined by appropriate calls to \funref{car} and
+\funref{cdr}.
+
+\label See Also::
+
+\funref{rplaca}, \funref{first}, \funref{rest}
+
+\label Notes::
+
+%% 15.1.0 7
+The \term{car} of a \term{cons} can also be altered by using \funref{rplaca},
+and the \term{cdr} of a \term{cons} can be altered by using \funref{rplacd}.
+
+\code
+(car \i{x})    \EQ (first \i{x})
+(cadr \i{x})   \EQ (second \i{x}) \EQ (car (cdr \i{x}))
+(caddr \i{x})  \EQ (third \i{x})  \EQ (car (cdr (cdr \i{x})))
+(cadddr \i{x}) \EQ (fourth \i{x}) \EQ (car (cdr (cdr (cdr \i{x}))))
+\endcode
+
+\endcom
+
+%-------------------- Trees --------------------
+
+%%% ========== COPY-TREE
+\begincom{copy-tree}\ftype{Function}
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label Syntax::
+
+\DefunWithValues copy-tree {tree} {new-tree}
+
+\label Arguments and Values::
+
+\param{tree}---a \term{tree}.
+
+\param{new-tree}---a \term{tree}.
+
+\label Description::
+
+%% 15.2.0 25
+Creates a \term{copy} of a \term{tree} of \term{conses}.
+
+If \param{tree} is not a \term{cons}, it is returned; 
+otherwise, the result is a new \term{cons} of the results of calling \funref{copy-tree} 
+on the \term{car} and \term{cdr} of \param{tree}.
+In other words, all \term{conses} in the \term{tree} represented by \param{tree}
+are copied recursively, stopping only when non-\term{conses} are encountered.
+
+\funref{copy-tree} does not preserve circularities and the sharing of substructure.
+%!!! And consequently might fail to return in the case of circularity? -kmp 09-Apr-91
+
+\label Examples::
+
+\code
+ (setq object (list (cons 1 "one")
+                    (cons 2 (list 'a 'b 'c))))
+\EV ((1 . "one") (2 A B C))
+ (setq object-too object) \EV ((1 . "one") (2 A B C))
+ (setq copy-as-list (copy-list object))
+ (setq copy-as-alist (copy-alist object))
+ (setq copy-as-tree (copy-tree object))
+ (eq object object-too) \EV \term{true}
+ (eq copy-as-tree object) \EV \term{false}
+ (eql copy-as-tree object) \EV \term{false}
+ (equal copy-as-tree object) \EV \term{true}
+ (setf (first (cdr (second object))) "a"
+       (car (second object)) "two"
+       (car object) '(one . 1)) \EV (ONE . 1)
+ object \EV ((ONE . 1) ("two" "a" B C))
+ object-too \EV ((ONE . 1) ("two" "a" B C))
+ copy-as-list \EV ((1 . "one") ("two" "a" B C))
+ copy-as-alist \EV ((1 . "one") (2 "a" B C))
+ copy-as-tree \EV ((1 . "one") (2 A B C)) 
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{tree-equal}
+
+\label Notes:\None.
+
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\endcom
+
+%%% ========== NSUBLIS
+%%% ========== SUBLIS
+\begincom{sublis, nsublis}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues sublis  {alist tree {\key} key test test-not} {new-tree}
+\DefunWithValues nsublis {alist tree {\key} key test test-not} {new-tree}
+
+\label Arguments and Values::
+
+\param{alist}---an \term{association list}.
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{tree}---a \term{tree}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{new-tree}---a \term{tree}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label Description::
+
+%% 15.4.0 9
+\funref{sublis} makes substitutions for \term{objects} in \param{tree}
+(a structure of \term{conses}).
+%% 15.4.0 10
+\funref{nsublis} is like \funref{sublis} 
+but destructively modifies the relevant
+parts of the \param{tree}.
+
+\funref{sublis} looks at all subtrees and leaves of \param{tree};
+if a subtree or leaf appears as a key in \param{alist}
+(that is, the key and the subtree or leaf \term{satisfy the test}),
+it is replaced by the \term{object} with which that key is associated.
+This operation is non-destructive.  In effect, \funref{sublis} can
+perform several \funref{subst} operations simultaneously.
+
+%% Implied by "satisfy the test." -kmp 15-Feb-92
+% The first argument to the \kwd{test} or \kwd{test-not}
+% function is a key appearing in \param{alist};
+% the second argument is
+% the part of an element of \param{tree} extracted by the
+% \kwd{key} function (if supplied).
+% 
+% The argument to the \kwd{key} 
+% function is a \param{tree} element; the return value is part of
+% the supplied \param{tree} element.
+% If \kwd{key} is not supplied or \nil, 
+% the \param{tree} element itself is 
+% supplied to the \kwd{test} or \kwd{test-not}
+% function.
+
+If \funref{sublis} succeeds, a new copy of \param{tree} is returned in
+which each occurrence of such a subtree or leaf is replaced by the
+\term{object} with which it is associated.   If no changes are made, the
+original tree is returned.  The original \param{tree} is left unchanged,
+but the result tree may share cells with it.
+
+\funref{nsublis} is permitted to modify \param{tree} 
+but otherwise returns the same values as \funref{sublis}.
+
+\label Examples::
+
+\code
+ (sublis '((x . 100) (z . zprime))
+         '(plus x (minus g z x p) 4 . x))
+\EV (PLUS 100 (MINUS G ZPRIME 100 P) 4 . 100)
+ (sublis '(((+ x y) . (- x y)) ((- x y) . (+ x y)))
+         '(* (/ (+ x y) (+ x p)) (- x y))
+         :test #'equal)
+\EV (* (/ (- X Y) (+ X P)) (+ X Y))
+ (setq tree1 '(1 (1 2) ((1 2 3)) (((1 2 3 4)))))
+\EV (1 (1 2) ((1 2 3)) (((1 2 3 4))))
+ (sublis '((3 . "three")) tree1) 
+\EV (1 (1 2) ((1 2 "three")) (((1 2 "three" 4))))
+ (sublis '((t . "string"))
+          (sublis '((1 . "") (4 . 44)) tree1)
+          :key #'stringp)
+\EV ("string" ("string" 2) (("string" 2 3)) ((("string" 2 3 44))))
+ tree1 \EV (1 (1 2) ((1 2 3)) (((1 2 3 4))))
+ (setq tree2 '("one" ("one" "two") (("one" "Two" "three"))))
+\EV ("one" ("one" "two") (("one" "Two" "three"))) 
+ (sublis '(("two" . 2)) tree2) 
+\EV ("one" ("one" "two") (("one" "Two" "three"))) 
+ tree2 \EV ("one" ("one" "two") (("one" "Two" "three"))) 
+ (sublis '(("two" . 2)) tree2 :test 'equal) 
+\EV ("one" ("one" 2) (("one" "Two" "three"))) 
+
+ (nsublis '((t . 'temp))
+           tree1
+           :key #'(lambda (x) (or (atom x) (< (list-length x) 3))))
+\EV ((QUOTE TEMP) (QUOTE TEMP) QUOTE TEMP) 
+\endcode
+
+\label Side Effects::
+
+\funref{nsublis} modifies \param{tree}.
+ 
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{subst},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification},
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+Because the side-effecting variants (\eg \funref{nsublis}) potentially
+change the path that is being traversed, their effects in the presence
+of shared or circular structure structure may vary in surprising ways
+when compared to their non-side-effecting alternatives.  To see this,
+consider the following side-effect behavior, which might be exhibited by
+some implementations:
+
+\code
+ (defun test-it (fn)
+   (let* ((shared-piece (list 'a 'b))
+          (data (list shared-piece shared-piece)))
+     (funcall fn '((a . b) (b . a)) data)))
+ (test-it #'sublis) \EV ((B A) (B A))
+ (test-it #'nsublis) \EV ((A B) (A B))
+\endcode
+
+
+\endcom
+
+%%% ========== NSUBST
+%%% ========== NSUBST-IF
+%%% ========== NSUBST-IF-NOT
+%%% ========== SUBST
+%%% ========== SUBST-IF
+%%% ========== SUBST-IF-NOT
+\begincom{subst, subst-if, subst-if-not, nsubst, nsubst-if, nsubst-if-not}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues subst         {new old  tree {\key} key test test-not} {new-tree}
+\DefunWithValues subst-if      {new predicate tree {\key} key} {new-tree}
+\DefunWithValues subst-if-not  {new predicate tree {\key} key} {new-tree}
+
+\DefunWithValues nsubst        {new old  tree {\key} key test test-not} {new-tree}
+\DefunWithValues nsubst-if     {new predicate tree {\key} key} {new-tree}
+\DefunWithValues nsubst-if-not {new predicate tree {\key} key} {new-tree}
+
+\label Arguments and Values:: 
+
+\param{new}---an \term{object}.
+
+\param{old}---an \term{object}.
+
+\param{predicate}---a \term{symbol} that names a \term{function},
+   or a \term{function} of one argument 
+      that returns a \term{generalized boolean} value.
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{tree}---a \term{tree}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{new-tree}---a \term{tree}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label Description::
+
+\funref{subst}, \funref{subst-if}, and \funref{subst-if-not} perform
+substitution operations on \param{tree}.  
+Each function searches \param{tree} for occurrences of a 
+particular \param{old} item of an element or subexpression that 
+\term{satisfies the test}.
+
+\funref{nsubst}, \funref{nsubst-if}, and \funref{nsubst-if-not} are 
+like \funref{subst},
+\funref{subst-if}, and \funref{subst-if-not} respectively, except that the 
+original \param{tree} is  modified.
+
+%% 15.4.0 4
+\funref{subst} makes a copy of \param{tree},
+substituting \param{new} for every subtree or leaf of \param{tree}
+(whether the subtree or leaf is a \term{car} or a \term{cdr} of its parent)
+such that \param{old} and the subtree or leaf \term{satisfy the test}.  
+
+%% 15.4.0 7
+\funref{nsubst} is a destructive version of \funref{subst}.  
+The list structure of
+\param{tree} is altered by destructively replacing with \param{new}
+each leaf of the \param{tree} such that \param{old} and the leaf
+\term{satisfy the test}.
+
+%% Implied by "satisfy the test".
+% Either \kwd{test} or \kwd{test-not} can
+% be used to supply a test function other than the default.
+% The first argument to the \kwd{test} or \kwd{test-not} function
+% is \param{old};
+% the second argument is 
+% the part of an element of \param{tree} 
+% extracted by the \kwd{key} function (if supplied).
+% The argument to the \kwd{key} function is an
+% element of \param{tree}; the return value is part of the supplied
+% argument.
+% If \kwd{key} is not supplied, the element from
+% \param{tree} is supplied to the \kwd{test} or \kwd{test-not} function.
+
+For \funref{subst}, \funref{subst-if}, 
+and \funref{subst-if-not},
+if the functions succeed, a new
+copy of the tree is returned in which each  occurrence of such an
+element is replaced by the
+\param{new} element or subexpression.  If no changes are made, the original 
+\param{tree} may be returned.
+The original \param{tree} is left unchanged, but the result tree 
+may share storage with it.           
+
+For \funref{nsubst}, \funref{nsubst-if}, 
+and \funref{nsubst-if-not}
+the original \param{tree} is  modified and returned as the function result,
+but the result may not be \funref{eq} to \param{tree}.
+%!!! Barmar: Huh??? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+\label Examples::
+
+%% 15.4.0 6
+\code
+ (setq tree1 '(1 (1 2) (1 2 3) (1 2 3 4))) \EV (1 (1 2) (1 2 3) (1 2 3 4))
+ (subst "two" 2 tree1) \EV (1 (1 "two") (1 "two" 3) (1 "two" 3 4))
+ (subst "five" 5 tree1) \EV (1 (1 2) (1 2 3) (1 2 3 4))
+ (eq tree1 (subst "five" 5 tree1)) \EV \term{implementation-dependent}
+ (subst 'tempest 'hurricane
+        '(shakespeare wrote (the hurricane)))
+\EV (SHAKESPEARE WROTE (THE TEMPEST))
+ (subst 'foo 'nil '(shakespeare wrote (twelfth night)))
+\EV (SHAKESPEARE WROTE (TWELFTH NIGHT . FOO) . FOO)
+ (subst '(a . cons) '(old . pair)
+        '((old . spice) ((old . shoes) old . pair) (old . pair))
+        :test #'equal)
+\EV ((OLD . SPICE) ((OLD . SHOES) A . CONS) (A . CONS))
+
+ (subst-if 5 #'listp tree1) \EV 5
+ (subst-if-not '(x) #'consp tree1) 
+\EV (1 X)
+
+ tree1 \EV (1 (1 2) (1 2 3) (1 2 3 4))
+ (nsubst 'x 3 tree1 :key #'(lambda (y) (and (listp y) (third y)))) 
+\EV (1 (1 2) X X)
+ tree1 \EV (1 (1 2) X X)
+\endcode
+
+\label Side Effects::
+
+%% 15.4.0 7
+\funref{nsubst}, \funref{nsubst-if}, and \funref{nsubst-if-not} 
+might alter the \term{tree structure} of \param{tree}.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{substitute},
+\funref{nsubstitute},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification},
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The functions \funref{subst-if-not} and \funref{nsubst-if-not} are deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+One possible definition of \funref{subst}:
+
+%% Indentation fixed per Boyer/Kaufmann/Moore #13 (by X3J13 vote at May 4-5, 1994 meeting)
+%% -kmp 9-May-94
+\code
+ (defun subst (old new tree &rest x &key test test-not key)
+   (cond ((satisfies-the-test old tree :test test
+                              :test-not test-not :key key)
+          new)
+         ((atom tree) tree)
+         (t (let ((a (apply #'subst old new (car tree) x))
+                  (d (apply #'subst old new (cdr tree) x)))
+              (if (and (eql a (car tree))
+                       (eql d (cdr tree)))
+                  tree
+                  (cons a d))))))
+\endcode
+\endcom
+
+%%% ========== TREE-EQUAL
+\begincom{tree-equal}\ftype{Function}
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label Syntax::
+
+\DefunWithValues tree-equal {tree-1 tree-2 {\key} test test-not} {generalized-boolean}
+
+\label Arguments and Values:: 
+
+\param{tree-1}---a \term{tree}.
+
+\param{tree-2}---a \term{tree}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 15.1.0 8
+\funref{tree-equal} tests whether two trees are of the same shape
+and have the same leaves.  
+\funref{tree-equal} returns \term{true} if \param{tree-1} and \param{tree-2}  are 
+both \term{atoms} and \term{satisfy the test},
+or if they are both \term{conses} and
+the \term{car} of \param{tree-1} is \funref{tree-equal} to
+the \term{car} of \param{tree-2} and
+the \term{cdr} of \param{tree-1} is \funref{tree-equal} to
+the \term{cdr} of \param{tree-2}.  
+Otherwise, \funref{tree-equal} returns \term{false}.
+
+\funref{tree-equal} recursively compares \term{conses} but not any 
+other \term{objects} that have components.  
+
+The first argument to the \kwd{test} or \kwd{test-not} 
+function is \param{tree-1} or a \term{car} or \term{cdr} of \param{tree-1};
+the second argument is \param{tree-2} or a \term{car} 
+or \term{cdr} of \param{tree-2}.
+
+\label Examples::
+
+\code
+ (setq tree1 '(1 (1 2))
+       tree2 '(1 (1 2))) \EV (1 (1 2))
+ (tree-equal tree1 tree2) \EV \term{true}
+ (eql tree1 tree2) \EV \term{false}
+ (setq tree1 '('a ('b 'c))
+       tree2 '('a ('b 'c))) \EV ('a ('b 'c)) 
+\EV ((QUOTE A) ((QUOTE B) (QUOTE C)))
+ (tree-equal tree1 tree2 :test 'eq) \EV \term{true}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+The consequences are undefined 
+if both \param{tree-1} and \param{tree-2} are circular.
+
+\label See Also::
+
+\funref{equal},
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\endcom
+
+%-------------------- List --------------------
+
+%%% ========== COPY-LIST
+\begincom{copy-list}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues copy-list {list} {copy}
+
+\label Arguments and Values::
+
+\param{list}---a \term{proper list} or a \term{dotted list}.
+
+\param{copy}---a \term{list}.
+
+\label Description::
+
+%% 15.2.0 23
+
+Returns a \term{copy} of \param{list}.
+If \param{list} is a \term{dotted list},
+the resulting \term{list} will also be a \term{dotted list}.
+
+Only the \term{list structure} of \param{list} is copied; 
+the \term{elements} of the resulting list are 
+the \term{same} as the corresponding \term{elements} of the given \param{list}.
+
+\label Examples::    
+
+\code
+ (setq lst (list 1 (list 2 3))) \EV (1 (2 3))
+ (setq slst lst) \EV (1 (2 3))
+ (setq clst (copy-list lst)) \EV (1 (2 3))
+ (eq slst lst) \EV \term{true}
+ (eq clst lst) \EV \term{false}
+ (equal clst lst) \EV \term{true}
+ (rplaca lst "one") \EV ("one" (2 3))
+ slst \EV ("one" (2 3))
+ clst \EV (1 (2 3))
+ (setf (caadr lst) "two") \EV "two"
+ lst \EV ("one" ("two" 3))
+ slst \EV ("one" ("two" 3))
+ clst \EV (1 ("two" 3))
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+The consequences are undefined if \param{list} is a \term{circular list}.
+
+\label See Also::
+
+\funref{copy-alist},
+\funref{copy-seq},
+\funref{copy-tree}
+
+\label Notes::
+
+The copy created is \funref{equal} to \param{list}, but not \funref{eq}.
+
+\endcom
+
+%%% ========== LIST
+%%% ========== LIST*
+\begincom{list, list*}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues {list}  {{\rest} objects} {list}
+\DefunWithValues {list*} {{\rest} \plus{objects}} {result}
+
+\label Arguments and Values:: 
+
+\param{object}---an \term{object}.
+
+\param{list}---a \term{list}.
+
+\param{result}---an \term{object}.
+%A (possibly dotted) list, if at least 2 args are given.
+
+\label Description::
+
+%% 15.2.0 17
+
+\funref{list} returns a \term{list} containing the supplied \param{objects}.  
+
+%% 15.2.0 18
+
+\funref{list*} is like \funref{list} except that 
+the last \term{argument} to \funref{list} becomes 
+the \term{car} of the last \term{cons} constructed, while
+the last \term{argument} to \funref{list*} becomes 
+the \term{cdr} of the last \term{cons} constructed.
+Hence, any given call to \funref{list*} always produces one fewer \term{conses}
+than a call to \funref{list} with the same number of arguments.
+
+If the last \term{argument} to \funref{list*} is a \term{list}, 
+the effect is to construct a new \term{list} which is similar, but
+which has additional elements added to the front corresponding to
+the preceding \term{arguments} of \funref{list*}.
+
+If \funref{list*} receives only one \param{object},
+that \param{object} is returned, regardless of whether or not it is a \term{list}.
+
+\label Examples::
+
+\code
+ (list 1) \EV (1)
+ (list* 1) \EV 1
+ (setq a 1) \EV 1
+ (list a 2) \EV (1 2)
+ '(a 2) \EV (A 2)
+ (list 'a 2) \EV (A 2)
+ (list* a 2) \EV (1 . 2)
+ (list) \EV NIL ;\ie ()
+ (setq a '(1 2)) \EV (1 2)
+ (eq a (list* a)) \EV \term{true}
+ (list 3 4 'a (car '(b . c)) (+ 6 -2)) \EV (3 4 A B 4)
+ (list* 'a 'b 'c 'd) \EQ (cons 'a (cons 'b (cons 'c 'd))) \EV (A B C . D)
+ (list* 'a 'b 'c '(d e f)) \EV (A B C D E F)
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{cons}
+
+\label Notes::
+
+\code
+ (list* \param{x}) \EQ \param{x}
+\endcode
+
+\endcom
+
+%%% ========== LIST-LENGTH
+\begincom{list-length}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues list-length {list} {length}
+
+\label Arguments and Values::
+
+\param{list}---a \term{proper list} or a \term{circular list}.
+
+\param{length}---a non-negative \term{integer}, or \nil.
+
+\label Description::
+
+%% 15.2.0 5
+Returns the \term{length} of \param{list} if \param{list} is a \term{proper list}.
+Returns \nil\ if \param{list} is a \term{circular list}.
+
+\label Examples::
+
+\code
+ (list-length '(a b c d)) \EV 4
+ (list-length '(a (b c) d)) \EV 3
+ (list-length '()) \EV 0
+ (list-length nil) \EV 0
+ (defun circular-list (&rest elements)
+   (let ((cycle (copy-list elements))) 
+     (nconc cycle cycle)))
+ (list-length (circular-list 'a 'b)) \EV NIL
+ (list-length (circular-list 'a)) \EV NIL
+ (list-length (circular-list)) \EV 0
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{list}{a \term{proper list} or a \term{circular list}}
+
+\label See Also::
+
+\funref{length}
+
+\label Notes::
+
+\funref{list-length} could be implemented as follows:
+
+\code
+ (defun list-length (x)  
+   (do ((n 0 (+ n 2))           ;Counter.
+        (fast x (cddr fast))    ;Fast pointer: leaps by 2.
+        (slow x (cdr slow)))    ;Slow pointer: leaps by 1.
+       (nil)
+     ;; If fast pointer hits the end, return the count.
+     (when (endp fast) (return n))
+     (when (endp (cdr fast)) (return (+ n 1)))
+     ;; If fast pointer eventually equals slow pointer,
+     ;;  then we must be stuck in a circular list.
+     ;; (A deeper property is the converse: if we are
+     ;;  stuck in a circular list, then eventually the
+     ;;  fast pointer will equal the slow pointer.
+     ;;  That fact justifies this implementation.)
+     (when (and (eq fast slow) (> n 0)) (return nil))))
+ 
+\endcode
+
+\endcom
+
+%%% ========== LISTP
+\begincom{listp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues listp {object} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 6.2.2 10
+\TypePredicate{object}{list}
+
+\label Examples::
+\code
+ (listp nil) \EV \term{true}
+ (listp (cons 1 2)) \EV \term{true}
+ (listp (make-array 6)) \EV \term{false}
+ (listp t) \EV \term{false}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\funref{consp}
+
+\label Notes::
+
+%This is implied by type list, but still worth saying. -kmp
+
+If \param{object} is a \term{cons},
+\funref{listp} does not check whether \param{object} is a \term{proper list};
+it returns \term{true} for any kind of \term{list}.
+
+\code
+ (listp \param{object}) \EQ (typep \param{object} 'list) \EQ (typep \param{object} '(or cons null))
+\endcode
+
+\endcom
+
+%%% ========== MAKE-LIST
+\begincom{make-list}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues make-list {size {\key} initial-element} {list}
+                                   
+\label Arguments and Values::
+
+\param{size}---a non-negative \term{integer}.
+
+\param{initial-element}---an \term{object}.
+  \Default{\nil}
+
+\param{list}---a \term{list}.
+
+\label Description::
+
+%% 15.2.0 19
+Returns a \term{list} of \param{length} given by \term{size},
+each of the \term{elements} of which is \param{initial-element}.
+
+\label Examples::
+\code
+ (make-list 5) \EV (NIL NIL NIL NIL NIL)
+ (make-list 3 :initial-element 'rah) \EV (RAH RAH RAH)
+ (make-list 2 :initial-element '(1 2 3)) \EV ((1 2 3) (1 2 3))
+ (make-list 0) \EV NIL ;\ie ()
+ (make-list 0 :initial-element 'new-element) \EV NIL 
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{size}{a non-negative \term{integer}}
+
+\label See Also::
+
+\funref{cons},
+\funref{list}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- List Elements --------------------
+
+%%% ========== PUSH
+\begincom{push}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues push {item place} {new-place-value}
+
+\label Arguments and Values::
+
+\param{item}---an \term{object}. 
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{place}---a \term{place}, the \term{value} of which may be any \term{object}.  
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{new-place-value}---a \term{list} (the new \term{value} of \param{place}).
+
+\label Description::
+
+\macref{push} prepends \param{item} to the \term{list} that is stored
+in \param{place}, stores the resulting \term{list} in \param{place}, 
+and returns the \term{list}.
+
+\issue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+For information about the \term{evaluation} of \term{subforms} of \param{place},
+\seesection\GenRefSubFormEval.
+\endissue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+
+\label Examples::
+%% 15.2.0 31
+\code
+ (setq llst '(nil)) \EV (NIL)
+ (push 1 (car llst)) \EV (1)
+ llst \EV ((1))
+ (push 1 (car llst)) \EV (1 1)
+ llst \EV ((1 1))
+ (setq x '(a (b c) d)) \EV (A (B C) D)
+ (push 5 (cadr x)) \EV (5 B C)  
+ x \EV (A (5 B C) D)
+\endcode
+
+\label Side Effects::
+
+The contents of \param{place} are modified.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{pop},
+\macref{pushnew},
+{\secref\GeneralizedReference}
+
+\label Notes::
+The effect of \f{(push \i{item} \i{place})}
+is equivalent to
+
+\code
+ (setf place (cons \i{item} \i{place}))
+\endcode
+\issue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+except that the \term{subforms} of \param{place} 
+are evaluated only once, and \param{item} is evaluated
+before \param{place}.
+\endissue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+
+\endcom
+
+%%% ========== POP
+\begincom{pop}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues pop {place} {element}
+
+\label Arguments and Values:: 
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{place}---a \term{place}, the \term{value} of which is a \term{list}
+   (possibly, but necessarily, a \term{dotted list} or \term{circular list}).
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{element}---an \term{object} (the \term{car} of the contents of \param{place}).
+
+\label Description::
+
+%% 15.2.0 35
+\macref{pop} \term{reads} the \term{value} of \param{place},
+remembers the \term{car} of the \term{list} which was retrieved,
+\term{writes} the \term{cdr} of the \term{list} back into the \param{place},
+and finally \term{yields} the \term{car} of the originally retrieved \term{list}.
+
+\issue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+For information about the \term{evaluation} of \term{subforms} of \param{place},
+\seesection\GenRefSubFormEval.
+\endissue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+
+\label Examples::
+
+\code
+ (setq stack '(a b c)) \EV (A B C)
+ (pop stack) \EV A  
+ stack \EV (B C)
+ (setq llst '((1 2 3 4))) \EV ((1 2 3 4))
+ (pop (car llst)) \EV 1
+ llst \EV ((2 3 4))
+\endcode
+
+\label Side Effects::
+
+The contents of \param{place} are modified.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{push},
+\macref{pushnew},
+{\secref\GeneralizedReference}
+
+\label Notes::
+
+The effect of \f{(pop \param{place})} is roughly equivalent to
+
+\code
+ (prog1 (car \param{place}) (setf \param{place} (cdr \param{place})))
+\endcode
+except that the latter would evaluate any \term{subforms} of \param{place}
+three times, while \macref{pop} evaluates them only once.
+
+
+\endcom
+
+
+%%% ========== FIRST
+%%% ========== SECOND
+%%% ========== THIRD
+%%% ========== FOURTH
+%%% ========== FIFTH
+%%% ========== SIXTH
+%%% ========== SEVENTH
+%%% ========== EIGHTH
+%%% ========== NINTH
+%%% ========== TENTH
+\begincom{first, second, third, fourth, fifth, 
+	  sixth, seventh, eighth, ninth, tenth}\ftype{Accessor}
+         
+\label Syntax::
+
+\DefunMultiAccessorWithValues {list} {object} {new-object}
+ {\entry{first}
+  \entry{second}
+  \entry{third}
+  \entry{fourth}
+  \entry{fifth}
+  \entry{sixth}
+  \entry{seventh}
+  \entry{eighth}
+  \entry{ninth}
+  \entry{tenth}}
+
+\label Arguments and Values::
+
+\param{list}---a \term{list}, 
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+	       which might be a \term{dotted list} or a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{object}, \param{new-object}---an \param{object}.
+
+\label Description::
+
+The functions
+%% 15.2.0 11
+\funref{first},
+\funref{second},
+\funref{third}, 
+\funref{fourth}, 
+\funref{fifth},
+\funref{sixth},
+\funref{seventh},
+\funref{eighth}, 
+\funref{ninth},
+and
+\funref{tenth}
+%% 15.2.0 12
+\param{access} the first, second, third, fourth, fifth, sixth, seventh, eighth,
+ninth, and tenth \term{elements} of \param{list}, respectively.
+%% I changed this to be in terms of car/cdr because I felt this made 
+%% the error checking requirements more apparent. -kmp 27-Aug-93
+% If there is no such \term{element} during a \term{read}, \nil\ is returned.
+% The consequences are undefined if there is no such \term{element} during a \term{write}.
+Specifically,
+
+\code
+ (first \param{list})    \EQ  (car \param{list})
+ (second \param{list})   \EQ  (car (cdr \param{list}))
+ (third \param{list})    \EQ  (car (cddr \param{list}))
+ (fourth \param{list})   \EQ  (car (cdddr \param{list}))
+ (fifth \param{list})    \EQ  (car (cddddr \param{list}))
+ (sixth \param{list})    \EQ  (car (cdr (cddddr \param{list})))
+ (seventh \param{list})  \EQ  (car (cddr (cddddr \param{list})))
+ (eighth \param{list})   \EQ  (car (cdddr (cddddr \param{list})))
+ (ninth \param{list})    \EQ  (car (cddddr (cddddr \param{list})))
+ (tenth \param{list})    \EQ  (car (cdr (cddddr (cddddr \param{list}))))
+\endcode
+
+\macref{setf} can also be used with any of these functions to change an
+existing component.  The same equivalences apply.  For example:
+
+\code
+ (setf (fifth \param{list}) \param{new-object}) \EQ (setf (car (cddddr \param{list})) \param{new-object})
+\endcode
+
+\label Examples::
+
+\code
+ (setq lst '(1 2 3 (4 5 6) ((V)) vi 7 8 9 10)) 
+\EV (1 2 3 (4 5 6) ((V)) VI 7 8 9 10)
+ (first lst) \EV 1
+ (tenth lst) \EV 10
+ (fifth lst) \EV ((V))
+ (second (fourth lst)) \EV 5
+ (sixth '(1 2 3)) \EV NIL
+ (setf (fourth lst) "four") \EV "four"
+ lst \EV (1 2 3 "four" ((V)) VI 7 8 9 10)
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{car}, \funref{nth}
+
+\label Notes::
+
+\funref{first}  is functionally equivalent to \funref{car},
+\funref{second} is functionally equivalent to \funref{cadr},
+\funref{third}  is functionally equivalent to \funref{caddr}, and 
+\funref{fourth} is functionally equivalent to \funref{cadddr}.
+
+The ordinal numbering used here is one-origin,
+as opposed to the zero-origin numbering used by \funref{nth}:
+
+\code
+ (fifth x) \EQ (nth 4 x)
+\endcode
+
+\endcom
+
+%%% ========== NTH
+\begincom{nth}\ftype{Accessor}
+
+\label Syntax::
+
+\DefunWithValues nth {n list} {object}
+\Defsetf         nth {n list} {new-object}
+
+\label Arguments and Values::
+
+\param{n}---a non-negative \term{integer}.
+
+\param{list}---a \term{list},
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+	       which might be a \term{dotted list} or a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{object}---an \term{object}.
+
+\param{new-object}---an \term{object}.
+
+\label Description::
+
+\funref{nth} locates the \param{n}th element of \param{list},
+where the \term{car} of the \param{list} is the ``zeroth'' element.
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% If the length of \param{list} is not greater than \param{n}, 
+% then the result is \nil.
+Specifically,
+
+\code
+ (nth \param{n} \param{list}) \EQ (car (nthcdr \param{n} \param{list}))
+\endcode
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+%% 15.2.0 8
+
+\funref{nth} may be used to specify a \param{place} to \macref{setf}.
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+Specifically,
+% when \funref{nth} is used in this way, \param{n} must be less
+% than the length of the \param{list}.
+
+\code
+ (setf (nth \param{n} \param{list}) \param{new-object}) \EQ (setf (car (nthcdr \param{n} \param{list})) \param{new-object})
+\endcode
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label Examples::
+
+%% 15.2.0 6
+\code
+ (nth 0 '(foo bar baz)) \EV FOO
+ (nth 1 '(foo bar baz)) \EV BAR
+ (nth 3 '(foo bar baz)) \EV NIL
+ (setq 0-to-3 (list 0 1 2 3)) \EV (0 1 2 3)
+ (setf (nth 2 0-to-3) "two") \EV "two"
+ 0-to-3 \EV (0 1 "two" 3)
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{elt},
+\funref{first},
+\funref{nthcdr}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- List Tails --------------------
+
+%%% ========== ENDP
+\begincom{endp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues endp {list} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{list}---a \term{list},
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+	       which might be a \term{dotted list} or a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 15.2.0 3
+Returns \term{true}  if \param{list} is the \term{empty list}.
+Returns \term{false} if \param{list} is a \term{cons}.
+
+\label Examples::
+
+\code
+ (endp nil) \EV \term{true}
+ (endp '(1 2)) \EV \term{false}
+ (endp (cddr '(1 2))) \EV \term{true}
+\endcode
+                              
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{list}{a \term{list}}
+
+\label See Also:\None.
+
+\label Notes::
+
+The purpose of \funref{endp} is to test for the end of \param{proper list}.
+Since \funref{endp} does not descend into a \term{cons}, 
+it is well-defined to pass it a \term{dotted list}.
+However, if shorter ``lists'' are iteratively produced 
+by calling \funref{cdr} on such a \term{dotted list} 
+and those ``lists'' are tested with \funref{endp},
+a situation that has undefined consequences will eventually result 
+when the \term{non-nil} \term{atom} (which is not in fact a \term{list})
+finally becomes the argument to \funref{endp}.
+Since this is the usual way in which \funref{endp} is used,
+it is conservative programming style 
+and consistent with the intent of \funref{endp}
+to treat \funref{endp} as simply a function on \term{proper lists} 
+which happens not to enforce an argument type of \term{proper list} except
+when the argument is \term{atomic}.
+
+\endcom
+
+%%% ========== NULL
+\begincom{null}\ftype{Function}
+
+\issue{NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93}
+
+\label Syntax::
+
+\DefunWithValues null {object} {boolean}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\param{boolean}---a \term{boolean}.
+
+\label Description::
+
+%% 6.2.2 3
+\StrictPredicate{object}{the \term{empty list}}
+
+\label Examples::   
+
+\code
+ (null '()) \EV T
+ (null nil) \EV T
+ (null t) \EV NIL
+ (null 1) \EV NIL
+\endcode
+
+\endissue{NOT-AND-NULL-RETURN-VALUE:X3J13-MAR-93}
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\funref{not}
+
+\label Notes::
+
+%% 6.4.0 4
+\funref{null} is intended to be used to test for the \term{empty list}
+whereas \funref{not} is intended to be used to invert a \term{boolean}
+(or \term{generalized boolean}).
+Operationally, \funref{null} and \funref{not} compute the same result;
+which to use is a matter of style.
+
+\code
+ (null \param{object}) \EQ (typep \param{object} 'null) \EQ (eq \param{object} '\empty)
+\endcode
+
+\endcom
+
+%%% ========== NCONC
+\begincom{nconc}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues nconc {{\rest} lists} {concatenated-list}
+
+\label Arguments and Values::
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{list}---each but the last must be a \term{list} 
+	(which might be a \param{dotted list} but must not be a \term{circular list});
+        the last \param{list} may be any \term{object}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{concatenated-list}---a \term{list}.
+
+\label Description::
+
+% Note: Issue APPEND-DOTTED was repealed.
+
+%% 15.2.0 28
+Returns a \term{list} that is the concatenation of \param{lists}.
+If no \param{lists} are supplied, \f{(nconc)} returns \nil.
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\funref{nconc} is defined using the following recursive relationship:
+ 
+\code
+ (nconc) \EV ()
+ (nconc nil . \param{lists}) \EQ (nconc . \param{lists})
+ (nconc \param{list}) \EV \param{list}
+ (nconc \param{list-1} \param{list-2}) \EQ (progn (rplacd (last \param{list-1}) \param{list-2}) \param{list-1})
+ (nconc \param{list-1} \param{list-2} . \param{lists}) \EQ (nconc (nconc \param{list-1} \param{list-2}) . \param{lists})
+\endcode
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+
+\label Examples::
+
+\code
+ (nconc) \EV NIL
+ (setq x '(a b c)) \EV (A B C)
+ (setq y '(d e f)) \EV (D E F)
+ (nconc x y) \EV (A B C D E F)
+ x \EV (A B C D E F)
+\endcode
+Note, in the example, that the value of \f{x} is now different,
+since its last \term{cons} 
+has been \funref{rplacd}'d to the value of \f{y}.
+If \f{(nconc x y)} were evaluated again,
+it would yield a piece of a \term{circular list},
+whose printed representation would be
+\f{(A B C D E F D E F D E F ...)}, repeating forever;
+if the \varref{*print-circle*} switch were \term{non-nil},
+it would be printed as \f{(A B C . \#1=(D E F . \#1\#))}.
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\code
+ (setq foo (list 'a 'b 'c 'd 'e)
+       bar (list 'f 'g 'h 'i 'j)
+       baz (list 'k 'l 'm)) \EV (K L M)
+ (setq foo (nconc foo bar baz)) \EV (A B C D E F G H I J K L M)
+ foo \EV (A B C D E F G H I J K L M)
+ bar \EV (F G H I J K L M)
+ baz \EV (K L M)
+
+ (setq foo (list 'a 'b 'c 'd 'e)
+       bar (list 'f 'g 'h 'i 'j)
+       baz (list 'k 'l 'm)) \EV (K L M)
+ (setq foo (nconc nil foo bar nil baz)) \EV (A B C D E F G H I J K L M) 
+ foo \EV (A B C D E F G H I J K L M)
+ bar \EV (F G H I J K L M)
+ baz \EV (K L M)
+\endcode
+
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+\label Side Effects::
+
+The \param{lists} are modified rather than copied.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None?
+
+\label See Also::
+
+\funref{append}, \funref{concatenate}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== APPEND
+\begincom{append}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues append {{\rest} lists} {result}
+
+\label Arguments and Values:: 
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{list}---each must be a \term{proper list} except the last,
+	       which may be any \term{object}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{result}---an \term{object}.  This will be a \term{list}
+		 unless the last \param{list} was not a \term{list}
+%Sandra noted a but in the preceding.
+        	    and all preceding \param{lists} were \term{null}.
+
+
+\label Description::
+
+%% Issue APPEND-DOTTED had an effect here, but was later rescinded.
+
+%% 15.2.0 20
+\funref{append} returns a new \param{list} that is the concatenation of
+the copies.  \param{lists} are left unchanged; the \term{list structure} 
+of each of \param{lists} except the last is copied.
+%% 15.2.0 21
+The last argument is not copied; it becomes the \term{cdr} of the 
+final \term{dotted pair} of the concatenation of the preceding \param{lists},
+or is returned directly if there are no preceding
+% "non-empty" added with encouragement of Sandra and KAB. -kmp 28-Jan-92
+\term{non-empty} 
+\param{lists}.
+
+\label Examples::
+
+\code
+ (append '(a b c) '(d e f) '() '(g)) \EV (A B C D E F G)
+ (append '(a b c) 'd) \EV (A B C . D)
+ (setq lst '(a b c)) \EV (A B C)
+ (append lst '(d)) \EV (A B C D)
+ lst \EV (A B C)
+ (append) \EV NIL
+ (append 'a) \EV A
+\endcode
+ 
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{nconc}, \funref{concatenate}
+
+\label Notes:\None.
+
+\endcom
+
+%% Entries for REVAPPEND and NCONC consolidated. -kmp 29-Aug-93
+
+%%% ========== REVAPPEND
+%%% ========== NRECONC
+
+\begincom{revappend, nreconc}\ftype{Function}
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label Syntax::
+
+\DefunWithValues revappend {list tail} {result-list}
+\DefunWithValues nreconc   {list tail} {result-list}
+
+\label Arguments and Values::
+
+\param{list}---a \term{proper list}.
+
+\param{tail}---an \term{object}. 
+
+\param{result-list}---an \term{object}.
+
+\label Description::
+
+\funref{revappend} constructs a \term{copy}\meaning{2} of \param{list},
+but with the \term{elements} in reverse order.  It then appends (as if
+by \funref{nconc}) the \param{tail} to that reversed list and returns the result.
+
+\funref{nreconc} reverses the order of \term{elements} in \param{list}
+(as if by \funref{nreverse}).  It then appends (as if by \funref{nconc})
+the \param{tail} to that reversed list and returns the result.
+
+The resulting \term{list} shares \term{list structure} with \param{tail}.
+
+\label Examples::
+
+\code
+ (let ((list-1 (list 1 2 3))
+       (list-2 (list 'a 'b 'c)))
+   (print (revappend list-1 list-2))
+   (print (equal list-1 '(1 2 3)))
+   (print (equal list-2 '(a b c))))
+\OUT (3 2 1 A B C) 
+\OUT T
+\OUT T
+\EV T
+
+ (revappend '(1 2 3) '()) \EV (3 2 1)
+ (revappend '(1 2 3) '(a . b)) \EV (3 2 1 A . B)
+ (revappend '() '(a b c)) \EV (A B C)
+ (revappend '(1 2 3) 'a) \EV (3 2 1 . A)
+ (revappend '() 'a) \EV A   ;degenerate case
+
+ (let ((list-1 '(1 2 3))
+       (list-2 '(a b c)))
+   (print (nreconc list-1 list-2))
+   (print (equal list-1 '(1 2 3)))
+   (print (equal list-2 '(a b c))))
+\OUT (3 2 1 A B C) 
+\OUT NIL
+\OUT T
+\EV T
+
+\endcode
+
+\label Side Effects::
+
+\funref{revappend} does not modify either of its \term{arguments}.
+\funref{nreconc} is permitted to modify \param{list} but not \param{tail}.
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+Although it might be implemented differently,
+\funref{nreconc} is constrained to have side-effect behavior equivalent to:
+
+\code
+ (nconc (nreverse \param{list}) \param{tail})
+\endcode
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{reverse},
+\funref{nreverse},
+\funref{nconc}
+
+\label Notes::
+
+%% 15.2.0 27
+%% 15.2.0 30
+
+The following functional equivalences are true, 
+although good \term{implementations} will typically use a faster algorithm for
+achieving the same effect:
+
+\code
+ (revappend \param{list} \param{tail}) \EQ (nconc (reverse \param{list}) \param{tail})
+ (nreconc \param{list} \param{tail}) \EQ (nconc (nreverse \param{list}) \param{tail})
+\endcode
+
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\endcom
+
+
+
+%% Entries for REVAPPEND and NCONC consolidated. -kmp 29-Aug-93
+% %%% ========== NRECONC
+% \begincom{nreconc}\ftype{Function}
+% 
+% \label Syntax::
+% 
+% \DefunWithValues nreconc {list-1 list-2} {result-list}
+% 
+% \label Arguments and Values:: 
+% 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \param{list-1}---a \term{proper list}.
+% 
+% \param{list-2}---an \term{object}.
+% 
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \param{result-list}---an \term{object}. 
+% 
+% \label Description::
+% 
+% \funref{nreconc} reverses the order of the elements in 
+% \param{list-1} and appends \param{list-2} to \param{list-1} 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% (as if by \funref{nconc}).
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% The new \param{list-1} is returned.
+% 
+% \label Examples::
+% 
+% \code
+%  (defparameter *list-1* (list 1 2 3))
+%  (defparameter *list-2* (list 'a 'b 'c))
+%  (nreconc *list-1* *list-2*) \EV (3 2 1 A B C)
+%  *list-1* \EV \term{implementation-dependent}
+%  *list-2* \EV (A B C)
+% 
+%  (nreconc (list) 'a) \EV A  ;degenerate situation
+% \endcode
+% 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% % \code
+% %  (nreconc (cons 1 2) nil) \EV (1)
+% % \endcode
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \label Side Effects::
+% 
+% \param{list-1} is modified.
+% 
+% \issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+% \funref{nreconc} is constrained to have side-effect behavior equivalent to:
+% 
+% \f{(nconc (nreverse \param{list-1}) \param{list-2})}.
+% \endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+% 
+% \label Affected By:\None.
+% 
+% \label Exceptional Situations:\None?
+% 
+% \label See Also::
+% 
+% \funref{revappend}
+% 
+% \label Notes::
+% %% 15.2.0 30
+% \f{(nreconc x y)} is exactly the same as 
+% \f{(nconc (nreverse x) y)} except that it is potentially more efficient.
+% 
+% \endcom
+
+%% Entries for REVAPPEND and NCONC consolidated. -kmp 29-Aug-93
+% %%% ========== REVAPPEND
+% \begincom{revappend}\ftype{Function}
+% 
+% \label Syntax::
+% 
+% \DefunWithValues revappend {list-1 list-2} {result-list}
+% 
+% \label Arguments and Values::
+% 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% \param{list-1}---a \term{proper list}.
+% 
+% \param{list-2}---an \term{object}. 
+% 
+% \param{result-list}---an \term{object}.
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \label Description::
+% 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% Constructs a \term{fresh} \term{list} that is a \term{copy} of \param{list-1}
+% but with the \term{elements} in reverse order,
+% and then appends \param{list-2} to that \term{list}
+% (as if by \funref{nconc}).
+% %(as if by \funref{append}).
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% The resulting \term{list} shares \term{list structure} with \param{list-2}.
+% 
+% \label Examples::
+% 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% \code
+%  (setq lst1 '(1 2 3)
+%         lst2 '(a b c))  \EV (A B C)
+%  (revappend lst1 lst2) \EV (3 2 1 A B C)
+%  lst1 \EV (1 2 3)
+%  lst2 \EV (A B C)
+%  (revappend '(1 2 3) '(a . b)) \EV (3 2 1 A . B)
+%  (revappend nil '(a b c)) \EV (A B C)
+%  (revappend '() 'a) \EV A ;degenerate case
+% \endcode
+% 
+% % \code
+% %  (revappend '(1 . 2) '(a b c)) \EV (1 A B C)
+% % \endcode
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \label Side Effects:\None.
+% 
+% \label Affected By:\None.
+% 
+% \label Exceptional Situations:\None.
+% 
+% \label See Also::
+% 
+% \funref{nreconc}
+% 
+% \label Notes::
+% %% 15.2.0 27
+% 
+% %"reverse" => "nconc" per Barrett
+% \code
+%  (revappend x y) \EQ (nconc (reverse x) y)
+% \endcode
+% 
+% \endcom
+
+%%% ========== NBUTLAST
+%%% ========== BUTLAST
+\begincom{butlast, nbutlast}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues butlast  {list {\opt} n} {result-list}
+\DefunWithValues nbutlast {list {\opt} n} {result-list}
+
+\label Arguments and Values::
+
+\param{list}---a \term{list}, 
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+	       which might be a \term{dotted list} but must not be a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\issue{BUTLAST-NEGATIVE:SHOULD-SIGNAL}
+\param{n}---a non-negative \term{integer}.
+\endissue{BUTLAST-NEGATIVE:SHOULD-SIGNAL}
+
+\param{result-list}---a \term{list}.
+
+\label Description::
+
+%% 15.2.0 36
+\funref{butlast} returns a copy of \param{list} from which the last
+\param{n}
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+%elements
+conses
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+have been omitted.
+If \param{n} is not supplied, its value is 1.  
+If there are fewer than \param{n} 
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+%elements
+conses
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+in \param{list},
+\nil\ is returned and, in the case of \funref{nbutlast},
+\param{list} is not modified.  
+%Barmar notes that if there are n elements, NIL is returned, too.
+%He suggests says "fewer than n+1".
+%But KMP thinks the definition already covers that, and the reason for the
+%exception about NIL is to clarify the behavior in the cases not covered.
+
+%% 15.2.0 37
+\funref{nbutlast} is like \funref{butlast}, but \funref{nbutlast} 
+may modify \param{list}.
+It changes the \term{cdr} of
+the \term{cons} \param{n}+1 from the end of the \param{list} to \nil.  
+
+\label Examples::
+\code
+ (setq lst '(1 2 3 4 5 6 7 8 9)) \EV (1 2 3 4 5 6 7 8 9)
+ (butlast lst) \EV (1 2 3 4 5 6 7 8)
+ (butlast lst 5) \EV (1 2 3 4)
+ (butlast lst (+ 5 5)) \EV NIL
+ lst \EV (1 2 3 4 5 6 7 8 9)
+ (nbutlast lst 3) \EV (1 2 3 4 5 6)
+ lst \EV (1 2 3 4 5 6)
+ (nbutlast lst 99) \EV NIL
+ lst \EV (1 2 3 4 5 6)
+ (butlast '(a b c d)) \EV (A B C)
+ (butlast '((a b) (c d))) \EV ((A B))
+ (butlast '(a)) \EV NIL
+ (butlast nil) \EV NIL
+ (setq foo (list 'a 'b 'c 'd)) \EV (A B C D)
+ (nbutlast foo) \EV (A B C)
+ foo \EV (A B C)
+ (nbutlast (list 'a)) \EV NIL
+ (nbutlast '()) \EV NIL
+\endcode
+
+% The following example was present but no one could figure out what
+% made anyone think this would reliably work, so I removed it. -kmp 14-Feb-92
+%
+% (butlast '(1 2 . 3)) \EV (1)
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\Shouldchecktype{list}{a \term{proper list} or a \term{dotted list}}
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\issue{BUTLAST-NEGATIVE:SHOULD-SIGNAL}
+\Shouldchecktype{n}{a non-negative \term{integer}}
+\endissue{BUTLAST-NEGATIVE:SHOULD-SIGNAL}
+
+\label See Also:\None.
+
+\label Notes::
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\code
+ (butlast \param{list} \param{n}) \EQ (ldiff \param{list} (last \param{list} \param{n}))
+\endcode
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\endcom      
+
+%%% ========== LAST
+\begincom{last}\ftype{Function}      
+
+\label Syntax::
+
+\DefunWithValues last {list {\opt} n} {tail}
+
+\label Arguments and Values::
+
+\param{list}---a \term{list},
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+               which might be a \term{dotted list} but must not be a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\issue{LAST-N}
+\param{n}---a non-negative \term{integer}.
+ \Default{\f{1}}
+\endissue{LAST-N}
+
+\param{tail}---an \term{object}.
+
+\label Description::
+
+\issue{LAST-N}
+%% 15.2.0 16
+\funref{last} returns the last \param{n} \term{conses} 
+ (not the last \param{n} elements) of \param{list}).
+If \param{list} is \empty, \funref{last} returns \empty.
+
+If \param{n} is zero,
+  the atom that terminates \param{list} is returned.
+If \param{n} is greater than or equal to the number of \term{cons} cells in \param{list},
+  the result is \param{list}.
+\endissue{LAST-N}
+
+\label Examples::
+
+\issue{LAST-N}
+\code
+ (last nil) \EV NIL
+ (last '(1 2 3)) \EV (3)
+ (last '(1 2 . 3)) \EV (2 . 3)
+ (setq x (list 'a 'b 'c 'd)) \EV (A B C D)
+ (last x) \EV (D)
+ (rplacd (last x) (list 'e 'f)) x \EV (A B C D E F)
+ (last x) \EV (F)
+
+ (last '(a b c))   \EV (C)
+
+ (last '(a b c) 0) \EV ()
+ (last '(a b c) 1) \EV (C)
+ (last '(a b c) 2) \EV (B C)
+ (last '(a b c) 3) \EV (A B C)
+ (last '(a b c) 4) \EV (A B C)
+
+ (last '(a . b) 0) \EV B
+ (last '(a . b) 1) \EV (A . B)
+ (last '(a . b) 2) \EV (A . B)
+\endcode
+\endissue{LAST-N}
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\issue{LAST-N}
+The consequences are undefined if \param{list} is a \term{circular list}.
+\endissue{LAST-N}
+\Shouldchecktype{n}{a non-negative \term{integer}}
+
+\label See Also::
+
+\funref{butlast},
+\funref{nth}
+
+\label Notes::                                             
+
+\issue{LAST-N}
+The following code could be used to define \funref{last}.
+
+\code
+ (defun last (list &optional (n 1))
+   (check-type n (integer 0))
+   (do ((l list (cdr l))
+        (r list)
+        (i 0 (+ i 1)))
+       ((atom l) r)
+     (if (>= i n) (pop r))))
+\endcode
+\endissue{LAST-N}
+\endcom
+
+%% Tentatively merged entries for LDIFF and TAILP. -kmp 29-Aug-93
+
+%%% ========== LDIFF
+%%% ========== TAILP
+\begincom{ldiff, tailp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues ldiff {list object} {result-list}
+\DefunWithValues tailp {object list} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{list}---a \term{list},
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+                   which might be a \term{dotted list}.
+
+\param{object}---an \term{object}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{result-list}---a \term{list}.
+
+%% Per X3J13. -kmp 05-Oct-93
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+\issue{TAILP-NIL:T}
+%% 15.5.0 7
+%% (CLtL definition superseded by later cleanup issue clarifying behavior.)
+If \param{object} is the \term{same} as some \term{tail} of \param{list},
+\funref{tailp} returns \term{true};
+otherwise, it returns \term{false}.
+\endissue{TAILP-NIL:T}
+
+%% 15.2.0 38
+If \param{object} is the \term{same} as some \term{tail} of \param{list},
+\funref{ldiff} returns a \term{fresh} \term{list} 
+of the \term{elements} of \term{list} 
+that precede \funref{object} in the \term{list structure} of \param{list};
+otherwise, it returns a \term{copy}\meaning{2} of \param{list}.
+
+\label Examples::
+
+\issue{TAILP-NIL:T}
+\code
+ (let ((lists '#((a b c) (a b c . d))))
+   (dotimes (i (length lists)) ()
+     (let ((list (aref lists i)))
+       (format t "~2&list=~S ~21T(tailp object list)~
+                  ~44T(ldiff list object)~%" list)
+         (let ((objects (vector list (cddr list) (copy-list (cddr list))
+                                '(f g h) '() 'd 'x)))
+           (dotimes (j (length objects)) ()
+             (let ((object (aref objects j)))
+               (format t "~& object=~S ~21T~S ~44T~S"
+                       object (tailp object list) (ldiff list object))))))))
+\OUT 
+\OUT list=(A B C)         (tailp object list)    (ldiff list object)
+\OUT  object=(A B C)      T                      NIL
+\OUT  object=(C)          T                      (A B)
+\OUT  object=(C)          NIL                    (A B C)
+\OUT  object=(F G H)      NIL                    (A B C)
+\OUT  object=NIL          T                      (A B C)
+\OUT  object=D            NIL                    (A B C)
+\OUT  object=X            NIL                    (A B C)
+\OUT 
+\OUT list=(A B C . D)     (tailp object list)    (ldiff list object)
+\OUT  object=(A B C . D)  T                      NIL
+\OUT  object=(C . D)      T                      (A B)
+\OUT  object=(C . D)      NIL                    (A B C . D)
+\OUT  object=(F G H)      NIL                    (A B C . D)
+\OUT  object=NIL          NIL                    (A B C . D)
+\OUT  object=D            T                      (A B C)
+\OUT  object=X            NIL                    (A B C . D)
+\EV NIL
+\endcode
+\endissue{TAILP-NIL:T}
+
+\label Side Effects::
+
+Neither \funref{ldiff} nor \funref{tailp} modifies either of its \term{arguments}.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\Lazychecktype{list}{a \term{proper list} or a \term{dotted list}}
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\label See Also::
+
+\funref{set-difference}
+
+\label Notes::
+
+If the \param{list} is a \term{circular list},
+\funref{tailp} will reliably \term{yield} a \term{value} 
+only if the given \param{object} is in fact a \term{tail} of \param{list}.
+Otherwise, the consequences are unspecified:
+a given \term{implementation} which detects the circularity must return \term{false},
+but since an \term{implementation} is not obliged to detect such a \term{situation},
+\funref{tailp} might just loop indefinitely without returning in that case.
+
+\issue{TAILP-NIL:T}
+
+\funref{tailp} could be defined as follows:
+
+\code
+ (defun tailp (object list)
+   (do ((list list (cdr list)))
+       ((atom list) (eql list object))
+      (if (eql object list)
+          (return t))))
+\endcode
+
+and \funref{ldiff} could be defined by:
+
+%% !!! I just up the following based on the Description.
+%%     Does everyone agree it's right? -kmp 29-Aug-93
+\code
+(defun ldiff (list object)
+  (do ((list list (cdr list))
+       (r '() (cons (car list) r)))
+      ((atom list)
+       (if (eql list object) (nreverse r) (nreconc r list)))
+    (when (eql object list)
+      (return (nreverse r)))))
+\endcode
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% This stuff probably isn't needed. -kmp 7-Jan-91
+%
+% Since the \param{list} can be a \term{dotted list},
+% the end test must be \funref{atom}, not \funref{endp}.
+% For example, if \f{(tailp \i{x} l)} returns \term{true},
+% it means that there is an \i{n} such that \f{(nthcdr \i{n} \param{list})} returns \i{x}.
+%
+% Note that it doesn't follow that if \term{tailp} returns \nil,
+% it is safe to go \funref{nthcdr}'s into the \param{list} looking
+% for \i{x}, since the \param{list} might be a \term{dotted list}
+% and \funref{nthcdr} might hit bad data.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\endissue{TAILP-NIL:T}
+
+\endcom
+
+% %%% ========== LDIFF
+% \begincom{ldiff}\ftype{Function}
+% 
+% \label Syntax::
+% 
+% \DefunWithValues ldiff {list object} {result-list}
+% 
+% \label Arguments and Values::
+% 
+% \param{list}---a \term{list},
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+%                    which might be a \term{dotted list}.
+% 
+% \param{object}---an \term{object}.
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \param{result-list}---a \term{list}.
+% 
+% \label Description::
+% 
+% %!!! Rewrite in terms of glossary term "sublist" if we can get the issue
+% %    of dottedness resolved. -kmp 27-May-91
+% 
+% %% 15.2.0 38
+% Returns a \term{fresh} \term{list} whose \term{elements} are 
+% those \term{elements} of \param{list} that appear before \param{object}.
+% If \param{object} is not a tail of \param{list} or
+% if \param{object} is \nil,
+% then a copy of the entire \param{list} is returned.
+% \param{list} is not destroyed.
+% 
+% % KMP: Can the list be dotted?
+% %      What is the status of (LDIFF '(A B C . 3) 3)?
+% % Barrett: The description seems to imply that it cannot be dotted.
+% 
+% \label Examples::
+% 
+% \code
+%  (setq x '(a b c d e)) \EV (A B C D E)
+%  (setq y (cdddr x)) \EV (D E)
+%  (ldiff x y) \EV (A B C)
+%  (ldiff x (copy-list y)) \EV (A B C D E)
+% \endcode
+% 
+% \label Side Effects:\None.
+% 
+% \label Affected By:\None.
+% 
+% \label Exceptional Situations::
+% 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% \Lazychecktype{list}{a \term{proper list} or a \term{dotted list}}
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \label See Also::
+% 
+% \funref{tailp},
+% \funref{set-difference}
+% 
+% \label Notes:\None.
+% 
+% \endcom
+% 
+% %%% ========== TAILP
+% \begincom{tailp}\ftype{Function}
+% 
+% \label Syntax::
+% 
+% \DefunWithValues tailp {object list} {generalized-boolean}
+% 
+% \label Arguments and Values:: 
+% 
+% \param{object}---an \term{object}.
+% 
+% \param{list}---a \term{list},
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+%                    which might be a \term{dotted list}.
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \param{generalized-boolean}---a \term{generalized boolean}.
+% 
+% \label Description::
+% 
+% \issue{TAILP-NIL:T}
+% %% 15.5.0 7
+% %% (CLtL definition superseded by later cleanup issue clarifying behavior.)
+% 
+% Returns \term{true} if and only if \param{object} is a \term{tail} of \param{list};
+% otherwise returns \term{false}.  The predicate used for comparison is \funref{eql}.
+% 
+% Since the \param{list} can be a \term{dotted list},
+% the end test used by \funref{tailp} must be \funref{atom}, not \funref{endp}.
+% That is, if \f{(tailp \i{x} l)} returns \term{true},
+% it means that there is an \i{n} such that \f{(nthcdr \i{n} \param{list})} returns \i{x}.
+%  
+% \label Examples::
+% 
+% \code
+%  (let ((x '(b c))) (tailp x (cons 'a x))) \EV \term{true}
+%  (tailp '(x y) '(a b c)) \EV \term{false}
+%  (tailp '() '(a b c)) \EV \term{true}
+%  (tailp 3 '(a b c)) \EV \term{false}
+%  (tailp 3 '(a b c . 3)) \EV \term{true}
+%  (tailp '(x y) '(a b c . 3)) \EV \term{false}
+% \endcode
+% 
+% \endissue{TAILP-NIL:T}
+% 
+% \label Side Effects:\None.
+% 
+% \label Affected By:\None.
+% 
+% \label Exceptional Situations::
+% 
+% \issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% \Lazychecktype{list}{a \term{proper list} or a \term{dotted list}}
+% \endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+% 
+% \label See Also::
+% 
+% \funref{ldiff}
+% 
+% \label Notes::
+% 
+% If the \param{list} is a \term{circular list},
+% \funref{tailp} will reliably \term{yield} a \term{value} 
+% only if the given \param{object} is in fact a \term{subtail}.
+% Otherwise, the consequences are unspecified:
+% a given \term{implementation} which detects the circularity must return \term{false},
+% but since an \term{implementation} is not obliged to detect such a \term{situation},
+% \funref{tailp} might just loop indefinitely without returning in that case.
+% 
+% \issue{TAILP-NIL:T}
+% 
+% \funref{tailp} could be defined as follows:
+% 
+% \code
+%  (defun tailp (sublist list)
+%    (do ((list list (cdr list)))
+%        ((atom list) (eql list sublist))
+%       (if (eql sublist list)
+%           (return t))))
+% \endcode
+% 
+% % This probably isn't needed. -kmp 7-Jan-91
+% %
+% % Note that it doesn't follow that if \term{tailp} returns \nil,
+% % it is safe to go \funref{nthcdr}'s into the \param{list} looking
+% % for \i{x}, since the \param{list} might be a \term{dotted list}
+% % and \funref{nthcdr} might hit bad data.
+% 
+% \endissue{TAILP-NIL:T}
+% 
+% \endcom
+
+%%% ========== NTHCDR
+\begincom{nthcdr}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues nthcdr {n list} {tail}
+
+\label Arguments and Values::
+
+\issue{ARGUMENTS-UNDERSPECIFIED:SPECIFY}
+\param{n}---a non-negative \term{integer}.
+\endissue{ARGUMENTS-UNDERSPECIFIED:SPECIFY}
+
+\param{list}---a \term{list},
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+	       which might be a \term{dotted list} or a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{tail}---an \term{object}.
+%\term{tail} of the \param{list}.
+
+\label Description::
+
+%% 15.2.0 14
+%% Described using more descriptive terminology, 
+%% in a way that doesn't get confused about whether n is 0-based or 1-based. -kmp 29-Aug-93
+%Returns the \param{n}th successive \term{cdr} of \param{list}.
+Returns the \term{tail} of \param{list} that would be obtained by calling \funref{cdr}
+\param{n} times in succession.
+
+\label Examples::
+
+% I added an example of high-safety error, to demonstrate relation of NTHCDR and CDR.
+% -kmp 26-Aug-93
+\code
+ (nthcdr 0 '()) \EV NIL
+ (nthcdr 3 '()) \EV NIL
+ (nthcdr 0 '(a b c)) \EV (A B C)
+ (nthcdr 2 '(a b c)) \EV (C)
+ (nthcdr 4 '(a b c)) \EV ()
+ (nthcdr 1 '(0 . 1)) \EV 1
+
+ (locally (declare (optimize (safety 3)))
+   (nthcdr 3 '(0 . 1)))
+ Error: Attempted to take CDR of 1.
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+%% I added this stuff because it seemed consistent with the other entries. -kmp 26-Aug-93
+
+\Shouldchecktype{n}{a non-negative \term{integer}}
+
+For \param{n} being an integer greater than \f{1},
+the error checking done by \f{(nthcdr \param{n} \param{list})}
+is the same as for \f{(nthcdr (- \param{n} 1) (cdr \param{list}))};
+\seefun{cdr}.
+
+\label See Also::
+
+\funref{cdr},
+\funref{nth},
+\funref{rest}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== REST
+\begincom{rest}\ftype{Accessor}
+
+\label Syntax::
+
+\DefunWithValues rest {list} {tail}
+\Defsetf         rest {list} {new-tail}
+
+\label Arguments and Values::
+
+\param{list}---a \term{list},
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+	       which might be a \term{dotted list} or a \term{circular list}.
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{tail}---an \term{object}.
+
+\label Description::
+
+%% 15.2.0 13
+\funref{rest} performs the same operation as \funref{cdr},
+but mnemonically complements \funref{first}.
+Specifically,
+
+\code
+ (rest \param{list}) \EQ (cdr \param{list})
+ (setf (rest \param{list}) \param{new-tail}) \EQ (setf (cdr \param{list}) \param{new-tail})
+\endcode
+
+% If \param{list} is a \term{cons},
+% \funref{rest} returns the portion that follows the first \term{element}.
+% If \param{list} is the \term{empty list},
+% \funref{rest} returns the \term{empty list}.
+% 
+% \macref{setf} may be used with \funref{rest} to change 
+% the \term{cdr} of a \term{non-empty} \term{list} (\ie a \term{cons}).
+
+\label Examples::
+
+\code
+ (rest '(1 2)) \EV (2)
+ (rest '(1 . 2)) \EV 2
+ (rest '(1)) \EV NIL
+ (setq *cons* '(1 . 2)) \EV (1 . 2)
+ (setf (rest *cons*) "two") \EV "two"
+ *cons* \EV (1 . "two")
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{cdr},
+\funref{nthcdr}
+
+\label Notes::
+
+\funref{rest} is often preferred stylistically over \funref{cdr}
+when the argument is to being subjectively viewed as a \term{list} 
+rather than as a \term{cons}.
+
+\endcom
+
+%%% ========== MEMBER
+%%% ========== MEMBER-IF
+%%% ========== MEMBER-IF-NOT
+\begincom{member, member-if, member-if-not}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues member        {item      list {\key} key test test-not} {tail}
+\DefunWithValues member-if     {predicate list {\key} key} {tail}
+\DefunWithValues member-if-not {predicate list {\key} key} {tail}
+
+\label Arguments and Values:: 
+
+\param{item}---an \term{object}.
+
+\param{list}---a \term{proper list}.
+
+\param{predicate}---a \term{designator} for 
+		    a \term{function} of one \term{argument}
+		    that returns a \term{generalized boolean}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{tail}---a \term{list}.
+
+\label Description::
+
+%% 15.5.0 4
+\funref{member}, \funref{member-if}, and \funref{member-if-not} each
+search \param{list} for \param{item} or for a top-level element that 
+\term{satisfies the test}.  The argument to the \param{predicate} function 
+is an element of \param{list}.
+
+%% Implied by "satifies the test". -kmp 15-Feb-92
+% If \kwd{test} or \kwd{test-not} is not supplied, 
+% \funref{eql} is used.
+% The first argument to the \kwd{test} 
+% or \kwd{test-not} function is \param{item}, and the second argument
+% is an element of \param{list} as returned by the \kwd{key} function.
+% It is an error to supply both \kwd{test} and 
+% \kwd{test-not} 
+% in the same function call.
+% 
+% If \kwd{key} is supplied, it is used to
+% extract the part to be tested from the \param{list} element.
+% The argument to the \kwd{key} function 
+% is an element of \param{list}; typically, the  \kwd{key} function 
+% returns part of the element of
+% \param{list} it was given.
+% If \kwd{key} is not supplied or \nil, the \param{list} 
+% element is used.
+
+If some element \term{satisfies the test},
+the tail of \param{list} beginning
+with this element is returned; otherwise \nil\ is returned.
+
+\param{list} is searched on the top level only. 
+
+\label Examples::
+
+\code
+ (member 2 '(1 2 3)) \EV (2 3)                                 
+ (member 2 '((1 . 2) (3 . 4)) :test-not #'= :key #'cdr) \EV ((3 . 4))
+ (member 'e '(a b c d)) \EV NIL
+\endcode
+
+
+%!!! I'm suspicious of this dotted list.
+\code
+ (member-if #'listp '(a b nil c d)) \EV (NIL C D)
+ (member-if #'numberp '(a #\\Space 5/3 foo)) \EV (5/3 FOO)
+ (member-if-not #'zerop 
+                 '(3 6 9 11 . 12)
+                 :key #'(lambda (x) (mod x 3))) \EV (11 . 12)
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktype{list}{a \term{proper list}}
+
+\label See Also::
+
+\funref{find},
+\funref{position},
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+\Thefunction{member-if-not} is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+In the following
+
+\code
+ (member 'a '(g (a y) c a d e a f)) \EV (A D E A F)
+\endcode
+
+the value returned by \funref{member} is \term{identical} to the portion
+of the \term{list} beginning with \f{a}.  Thus \funref{rplaca} on the
+result of \funref{member} can be used to alter the part of the \term{list}
+where \f{a} was found (assuming a check has been made that \funref{member}
+did not return \nil).
+
+\endcom
+
+%-------------------- List Mapping --------------------
+
+
+%%% ========== MAPCAR
+%%% ========== MAPLIST
+%%% ========== MAPC
+%%% ========== MAPL
+%%% ========== MAPCAN
+%%% ========== MAPCON
+\begincom{mapc, mapcar, mapcan, mapl, maplist, mapcon}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues mapc    {function {\rest} \plus{lists}} {list-1}
+\DefunWithValues mapcar  {function {\rest} \plus{lists}} {result-list}
+\DefunWithValues mapcan  {function {\rest} \plus{lists}} {concatenated-results}
+\DefunWithValues mapl    {function {\rest} \plus{lists}} {list-1}
+\DefunWithValues maplist {function {\rest} \plus{lists}} {result-list}
+\DefunWithValues mapcon  {function {\rest} \plus{lists}} {concatenated-results}
+
+\label Arguments and Values:: 
+
+\param{function}---a \term{designator} for a \term{function} 
+  that must take as many \term{arguments} as there are \param{lists}.
+
+\issue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+\param{list}---a \term{proper list}.
+
+\param{list-1}---the first \param{list} (which must be a \term{proper list}).
+\endissue{DOTTED-LIST-ARGUMENTS:CLARIFY}
+
+\param{result-list}---a \term{list}.
+                   
+\param{concatenated-results}---a \term{list}.
+
+\label Description::
+
+The mapping operation involves applying \param{function} to
+successive sets of arguments in which
+one argument is obtained from each \term{sequence}.
+Except for \funref{mapc} and \funref{mapl},
+the result contains the results returned by \param{function}.
+In the cases of \funref{mapc} and \funref{mapl},
+the resulting \term{sequence} is \param{list}.
+
+%% 14.2.0 6
+\param{function} is called
+first on all the elements with index \f{0}, then on all those
+with index \f{1}, and so on.
+\param{result-type} specifies the \term{type} of
+the 
+resulting \term{sequence}.
+\issue{FUNCTION-TYPE:X3J13-MARCH-88}
+If \param{function} is a \term{symbol}, it is \funref{coerce}d
+to a \term{function} as if by \funref{symbol-function}.
+\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
+
+%% 7.8.4 4
+\funref{mapcar} operates on successive \term{elements} of the \param{lists}.
+\param{function} is applied to the first \term{element} of each \param{list},
+then to the second \term{element} of each \param{list}, and so on.
+The iteration terminates when the shortest \param{list} runs out,
+and excess elements in other lists are ignored.
+The value returned by \funref{mapcar} is a \term{list}
+of the results of successive calls to \param{function}.
+
+%% 7.8.4 6             
+\funref{mapc} is like \funref{mapcar} except that the results of 
+applying \param{function} are not accumulated.
+The \param{list} argument is returned.
+
+%% 7.8.4 5
+\funref{maplist} is like \funref{mapcar} except that
+\param{function} is applied to successive sublists of the \param{lists}.
+\param{function} 
+is first applied to the \param{lists} themselves, 
+and then to the \term{cdr} of each
+\param{list}, and then to the \term{cdr} of the \term{cdr}
+of each \param{list}, and so on.  
+
+\funref{mapl} is like \funref{maplist} except that the results of 
+applying \param{function} are not accumulated;
+\param{list-1} is returned.
+  
+%% 7.8.4 8
+\funref{mapcan} and \funref{mapcon} are like \funref{mapcar} and
+\funref{maplist} respectively, except that the results of
+applying \param{function} are combined 
+into a \term{list} by the use of \funref{nconc}
+rather than \funref{list}.
+That is,
+
+\code
+ (mapcon f x1 ... xn)
+   \EQ (apply #'nconc (maplist f x1 ... xn))
+\endcode
+and similarly for the relationship between \funref{mapcan} 
+and \funref{mapcar}.
+
+\label Examples::
+
+\code
+ (mapcar #'car '((1 a) (2 b) (3 c))) \EV (1 2 3) 
+ (mapcar #'abs '(3 -4 2 -5 -6)) \EV (3 4 2 5 6)
+ (mapcar #'cons '(a b c) '(1 2 3)) \EV ((A . 1) (B . 2) (C . 3))
+
+ (maplist #'append '(1 2 3 4) '(1 2) '(1 2 3)) 
+\EV ((1 2 3 4 1 2 1 2 3) (2 3 4 2 2 3)) 
+ (maplist #'(lambda (x) (cons 'foo x)) '(a b c d))
+\EV ((FOO A B C D) (FOO B C D) (FOO C D) (FOO D))
+ (maplist #'(lambda (x) (if (member (car x) (cdr x)) 0 1)) '(a b a c d b c))
+\EV (0 0 1 0 1 1 1)
+;An entry is 1 if the corresponding element of the input
+;  list was the last instance of that element in the input list.
+
+ (setq dummy nil) \EV NIL 
+ (mapc #'(lambda (&rest x) (setq dummy (append dummy x)))
+        '(1 2 3 4)
+        '(a b c d e)
+        '(x y z)) \EV (1 2 3 4) 
+ dummy \EV (1 A X 2 B Y 3 C Z)                   
+
+ (setq dummy nil) \EV NIL 
+ (mapl #'(lambda (x) (push x dummy)) '(1 2 3 4)) \EV (1 2 3 4) 
+ dummy \EV ((4) (3 4) (2 3 4) (1 2 3 4)) 
+
+ (mapcan #'(lambda (x y) (if (null x) nil (list x y)))
+          '(nil nil nil d e)
+          '(1 2 3 4 5 6)) \EV (D 4 E 5) 
+ (mapcan #'(lambda (x) (and (numberp x) (list x)))
+          '(a 1 b c 3 4 d 5))
+\EV (1 3 4 5)
+\endcode
+In this case the function serves as a filter; 
+this is a standard \Lisp\ idiom using \funref{mapcan}.
+
+\code
+ (mapcon #'list '(1 2 3 4)) \EV ((1 2 3 4) (2 3 4) (3 4) (4)) 
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazycheckanytype{list}{a \term{proper list}}
+
+\label See Also::
+
+\macref{dolist},
+\funref{map},
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Alists --------------------
+
+%%% ========== ACONS
+\begincom{acons}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues acons {key datum alist} {new-alist}
+
+\label Arguments and Values:: 
+
+\param{key}---an \term{object}.
+
+\param{datum}---an \term{object}.
+
+\param{alist}---an \term{association list}.
+
+\param{new-alist}---an \term{association list}.
+
+\label Description::
+
+%% 15.6.0 5
+Creates a \term{fresh} \term{cons},
+the \term{cdr} of which is \param{alist} and
+the \term{car} of which is another \term{fresh} \term{cons},
+ the \term{car} of which is \param{key} and
+ the \term{cdr} of which is \param{datum}.
+
+\label Examples::
+
+\code
+ (setq alist '()) \EV NIL
+ (acons 1 "one" alist) \EV ((1 . "one"))
+ alist \EV NIL
+ (setq alist (acons 1 "one" (acons 2 "two" alist))) \EV ((1 . "one") (2 . "two"))
+ (assoc 1 alist) \EV (1 . "one")
+ (setq alist (acons 1 "uno" alist)) \EV ((1 . "uno") (1 . "one") (2 . "two"))
+ (assoc 1 alist) \EV (1 . "uno")
+\endcode
+
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+ 
+\label See Also::
+
+\funref{assoc}, \funref{pairlis}
+
+\label Notes::
+
+\code
+(acons \param{key} \param{datum} \param{alist}) \EQ (cons (cons \param{key} \param{datum}) \param{alist})
+\endcode
+
+\endcom
+
+%%% ========== ASSOC
+%%% ========== ASSOC-IF
+%%% ========== ASSOC-IF-NOT
+\begincom{assoc, assoc-if, assoc-if-not}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues assoc        {item      alist {\key} key test test-not} {entry}
+
+\issue{ASSOC-RASSOC-IF-KEY:YES}
+
+\DefunWithValues assoc-if     {predicate alist {\key} key} {entry}
+\DefunWithValues assoc-if-not {predicate alist {\key} key} {entry}
+
+\endissue{ASSOC-RASSOC-IF-KEY:YES}
+
+\label Arguments and Values::
+
+\param{item}---an \term{object}.
+
+\param{alist}---an \term{association list}.
+
+\param{predicate}---a \term{designator} for 
+		    a \term{function} of one \term{argument}
+		    that returns a \term{generalized boolean}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{entry}---a \term{cons} that is an \term{element} of \param{alist},
+	        or \nil.
+
+\label Description::
+
+\issue{ASSOC-RASSOC-IF-KEY}
+%% Replaced per X3J13. -kmp 05-Oct-93
+% %% 15.6.0 8
+% \funref{assoc} returns the first \term{cons} in \param{alist} whose 
+% \term{car} \term{satisfies the test}, or \nil\ if no such \term{cons} is found.
+% 
+% The arguments to \param{test} and \param{test-not} and are the key of the
+% \param{item} and the key of the \term{car} of an element of \param{alist}, 
+% in that order.
+% 
+% \funref{assoc-if} and \funref{assoc-if-not} return the first \term{cons} 
+% in \param{alist} whose \term{car} \term{satisfies the predicate}, or \nil\ if 
+% no such \term{cons} is found.
+% 
+% The argument to \param{predicate} is the key of an element of \param{alist}.
+\funref{assoc}, \funref{assoc-if}, and \funref{assoc-if-not}
+return the first \term{cons} in \param{alist} whose \term{car} \term{satisfies the test},
+or \nil\ if no such \term{cons} is found.
+\endissue{ASSOC-RASSOC-IF-KEY}
+                    
+For \funref{assoc}, \funref{assoc-if}, and \funref{assoc-if-not}, if \nil\ appears
+in \param{alist} in place of a pair, it is ignored.
+
+\label Examples::
+%% 15.6.0 9
+
+\issue{ASSOC-RASSOC-IF-KEY}
+\code
+ (setq values '((x . 100) (y . 200) (z . 50))) \EV ((X . 100) (Y . 200) (Z . 50))
+ (assoc 'y values) \EV (Y . 200)
+ (rplacd (assoc 'y values) 201) \EV (Y . 201)
+ (assoc 'y values) \EV (Y . 201)
+ (setq alist '((1 . "one")(2 . "two")(3 . "three"))) 
+\EV ((1 . "one") (2 . "two") (3 . "three"))
+ (assoc 2 alist) \EV (2 . "two")
+ (assoc-if #'evenp alist) \EV (2 . "two")
+ (assoc-if-not #'(lambda(x) (< x 3)) alist) \EV (3 . "three")
+ (setq alist '(("one" . 1)("two" . 2))) \EV (("one" . 1) ("two" . 2))
+ (assoc "one" alist) \EV NIL
+ (assoc "one" alist :test #'equalp) \EV ("one" . 1)
+ (assoc "two" alist :key #'(lambda(x) (char x 2))) \EV NIL 
+ (assoc #\\o alist :key #'(lambda(x) (char x 2))) \EV ("two" . 2)
+ (assoc 'r '((a . b) (c . d) (r . x) (s . y) (r . z))) \EV  (R . X)
+ (assoc 'goo '((foo . bar) (zoo . goo))) \EV NIL
+ (assoc '2 '((1 a b c) (2 b c d) (-7 x y z))) \EV (2 B C D)
+ (setq alist '(("one" . 1) ("2" . 2) ("three" . 3)))
+\EV (("one" . 1) ("2" . 2) ("three" . 3))
+ (assoc-if-not #'alpha-char-p alist
+               :key #'(lambda (x) (char x 0))) \EV ("2" . 2)
+\endcode
+\endissue{ASSOC-RASSOC-IF-KEY}
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktype{alist}{an \term{association list}}
+
+\label See Also::
+
+\funref{rassoc},
+\funref{find},
+\funref{member},
+\funref{position},
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+\Thefunction{assoc-if-not} is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+It is possible to \funref{rplacd} the result of \funref{assoc}, provided
+that it is not \nil,
+in order to ``update'' \param{alist}. 
+
+%% 15.6.0 10
+The two expressions
+
+\code
+ (assoc item list :test fn)
+\endcode
+and
+
+\code
+ (find item list :test fn :key #'car)
+\endcode
+are equivalent in meaning with one exception:
+if \nil\ appears in \param{alist} in place of a pair,
+and \param{item} is \nil,
+\funref{find} will compute the \term{car} of the \nil\ in \param{alist},
+find that it is equal to \param{item}, and return \nil,
+whereas \funref{assoc} will ignore the \nil\ in \param{alist} and continue
+to search for an actual \term{cons} whose \term{car} is \nil.
+
+\endcom
+
+
+%%% ========== COPY-ALIST
+\begincom{copy-alist}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues copy-alist {alist} {new-alist}
+
+\label Arguments and Values::
+
+\param{alist}---an \term{association list}.
+
+\param{new-alist}---an \term{association list}.
+
+\label Description::
+
+%% 15.2.0 24
+\funref{copy-alist} returns a \term{copy} of \param{alist}.
+
+The \term{list structure} of \param{alist} is copied,
+and the \term{elements} of \param{alist} which are \term{conses} are
+also copied (as \term{conses} only). 
+Any other \term{objects} which are referred to, 
+whether directly or indirectly,
+by the \param{alist} continue to be shared.
+
+\label Examples::
+
+\code
+(defparameter *alist* (acons 1 "one" (acons 2 "two" '())))
+*alist* \EV ((1 . "one") (2 . "two"))
+(defparameter *list-copy* (copy-list *alist*))
+*list-copy* \EV ((1 . "one") (2 . "two"))
+(defparameter *alist-copy* (copy-alist *alist*))
+*alist-copy* \EV ((1 . "one") (2 . "two"))
+(setf (cdr (assoc 2 *alist-copy*)) "deux") \EV "deux"
+*alist-copy* \EV ((1 . "one") (2 . "deux"))
+*alist* \EV ((1 . "one") (2 . "two"))
+(setf (cdr (assoc 1 *list-copy*)) "uno") \EV "uno"
+*list-copy* \EV ((1 . "uno") (2 . "two"))
+*alist* \EV ((1 . "uno") (2 . "two"))
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{copy-list}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== PAIRLIS
+\begincom{pairlis}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues pairlis {keys data {\opt} alist} {new-alist}
+
+\label Arguments and Values::
+
+\param{keys}---a \term{proper list}.
+
+\param{data}---a \term{proper list}.
+
+\param{alist}---an \term{association list}.
+  \Default{the \term{empty list}}
+
+\param{new-alist}---an \term{association list}.
+
+\label Description::
+
+%% 15.6.0 6
+Returns an \term{association list} that associates
+elements of \param{keys} to corresponding elements of \param{data}.
+The consequences are undefined if \param{keys} and \param{data} are 
+not of the same \term{length}.  
+
+If \param{alist} is supplied, \funref{pairlis} returns
+a modified \param{alist} with the
+new pairs prepended to it.
+%% 15.6.0 7
+The new pairs may appear in the resulting \term{association list} in 
+either forward or backward order.
+The result of 
+
+\code
+ (pairlis '(one two) '(1 2) '((three . 3) (four . 19)))
+\endcode
+might be
+
+\code
+ ((one . 1) (two . 2) (three . 3) (four . 19))
+\endcode
+or
+
+\code
+ ((two . 2) (one . 1) (three . 3) (four . 19))
+\endcode
+
+
+\label Examples::
+\code
+ (setq keys '(1 2 3)
+        data '("one" "two" "three")
+        alist '((4 . "four"))) \EV ((4 . "four"))
+ (pairlis keys data) \EV ((3 . "three") (2 . "two") (1 . "one"))
+ (pairlis keys data alist)
+\EV ((3 . "three") (2 . "two") (1 . "one") (4 . "four"))
+ alist \EV ((4 . "four"))
+\endcode
+
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktypes{\param{keys} and \param{data}}{\term{proper lists}}
+
+\label See Also::
+
+\funref{acons}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== RASSOC
+%%% ========== RASSOC-IF
+%%% ========== RASSOC-IF-NOT
+\begincom{rassoc, rassoc-if, rassoc-if-not}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues rassoc        {item      alist  {\key} key test test-not} {entry}
+
+\issue{ASSOC-RASSOC-IF-KEY:YES}
+
+\DefunWithValues rassoc-if     {predicate alist {\key} key} {entry}
+\DefunWithValues rassoc-if-not {predicate alist {\key} key} {entry}
+
+\endissue{ASSOC-RASSOC-IF-KEY:YES}
+
+\label Arguments and Values:: 
+
+\param{item}---an \term{object}.
+
+\param{alist}---an \term{association list}.
+
+\param{predicate}---a \term{designator} for
+		    a \term{function} of one \term{argument}
+		    that returns a \term{generalized boolean}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{entry}---a \term{cons} that is an \term{element} of the \param{alist},
+		or \nil.
+
+\label Description::
+
+%% 15.6.0 13
+\funref{rassoc}, \funref{rassoc-if}, and \funref{rassoc-if-not}
+return the first \term{cons} whose \term{cdr} 
+\term{satisfies the test}.
+If no such \term{cons} is found, \nil\
+is returned.
+
+\issue{ASSOC-RASSOC-IF-KEY}
+%% Removed per X3J13. -kmp 05-Oct-93
+% The argument to \param{predicate} is an element of \param{alist}
+% as returned by the \kwd{key} function (if supplied).
+% The arguments to \kwd{test} and \kwd{test-not}
+% are \param{item} and an element of \param{alist}
+% as returned by the \kwd{key} function (if supplied), in that
+% order.
+% 
+% If \kwd{key} is supplied, it is applied to the \term{cdr}
+% of the \param{alist} entries and the result is passed to the
+% \param{predicate}, \kwd{test}, or \kwd{test-not} function.
+% The \term{cdr} of the \param{alist} entry contains the
+% key of the association, and if \kwd{key} is
+% not supplied or \nil, the \term{cdr} is the key of the association.
+\endissue{ASSOC-RASSOC-IF-KEY}
+
+If \nil\ appears in \param{alist} in place of a pair, it is  ignored.
+
+\label Examples::
+
+\code
+ (setq alist '((1 . "one") (2 . "two") (3 . 3))) 
+\EV ((1 . "one") (2 . "two") (3 . 3))
+ (rassoc 3 alist) \EV (3 . 3)
+ (rassoc "two" alist) \EV NIL
+ (rassoc "two" alist :test 'equal) \EV (2 . "two")
+ (rassoc 1 alist :key #'(lambda (x) (if (numberp x) (/ x 3)))) \EV (3 . 3)
+ (rassoc 'a '((a . b) (b . c) (c . a) (z . a))) \EV (C . A)
+ (rassoc-if #'stringp alist) \EV (1 . "one")
+ (rassoc-if-not #'vectorp alist) \EV (3 . 3)
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{assoc},
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+\Thefunction{rassoc-if-not} is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+It is possible to \funref{rplaca} the result of \funref{rassoc}, 
+provided that it is not \nil, in order to ``update'' \param{alist}. 
+
+%% 15.6.0 13
+
+The expressions
+
+\code
+ (rassoc item list :test fn)
+\endcode
+and
+
+\code
+ (find item list :test fn :key #'cdr)
+\endcode
+are equivalent in meaning, except when the \f{item} is \nil\
+and \nil\ appears in place of a pair in the \param{alist}.
+\Seefun{assoc}. 
+
+\endcom
+
+
+
+%-------------------- Plists --------------------
+
+%%% ========== GET-PROPERTIES
+\begincom{get-properties}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues get-properties {plist indicator-list} {indicator, value, tail}
+
+\label Arguments and Values:: 
+
+\issue{PLIST-DUPLICATES:ALLOW}
+\param{plist}---a \term{property list}.
+\endissue{PLIST-DUPLICATES:ALLOW}
+
+\param{indicator-list}---a \term{proper list} (of \term{indicators}).
+
+\param{indicator}---an \term{object} that is an \term{element} of \param{indicator-list}.
+
+\param{value}---an \term{object}.
+
+\param{tail}---a \term{list}.
+
+\label Description::
+
+%% 10.1.0 19
+\funref{get-properties} is used to look up any of several
+\term{property list} entries all at once.
+
+%% 10.1.0 23        
+It searches the \param{plist} for the first entry whose \term{indicator} 
+is \term{identical} to one of the \term{objects} in \param{indicator-list}.
+If such an entry is found, the \param{indicator} and \param{value} returned
+are the \term{property indicator} and its associated \term{property value},
+and the \param{tail} returned is the \term{tail} of the \param{plist}
+that begins with the found entry (\ie whose \term{car} is the \param{indicator}).
+If no such entry is found, the \param{indicator}, \param{value}, and \param{tail} 
+are all \nil.
+                                              
+\label Examples::
+
+\code
+ (setq x '()) \EV NIL
+ (setq *indicator-list* '(prop1 prop2)) \EV (PROP1 PROP2)
+ (getf x 'prop1) \EV NIL
+ (setf (getf x 'prop1) 'val1) \EV VAL1
+ (eq (getf x 'prop1) 'val1) \EV \term{true}
+ (get-properties x *indicator-list*) \EV PROP1, VAL1, (PROP1 VAL1)
+ x \EV (PROP1 VAL1)
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{get}, \funref{getf}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== GETF
+\begincom{getf}\ftype{Accessor}
+
+\label Syntax::
+
+\DefunWithValues getf {plist indicator {\opt} default} {value}
+\Defsetf         getf {place indicator {\opt} default} {new-value}
+
+\label Arguments and Values::
+
+\param{plist}---a \term{property list}.
+
+\param{place}---a \term{place}, the \term{value} of which is a \term{property list}.
+
+\param{indicator}---an \term{object}.
+
+\param{default}---an \term{object}.
+ \Default{\nil}
+
+%% 10.1.0 24
+\param{value}---an \term{object}.
+
+\param{new-value}---an \term{object}.
+
+\label Description::
+
+%% 10.1.0 19
+% \funref{getf} is used to \term{access} entries in a \term{property list}.
+% \funref{getf} searches \param{plist} for an indicator 
+% \term{identical} to \param{indicator} and returns the associated value.
+\funref{getf} finds a \term{property} on the \param{plist}
+whose \term{property indicator} is \term{identical} to \param{indicator},
+and returns its corresponding \term{property value}.
+\issue{PLIST-DUPLICATES:ALLOW}
+If there are multiple \term{properties}\meaning{1} with that \term{property indicator},
+\funref{getf} uses the first such \term{property}.
+\endissue{PLIST-DUPLICATES:ALLOW}
+% If \param{indicator} is not found, then \param{default} is returned.
+If there is no \term{property} with that \term{property indicator},
+\param{default} is returned.
+
+% %% 10.1.0 20
+% For \macref{setf} of \funref{getf}, the effect is 
+%    to add a new property-value pair,
+% or to update an existing pair,
+% in the \term{property list} that is the \term{value} of \param{place}.
+\macref{setf} of \funref{getf} may be used to associate a new \term{object}
+with an existing indicator in the \term{property list} held by \param{place},
+or to create a new assocation if none exists.
+\issue{PLIST-DUPLICATES:ALLOW}
+If there are multiple \term{properties}\meaning{1} with that \term{property indicator},
+\macref{setf} of \funref{getf} associates the \param{new-value} 
+with the first such \term{property}.
+\endissue{PLIST-DUPLICATES:ALLOW}
+\issue{SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED}
+When a \funref{getf} \term{form} is used as a \macref{setf} \param{place},
+any \param{default} which is supplied is evaluated according to normal
+left-to-right evaluation rules, but its \term{value} is ignored.
+\endissue{SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED}
+
+%% 10.1.0 20
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\macref{setf} of \funref{getf} is permitted to either
+    \term{write} the \term{value} of \param{place} itself,
+ or modify of any part, \term{car} or \term{cdr}, 
+     of the \term{list structure} held by \param{place}.
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}%
+
+\label Examples::
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\code
+ (setq x '()) \EV NIL
+ (getf x 'prop1) \EV NIL
+ (getf x 'prop1 7) \EV 7
+ (getf x 'prop1) \EV NIL
+ (setf (getf x 'prop1) 'val1) \EV VAL1
+ (eq (getf x 'prop1) 'val1) \EV \term{true}
+ (getf x 'prop1) \EV VAL1
+ (getf x 'prop1 7) \EV VAL1
+ x \EV (PROP1 VAL1)
+
+;; Examples of implementation variation permitted.
+ (setq foo (list 'a 'b 'c 'd 'e 'f)) \EV (A B C D E F)
+ (setq bar (cddr foo)) \EV (C D E F)
+ (remf foo 'c) \EV \term{true}
+ foo \EV (A B E F)
+ bar
+\EV (C D E F)
+\OV (C)
+\OV (NIL)
+\OV (C NIL)
+\OV (C D)
+\endcode
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+ 
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{get},
+\funref{get-properties},
+\macref{setf},
+{\secref\FnFormsAsGenRefs}
+
+\label Notes::
+
+There is no way (using \funref{getf}) to distinguish an absent property
+from one whose value is \param{default}; but see \funref{get-properties}.
+
+Note that while supplying a \term{default} argument to \macref{getf}
+in a \macref{setf} situation is sometimes not very interesting,
+it is still important because some macros, such as \macref{push} and
+\macref{incf}, require a \param{place} argument which data is both \term{read}
+from and \term{written} to.  In such a context, if a \term{default} 
+argument is to be supplied for the \term{read} situation, it must be
+syntactically valid for the \term{write} situation as well. For example,
+
+\code
+ (let ((plist '()))
+   (incf (getf plist 'count 0))
+   plist) \EV (COUNT 1)
+\endcode
+
+\endcom
+
+%%% ========== REMF
+\begincom{remf}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues remf {place indicator} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{place}---a \term{place}.
+
+\param{indicator}---an \term{object}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 10.1.0 22
+\macref{remf} removes from the \term{property list} stored in \param{place}
+a \term{property}\meaning{1} with a \term{property indicator}
+% EQ => identical -kmp 14-Jul-93
+\term{identical} to \param{indicator}.
+\issue{PLIST-DUPLICATES:ALLOW}
+If there are multiple \term{properties}\meaning{1} with the \term{identical} key,
+\macref{remf} only removes the first such \term{property}.
+\endissue{PLIST-DUPLICATES:ALLOW}
+\macref{remf} returns \term{false} if no such \term{property} was found,
+or \term{true} if a property was found.
+
+The \term{property indicator} 
+and the corresponding \term{property value} 
+are removed in an undefined order
+by destructively splicing the property list.  
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\macref{remf} is permitted to either \macref{setf} \param{place} or to 
+\macref{setf} any part, \funref{car} or \funref{cdr}, 
+of the \term{list structure} held by that \param{place}.
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+\issue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+For information about the \term{evaluation} of \term{subforms} of \param{place},
+\seesection\GenRefSubFormEval.
+\endissue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+
+\label Examples::
+
+\code
+ (setq x (cons () ())) \EV (NIL)
+ (setf (getf (car x) 'prop1) 'val1) \EV VAL1
+ (remf (car x) 'prop1) \EV \term{true}
+ (remf (car x) 'prop1) \EV \term{false}
+\endcode
+
+\label Side Effects::
+
+The property list stored in \param{place} is modified.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{remprop}, \funref{getf}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Sets --------------------
+
+%%% ========== INTERSECTION
+%%% ========== NINTERSECTION
+\begincom{intersection, nintersection}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues intersection  {list-1 list-2 {\key} key test test-not} {result-list}
+\DefunWithValues nintersection {list-1 list-2 {\key} key test test-not} {result-list}
+
+\label Arguments and Values:: 
+
+\param{list-1}---a \term{proper list}.
+
+\param{list-2}---a \term{proper list}.
+
+%% 15.5.0 15
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{result-list}---a \term{list}.
+     
+\label Description::
+
+%% 15.5.0 14
+\funref{intersection} and \funref{nintersection} return a \term{list}
+that contains every element that occurs in both \param{list-1} and \param{list-2}.
+
+%% 15.5.0 16
+\funref{nintersection} is the destructive version of \funref{intersection}.
+It performs the same operation,
+but may destroy \param{list-1} using its cells to construct the result.
+\issue{NINTERSECTION-DESTRUCTION:REVERT}
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+%% This has gone back and forth, but my opinion is that the current state of this
+%% is that the second arg is again protected. -kmp 7-Feb-92
+%%
+%% This opinion finally validated by clarifying vote in letter ballot (X3J13/93-302).
+%% Option REVERT affirms the status quo from both CLtL1 and draft 12.24,
+%% overriding the possible effect of REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89.
+%
+% %%Barmar noted that this next sentence was in conflict with the changes
+% %%made by REMF-DESTRUCTION-UNSPECIFIED, so I've removed it for now.  Mail sent
+% %%to find out if X3J13 really intended for NINTERSECTION's contract to be changed,
+% %%or if making this untrue this was a `typo':
+% %\param{list-2} is not destroyed.
+% 
+% \funref{nintersection} is permitted to modify any part of the \term{list structure} 
+% of \param{list-1} or \param{list-2}.
+%
+\param{list-2} is not destroyed.
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\endissue{NINTERSECTION-DESTRUCTION:REVERT}
+
+The intersection operation is described as follows.
+For all possible ordered pairs consisting of 
+    one \term{element} from \param{list-1} 
+and one \term{element} from \param{list-2},
+\kwd{test} or \kwd{test-not} are used 
+to determine whether they \term{satisfy the test}.  
+The first argument to the \kwd{test} or \kwd{test-not}
+function is an element of \param{list-1}; the second argument is an
+element of \param{list-2}.
+If \kwd{test} or \kwd{test-not} is not supplied, \funref{eql}
+is used.
+It is an error if \kwd{test} and \kwd{test-not} are supplied in
+the same function call.
+
+If \kwd{key} is supplied (and not \nil), it is used to
+extract the part to be tested from the \param{list} element. 
+The argument to the \kwd{key} function
+is an element of either \param{list-1} or \param{list-2};
+the \kwd{key} function typically returns part of the supplied element.
+If \kwd{key} is not supplied or \nil, the \param{list-1} and
+\param{list-2} elements are used.
+
+For every pair that \term{satifies the test},
+exactly one of the two elements of the pair will be put in the result.
+No element from either \term{list} appears in the result that does not 
+\term{satisfy the test} for
+an element from the other \term{list}.
+If one of the \term{lists} contains duplicate
+elements, there may be duplication in the result.
+
+There is no guarantee that the order of elements in the result will
+reflect the ordering of the arguments in any particular way.
+The result \term{list} may share cells with, 
+or be \funref{eq} to, either \param{list-1} or \param{list-2}
+if appropriate.
+
+\label Examples::
+
+\code
+ (setq list1 (list 1 1 2 3 4 a b c "A" "B" "C" "d")
+       list2 (list 1 4 5 b c d "a" "B" "c" "D")) 
+  \EV (1 4 5 B C D "a" "B" "c" "D")
+ (intersection list1 list2) \EV (C B 4 1 1)
+ (intersection list1 list2 :test 'equal) \EV ("B" C B 4 1 1)
+ (intersection list1 list2 :test #'equalp) \EV ("d" "C" "B" "A" C B 4 1 1) 
+ (nintersection list1 list2) \EV (1 1 4 B C)
+ list1 \EV \term{implementation-dependent} ;\eg (1 1 4 B C)
+ list2 \EV \term{implementation-dependent} ;\eg (1 4 5 B C D "a" "B" "c" "D")
+ (setq list1 (copy-list '((1 . 2) (2 . 3) (3 . 4) (4 . 5))))
+\EV ((1 . 2) (2 . 3) (3 . 4) (4 . 5)) 
+ (setq list2 (copy-list '((1 . 3) (2 . 4) (3 . 6) (4 . 8))))
+\EV ((1 . 3) (2 . 4) (3 . 6) (4 . 8)) 
+ (nintersection list1 list2 :key #'cdr) \EV ((2 . 3) (3 . 4)) 
+ list1 \EV \term{implementation-dependent} ;\eg ((1 . 2) (2 . 3) (3 . 4)) 
+ list2 \EV \term{implementation-dependent} ;\eg ((1 . 3) (2 . 4) (3 . 6) (4 . 8)) 
+\endcode
+
+\label Side Effects::
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\funref{nintersection} can modify \param{list-1}, 
+\issue{NINTERSECTION-DESTRUCTION}
+%or \param{list-2}.
+but not \param{list-2}.
+\endissue{NINTERSECTION-DESTRUCTION}
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktypes{\param{list-1} and \param{list-2}}{\term{proper lists}}
+
+\label See Also::
+
+\funref{union},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification},
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+Since the \funref{nintersection} side effect is not required,
+it should not be used in for-effect-only
+  positions in portable code.
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\endcom
+
+%%% ========== ADJOIN
+\begincom{adjoin}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues adjoin {item list {\key} key test test-not} {new-list}
+
+\label Arguments and Values:: 
+
+\param{item}---an \term{object}.
+
+\param{list}---a \term{proper list}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+%% 15.5.0 8   
+\param{new-list}---a \term{list}.
+
+\label Description::
+
+Tests whether \param{item} is the same as an existing element of \param{list}.
+If the \param{item} is not an existing element,
+\funref{adjoin} adds it to \param{list} (as if by \funref{cons})
+and returns the resulting \term{list}; 
+otherwise, nothing is added and the original \param{list} is returned.
+
+\SatisfyTest{item}{an \term{element} of \param{list}}
+
+\label Examples::
+
+\code
+ (setq slist '()) \EV NIL 
+ (adjoin 'a slist) \EV (A) 
+ slist \EV NIL 
+ (setq slist (adjoin '(test-item 1) slist)) \EV ((TEST-ITEM 1)) 
+ (adjoin '(test-item 1) slist) \EV ((TEST-ITEM 1) (TEST-ITEM 1)) 
+ (adjoin '(test-item 1) slist :test 'equal) \EV ((TEST-ITEM 1)) 
+ (adjoin '(new-test-item 1) slist :key #'cadr) \EV ((TEST-ITEM 1)) 
+ (adjoin '(new-test-item 1) slist) \EV ((NEW-TEST-ITEM 1) (TEST-ITEM 1)) 
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktype{list}{a \term{proper list}}
+
+\label See Also::
+
+\macref{pushnew},
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\code
+ (adjoin item list :key fn)
+   \EQ (if (member (fn item) list :key fn) list (cons item list))
+\endcode
+      
+\endcom
+
+%%% ========== PUSHNEW
+\begincom{pushnew}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValuesNewline pushnew {item place {\key} key test test-not} {new-place-value}
+
+\label Arguments and Values:: 
+
+\param{item}---an \term{object}.  
+
+%!!! Need to separate discussion of place from its value. -kmp 1-Sep-91
+\param{place}---a \term{place}, the \term{value} of which is a \term{proper list}. 
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{new-place-value}---a \term{list} (the new \term{value} of \param{place}).
+
+\label Description::
+
+\macref{pushnew} tests whether  \param{item} is the same as any existing
+element of the \term{list} stored in \param{place}.  If \param{item} is not,
+it is prepended to the \term{list}, and the new \term{list} is stored in
+\param{place}.
+
+%% 15.2.0 34
+\macref{pushnew} returns the new \term{list} that is stored in \param{place}.
+
+%% 15.2.0 32
+Whether or not \param{item} is already a member of the \term{list} that is
+in \param{place} is determined by comparisons using \kwd{test} or \kwd{test-not}.
+The first argument to the \kwd{test} or \kwd{test-not}
+function is \param{item}; the second argument is
+an element of the \term{list} in \param{place} as returned by
+the \kwd{key} function (if supplied).
+
+If \kwd{key} is supplied, it is used to extract the part to be tested from
+both \param{item} and the \term{list} element,
+as for \funref{adjoin}.
+
+The argument to the \kwd{key} function 
+is an element of the \term{list} stored in 
+\param{place}. The \kwd{key} function typically returns part
+part of the element of the \term{list}.
+If \kwd{key} is not supplied or \nil, the \term{list} 
+element is used.
+
+\issue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+For information about the \term{evaluation} of \term{subforms} of \param{place},
+\seesection\GenRefSubFormEval.
+\endissue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+
+\issue{PUSHNEW-STORE-REQUIRED:UNSPECIFIED}
+It is \term{implementation-dependent} whether or not \macref{pushnew} 
+actually executes the storing form for its \param{place} in the
+situation where the \param{item} is already a member of the \term{list}
+held by \param{place}.
+\endissue{PUSHNEW-STORE-REQUIRED:UNSPECIFIED}
+
+\label Examples::
+\code
+ (setq x '(a (b c) d)) \EV (A (B C) D)
+ (pushnew 5 (cadr x)) \EV (5 B C)   
+ x \EV (A (5 B C) D)
+ (pushnew 'b (cadr x)) \EV (5 B C)  
+ x \EV (A (5 B C) D)
+ (setq lst '((1) (1 2) (1 2 3))) \EV ((1) (1 2) (1 2 3))
+ (pushnew '(2) lst) \EV ((2) (1) (1 2) (1 2 3))
+ (pushnew '(1) lst) \EV ((1) (2) (1) (1 2) (1 2 3))
+ (pushnew '(1) lst :test 'equal) \EV ((1) (2) (1) (1 2) (1 2 3))
+ (pushnew '(1) lst :key #'car) \EV ((1) (2) (1) (1 2) (1 2 3)) 
+\endcode
+
+\label Side Effects::
+
+The contents of \param{place} may be modified.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{push},
+\funref{adjoin},
+{\secref\GeneralizedReference}
+
+\label Notes::
+
+The effect of
+\code
+ (pushnew item place :test p)
+\endcode
+is roughly equivalent to
+\code
+ (setf place (adjoin item place :test p))
+\endcode
+\issue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+except that the \term{subforms} of \f{place} are evaluated only once, 
+and \f{item} is evaluated before \f{place}.
+\endissue{PUSH-EVALUATION-ORDER:FIRST-ITEM}
+
+\endcom
+
+%%% ========== NSET-DIFFERENCE
+%%% ========== SET-DIFFERENCE
+\begincom{set-difference, nset-difference}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues set-difference  {list-1 list-2 {\key} key test test-not} {result-list}
+\DefunWithValues nset-difference {list-1 list-2 {\key} key test test-not} {result-list}
+
+\label Arguments and Values:: 
+
+\param{list-1}---a \term{proper list}.
+
+\param{list-2}---a \term{proper list}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{result-list}---a \term{list}.
+                                   
+\label Description::
+%% 15.5.0 17
+\funref{set-difference} returns a \term{list} 
+of elements of \param{list-1}
+that do not appear in \param{list-2}.  
+
+%% 15.5.0 20
+\funref{nset-difference} is the destructive 
+version of \funref{set-difference}.
+It may destroy \param{list-1}.
+
+%% 15.5.0 19
+For all possible ordered pairs consisting of
+one element from \param{list-1} and one element from \param{list-2}, the 
+\kwd{test} or \kwd{test-not} function is
+used to determine whether they \term{satisfy the test}.  
+The first argument to the \kwd{test} or \kwd{test-not} function 
+is the part of an element of \param{list-1} that is returned by 
+the \kwd{key} function (if supplied); the second argument is the part of 
+an element of \param{list-2} that is 
+returned by the \kwd{key} function (if supplied).
+
+If \kwd{key} is supplied, its argument is a \param{list-1} or
+\param{list-2} element. The \kwd{key} function 
+typically returns part of 
+the supplied element.
+If \kwd{key} is not supplied, the \param{list-1} or \param{list-2}
+element is used.
+
+An element of \param{list-1}
+appears in the result if and only if it does not match any element
+of \param{list-2}.  
+
+
+%% 15.5.0 18
+There is no guarantee that the order of elements in the result will
+reflect the ordering of the arguments in any particular way.
+The result \term{list} 
+may share cells with, or be \funref{eq} to, either of \param{list-1}
+or \param{list-2},
+if appropriate.
+
+\label Examples::
+
+\code
+ (setq lst1 (list "A" "b" "C" "d")
+       lst2 (list "a" "B" "C" "d")) \EV ("a" "B" "C" "d")
+ (set-difference lst1 lst2) \EV ("d" "C" "b" "A")
+ (set-difference lst1 lst2 :test 'equal) \EV ("b" "A")
+ (set-difference lst1 lst2 :test #'equalp) \EV NIL 
+ (nset-difference lst1 lst2 :test #'string=) \EV ("A" "b")
+ (setq lst1 '(("a" . "b") ("c" . "d") ("e" . "f")))
+\EV (("a" . "b") ("c" . "d") ("e" . "f")) 
+ (setq lst2 '(("c" . "a") ("e" . "b") ("d" . "a")))
+\EV (("c" . "a") ("e" . "b") ("d" . "a")) 
+ (nset-difference lst1 lst2 :test #'string= :key #'cdr)
+\EV (("c" . "d") ("e" . "f")) 
+ lst1 \EV (("a" . "b") ("c" . "d") ("e" . "f")) 
+ lst2 \EV (("c" . "a") ("e" . "b") ("d" . "a")) 
+\endcode
+\code
+;; Remove all flavor names that contain "c" or "w".
+ (set-difference '("strawberry" "chocolate" "banana"
+                  "lemon" "pistachio" "rhubarb")
+          '(#\\c #\\w)
+          :test #'(lambda (s c) (find c s)))
+\EV ("banana" "rhubarb" "lemon")    ;One possible ordering.
+\endcode
+
+\label Side Effects::
+
+\funref{nset-difference} may destroy \param{list-1}.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktypes{\param{list-1} and \param{list-2}}{\term{proper lists}}
+
+\label See Also::
+
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification},
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\endcom
+
+%%% ========== NSET-EXCLUSIVE-OR
+%%% ========== SET-EXCLUSIVE-OR
+\begincom{set-exclusive-or, nset-exclusive-or}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues set-exclusive-or  {list-1 list-2 {\key} key test test-not} {result-list}
+\DefunWithValues nset-exclusive-or {list-1 list-2 {\key} key test test-not} {result-list}
+
+\label Arguments and Values:: 
+
+\param{list-1}---a \term{proper list}.
+
+\param{list-2}---a \term{proper list}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{result-list}---a \term{list}.
+
+\label Description::
+%% 15.5.0 22
+\funref{set-exclusive-or} returns a \term{list} of elements that appear
+in exactly one of \param{list-1} and \param{list-2}.
+
+%% 15.5.0 25
+\funref{nset-exclusive-or} 
+is the \term{destructive} version of \funref{set-exclusive-or}.
+
+%% 15.5.0 24
+For all possible ordered pairs consisting of
+one element from \param{list-1} and one element from \param{list-2}, the 
+\kwd{test} or \kwd{test-not} function is
+used to determine whether they \term{satisfy the test}.  
+
+If \kwd{key} is supplied, it is used to
+extract the part to be tested from the \param{list-1} or \param{list-2} element. 
+The first argument to the \kwd{test} or \kwd{test-not} function 
+is the part of an element of \param{list-1} extracted by the \kwd{key}
+function (if supplied); the second argument  is the part of an 
+element of \param{list-2} extracted by the \kwd{key} function (if supplied).
+If \kwd{key} is not supplied or \nil, the \param{list-1} or
+\param{list-2} element is used.
+
+The result contains precisely
+those elements of \param{list-1} and \param{list-2} 
+that appear in no matching pair.
+
+The result \term{list} of \funref{set-exclusive-or} 
+might share storage with one of \param{list-1} or \param{list-2}.
+
+\label Examples::
+
+\code
+ (setq lst1 (list 1 "a" "b")
+       lst2 (list 1 "A" "b")) \EV (1 "A" "b")
+ (set-exclusive-or lst1 lst2) \EV ("b" "A" "b" "a")
+ (set-exclusive-or lst1 lst2 :test #'equal) \EV ("A" "a")
+ (set-exclusive-or lst1 lst2 :test 'equalp) \EV NIL 
+ (nset-exclusive-or lst1 lst2) \EV ("a" "b" "A" "b") 
+ (setq lst1 (list (("a" . "b") ("c" . "d") ("e" . "f"))))
+\EV (("a" . "b") ("c" . "d") ("e" . "f"))
+ (setq lst2 (list (("c" . "a") ("e" . "b") ("d" . "a"))))
+\EV (("c" . "a") ("e" . "b") ("d" . "a")) 
+ (nset-exclusive-or lst1 lst2 :test #'string= :key #'cdr)
+\EV (("c" . "d") ("e" . "f") ("c" . "a") ("d" . "a")) 
+ lst1 \EV (("a" . "b") ("c" . "d") ("e" . "f"))
+ lst2 \EV (("c" . "a") ("d" . "a")) 
+\endcode
+
+\label Side Effects::
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\funref{nset-exclusive-or} is permitted to modify any part,
+\term{car} or \term{cdr}, of the \term{list structure} of \param{list-1} or \param{list-2}.
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktypes{\param{list-1} and \param{list-2}}{\term{proper lists}}
+
+\label See Also::
+
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification},
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+Since the \funref{nset-exclusive-or} side effect is not required,
+it should not be used in for-effect-only
+  positions in portable code.
+ 
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+\endcom
+
+%%% ========== SUBSETP
+\begincom{subsetp}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues subsetp {list-1 list-2 {\key} key test test-not} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{list-1}---a \term{proper list}.
+
+\param{list-2}---a \term{proper list}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 15.5.0 26
+\funref{subsetp} returns \term{true} if every element of \param{list-1}
+\bogusterm{matches} some element of \param{list-2},
+and \term{false} otherwise.
+
+Whether a list element is the same as another list element is
+determined by the functions specified by the keyword arguments.  
+The first argument to the \kwd{test} or \kwd{test-not} 
+function is 
+%!!! Sandra: typically?
+typically
+part of an element of \param{list-1} extracted by
+the \kwd{key} function; the second argument is  typically part of 
+an element of \param{list-2} extracted by
+the \kwd{key} function.
+
+The argument to the \kwd{key} function is an element of either
+\param{list-1} or \param{list-2}; the return value is part of the element
+of the supplied list element.
+If \kwd{key} is not supplied or \nil, 
+the \param{list-1} or \param{list-2}
+element itself is supplied to the \kwd{test} or \kwd{test-not} 
+function.
+
+\label Examples::
+
+\code
+ (setq cosmos '(1 "a" (1 2))) \EV (1 "a" (1 2))
+ (subsetp '(1) cosmos) \EV \term{true}
+ (subsetp '((1 2)) cosmos) \EV \term{false}
+ (subsetp '((1 2)) cosmos :test 'equal) \EV \term{true}
+ (subsetp '(1 "A") cosmos :test #'equalp) \EV \term{true}
+ (subsetp '((1) (2)) '((1) (2))) \EV \term{false}
+ (subsetp '((1) (2)) '((1) (2)) :key #'car) \EV \term{true}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktypes{\param{list-1} and \param{list-2}}{\term{proper lists}}
+
+\label See Also::
+
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+\endcom
+
+%%% ========== NUNION
+%%% ========== UNION
+\begincom{union, nunion}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues union  {list-1 list-2 {\key} key test test-not} {result-list}
+\DefunWithValues nunion {list-1 list-2 {\key} key test test-not} {result-list}
+
+\label Arguments and Values:: 
+
+\param{list-1}---a \term{proper list}.
+
+\param{list-2}---a \term{proper list}.
+
+\param{test}---a \term{designator} for a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{test-not}---a \term{designator} for 
+  a \term{function} of two \term{arguments}
+  that returns a \term{generalized boolean}.
+
+\param{key}---a \term{designator} for a \term{function} of one argument,
+  or \nil.
+
+\param{result-list}---a \term{list}.
+
+\label Description::
+
+\funref{union} and \funref{nunion} return a \term{list}
+that contains every element that occurs in either \param{list-1} 
+or \param{list-2}.                                 
+
+%% 15.5.0 11
+For all possible ordered pairs consisting of one
+element from \param{list-1} 
+and one element from \param{list-2}, \kwd{test} or  \kwd{test-not} is used
+to determine whether they \term{satisfy the test}. 
+The first argument to the \kwd{test} or \kwd{test-not} 
+function is the part of the element of \param{list-1} extracted by the
+\kwd{key} function (if supplied); the second argument  
+is the part of the element of \param{list-2} extracted by the
+\kwd{key} function (if supplied).
+
+The argument to the \kwd{key} function is an element of
+\param{list-1} or \param{list-2}; the return value is part of the supplied
+element.  
+If \kwd{key} is not supplied or \nil, 
+the element of \param{list-1} or \param{list-2}
+itself is supplied to the \kwd{test} or \kwd{test-not} function. 
+
+For every matching pair, 
+%Removed per barmar -kmp 29-Jul-91
+%at least
+one of the two elements of the pair will be in the result.  Any
+element from either \param{list-1} or \param{list-2}
+that matches no element of the other will appear
+in the result.  
+
+%% 15.5.0 9
+If there is a duplication between \param{list-1} 
+and \param{list-2},
+only one of the duplicate instances will be in the result.
+If either \param{list-1} 
+or \param{list-2} has duplicate entries within it,
+the redundant entries
+might or might not appear in the result.
+
+%% 15.5.0 10
+The order of elements in the result do not have to
+reflect the ordering of \param{list-1} or \param{list-2} in any way.
+The result \term{list} may be \funref{eq} to either
+\param{list-1} or \param{list-2} if appropriate.
+
+\label Examples::
+
+\code
+ (union '(a b c) '(f a d))
+\EV (A B C F D)
+\OV (B C F A D)
+\OV (D F A B C)
+ (union '((x 5) (y 6)) '((z 2) (x 4)) :key #'car)
+\EV ((X 5) (Y 6) (Z 2))
+\OV ((X 4) (Y 6) (Z 2))
+
+ (setq lst1 (list 1 2 '(1 2) "a" "b")
+       lst2 (list 2 3 '(2 3) "B" "C"))
+\EV (2 3 (2 3) "B" "C")
+ (nunion lst1 lst2)
+\EV (1 (1 2) "a" "b" 2 3 (2 3) "B" "C") 
+\OV (1 2 (1 2) "a" "b" "C" "B" (2 3) 3)
+\endcode
+
+\label Side Effects::
+
+\issue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+\funref{nunion} is permitted to modify any part, \term{car} or \term{cdr}, 
+of the \term{list structure} of \param{list-1} or \param{list-2}.
+\endissue{REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89}
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+\Lazychecktypes{\param{list-1} and \param{list-2}}{\term{proper lists}}
+
+\label See Also::
+
+\funref{intersection},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification},
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+\issue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+{\secref\TraversalRules}
+\endissue{MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE}
+
+\label Notes::
+
+\issue{TEST-NOT-IF-NOT:FLUSH-ALL}
+The \kwd{test-not} parameter is deprecated.
+\endissue{TEST-NOT-IF-NOT:FLUSH-ALL}
+
+Since the \funref{nunion} side effect is not required,
+it should not be used in for-effect-only positions in portable code.
+
+\endcom
+

dict-environment.tex

@@ -0,0 +1,2104 @@
+% -*- Mode: TeX -*-
+
+% Environment
+%  Time
+%  Debugging/Tuning
+%  Storage System
+%  Browsing/Editing
+%  Read-Eval-Print Loop
+%  External Environment Queries
+
+%-------------------- Time --------------------
+
+%%% ========== DECODE-UNIVERSAL-TIME
+\begincom{decode-universal-time}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValuesNewline decode-universal-time
+			{universal-time {\opt} time-zone}
+			{second, minute, hour, date, month, year, day, daylight-p, zone}
+
+\label Arguments and Values::
+
+\param{universal-time}---a \term{universal time}.
+
+\issue{TIME-ZONE-NON-INTEGER:ALLOW}
+\param{time-zone}---a \term{time zone}.
+\endissue{TIME-ZONE-NON-INTEGER:ALLOW}
+
+\param{second}, \param{minute}, \param{hour}, \param{date}, \param{month},
+\param{year}, \param{day}, \param{daylight-p}, \param{zone}---a \term{decoded time}.
+
+\label Description::
+
+%% 25.4.1 18
+Returns the \term{decoded time} represented by the given \term{universal time}.
+
+If \param{time-zone} is not supplied,
+it defaults to the current time zone adjusted for daylight saving time.  
+\issue{DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE}
+If \param{time-zone} is supplied, daylight saving time information is ignored.
+The daylight saving time flag is \nil\ if \param{time-zone} is supplied.
+\endissue{DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE}
+
+\label Examples::
+
+\issue{DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE}
+\code
+ (decode-universal-time 0 0) \EV 0, 0, 0, 1, 1, 1900, 0, \term{false}, 0
+
+;; The next two examples assume Eastern Daylight Time.
+ (decode-universal-time 2414296800 5) \EV 0, 0, 1, 4, 7, 1976, 6, \term{false}, 5
+ (decode-universal-time 2414293200) \EV 0, 0, 1, 4, 7, 1976, 6, \term{true}, 5
+
+;; This example assumes that the time zone is Eastern Daylight Time
+;; (and that the time zone is constant throughout the example).
+ (let* ((here (nth 8 (multiple-value-list (get-decoded-time)))) ;Time zone
+        (recently (get-universal-time))
+        (a (nthcdr 7 (multiple-value-list (decode-universal-time recently))))
+        (b (nthcdr 7 (multiple-value-list (decode-universal-time recently here)))))
+   (list a b (equal a b))) \EV ((T 5) (NIL 5) NIL)
+\endcode
+\endissue{DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE}
+
+\label Affected By::
+
+\term{Implementation-dependent} mechanisms for calculating when or if daylight
+savings time is in effect for any given session.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{encode-universal-time}, \funref{get-universal-time}, 
+%5.3
+{\secref\Time}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ENCODE-UNIVERSAL-TIME
+\begincom{encode-universal-time}\ftype{function}
+                                             
+\label Syntax::
+
+\DefunWithValuesNewline encode-universal-time
+		        {\vtop{\hbox{second minute hour date month year}
+                               \hbox{{\opt} time-zone}}}
+			{universal-time}
+
+\label Arguments and Values::
+
+\param{second}, \param{minute}, \param{hour}, 
+\param{date}, \param{month}, \param{year}, 
+\param{time-zone}---the corresponding parts of a \term{decoded time}.
+ (Note that some of the nine values in a full \term{decoded time} are redundant,
+  and so are not used as inputs to this function.)
+
+\param{universal-time}---a \term{universal time}.
+
+\label Description::
+
+%% 25.4.1 20
+%!!! Actually, the args are only part of a decoded time
+\funref{encode-universal-time} converts a time from Decoded Time format
+to a \term{universal time}.
+
+If \param{time-zone} is supplied, no adjustment for daylight savings time is performed.
+
+\label Examples::
+
+\code
+ (encode-universal-time 0 0 0 1 1 1900 0) \EV 0
+ (encode-universal-time 0 0 1 4 7 1976 5) \EV 2414296800
+;; The next example assumes Eastern Daylight Time.
+ (encode-universal-time 0 0 1 4 7 1976) \EV 2414293200
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{decode-universal-time}, \funref{get-decoded-time}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== GET-DECODED-TIME
+%%% ========== GET-UNIVERSAL-TIME
+\begincom{get-universal-time, get-decoded-time}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues get-universal-time {\noargs} {universal-time}
+
+\DefunWithValuesNewline get-decoded-time {\noargs}
+		        {second, minute, hour, date, month, year, day, daylight-p, zone}
+
+\label Arguments and Values::
+
+\param{universal-time}---a \term{universal time}.
+
+\param{second}, \param{minute}, \param{hour},
+\param{date}, \param{month}, \param{year},
+\param{day}, \param{daylight-p}, \param{zone}---a \term{decoded time}.
+
+\label Description::
+
+%% 25.4.1 17
+\funref{get-universal-time} returns the current time, represented as a \term{universal time}.
+
+%% 25.4.1 15
+\funref{get-decoded-time} returns the current time, represented as a \term{decoded time}.
+
+\label Examples::
+
+\code
+;; At noon on July 4, 1976 in Eastern Daylight Time.
+ (get-decoded-time) \EV 0, 0, 12, 4, 7, 1976, 6, \term{true}, 5
+;; At exactly the same instant.
+ (get-universal-time) \EV 2414332800
+;; Exactly five minutes later.
+ (get-universal-time) \EV 2414333100
+;; The difference is 300 seconds (five minutes)
+ (- * **) \EV 300
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+The time of day (\ie the passage of time),
+the system clock's ability to keep accurate time,
+and the accuracy of the system clock's initial setting.
+
+\label Exceptional Situations::
+
+An error \oftype{error} might be signaled if the current time cannot be determined.
+
+\label See Also::
+
+\funref{decode-universal-time},
+\funref{encode-universal-time},
+{\secref\Time}
+
+\label Notes::
+
+\code
+ (get-decoded-time) \EQ (decode-universal-time (get-universal-time))
+\endcode
+
+No \term{implementation} is required to have a way to verify that the
+time returned is correct.  However, if an \term{implementation} provides
+a validity check (\eg the failure to have properly initialized the system
+clock can be reliably detected) and that validity check fails, 
+the \term{implementation} is strongly encouraged (but not required)
+to signal an error \oftype{error} (rather than, for example, returning a
+known-to-be-wrong value) that is \term{correctable} by allowing the user
+to interactively set the correct time.
+
+\endcom
+
+%%% ========== SLEEP
+\begincom{sleep}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues sleep {seconds} {\nil}
+
+\label Arguments and Values::
+
+\param{seconds}---a non-negative \term{real}.
+
+\label Description::
+
+%% 25.4.1 24
+Causes execution to cease and become dormant for approximately the
+seconds of real time indicated by \param{seconds}, 
+whereupon execution is resumed.
+
+\label Examples::
+
+\code
+ (sleep 1) \EV NIL 
+
+;; Actually, since SLEEP is permitted to use approximate timing, 
+;; this might not always yield true, but it will often enough that
+;; we felt it to be a productive example of the intent.
+ (let ((then (get-universal-time))
+       (now  (progn (sleep 10) (get-universal-time))))
+   (>= (- now then) 10))
+\EV \term{true}
+\endcode
+
+\label Side Effects::
+
+Causes processing to pause.
+
+\label Affected By::
+
+The granularity of the scheduler.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{seconds}{a non-negative \term{real}}
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Debugging Tuning --------------------
+
+%%% ========== APROPOS
+%%% ========== APROPOS-LIST
+
+\begincom{apropos, apropos-list}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues apropos      {string {\opt} package} {\novalues}
+
+\DefunWithValues apropos-list {string {\opt} package} {symbols}
+
+\label Arguments and Values::
+
+\param{string}---a \term{\symbolnamedesignator}.
+
+\param{package}---a \term{package designator} or \nil.
+ \Default{\nil}
+
+\param{symbols}---a \term{list} of \term{symbols}.
+
+\label Description::
+
+%% 25.3.0 23
+These functions search for \term{interned} \term{symbols} 
+whose \term{names} contain the substring \param{string}.
+
+For \funref{apropos}, as each such \term{symbol} is found,
+its name is printed on \term{standard output}.
+In addition,
+if such a \term{symbol} is defined as a \term{function} or \term{dynamic variable},
+information about those definitions might also be printed.
+
+%% 25.3.0 23
+For \funref{apropos-list},
+no output occurs as the search proceeds;
+instead a list of the matching \term{symbols} is returned when the search is complete.
+
+If \param{package} is \term{non-nil},
+only the \term{symbols} \term{accessible} in that \param{package} are searched;
+otherwise all \term{symbols} \term{accessible} in any \term{package} are searched.
+
+Because a \term{symbol} might be available 
+by way of more than one inheritance path,
+\funref{apropos} might print information about the \term{same} \term{symbol} more than once,
+%What about APROPOS-LIST? Can its result contain duplicates? -kmp 24-Apr-91
+%I added this next since it was implicitly vague; makes it explicitly vague. -kmp 1-Feb-92
+or \funref{apropos-list} might return a \term{list} containing duplicate \term{symbols}.
+
+%!!! This really wants a technical issue in order to resolve it.
+Whether or not the search is case-sensitive is \term{implementation-defined}.
+
+\label Examples:\None.
+
+\label Affected By::
+
+The set of \term{symbols} which are currently \term{interned}
+in any \term{packages} being searched.
+
+\funref{apropos} is also affected by \varref{*standard-output*}.
+
+\label Exceptional Situations:\None.
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== DESCRIBE
+\begincom{describe}\ftype{Function}
+
+%% 25.3.0 12
+\label Syntax::
+
+\DefunWithValues describe {object {\opt} stream} {\novalues}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\issue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+\param{stream}---an \term{output} \term{stream designator}.
+ \Default{\term{standard output}}
+\endissue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+
+\label Description::
+
+\funref{describe} displays information about \param{object}
+\issue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+to \param{stream}.
+\endissue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+
+%This used to be worded in a way which required these two behaviors in seeming
+%contradiction to the remark about output being implementation-dependent.
+%Barmar flagged this and I fixed it in a way that is hopefully non-controversial.
+%  -kmp 29-Dec-90
+For example, \funref{describe} of a \term{symbol} might show the
+\term{symbol}'s value, its definition, and each of its properties. 
+\funref{describe} of a \term{float} might show the number's
+internal representation in a way that is useful for tracking
+down round-off errors.  In all cases, however, the nature and format of the
+output of \funref{describe} is \term{implementation-dependent}.
+
+%% 25.3.0 13
+\funref{describe} can describe something that it finds inside the \param{object};
+in such cases, a notational device such as increased indentation or positioning in a
+table is typically used in order to visually distinguish such recursive descriptions 
+from descriptions of the argument \param{object}.
+
+\issue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+The actual act of describing the object is implemented by \funref{describe-object}.
+\funref{describe} exists as an interface primarily to manage argument defaulting (including
+conversion of arguments \t\ and \nil\ into \term{stream} \term{objects}) and to inhibit
+any return values from \funref{describe-object}.
+\endissue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+
+\issue{DESCRIBE-INTERACTIVE:NO}
+\funref{describe} is not intended to be an interactive function.  In a 
+\term{conforming implementation}, \funref{describe} must not, by default, 
+prompt for user input.  User-defined methods for \funref{describe-object}
+are likewise restricted.  
+\endissue{DESCRIBE-INTERACTIVE:NO}
+
+\label Examples:\None.
+
+\label Side Effects::
+
+Output to \term{standard output} or \term{terminal I/O}.
+
+\label Affected By::
+
+\varref{*standard-output*} and \varref{*terminal-io*},
+methods on \funref{describe-object} and \funref{print-object}
+for \term{objects} having user-defined \term{classes}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{inspect}, \funref{describe-object}
+
+\label Notes:\None.
+
+%% There are argument congruence problems with this stuff, so it's just not worth
+%% keeping.  A discussion among Quinquevirate left us with no good way out. -kmp 30-Jan-92
+%\issue{DESCRIBE-INTERACTIVE:NO}
+% An \term{implementation} may be extended to permit additional, non-portable keyword arguments to \funref{describe} 
+% which, if used, might cause \funref{describe} to behave in an interactive way.
+% 
+% An implementations may be extended to permit additional, non-portable keyword
+% arguments would prompt for or require
+% user input as long as the default action if no keyword arguments are supplied does not
+% prompt for or
+%     require user input.
+% For example, the following kind of interaction would be permissible in
+% implementations which chose to do it:
+% 
+% \code
+%  (defvar *my-table* (make-hash-table))
+%  (setf (gethash 'foo *my-table*) 1)
+%  (setf (gethash 'bar *my-table*) 2)
+%  (setf (gethash 'foobar *my-table*) 3)
+%  (describe *my-table* :interactive t)
+% #<EQ-HASH-TABLE 259> has 3 entries.
+% Do you want to see its contents? (Yes or No) Yes
+% \endcode
+%\endissue{DESCRIBE-INTERACTIVE:NO}
+
+\endcom
+
+%%% ========== DESCRIBE-OBJECT
+\begincom{describe-object}\ftype{Standard Generic Function}
+ 
+\issue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+
+\label Syntax::
+ 
+\DefgenWithValues {describe-object} {object stream} {\term{implementation-dependent}}
+ 
+\label Method Signatures::
+ 
+\Defmeth {describe-object} {(\param{object} standard-object) \param{stream}}
+ 
+\label Arguments and Values::
+ 
+\param{object}---an \term{object}.
+ 
+\param{stream}---a \term{stream}.
+ 
+\label Description::
+ 
+The generic function \funref{describe-object} prints a description of
+\param{object} to a \param{stream}.  \funref{describe-object} is called 
+by \funref{describe}; it must not be called by the user.
+%I changed should -> must in the above.  An implementation can always defined
+%the consequences in order to lift this restriction.
+ 
+Each implementation is required to provide a \term{method} on 
+\theclass{standard-object} and \term{methods} on enough other
+\term{classes} so as to ensure that there is always an applicable \term{method}.  
+Implementations are free to add \term{methods} for other \term{classes}.
+Users can write \term{methods} for \funref{describe-object} for their
+own \term{classes} if they do not wish to inherit an implementation-supplied
+\term{method}.
+ 
+\term{Methods} on \funref{describe-object} can recursively call
+\funref{describe}.  Indentation, depth limits, and circularity detection
+are all taken care of automatically, provided that each \term{method} 
+handles exactly one level of structure and calls \funref{describe} 
+recursively if there are more structural levels.  The consequences are 
+undefined if this rule is not obeyed.
+ 
+In some implementations the \param{stream} argument passed to a
+\funref{describe-object} method is not the original \param{stream}, but is
+an intermediate \term{stream} that implements parts of \funref{describe}.
+\term{Methods} should therefore not depend on the identity of this
+\term{stream}.
+
+%Output is sent to \param{stream}. 
+ 
+\label Examples::
+
+\code
+ (defclass spaceship ()
+   ((captain :initarg :captain :accessor spaceship-captain)
+    (serial# :initarg :serial-number :accessor spaceship-serial-number)))
+
+ (defclass federation-starship (spaceship) ())
+
+ (defmethod describe-object ((s spaceship) stream)
+   (with-slots (captain serial#) s
+     (format stream "~&~S is a spaceship of type ~S,~
+                     ~%with ~A at the helm ~
+                       and with serial number ~D.~%"
+             s (type-of s) captain serial#)))
+
+ (make-instance 'federation-starship
+                :captain "Rachel Garrett"
+                :serial-number "NCC-1701-C")
+\EV #<FEDERATION-STARSHIP 26312465>
+
+ (describe *)
+\OUT #<FEDERATION-STARSHIP 26312465> is a spaceship of type FEDERATION-STARSHIP,
+\OUT with Rachel Garrett at the helm and with serial number NCC-1701-C.
+\EV \novalues
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+ 
+\label See Also::
+
+\funref{describe}
+
+\label Notes::
+
+The same implementation techniques that are applicable to \funref{print-object} are
+applicable to \funref{describe-object}.
+
+The reason for making the return values for \funref{describe-object}
+unspecified is to  avoid forcing users to include explicit \f{(values)}
+in all of their \term{methods}.  \funref{describe} takes care of that.
+ 
+\endissue{DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT}
+
+\endcom
+
+%%% ========== TRACE
+%%% ========== UNTRACE
+\begincom{trace, untrace}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues trace   {\starparam{function-name}} {trace-result}
+\DefmacWithValues untrace {\starparam{function-name}} {untrace-result}
+
+\label Arguments and Values::
+
+\issue{FUNCTION-NAME:LARGE}
+\param{function-name}---a \term{function name}.
+\endissue{FUNCTION-NAME:LARGE}
+
+\param{trace-result}---\term{implementation-dependent},
+  unless no \term{function-names} are supplied, 
+%% 25.3.0 6
+  in which case \param{trace-result} is a \term{list} of \term{function names}.
+
+\param{untrace-result}---\term{implementation-dependent}.
+
+\label Description::
+
+\macref{trace} and \macref{untrace} control the invocation of the trace facility.  
+
+Invoking \macref{trace} with one or more \param{function-names} causes
+the denoted \term{functions} to be ``traced.''
+Whenever a traced \term{function} is invoked, information
+     about the call,
+     about the arguments passed,
+ and about any eventually returned values
+is printed to \term{trace output}.
+If \macref{trace} is used with no \param{function-names},
+no tracing action is performed; 
+instead, a list of the \term{functions} currently being traced is returned.
+
+%% 25.3.0 4
+Invoking \macref{untrace} with one or more function names causes those
+functions to be ``untraced'' (\ie no longer traced).
+%% 25.3.0 7
+If \macref{untrace} is used with no \param{function-names},
+all \term{functions} currently being traced are untraced.
+
+If a \term{function} to be traced has been open-coded
+(\eg because it was declared \declref{inline}),
+a call to that \term{function} might not produce trace output.
+
+\label Examples::
+
+\code
+ (defun fact (n) (if (zerop n) 1 (* n (fact (- n 1)))))
+\EV FACT
+ (trace fact)
+\EV (FACT)
+;; Of course, the format of traced output is implementation-dependent.
+ (fact 3)
+\OUT 1 Enter FACT 3
+\OUT | 2 Enter FACT 2
+\OUT |   3 Enter FACT 1
+\OUT |   | 4 Enter FACT 0
+\OUT |   | 4 Exit FACT 1
+\OUT |   3 Exit FACT 1
+\OUT | 2 Exit FACT 2
+\OUT 1 Exit FACT 6
+\EV 6
+\endcode
+
+\label Side Effects::
+
+Might change the definitions of the \term{functions} named by \param{function-names}.
+
+\label Affected By::
+
+Whether the functions named are defined or already being traced.
+
+\label Exceptional Situations::
+
+% addressed in the packages chapter.  --sjl 5 Mar 92
+%\issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+% The consequences are undefined if an \term{external symbol} of
+% \thepackage{common-lisp} is
+% used as a \param{function-name} argument.
+%\endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+
+%% 25.3.0 5
+   Tracing an already traced function,
+or untracing a function not currently being traced,
+should produce no harmful effects, but might signal a warning.
+
+\label See Also::
+
+\varref{*trace-output*},
+\macref{step}
+
+\label Notes::
+
+%% 25.3.0 8
+\macref{trace} and \macref{untrace} may also accept additional
+\term{implementation-dependent} argument formats.  The format of the trace
+output is \term{implementation-dependent}.
+
+Although \macref{trace} can be extended to permit non-standard options,
+\term{implementations} are nevertheless encouraged (but not required)
+to warn about the use of syntax or options 
+that are neither specified by this standard 
+nor added as an extension by the \term{implementation},
+since they could be symptomatic of typographical errors
+or of reliance on features supported in \term{implementations} 
+other than the current \term{implementation}.
+
+\endcom
+
+%%% ========== STEP
+\begincom{step}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues step {form} {\starparam{result}}
+
+\label Arguments and Values:: 
+
+\param{form}---a \term{form}; \evalspecial.
+
+\param{results}---the \term{values} returned by the \param{form}.
+
+\label Description::
+
+\macref{step} implements a debugging paradigm wherein the programmer
+is allowed to \term{step} through the \term{evaluation} of a \term{form}.
+The specific nature of the interaction,
+\issue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+including which I/O streams are used and
+whether the stepping has lexical or dynamic scope,
+\endissue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+is \term{implementation-defined}.
+
+%% 25.3.0 9
+\issue{STEP-ENVIRONMENT:CURRENT}
+\macref{step} evaluates \param{form} in the current \term{environment}.
+A call to \macref{step} can be compiled, but it is acceptable for an
+implementation to interactively step through only those parts of the computation
+that are interpreted.
+\endissue{STEP-ENVIRONMENT:CURRENT}
+
+\issue{STEP-MINIMAL:PERMIT-PROGN}
+It is technically permissible for a \term{conforming implementation} 
+to take no action at all other than normal \term{execution} of the \param{form}.
+In such a situation, 
+\f{(step \i{form})}
+is equivalent to, for example,
+\f{(let () \i{form})}. 
+In implementations where this is the case, the associated documentation
+should mention that fact.
+\endissue{STEP-MINIMAL:PERMIT-PROGN}
+
+\label Examples:\None.
+
+\label Affected By:\None?
+%% clean-up item in progress here.
+%% Could be bindings of streams to which i/o occurs, current
+%% dynamic environment, lexical too?
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\macref{trace}
+
+\issue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+%\varref{*evalhook*}, \varref{*applyhook*}.
+\endissue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+
+\label Notes::
+
+\term{Implementations} are encouraged to respond to the typing of \f{?} 
+or the pressing of a ``help key'' by providing help including a list of
+commands.
+
+\issue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+% %% 20.1.0 9
+% The \macref{step} facility can be implemented using the \varref{*evalhook*}
+% and \varref{*applyhook*} features.
+\endissue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+
+\endcom
+
+%%% ========== TIME
+\begincom{time}\ftype{Macro}
+
+\label Syntax::
+
+\DefmacWithValues time {form} {\starparam{result}}
+
+\label Arguments and Values::
+
+\param{form}---a \term{form}; \evalspecial.
+
+\param{results}---the \term{values} returned by the \param{form}.
+
+\label Description::
+
+\issue{STEP-ENVIRONMENT:CURRENT}
+\funref{time} evaluates \param{form} in the current \term{environment} (lexical and dynamic).
+A call to \funref{time} can be compiled.
+\endissue{STEP-ENVIRONMENT:CURRENT}
+
+\funref{time} prints various timing data and other information to \term{trace output}.
+The nature and format of the printed information is \term{implementation-defined}.
+Implementations are encouraged to provide such information as 
+     elapsed real time,
+     machine run time,
+ and storage management statistics.
+
+%%% 25.3.0 10
+%\funref{time} evaluates \param{form}.
+
+\label Examples:\None.
+
+\label Affected By::
+
+The accuracy of the results depends, among other things, on the accuracy
+of the corresponding functions provided by the underlying operating system.
+
+The magnitude of the results may depend on 
+  the hardware,
+  the operating system,
+  the lisp implementation,
+ and the state of the global environment.
+Some specific issues which frequently affect the outcome are
+  hardware speed,
+  nature of the scheduler (if any),
+  number of competing processes (if any),
+  system paging,
+  whether the call is interpreted or compiled,
+  whether functions called are compiled,
+  the kind of garbage collector involved and whether it runs,
+  whether internal data structures (e.g., hash tables) are implicitly reorganized,
+  \etc.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{get-internal-real-time},
+\funref{get-internal-run-time}
+
+\label Notes::
+
+In general, these timings are not guaranteed to be reliable enough for
+marketing comparisons. Their value is primarily heuristic, for tuning
+purposes.
+
+For useful background information on the complicated issues involved in
+interpreting timing results, see {\GabrielBenchmarks}.
+
+\endcom
+
+%%% ========== INTERNAL-TIME-UNITS-PER-SECOND
+\begincom{internal-time-units-per-second}\ftype{Constant Variable}
+
+\label Constant Value::
+
+A positive \term{integer}, the magnitude of which is \term{implementation-dependent}.
+
+\label Description::
+
+The number of \term{internal time units} in one second.
+
+\label Examples:\None.
+
+\label See Also::
+
+\funref{get-internal-run-time}, \funref{get-internal-real-time}
+
+\label Notes::
+
+%Shouldn't this be in the glossary with the definition of internal time unit? -kmp
+These units form the basis of the Internal Time format representation.
+
+\endcom
+
+%%% ========== GET-INTERNAL-REAL-TIME
+\begincom{get-internal-real-time}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues get-internal-real-time {\noargs} {internal-time}
+
+\label Arguments and Values::
+
+\param{internal-time}---a non-negative \term{integer}.
+
+\label Description::
+
+%% 25.4.1 23
+\funref{get-internal-real-time} returns as an \term{integer} the 
+current time in \term{internal time units}, relative to an arbitrary 
+time base.  The difference between the values of two calls to this
+function is the amount of elapsed real time (\ie clock time) between the two calls. 
+
+\label Examples:\None.
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+Time of day (\ie the passage of time).
+The time base affects the result magnitude.
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\conref{internal-time-units-per-second}
+
+\label Notes:\None.
+
+\endcom 
+
+%%% ========== GET-INTERNAL-RUN-TIME
+\begincom{get-internal-run-time}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues get-internal-run-time {\noargs} {internal-time}
+
+\label Arguments and Values::
+
+\param{internal-time}---a non-negative \term{integer}.
+
+\label Description::
+
+%% 25.4.1 22
+Returns as an \term{integer} the current 
+run time in \term{internal time units}.  The precise meaning of this quantity is
+\term{implementation-defined};  it may measure real time, run time, CPU cycles, or some
+other quantity.  The intent is that the difference between the values of two calls
+to this function be the amount of time between the two calls during which 
+computational effort was expended on behalf of the executing program.
+
+\label Examples:\None.
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+The \term{implementation},
+the time of day (\ie the passage of time).
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\conref{internal-time-units-per-second}
+
+\label Notes::
+
+Depending on the \term{implementation}, paging time and garbage
+collection time might be included in this measurement.  Also, in a
+multitasking environment, it might not be possible to show the time for
+just the running process, so in some \term{implementations}, time taken
+by other processes during the same time interval might be included in
+this measurement as well.
+
+\endcom 
+
+%%% ========== DISASSEMBLE
+\begincom{disassemble}\ftype{Function}
+
+%% 25.1.0 9
+\label Syntax::
+
+\DefunWithValues disassemble {fn} {\nil}
+
+\label Arguments and Values::
+
+\issue{FUNCTION-NAME:LARGE}
+\param{fn}---an \term{extended function designator}
+	  or a \term{lambda expression}.
+\endissue{FUNCTION-NAME:LARGE}
+
+\label Description::
+
+\Thefunction{disassemble} is a debugging aid that composes symbolic 
+instructions or expressions in some \term{implementation-dependent} 
+language which represent the code used to produce the \term{function}
+which is or is named by the argument \param{fn}.  The result is displayed
+to \term{standard output} in an \term{implementation-dependent} format.
+
+If \param{fn} is a \term{lambda expression} or \term{interpreted function},
+it is compiled first and the result is disassembled.
+
+If the \param{fn} \term{designator} is a \term{function name},
+the \term{function} that it \term{names} is disassembled.
+\issue{DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL}
+(If that \term{function} is an \term{interpreted function},
+it is first compiled but the result of this implicit compilation is not installed.)
+\endissue{DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL}
+
+\label Examples::
+\issue{DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL}
+\code
+ (defun f (a) (1+ a)) \EV F
+ (eq (symbol-function 'f)
+     (progn (disassemble 'f)
+            (symbol-function 'f))) \EV \term{true}
+\endcode
+\endissue{DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL}
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+\varref{*standard-output*}.
+
+\label Exceptional Situations::
+
+\Shouldchecktype{fn}{an \term{extended function designator}
+		  or a \term{lambda expression}}
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom
+
+\issue{DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT}
+
+%%% ========== COMPILER-MACRO
+%%% ========== FUNCTION
+%%% ========== METHOD-COMBINATION
+%%% ========== SETF
+%%% ========== STRUCTURE
+%%% ========== TYPE
+%%% ========== VARIABLE
+%%% ========== DOCUMENTATION
+%%% ========== (SETF DOCUMENTATION)
+\begincom{documentation, (setf documentation)}\ftype{Standard Generic Function}
+ 
+%Note that the CLtL function \funref{documentation} is replaced by a generic function.
+
+\label Syntax::
+ 
+\DefgenWithValues documentation {x doc-type} {documentation}
+
+\DefgenWithValues {(setf documentation)} {new-value x doc-type} {new-value}
+
+\label Argument Precedence Order::
+
+\param{doc-type}, \param{object}
+
+\label Method Signatures::
+
+\def\DocMethods#1#2{{%
+{\bf #1:}\par
+\def\Meth##1##2{\Defmeth{documentation} {\specparam{x}{##1} \specparam{doc-type}{\f{(eql '##2)}}}\idxref{##2}\par}%
+#2\par%
+\def\Meth##1##2{\Defmeth{(setf documentation)} {\param{new-value} \specparam{x}{##1} \specparam{doc-type}{\f{(eql '##2)}}}\idxref{##2}\par}%
+#2\par}}
+
+% I fixed a bunch of font-o's and formatting inconsistencies, and reordered
+% all the methods into something a little less confusing.  --sjl 7 Mar 92
+ 
+\issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+%Signature for STANDARD-SLOT-DESCRIPTION removed.
+
+\DocMethods{Functions, Macros, and Special Forms}{%
+\Meth{function}{t}%
+\Meth{function}{function}%
+\Meth{list}{function}%
+\Meth{list}{compiler-macro}%
+\Meth{symbol}{function}%
+\Meth{symbol}{compiler-macro}%
+\Meth{symbol}{setf}}
+
+\DocMethods{Method Combinations}{%
+\Meth{method-combination}{t}%
+\Meth{method-combination}{method-combination}%
+\Meth{symbol}{method-combination}}
+
+\DocMethods{Methods}{%
+\Meth{standard-method}{t}}
+
+\DocMethods{Packages}{%
+\Meth{package}{t}}
+
+\DocMethods{Types, Classes, and Structure Names}{%
+\Meth{standard-class}{t}%
+\Meth{standard-class}{type}%
+\Meth{structure-class}{t}%
+\Meth{structure-class}{type}%
+\Meth{symbol}{type}%
+\Meth{symbol}{structure}}
+
+\DocMethods{Variables}{%
+\Meth{symbol}{variable}}
+
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}%
+
+\label Arguments and Values::
+ 
+\issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+\param{x}---an \term{object}.
+%% Removed the detail here because it is implied by the signatures above.
+%  This leaves room more naturally for implementation-defined extension. -kmp 2-Sep-91
+%           a \term{symbol},
+% 	    a \term{list}, 
+% 	    a \term{method},
+% 	    a \term{class}, 
+% 	    a \term{package},
+% 	    a \term{function}, 
+% 	 or a \term{method combination} \term{object}.
+% %	 or a slot-description \term{object}.
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+
+\param{doc-type}---a \term{symbol}.
+%% Per issue DOCUMENTATION-FUNCTION-TANGLED, this has been simplified.
+% If \param{x} is a \term{symbol} or a \term{list},
+%  \param{doc-type} must be one of
+%  \issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+%         \misc{compiler-macro},
+%  \endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+%         \misc{function},
+%         \misc{method-combination},
+%         \misc{setf}, 
+%         \misc{structure},
+%         \misc{type},
+%      or \misc{variable};
+%  otherwise, \param{doc-type} must not be supplied.
+ 
+\param{documentation}---a \term{string}, or \nil.
+ 
+\param{new-value}---a \term{string}.
+
+\label Description::
+ 
+\TheGF{documentation} returns the \term{documentation string}
+associated with the given \term{object} if it is available;
+otherwise it returns \nil.
+
+The \term{generic function} \f{(setf documentation)} updates the 
+\term{documentation string} associated with \param{x} to \param{new-value}.
+If \param{x} is a \term{list},
+it must be of the form \f{(setf \param{symbol})}.
+
+\term{Documentation strings} are made available for debugging purposes.
+\term{Conforming programs} are permitted to use \term{documentation strings}
+when they are present, but should not depend for their correct behavior on 
+the presence of those \term{documentation strings}.
+An \term{implementation} is permitted to discard \term{documentation strings} 
+at any time for \term{implementation-defined} reasons.
+
+% For those situations where a \param{doc-type} argument is permitted,
+The nature of the \term{documentation string} returned depends on the
+\param{doc-type}, as follows:
+
+% I alphabetized this list.  --sjl 7 Mar 92
+
+\beginlist
+
+\issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+\itemitem{\misc{compiler-macro}}
+
+Returns the \term{documentation string} of the \term{compiler macro}
+whose \term{name} is the \term{function name} \param{x}.
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+
+\itemitem{\misc{function}}
+
+If \param{x} is a \term{function name},
+returns the \term{documentation string} of 
+the \term{function}, \term{macro}, or \term{special operator} 
+whose \term{name} is \param{x}.
+
+If \param{x} is a \term{function},
+returns the \term{documentation string} associated with \param{x}.
+ 
+\itemitem{\misc{method-combination}}
+
+If \param{x} is a \term{symbol},
+returns the \term{documentation string} of
+the \term{method combination}
+whose \term{name} is \param{x}.
+
+If \param{x} is a \term{method combination},
+returns the \term{documentation string} associated with \param{x}.
+
+\itemitem{\misc{setf}}
+
+Returns the \term{documentation string} of 
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+the \term{setf expander}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+whose \term{name} is the \term{symbol} \param{x}.
+
+\itemitem{\misc{structure}}
+
+%!!! wording??
+Returns the \term{documentation string} 
+associated with the \term{structure name} \param{x}.
+
+\itemitem{\misc{t}}
+
+% added introductory text for this next list  --sjl 7 Mar 92
+Returns a \term{documentation string} specialized on the \term{class} of
+the argument \param{x} itself.
+For example, if \param{x} is a \term{function},
+the \term{documentation string} associated with the \term{function} \param{x} is returned.
+
+% \beginlist
+% 
+% \itemitem{\typeref{function}}
+% 
+% Returns the \term{documentation string} associated with
+% the \term{function} \param{x}.
+% 
+% \itemitem{\typeref{method-combination}}
+% 
+% Returns the \term{documentation string} associated with
+% the \term{method combination} \param{x}.
+% 
+% \itemitem{\typeref{package}}
+% 
+% Returns the \term{documentation string} associated with
+% the \term{package} \param{x}.
+% 
+% \itemitem{\typeref{standard-class} or \typeref{structure-class}}
+% 
+% Returns the \term{documentation string} associated with
+% the \term{class} \param{x}.
+% 
+% \itemitem{\typeref{standard-method}}
+% 
+% Returns the \term{documentation string} associated with
+% the \term{method} \param{x}.
+% 
+% \endlist 
+
+\itemitem{\misc{type}}
+
+If \param{x} is a \term{symbol},
+returns the \term{documentation string} of the \term{class}
+whose \term{name} is the \term{symbol} \param{x},
+if there is such a \term{class}.
+Otherwise, it returns the \term{documentation string} of the \term{type} 
+which is the \term{type specifier} \term{symbol} \param{x}.
+
+If \param{x} is a \term{structure class} or \term{standard class},
+returns the \term{documentation string} associated with
+the \term{class} \param{x}.
+
+\itemitem{\misc{variable}}
+
+Returns the \term{documentation string} of
+the \term{dynamic variable} or \term{constant variable}
+whose \term{name} is the \term{symbol} \param{x}.
+ 
+\endlist
+
+% An implementation may extend the set of \term{symbols} 
+% that are acceptable as the \param{doc-type}.
+% If a \term{symbol} is not recognized as an acceptable \param{doc-type}
+% by the \term{implementation}, an error must be signaled.
+% \editornote{KMP: Can't the user extend this, too, via methods?}%!!!
+%% Rewrite per Moon's instructions:
+A \term{conforming implementation} or a \term{conforming program}
+may extend the set of \term{symbols} that are acceptable as the \param{doc-type}.
+%% This info should follow from the normal rules of method dispatching.
+%% No need to risk making it more complicated. -kmp 21-Aug-93
+%If \param{doc-type} is not recognized, an error is signaled.
+
+% %Moon: This is useless and should be removed.
+% %KMP: Done. 1-Feb-92
+% For those situations where a \param{doc-type} argument is not permitted,
+% the nature of the \term{documentation string} returned depends on the
+% \term{type} of the \term{object} \param{x}.
+
+\label Examples:\None.
+ 
+\label Affected By:\None.
+ 
+\label Exceptional Situations:\None.
+ 
+%% All of this should follow from normal method dispatch now.  Let's not beat
+%% people over the head with a restatement of what should already be apparent,
+%% and also risk that we've said it in some way that's hard to implement. -kmp 21-Aug-93
+%
+% If \param{x} is
+%      a \term{method} \term{object}, 
+%      a \term{class} \term{object},
+% \issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+%      a \term{package} \term{object},
+%      a \term{function} \term{object}, 
+% \endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+%   or a \term{method combination} \term{object},
+% \issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+% % or a slot description \term{object},
+% \endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+% the second argument must not be supplied, 
+% or else an error \oftype{program-error} is signaled.
+%  
+% If a \term{symbol} is not recognized as an acceptable \param{doc-type} argument by the
+% \term{implementation}, an error \oftype{error} is signaled.
+ 
+\label See Also:\None.
+ 
+\label Notes::
+
+\issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+This standard prescribes no means to retrieve the \term{documentation strings}
+for individual slots specified in a \macref{defclass} form, but 
+\term{implementations} might still provide debugging tools and/or
+programming language extensions which manipulate this information.
+Implementors wishing to provide such support are encouraged to consult the
+\term{Metaobject Protocol} for suggestions about how this might be done.
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+
+\endcom
+
+\endissue{DOCUMENTATION-FUNCTION-TANGLED:REQUIRE-ARGUMENT}
+
+%-------------------- Storage System --------------------
+
+%%% ========== ROOM
+\begincom{room}\ftype{Function}
+
+\label Syntax:: 
+
+\DefunWithValues room {{\opt} x} {\term{implementation-dependent}}
+
+\label Arguments and Values:: 
+
+\param{x}---one of \t, \nil, or \kwd{default}.
+
+\label Description::
+
+%% 25.3.0 15
+\funref{room} prints, to \term{standard output},
+information about the state of internal storage and its management.
+This might include descriptions of the amount of memory in use and 
+the degree of memory compaction, possibly broken down by internal data type if that
+is appropriate.  The nature and format of the printed information is
+\term{implementation-dependent}.
+The intent is to provide information that a \term{programmer}
+might use to tune a \term{program} for a particular \term{implementation}.
+
+%% 25.3.0 16
+\f{(room nil)} prints out a minimal amount of information.
+\f{(room t)} prints out a maximal amount of information.
+\issue{ROOM-DEFAULT-ARGUMENT:NEW-VALUE}
+\f{(room)} or \f{(room :default)} prints out an intermediate amount
+of information that is likely to be useful.
+\endissue{ROOM-DEFAULT-ARGUMENT:NEW-VALUE}
+
+\label Examples:\None.
+
+\label Side Effects::
+
+Output to \term{standard output}.
+
+\label Affected By::
+
+\varref{*standard-output*}.
+
+\label Exceptional Situations:\None.
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- Browsing Editing --------------------
+
+%%% ========== ED
+\begincom{ed}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues ed {{\opt} x} {\term{implementation-dependent}}
+
+\label Arguments and Values::
+
+\issue{FUNCTION-NAME:LARGE}
+\param{x}---\nil, a \term{pathname}, a \term{string}, or a \term{function name}.
+\endissue{FUNCTION-NAME:LARGE}
+ \Default{\nil}
+
+\label Description::
+
+%% 25.3.0 17
+\funref{ed} invokes the editor if the \term{implementation} provides a resident editor.
+
+%% 25.3.0 18
+If \param{x} is \nil, the editor is entered.
+If the editor had been previously entered, its prior state is resumed, if possible.
+
+%% 25.3.0 19
+If \param{x} is a \term{pathname} or \term{string}, 
+it is taken as the \term{pathname designator} for a \term{file} to be edited.
+
+%% 25.3.0 20                       
+If \param{x} is a \term{function name}, the text of its definition is edited.
+The means by which the function text is obtained is \term{implementation-defined}.
+
+\label Examples:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+% I changed this from "implicitly vague" to "explicitly vauge" since CLtL doesn't
+% say and since Sandra felt this should be explicit. -kmp 9-Jan-92
+The consequences are undefined if the \term{implementation} does not provide a resident editor.
+
+Might signal \typeref{type-error} if its argument is supplied but is not
+a \term{symbol}, a \term{pathname}, or \nil. 
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+If a failure occurs when performing some operation on the \term{file system}
+while attempting to edit a \term{file},
+an error \oftype{file-error} is signaled.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+An error \oftype{file-error} might be signaled if \param{x}
+is a \term{designator} for a \term{wild} \term{pathname}.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\term{Implementation-dependent} additional conditions might be signaled as well.
+
+\label See Also::
+
+\typeref{pathname},
+\issue{PATHNAME-LOGICAL:ADD}
+\typeref{logical-pathname},
+\endissue{PATHNAME-LOGICAL:ADD}
+\funref{compile-file},
+\funref{load},
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes:\None.
+
+\issue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+% \issue{PATHNAME-LOGICAL:ADD}
+% Whether \funref{ed} recognizes \term{logical pathname} \term{namestrings}
+% is \term{implementation-defined}.
+% \endissue{PATHNAME-LOGICAL:ADD}
+\endissue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+
+\endcom    
+
+%%% ========== INSPECT
+\begincom{inspect}\ftype{Function}
+
+\label Syntax::
+
+\issue{RETURN-VALUES-UNSPECIFIED:SPECIFY}
+\DefunWithValues inspect {object} {\term{implementation-dependent}}
+\endissue{RETURN-VALUES-UNSPECIFIED:SPECIFY}
+
+\label Arguments and Values::
+
+\param{object}---an \term{object}.
+
+\label Description::
+
+%% 25.3.0 14
+\funref{inspect} is an interactive version of \funref{describe}.
+The nature of the interaction is \term{implementation-dependent},
+but the purpose of \funref{inspect} is to make it easy to wander
+through a data structure, examining and modifying parts of it.
+
+\label Examples:\None.
+
+\label Side Effects::
+
+\term{implementation-dependent}.
+
+\label Affected By::
+
+\term{implementation-dependent}.
+
+\label Exceptional Situations::
+
+\term{implementation-dependent}.
+
+\label See Also::
+
+\funref{describe}
+
+\label Notes::
+
+Implementations are encouraged to respond to the typing
+of \f{?} or a ``help key'' by providing help, including a list
+of commands.
+
+\endcom
+
+%-------------------- Read-Eval-Print Loop --------------------
+
+%%% ========== DRIBBLE
+\begincom{dribble}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues dribble {{\opt} pathname} {\term{implementation-dependent}}
+
+\label Arguments and Values::
+
+\param{pathname}---a \term{pathname designator}.
+
+\label Description::
+
+%% 25.3.0 21
+
+Either \term{binds} \varref{*standard-input*} and \varref{*standard-output*} 
+or takes other appropriate action, 
+so as to send a record of the input/output interaction to a file 
+named by \param{pathname}.  \funref{dribble} is intended to create
+a readable record of an interactive session.
+
+\issue{PATHNAME-LOGICAL:ADD}
+If \param{pathname} is a \term{logical pathname}, it is translated
+into a physical pathname as if by calling \funref{translate-logical-pathname}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+%% 25.3.0 22
+\f{(dribble)} terminates the recording of input and output 
+and closes the dribble file.
+
+\issue{JUN90-TRIVIAL-ISSUES:25}
+%Actually, the cleanup said "consequences are unspecified", but I wasn't happy with that,
+%so I made the implementation have to tell you what would happen.
+If \funref{dribble} is \term{called} while a \term{stream} to a ``dribble file'' 
+is still open from a previous \term{call} to \funref{dribble},
+the effect is \term{implementation-defined}.  For example, 
+    the already-\term{open} \term{stream} might be \term{closed}, 
+ or dribbling might occur both to the old \term{stream} and to a new one,
+ or the old \term{stream} might stay open but not receive any further output,
+ or the new request might be ignored,
+ or some other action might be taken.
+\endissue{JUN90-TRIVIAL-ISSUES:25}
+
+\label Examples:\None.
+
+\label Affected By::
+
+The \term{implementation}.
+
+\label Exceptional Situations::
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+If a failure occurs when performing some operation on the \term{file system}
+while creating the dribble file, 
+an error \oftype{file-error} is signaled.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+An error \oftype{file-error} might be signaled if \param{pathname}
+is a \term{designator} for a \term{wild} \term{pathname}.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label See Also::
+
+% This used to say the following, but Sandra thought it was bogus.
+% I tend to agree.  People can cross-reference through "pathname designator". -kmp 9-Jan-92
+% \typeref{pathname},
+% \issue{PATHNAME-LOGICAL:ADD}
+% \typeref{logical-pathname}
+% \endissue{PATHNAME-LOGICAL:ADD}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes::
+
+\issue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+% \issue{PATHNAME-LOGICAL:ADD}
+% Whether \funref{dribble} recognizes \term{logical pathname} \term{namestrings}
+% is \term{implementation-defined}.
+% \endissue{PATHNAME-LOGICAL:ADD}
+\endissue{PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES}
+
+\funref{dribble} can return before subsequent 
+\term{forms} are executed. It also
+can enter a recursive interaction loop, 
+returning only when \f{(dribble)} is done.
+
+\issue{DRIBBLE-TECHNIQUE}
+\funref{dribble} is intended primarily for interactive debugging;
+its effect cannot be relied upon when used in a program.
+\endissue{DRIBBLE-TECHNIQUE}
+\endcom
+
+%%% ========== - (Variable)
+\begincom{$-$}\ftype{Variable}
+
+\label Value Type::
+
+a \term{form}.
+
+\label Initial Value::
+
+\term{implementation-dependent}.
+
+\label Description::
+
+%% 20.2.0 6
+
+\Thevalueof{-} is the \term{form} that is currently being evaluated by
+the \term{Lisp read-eval-print loop}.
+
+\label Examples::
+
+\code
+(format t "~&Evaluating ~S~%" -)
+\OUT Evaluating (FORMAT T "~&Evaluating ~S~%" -)
+\EV NIL
+\endcode
+
+\label Affected By::
+
+\term{Lisp read-eval-print loop}.
+
+\label See Also::
+
+\funref{+} (\term{variable}),
+\funref{*} (\term{variable}),
+\funref{/} (\term{variable}), 
+{\secref\TopLevelLoop}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== + (Variable)
+%%% ========== ++ (Variable)
+%%% ========== +++ (Variable)
+\begincom{+, ++, +++}\ftype{Variable}
+
+\label Value Type::
+
+an \term{object}.
+
+\label Initial Value::
+
+\term{implementation-dependent}.
+
+\label Description::
+
+%% 20.2.0 5
+\Thevariables{+}, \misc{++}, and \misc{+++} are maintained by the
+\term{Lisp read-eval-print loop} to save \term{forms} that were
+recently \term{evaluated}.
+
+\Thevalueof{+}   is the last \term{form} that was \term{evaluated},
+\thevalueof{++}  is the previous value of \misc{+}, and
+\thevalueof{+++} is the previous value of \misc{++}.
+%% 20.2.0 8
+
+%If the evaluation of the variable \misc{+} is aborted for some reason,
+%then the values associated with \misc{++}, 
+%and \misc{+++} are updated ???
+
+\label Examples::
+\code
+(+ 0 1) \EV 1
+(- 4 2) \EV 2
+(/ 9 3) \EV 3
+(list + ++ +++) \EV ((/ 9 3) (- 4 2) (+ 0 1))
+(setq a 1 b 2 c 3 d (list a b c)) \EV (1 2 3)
+(setq a 4 b 5 c 6 d (list a b c)) \EV (4 5 6)
+(list a b c) \EV (4 5 6)
+(eval +++) \EV (1 2 3)
+#.`(,@++ d) \EV (1 2 3 (1 2 3))
+\endcode
+
+\label Affected By:: 
+
+\term{Lisp read-eval-print loop}.
+
+\label See Also::
+
+\funref{-} (\term{variable}),
+\funref{*} (\term{variable}),
+\funref{/} (\term{variable}), 
+{\secref\TopLevelLoop}
+
+\label Notes:\None.
+
+\endcom
+
+
+%%% ========== * (Variable)
+%%% ========== ** (Variable)
+%%% ========== *** (Variable)
+\begincom{*, **, ***}\ftype{Variable}
+
+\label Value Type::
+
+an \term{object}.
+
+\label Initial Value::
+
+\term{implementation-dependent}.
+
+\label Description::
+
+%% 20.2.0 7
+\Thevariables{*}, \misc{**}, and \misc{***} are 
+maintained by the \term{Lisp read-eval-print loop} to save the 
+values of results that are printed each time through the loop.
+
+\Thevalueof{*}   is the most recent \term{primary value} that was printed,
+\thevalueof{**}  is the previous value of \misc{*}, and 
+\thevalueof{***} is the previous value of \misc{**}.
+
+%The values of these variables are not updated when the evaluation of
+%a form is aborted.
+
+If several values are produced, \misc{*} contains the first value only;
+\misc{*} contains \nil\ if zero values are produced.
+
+%%This is very muddled. -kmp 17-Dec-90
+% If the evaluation of the variable \misc{+} is aborted for some reason,
+% then the values associated with \misc{*}, \misc{**}, and \misc{***} are not updated;
+% they are updated only if the printing of values is at least begun (though not
+% necessarily completed).
+
+The \term{values} of \misc{*}, \misc{**}, and \misc{***} are updated immediately
+prior to printing the \term{return value} of a top-level \term{form} by the
+\term{Lisp read-eval-print loop}.  If the \term{evaluation} of such a \term{form}
+is aborted prior to its normal return, the values of \misc{*}, \misc{**}, and \misc{***} 
+are not updated.
+
+\label Examples::
+\code
+(values 'a1 'a2) \EV A1, A2
+'b \EV B
+(values 'c1 'c2 'c3) \EV C1, C2, C3
+(list * ** ***) \EV (C1 B A1)
+
+(defun cube-root (x) (expt x 1/3)) \EV CUBE-ROOT
+(compile *) \EV CUBE-ROOT
+(setq a (cube-root 27.0)) \EV 3.0
+(* * 9.0) \EV 27.0
+\endcode
+
+\label Affected By::
+
+\term{Lisp read-eval-print loop}.
+
+\label See Also::
+
+\funref{-} (\term{variable}),
+\funref{+} (\term{variable}),
+\funref{/} (\term{variable}), 
+{\secref\TopLevelLoop}
+
+\label Notes::
+
+\code
+ *   \EQ (car /)
+ **  \EQ (car //)
+ *** \EQ (car ///)
+\endcode
+
+\endcom
+
+%%% ========== / (Variable)
+%%% ========== // (Variable)
+%%% ========== /// (Variable)
+\begincom{/, //, ///}\ftype{Variable}
+
+\label Value Type::
+
+a \term{proper list}.
+
+\label Initial Value::
+
+\term{implementation-dependent}.
+
+\label Description::
+
+%% 20.2.0 9
+\Thevariables{/}, \misc{//}, and \misc{///} are maintained by
+the \term{Lisp read-eval-print loop} to save the values of results that
+were printed at the end of the loop.
+
+\Thevalueof{/}   is a \term{list} of the most recent \term{values} that were printed,
+\thevalueof{//}  is the previous value of \misc{/}, and
+\thevalueof{///} is the previous value of \misc{//}.
+
+%% 20.2.0 10
+
+%% This is pretty muddled. -kmp 17-Dec-90
+% If the evaluation of the \term{form} associated
+% with the variable \misc{+} is aborted for some reason,
+% then the values associated with 
+% \misc{/}, \misc{//}, and \misc{///} are not updated;
+% they are updated only if the printing of values is at least begun (though not
+% necessarily completed).
+
+The \term{values} of \misc{/}, \misc{//}, and \misc{///} are updated immediately
+prior to printing the \term{return value} of a top-level \term{form} by the
+\term{Lisp read-eval-print loop}.  If the \term{evaluation} of such a \term{form}
+is aborted prior to its normal return, the values of \misc{/}, \misc{//}, and \misc{///} 
+are not updated.
+
+\label Examples::
+\code
+ (floor 22 7) \EV 3, 1
+ (+ (* (car /) 7) (cadr /)) \EV 22
+\endcode
+
+\label Affected By::
+
+\term{Lisp read-eval-print loop}.
+
+\label See Also::
+
+\funref{-} (\term{variable}),
+\funref{+} (\term{variable}),
+\funref{*} (\term{variable}),
+{\secref\TopLevelLoop}
+
+\label Notes:\None.
+
+\endcom
+
+%-------------------- External Environment Queries --------------------
+
+%%% ========== LISP-IMPLEMENTATION-TYPE
+%%% ========== LISP-IMPLEMENTATION-VERSION
+\begincom{lisp-implementation-type,
+          lisp-implementation-version}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues lisp-implementation-type    {\noargs} {description}
+
+\DefunWithValues lisp-implementation-version {\noargs} {description}
+
+\label Arguments and Values::
+
+\param{description}---a \term{string} or \nil.
+
+\label Description::
+
+\funref{lisp-implementation-type} and \funref{lisp-implementation-version} 
+identify the current implementation of \clisp.
+
+%% 25.4.2 2
+\funref{lisp-implementation-type} returns a \term{string} 
+that identifies the generic name of
+the particular \clisp\ implementation.
+
+%% 25.4.2 3
+\funref{lisp-implementation-version} 
+returns a \term{string} that identifies the version of
+the particular \clisp\ implementation.
+
+%% 25.4.2 1
+If no appropriate
+and relevant result can be produced, \nil\ is returned instead
+of a \term{string}.
+
+
+\label Examples::
+
+\code
+ (lisp-implementation-type)
+\EV "ACME Lisp"
+\OV "Joe's Common Lisp"
+ (lisp-implementation-version)
+\EV "1.3a"
+\EV "V2"
+\OV "Release 17.3, ECO #6"
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== SHORT-SITE-NAME
+%%% ========== LONG-SITE-NAME
+\begincom{short-site-name, long-site-name}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues short-site-name {\noargs} {description}
+
+\DefunWithValues long-site-name {\noargs} {description}
+
+\label Arguments and Values:: 
+
+\param{description}---a \term{string} or \nil.
+
+\label Description::
+
+%% 25.4.2 11
+\funref{short-site-name} and \funref{long-site-name} return
+a \term{string} that identifies the physical location 
+of the computer hardware, 
+or \nil\ if no appropriate \param{description} can be produced.
+
+\label Examples::
+
+\code
+ (short-site-name)
+\EV "MIT AI Lab"
+\OV "CMU-CSD"
+ (long-site-name)
+\EV "MIT Artificial Intelligence Laboratory"
+\OV "CMU Computer Science Department"
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+The implementation,
+the location of the computer hardware,
+and the installation/configuration process.
+
+\label Exceptional Situations:\None.
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== MACHINE-INSTANCE
+\begincom{machine-instance}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues machine-instance {\noargs} {description}
+
+\label Arguments and Values::
+
+\param{description}---a \term{string} or \nil.
+
+\label Description::
+
+%% 25.4.2 6
+Returns a \term{string} that identifies the particular instance of
+the computer hardware on which \clisp\ is running, 
+or \nil\ if no such \term{string} can be computed.
+
+\label Examples::
+
+\code
+ (machine-instance)
+\EV "ACME.COM"
+\OV "S/N 123231"
+\OV "18.26.0.179"
+\OV "AA-00-04-00-A7-A4"
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+The machine instance,
+and the \term{implementation}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{machine-type}, \funref{machine-version}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== MACHINE-TYPE
+\begincom{machine-type}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues machine-type {\noargs} {description}
+
+\label Arguments and Values::
+
+\param{description}---a \term{string} or \nil.
+
+\label Description::
+
+%% 25.4.2 4
+Returns a \term{string} that identifies the generic name of
+the computer hardware on which \clisp\ is running.
+
+\label Examples::
+
+\code
+ (machine-type)
+\EV "DEC PDP-10"
+\OV "Symbolics LM-2"
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+The machine type.
+The implementation.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{machine-version}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== MACHINE-VERSION
+\begincom{machine-version}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues machine-version {\noargs} {description}
+
+\label Arguments and Values::
+
+\param{description}---a \term{string} or \nil.
+
+\label Description::
+
+%% 25.4.2 5
+Returns a \term{string} that identifies the version of the computer hardware
+on which \clisp\ is running, or \nil\ if no such value can be computed.
+
+\label Examples::
+
+\code
+ (machine-version) \EV "KL-10, microcode 9"
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+The machine version, 
+and the \term{implementation}.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{machine-type}, \funref{machine-instance}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== SOFTWARE-TYPE
+%%% ========== SOFTWARE-VERSION
+\begincom{software-type, software-version}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues software-type    {\noargs} {description}
+\DefunWithValues software-version {\noargs} {description}
+
+\label Arguments and Values:: 
+
+\param{description}---a \term{string} or \nil.
+
+\label Description::
+
+%% 25.4.2 7
+\funref{software-type} returns a \term{string} that identifies the
+generic name of any relevant supporting software, or \nil\ if no
+appropriate or relevant result can be produced.          
+
+%% 25.4.2 8
+\funref{software-version} returns a \term{string} that identifies 
+the version of any relevant supporting software, or \nil\ if no 
+appropriate or relevant result can be produced.          
+
+\label Examples::
+
+\code
+ (software-type) \EV "Multics"
+ (software-version) \EV "1.3x"
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+Operating system environment.
+
+\label Exceptional Situations:\None.
+
+\label See Also:\None.
+
+\label Notes::
+
+This information should be of use to maintainers of the \term{implementation}.
+
+\endcom
+
+%%% ========== USER-HOMEDIR-PATHNAME
+\begincom{user-homedir-pathname}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues user-homedir-pathname {{\opt} host} {pathname}
+
+\label Arguments and Values::
+
+\param{host}---a \term{string}, a \term{list} of \term{strings}, or \kwd{unspecific}.
+%!!! Barmar: What does a list of strings denote??
+
+\param{pathname}---a \term{pathname}, or \nil.
+
+\label Description::
+
+%% 23.1.2 36
+\funref{user-homedir-pathname} determines the \term{pathname} that corresponds
+to the user's home directory on \param{host}.  
+If \param{host} is not supplied, its value is \term{implementation-dependent}.
+\issue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+For a description of \kwd{unspecific}, \seesection\PathnameComponents.
+\endissue{PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN}
+
+The definition of home directory is \term{implementation-dependent}, 
+but defined in \clisp\ to mean the directory where the user
+keeps personal files such as initialization files and mail.  
+
+\funref{user-homedir-pathname} returns a \term{pathname} without any name, 
+type, or version component (those components are all \nil)
+for the user's home directory on \param{host}.
+
+If it is impossible to determine the user's home directory on \param{host},
+then \nil\ is returned.
+\funref{user-homedir-pathname} never returns \nil\ if \param{host} is not supplied.
+
+
+\label Examples::
+
+\code
+ (pathnamep (user-homedir-pathname)) \EV \term{true}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By::
+
+The host computer's file system,
+and the \term{implementation}.
+
+\label Exceptional Situations:\None.
+
+\label See Also:\None.
+
+\label Notes:\None.
+
+\endcom

dict-eval-compile.tex

@@ -0,0 +1,4358 @@
+% -*- Mode: TeX -*-
+
+% Evaluation Control
+% Macros
+% Declarations
+% Introspection
+
+%-------------------- Lambda Expressions --------------------
+
+%%% ========== LAMBDA (symbol)
+
+\begincom{lambda}\ftype{Symbol}
+
+\issue{DECLS-AND-DOC}
+
+\label Syntax::
+
+\Defspec lambda {lambda-list {\DeclsAndDoc} \starparam{form}}
+
+\label Arguments:: 
+
+\param{lambda-list}---an \term{ordinary lambda list}.
+
+\param{declaration}---a \misc{declare} \term{expression}; \noeval.
+ 
+\param{documentation}---a \term{string}; \noeval.
+
+\param{form}---a \term{form}.
+
+\label Description::
+
+A \term{lambda expression} is a \term{list} that can be used in place of a
+\term{function name} in certain contexts to denote a \term{function} by 
+directly describing its behavior rather than indirectly by referring to the 
+name of an \term{established} \term{function}.
+
+\param{Documentation} is attached to the denoted \param{function} (if any
+is actually created) as a \term{documentation string}.
+
+\label See Also::
+
+\specref{function},
+\specref{documentation},
+{\secref\LambdaExpressions},
+{\secref\LambdaForms},
+{\secref\DocVsDecls}
+
+\label Notes::
+
+The \term{lambda form}
+
+\code
+ ((lambda \param{lambda-list} . \param{body}) . \param{arguments})
+\endcode
+
+is semantically equivalent to the \term{function form}
+
+\code
+ (funcall #'(lambda \param{lambda-list} . \param{body}) . \param{arguments})
+\endcode
+
+\endissue{DECLS-AND-DOC}
+
+\endcom%{lambda}
+
+%%% ========== LAMBDA (macro)
+
+\issue{ISO-COMPATIBILITY:ADD-SUBSTRATE}
+\begincom{lambda}\ftype{Macro}
+
+\label Syntax::
+
+%% 7.6.0 7
+\DefmacWithValues lambda
+	          {lambda-list {\DeclsAndDoc} \starparam{form}}
+		  {\param{function}}
+
+\label Arguments and Values:: 
+
+\param{lambda-list}---an \term{ordinary lambda list}.
+
+\param{declaration}---a \misc{declare} \term{expression}; \noeval.
+ 
+\param{documentation}---a \term{string}; \noeval.
+
+\param{form}---a \term{form}.
+
+\param{function}---a \term{function}.
+
+\label Description::
+
+Provides a shorthand notation for a \specref{function} \term{special form}
+involving a \term{lambda expression} such that:
+
+\code
+    (lambda \param{lambda-list} {\DeclsAndDoc} \starparam{form})
+ \EQ (function (lambda \param{lambda-list} {\DeclsAndDoc} \starparam{form}))
+ \EQ #'(lambda \param{lambda-list} {\DeclsAndDoc} \starparam{form})
+\endcode
+
+\label Examples::
+
+\code
+ (funcall (lambda (x) (+ x 3)) 4) \EV 7
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\misc{lambda} (symbol)
+
+\label Notes::
+
+This macro could be implemented by:
+
+\code
+(defmacro lambda (&whole form &rest bvl-decls-and-body)
+  (declare (ignore bvl-decls-and-body))
+  `#',form)
+\endcode
+
+\endcom%{lambda}
+\endissue{ISO-COMPATIBILITY:ADD-SUBSTRATE}
+
+%-------------------- Evaluation Control --------------------
+
+%%% ========== COMPILE
+
+\begincom{compile}\ftype{Function}
+
+\issue{FUNCTION-NAME:LARGE}
+%%\param{Name} has been changed to \param{function-name} throughout.}
+\endissue{FUNCTION-NAME:LARGE}
+
+\label Syntax::
+
+\DefunWithValues compile {name {\opt} definition} {function, warnings-p, failure-p}
+
+\label Arguments and Values::
+
+\param{name}---a \term{function name}, or \nil.
+               
+%% 25.1.0 5
+\param{definition}---a \term{lambda expression} or a \term{function}.
+  \Default{the function definition of \param{name} if it names a \term{function},
+	   or the \term{macro function} of \param{name} if it names a \term{macro}}
+  The consequences are undefined if no \param{definition} is supplied
+  when the \param{name} is \nil.
+
+%% 25.1.0 6
+\param{function}---the \param{function-name},
+\issue{COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN}
+	        or a \term{compiled function}.
+\endissue{COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN}
+
+\param{warnings-p}---a \term{generalized boolean}.
+
+\param{failure-p}---a \term{generalized boolean}.
+
+\label Description::
+
+Compiles an \term{interpreted function}.
+%% Moon: Intent is compilation envirionment = startup environment.
+%%       Just delete this phrase, I think.
+%in the current \term{dynamic environment}.
+
+\funref{compile} produces a \term{compiled function} from \param{definition}.
+If the \param{definition} is a \term{lambda expression},
+it is coerced to a \term{function}.  
+\issue{COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX}
+If the \param{definition} is already a \term{compiled function},
+\funref{compile} either produces that function itself (\ie is an identity operation)
+or an equivalent function.
+\endissue{COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX}
+
+\editornote{KMP: There are a number of ambiguities here that still need resolution.}%!!!
+% Cases of interest:
+% Given: (defmacro foist (x) `(car ,x))
+% What do these do:
+%  (compile 'foist (macro-function 'foist))
+%  (compile 'foist (symbol-function 'foist))
+%  (compile 'foist '(lambda (x y) (+ x y)))
+If the \param{name} is \nil,
+the resulting \term{compiled function} is returned directly as the \term{primary value}.
+If a \term{non-nil} \param{name} is given, 
+then the resulting \term{compiled function} replaces 
+the existing \term{function} definition of \param{name}
+and the \param{name} is returned as the \term{primary value};
+if \param{name} is a \term{symbol} that names a \term{macro},
+its \term{macro function} is updated
+and the \param{name} is returned as the \term{primary value}.
+
+% I moved this paragraph so it isn't in the middle of the discussion
+% of compiler diagnostics.  --sjl 7 Mar 92
+\issue{QUOTE-SEMANTICS:NO-COPYING}
+% Constants -> Literal objects. -kmp 15-Jan-91
+\term{Literal objects} appearing in code processed by 
+the \funref{compile} function are neither copied nor \term{coalesced}.
+The code resulting from the execution of \funref{compile} 
+references \term{objects} that are \funref{eql} to the corresponding
+\term{objects} in the source code.  
+\endissue{QUOTE-SEMANTICS:NO-COPYING}
+
+\issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+\funref{compile} is permitted, but not required, to \term{establish}
+a \term{handler} for \term{conditions} \oftype{error}.
+For example, the \term{handler} might issue a warning and 
+restart compilation from some \term{implementation-dependent} point 
+in order to let the compilation proceed without manual intervention.
+\endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+
+The \term{secondary value}, \param{warnings-p}, is \term{false}
+% clarify ``compiler diagnostics''  --sjl 7 Mar 92
+%if no compiler diagnostics were issued, and \term{true} otherwise.
+if no \term{conditions} \oftype{error} or \typeref{warning}
+were detected by the compiler, and \term{true} otherwise.
+
+The \term{tertiary value}, \param{failure-p}, is \term{false}
+% clarify ``compiler diagnostics''  --sjl 7 Mar 92
+%if no compiler diagnostics other than \term{style warnings} were issued.
+%A value of \term{true} indicates that there were serious compiler diagnostics
+%issued, or that other \term{conditions} \oftype{error} or \typeref{warning}
+%(but not \oftype{style-warning}) were signaled during compilation.
+if no \term{conditions} \oftype{error} or \typeref{warning}
+(other than \typeref{style-warning})
+were detected by the compiler, and \term{true} otherwise.
+
+\label Examples::
+
+\code
+ (defun foo () "bar") \EV FOO
+ (compiled-function-p #'foo) \EV \term{implementation-dependent}
+ (compile 'foo) \EV FOO 
+ (compiled-function-p #'foo) \EV \term{true}
+ (setf (symbol-function 'foo)
+       (compile nil '(lambda () "replaced"))) \EV #<Compiled-Function>
+ (foo) \EV "replaced"
+\endcode
+% (defun foo ...) \EV foo  ;A function definition.
+% (compile 'foo) \EV foo   ;Compile it.
+%                          ;Now foo runs faster.
+
+\label Affected By::
+
+\issue{COMPILER-WARNING-STREAM}
+\varref{*error-output*},
+\endissue{COMPILER-WARNING-STREAM}
+\varref{*macroexpand-hook*}.
+
+The presence of macro definitions and proclamations.
+
+\label Exceptional Situations::
+
+\issue{COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX}
+The consequences are undefined if the \term{lexical environment} surrounding the
+\term{function} to be compiled contains any \term{bindings} other than those for
+\term{macros}, \term{symbol macros}, or \term{declarations}.
+
+% The consequences are undefined if the \term{function} to be compiled
+% was defined in a \term{non-null lexical environment}.
+
+% The consequences are unspecified if the \term{function} is already a
+% \term{compiled function}.
+\endissue{COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX}
+
+%% should be an error signaled if name is nil and no definition is supplied.
+%% also if function is already compiled.
+%ERROR and WARNING conditions may be signaled within 
+%    COMPILE or COMPILE-FILE, including arbitrary errors which may 
+%    occur due to compile-time processing of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) 
+%    forms or macro expansion.
+% 
+
+% The following information is mostly redundant with info in the chapter 3
+% concept section, and contains some inconsistencies.  Better to just
+% put in a cross-reference.  --sjl 4 mar 92
+% \issue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+% The following list considers only 
+% those conditions signaled by the compiler as
+%     opposed to within the compiler.
+%  
+%     An error \oftype{error} might be signaled by the compiler in
+%         situations where the compilation cannot proceed without
+%         intervention.
+%         Examples include
+% 	    file open errors and
+%    	    syntax errors.
+%  
+% An error \oftype{warning} might be signaled by the compiler in 
+% situations where the standard explicitly states 
+% that a warning must, should, or might be signaled.
+% Also, an error \oftype{warning} might be signaled 
+% by the compiler in situations where the compiler can determine 
+% that a situation with undefined consequences or that would cause
+% an error to be signaled would result at runtime.
+% Examples include
+%  violation of type declarations,
+%  \term{assigning} or \term{binding} a \term{constant variable},
+%  calling a built-in Lisp function with the wrong number of arguments
+%    or malformed keyword argument lists,
+%  referencing a variable declared \declref{ignore}, 
+%  and the usage of unrecognized declaration specifiers.
+%  
+% The compiler is permitted to signal errors \oftype{style-warning}
+% about matters of programming style. Although \term{style warnings} might 
+% be signaled in these situations, no implementation is required to 
+% signal them. However, if an implementation does choose to signal an
+% error about matters of programming style, 
+% that error is \oftype{style-warning} and is signaled by a call to \funref{warn}.
+% Examples include
+%  redefinition of a \term{function} with a different argument list,
+%  calling a \term{function} with the wrong number of arguments,
+%  \term{accessing} unreferenced local variables not declared \declref{ignore}, 
+%  and usage of declaration specifiers described in the standard but ignored by the compiler.
+%  
+% \issue{COMPILER-WARNING-STREAM}
+% %%This is now implied by the remarks about using WARN above.
+% %\funref{compile} is permitted to issue warnings through \term{error output}.
+% \endissue{COMPILER-WARNING-STREAM}
+% 
+% \endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
+
+For information about errors detected during the compilation process, 
+\seesection\FileCompilerExceptions.
+
+\label See Also::
+
+\funref{compile-file}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== EVAL
+\begincom{eval}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues eval {form} {\starparam{result}}
+
+\label Arguments and Values::
+
+\param{form}---a \term{form}.
+
+\param{results}---the \term{values} \term{yielded} by the \term{evaluation} of \param{form}.
+
+%% Goes without saying. -kmp 8-Aug-91
+% %% 7.9.2 4
+% Returns multiple values if \param{form} produces multiple values.
+
+\label Description::                    
+
+%% 20.1.0 2
+Evaluates \param{form} in the current \term{dynamic environment}
+and the \term{null lexical environment}.
+
+
+%% 20.1.0 1
+\funref{eval} is a user interface to the evaluator.
+
+%% 8.2.0 5
+The evaluator expands macro calls as if through the use of \funref{macroexpand-1}.
+
+%%% 9.1.0 3
+%It is an error to attempt to evaluate a declaration.
+%Those \term{forms} that permit declarations to appear
+%perform explicit checks for their presence.
+
+\issue{QUOTE-SEMANTICS:NO-COPYING}
+Constants appearing in code
+processed by \funref{eval} are
+not copied nor coalesced. The code resulting from the execution of 
+\funref{eval}
+references \term{objects} 
+that are \funref{eql} to the corresponding \term{objects} in
+the source code.  
+\endissue{QUOTE-SEMANTICS:NO-COPYING}
+
+%!!! Barmar: What about compiler macros?
+
+\label Examples::
+
+\code
+ (setq form '(1+ a) a 999) \EV 999
+ (eval form) \EV 1000
+ (eval 'form) \EV (1+ A)
+ (let ((a '(this would break if eval used local value))) (eval form))
+\EV 1000
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\issue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+%\funref{evalhook},
+%\funref{applyhook},
+\endissue{EVALHOOK-STEP-CONFUSION:X3J13-NOV-89}
+\funref{macroexpand-1},
+{\secref\EvaluationModel}
+
+\label Notes::
+
+%% 20.1.0 4
+To obtain the current dynamic value of a \term{symbol}, 
+use of \funref{symbol-value} is equivalent (and usually preferable) 
+to use of \funref{eval}.
+
+%% 20.1.0 3
+Note that an \funref{eval} \term{form} involves two levels of \term{evaluation} 
+for its \term{argument}.  First, \param{form} is \term{evaluated} by the
+normal argument evaluation mechanism as would occur with any \term{call}.
+The \term{object} that results from this normal \term{argument} \term{evaluation} 
+becomes the \term{value} of the \param{form} \term{parameter}, and is then
+\term{evaluated} as part of the \funref{eval} \term{form}.
+For example:
+
+\code
+ (eval (list 'cdr (car '((quote (a . b)) c)))) \EV b
+\endcode
+The \term{argument} \term{form} \f{(list 'cdr (car '((quote (a . b)) c)))} is evaluated
+in the usual way to produce the \term{argument} \f{(cdr (quote (a . b)))}; 
+% this is then given to \funref{eval} 
+% because \funref{eval} is being called explicitly,
+% and 
+\funref{eval} then evaluates its \term{argument}, \f{(cdr (quote (a . b)))}, to produce \f{b}.
+Since a single \term{evaluation} already occurs for any \term{argument} \term{form}
+in any \term{function form},
+\funref{eval} is sometimes said to perform ``an extra level of evaluation.''
+
+\issue{EVALHOOK-STEP-CONFUSION:FIX}
+% Hooks are provided for user-supplied debugging routines
+% to obtain control during the execution of an interpretive evaluator.
+% \funref{evalhook} and \funref{applyhook} provide alternative
+% interfaces to the evaluator mechanism for use by these debugging routines.
+\endissue{EVALHOOK-STEP-CONFUSION:FIX}
+
+\endcom
+
+%%% ========== EVAL-WHEN
+\begincom{eval-when}\ftype{Special Operator}      
+
+\label Syntax::
+
+\DefspecWithValues eval-when
+		   {\paren{\starparam{situation}} \starparam{form}}
+		   {\starparam{result}}
+
+\label Arguments and Values::
+
+\issue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+\param{situation}---One of the \term{symbols} 
+		    \kwd{compile-toplevel}\idxkwd{compile-toplevel},
+		    \kwd{load-toplevel}\idxkwd{load-toplevel},
+		    \kwd{execute}\idxkwd{execute},
+		    \misc{compile}\idxref{compile},
+		    \misc{load}\idxref{load}, or
+		    \misc{eval}\idxref{eval}.
+
+The use of \misc{eval}, \misc{compile}, and \misc{load} is deprecated.
+\issue{EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993}
+%They are supported when \specref{eval-when} is a \term{top level form},
+%but their meaning is not defined elsewhere.
+\endissue{EVAL-WHEN-OBSOLETE-KEYWORDS:X3J13-MAR-1993}
+\endissue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+
+\param{forms}---an \term{implicit progn}.
+
+\param{results}---the \term{values} of the \term{forms} if they are executed,
+		  or \nil\ if they are not. 
+
+\label Description::
+
+%%% 5.3.3 2
+%\specref{eval-when} specifies when a particular body
+%of code is to be evaluated.
+%%% 5.3.3 1.5
+%\specref{eval-when} allows pieces of code to
+%be executed only at compile time, only in compiled code, or
+%when interpreted but not compiled.  
+%If no \param{forms} are executed, \specref{eval-when} returns
+%\nil.
+%
+%%% 5.3.3 3
+%\f{eval} specifies that the interpreter should process the body.
+%\f{compile} specifies that the compiler should evaluate the body
+%at compile time in the compilation context.
+%\f{load} specifies that the compiler should arrange to evaluate
+%the forms in the body when the compiled file containing the
+%\specref{eval-when} form is \term{loaded}.
+%
+%The body of \specref{eval-when} is processed as an implicit
+%\specref{progn}, but only in the allowed \param{situations}.
+%
+%
+\issue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+The body of an \specref{eval-when} form is processed as an \term{implicit progn}, 
+but only in the \param{situations} listed.  
+%Each \param{situation} must be a symbol,
+%  either COMPILE, LOAD, or EVAL.
+
+% The file compilation section only describe processing by COMPILE-FILE.
+% We must say something explicit here about EVAL and COMPILE.
+% (The last paragraph from the eval-when cleanup has gotten lost.)
+% I have rewritten this below to include the missing info.  --sjl 5 Mar 92
+ 
+%  The use of the \param{situations} \kwd{compile-toplevel} ({\tt compile}) and 
+% \kwd{load-toplevel} ({\tt load}) controls whether and when processing
+%   occurs for \term{top level forms}. The use of 
+% the situation \kwd{execute} ({\tt eval}) controls whether
+%   processing occurs for \term{non-top-level forms}.
+% 
+% For a description of \specref{eval-when} processing, \seesection\FileCompilation.
+
+The use of the \param{situations} \kwd{compile-toplevel} (or {\tt compile}) and
+\kwd{load-toplevel} (or {\tt load}) controls whether and when \term{evaluation}
+occurs when \specref{eval-when} appears as a \term{top level form} in
+code processed by \funref{compile-file}.  \Seesection\FileCompilation.
+
+The use of the \param{situation} \kwd{execute} (or {\tt eval}) controls whether
+evaluation occurs for other \specref{eval-when} \term{forms}; that is, 
+those that are not \term{top level forms}, or those in code processed by
+\funref{eval} or \varref{compile}.  If the \kwd{execute} situation is
+specified in such a \term{form}, then the body \param{forms} are processed as 
+an \term{implicit progn}; otherwise, the \specref{eval-when} \term{form}
+returns \nil.
+ 
+%  The \specref{eval-when} 
+%construct can be more precisely understood in terms of
+%  a model of how the file compiler, COMPILE-FILE, processes forms in a
+%  file to be compiled.
+
+
+%When  successive \term{forms} are 
+%read from the file by \funref{compile-file},
+%these \term{top level forms} are normally processed in 
+%  not-compile-time mode. There is one other mode, called 
+%  compile-time-too mode, that is also used for processing \term{top level forms}.
+%  The \specref{eval-when} special form 
+%is used to annotate a program
+%  in a way that allows the program doing the processing to select
+%  the appropriate mode.
+% 
+%When \funref{compile-file}
+%encounters an \specref{eval-when} form, the \term{form}
+%is handled according to
+%the table in \thenextfigure.
+% 
+%\boxfig
+%{\dimen0=.75pc
+%\tabskip \dimen0 plus .5 fil
+%\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip 
+%\dimen0 plus .5 fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus 1fil
+%&#\hfil\cr 
+%\noalign{\vskip -9pt}
+%\hfil{\bf A} & {\bf B} & {\bf C} & {\bf D}& {\bf Action} \cr
+%& & & & \cr
+%   Yes &  Yes  &--     &--             &Process body in compile-time-too
+%mode\cr
+%   No   &Yes  &Yes    &Yes            &Process body in compile-time-too mode\cr
+%   No    &Yes  &Yes    &No             &Process body in not-compile-time mode\cr
+%   No    &Yes  &No     &--             &Process body in not-compile-time mode\cr
+%   Yes   &No   &--     &--             &Evaluate body\cr
+%   No    &No   &Yes    &Yes            &Evaluate body\cr
+%   No    &No   &Yes    &No             &do nothing\cr
+%   No    &No   &No     &--             &do nothing\cr
+%\noalign{\vskip -9pt}
+%}}
+%\caption{\specref{eval-when} processing}
+%\endfig
+%Column A indicates
+%{\tt   :compile-toplevel}  processing.
+%Column B indicates \kwd{load-toplevel} processing.
+%Column C indicates {\tt    :execute} processing.
+%Column D indicates  compile-time-too processing.
+%   
+%  Process body means to process the body (using the procedure 
+%  outlined in this subsection) as an implicit toplevel \specref{progn}.
+% 
+% 
+%  Evaluate body means to evaluate the body \param{forms} as an 
+%  \term{implicit progn} in the
+%  % dynamic execution context
+%  \term{dynamic environment} of the compiler and in the
+%  \term{lexical environment} in which the \specref{eval-when} appears.
+%          
+%  For an \specref{eval-when} 
+%form that is not a \term{top level form},  
+%if the \kwd{execute} situation is specified,
+%the body of the \specref{eval-when}
+%is treated as an \term{implicit progn}.  Otherwise, the 
+%\specref{eval-when}
+%  form returns \nil.
+%An \specref{eval-when} form is a \term{non-top-level form}
+%if it is one of the following: 
+%in the interpreter, in \funref{compile}, or in \funref{compile-file}
+%but not a \term{top level form}. 
+\endissue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+
+%!!! Barmar: Redundant.  (KMP: I'll have to think about that.)
+\issue{DEFINING-MACROS-NON-TOP-LEVEL:ALLOW}
+\specref{eval-when} 
+normally appears as a \term{top level form}, but it is meaningful
+for it to appear as a \term{non-top-level form}.
+However, the compile-time side
+effects described in {\secref\Compilation}
+only take place when \specref{eval-when} appears as a  
+\term{top level form}.
+\endissue{DEFINING-MACROS-NON-TOP-LEVEL:ALLOW}
+ 
+%\specref{eval-when} is meaningful only as a \term{top level form}.
+
+\label Examples::
+
+%!!! Are the EVAL-WHEN return values correct?? -kmp 29-Aug-91
+
+%% Moon: Why isn't this compile toplevel? Maybe this example is not portable?
+%%       It's an obfuscating example anyway. Delete it.
+% \code
+%  (setq temp 3) \EV 3 
+%  (eval-when (:compile-toplevel) (setq temp 2)) \EV NIL 
+%  temp \EV 3 
+%  (eval-when (:execute) (setq temp 2)) \EV 2 
+%  temp \EV 2 
+% \endcode
+
+%% 5.3.3 10
+One example of the use of \specref{eval-when} is that for the 
+compiler to be able to read a file properly when it uses user-defined
+\term{reader macros}, it is necessary to write
+
+\code
+ (eval-when (:compile-toplevel :load-toplevel :execute)
+   (set-macro-character #\\$ #'(lambda (stream char)
+                                (declare (ignore char))
+                                (list 'dollar (read stream))))) \EV T
+\endcode
+This causes the call to \funref{set-macro-character} to be executed
+in the compiler's execution environment, thereby modifying its
+reader syntax table.
+
+\code
+;;;     The EVAL-WHEN in this case is not at toplevel, so only the :EXECUTE
+;;;     keyword is considered. At compile time, this has no effect.
+;;;     At load time (if the LET is at toplevel), or at execution time
+;;;     (if the LET is embedded in some other form which does not execute
+;;;     until later) this sets (SYMBOL-FUNCTION 'FOO1) to a function which
+;;;     returns 1.
+ (let ((x 1))
+   (eval-when (:execute :load-toplevel :compile-toplevel)
+     (setf (symbol-function 'foo1) #'(lambda () x))))
+
+;;;     If this expression occurs at the toplevel of a file to be compiled,
+;;;     it has BOTH a compile time AND a load-time effect of setting
+;;;     (SYMBOL-FUNCTION 'FOO2) to a function which returns 2.
+ (eval-when (:execute :load-toplevel :compile-toplevel)
+   (let ((x 2))
+     (eval-when (:execute :load-toplevel :compile-toplevel)
+       (setf (symbol-function 'foo2) #'(lambda () x)))))
+
+;;;     If this expression occurs at the toplevel of a file to be compiled,
+;;;     it has BOTH a compile time AND a load-time effect of setting the
+;;;     function cell of FOO3 to a function which returns 3.
+ (eval-when (:execute :load-toplevel :compile-toplevel)
+   (setf (symbol-function 'foo3) #'(lambda () 3)))
+ 
+;;; #4: This always does nothing. It simply returns NIL.
+ (eval-when (:compile-toplevel)
+   (eval-when (:compile-toplevel) 
+     (print 'foo4)))
+
+;;;     If this form occurs at toplevel of a file to be compiled, FOO5 is
+;;;     printed at compile time. If this form occurs in a non-top-level
+;;;     position, nothing is printed at compile time. Regardless of context,
+;;;     nothing is ever printed at load time or execution time.
+ (eval-when (:compile-toplevel) 
+   (eval-when (:execute)
+     (print 'foo5)))
+ 
+;;;     If this form occurs at toplevel of a file to be compiled, FOO6 is
+;;;     printed at compile time.  If this form occurs in a non-top-level
+;;;     position, nothing is printed at compile time. Regardless of context,
+;;;     nothing is ever printed at load time or execution time.
+ (eval-when (:execute :load-toplevel)
+   (eval-when (:compile-toplevel)
+     (print 'foo6)))
+\endcode
+ 
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{compile-file}, {\secref\Compilation}
+
+\label Notes::
+
+\issue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+The following effects are logical consequences of the definition of 
+\specref{eval-when}:
+ 
+\beginlist
+\itemitem{\bull}
+Execution of a single \specref{eval-when}
+expression executes the body code at most once.
+ 
+\itemitem{\bull}
+\term{Macros} intended for use in \term{top level forms} 
+should be written so that side-effects are done by the \term{forms}
+in the macro expansion.  The macro-expander itself should not do 
+the side-effects.
+ 
+For example:
+
+       Wrong:  
+
+\code
+ (defmacro foo ()
+   (really-foo)
+   `(really-foo))
+\endcode
+    
+      Right:  
+
+\code
+ (defmacro foo ()
+   `(eval-when (:compile-toplevel :execute :load-toplevel) (really-foo)))
+\endcode
+ 
+Adherence to this convention means that such \term{macros} behave
+intuitively when appearing as \term{non-top-level forms}.
+ 
+\itemitem{\bull}
+Placing a variable binding around an \specref{eval-when} reliably 
+captures the binding because the compile-time-too mode cannot occur 
+ (\ie introducing a variable binding means that the \specref{eval-when}
+      is not a \term{top level form}).
+For example,
+ 
+\code
+ (let ((x 3))
+   (eval-when (:execute :load-toplevel :compile-toplevel) (print x)))
+\endcode
+
+
+prints {\tt 3} 
+at execution (\ie load) time, and does not print anything at
+compile time.  This is important so that expansions of 
+\macref{defun} and 
+\macref{defmacro} 
+can be done in terms of \specref{eval-when} and can correctly capture
+the \term{lexical environment}.
+ 
+\code
+ (defun bar (x) (defun foo () (+ x 3)))
+\endcode
+ 
+might expand into
+ 
+\code
+ (defun bar (x) 
+   (progn (eval-when (:compile-toplevel) 
+            (compiler::notice-function-definition 'foo '(x)))
+          (eval-when (:execute :load-toplevel)
+            (setf (symbol-function 'foo) #'(lambda () (+ x 3))))))
+\endcode
+
+which would be treated by the above rules the same as
+ 
+\code
+ (defun bar (x) 
+   (setf (symbol-function 'foo) #'(lambda () (+ x 3))))
+\endcode
+ 
+when the definition of \f{bar} is not a \term{top level form}.
+\endlist
+ 
+\endissue{EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS}
+                                                                        
+\endcom
+
+%% Replaced per X3J13. -kmp 05-Oct-93
+% %%% ========== LOAD-TIME-VALUE
+% \begincom{load-time-value}\ftype{Special Operator}      
+% \issue{LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM}
+% 
+% \label Syntax::
+% 
+% \DefspecWithValues load-time-value {form {\opt} read-only-p} {object}
+% 
+% \label Arguments and Values::         
+% 
+% \param{form}---a \term{form}; \evalspecial.
+% 
+% \param{read-only-p}---one of the \term{symbols} \t\ or \nil; \noeval.
+% 
+% \param{object}---the \term{primary value} resulting from evaluating \param{form}.
+% 
+% \label Description::
+% 
+% \specref{load-time-value} provides a mechanism for delaying evaluation of \param{form}
+% until the expression is in the run-time environment; \seesection\Compilation.
+%  
+% \param{Read-only-p} designates whether the result can be considered a
+% \term{constant object}. If \nil\ (the default), the result must be considered 
+% ordinary, modifiable data. If \t, the result is a read-only quantity
+% that can, if appropriate to the \term{implementation}, 
+% be copied into read-only space and/or \term{coalesced} with \term{similar}
+% \term{constant objects} from other \term{programs}.
+% 
+% If a \specref{load-time-value} expression is processed by \funref{compile-file},
+% the compiler performs its normal semantic processing (such as macro expansion 
+% and translation into machine code) on \param{form}, but arranges for the
+% execution of \param{form} to occur at load time in a \term{null lexical environment}, 
+% with the result of this \term{evaluation} then being treated as 
+% %an immediate quantity
+% a \term{literal object}
+% at run time.  It is guaranteed that the evaluation of \param{form} 
+% will take place only once when the \term{file} is \term{loaded}, but 
+% the order of evaluation with respect to the evaluation of
+% \term{top level forms} in the file is \term{implementation-dependent}.
+% \idxtext{order of evaluation}\idxtext{evaluation order}
+%  
+% If a \specref{load-time-value} expression appears within a function compiled
+% with \funref{compile}, the \param{form} is evaluated at compile time in a
+% \term{null lexical environment}.  The result of this compile-time evaluation 
+% is treated as
+% %an immediate quantity
+% a \term{literal object}
+% in the compiled code.  
+%  
+% If a \specref{load-time-value} expression is processed by \funref{eval},
+% \param{form} is evaluated in a \term{null lexical environment}, 
+% and one value is returned.  Implementations that implicitly compile
+% (or partially compile) expressions processed by \funref{eval} 
+% %"can" => "might".  Barrett thought "can" was clumsy.
+% might evaluate \param{form} only once, at the time this compilation is performed.  
+% %This is intentionally similar to the
+% %   freedom which implementations are given for the time of expanding
+% %   macros in interpreted code.
+%  
+% If the \term{same} \term{list} \f{(load-time-value \param{form})} is
+% evaluated or compiled more than once, it is \term{implementation-dependent}
+% whether \param{form} is evaluated only once or is evaluated more than once.
+% This can happen both when an expression being evaluated or compiled shares
+% substructure, and when the \term{same} \term{form} is processed by \funref{eval} or 
+% \funref{compile} multiple times.                               
+% Since a \specref{load-time-value} expression can be
+%   referenced in more than one place and can be evaluated multiple times
+%   by \funref{eval}, it is 
+% \term{implementation-dependent} whether each execution returns
+%   a fresh \term{object} 
+% or returns the same \term{object} as some other execution.
+%   Users must use caution when destructively modifying the resulting
+%   \term{object}.
+% 
+% If two lists \f{(load-time-value \param{form})} 
+% that are the \term{same} under \funref{equal} but are not \term{identical}
+% are evaluated or compiled,
+% their values always come from distinct evaluations of \param{form}.
+% %Per Barrett: "These forms" => "Their values"
+% Their \term{values} may not be coalesced
+% %Added per Barmar:
+% unless \param{read-only-p} is \t.
+%  
+% \label Examples:\None.
+%  
+% \label Affected By:\None.
+% 
+% \label Exceptional Situations:\None.
+% 
+% \label See Also::
+% 
+% \funref{compile-file},
+% \funref{compile},
+% \funref{eval},
+% {\secref\MinimalCompilation},
+% {\secref\Compilation}
+% 
+% \label Notes::
+% 
+% \specref{load-time-value} must appear outside of quoted structure in a
+% ``for \term{evaluation}'' position.  In situations which would appear to call
+% for use of \specref{load-time-value} within a quoted structure, 
+% the \term{backquote} \term{reader macro} is probably called for;
+% \seesection\Backquote.
+% 
+% \endissue{LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM}
+%                                                                         
+% \endcom
+
+%%% ========== LOAD-TIME-VALUE
+\begincom{load-time-value}\ftype{Special Operator}      
+\issue{LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM}
+
+\label Syntax::
+
+\DefspecWithValues load-time-value {form {\opt} read-only-p} {object}
+
+\label Arguments and Values::         
+
+\param{form}---a \term{form}; \evalspecial.
+
+\param{read-only-p}---a \term{boolean}; \noeval.
+
+\param{object}---the \term{primary value} resulting from evaluating \param{form}.
+
+\label Description::
+
+\specref{load-time-value} provides a mechanism for delaying evaluation of \param{form}
+until the expression is in the run-time environment; \seesection\Compilation.
+ 
+\param{Read-only-p} designates whether the result can be considered a
+\term{constant object}.
+If \t,
+   the result is a read-only quantity that can, 
+   if appropriate to the \term{implementation}, 
+   be copied into read-only space and/or \term{coalesced} with \term{similar}
+   \term{constant objects} from other \term{programs}.
+If \nil\ (the default),
+   the result must be neither copied nor coalesced;
+   it must be considered to be potentially modifiable data.
+
+If a \specref{load-time-value} expression is processed by \funref{compile-file},
+the compiler performs its normal semantic processing (such as macro expansion 
+and translation into machine code) on \param{form}, but arranges for the
+execution of \param{form} to occur at load time in a \term{null lexical environment}, 
+with the result of this \term{evaluation} then being treated as 
+%an immediate quantity
+a \term{literal object}
+at run time.  It is guaranteed that the evaluation of \param{form} 
+will take place only once when the \term{file} is \term{loaded}, but 
+the order of evaluation with respect to the evaluation of
+\term{top level forms} in the file is \term{implementation-dependent}.
+\idxtext{order of evaluation}\idxtext{evaluation order}
+ 
+If a \specref{load-time-value} expression appears within a function compiled
+with \funref{compile}, the \param{form} is evaluated at compile time in a
+\term{null lexical environment}.  The result of this compile-time evaluation 
+is treated as
+%an immediate quantity
+a \term{literal object}
+in the compiled code.  
+ 
+If a \specref{load-time-value} expression is processed by \funref{eval},
+\param{form} is evaluated in a \term{null lexical environment}, 
+and one value is returned.  Implementations that implicitly compile
+(or partially compile) expressions processed by \funref{eval} 
+%"can" => "might".  Barrett thought "can" was clumsy.
+might evaluate \param{form} only once, at the time this compilation is performed.  
+%This is intentionally similar to the
+%   freedom which implementations are given for the time of expanding
+%   macros in interpreted code.
+ 
+If the \term{same} \term{list} \f{(load-time-value \param{form})} is
+evaluated or compiled more than once, it is \term{implementation-dependent}
+whether \param{form} is evaluated only once or is evaluated more than once.
+This can happen both when an expression being evaluated or compiled shares
+substructure, and when the \term{same} \term{form} is processed by \funref{eval} or 
+\funref{compile} multiple times.                               
+Since a \specref{load-time-value} expression can be
+  referenced in more than one place and can be evaluated multiple times
+  by \funref{eval}, it is 
+\term{implementation-dependent} whether each execution returns
+  a fresh \term{object} 
+or returns the same \term{object} as some other execution.
+  Users must use caution when destructively modifying the resulting
+  \term{object}.
+
+If two lists \f{(load-time-value \param{form})} 
+that are the \term{same} under \funref{equal} but are not \term{identical}
+are evaluated or compiled,
+their values always come from distinct evaluations of \param{form}.
+%Per Barrett: "These forms" => "Their values"
+Their \term{values} may not be coalesced
+%Added per Barmar:
+unless \param{read-only-p} is \t.
+ 
+\label Examples::
+
+\code
+;;; The function INCR1 always returns the same value, even in different images.
+;;; The function INCR2 always returns the same value in a given image, 
+;;; but the value it returns might vary from image to image.
+(defun incr1 (x) (+ x #.(random 17)))
+(defun incr2 (x) (+ x (load-time-value (random 17))))
+
+;;; The function FOO1-REF references the nth element of the first of 
+;;; the *FOO-ARRAYS* that is available at load time.  It is permissible for
+;;; that array to be modified (e.g., by SET-FOO1-REF); FOO1-REF will see the
+;;; updated values.
+(defvar *foo-arrays* (list (make-array 7) (make-array 8)))
+(defun foo1-ref (n) (aref (load-time-value (first *my-arrays*) nil) n))
+(defun set-foo1-ref (n val) 
+  (setf (aref (load-time-value (first *my-arrays*) nil) n) val))
+
+;;; The function BAR1-REF references the nth element of the first of 
+;;; the *BAR-ARRAYS* that is available at load time.  The programmer has
+;;; promised that the array will be treated as read-only, so the system 
+;;; can copy or coalesce the array.
+(defvar *bar-arrays* (list (make-array 7) (make-array 8)))
+(defun bar1-ref (n) (aref (load-time-value (first *my-arrays*) t) n))
+
+;;; This use of LOAD-TIME-VALUE permits the indicated vector to be coalesced
+;;; even though NIL was specified, because the object was already read-only
+;;; when it was written as a literal vector rather than created by a constructor.
+;;; User programs must treat the vector v as read-only.
+(defun baz-ref (n)
+  (let ((v (load-time-value #(A B C) nil)))
+    (values (svref v n) v)))
+
+;;; This use of LOAD-TIME-VALUE permits the indicated vector to be coalesced
+;;; even though NIL was specified in the outer situation because T was specified
+;;; in the inner situation.  User programs must treat the vector v as read-only.
+(defun baz-ref (n)
+  (let ((v (load-time-value (load-time-value (vector 1 2 3) t) nil)))
+    (values (svref v n) v)))
+\endcode
+ 
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\funref{compile-file},
+\funref{compile},
+\funref{eval},
+{\secref\MinimalCompilation},
+{\secref\Compilation}
+
+\label Notes::
+
+\specref{load-time-value} must appear outside of quoted structure in a
+``for \term{evaluation}'' position.  In situations which would appear to call
+for use of \specref{load-time-value} within a quoted structure, 
+the \term{backquote} \term{reader macro} is probably called for;
+\seesection\Backquote.
+
+Specifying \nil\ for \param{read-only-p} is not a way to force an object
+to become modifiable if it has already been made read-only.  It is only a way
+to say that, for an object that is modifiable, this operation is not intended
+to make that object read-only.
+
+\endissue{LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM}
+                                                                        
+\endcom
+
+%%% ========== QUOTE
+\begincom{quote}\ftype{Special Operator}
+
+\label Syntax::
+
+\DefspecWithValues quote {object} {object}
+
+\label Arguments and Values:: 
+
+\param{object}---an \term{object}; \noeval.
+
+\label Description::
+
+%% 7.1.1 3
+\Thespecop{quote} just returns \param{object}.
+
+% added  --sjl 3 Mar 92
+The consequences are undefined if \term{literal objects} (including
+\term{quoted objects}) are destructively modified.
+
+\label Examples::
+
+\code
+ (setq a 1) \EV 1
+ (quote (setq a 3)) \EV (SETQ A 3)
+ a \EV 1
+ 'a \EV A
+ ''a \EV (QUOTE A) 
+ '''a \EV (QUOTE (QUOTE A))
+ (setq a 43) \EV 43
+ (list a (cons a 3)) \EV (43 (43 . 3))
+ (list (quote a) (quote (cons a 3))) \EV (A (CONS A 3)) 
+ 1 \EV 1
+ '1 \EV 1
+ "foo" \EV "foo"
+ '"foo" \EV "foo"
+ (car '(a b)) \EV A
+ '(car '(a b)) \EV (CAR (QUOTE (A B)))
+ #(car '(a b)) \EV #(CAR (QUOTE (A B)))
+ '#(car '(a b)) \EV #(CAR (QUOTE (A B)))
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+{\secref\Evaluation},
+{\secref\QuoteMacro},
+\issue{CONSTANT-MODIFICATION:DISALLOW}
+{\secref\ConstantModification}
+\endissue{CONSTANT-MODIFICATION:DISALLOW}
+
+\label Notes::
+
+The textual notation \f{'\param{object}} is equivalent to \f{(quote \param{object})};
+\seesection\ConstantModification.
+
+%% 7.1.0 1
+Some \term{objects}, called \term{self-evaluating objects}, 
+do not require quotation by \specref{quote}.  
+However, \term{symbols} and \term{lists} are used to represent parts of programs,
+and so would not be useable as constant data in a program without \specref{quote}.
+Since \specref{quote} suppresses the \term{evaluation} of these \term{objects},
+they become data rather than program.
+
+\endcom
+
+%-------------------- Macros --------------------
+
+%%% ========== COMPILER-MACRO-FUNCTION
+\begincom{compiler-macro-function}\ftype{Accessor}
+
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+
+\label Syntax::
+
+\DefunWithValues compiler-macro-function {name {\opt} environment} {function}
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+\Defsetf         compiler-macro-function {name {\opt} environment} {new-function}
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+\label Arguments and Values::
+
+\param{name}---a \term{function name}.
+
+\param{environment}---an \term{environment} \term{object}.
+
+\param{function}, \param{new-function}---a \term{compiler macro function}, or \nil.
+ 
+\label Description::
+
+\term{Accesses} the \term{compiler macro function} named \param{name}, if any,
+in the \param{environment}.
+
+A value of \nil\ denotes the absence of a \term{compiler macro function} named \param{name}.
+
+\label Examples:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+ 
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+The consequences are undefined if \param{environment} is \term{non-nil}
+in a use of \SETFof{compiler-macro-function}.
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+\label See Also::
+ 
+\macref{define-compiler-macro}, {\secref\CompilerMacros}
+
+\label Notes:\None.
+
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+
+\endcom
+
+%%% ========== DEFINE-COMPILER-MACRO
+\begincom{define-compiler-macro}\ftype{Macro}
+ 
+\issue{DECLS-AND-DOC}
+
+\label Syntax::
+
+\DefmacWithValuesNewline define-compiler-macro
+			 {name lambda-list {\DeclsAndDoc} \starparam{form}}
+			 {name}
+
+\label Arguments and Values::
+
+\param{name}---a \term{function name}.
+
+% tweaked.  --sjl 5 Mar 92 
+% \param{lambda-list}---a \term{lambda list}; 
+%  can contain the lambda list keywords
+%   \keyref{allow-other-keys},
+%   \keyref{aux},
+%   \keyref{body},
+%   \keyref{environment},
+%   \keyref{key},
+%   \keyref{optional}, 
+%   \keyref{rest},
+%  and 
+%  \keyref{whole}.
+\param{lambda-list}---a \term{macro lambda list}.
+ 
+\param{declaration}---a \misc{declare} \term{expression}; \noeval.
+ 
+\param{documentation}---a \term{string}; \noeval.
+
+\param{form}---a \term{form}.
+
+\label Description::
+
+\editornote{KMP: This definition probably needs to be fully expanded to not
+	 	 refer through the definition of defmacro, but should suffice for now.}
+% If this rewriting happens, be sure to copy the compile-time side-effects
+% info from DEFMACRO too.  -- sjl 5 Mar 92
+
+This is the normal mechanism for defining a \term{compiler macro function}.
+Its manner of definition is the same as for \macref{defmacro}; the only
+differences are:
+
+\beginlist
+\itemitem{\bull} The \param{name} can be a \term{function name} naming
+ any \term{function} or \term{macro}.
+
+\itemitem{\bull} The expander function is installed as a \term{compiler macro function}
+ for the \param{name}, rather than as a \term{macro function}.
+
+\itemitem{\bull} The \keyref{whole} argument is bound to the form argument that 
+ is passed to the \term{compiler macro function}.  The remaining lambda-list 
+ parameters are specified as if this form contained the function name in the
+ \term{car} and the actual arguments in the \term{cdr}, but if the \term{car} 
+ of the actual form is the symbol \funref{funcall}, then the destructuring of 
+ the arguments is actually performed using its \term{cddr} instead.
+
+\itemitem{\bull}\issue{DOCUMENTATION-FUNCTION-BUGS:FIX}%
+ \param{Documentation} is attached as a \term{documentation string} 
+    to \param{name} (as kind \specref{compiler-macro})
+and to the \term{compiler macro function}.
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+
+\itemitem{\bull} Unlike an ordinary \term{macro}, a \term{compiler macro}
+ can decline to provide an expansion merely by returning a form that is
+ the \term{same} as the original (which can be obtained by using
+ \keyref{whole}).
+\endlist 
+
+\label Examples::
+
+\code
+ (defun square (x) (expt x 2)) \EV SQUARE
+ (define-compiler-macro square (&whole form arg)
+   (if (atom arg)
+       `(expt ,arg 2)
+       (case (car arg)
+         (square (if (= (length arg) 2)
+                     `(expt ,(nth 1 arg) 4)
+                     form))
+         (expt   (if (= (length arg) 3)
+                     (if (numberp (nth 2 arg))
+                         `(expt ,(nth 1 arg) ,(* 2 (nth 2 arg)))
+                         `(expt ,(nth 1 arg) (* 2 ,(nth 2 arg))))
+                     form))
+         (otherwise `(expt ,arg 2))))) \EV SQUARE
+ (square (square 3)) \EV 81
+ (macroexpand '(square x)) \EV (SQUARE X), \term{false}
+ (funcall (compiler-macro-function 'square) '(square x) nil)
+\EV (EXPT X 2)
+ (funcall (compiler-macro-function 'square) '(square (square x)) nil)
+\EV (EXPT X 4)
+ (funcall (compiler-macro-function 'square) '(funcall #'square x) nil)
+\EV (EXPT X 2)
+
+ (defun distance-positional (x1 y1 x2 y2)
+   (sqrt (+ (expt (- x2 x1) 2) (expt (- y2 y1) 2))))
+\EV DISTANCE-POSITIONAL
+ (defun distance (&key (x1 0) (y1 0) (x2 x1) (y2 y1))
+   (distance-positional x1 y1 x2 y2))
+\EV DISTANCE
+ (define-compiler-macro distance (&whole form
+                                  &rest key-value-pairs
+                                  &key (x1 0  x1-p)
+                                       (y1 0  y1-p)
+                                       (x2 x1 x2-p)
+                                       (y2 y1 y2-p)
+                                  &allow-other-keys
+                                  &environment env)
+   (flet ((key (n) (nth (* n 2) key-value-pairs))
+          (arg (n) (nth (1+ (* n 2)) key-value-pairs))
+          (simplep (x)
+            (let ((expanded-x (macroexpand x env)))
+              (or (constantp expanded-x env)
+                  (symbolp expanded-x)))))
+     (let ((n (/ (length key-value-pairs) 2)))
+       (multiple-value-bind (x1s y1s x2s y2s others)
+           (loop for (key) on key-value-pairs by #'cddr
+                 count (eq key ':x1) into x1s
+                 count (eq key ':y1) into y1s
+                 count (eq key ':x2) into x2s
+                 count (eq key ':y1) into y2s
+                 count (not (member key '(:x1 :x2 :y1 :y2)))
+                   into others
+                 finally (return (values x1s y1s x2s y2s others)))
+         (cond ((and (= n 4)
+                     (eq (key 0) :x1)
+                     (eq (key 1) :y1)
+                     (eq (key 2) :x2)
+                     (eq (key 3) :y2))
+                `(distance-positional ,x1 ,y1 ,x2 ,y2))
+               ((and (if x1-p (and (= x1s 1) (simplep x1)) t)
+                     (if y1-p (and (= y1s 1) (simplep y1)) t)
+                     (if x2-p (and (= x2s 1) (simplep x2)) t)
+                     (if y2-p (and (= y2s 1) (simplep y2)) t)
+                     (zerop others))
+                `(distance-positional ,x1 ,y1 ,x2 ,y2))
+               ((and (< x1s 2) (< y1s 2) (< x2s 2) (< y2s 2)
+                     (zerop others))
+                (let ((temps (loop repeat n collect (gensym))))
+                  `(let ,(loop for i below n
+                               collect (list (nth i temps) (arg i)))
+                     (distance
+                       ,@(loop for i below n
+                               append (list (key i) (nth i temps)))))))
+               (t form))))))
+\EV DISTANCE
+ (dolist (form
+           '((distance :x1 (setq x 7) :x2 (decf x) :y1 (decf x) :y2 (decf x))
+             (distance :x1 (setq x 7) :y1 (decf x) :x2 (decf x) :y2 (decf x))
+             (distance :x1 (setq x 7) :y1 (incf x))
+             (distance :x1 (setq x 7) :y1 (incf x) :x1 (incf x))
+             (distance :x1 a1 :y1 b1 :x2 a2 :y2 b2)
+             (distance :x1 a1 :x2 a2 :y1 b1 :y2 b2)
+             (distance :x1 a1 :y1 b1 :z1 c1 :x2 a2 :y2 b2 :z2 c2)))
+   (print (funcall (compiler-macro-function 'distance) form nil)))
+\OUT (LET ((#:G6558 (SETQ X 7))
+\OUT       (#:G6559 (DECF X))
+\OUT       (#:G6560 (DECF X))
+\OUT       (#:G6561 (DECF X)))
+\OUT   (DISTANCE :X1 #:G6558 :X2 #:G6559 :Y1 #:G6560 :Y2 #:G6561)) 
+\OUT (DISTANCE-POSITIONAL (SETQ X 7) (DECF X) (DECF X) (DECF X)) 
+\OUT (LET ((#:G6567 (SETQ X 7))
+\OUT       (#:G6568 (INCF X)))
+\OUT   (DISTANCE :X1 #:G6567 :Y1 #:G6568)) 
+\OUT (DISTANCE :X1 (SETQ X 7) :Y1 (INCF X) :X1 (INCF X)) 
+\OUT (DISTANCE-POSITIONAL A1 B1 A2 B2) 
+\OUT (DISTANCE-POSITIONAL A1 B1 A2 B2) 
+\OUT (DISTANCE :X1 A1 :Y1 B1 :Z1 C1 :X2 A2 :Y2 B2 :Z2 C2) 
+\EV NIL
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None. 
+
+\label See Also::
+
+\funref{compiler-macro-function},
+\macref{defmacro},
+\funref{documentation},
+{\secref\DocVsDecls}
+
+\label Notes::
+
+The consequences of writing a \term{compiler macro} definition for a function
+in \thepackage{common-lisp} are undefined; it is quite possible that in some
+\term{implementations} such an attempt would override an equivalent or equally
+important definition.  In general, it is recommended that a programmer only
+write \term{compiler macro} definitions for \term{functions} he or she personally 
+maintains--writing a \term{compiler macro} definition for a function maintained
+elsewhere is normally considered a violation of traditional rules of modularity
+and data abstraction.
+
+\endissue{DECLS-AND-DOC}
+
+\endcom
+
+%%% ========== DEFMACRO
+\begincom{defmacro}\ftype{Macro}
+
+\issue{DECLS-AND-DOC}
+
+\label Syntax::
+
+\DefmacWithValuesNewline defmacro {name lambda-list {\DeclsAndDoc} \starparam{form}} {name}
+ 
+\label Arguments and Values::
+
+\param{name}---a \term{symbol}. %!!! maybe call it a "user symbol" ?? -kmp 2-Aug-91
+ 
+%% 8.1.0 9
+%% 8.1.0 10
+%% 8.1.0 11
+%% 8.1.0 12
+\param{lambda-list}---a \term{macro lambda list}.
+ 
+\param{declaration}---a \misc{declare} \term{expression}; \noeval.
+ 
+\param{documentation}---a \term{string}; \noeval.
+ 
+\param{form}---a \term{form}.
+ 
+\label Description::
+
+%% 8.1.0 6
+Defines \param{name} as a \term{macro} 
+by associating a \term{macro function} with that \param{name}
+in the global environment.
+\issue{DEFINING-MACROS-NON-TOP-LEVEL:ALLOW}
+% Reworded garbled text.  --sjl 7 Mar 92
+%When the \term{macro function} is called,
+%the \param{forms} are evaluated in
+%the \term{lexical environment} in which the \macref{defmacro} form was evaluated.
+The \term{macro function} is defined in the same \term{lexical environment}
+in which the \macref{defmacro} \term{form} appears.
+\endissue{DEFINING-MACROS-NON-TOP-LEVEL:ALLOW}
+
+ 
+%% 8.1.0 7
+The parameter variables in \param{lambda-list} are bound to
+destructured portions of the macro call.
+ 
+The expansion function
+accepts two arguments, a \term{form} and an 
+\term{environment}.  The expansion function returns a \term{form}.  
+The body of the expansion function is specified by \param{forms}.
+\param{Forms} are executed in order.  The value of the
+last \param{form} executed is returned as the expansion of the
+\term{macro}.
+\issue{FLET-IMPLICIT-BLOCK:YES}
+\issue{DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS}
+The body \param{forms} of the expansion function (but not the \param{lambda-list})
+\endissue{DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS}
+are implicitly enclosed in a \term{block} whose name is \param{name}.
+\endissue{FLET-IMPLICIT-BLOCK:YES}
+ 
+The \param{lambda-list} conforms to the requirements described in \secref\MacroLambdaLists.
+ 
+\issue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+\param{Documentation} is attached as a \term{documentation string} 
+    to \param{name} (as kind \specref{function})
+and to the \term{macro function}.
+\endissue{DOCUMENTATION-FUNCTION-BUGS:FIX}
+ 
+%% 8.1.0 17
+\macref{defmacro} can be used to redefine a \term{macro} or to replace
+a \term{function} definition with a \term{macro} definition.
+ 
+%% sandra says this is redundant
+%The consequences are undefined if a \term{special form} is redefined
+%using \macref{defmacro}.
+ 
+\issue{RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE}
+Recursive expansion of the \term{form} returned must terminate,
+including the expansion of other \term{macros} which are \term{subforms}
+of other \term{forms} returned.
+
+%% Per Moon#13 (first public review) -kmp 5-May-93
+The consequences are undefined if the result of fully macroexpanding
+%a form contains any non-constant circular list structure.
+a \term{form}
+contains any \term{circular} \term{list structure} except in \term{literal objects}.
+\endissue{RECURSIVE-DEFTYPE:EXPLICITLY-VAGUE}
+ 
+\issue{COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY}
+% added qualification about top-level-ness  --sjl 5 Mar 92
+If a \macref{defmacro} \term{form} appears as a \term{top level form},
+the \term{compiler} must store the \term{macro} definition at compile time,
+so that occurrences of the macro later on in the file can be expanded correctly.
+Users must ensure that the body of the \term{macro} can be evaluated at 
+compile time if it is referenced within the \term{file} being \term{compiled}.
+\endissue{COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY}
+
+\label Examples::
+
+\code
+ (defmacro mac1 (a b) "Mac1 multiplies and adds" 
+            `(+ ,a (* ,b 3))) \EV MAC1 
+ (mac1 4 5) \EV 19 
+ (documentation 'mac1 'function) \EV "Mac1 multiplies and adds" 
+ (defmacro mac2 (&optional (a 2 b) (c 3 d) &rest x) `'(,a ,b ,c ,d ,x)) \EV MAC2 
+ (mac2 6) \EV (6 T 3 NIL NIL) 
+ (mac2 6 3 8) \EV (6 T 3 T (8)) 
+ (defmacro mac3 (&whole r a &optional (b 3) &rest x &key c (d a))
+    `'(,r ,a ,b ,c ,d ,x)) \EV MAC3 
+ (mac3 1 6 :d 8 :c 9 :d 10) \EV ((MAC3 1 6 :D 8 :C 9 :D 10) 1 6 9 8 (:D 8 :C 9 :D 10)) 
+\endcode
+% (defmacro mac4
+%      (&whole (su &rest (p &rest q)) a 
+%              &optional (b 3) &rest x &key c (d a))
+%    `'(,su ,p ,a ,b ,c ,d ,x)) \EV MAC4 
+% (mac4 1 6 :d 8 :c 9 :d 10) \EV (MAC4 1 1 6 9 8 (:D 8 :C 9 :D 10)) 
+ 
+%An example of destructuring follows:
+% 
+%\code
+% (defmacro halibut ((mouth eye1 eye2)
+%                    ((fin1 length1) (fin2 length2))
+%                    tail)
+% ...)
+%\endcode
+%Now consider this macro call:
+% 
+%\code
+% (halibut (m (car eyes) (cdr eyes))
+%          ((f1 (count-scales f1)) (f2 (count-scales f2)))
+%          my-favorite-tail) \EV NIL
+%\endcode
+%This would cause the expansion function to receive the 
+%values in \thenextfigure\ for its parameters:
+% 
+%\boxfig
+%{\dimen0=.75pc
+%\tabskip \dimen0 plus .5 fil
+%\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr 
+%\noalign{\vskip -9pt}
+%\hfil{{\sl Parameter\/}} & {{\sl Value\/}} \cr
+%\noalign{\vskip 2pt\hrule\vskip 2pt}
+%mouth & m \cr
+%eye1 & (car eyes) \cr
+%eye2 & (cdr eyes) \cr
+%fin1 & f1 \cr
+%length1 & (count-scales f1) \cr
+%fin2 & f2 \cr
+%length2 & (count-scales f2) \cr
+%tail & my-favorite-tail \cr
+%\noalign{\vskip -9pt}                              
+%}}
+%\caption{Destructuring example expansion function values}
+%\endfig
+%The following macro call would be in error because there would be no
+%argument form to match the parameter \f{length1}:
+% 
+%\code
+% (halibut (m (car eyes) (cdr eyes))
+%          ((f1) (f2 (count-scales f2)))
+%          my-favorite-tail)
+%\endcode
+%The following macro call would be in error because a \term{symbol} appears
+%in the call where the structure of the \term{lambda list} requires a 
+%\term{list}:
+% 
+%\code
+% (halibut my-favorite-head
+%          ((f1 (count-scales f1)) (f2 (count-scales f2)))
+%          my-favorite-tail)
+%\endcode
+%The fact that the value of the variable \f{my-favorite-head}
+%might happen to be a \term{list} is irrelevant here.  It is the macro call
+%itself whose structure must match that of the \macref{defmacro} 
+%\term{lambda list}.
+% 
+%%% 8.1.0 25
+%The use of \term{lambda list keywords} is illustrated as follows.
+%Suppose it is convenient within the expansion
+%function for \f{halibut} to be able to refer to the \term{list}
+%whose components are called \f{mouth}, \f{eye1}, and \f{eye2} 
+%as \f{head}.
+%This may be written as follows:
+% 
+%\code
+% (defmacro halibut ((&whole head mouth eye1 eye2)
+%                    ((fin1 length1) (fin2 length2))
+%                    tail)
+% ...)
+%\endcode
+%Now consider the same valid macro call as before:
+% 
+%\code
+% (halibut (m (car eyes) (cdr eyes))
+%          ((f1 (count-scales f1)) (f2 (count-scales f2)))
+%          my-favorite-tail) \EV NIL
+%\endcode
+%This would cause the expansion function to receive the same
+%values for its parameters and also a value for the parameter \f{head}
+%as in \thenextfigure.
+% 
+%\boxfig
+%{\dimen0=.75pc
+%\tabskip \dimen0 plus .5 fil
+%\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr 
+%\noalign{\vskip -9pt}
+%\hfil{{\sl Parameter\/}} & {{\sl Value\/}} \cr
+%\noalign{\vskip 2pt\hrule\vskip 2pt}
+%head & (m (car eyes) (cdr eyes)) \cr
+%\noalign{\vskip -9pt}
+%}}
+%\caption{Lambda list keywords expansion function values example}
+%\endfig
+% 
+%%% 8.1.0 19
+%The following implements a conditional \term{form} analogous to the
+%\fortran\ arithmetic IF statement.  
+%The \term{form} should accept four argument forms: a \f{test-value},
+%a \f{neg-form}, a \f{zero-form}, and a \f{pos-form}.
+%One of the last three forms is chosen to be executed according
+%to whether the value of the \f{test-form} is positive, negative,
+%or zero.
+%Using \macref{defmacro}, a definition for such a \term{form}
+%might look like this:
+% 
+%\code
+% (defmacro arithmetic-if (test neg-form zero-form pos-form)
+%   (let ((var (gensym)))
+%     `(let ((,var ,test))
+%        (cond ((< ,var 0) ,neg-form)
+%            ((= ,var 0) ,zero-form)
+%            (t ,pos-form))))) \EV ARITHMETIC-IF
+%\endcode
+%Note the use of the backquote facility in this definition,
+%and also the use of \funref{gensym} to generate a new variable name.
+%This is necessary to avoid conflict with any variables that might
+%be referred to in \f{neg-form}, \f{zero-form}, or \f{pos-form}.
+% 
+%%% 8.1.0 20
+%If the form is executed by the interpreter, it will cause the
+%function definition of the symbol \f{arithmetic-if}
+%to be a macro associated with which is
+%a two-argument expansion function roughly equivalent to:
+% 
+%\code
+% (lambda (calling-form environment)
+%   (declare (ignore environment))
+%   (let ((var (gensym)))
+%     (list 'let
+%           (list (list 'var (cadr calling-form)))
+%           (list 'cond
+%                 (list (list '< var '0) (caddr calling-form))
+%                 (list (list '= var '0) (cadddr calling-form))
+%                 (list 't (fifth calling-form))))))
+%\endcode
+ 
+ 
+% Barmar had noted that if we were going to show the above lambda, we should show
+% the defmacro that might have produced it.  But since we're not going to show it,
+% I guess the issue is moot. -kmp 28-Dec-90
+%
+%%% 8.1.0 21
+%The \term{lambda expression} 
+%could have been produced by the \macref{defmacro} macro.
+%The calls to \funref{list} are the (hypothetical) result 
+%of the backquote (\f{\bq})
+%macro character and its associated commas.
+%The precise macro expansion function might depend on the implementation.
+%For example, the implementation
+%might provide some degree of explicit error checking on the number
+%of argument forms in the macro call.
+% 
+%%% 8.1.0 22
+% 
+%%If \funref{eval} encounters
+%% 
+%%\code
+% (arithmetic-if (- x 4.0)
+%%                (- x)
+%%                (error "Strange zero")
+%%                x)
+%%\endcode
+%this will be expanded into something like
+% 
+%\code
+% (let ((g407 (- x 4.0)))
+%   (cond ((< g407 0) (- x))
+%         ((= g407 0) (error "Strange zero"))
+%         (t x)))
+%\endcode
+%and \funref{eval} tries again on this new form.
+% 
+%%% 8.1.0 23
+%To expand on this example
+%the \f{pos-form}
+%and \f{zero-form} could be omitted, allowing their values to default to \nil,
+%in the same way that the \f{else} form of \specref{if} 
+%may be omitted:
+% 
+%\code
+% (defmacro arithmetic-if (test neg-form &optional zero-form pos-form)
+%   (let ((var (gensym)))
+%     \bq(let ((,var ,test))
+%        (cond ((< ,var 0) ,neg-form)
+%              ((= ,var 0) ,zero-form)
+%              (t ,pos-form)))))
+%\endcode
+%Then 
+% 
+%\code
+% (arithmetic-if (- x 4.0) (print x))
+%\endcode
+%would be expanded into something like
+% 
+%\code
+% (let ((g408 (- x 4.0)))
+%   (cond ((< g408 0) (print x))
+%         ((= g408 0) nil)
+%         (t nil)))
+%\endcode
+ 
+%% 8.1.0 26
+The stipulation that
+an embedded \term{destructuring lambda list} is permitted only
+where \term{ordinary lambda list} syntax would permit a parameter name
+but not a \term{list} is made to prevent ambiguity.  For example,
+the following is not valid:
+ 
+\code
+ (defmacro loser (x &optional (a b &rest c) &rest z)
+   ...)
+\endcode
+because \term{ordinary lambda list} syntax does permit a 
+\term{list} following \optional;
+the list \f{(a b \&rest c)} would be interpreted as describing an
+optional parameter named \f{a} whose default value is that of the
+form \f{b}, with a supplied-p parameter named \keyref{rest} (not valid),
+and an extraneous symbol \f{c} in the list (also not valid).  An almost
+correct way to express this is
+ 
+\code
+ (defmacro loser (x &optional ((a b &rest c)) &rest z)
+   ...)
+\endcode
+The extra set of parentheses removes the ambiguity.  However, the
+definition is now incorrect because a macro call such as \f{(loser (car pool))}
+would not provide any argument form for the lambda list \f{(a b \&rest c)},
+and so the default value against which to match the \term{lambda list} would be
+\nil\ because no explicit default value was specified.  
+The consequences of this are  unspecified
+since the empty list, \nil, does not have \term{forms} to satisfy the
+parameters \f{a} and \f{b}.  The fully correct definition would be either
+ 
+\code
+ (defmacro loser (x &optional ((a b &rest c) '(nil nil)) &rest z)
+   ...)
+\endcode
+or
+ 
+\code
+ (defmacro loser (x &optional ((&optional a b &rest c)) &rest z)
+   ...)
+\endcode
+These differ slightly: the first requires that if the macro call
+specifies \f{a} explicitly then it must also specify \f{b} explicitly,
+whereas the second does not have this requirement.  For example,
+ 
+\code
+ (loser (car pool) ((+ x 1)))
+\endcode
+would be a valid call for the second definition but not for the first.
+ 
+\issue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+ 
+\code
+ (defmacro dm1a (&whole x) `',x)
+ (macroexpand '(dm1a))  \EV (QUOTE (DM1A))
+ (macroexpand '(dm1a a)) is an error.
+ 
+ (defmacro dm1b (&whole x a &optional b) `'(,x ,a ,b))
+ (macroexpand '(dm1b))  is an error.
+ (macroexpand '(dm1b q))  \EV (QUOTE ((DM1B Q) Q NIL))
+ (macroexpand '(dm1b q r)) \EV (QUOTE ((DM1B Q R) Q R))
+ (macroexpand '(dm1b q r s)) is an error.
+\endcode
+ 
+\code
+ (defmacro dm2a (&whole form a b) `'(form ,form a ,a b ,b))
+ (macroexpand '(dm2a x y)) \EV (QUOTE (FORM (DM2A X Y) A X B Y))
+ (dm2a x y) \EV (FORM (DM2A X Y) A X B Y)
+
+ (defmacro dm2b (&whole form a (&whole b (c . d) &optional (e 5)) 
+                 &body f &environment env)
+   ``(,',form ,,a ,',b ,',(macroexpand c env) ,',d ,',e ,',f))
+ ;Note that because backquote is involved, implementations may differ
+ ;slightly in the nature (though not the functionality) of the expansion.
+ (macroexpand '(dm2b x1 (((incf x2) x3 x4)) x5 x6))
+ \EV (LIST* '(DM2B X1 (((INCF X2) X3 X4))
+                   X5 X6)
+            X1
+            '((((INCF X2) X3 X4)) (SETQ X2 (+ X2 1)) (X3 X4) 5 (X5 X6))),
+     T
+ (let ((x1 5))
+   (macrolet ((segundo (x) `(cadr ,x)))
+     (dm2b x1 (((segundo x2) x3 x4)) x5 x6)))
+ \EV ((DM2B X1 (((SEGUNDO X2) X3 X4)) X5 X6)
+      5 (((SEGUNDO X2) X3 X4)) (CADR X2) (X3 X4) 5 (X5 X6))
+\endcode
+ 
+\endissue{DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION}
+ 
+\label Affected By:\None.
+
+\label Exceptional Situations:\none.
+% adequately covered in the packages chapter.  --sjl 5 Mar 92
+% \issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+% The consequences are undefined if \param{name} 
+% is a \term{symbol} in \thepackage{common-lisp}.
+% \endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+
+% Barmar writes:
+%     "Macros must not modify any of the structure they are given."
+%     We outlawed displacing at some point.
+% but I couldn't find anything to back up this claim.  Issue MACRO-CACHING
+% had this in mind, but didn't go far enough. So I've left this alone for now.
+% -kmp 2-Aug-91
+
+\label See Also::
+
+\issue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+\macref{define-compiler-macro},
+\endissue{DEFINE-COMPILER-MACRO:X3J13-NOV89}
+\macref{destructuring-bind}, 
+\funref{documentation},
+\funref{macroexpand},
+\varref{*macroexpand-hook*},
+\specref{macrolet}, 
+\funref{macro-function}, 
+{\secref\Evaluation},
+{\secref\Compilation},
+{\secref\DocVsDecls}
+
+\label Notes:\None.
+ 
+\endissue{DECLS-AND-DOC}
+
+\endcom
+
+%%% ========== MACRO-FUNCTION
+\begincom{macro-function}\ftype{Accessor}
+ 
+\label Syntax::
+
+\DefunWithValues macro-function {symbol {\opt} environment} {function}
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+% % If it's an error to supply the environment argument here, the syntax
+% % shouldn't show it.  Compare w/COMPILER-MACRO-FUNCTION.  --sjl 5 Mar 92
+% % \Defsetf         macro-function {symbol {\opt} environment} {new-function}
+% \Defsetf         macro-function {symbol} {new-function}
+%% Reinstated per X3J13.
+\Defsetf         macro-function {symbol {\opt} environment} {new-function}
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+\label Arguments and Values::
+
+\param{symbol}---a \term{symbol}.
+ 
+\issue{MACRO-FUNCTION-ENVIRONMENT}
+\param{environment}---an \term{environment} \term{object}.
+\endissue{MACRO-FUNCTION-ENVIRONMENT}
+
+\param{function}---a \term{macro function} or \nil.
+ 
+\param{new-function}---a \term{macro function}.
+
+\label Description::
+
+%% 8.1.0 2
+Determines whether \param{symbol} has a function definition 
+as a macro in the specified \param{environment}.
+ 
+If so, the macro expansion function, a function of two arguments,
+is returned.  If \param{symbol} has no function definition
+in the lexical environment \param{environment}, or its definition
+is not a \term{macro}, \funref{macro-function} returns \nil.
+ 
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+\issue{MACRO-FUNCTION-ENVIRONMENT}
+% The consequences are undefined if \param{environment} is supplied 
+% in a use of \funref{macro-function} as a \macref{setf} location specifier.
+\endissue{MACRO-FUNCTION-ENVIRONMENT}
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+%This doesn't belong here. -kmp 09-Apr-91
+% \issue{MACRO-ENVIRONMENT-EXTENT:DYNAMIC}
+% The \term{environment} \term{object} has 
+% \term{dynamic extent}; the consequences are undefined if 
+% the \keyref{environment} argument is 
+% referred to outside the \term{dynamic extent} 
+% of the macro expansion function.
+% \endissue{MACRO-ENVIRONMENT-EXTENT:DYNAMIC}
+ 
+\issue{MACRO-FUNCTION-ENVIRONMENT}
+% The following will be deleted:
+%  
+% %% 8.1.0 4
+% \funref{macro-function} 
+% cannot be used to determine whether \param{symbol} names
+% a locally defined macro established by \specref{macrolet};
+% %% or \specref{symbol-macrolet}
+% \funref{macro-function} can
+% examine only global definitions.
+\endissue{MACRO-FUNCTION-ENVIRONMENT}
+ 
+%% 8.1.0 3
+It is possible for both \funref{macro-function} and 
+\issue{SPECIAL-FORM-P-MISNOMER:RENAME}
+\funref{special-operator-p}
+\endissue{SPECIAL-FORM-P-MISNOMER:RENAME}
+to return \term{true} of \param{symbol}.  The \term{macro} definition must
+be available for use by programs that understand only the standard 
+\clisp\ \term{special forms}.
+ 
+\label Examples::
+\code
+ (defmacro macfun (x) '(macro-function 'macfun)) \EV MACFUN 
+ (not (macro-function 'macfun)) \EV \term{false} 
+\endcode
+%;;--- The next four lines are not valid Common Lisp, as equal
+%;;--- is not defined for functions --Moon
+% (and (setf (macro-function 'macfun) #'equal)
+%         (equal (macro-function 'macfun) #'equal)) \EV \term{true}
+% (macrolet ((macfun (x) "local"))
+%    (equal (macro-function 'macfun) #'equal)) \EV \term{true}
+\issue{MACRO-FUNCTION-ENVIRONMENT}
+\code
+ (macrolet ((foo (&environment env)
+               (if (macro-function 'bar env)
+                  ''yes
+                  ''no)))
+    (list (foo)
+          (macrolet ((bar () :beep))
+             (foo))))
+ 
+\EV (NO YES)
+\endcode
+\endissue{MACRO-FUNCTION-ENVIRONMENT}
+ 
+\label Affected By::
+\f{(setf macro-function)}, \macref{defmacro}, and \specref{macrolet}.
+
+\label Exceptional Situations::
+
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+The consequences are undefined if \param{environment} is \term{non-nil}
+in a use of \SETFof{macro-function}.
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+ 
+\label See Also::
+
+\macref{defmacro}, {\secref\Evaluation}
+ 
+\label Notes::
+ 
+%% 8.1.0 5
+\macref{setf} can be used with \funref{macro-function} to install
+a \term{macro} as a symbol's global function definition:
+ 
+\code
+ (setf (macro-function symbol) fn)
+\endcode
+The value installed must be a \term{function} that accepts two arguments,
+the entire macro call and an \term{environment}, 
+and computes the expansion for that call.
+Performing this operation causes \param{symbol} to have only that
+macro definition as its global function definition; any previous
+definition, whether as a \term{macro} or as a 
+\term{function}, is lost.
+ 
+\endcom                          
+
+%%% ========== MACROEXPAND
+%%% ========== MACROEXPAND-1
+\begincom{macroexpand, macroexpand-1}\ftype{Function}
+ 
+\label Syntax::
+
+\DefunWithValues macroexpand   {form {\opt} env} {expansion, expanded-p}
+\DefunWithValues macroexpand-1 {form {\opt} env} {expansion, expanded-p}
+ 
+\label Arguments and Values::
+
+\param{form}---a \term{form}.
+ 
+\param{env}---an \term{environment} \term{object}.
+  \Default{\nil}
+ 
+\param{expansion}---a \term{form}.
+ 
+\issue{MACROEXPAND-RETURN-VALUE:TRUE}
+\param{expanded-p}---a \term{generalized boolean}.
+\endissue{MACROEXPAND-RETURN-VALUE:TRUE}
+ 
+\label Description::
+
+\funref{macroexpand} and \funref{macroexpand-1} expand \term{macros}.
+ 
+%% 8.2.0 2
+%% 8.2.0 3
+If \param{form} is a \term{macro form},
+then \funref{macroexpand-1} expands the \term{macro form} call once.
+ 
+%% 8.2.0 7
+\funref{macroexpand} 
+repeatedly expands \param{form} until it is no longer a \term{macro form}.
+In effect, \funref{macroexpand} calls \funref{macroexpand-1} repeatedly
+until the \term{secondary value} it returns is \nil.
+
+%% 8.2.0 2
+If \param{form} is a \term{macro form},
+then the \param{expansion} is a \term{macro expansion}
+ and \param{expanded-p} is \term{true}.
+Otherwise,
+ the \param{expansion} is the given \param{form}
+ and \param{expanded-p} is \term{false}.
+ 
+%% 8.2.0 4
+Macro expansion is carried out as follows.  
+Once \funref{macroexpand-1} has
+determined that the \param{form} is a \term{macro form},
+it obtains an appropriate expansion \term{function} for the
+\term{macro} or \term{symbol macro}.
+The value of 
+\varref{*macroexpand-hook*} is 
+\issue{FUNCTION-TYPE:X3J13-MARCH-88}
+coerced to a \term{function} and
+\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
+then called as a \term{function} of three arguments:
+      the expansion \term{function},
+      the \param{form},
+  and the \param{env}.
+The \term{value} returned from this call is taken to be the expansion
+of the \param{form}.
+
+%% Augmented this first sentence to mention global environment 
+%% and local symbol-macrolet definitions. -kmp 12-May-93
+In addition to \term{macro} definitions in the global environment,
+any local macro definitions established within \param{env} by \specref{macrolet} 
+or \specref{symbol-macrolet} are considered.
+If only \param{form} is supplied as an argument,
+then the environment is effectively null, and only global macro definitions
+as established by \macref{defmacro} are considered.
+%% Sandra addition
+\term{Macro} definitions are shadowed by local \term{function} definitions.
+%% end Sandra addition
+
+\label Examples::
+
+\code
+ (defmacro alpha (x y) `(beta ,x ,y)) \EV ALPHA
+ (defmacro beta (x y) `(gamma ,x ,y)) \EV BETA
+ (defmacro delta (x y) `(gamma ,x ,y)) \EV EPSILON
+ (defmacro expand (form &environment env)
+   (multiple-value-bind (expansion expanded-p)
+       (macroexpand form env)
+     `(values ',expansion ',expanded-p))) \EV EXPAND
+ (defmacro expand-1 (form &environment env)
+   (multiple-value-bind (expansion expanded-p)
+       (macroexpand-1 form env)
+     `(values ',expansion ',expanded-p))) \EV EXPAND-1
+\medbreak
+;; Simple examples involving just the global environment
+ (macroexpand-1 '(alpha a b)) \EV (BETA A B), \term{true}
+ (expand-1 (alpha a b)) \EV (BETA A B), \term{true}
+ (macroexpand '(alpha a b)) \EV (GAMMA A B), \term{true}
+ (expand (alpha a b)) \EV (GAMMA A B), \term{true}
+ (macroexpand-1 'not-a-macro) \EV NOT-A-MACRO, \term{false}
+ (expand-1 not-a-macro) \EV NOT-A-MACRO, \term{false}
+ (macroexpand '(not-a-macro a b)) \EV (NOT-A-MACRO A B), \term{false}
+ (expand (not-a-macro a b)) \EV (NOT-A-MACRO A B), \term{false}
+\medbreak
+;; Examples involving lexical environments
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (macroexpand-1 '(alpha a b))) \EV (BETA A B), \term{true}
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (expand-1 (alpha a b))) \EV (DELTA A B), \term{true}
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (macroexpand '(alpha a b))) \EV (GAMMA A B), \term{true}
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (expand (alpha a b))) \EV (GAMMA A B), \term{true}
+ (macrolet ((beta (x y) `(epsilon ,x ,y)))
+   (expand (alpha a b))) \EV (EPSILON A B), \term{true}
+ (let ((x (list 1 2 3)))
+   (symbol-macrolet ((a (first x)))
+     (expand a))) \EV (FIRST X), \term{true}
+ (let ((x (list 1 2 3)))
+   (symbol-macrolet ((a (first x)))
+     (macroexpand 'a))) \EV A, \term{false}
+ (symbol-macrolet ((b (alpha x y)))
+   (expand-1 b)) \EV (ALPHA X Y), \term{true}
+ (symbol-macrolet ((b (alpha x y)))
+   (expand b)) \EV (GAMMA X Y), \term{true}
+ (symbol-macrolet ((b (alpha x y))
+                   (a b))
+   (expand-1 a)) \EV B, \term{true}
+ (symbol-macrolet ((b (alpha x y))
+                   (a b))
+   (expand a)) \EV (GAMMA X Y), \term{true}
+\medbreak
+;; Examples of shadowing behavior
+ (flet ((beta (x y) (+ x y)))
+   (expand (alpha a b))) \EV (BETA A B), \term{true}
+ (macrolet ((alpha (x y) `(delta ,x ,y)))
+   (flet ((alpha (x y) (+ x y)))
+     (expand (alpha a b)))) \EV (ALPHA A B), \term{false}
+ (let ((x (list 1 2 3)))
+   (symbol-macrolet ((a (first x)))
+     (let ((a x))
+       (expand a)))) \EV A, \term{false}
+\endcode
+ 
+\label Affected By::
+
+\macref{defmacro},
+\macref{setf} of \macref{macro-function},
+\specref{macrolet},
+\specref{symbol-macrolet}
+
+\label Exceptional Situations:\None.
+ 
+\label See Also::     
+
+\varref{*macroexpand-hook*},
+\macref{defmacro},
+\macref{setf} of \macref{macro-function},
+\specref{macrolet},
+\specref{symbol-macrolet},
+{\secref\Evaluation}
+ 
+\label Notes::
+ 
+Neither \funref{macroexpand} nor \funref{macroexpand-1} 
+makes any explicit attempt to expand \term{macro forms} that are
+either \term{subforms} of the \param{form} 
+    or \term{subforms} of the \param{expansion}.
+Such expansion might occur implicitly, however,
+due to the semantics or implementation of the \term{macro function}.
+
+\endcom
+
+\issue{ISO-COMPATIBILITY:ADD-SUBSTRATE}
+%%% ========== DEFINE-SYMBOL-MACRO
+\begincom{define-symbol-macro}\ftype{Macro}
+
+\label Syntax::
+ 
+\DefmacWithValuesNewline define-symbol-macro {symbol expansion} {symbol}
+ 
+\label Arguments and Values::
+ 
+\param{symbol}---a \term{symbol}.
+ 
+\param{expansion}---a \term{form}.
+ 
+\label Description::
+
+Provides a mechanism for globally affecting the \term{macro expansion}
+of the indicated \param{symbol}.
+
+Globally establishes an expansion function for the \term{symbol macro} 
+named by \param{symbol}.
+%% Patterned after wording from SYMBOL-MACROLET (per issue SYMBOL-MACROLET-SEMANTICS).
+The only guaranteed property of an expansion \term{function} for a \term{symbol macro}
+is that when it is applied to the \term{form} and the \term{environment} it returns
+the correct expansion.  (In particular, it is \term{implementation-dependent} 
+whether the expansion is conceptually stored in the expansion function,
+the \term{environment}, or both.)
+
+Each global reference to \param{symbol} (\ie not \term{shadowed}\meaning{2} by a 
+\term{binding} for a \term{variable} or \term{symbol macro} named by
+the same \term{symbol}) is expanded by the normal macro expansion process;
+\seesection\SymbolsAsForms.
+The expansion of a \term{symbol macro} is subject to further \term{macro expansion}
+in the same \term{lexical environment} as the \term{symbol macro} reference,
+exactly analogous to normal \term{macros}.
+ 
+%% Patterned after wording from SYMBOL-MACROLET (per issue SYMBOL-MACROLET-DECLARE).
+The consequences are unspecified if a \declref{special} declaration is made for
+\param{symbol} while in the scope of this definition (\ie when it is not 
+\term{shadowed}\meaning{2} by a \term{binding} for a \term{variable}
+or \term{symbol macro} named by the same \term{symbol}).
+
+Any use of \specref{setq} to set the value of 
+%% Per X3J13. -kmp 5-Oct-93
+%one of
+the \param{symbol}
+ while in the scope of this definition
+ is treated as if it were a \macref{setf}.
+\macref{psetq} of \param{symbol}
+ is treated as if it were a \macref{psetf}, and
+\macref{multiple-value-setq} 
+ is treated as if it were a \specref{setf} of \funref{values}.
+
+A \term{binding} for a \term{symbol macro} can be \term{shadowed}\meaning{2}
+by \specref{let} or \specref{symbol-macrolet}.
+
+\label Examples::
+ 
+\code
+(defvar *things* (list 'alpha 'beta 'gamma)) \EV *THINGS*
+
+(define-symbol-macro thing1 (first *things*)) \EV THING1
+(define-symbol-macro thing2 (second *things*)) \EV THING2
+(define-symbol-macro thing3 (third *things*)) \EV THING3
+
+thing1 \EV ALPHA
+(setq thing1 'ONE) \EV ONE
+*things* \EV (ONE BETA GAMMA)
+(multiple-value-setq (thing2 thing3) (values 'two 'three)) \EV TWO
+thing3 \EV THREE
+*things* \EV (ONE TWO THREE)
+
+(list thing2 (let ((thing2 2)) thing2)) \EV (TWO 2)
+\endcode
+ 
+\label Affected By:\None.
+ 
+\label Exceptional Situations::
+
+%% See issues LISP-SYMBOL-REDEFINITION and SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS.
+If \param{symbol} is already defined as a \term{global variable},
+an error \oftype{program-error} is signaled.
+
+\label See Also::
+ 
+\specref{symbol-macrolet},
+\funref{macroexpand}
+ 
+\label Notes:\None.
+
+\endcom%{define-symbol-macro}
+\endissue{ISO-COMPATIBILITY:ADD-SUBSTRATE}
+
+%%% ========== SYMBOL-MACROLET
+\begincom{symbol-macrolet}\ftype{Special Operator}
+
+\issue{DECLS-AND-DOC}
+\issue{SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM} 
+
+\label Syntax::
+ 
+\DefspecWithValuesNewline symbol-macrolet
+			  {\paren{\starparen{symbol expansion}}
+			   \starparam{declaration} 
+			   \starparam{form}}
+			  {\starparam{result}}
+ 
+\label Arguments and Values::
+ 
+\param{symbol}---a \term{symbol}.
+ 
+\param{expansion}---a \term{form}.
+
+\issue{SYMBOL-MACROLET-DECLARE:ALLOW}
+\param{declaration}---a \misc{declare} \term{expression}; \noeval.
+\endissue{SYMBOL-MACROLET-DECLARE:ALLOW}
+                           
+\param{forms}---an \term{implicit progn}.
+                   
+\param{results}---the \term{values} returned by the \param{forms}.
+ 
+\label Description::
+ 
+%A number of changes in here due to Moore #1 (first public review).
+
+\specref{symbol-macrolet} provides a mechanism for 
+affecting the \term{macro expansion} environment for \term{symbols}.
+
+\specref{symbol-macrolet} lexically establishes expansion functions
+for each of the \term{symbol macros} named by \param{symbols}.
+\issue{SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM}
+The only guaranteed property of an expansion \term{function} for a \term{symbol macro}
+is that when it is applied to the \term{form} and the \term{environment} it returns
+the correct expansion.  (In particular, it is \term{implementation-dependent} 
+whether the expansion is conceptually stored in the expansion function,
+the \term{environment}, or both.)
+\endissue{SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM}
+
+Each reference to \param{symbol} as a variable within the lexical \term{scope}
+of \specref{symbol-macrolet} is expanded by the normal macro expansion process;
+\seesection\SymbolsAsForms.
+The expansion of a symbol macro is subject to further macro expansion
+in the same lexical environment as the symbol macro invocation, exactly 
+analogous to normal \term{macros}.
+
+\issue{SYMBOL-MACROLET-DECLARE:ALLOW}
+Exactly the same \param{declarations} are allowed as for \specref{let}
+with one exception: \specref{symbol-macrolet} signals an error
+if a \declref{special} declaration names one of the \term{symbols} 
+being defined by \specref{symbol-macrolet}.  
+% Discussion of declarations moved to TYPE dictionary entry. --sjl 5 Mar 92
+\endissue{SYMBOL-MACROLET-DECLARE:ALLOW}
+ 
+When the \param{forms} of the \specref{symbol-macrolet} form are expanded, 
+any use of \specref{setq} to set the value of one of the specified variables 
+ is treated as if it were a \macref{setf}.
+\macref{psetq} of a \term{symbol} defined as a symbol macro 
+ is treated as if it were a \macref{psetf}, and
+\macref{multiple-value-setq} 
+ is treated as if it were a \specref{setf} of \funref{values}.
+
+The use of \specref{symbol-macrolet} can be shadowed by \specref{let}.
+In other words, \specref{symbol-macrolet} only substitutes for occurrences
+of \param{symbol} that would be in the \term{scope} of a lexical binding of
+\param{symbol} surrounding the \param{forms}.
+
+\label Examples::
+ 
+\code
+;;; The following is equivalent to
+;;;   (list 'foo (let ((x 'bar)) x)),
+;;; not
+;;;   (list 'foo (let (('foo 'bar)) 'foo))
+ (symbol-macrolet ((x 'foo))
+   (list x (let ((x 'bar)) x))) 
+\EV (foo bar)
+\NV (foo foo) 
+ 
+ (symbol-macrolet ((x '(foo x)))
+   (list x))
+\EV ((FOO X))
+\endcode
+ 
+\label Affected By:\None.
+ 
+\label Exceptional Situations::
+\issue{SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR}
+\issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+If an attempt is made to bind a \term{symbol} that is defined as a \term{global variable},
+an error \oftype{program-error} is signaled.
+\endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+\endissue{SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR} 
+
+If \param{declaration} contains a \declref{special} declaration 
+that names one of the \term{symbols} being bound by \specref{symbol-macrolet},
+an error \oftype{program-error} is signaled.
+
+\label See Also::
+ 
+\macref{with-slots}, \funref{macroexpand}
+ 
+\label Notes::
+ 
+The special form \specref{symbol-macrolet} is the basic mechanism that is used to
+implement \macref{with-slots}.
+
+If a \specref{symbol-macrolet} \term{form} is a \term{top level form},
+the \param{forms} are also processed as \term{top level forms}.
+\Seesection\FileCompilation.
+
+\endissue{SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM} 
+\endissue{DECLS-AND-DOC}
+
+\endcom
+
+%%% ========== *MACROEXPAND-HOOK*
+\begincom{*macroexpand-hook*}\ftype{Variable}
+
+\issue{FUNCTION-TYPE:X3J13-MARCH-88}
+
+\label Value Type::
+
+a \term{designator} for a \term{function} of three \term{arguments}:
+  a \term{macro function},
+  a \term{macro form},
+  and an \term{environment} \term{object}.
+
+\label Initial Value::
+
+\issue{MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE}
+\issue{MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT}
+a \term{designator} for a function that is equivalent to \thefunction{funcall},
+but that might have additional \term{implementation-dependent} side-effects.
+\endissue{MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT}
+\endissue{MACROEXPAND-HOOK-DEFAULT:EXPLICITLY-VAGUE}
+
+\label Description::
+
+%% 8.2.0 7
+Used as the expansion interface hook by \funref{macroexpand-1} to 
+control the \term{macro expansion} process.
+When a \term{macro form} is to be expanded,
+this \term{function} is called with three arguments:
+  the \term{macro function},
+  the \term{macro form},
+  and the \term{environment} in which the \term{macro form} is to be expanded.
+\issue{MACRO-ENVIRONMENT-EXTENT:DYNAMIC}
+The \term{environment} \term{object} has \term{dynamic extent};
+the consequences are undefined if the \term{environment} \term{object} is 
+referred to outside the \term{dynamic extent} of the macro expansion function.
+\endissue{MACRO-ENVIRONMENT-EXTENT:DYNAMIC}
+ 
+\label Examples::
+
+\code
+ (defun hook (expander form env)
+    (format t "Now expanding: ~S~%" form)
+    (funcall expander form env)) \EV HOOK 
+ (defmacro machook (x y) `(/ (+ ,x ,y) 2)) \EV MACHOOK 
+ (macroexpand '(machook 1 2)) \EV (/ (+ 1 2) 2), \term{true} 
+ (let ((*macroexpand-hook* #'hook)) (macroexpand '(machook 1 2)))
+\OUT Now expanding (MACHOOK 1 2) 
+\EV (/ (+ 1 2) 2), \term{true}
+\endcode
+ 
+\label Affected By:\None.
+
+\label See Also::
+
+\funref{macroexpand}, \funref{macroexpand-1}, \funref{funcall}, {\secref\Evaluation}
+ 
+\label Notes::
+
+The net effect of the chosen initial value is to just invoke the
+\term{macro function}, giving it the \term{macro form} and
+\term{environment} as its two arguments.
+
+Users or user programs can \term{assign} this \term{variable} to
+customize or trace the \term{macro expansion} mechanism.  Note, however,
+that this \term{variable} is a global resource, potentially shared by
+multiple \term{programs}; as such, if any two \term{programs} depend for
+their correctness on the setting of this \term{variable}, those
+\term{programs} may not be able to run in the same \term{Lisp image}.
+For this reason, it is frequently best to confine its uses to debugging
+situations.
+
+\issue{MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT}
+Users who put their own function into \varref{*macroexpand-hook*}
+should consider saving the previous value of the hook, and calling that
+value from their own.
+\endissue{MACROEXPAND-HOOK-INITIAL-VALUE:IMPLEMENTATION-DEPENDENT}
+
+\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
+
+\endcom
+
+%-------------------- Declarations --------------------
+
+%%% ========== PROCLAIM
+\begincom{proclaim}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues proclaim {declaration-specifier} {\term{implementation-dependent}}
+
+\label Arguments and Values::
+
+\param{declaration-specifier}---a \term{declaration specifier}.
+
+\label Description::
+
+%% 9.1.0 11
+\term{Establishes} the \term{declaration} specified by \param{declaration-specifier}
+in the \term{global environment}.
+
+%% 9.1.0 13
+Such a \term{declaration}, sometimes called a \term{global declaration} 
+or a \term{proclamation}, is always in force unless locally \term{shadowed}.
+
+%% 9.1.0 12
+\term{Names} of \term{variables} and \term{functions} within 
+\param{declaration-specifier} refer to \term{dynamic variables} 
+and global \term{function} definitions, respectively.
+
+\Thenextfigure\ shows a list of \param{declaration identifiers} 
+that can be used with \funref{proclaim}.
+
+% IGNORE, IGNORABLE, and DYNAMIC-EXTENT removed as consequence of vote
+% taken at 5-Oct-93 X3J13 meeting.
+\issue{DYNAMIC-EXTENT:NEW-DECLARATION}
+\issue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+\displayfour{Global Declaration Specifiers}{
+declaration&inline&optimize&type\cr
+ftype&notinline&special&\cr
+}
+%function removed.
+\endissue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+\endissue{DYNAMIC-EXTENT:NEW-DECLARATION}
+
+%% 9.2.0 20
+An implementation is free to support other (\term{implementation-defined})
+\term{declaration identifiers} as well.
+
+\label Examples::
+
+\code
+ (defun declare-variable-types-globally (type vars)
+   (proclaim `(type ,type ,@vars))
+   type)
+
+ ;; Once this form is executed, the dynamic variable *TOLERANCE*
+ ;; must always contain a float.
+ (declare-variable-types-globally 'float '(*tolerance*))
+\EV FLOAT
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\specref{declaim},
+\misc{declare},
+{\secref\Compilation}
+
+\label Notes::
+
+Although the \term{execution} of a \funref{proclaim} \term{form} 
+has effects that might affect compilation, the compiler does not make
+any attempt to recognize and specially process \funref{proclaim} \term{forms}.
+A \term{proclamation} such as the following, even if a \term{top level form},
+does not have any effect until it is executed:
+
+\code
+(proclaim '(special *x*))
+\endcode
+
+If compile time side effects are desired, \specref{eval-when} may be useful.
+For example:
+
+\code
+ (eval-when (:execute :compile-toplevel :load-toplevel)
+   (proclaim '(special *x*)))
+\endcode
+
+In most such cases, however, it is preferrable to use \macref{declaim} for
+this purpose.
+
+\issue{DECLARE-MACROS:FLUSH}
+Since \funref{proclaim} \term{forms} are ordinary \term{function forms},
+\term{macro forms} can expand into them.
+%Barrett: So what?
+%Sandra: DUMB!
+%KMP: Tough. I think this is a commonly asked question, and perfectly 
+%     appropriate for a Note even though it's not a revelation.  Technically,
+%     anything in the Notes should be describable as "so what?" or "dumb"
+%     or we should ask why it's in the Notes and not the Description.
+\endissue{DECLARE-MACROS:FLUSH}
+
+\endcom
+
+%%% ========== DECLAIM
+\begincom{declaim}\ftype{Macro}
+
+\issue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+
+\label Syntax:: 
+
+\DefmacWithValues declaim 
+		  {\starparam{declaration-specifier}}
+		  {\term{implementation-dependent}}
+
+\label Arguments and Values::
+
+\param{declaration-specifier}---a \term{declaration specifier}; \noeval.
+
+\label Description::
+
+Establishes the \term{declarations} specified by the \param{declaration-specifiers}.
+
+If a use of this macro appears as a \term{top level form} in a \term{file} 
+being processed by the \term{file compiler}, the proclamations are also made
+at compile-time.  As with other defining macros, it is unspecified whether or
+not the compile-time side-effects of a \macref{declaim} persist after the
+\term{file} has been \term{compiled}.
+
+\label Examples::
+
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\misc{declare},
+\funref{proclaim}
+
+\label Notes:\None.
+
+%!!! How does proclaim relate to declaim.
+%    Not quite as simple as
+%    (declaim <x>) == (eval-when (:compile-toplevel :load-toplevel :execute) (proclaim '<x>))
+%    but close...
+
+% Clarify that calls to PROCLAIM should be treated the same as any
+%   other function call.  Users should wrap an explicit EVAL-WHEN around
+%   top-level calls to PROCLAIM if they want them to affect compilation,
+%   or use the macro DECLAIM.
+
+\endissue{PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO}
+
+\endcom
+
+%%% ========== DECLARE
+\begincom{declare}\ftype{Symbol}
+
+%!!! Barmar: This entry needs A LOT of work.  It is highly redundant and perhaps inconsistent.
+
+\label Syntax::
+
+\Defspec declare {\starparam{declaration-specifier}}
+
+\label Arguments:: 
+
+%% 9.1.0 6
+\param{declaration-specifier}---a \term{declaration specifier}; \noeval.
+
+\label Description::
+
+%% 9.1.0 2
+A \misc{declare} \term{expression}, sometimes called a \term{declaration},
+can occur only at the beginning of the bodies of certain \term{forms};
+that is, it may be preceded only by other \misc{declare} \term{expressions},
+or by a \term{documentation string} if the context permits.
+
+A \misc{declare} \term{expression} can occur in a \term{lambda expression}
+or in any of the \term{forms} listed in \thenextfigure.
+
+\issue{DECLS-AND-DOC}
+\issue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\issue{SYMBOL-MACROLET-DECLARE:ALLOW}
+\issue{WITH-ADDED-METHODS:DELETE}
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\displaythree{Standardized Forms In Which Declarations Can Occur}{
+defgeneric&do-external-symbols&prog\cr
+define-compiler-macro&do-symbols&prog*\cr
+define-method-combination&dolist&restart-case\cr
+define-setf-expander&dotimes&symbol-macrolet\cr
+defmacro&flet&with-accessors\cr
+defmethod&handler-case&with-hash-table-iterator\cr
+defsetf&labels&with-input-from-string\cr
+deftype&let&with-open-file\cr
+defun&let*&with-open-stream\cr
+destructuring-bind&locally&with-output-to-string\cr
+do&macrolet&with-package-iterator\cr
+do*&multiple-value-bind&with-slots\cr
+do-all-symbols&pprint-logical-block&\cr
+}
+%Deleted GENERIC-FLET, GENERIC-LABELS, GENERIC-FUNCTION -kmp 7-Feb-92
+%Deleted WITH-ADDED-METHODS. -kmp 7-Jan-91
+%Added DEFINE-COMPILER-MACRO, DESTRUCTURING-BIND, HANDLER-CASE,
+% PPRINT-LOGICAL-BLOCK, RESTART-CASE, WITH-HASH-TABLE-ITERATOR,
+% and WITH-PACKAGE-ITERATOR. -kmp 15-Feb-92
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\endissue{WITH-ADDED-METHODS:DELETE}
+\endissue{SYMBOL-MACROLET-DECLARE:ALLOW}
+\endissue{SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS}
+\endissue{DECLS-AND-DOC}
+
+A \misc{declare} \term{expression} can only occur 
+where specified by the syntax of these \term{forms}.
+%% 9.1.0 3
+The consequences of attempting to evaluate a \misc{declare} \term{expression} 
+are undefined.  In situations where such \term{expressions} can appear, 
+explicit checks are made for their presence and they are never actually evaluated;
+it is for this reason that they
+are called  ``\misc{declare} \term{expressions}''
+rather than ``\misc{declare} \term{forms}.''
+
+% This doesn't belong here.  I think it is adequately covered by the
+% discussion of lambda lists and scoping of lambda variables.  --sjl 5 mar 92
+% When evaluating a \term{lambda form},
+% none of the \term{bound declarations} made by \misc{declare} \term{expressions} 
+% appearing at the beginning of the body
+% of the \term{lambda expression} apply to the \term{argument} \term{evaluations}.
+% However, such \term{declarations} apply to the \term{initialization form} code (if any) 
+% for \keyref{optional}, \keyref{key}, and \keyref{aux} \term{bindings}
+% % Added to please KMP (and hopefully Moon, too).
+% subsequent to the \term{name} to which the \term{bound declaration} refers;
+% \seesection\DeclScope.
+
+\issue{DECLARE-MACROS:FLUSH}
+%\term{macro} 
+%calls may expand into declarations as long as this syntax is observed.
+\term{Macro forms} cannot expand into declarations;
+\misc{declare} \term{expressions} must appear as actual \term{subexpressions} of
+the \term{form} to which they refer.
+% the only valid declarations are \term{lists} whose \term{car} is the symbol \misc{declare}.
+%% Removed because this is already said in PROCLAIM.
+% \term{Macro forms} can expand into \funref{proclaim} forms, however.
+\endissue{DECLARE-MACROS:FLUSH}
+
+\Thenextfigure\ shows a list of \term{declaration identifiers} 
+that can be used with \misc{declare}.
+
+\issue{DYNAMIC-EXTENT:NEW-DECLARATION}
+\issue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+\displaythree{Local Declaration Specifiers}{
+dynamic-extent&ignore&optimize\cr
+ftype&inline&special\cr
+ignorable&notinline&type\cr
+}
+%function removed.
+\endissue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+\endissue{DYNAMIC-EXTENT:NEW-DECLARATION}
+
+%% 9.2.0 20
+An implementation is free to support other (\term{implementation-defined})
+\term{declaration identifiers} as well.
+
+\label Examples::     
+
+\code
+ (defun nonsense (k x z)
+   (foo z x)                     ;First call to foo
+   (let ((j (foo k x))           ;Second call to foo
+         (x (* k k)))
+     (declare (inline foo) (special x z))
+     (foo x j z)))               ;Third call to foo
+\endcode
+
+In this example,
+the \declref{inline} declaration applies
+only to the third call to \f{foo}, but not to the first or second ones.
+The \declref{special} declaration of \f{x} causes \specref{let} 
+to make a dynamic \term{binding} for \f{x}, and causes the reference to 
+\f{x}
+in the body of \specref{let} to be a dynamic reference.
+The reference to \f{x} in the second call to \f{foo} is a local reference
+to the second parameter of {\tt nonsense}.
+The reference to \f{x} in the first call to \f{foo} is a local
+reference, not a \declref{special} one.  The \declref{special} declaration of \f{z}
+causes the reference to \f{z} in the 
+%Added for Moon:
+third
+call
+to \f{foo} to be a dynamic reference; it does not
+refer to the parameter to \f{nonsense} named \f{z}, because that
+parameter \term{binding} has not been declared to be \declref{special}.
+(The \declref{special} declaration of \f{z} does not appear in the body
+of \macref{defun},  but in an inner \term{form}, and therefore does not
+affect the \term{binding} of the \term{parameter}.)
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+The consequences  of trying to use a \misc{declare} \term{expression} as 
+a \term{form} to be \term{evaluated} are undefined.
+
+\editornote{KMP: Probably we need to say something here about ill-formed 
+declare expressions.}
+
+\label See Also::
+
+\funref{proclaim},
+\secref\TypeSpecifiers,
+\declref{declaration},
+\declref{dynamic-extent},
+\declref{ftype},
+\declref{ignorable},
+\declref{ignore},
+\declref{inline},
+\declref{notinline},
+\declref{optimize},
+\declref{type}
+
+\label Notes:\None.
+
+%In all cases such additional code is within the scope of any \term{pervasive}
+%declarations appearing before the body of the \term{form}.
+%Declarations that affect \term{bindings} 
+%have no effect on such code, except (of course)
+%in those situations where the code is defined to be within the scope
+%of the variables affected by such non-\term{pervasive} declarations.
+
+%%% 9.1.0 3
+%Those \term{forms} that permit declarations to appear                      
+%perform explicit checks for their presence.
+
+\endcom
+
+%%% ========== IGNORE
+%%% ========== IGNORABLE
+
+\begincom{ignore, ignorable}\ftype{Declaration}
+
+\issue{DOTIMES-IGNORE:X3J13-MAR91}
+
+\label Syntax::
+
+\f{\paren{ignore \star{\curly{\param{var} | \paren{\misc{function} \param{fn}}}}}}
+
+\f{\paren{ignorable \star{\curly{\param{var} | \paren{\misc{function} \param{fn}}}}}}
+
+\label Arguments::
+
+\param{var}---a \term{variable} \term{name}.
+
+\param{fn}---a \term{function} \term{name}.
+
+\label Valid Context::
+
+\term{declaration}
+%% Removed per X3J13 -kmp 4-Oct-93 
+%or \term{proclamation}
+
+\label Binding Types Affected::
+
+\term{variable}, \term{function}
+
+\label Description::
+
+\issue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+The \declref{ignore} and \declref{ignorable} declarations
+refer to \term{for-value} \term{references} 
+    to \term{variable} \term{bindings} for the \param{vars}
+and to \term{function} \term{bindings} for the \param{fns}.
+
+An \declref{ignore} \term{declaration} specifies that
+\term{for-value} \term{references} to the indicated \term{bindings}
+will not
+occur within the scope of the \term{declaration}.
+Within the \term{scope} of such a \term{declaration},
+it is desirable
+for a compiler to issue a warning about 
+the presence of
+either a \term{for-value} \term{reference} to any \param{var} or \param{fn},
+    or a \declref{special} \term{declaration} for any \param{var}.
+
+An \declref{ignorable} \term{declaration} specifies that 
+\term{for-value} \term{references} to the indicated \term{bindings}
+might or might not
+occur within the scope of the \term{declaration}.
+Within the \term{scope} of such a \term{declaration},
+it is not desirable
+for a compiler to issue a warning about
+the presence or absence of
+either a \term{for-value} \term{reference} to any \param{var} or \param{fn},
+    or a \declref{special} \term{declaration} for any \param{var}.
+
+When not within the \term{scope} 
+of a \declref{ignore} or \declref{ignorable} \term{declaration},
+it is desirable
+for a compiler to issue a warning about
+any \param{var} for which there is 
+neither a \term{for-value} \term{reference} 
+    nor a \declref{special} \term{declaration},
+or about
+any \param{fn} for which there is 
+     no \term{for-value} \term{reference}.
+
+Any warning about a ``used'' or ``unused'' \term{binding} must be \oftype{style-warning},
+and may not affect program semantics.
+
+\endissue{IGNORE-USE-TERMINOLOGY:VALUE-ONLY}
+
+%!!! Maybe separate out to a concept section?
+%!!! Once these functions are described as using stream vars, 
+%    we can maybe remove this enumeration.
+%    Alternatively, we could make a table and put it in the chapter of "general rules".
+The \term{stream variables} established by 
+     \macref{with-open-file},
+     \macref{with-open-stream},
+     \macref{with-input-from-string},
+ and \macref{with-output-to-string},
+and all \term{iteration variables} are, by definition, always ``used''.
+Using \f{(declare (ignore \param{v}))}, 
+for such a \term{variable} \param{v} has unspecified consequences.
+
+\endissue{DOTIMES-IGNORE:X3J13-MAR91}
+
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+% % added.  I interpolated the bit about ignorable, since this was
+% % not covered in the original proposal.  --sjl 4 Mar 92
+% \issue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+% \declref{ignore} and \declref{ignorable} declarations may apply to
+% \term{symbol macros}.  Such a declaration specifies that the named
+% \term{symbol macro} must not (in the case of \declref{ignore}) or
+% may not (in the case of \declref{ignorable}) be referenced within
+% the scope of the declaration.
+% \endissue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+
+\label See Also::
+
+\misc{declare}
+%% Removed per X3J13.  -kmp 4-Oct-93
+% , \macref{declaim},
+% \funref{proclaim}
+
+\endcom
+
+%%% ========== DYNAMIC-EXTENT
+
+\begincom{dynamic-extent}\ftype{Declaration}
+
+\label Syntax::
+
+\f{(dynamic-extent \interleave{\starparam{var} |
+		               \star{\paren{\misc{function} \param{fn}}}})}
+
+\label Arguments::
+
+\param{var}---a \term{variable} \term{name}.
+
+\param{fn}---a \term{function} \term{name}.
+
+\label Valid Context::
+
+\term{declaration}
+%% Removed per X3J13 -kmp 4-Oct-93 
+%or \term{proclamation}
+
+\label Binding Types Affected::
+
+\term{variable}, \term{function}
+
+\label Description::
+
+\issue{DYNAMIC-EXTENT:NEW-DECLARATION}
+
+%!!! This needs work. -kmp 23-Aug-91
+%   Suppose that form <f> contains a DYNAMIC-EXTENT declaration for
+%   variable <v> (which need not be bound by <f>).  Consider the values
+%   <w1>, ..., <wN> taken on by <v> during the course of some execution of
+%   <f>.  The declaration asserts that if object <x> is an OIP of <wI>
+%   when <wI> ever becomes the value of <v>, then just after execution of
+%   <f> terminates <x> will be either inaccessible or still an OIP of <v>.
+In some containing \term{form}, \param{F}, this declaration
+asserts for each \param{var$\sub{i}$} (which need not be bound by \param{F}),
+and for each \term{value} \param{v$\sub{ij}$} that \param{var$\sub{i}$} takes on,
+and for each \term{object} \param{x$\sub{ijk}$} that 
+%% Removed per Moon
+%\param{v$\sub{ij}$}
+is
+an \term{otherwise inaccessible part} of \param{v$\sub{ij}$} at any time when
+%% "it" => V[ij] per Moon
+%it
+\param{v$\sub{ij}$}
+becomes the value of \param{var$\sub{i}$},
+that just after the execution of \param{F} terminates, 
+\param{x$\sub{ijk}$} is either \term{inaccessible}
+(if \param{F} established a \term{binding} for \param{var$\sub{i}$})
+or still an \term{otherwise inaccessible part} of the current value of 
+\param{var$\sub{i}$} (if \param{F} did not establish a \term{binding} 
+for \param{var$\sub{i}$}).
+\issue{DYNAMIC-EXTENT-FUNCTION:EXTEND}
+% The \param{var} may either be a symbol naming a variable, 
+% or a list of the form {\tt (function \i{name})} which names a function.
+The same relation holds for each \param{fn$\sub{i}$}, 
+except that the \term{bindings} are in the \term{function} \term{namespace}.
+\endissue{DYNAMIC-EXTENT-FUNCTION:EXTEND}
+
+The compiler is permitted to use
+%make whatever optimizations are appropriate given 
+%% For RPG:
+this information in any way that is appropriate to the \term{implementation}
+and that does not conflict with the semantics of \clisp.
+
+\declref{dynamic-extent} declarations can be \term{free declarations}
+or \term{bound declarations}.
+
+% added.  --sjl 4 Mar 92
+\issue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+The \param{vars} and \param{fns} named in a \declref{dynamic-extent} 
+declaration must not refer to \term{symbol macro} or \term{macro} bindings.
+\endissue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+
+
+\label Examples::
+
+
+Since stack allocation of the initial value entails knowing at the
+\term{object}'s creation time that the \term{object} can be 
+\term{stack-allocated},  it is not generally useful to make a 
+\declref{dynamic-extent} \term{declaration} for \term{variables}
+which have no lexically apparent initial value. 
+For example, it is probably useful to write:
+ 
+\code
+ (defun f ()
+   (let ((x (list 1 2 3)))
+     (declare (dynamic-extent x))
+         ...))
+\endcode
+ 
+This would permit those compilers that wish to do so to \term{stack allocate}
+the list held by the local variable {\tt x}.  It is permissible,
+but in practice probably not as useful, to write:
+ 
+\code
+ (defun g (x) (declare (dynamic-extent x)) ...)
+ (defun f () (g (list 1 2 3)))
+\endcode
+ 
+Most compilers would probably not \term{stack allocate} the \term{argument}
+to {\tt g} in {\tt f} because it would be a modularity violation for the compiler
+to assume facts about {\tt g} from within {\tt f}.   Only an implementation that 
+was willing to be responsible for recompiling {\tt f} if the definition of {\tt g} 
+changed incompatibly could legitimately \term{stack allocate} the \term{list} 
+argument to {\tt g} in {\tt f}.
+ 
+Here is another example:
+
+\code
+ (declaim (inline g))
+ (defun g (x) (declare (dynamic-extent x)) ...)
+ (defun f () (g (list 1 2 3)))
+ 
+ (defun f ()
+   (flet ((g (x) (declare (dynamic-extent x)) ...))
+     (g (list 1 2 3))))
+ 
+\endcode
+In the previous example, some compilers might determine that optimization was 
+possible and others might not.
+ 
+A variant of this is the so-called ``stack allocated rest list''
+that can be achieved (in implementations supporting the optimization) by:
+ 
+\code
+ (defun f (&rest x)
+   (declare (dynamic-extent x))
+   ...)
+\endcode
+ 
+Note that although the initial value of {\tt x} is not explicit, the {\tt f}
+function is responsible for assembling the list {\tt x} from the passed arguments,
+so the {\tt f} function can be optimized by the compiler to construct a 
+\term{stack-allocated} list instead of a heap-allocated list in implementations
+that support such.
+ 
+In the following example,
+
+\code
+ (let ((x (list 'a1 'b1 'c1))
+       (y (cons 'a2 (cons 'b2 (cons 'c2 nil)))))
+   (declare (dynamic-extent x y))
+   ...)
+\endcode
+The \term{otherwise inaccessible parts} of {\tt x} are three 
+\term{conses},  and the \term{otherwise inaccessible parts}
+of {\tt y} are three other \term{conses}.  
+None of the symbols {\tt a1},  {\tt b1},  {\tt c1},  {\tt a2},
+{\tt b2},  {\tt c2},  or \nil\ is an
+\term{otherwise inaccessible part} of {\tt x} or {\tt y} because each
+is \term{interned} and hence \term{accessible} by the \term{package}
+(or \term{packages}) in which it is \term{interned}.
+However, if a freshly allocated \term{uninterned} \term{symbol} had
+been used, it would have been an \term{otherwise inaccessible part} of
+the \term{list} which contained it.
+
+\code
+;; In this example, the implementation is permitted to \term{stack allocate}
+;; the list that is bound to X.
+ (let ((x (list 1 2 3)))
+   (declare (dynamic-extent x))
+   (print x)
+   :done)
+\OUT (1 2 3)
+\EV :DONE
+ 
+;; In this example, the list to be bound to L can be \term{stack-allocated}.
+ (defun zap (x y z)
+   (do ((l (list x y z) (cdr l)))
+       ((null l))
+     (declare (dynamic-extent l))
+     (prin1 (car l)))) \EV ZAP
+ (zap 1 2 3)
+\OUT 123
+\EV NIL
+
+;; Some implementations might open-code LIST-ALL-PACKAGES in a way
+;; that permits using \term{stack allocation} of the list to be bound to L.
+ (do ((l (list-all-packages) (cdr l)))
+     ((null l))
+   (declare (dynamic-extent l))
+   (let ((name (package-name (car l))))
+     (when (string-search "COMMON-LISP" name) (print name))))
+\OUT "COMMON-LISP"
+\OUT "COMMON-LISP-USER"
+\EV NIL
+
+;; Some implementations might have the ability to \term{stack allocate} 
+;; rest lists.  A declaration such as the following should be a cue
+;; to such implementations that stack-allocation of the rest list
+;; would be desirable.
+ (defun add (&rest x)
+   (declare (dynamic-extent x))
+   (apply #'+ x)) \EV ADD
+ (add 1 2 3) \EV 6
+
+ (defun zap (n m)
+   ;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
+   ;; It may be slow, but with a good compiler at least it
+   ;; doesn't waste much heap storage.  :-\}
+   (let ((a (make-array n)))
+     (declare (dynamic-extent a))
+     (dotimes (i n) 
+       (declare (dynamic-extent i))
+       (setf (aref a i) (random (+ i 1))))
+     (aref a m))) \EV ZAP
+ (< (zap 5 3) 3) \EV \term{true}
+\endcode
+ 
+The following are in error, since the value of {\tt x} is used outside of its
+\term{extent}:
+ 
+\code
+ (length (list (let ((x (list 1 2 3)))  ; Invalid
+                (declare (dynamic-extent x))
+                x)))
+
+ (progn (let ((x (list 1 2 3)))  ; Invalid
+          (declare (dynamic-extent x))
+          x)
+        nil)
+\endcode
+\endissue{DYNAMIC-EXTENT:NEW-DECLARATION}
+
+\label See Also::
+
+\misc{declare}
+%% Removed per X3J13.  -kmp 4-Oct-93
+% , \macref{declaim},
+% \funref{proclaim}
+
+\label Notes::
+
+The most common optimization is to \term{stack allocate} the 
+initial value of the \term{objects} named by the \param{vars}. 
+
+It is permissible for an implementation to simply ignore this declaration.
+
+\endcom
+
+%%% ========== TYPE
+
+\begincom{type}\ftype{Declaration}
+
+\label Syntax::
+
+\f{(type \param{typespec} \starparam{var})}
+
+\f{(\param{typespec} \starparam{var})}
+
+\label Arguments::
+
+\param{typespec}---a \term{type specifier}.
+
+\param{var}---a \term{variable} \term{name}.
+
+\label Valid Context::
+
+\term{declaration} or \term{proclamation}
+
+\label Binding Types Affected::
+
+\term{variable}
+
+\label Description::
+
+Affects
+only variable \term{bindings} and specifies that the
+\param{vars} take on 
+values only of the specified \param{typespec}.
+In particular, values assigned to the variables by \specref{setq},
+as well as the initial values of the \param{vars} must be of
+the specified \param{typespec}.
+\declref{type} declarations never apply to function \term{bindings} (see \declref{ftype}).
+
+%% This is already said in the stuff on COMMON-LISP package.
+%% !!! Maybe add a cross-reference? -kmp 9-Feb-92
+% \issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+% Except where explicitly allowed, the consequences are undefined if a
+% \term{symbol} in \thepackage{common-lisp} is used as a
+% \param{var} argument.
+% If such a \term{symbol} is not globally
+% defined 
+% %"by this standard" added per barmar: -kmp 28-Dec-90
+% by this standard
+% as a variable or a constant, it is allowed to lexically bind it
+% and to declare the {\tt type} of that \term{binding}.  For example,
+% the lexical variable names {\tt list} and {\tt car} are permitted.
+% \editornote{KMP: This is unintelligible to me and needs to be rewritten to clarify 
+%     that binding CL special variables is ok, but that their type decls are lexical.}
+% \endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+
+\issue{SYMBOL-MACROLET-DECLARE:ALLOW}
+A type declaration of a \term{symbol} 
+defined by \specref{symbol-macrolet} is equivalent
+to wrapping a \specref{the} 
+expression around the expansion of that \term{symbol},
+\endissue{SYMBOL-MACROLET-DECLARE:ALLOW}
+% moved here from symbol-macrolet dictionary entry  --sjl 5 mar 92
+\issue{SYMBOL-MACROLET-TYPE-DECLARATION:NO}
+although the \term{symbol}'s \term{macro expansion} is not actually affected.
+\endissue{SYMBOL-MACROLET-TYPE-DECLARATION:NO}
+
+\issue{DECLARE-TYPE-FREE:LEXICAL}
+
+The meaning of a type declaration
+  is equivalent to changing each reference to 
+a variable (\param{var}) within the scope of the
+  declaration to {\tt (the \param{typespec} \param{var})},
+changing each expression assigned to the
+  variable (\param{new-value}) within the scope of the declaration to 
+{\tt (the \param{typespec} \param{new-value})},
+  and executing 
+{\tt (the \param{typespec} \param{var})} at the moment the scope of the declaration
+  is entered.
+ 
+A \term{type} declaration is valid in all declarations. The interpretation
+  of a type declaration is as follows:
+\beginlist
+\itemitem{1.} During the execution of any reference to the
+  declared variable within the scope of the declaration, the consequences
+are 
+%"unspecified" -> "undefined" per barmar. i concur. -kmp
+%unspecified
+undefined
+if
+  the value of the declared variable is not of the declared \term{type}.
+
+\itemitem{2.} During the execution of any 
+\specref{setq} of the declared variable within the scope
+  of the declaration, the consequences are 
+%"unspecified" -> "undefined" per barmar. i concur. -kmp
+%unspecified
+undefined
+if the newly assigned value of the
+  declared variable is not of the declared \term{type}. 
+
+\itemitem{3.} At the moment the
+  scope of the declaration is entered, the consequences are 
+%"unspecified" -> "undefined" per barmar. i concur. -kmp
+%unspecified
+undefined
+if the value of the
+  declared variable is not of the declared \term{type}.
+\endlist
+
+A \term{type} declaration affects only variable references within
+its scope.
+% and the meaning of free and "variable-binding-associated" type
+%  declarations can be described identically.
+
+If nested \term{type} declarations refer to the same variable,
+  then the value of the variable must be a member of the intersection of
+  the declared \term{types}.
+\endissue{DECLARE-TYPE-FREE:LEXICAL}
+
+\issue{SPECIAL-TYPE-SHADOWING:CLARIFY}
+  If there is a local {\tt type} declaration for a dynamic
+  variable, and there is also a global {\tt type} proclamation for that same
+  variable, then the value of the variable within the scope of the local
+  declaration must be a member of the intersection of the two declared
+  \term{types}.
+\endissue{SPECIAL-TYPE-SHADOWING:CLARIFY}
+ 
+\declref{type} declarations can  be \term{free declarations}
+or \term{bound declarations}.
+
+\issue{TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL}
+%!!! This paragraph might be better off elsewhere, but can live here for now.
+A \term{symbol} cannot be both the name of a \term{type} and the name of a
+declaration.  Defining a \term{symbol} as the \term{name} of a \term{class},
+\term{structure}, \term{condition}, or \term{type}, when the \term{symbol}
+has been \term{declared} as a declaration name, or vice versa, signals an error.
+\endissue{TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL}
+
+%% The following was inserted after GLS checked this out.
+
+\issue{DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE} 
+Within the \term{lexical scope} of an \typeref{array} type declaration, 
+all references to \term{array} \term{elements} are assumed to satisfy the
+\term{expressed array element type} (as opposed to the \term{upgraded array element type}).
+%The consequences are undefined if this is ever violated. 
+A compiler can treat
+the code within the scope of the \typeref{array} type declaration as if each
+\term{access} of an \term{array} \term{element} were surrounded by an appropriate 
+\specref{the} form.
+\endissue{DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE} 
+
+\label Examples::
+
+\code
+ (defun f (x y)
+   (declare (type fixnum x y))
+   (let ((z (+ x y)))
+     (declare (type fixnum z))
+     z)) \EV F
+ (f 1 2) \EV 3
+ ;; The previous definition of F is equivalent to
+ (defun f (x y)
+   ;; This declaration is a shorthand form of the TYPE declaration
+   (declare (fixnum x y))
+   ;; To declare the type of a return value, it's not necessary to
+   ;; create a named variable.  A THE special form can be used instead.
+   (the fixnum (+ x y))) \EV F
+ (f 1 2) \EV 3
+\endcode
+
+\issue{DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE} 
+
+% There were some comments on this code (from the Cleanup issue, probably)
+% that no one liked, so I removed them.  This example might do better with
+% some explanation, but better no explanation than a broken one. -kmp 14-Feb-92
+
+\code
+ (defvar *one-array* (make-array 10 :element-type '(signed-byte 5)))
+ (defvar *another-array* (make-array 10 :element-type '(signed-byte 8)))
+  
+ (defun frob (an-array)
+   (declare (type (array (signed-byte 5) 1) an-array))
+   (setf (aref an-array 1) 31)
+   (setf (aref an-array 2) 127)
+   (setf (aref an-array 3) (* 2 (aref an-array 3)))
+   (let ((foo 0))
+     (declare (type (signed-byte 5) foo))
+     (setf foo (aref an-array 0))))
+  
+ (frob *one-array*)
+ (frob *another-array*)
+\endcode
+
+\medbreak
+
+The above definition of \f{frob} is equivalent to:
+
+\code
+ (defun frob (an-array)
+   (setf (the (signed-byte 5) (aref an-array 1)) 31)
+   (setf (the (signed-byte 5) (aref an-array 2)) 127)
+   (setf (the (signed-byte 5) (aref an-array 3))
+         (* 2 (the (signed-byte 5) (aref an-array 3))))
+   (let ((foo 0))
+     (declare (type (signed-byte 5) foo))
+     (setf foo (the (signed-byte 5) (aref an-array 0)))))
+\endcode
+
+%!!! Barmar: What does upgrading matter?
+Given an implementation in which 
+\term{fixnums} are 29 bits but \typeref{fixnum} \term{arrays} 
+are upgraded to signed 32-bit \term{arrays},
+the following 
+%% "should->could" per barmar. i concur. -kmp 27-Dec-90
+%should
+could be compiled with all \term{fixnum} arithmetic:
+ 
+\code
+ (defun bump-counters (counters)
+   (declare (type (array fixnum *) bump-counters))
+   (dotimes (i (length counters))
+     (incf (aref counters i))))
+\endcode
+\endissue{DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE} 
+
+\label See Also::
+
+\misc{declare},
+\macref{declaim},
+\funref{proclaim}
+
+\label Notes::
+
+\f{(\param{typespec} \starparam{var})} 
+is an abbreviation for \f{(type \param{typespec} \starparam{var})}.
+\issue{TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL}
+%provided that \param{typespec} is one of the standard \term{type specifier} 
+%\term{symbols} in \figref\StandardizedAtomicTypeSpecs.
+\endissue{TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL}
+
+A \declref{type} declaration for the arguments to a function does not
+necessarily imply anything about the type of the result.  The following
+function is not permitted to be compiled using \term{implementation-dependent}
+\term{fixnum}-only arithmetic:
+
+\code
+ (defun f (x y) (declare (fixnum x y)) (+ x y))
+\endcode
+
+To see why, consider \f{(f most-positive-fixnum 1)}.
+Common Lisp defines that \f{F} must return a \term{bignum} here, rather
+than signal an error or produce a mathematically incorrect result.
+If you have special knowledge such ``\term{fixnum} overflow'' cases will
+not come up, you can declare the result value to be in the \term{fixnum}
+range, enabling some compilers to use more efficient arithmetic:
+
+\code
+ (defun f (x y)
+   (declare (fixnum x y))
+   (the fixnum (+ x y)))
+\endcode
+
+Note, however, that in the three-argument case, because of the possibility
+of an implicit intermediate value growing too large, the following will not
+cause \term{implementation-dependent} \term{fixnum}-only arithmetic to be used:
+
+\code
+ (defun f (x y)
+   (declare (fixnum x y z))
+   (the fixnum (+ x y z)))
+\endcode
+
+To see why, consider \f{(f most-positive-fixnum 1 -1).}
+Although the arguments and the result are all \term{fixnums}, an intermediate
+value is not a \term{fixnum}.  If it is important that 
+\term{implementation-dependent} \term{fixnum}-only arithmetic be selected
+in \term{implementations} that provide it, 
+consider writing something like this instead:
+
+\code
+ (defun f (x y)
+   (declare (fixnum x y z))
+   (the fixnum (+ (the fixnum (+ x y)) z)))
+\endcode
+
+\endcom
+
+%%% ========== INLINE
+%%% ========== NOTINLINE
+
+\begincom{inline, notinline}\ftype{Declaration}
+
+\label Syntax::
+
+{\tt (inline \starparam{function-name})}
+
+{\tt (notinline \starparam{function-name})}
+
+\label Arguments::
+
+\param{function-name}---a \term{function name}.
+
+\label Valid Context::
+
+\term{declaration} or \term{proclamation}
+
+\label Binding Types Affected::
+
+\term{function}
+
+\label Description::
+
+\issue{FUNCTION-NAME:LARGE}
+\declref{inline} specifies that
+it is desirable for the compiler to produce inline calls
+to the \term{functions} named by \param{function-names}; 
+that is, the code for a specified \param{function-name}
+\endissue{FUNCTION-NAME:LARGE}
+should be integrated into the calling routine, appearing ``in line''
+in place of a procedure call.  
+%This declaration is \term{pervasive}.
+A compiler is free to ignore this declaration.
+\declref{inline} declarations never apply to variable \term{bindings}. 
+
+%% 9.2.0 14
+If one of the \term{functions} mentioned has a lexically apparent local definition
+(as made by \specref{flet} or \specref{labels}), then the declaration
+applies to that local definition and not to the global function definition.
+
+\issue{ALLOW-LOCAL-INLINE:INLINE-NOTINLINE}
+While no \term{conforming implementation} is required to perform inline expansion
+of user-defined functions, those \term{implementations} that do attempt
+to recognize the following paradigm:
+
+To define a \term{function} \f{f} that is not \declref{inline} by default
+but for which \f{(declare (inline f))} will make \param{f} be locally inlined,
+the proper definition sequence is:
+    
+\code
+ (declaim (inline f))
+ (defun f ...)
+ (declaim (notinline f))
+\endcode
+
+The \declref{inline} proclamation preceding the \macref{defun} \term{form}
+ensures that the \term{compiler} has the opportunity save the information
+necessary for inline expansion, and the \declref{notinline} proclamation 
+following the \macref{defun} \term{form} prevents \f{f} from being expanded
+inline everywhere.  
+\endissue{ALLOW-LOCAL-INLINE:INLINE-NOTINLINE}
+
+\issue{FUNCTION-NAME:LARGE}
+\declref{notinline} specifies that it is
+\endissue{FUNCTION-NAME:LARGE}
+undesirable to compile the \term{functions}
+named by \param{function-names} in-line.
+%This declaration is \term{pervasive}.
+A compiler is not free to ignore this declaration;
+%clarifying clause added per barmar. -kmp 28-Dec-90
+calls to the specified functions must be implemented as out-of-line subroutine calls.
+
+%% 9.2.0 16
+If one of the \term{functions}
+mentioned has a lexically apparent local definition
+(as made by \specref{flet} or \specref{labels}), then the declaration
+applies to that local definition and not to the global function definition.
+
+% added.  --sjl 4 Mar 92
+\issue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+In the presence of a \term{compiler macro} definition for 
+\param{function-name}, a \declref{notinline} declaration prevents that
+\issue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+\term{compiler macro} from being used.
+% in preference to the normal definition 
+% of \param{function-name} as a \term{function} or \term{macro}.
+\endissue{KMP-COMMENTS-ON-SANDRA-COMMENTS:X3J13-MAR-92}
+An \declref{inline} declaration may be used to encourage use of 
+\term{compiler macro} definitions.  \declref{inline} and \declref{notinline}
+declarations otherwise have no effect when the lexically visible definition
+of \param{function-name} is a \term{macro} definition.
+\endissue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+
+
+\declref{inline} and \declref{notinline} declarations can be \term{free declarations} or
+\term{bound declarations}.                  
+\declref{inline} and \declref{notinline} declarations of functions that
+appear before the body of a 
+      \specref{flet}
+ or  \specref{labels}
+\issue{WITH-ADDED-METHODS:DELETE}
+% \specref{with-added-methods},
+\endissue{WITH-ADDED-METHODS:DELETE}
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+%   \specref{generic-flet}, 
+% and
+%   \specref{generic-labels} 
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\term{form} that defines that function are \term{bound declarations}.  
+Such declarations in other contexts are \term{free declarations}.
+
+\label Examples::
+
+\code
+ ;; The globally defined function DISPATCH should be open-coded,
+ ;; if the implementation supports inlining, unless a NOTINLINE 
+ ;; declaration overrides this effect.
+ (declaim (inline dispatch))
+ (defun dispatch (x) (funcall (get (car x) 'dispatch) x))
+ ;; Here is an example where inlining would be encouraged.
+ (defun top-level-1 () (dispatch (read-command)))
+ ;; Here is an example where inlining would be prohibited.
+ (defun top-level-2 ()
+   (declare (notinline dispatch))
+   (dispatch (read-command)))
+ ;; Here is an example where inlining would be prohibited.
+ (declaim (notinline dispatch))
+ (defun top-level-3 () (dispatch (read-command)))
+ ;; Here is an example where inlining would be encouraged.
+ (defun top-level-4 () 
+   (declare (inline dispatch))
+   (dispatch (read-command)))
+\endcode
+
+\label See Also::
+
+\misc{declare},
+\macref{declaim},
+\funref{proclaim}
+
+\endcom
+
+%%% ========== FTYPE
+
+\begincom{ftype}\ftype{Declaration}
+
+\label Syntax::
+
+\issue{FUNCTION-NAME:LARGE}
+\f{(ftype \param{type} \starparam{function-name})}
+\endissue{FUNCTION-NAME:LARGE}
+
+\label Arguments::
+
+\param{function-name}---a \term{function name}.
+
+% added --sjl 7 Mar 92
+\param{type}---a \term{type specifier}.
+
+\label Valid Context::
+
+\term{declaration} or \term{proclamation}
+
+\label Binding Types Affected::
+
+\term{function}
+
+\label Description::
+
+Specifies that the \term{functions} named by \param{function-names} are of
+the functional type \param{type}.
+For example:
+
+\code
+ (declare (ftype (function (integer list) t) ith)
+          (ftype (function (number) float) sine cosine))
+\endcode
+If one of the \term{functions} mentioned has a lexically apparent local definition
+(as made by \specref{flet} or \specref{labels}), then the declaration
+applies to that local definition and not to the global function definition.
+\declref{ftype} declarations never apply to variable \term{bindings} (see {\tt type}). 
+
+% added.  --sjl 4 Mar 92
+\issue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+The lexically apparent bindings of \param{function-names} must not be
+\term{macro} definitions.  (This is because \declref{ftype} declares the
+functional definition of each \term{function name} to be of a particular
+subtype of \typeref{function}, and \term{macros} do not denote 
+\term{functions}.)
+\endissue{MACRO-DECLARATIONS:MAKE-EXPLICIT}
+
+% This is adequately covered in the packages chapter.  --sjl 5 Mar 92
+% \issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+% Except where explicitly allowed, the consequences are undefined if
+% a \term{symbol} in \thepackage{common-lisp}
+% is used as a \param{function-name} argument.
+% If such a \term{symbol} is not defined
+% %"by this standard" added per barmar: -kmp 28-Dec-90
+% by this standard
+% as a \term{function},  \term{macro},  or \term{special form},
+% it is allowed to declare the
+% \declref{ftype} of that \term{binding}.  
+% \endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+
+\declref{ftype} 
+\issue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+%and \declref{function} 
+\endissue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+declarations
+can be \term{free declarations} or \term{bound declarations}.
+\declref{ftype} declarations of functions that appear before the body of a 
+   \specref{flet}
+or \specref{labels}
+\issue{WITH-ADDED-METHODS:DELETE}
+% \specref{with-added-methods},
+\endissue{WITH-ADDED-METHODS:DELETE}
+\issue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+%   \specref{generic-flet}, 
+% and
+%   \specref{generic-labels} 
+\endissue{GENERIC-FLET-POORLY-DESIGNED:DELETE}
+\term{form} that defines that function are \term{bound declarations}.  
+Such declarations in other contexts are \term{free declarations}.
+
+\issue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+% 
+% {\tt (function \param{var1} \param{var2}...)}
+% is equivalent to
+% {\tt  (type function \param{var1} \param{var2}...)}
+% 
+%
+%%% 9.2.0 12
+%If one of the \term{functions}
+%mentioned has a lexically apparent local definition
+%(as made by \specref{flet} or \specref{labels}), then the declaration
+%applies to that local definition and not to the global function definition.
+% 
+% 
+% See \declref{type} and \declref{ftype}.
+% 
+\endissue{DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION}
+
+\label See Also::
+
+\misc{declare},
+\macref{declaim},
+\funref{proclaim}
+
+\endcom
+
+%%% ========== DECLARATION
+\begincom{declaration}\ftype{Declaration}
+
+\label Syntax::
+
+\f{(declaration \starparam{name})}
+
+\label Arguments::
+
+\param{name}---a \term{symbol}.
+
+\label Binding Types Affected:\None.
+
+\label Valid Context::
+
+\term{proclamation} only
+
+\label Description::
+
+%% 9.2.0 19
+Advises the compiler that each \param{name} is a valid but potentially
+non-standard declaration name.  The purpose of this is to tell one
+compiler not to issue warnings for declarations meant for another 
+compiler or other program processor.
+% Already said in the packages chapter.  --sjl 5 Mar 92
+% \issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+% The consequences are undefined if a \term{symbol} in \thepackage{common-lisp}
+% is used as a \i{name} argument.
+% \endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+
+%!!! Couldn't figure this out.  It's obviously better to omit it than include it but...
+% \reviewer{Barmar: What does this mean??}%!!!
+% \f{(\i{declaration} x)} never applies to a \term{binding} of {\tt y}.
+
+\label Examples::
+
+\code
+ (declaim (declaration author target-language target-machine))
+ (declaim (target-language ada))
+ (declaim (target-machine IBM-650))
+ (defun strangep (x)
+   (declare (author "Harry Tweeker"))
+   (member x '(strange weird odd peculiar)))
+\endcode
+
+\label See Also::
+
+\macref{declaim},
+\funref{proclaim}
+
+\endcom
+
+%%% ========== OPTIMIZE
+%%% ========== COMPILATION-SPEED
+%%% ========== DEBUG
+%%% ========== SAFETY
+%%% ========== SPACE
+%%% ========== SPEED
+
+\begincom{optimize}\ftype{Declaration}
+
+\label Syntax::
+
+\f{(optimize \star{\curly{\param{quality} | (\param{quality} \param{value})}})}
+\idxref{compilation-speed}%
+\idxref{debug}%
+\idxref{safety}%
+\idxref{space}%
+\idxref{speed}
+
+\label Arguments::
+
+\param{quality}---an \term{optimize quality}.
+
+\param{value}---one of the \term{integers} \f{0}, \f{1}, \f{2}, or \f{3}.
+
+\label Valid Context::
+
+\term{declaration} or \term{proclamation}
+
+\label Binding Types Affected:\None.
+
+\label Description::
+
+Advises the compiler that each \param{quality} should be given attention
+according to the specified corresponding \param{value}.
+Each \param{quality} must be a \term{symbol} naming an \term{optimize quality}; 
+the names and meanings of the standard \param{optimize qualities} are shown in 
+\thenextfigure.
+
+\issue{OPTIMIZE-DEBUG-INFO:NEW-QUALITY}
+\tablefigtwo{Optimize qualities}{Name}{Meaning}{
+\declref{compilation-speed} & speed of the compilation process  \cr
+\declref{debug}             & ease of debugging                 \cr
+\declref{safety}	    & run-time error checking           \cr
+\declref{space}             & both code size and run-time space \cr
+\declref{speed}             & speed of the object code		\cr
+}
+\endissue{OPTIMIZE-DEBUG-INFO:NEW-QUALITY}
+
+There may be other, \term{implementation-defined} \term{optimize qualities}.
+
+A \param{value} \f{0} means that the corresponding \param{quality} is totally
+unimportant, and \f{3} that the \param{quality} is extremely important;
+\f{1} and \f{2} are intermediate values, with \f{1} the 
+%% "average" -> "neutral" since KAB balked and I think this will be less weird. -kmp 3-Oct-91
+%average
+neutral value.
+\f{(\param{quality} 3)} can be abbreviated to \param{quality}.
+%This declaration is \term{pervasive}.
+
+Note that \term{code} which has the optimization \f{(safety 3)},
+or just \typeref{safety},
+is called \term{safe} \term{code}.
+
+% Added per Sandra in response to Barrett query ...
+The consequences are unspecified if a \param{quality} appears more than once
+with \term{different} \param{values}.
+
+\label Examples::
+
+\code
+ (defun often-used-subroutine (x y)
+   (declare (optimize (safety 2)))
+   (error-check x y)
+   (hairy-setup x)
+   (do ((i 0 (+ i 1))
+        (z x (cdr z)))
+       ((null z))
+     ;; This inner loop really needs to burn.
+     (declare (optimize speed))
+     (declare (fixnum i))
+     ))
+\endcode
+
+\label See Also::
+
+\misc{declare},
+\macref{declaim},
+\funref{proclaim},
+{\secref\DeclScope}
+
+\label Notes::
+
+An \declref{optimize} declaration never applies to either a \term{variable} or
+a \term{function} \term{binding}.  An \declref{optimize} declaration can only
+be a \term{free declaration}.  For more information, \seesection\DeclScope.
+
+\endcom
+
+% I moved the dictionary entry for the special declaration here.
+% It used to be in chapter 5, but it seemed more logical to put it with
+% all the other declaration specifiers.   -- sjl 5 Mar 92
+
+%%% ========== SPECIAL
+
+\begincom{special}\ftype{Declaration}
+
+\label Syntax::
+
+\f{(special \starparam{var})}
+
+\label Arguments::
+
+\param{var}---a \term{symbol}.
+
+\label Valid Context::
+
+\term{declaration} or \term{proclamation}
+
+\label Binding Types Affected::
+
+\term{variable}
+
+\label Description::
+ 
+Specifies that all of
+the \param{vars} named are dynamic.
+This specifier affects variable \term{bindings} and 
+affects references.
+All variable \term{bindings} affected are made to be dynamic \term{bindings},
+and affected variable references refer to the current dynamic 
+\term{binding}.
+%rather than the current lexical \term{binding}.
+For example:
+
+\code
+ (defun hack (thing *mod*)    ;The binding of the parameter
+   (declare (special *mod*))  ; *mod* is visible to hack1,
+   (hack1 (car thing)))       ; but not that of thing.
+ (defun hack1 (arg)
+   (declare (special *mod*))  ;Declare references to *mod*
+                              ;within hack1 to be special.
+   (if (atom arg) *mod*
+       (cons (hack1 (car arg)) (hack1 (cdr arg)))))
+\endcode
+
+%% 9.2.0 4
+A \declref{special} declaration does not affect inner \term{bindings} 
+of a \param{var}; the inner \term{bindings} implicitly shadow
+a \declref{special} declaration and must be explicitly re-declared to
+be \declref{special}.
+\declref{special} declarations never apply to function \term{bindings}.
+
+% adequately covered in the packages chapter.  --sjl 5 Mar 92
+% \issue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+% Except where explicitly allowed, the consequences are undefined if
+% a \term{symbol} in \thepackage{common-lisp}
+% is used as a \param{var} argument.
+% \endissue{LISP-SYMBOL-REDEFINITION:MAR89-X3J13}
+
+\declref{special} declarations can be either \term{bound declarations},
+affecting both a binding and references, or \term{free declarations},
+affecting only references, depending on whether the declaration is 
+attached to a variable binding.
+
+%% 9.1.0 14
+When used in a \term{proclamation}, a \declref{special} 
+\term{declaration specifier}
+applies to all \term{bindings} as well as to all references of the
+mentioned variables.  For example, after
+
+\code
+ (declaim (special x))
+\endcode
+
+then in a function definition such as
+
+\code
+ (defun example (x) ...)
+\endcode
+
+the parameter \f{x} is bound as a dynamic variable
+rather than as a lexical variable.  
+
+\label Examples::
+
+\code
+(defun declare-eg (y)                 ;this y is special
+ (declare (special y))
+ (let ((y t))                         ;this y is lexical
+      (list y
+            (locally (declare (special y)) y)))) ;this y refers to the
+                                                 ;special binding of y
+\EV DECLARE-EG 
+ (declare-eg nil) \EV (T NIL) 
+\endcode
+
+
+\code
+(setf (symbol-value 'x) 6)
+(defun foo (x)                         ;a lexical binding of x
+  (print x)
+  (let ((x (1+ x)))                    ;a special binding of x
+    (declare (special x))              ;and a lexical reference
+    (bar))
+  (1+ x))
+(defun bar () 
+  (print (locally (declare (special x))
+           x)))
+(foo 10) 
+\OUT 10
+\OUT 11
+\EV 11
+\endcode
+
+\code
+(setf (symbol-value 'x) 6)
+(defun bar (x y)            ;[1] 1st occurrence of x
+  (let ((old-x x)           ;[2] 2nd occurrence of x -- same as 1st occurrence
+        (x y))              ;[3] 3rd occurrence of x
+    (declare (special x))
+    (list old-x x)))
+(bar 'first 'second) \EV (FIRST SECOND)
+\endcode
+
+\code
+ (defun few (x &optional (y *foo*))
+   (declare (special *foo*))
+   ...)
+\endcode
+The reference to \f{*foo*}
+in the first line of this example is not \declref{special}
+even though there is a \declref{special} declaration in the second line.
+
+\code
+ (declaim (special prosp)) \EV \term{implementation-dependent}
+ (setq prosp 1 reg 1) \EV 1
+ (let ((prosp 2) (reg 2))         ;the binding of prosp is special
+    (set 'prosp 3) (set 'reg 3)   ;due to the preceding proclamation,
+    (list prosp reg))             ;whereas the variable reg is lexical
+\EV (3 2)
+ (list prosp reg) \EV (1 3)
+
+ (declaim (special x))          ;x is always special.
+ (defun example (x y)                                 
+   (declare (special y))
+   (let ((y 3) (x (* x 2)))
+     (print (+ y (locally (declare (special y)) y)))
+     (let ((y 4)) (declare (special y)) (foo x)))) \EV EXAMPLE
+\endcode
+In the contorted code above, the outermost and innermost \term{bindings} of
+\f{y} are dynamic,
+but the middle
+binding is lexical. The two arguments to \f{+} are different,
+one being the value, which is \f{3}, of the lexical variable
+\f{y}, and the other being the value of the dynamic variable named \f{y}
+(a \term{binding} 
+of which happens, coincidentally, to lexically surround it at
+an outer level).  All the \term{bindings} 
+of \f{x} and references to \f{x}
+are dynamic, however, because of the proclamation that \f{x} is
+always \declref{special}.
+
+\label See Also::
+
+\macref{defparameter},
+\macref{defvar}
+
+\endcom
+
+%%% ========== LOCALLY
+\begincom{locally}\ftype{Special Operator}
+
+\issue{DECLS-AND-DOC}
+
+\label Syntax::
+
+\issue{LOCALLY-TOP-LEVEL:SPECIAL-FORM}
+\DefspecWithValues locally 
+		   {\starparam{declaration} \starparam{form}}
+		   {\starparam{result}}
+\endissue{LOCALLY-TOP-LEVEL:SPECIAL-FORM}
+
+\label Arguments and Values::
+
+\param{Declaration}---a \misc{declare} \term{expression}; \noeval.
+
+\param{forms}---an \term{implicit progn}.
+
+\issue{RETURN-VALUES-UNSPECIFIED:SPECIFY}
+\param{results}---the \term{values} of the \param{forms}.
+\endissue{RETURN-VALUES-UNSPECIFIED:SPECIFY}
+
+\label Description::
+
+%% 9.1.0 10
+Sequentially evaluates a body of \param{forms}
+in a \term{lexical environment} where the given \param{declarations} have effect.
+
+\label Examples::
+
+\code
+ (defun sample-function (y)  ;this y is regarded as special
+   (declare (special y))                                
+   (let ((y t))              ;this y is regarded as lexical
+     (list y
+           (locally (declare (special y))
+             ;; this next y is regarded as special
+             y))))
+\EV SAMPLE-FUNCTION
+ (sample-function nil) \EV (T NIL) 
+ (setq x '(1 2 3) y '(4 . 5)) \EV (4 . 5)
+
+;;; The following declarations are not notably useful in specific.
+;;; They just offer a sample of valid declaration syntax using LOCALLY.
+ (locally (declare (inline floor) (notinline car cdr))
+          (declare (optimize space))
+    (floor (car x) (cdr y))) \EV 0, 1
+\endcode
+
+\issue{LOCALLY-TOP-LEVEL:SPECIAL-FORM}
+%Barmar: Say what the example does.
+%KMP: I added some comments. OK?
+\code
+;;; This example shows a definition of a function that has a particular set
+;;; of OPTIMIZE settings made locally to that definition.
+ (locally (declare (optimize (safety 3) (space 3) (speed 0)))
+   (defun frob (w x y &optional (z (foo x y)))
+     (mumble x y z w)))
+\EV FROB
+
+;;; This is like the previous example, except that the optimize settings
+;;; remain in effect for subsequent definitions in the same compilation unit.
+ (declaim (optimize (safety 3) (space 3) (speed 0)))
+ (defun frob (w x y &optional (z (foo x y)))
+   (mumble x y z w))
+\EV FROB
+\endcode
+\endissue{LOCALLY-TOP-LEVEL:SPECIAL-FORM}
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations:\None.
+
+\label See Also::
+
+\misc{declare}
+
+\label Notes::
+
+The \declref{special} declaration may be used with \specref{locally}
+to affect references to, rather than \term{bindings} of, \term{variables}.
+%Barrett: So what?
+
+\issue{LOCALLY-TOP-LEVEL:SPECIAL-FORM}
+If a \specref{locally} \term{form} is a \term{top level form}, the body \param{forms}
+are also processed as \term{top level forms}.  \Seesection\FileCompilation.
+\endissue{LOCALLY-TOP-LEVEL:SPECIAL-FORM}
+
+\endissue{DECLS-AND-DOC}
+
+\endcom
+
+%%% ========== THE
+\begincom{the}\ftype{Special Operator}
+
+\label Syntax::
+
+\DefspecWithValues the {value-type form} {\starparam{result}}
+
+\label Arguments and Values::
+
+\param{value-type}---a \term{type specifier}; \noeval.
+
+\param{form}---a \term{form}; \eval.
+
+\issue{THE-VALUES:RETURN-NUMBER-RECEIVED}
+%% 7.9.2 19                      
+\param{results}---the \term{values} resulting from the \term{evaluation} of \param{form}.
+  These \term{values} must conform to the \term{type} supplied by \param{value-type};
+  see below.
+\endissue{THE-VALUES:RETURN-NUMBER-RECEIVED}
+
+\label Description::
+
+%% 9.3.0 2
+\specref{the} specifies that the \term{values}\meaning{1a} returned by \param{form}
+are of the \term{types} specified by \param{value-type}.
+The consequences are undefined if any \param{result}
+is not of the declared type.
+
+\issue{THE-AMBIGUITY:FOR-DECLARATION}
+%% This text has been removed per Moon #19 (first public review). -kmp 8-May-93
+% %!!! Barmar: If this is true, the THE form is equivalent to the form argument.
+% \param{Value-type} can be any valid \term{type specifier}.
+% In the case that \param{form} returns one
+%   value and \param{value-type} is not a 
+% \declref{values} \term{type specifier}, 
+% 
+% \code
+%  (the type exp) 
+% \EQ 
+%  (let ((#:g0001 exp))
+%    (declare (type type #:g0001))
+%    #:g0001)
+% \endcode
+\endissue{THE-AMBIGUITY:FOR-DECLARATION}
+
+\issue{JUN90-TRIVIAL-ISSUES:27}
+\issue{THE-VALUES:RETURN-NUMBER-RECEIVED}
+It is permissible for \param{form} to \term{yield} a different number of \term{values} 
+than are specified by \param{value-type}, provided that the values
+for which \param{types} are declared are indeed of those \term{types}.
+Missing values are treated as \nil\ for the purposes of checking their \term{types}.
+
+Regardless of number of \term{values} declared by \param{value-type},
+the number of \term{values} returned by \thespecform{the} is the same as
+the number of \term{values} returned by \param{form}. 
+\endissue{THE-VALUES:RETURN-NUMBER-RECEIVED}
+\endissue{JUN90-TRIVIAL-ISSUES:27}
+
+\label Examples::
+
+\issue{THE-VALUES:RETURN-NUMBER-RECEIVED}
+\code
+ (the symbol (car (list (gensym)))) \EV #:G9876
+ (the fixnum (+ 5 7)) \EV 12
+ (the (values) (truncate 3.2 2)) \EV 1, 1.2
+ (the integer (truncate 3.2 2)) \EV 1, 1.2
+ (the (values integer) (truncate 3.2 2)) \EV 1, 1.2
+ (the (values integer float) (truncate 3.2 2))   \EV 1, 1.2
+ (the (values integer float symbol) (truncate 3.2 2)) \EV 1, 1.2
+ (the (values integer float symbol t null list) 
+      (truncate 3.2 2)) \EV 1, 1.2
+ (let ((i 100))
+    (declare (fixnum i))
+    (the fixnum (1+ i))) \EV 101
+ (let* ((x (list 'a 'b 'c))
+        (y 5))
+    (setf (the fixnum (car x)) y)
+    x) \EV (5 B C)
+\endcode
+\endissue{THE-VALUES:RETURN-NUMBER-RECEIVED}
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+The consequences are undefined if
+the \term{values} \term{yielded} by the \param{form} 
+are not of the \term{type} specified by \param{value-type}.
+
+\label See Also::
+
+\declref{values}
+
+\label Notes::
+
+The \declref{values} \term{type specifier} can be used to indicate the types
+of \term{multiple values}:
+
+\code
+ (the (values integer integer) (floor x y))
+ (the (values string t)
+      (gethash the-key the-string-table))
+\endcode
+
+\macref{setf} can be used with \specref{the} type declarations.
+In this case the declaration is transferred to the form that
+specifies  the new value.  The resulting \macref{setf} \term{form}
+is then analyzed.
+
+\endcom
+
+%-------------------- Introspection --------------------
+
+%%% ========== SPECIAL-OPERATOR-P
+\begincom{special-operator-p}\ftype{Function}
+
+\issue{SPECIAL-FORM-P-MISNOMER:RENAME}
+
+\label Syntax::
+
+\DefunWithValues special-operator-p {symbol} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{symbol}---a \term{symbol}.
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 7.1.1 22
+\Predicate{symbol}{a \term{special operator}}
+
+\label Examples::
+
+\code
+ (special-operator-p 'if) \EV \term{true}
+ (special-operator-p 'car) \EV \term{false}
+ (special-operator-p 'one) \EV \term{false}
+\endcode
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+Should signal \typeref{type-error} if its argument is not a \term{symbol}.
+
+\label See Also:\None.
+
+\label Notes::
+
+Historically, this function was called \f{special-form-p}.  The name was
+finally declared a misnomer and changed, since it returned true for
+\term{special operators}, not \term{special forms}.
+
+%This is beyond the scope of the language. -kmp 26-Dec-90
+% A returned \term{non-nil} value is typically a \term{function}
+% of \term{implementation-dependent} nature that can be used to
+% interpret (evaluate) the \term{special form}.
+
+\endissue{SPECIAL-FORM-P-MISNOMER:RENAME}
+
+\endcom
+
+%%% ========== CONSTANTP
+\begincom{constantp}\ftype{Function}
+
+\issue{CONSTANTP-DEFINITION:INTENTIONAL}
+\issue{CONSTANTP-ENVIRONMENT:ADD-ARG}
+
+\label Syntax::
+
+\DefunWithValues constantp {form {\opt} environment} {generalized-boolean}
+
+\label Arguments and Values::
+
+\param{form}---a \term{form}.
+
+\param{environment}---an \term{environment} \term{object}.
+ \Default{\nil}
+
+\param{generalized-boolean}---a \term{generalized boolean}.
+
+\label Description::
+
+%% 20.1.0 14
+%% 20.1.0 15
+Returns \term{true} if \param{form} can be determined
+by the \term{implementation} to be a \term{constant form} 
+in the indicated \param{environment}; 
+otherwise, it returns \term{false} indicating either 
+    that the \term{form} is not a \term{constant form}
+ or that it cannot be determined whether or not \term{form} is a \term{constant form}.
+
+The following kinds of \term{forms} are considered \term{constant forms}:
+\beginlist
+\itemitem{\bull}
+% This is the wrong term.  --sjl 5 Mar 92
+%  \term{Constant objects}
+  \term{Self-evaluating objects} 
+  (such as \term{numbers}, 
+           \term{characters},
+       and the various kinds of \term{arrays})
+  are always considered \term{constant forms} 
+  and must be recognized as such by \funref{constantp}.
+
+\itemitem{\bull}
+  \term{Constant variables}, such as \term{keywords},
+  symbols defined by \clisp\ as constant (such as \nil, \t, and \conref{pi}),
+  and symbols declared as constant by the user in the indicated \param{environment}
+   using \macref{defconstant}
+  are always considered \term{constant forms}
+  and must be recognized as such by \funref{constantp}.
+
+\itemitem{\bull}
+  \specref{quote} \term{forms} are always considered \term{constant forms}
+  and must be recognized as such by \funref{constantp}.
+
+\itemitem{\bull} 
+  An \term{implementation} is permitted, but not required, to detect
+  additional \term{constant forms}.  If it does, it is also permitted,
+  but not required, to make use of information in the \param{environment}.
+  Examples of \term{constant forms} for which \funref{constantp} might
+  or might not return \term{true} are:
+    \f{(sqrt pi)},
+    \f{(+ 3 2)},
+    \f{(length '(a b c))},
+  and
+    \f{(let ((x 7)) (zerop x))}.
+\endlist
+
+If an \term{implementation} chooses to make use of the \param{environment}
+information, such actions as expanding \term{macros} or performing function
+inlining are permitted to be used, but not required; 
+however, expanding \term{compiler macros} is not permitted.
+
+\label Examples::
+
+\code
+ (constantp 1) \EV \term{true}
+ (constantp 'temp) \EV \term{false}
+ (constantp ''temp)) \EV \term{true}
+ (defconstant this-is-a-constant 'never-changing) \EV THIS-IS-A-CONSTANT 
+ (constantp 'this-is-a-constant) \EV \term{true}
+ (constantp "temp") \EV \term{true}
+ (setq a 6) \EV 6 
+ (constantp a) \EV \term{true}
+ (constantp '(sin pi)) \EV \term{implementation-dependent}
+ (constantp '(car '(x))) \EV \term{implementation-dependent}
+ (constantp '(eql x x)) \EV \term{implementation-dependent}
+ (constantp '(typep x 'nil)) \EV \term{implementation-dependent}
+ (constantp '(typep x 't)) \EV \term{implementation-dependent}
+ (constantp '(values this-is-a-constant)) \EV \term{implementation-dependent}
+ (constantp '(values 'x 'y)) \EV \term{implementation-dependent}
+ (constantp '(let ((a '(a b c))) (+ (length a) 6))) \EV \term{implementation-dependent}
+\endcode
+
+\label Side Effects:\None!
+
+\label Affected By::
+
+The state of the global environment (\eg which \term{symbols} have been
+declared to be the \term{names} of \term{constant variables}).
+
+\label Exceptional Situations:\None!
+
+\label See Also::
+
+\macref{defconstant}
+
+\label Notes:\None.
+
+\endissue{CONSTANTP-ENVIRONMENT:ADD-ARG}
+\endissue{CONSTANTP-DEFINITION:INTENTIONAL}
+
+\endcom
+
+\issue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}
+% The following functions were removed due to the retraction of
+% issue SYNTACTIC-ENVIRONMENT-ACCESS by X3J13 at the Mar 91 meeting.
+%  AUGMENT-ENVIRONMENT
+%  DECLARATION-INFORMATION
+%  DEFINE-DECLARATION
+%  ENCLOSE
+%  FUNCTION-INFORMATION
+%  PARSE-MACRO
+%  VARIABLE-INFORMATION
+\endissue{SYNTACTIC-ENVIRONMENT-ACCESS:RETRACTED-MAR91}

dict-files.tex

@@ -0,0 +1,725 @@
+% -*- Mode: TeX -*-
+
+% Files
+%  Directory
+%   Directory Query
+%    File Properties
+%   Directory Modification
+
+%-------------------- Directory Query --------------------
+
+%%% ========== DIRECTORY
+\begincom{directory}\ftype{Function}
+
+%% 23.5.0 3
+\label Syntax::
+
+\DefunWithValues directory {pathspec {\key}} {pathnames}
+
+\label Arguments and Values::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{pathspec}---a \term{pathname designator},
+		   which may contain \term{wild} components.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\param{pathnames}---a \term{list} of
+\issue{PATHNAME-LOGICAL:ADD}
+\term{physical pathnames}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\label Description::
+
+%% 23.5.0 4
+
+Determines which, if any, \term{files} that are present
+in the file system have names matching \param{pathspec},
+and returns a 
+\issue{RESULT-LISTS-SHARED:SPECIFY}
+\term{fresh}
+\endissue{RESULT-LISTS-SHARED:SPECIFY}
+\term{list} of \term{pathnames} corresponding to the \term{truenames} of
+those \term{files}.
+
+An \term{implementation} may be extended to accept 
+\term{implementation-defined} keyword arguments to \funref{directory}.  
+
+\label Examples:\None.
+
+\label Affected By::
+
+The host computer's file system.
+
+\label Exceptional Situations::
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+If the attempt to obtain a directory listing is not successful,
+an error \oftype{file-error} is signaled.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label See Also::
+
+\typeref{pathname},
+\issue{PATHNAME-LOGICAL:ADD}
+\typeref{logical-pathname},
+\endissue{PATHNAME-LOGICAL:ADD}
+\funref{ensure-directories-exist},
+{\secref\FileSystemConcepts},
+{\secref\OpenAndClosedStreams},
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes::
+
+If the \param{pathspec} is not \term{wild},
+the resulting list will contain either zero or one elements.
+
+\clisp\ specifies ``{\key}'' in the argument list to \funref{directory} 
+even though no \term{standardized} keyword arguments to \funref{directory} are defined.
+``\f{:allow-other-keys t}''
+may be used in \term{conforming programs} in order to quietly ignore any
+additional keywords which are passed by the program but not supported
+by the \term{implementation}.
+
+\endcom
+
+%%% ========== PROBE-FILE
+\begincom{probe-file}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues probe-file {pathspec} {truename}
+
+\label Arguments and Values::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{pathspec}---a \term{pathname designator}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{truename}---a \term{physical pathname} or \nil.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\label Description::  
+
+\funref{probe-file} tests whether a file exists.
+
+%% 23.3.0 12
+\funref{probe-file} returns \term{false} if there is no file named \param{pathspec},
+and otherwise returns the \term{truename} of \param{pathspec}.
+
+If the \param{pathspec} \term{designator} is an open \term{stream},
+then \funref{probe-file} produces the \term{truename} of its associated \term{file}.
+%!!! Sandra wonders if the following is implied by "pathname designator":
+\issue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+If \param{pathspec} is a \term{stream}, whether open or closed,
+it is coerced to a \term{pathname} as if by \thefunction{pathname}.
+\endissue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+
+\label Examples:\None.
+
+\label Affected By::
+
+The host computer's file system.
+
+\label Exceptional Situations::
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+\issue{PATHNAME-WILD:NEW-FUNCTIONS}
+An error \oftype{file-error} is signaled if \param{pathspec} is \term{wild}.
+\endissue{PATHNAME-WILD:NEW-FUNCTIONS}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+%% Wording changed per x3j13 (05-Oct-93) -kmp
+% If the probe attempt is not successful,
+% an error \oftype{file-error} is signaled.
+An error \oftype{file-error} is signaled
+if the \term{file system} cannot perform the requested operation.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label See Also::
+
+\funref{truename},
+\funref{open},
+\funref{ensure-directories-exist},
+\typeref{pathname},
+\issue{PATHNAME-LOGICAL:ADD}
+\typeref{logical-pathname},
+\endissue{PATHNAME-LOGICAL:ADD}
+{\secref\FileSystemConcepts},
+{\secref\OpenAndClosedStreams},
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== ENSURE-DIRECTORIES-EXIST
+\begincom{ensure-directories-exist}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues ensure-directories-exist {pathspec {\key} verbose} {pathspec, created}
+
+\label Arguments and Values::
+
+\param{pathspec}---a \term{pathname designator}.
+
+\param{verbose}---a \term{generalized boolean}.
+
+\param{created}---a \term{generalized boolean}.
+
+\label Description::  
+
+Tests whether the directories containing the specified \term{file} actually exist,
+and attempts to create them if they do not.
+
+If the containing directories do not exist and if \param{verbose} is \term{true}, 
+then the \term{implementation} is permitted (but not required) 
+to perform output to \term{standard output} saying what directories were created.
+If the containing directories exist, or if \param{verbose} is \term{false},
+this function performs no output.
+
+The \term{primary value} is the given \term{pathspec} so that this operation can
+be straightforwardly composed with other file manipulation expressions.
+The \term{secondary value}, \param{created}, is \term{true} if any directories were
+created.
+
+\label Examples:\None.
+
+\label Affected By::
+
+The host computer's file system.
+
+\label Exceptional Situations::
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+%% Confusion over type of error signaled resolved by x3j13 05-Oct-93
+%%  (type-error => file-error). -kmp
+An error \oftype{file-error} is signaled if the host, device, or directory
+part of \param{pathspec} is \term{wild}.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+If the directory creation attempt is not successful,
+an error \oftype{file-error} is signaled;
+if this occurs, 
+it might be the case that none, some, or all
+of the requested creations have actually occurred 
+within the \term{file system}.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+%% Removed per X3J13 05-Oct-93.
+%%  See first paragraph of Exceptional Situations above. -kmp
+% \issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+% An error \oftype{file-error} might be signaled if \param{pathspec}
+% is a \term{designator} for a \term{wild} \term{pathname}.
+% \endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label See Also::
+
+\funref{probe-file},
+\funref{open},
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes:\None.
+
+\endcom
+
+
+
+%%% ========== TRUENAME
+\begincom{truename}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues truename {filespec} {truename}
+
+\label Arguments and Values:: 
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{filespec}---a \term{pathname designator}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{truename}---a \term{physical pathname}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\label Description::
+
+\funref{truename} tries to find the \term{file} indicated by 
+\param{filespec} and returns its \term{truename}.
+%!!! Sandra wonders if the following is implied by "pathname designator":
+%% 23.1.2 6
+If the \param{filespec} \term{designator} is an open \term{stream},
+its associated \term{file} is used.
+\issue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+If \param{filespec} is a \term{stream},
+\funref{truename} can be used whether the \term{stream}
+is open or closed. It is permissible for \funref{truename} 
+to return more specific information after the \term{stream}
+is closed than when the \term{stream} was open.
+\endissue{CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY}
+If \param{filespec} is a \term{pathname} 
+it represents the name used to open the file. This may be, but is
+not required to be, the actual name of the file. 
+
+\label Examples::
+
+\code
+;; An example involving version numbers.  Note that the precise nature of
+;; the truename is implementation-dependent while the file is still open.
+ (with-open-file (stream ">vistor>test.text.newest")
+   (values (pathname stream)
+           (truename stream)))
+\EV #P"S:>vistor>test.text.newest", #P"S:>vistor>test.text.1"
+\OV #P"S:>vistor>test.text.newest", #P"S:>vistor>test.text.newest"
+\OV #P"S:>vistor>test.text.newest", #P"S:>vistor>_temp_._temp_.1"
+
+;; In this case, the file is closed when the truename is tried, so the
+;; truename information is reliable.
+ (with-open-file (stream ">vistor>test.text.newest")
+   (close stream)
+   (values (pathname stream)
+           (truename stream)))
+\EV #P"S:>vistor>test.text.newest", #P"S:>vistor>test.text.1"
+
+;; An example involving TOP-20's implementation-dependent concept 
+;; of logical devices -- in this case, "DOC:" is shorthand for
+;; "PS:<DOCUMENTATION>" ...
+ (with-open-file (stream "CMUC::DOC:DUMPER.HLP")
+   (values (pathname stream)
+           (truename stream)))
+\EV #P"CMUC::DOC:DUMPER.HLP", #P"CMUC::PS:<DOCUMENTATION>DUMPER.HLP.13"
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+An error \oftype{file-error} is signaled if an appropriate \term{file}
+cannot be located within the \term{file system} for the given \param{filespec},
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+%% Additional constraint per x3j13 (05-Oct-93) -kmp
+or if the \term{file system} cannot perform the requested operation.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+\issue{PATHNAME-WILD:NEW-FUNCTIONS}
+An error \oftype{file-error} is signaled if \param{pathname} is \term{wild}.
+\endissue{PATHNAME-WILD:NEW-FUNCTIONS}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label See Also::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\typeref{pathname},
+\typeref{logical-pathname},
+{\secref\FileSystemConcepts},
+\endissue{PATHNAME-LOGICAL:ADD}
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes::
+ 
+%% 23.1.2 7
+\funref{truename} may be used to account for any \term{filename} translations 
+performed by the \term{file system}.
+
+\endcom
+
+%-------------------- File Properties --------------------
+
+%%% ========== FILE-AUTHOR
+\begincom{file-author}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues file-author {pathspec} {author}
+
+\label Arguments and Values::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{pathspec}---a \term{pathname designator}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\param{author}---a \term{string} or \nil.
+
+\label Description::
+
+%% 23.3.0 15
+Returns a \term{string} naming the author of the \term{file} specified by \param{pathspec},
+or \nil\ if the author's name cannot be determined.
+
+\label Examples::
+
+\code
+ (with-open-file (stream ">relativity>general.text")
+   (file-author s))
+\EV "albert"
+\endcode
+
+\label Affected By::
+The host computer's file system.
+
+Other users of the \term{file} named by \param{pathspec}.
+\label Exceptional Situations::
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+\issue{PATHNAME-WILD:NEW-FUNCTIONS}
+An error \oftype{file-error} is signaled if \param{pathspec} is \term{wild}.
+\endissue{PATHNAME-WILD:NEW-FUNCTIONS}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+%% Wording changed per x3j13 (05-Oct-93) -kmp
+% If the attempt to obtain authorship information is not successful,
+% an error \oftype{file-error} is signaled.
+An error \oftype{file-error} is signaled
+if the \term{file system} cannot perform the requested operation.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label See Also::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\typeref{pathname},
+\typeref{logical-pathname},
+{\secref\FileSystemConcepts},
+\endissue{PATHNAME-LOGICAL:ADD}
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes:\None.
+ 
+\endcom
+
+%%% ========== FILE-WRITE-DATE
+\begincom{file-write-date}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues file-write-date {pathspec} {date}
+
+\label Arguments and Values::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{pathspec}---a \term{pathname designator}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\param{date}---a \term{universal time} or \nil.
+
+\label Description::
+
+%% 23.3.0 14
+Returns a \term{universal time} representing the time at which the \term{file} 
+specified by \param{pathspec} was last written (or created), 
+or returns \nil\ if such a time cannot be determined.
+
+\label Examples::
+
+\code
+ (with-open-file (s "noel.text" 
+                    :direction :output :if-exists :error)
+   (format s "~&Dear Santa,~2%I was good this year.  ~
+                Please leave lots of toys.~2%Love, Sue~
+             ~2%attachments: milk, cookies~%")
+   (truename s))
+\EV #P"CUPID:/susan/noel.text"
+ (with-open-file (s "noel.text")
+   (file-write-date s))
+\EV 2902600800
+\endcode
+
+\label Affected By::
+
+The host computer's file system.
+
+\label Exceptional Situations::
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+\issue{PATHNAME-WILD:NEW-FUNCTIONS}
+An error \oftype{file-error} is signaled if \param{pathspec} is \term{wild}.
+\endissue{PATHNAME-WILD:NEW-FUNCTIONS}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+%% Wording changed per x3j13 (05-Oct-93) -kmp
+% If the attempt to obtain write-date information is not successful,
+% an error \oftype{file-error} is signaled.
+An error \oftype{file-error} is signaled
+if the \term{file system} cannot perform the requested operation.
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label See Also::
+
+{\secref\UniversalTime},
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes:\None.
+ 
+\endcom
+
+%-------------------- Directory Modification --------------------
+
+%%% ========== RENAME-FILE
+\begincom{rename-file}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues rename-file 
+	         {filespec new-name}
+		 {defaulted-new-name, old-truename, new-truename}
+
+\label Arguments and Values::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{filespec}---a \term{pathname designator}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\param{new-name}---a \term{pathname designator} 
+%!!! it used to say (or pathname string symbol), so I added this for now ... ??
+other than a \term{stream}.
+
+\param{defaulted-new-name}---a \term{pathname}
+
+\param{old-truename}---a \term{physical pathname}.
+
+\param{new-truename}---a \term{physical pathname}.
+
+\label Description::
+
+%% 23.3.0 3
+\funref{rename-file} modifies the file system in such a way
+that the file indicated by \param{filespec} is renamed to
+%% Per X3J13. -kmp 05-Oct-93
+%\param{new-name}.
+\param{defaulted-new-name}.
+
+%% 23.3.0 6
+%!!! Sandra asks whether this first is a prohition on "filespec" or "new-name" or both?
+It is an error to specify a filename containing a \term{wild} component,
+for \param{filespec} to contain a \nil\ component where the file system does
+not permit a \nil\ component, or for the result of defaulting missing
+components of \param{new-name} from \param{filespec} to contain a \nil\ component
+where the file system does not permit a \nil\ component.
+
+\issue{PATHNAME-LOGICAL:ADD}
+If \param{new-name} is a \term{logical pathname}, 
+\funref{rename-file} returns a \term{logical pathname} as its \term{primary value}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+%% 23.3.0 4
+\funref{rename-file} 
+returns three values if successful.  The \term{primary value}, \param{defaulted-new-name},
+is the resulting name which is composed of
+\param{new-name} with any missing components filled in by performing
+a \funref{merge-pathnames} operation using \param{filespec} as the defaults.
+The \term{secondary value}, \param{old-truename},
+is the \term{truename} of the \term{file} before it was renamed.
+The \term{tertiary value}, \param{new-truename},
+is the \term{truename} of the \term{file} after it was renamed.
+
+If the \param{filespec} \term{designator} is an open \term{stream},
+then the \term{stream} itself and the file associated with it are 
+affected (if the \term{file system} permits).
+
+\label Examples::
+
+\code
+;; An example involving logical pathnames.
+ (with-open-file (stream "sys:chemistry;lead.text"
+                         :direction :output :if-exists :error)
+   (princ "eureka" stream)
+   (values (pathname stream) (truename stream)))
+\EV #P"SYS:CHEMISTRY;LEAD.TEXT.NEWEST", #P"Q:>sys>chem>lead.text.1"
+ (rename-file "sys:chemistry;lead.text" "gold.text")
+\EV #P"SYS:CHEMISTRY;GOLD.TEXT.NEWEST",
+   #P"Q:>sys>chem>lead.text.1",
+   #P"Q:>sys>chem>gold.text.1"
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+%% 23.3.0 5
+If the renaming operation is not successful, an error \oftype{file-error} is signaled.
+
+\issue{PATHNAME-WILD:NEW-FUNCTIONS}
+An error \oftype{file-error} might be signaled if \param{filespec} is \term{wild}.
+%!!! Sandra asks whether this should extend to  "new-name" as well?
+\endissue{PATHNAME-WILD:NEW-FUNCTIONS}
+
+\label See Also::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\funref{truename},
+\typeref{pathname},
+\typeref{logical-pathname},
+{\secref\FileSystemConcepts},
+\endissue{PATHNAME-LOGICAL:ADD}
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes:\None.
+
+\endcom
+
+%%% ========== DELETE-FILE
+\begincom{delete-file}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues delete-file {filespec} {\t}
+
+\label Arguments and Values::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\param{filespec}---a \term{pathname designator}.
+\endissue{PATHNAME-LOGICAL:ADD}
+
+\label Description::
+
+Deletes the \term{file} specified by \param{filespec}.
+
+%!!! Sandra thinks this makes no sense. -kmp 12-Dec-91
+If the \param{filespec} \term{designator} is an open \term{stream},
+then \param{filespec} and the file associated with it are affected 
+(if the file system permits),
+in which case \param{filespec} might be closed immediately,
+and the deletion might be immediate or delayed until \param{filespec} is explicitly closed,
+depending on the requirements of the file system.
+
+It is \term{implementation-dependent} whether an attempt
+to delete a nonexistent file is considered to be successful.
+
+%% 23.3.0 8
+%% 23.3.0 9
+\funref{delete-file} returns \term{true} if it succeeds,
+or signals an error \oftype{file-error} if it does not.
+
+%% 23.3.0 10
+The consequences are undefined 
+    if \param{filespec} has a \term{wild} component,
+ or if \param{filespec} has a \nil\ component 
+     and the file system does not permit a \nil\ component.
+
+\label Examples::
+
+\code
+ (with-open-file (s "delete-me.text" :direction :output :if-exists :error))
+\EV NIL
+ (setq p (probe-file "delete-me.text")) \EV #P"R:>fred>delete-me.text.1"
+ (delete-file p) \EV T
+ (probe-file "delete-me.text") \EV \term{false}
+ (with-open-file (s "delete-me.text" :direction :output :if-exists :error)
+   (delete-file s))
+\EV T
+ (probe-file "delete-me.text") \EV \term{false}
+\endcode
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+If the deletion operation is not successful, an error \oftype{file-error} is signaled.
+
+\issue{PATHNAME-WILD:NEW-FUNCTIONS}
+An error \oftype{file-error} might be signaled if \param{filespec} is \term{wild}.
+\endissue{PATHNAME-WILD:NEW-FUNCTIONS}
+
+\label See Also::
+
+\issue{PATHNAME-LOGICAL:ADD}
+\typeref{pathname},
+\typeref{logical-pathname},
+{\secref\FileSystemConcepts},
+\endissue{PATHNAME-LOGICAL:ADD}
+\issue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+{\secref\PathnamesAsFilenames}
+\endissue{FILE-OPEN-ERROR:SIGNAL-FILE-ERROR}
+
+\label Notes:\None.
+ 
+\endcom
+
+%-------------------- File Errors --------------------
+
+\begincom{file-error}\ftype{Condition Type}
+
+\label Class Precedence List::
+\typeref{file-error},
+\typeref{error},
+\typeref{serious-condition},
+\typeref{condition},
+\typeref{t}
+
+\label Description::
+
+\Thetype{file-error} consists of error conditions that occur during 
+an attempt to open or close a file, or during some low-level transactions 
+with a file system.  The ``offending pathname'' is initialized by 
+\theinitkeyarg{pathname} to \funref{make-condition}, and is \term{accessed}
+by \thefunction{file-error-pathname}.
+
+\label See Also::
+
+\function{file-error-pathname},
+\funref{open},
+\funref{probe-file},
+\funref{directory},
+\funref{ensure-directories-exist}
+
+\endcom%{file-error}\ftype{Condition Type}
+
+%%% ========== FILE-ERROR-PATHNAME
+\begincom{file-error-pathname}\ftype{Function}
+
+\label Syntax::
+
+\DefunWithValues file-error-pathname {condition} {pathspec}
+
+\label Arguments and Values:: 
+
+\param{condition}---a \term{condition} \oftype{file-error}.
+
+\param{pathspec}---a \term{pathname designator}.
+
+\label Description::
+
+Returns the ``offending pathname'' of a \term{condition} \oftype{file-error}.
+
+\label Examples:\None.
+
+\label Side Effects:\None.
+
+\label Affected By:\None.
+
+\label Exceptional Situations::
+
+% This might signal an error (probably TYPE-ERROR, but you can't say that
+% because it's not been voted in yet) if argument is not of correct type.
+% (Part of the issue here is whether anyone might define other signatures.)
+
+\label See Also::
+
+\typeref{file-error},
+{\secref\Conditions}
+
+\label Notes:\None.
+
+%% Removed because no primitive is provided to do this! -kmp
+%It is an error to use \macref{setf} with \funref{file-error-pathname}.
+
+\endcom