Edit ``Proposed ANSI Revisions and Clarifications''

This page is a listing of proposed and wishlist revisions and clarifications to _(ANSI) _(Common Lisp). It is not a forum for pie-in-the sky thoughts about future Lisps (for which, see _(Lisp - Next Generation)) or extra functionality that could be standardized (see _(Proposed Extensions To ANSI).)

Please check that what you're proposing isn't already in the standard.

<h2>Clarifications to the current standard:</h2>

<ul>
<li>_(Issue PRINTING-SPACE): Change the behavior of <a href="http://www.lisp.org/HyperSpec/Body/sec_22-1-3-2.html">character printing</a> such that invisible graphic characters such as space can be printed by name. The <a href="http://www.lisp.org/HyperSpec/Body/sec_22-3-1-1.html">~:C format directive</a> does this already.

<li>_(Issue BUTLAST-DOTTED-LIST): Clarify behaviour of :(CLHS "BUTLAST") and :(CLHS "NBUTLAST") for dotted lists.

<li>_(Issue ARRAY-ELEMENT-TYPE-NIL): Explicitly allow or disallow arrays of element type NIL, and clarify 
whether they are strings or not.

<li>_(Issue ARRAY-UPGRADING-UNDECIDABLE): As defined, array element upgrading is undecidable. Fix this.

<li>_(Issue EQUAL-CIRCULAR-LIST): Change ":(CLHS "EQUAL") may fail to terminate if x or y is circular" to "if x and y are circular", so that (equal t '#1=(nil #1#)) is required to terminate. (There is no such wording for :(CLHS "EQUALP").)

<li>_(Issue DEFINE-COMPILER-MACRO-DECLINE): Clarify what a compiler macro function should return if it declines to expand the form. The <a href="http://www.lisp.org/HyperSpec/Body/glo_c.html#compiler_macro_function">glossary entry</a> says NIL; :(CLHS "DEFINE-COMPILER-MACRO") and <a href="http://www.lisp.org/HyperSpec/Body/sec_3-2-2-1.html">3.2.2.1</a> say the original form.

<li>_(Issue PROG2-RETURN-VALUE): :(CLHS "PROG2") returns the primary value of the second form, as specified under "Arguments and Values". The text under "Description" that claims otherwise is wrong.

<li>_(Issue ERROR-EXAMPLE): Correct the invalid IF form in the (informational) wargames:no-win-scenario example for <a href="http://www.lisp.org/HyperSpec/Body/fun_error.html">ERROR</a>.

<li>_(Issue CHECK-TYPE-EXAMPLE): Correct the example for :(CLHS "CHECK-TYPE") that suggests that a case conversion of the first letter of the optional string might take place.

<li>_(Issue FORMAT-RADIX-COMMACHAR): Clarify or correct the interaction between padchar and commachar in :(CLHS "FORMAT") (<a href="http://www.lisp.org/HyperSpec/Body/sec_22-3-2-1.html">CLHS 22.3.2.1</a>).

<li>_(Issue PRINTING-ARRAYS-READABLY): The description of :(CLHS "*PRINT-READABLY*") says that throwing a :(CLHS "PRINT-NOT-READABLE") error is allowed for certain arrays. <a href="http://www.lisp.org/HyperSpec/Body/sec_22-1-3-7.html">CLHS 22.1.3.7</a> seems to imply that no error is allowed. This should probably be clarified one way or the other.

<li>_(Issue DESTRUCTURING-NIL): Confirm or disconfirm that NIL in a destructuring lambda list (or a macro lambda list) acts as a "don't care" symbol, matching any object without causing a binding. Why would it do that, other than in LOOP destructuring?

<li>:(CLHS "RESTART-CASE") clarification
 <ul>
 <li>_(Issue RESTART-CASE-EXAMPLE): :(CLHS "RESTART-CASE") examples: read-new-value should use :(CLHS "*QUERY-IO*") as specified above in the description of :INTERACTIVE option.
 <li>Clarify, that the argument to the test function may be a condition or NIL.
 <li>:(CLHS RESTART-CASE) refers to "each arglist" but the "Arguments and Values" sections talks about lambda-list. It should therefore be "each lambda-list".
 </ul>

<li>:(CLHS "LOOP") clarifications
 <ul>
 <li>_(Issue LOOP-FINALLY-VARIABLES): Clarify whether iteration variables are visible in FINALLY clauses. <a href="http://www.lisp.org/HyperSpec/Body/sec_6-1-1-4.html">CLHS 6.1.1.4</a> requires FINALLY clauses to end up in the same tagbody where the loop body is. The forms that bind iteration variables cannot be inside the tagbody as part of the loop body, because the loop prologue wouldn't then be able to access the variables. Thus, the binding forms must be around the tagbody, so the variables must be visible in FINALLY clauses. <a href="http://www.lisp.org/HyperSpec/Body/sec_6-1-1-6.html">CLHS 6.1.1.6</a> may help deduce the values of the variables.
 <li>_(Issue LOOP-WITH-NIL): Is (loop <a href="http://www.lisp.org/HyperSpec/Body/sec_6-1-2-2.html">with</a> x of-type nil do (return x)) required to construct and return an "appropriate default value" for type NIL?
 </ul>

<li>_(Issue DEFCLASS-READER-FUNCTION-NAME): The specification for :(CLHS "DEFCLASS") is a bit strange - in particular the use of reader-function-name for both :reader and :accessor, with two different descriptions given. Propose clarification by changing the second to accessor-function-name in both places.

<li>:(CLHS "DEFINE-CONDITION") clarifications
 <ul>
 <li>_(Issue DEFINE-CONDITION-WRITERS): The writeability or otherwise of condition slots is a little unclear. :(CLHS "DEFINE-CONDITION")'s Syntax allows <tt>:writer</tt> and <tt>:accessor</tt>, though the Description does not specify them, and the issues seem to imply that conditions were meant to be read-only objects.
 <li>_(Issue DEFINE-CONDITION-DOCUMENTATION): The :documentation option applies to the whole type in "Syntax" but to individual slots in "Arguments and Values" and "Description". :(CLHS "DEFCLASS") allows it in both places. It seems that :documentation was inadvertently omitted from the options BNF, although the text describes it as applicable in both locations per DEFCLASS.
 <li>_(Issue DEFINE-CONDITION-SLOT-NAME): The syntax where slot-name is "the list of slot name/slot form pairs" seems redundant, given :initform. Was it left in by accident?
 Current practice: (define-condition foo () ((((slot-name-symbol . "slot form"))))) signals an error in _(CMUCL) release-18e-branch, _(SBCL) 0.8.9.46, and _(CLISP) 2.32.
 <li>DEFINE-CONDITION-REPORT: The description of the :report option is put down at the bottom, in with slot-options, rather than normal options. Simple typo, but makes the page a little confusing. 
 </ul>

<li>_(Issue READER-MACRO-VALUES): Ok for reader macros to return more than one value?

<li>_(Issue DEFMACRO-VALUES): If the body of :(CLHS DEFMACRO) returns multiple values, can the macro function return them too?

<li>_(Issue WITH-HASH-TABLE-ITERATOR-BINDING-TYPE): The Exceptional Situations for :(CLHS "WITH-HASH-TABLE-ITERATOR") claim it establishes a local function. Should be a local macro.

<li>_(Issue CLOSE-FILE-OPENED-WITH-SUPERSEDE): Clarify the behaviour of :(CLHS CLOSE) when :abort is T and an old file is being superseded: :(CLHS OPEN) implies that an implementation is allowed to have already deleted the old file, whereas CLOSE does not allow this.

<li>_(Issue STANDARD-PACKAGE-NICKNAMES): Section 11.1.2 gives 'a summary of the names and nicknames of those standardized packages'. Clarify whether this list is exhaustive, or if an implementation may provide other nicknames.

<li>_(Issue DEFINE-SETF-METHOD): 11.1.2.1.2.13. speaks of DEFINE-SETF-METHOD, should be :(CLHS DEFINE-SETF-EXPANDER).

<li>_(Issue DEFCONSTANT-PREVIOUS-VALUE): :(CLHS DEFCONSTANT) says "The consequences are undefined if there are any bindings of the variable named by name at the time defconstant is executed or if the value is not eql to the value of initial-value." Clarify "...or the symbol-value of name...", or equivalent.

<li>_(Issue MAKE-INSTANCES-OBSOLETE-SYMBOL): Clarify that :(CLHS MAKE-INSTANCES-OBSOLETE), when called on the name of a class, returns that name, not the class object itself.

<li>_(Issue THE-VALUES): The entry for :(CLHS "THE") seems to imply that the number of values is not important. However, the entry for :(CLHS "VALUES") says that using &optional or &rest constrains the number of values.

<li>_(Issue STANDARDIZED-RESTART-NAMES): Clarify that :(CLHS "ABORT"), :(CLHS "CONTINUE"), :(CLHS "MUFFLE-WARNING"), :(CLHS "STORE-VALUE") and :(CLHS "USE-VALUE") may be bound as restart names by conforming code; this seems to be the intent, but formally CLHS 11.1.2.1.2 (point 18) could be read as disallowing it.

<li>_(Issue VALUES-&ALLOW-OTHER-KEYS): (:(clhs values) :(clhs "&ALLOW-OTHER-KEYS")) matches the syntax for the VALUES type specifier, but the description doesn't say what it means. Because the syntax does not allow :(clhs "&KEY"), &allow-other-keys was probably a mistake.

<li>_(Issue DO-SEMANTICS): According to the entry for :(CLHS "DO"), "do iterates over a group of statements while a test condition holds." But the iteration really continues until the test form returns true, which is more or less the opposite of what that sentence seems to suggest. Change that sentence to read "do iterates over a group of statements until a test form returns true".

<li>_(Issue FORMAT-TABULATE): CLHS 22.3.6.1, paragraph 1 describes what the ~T format directive does. If colnum is less than the current column, colinc is positive, and (mod (- curcol colnum) colinc) is 0, then it is unclear if this directive causes any spaces to be printed (and similarly for the case in :(CLHS "PPRINT-TAB")). Existing implementations do print at least one space in this case. Clarify that this is the intended behavior.

<li>_(Issue DEFGENERIC-METHOD-COMBINATION-NAME): Clarify that the method-combination in a :(CLHS DEFGENERIC) form is specified through a symbol, not a :(CLHS "METHOD-COMBINATION") object.

<li>_(Issue DEFGENERIC-MULTIPLE-DECLARE): Clarify that multiple DECLARE options can occur in a single :(CLHS DEFGENERIC) form.

<li> _(Issue FORMAT-RADIX-NONINTEGER): Clarify that the ~R directive (and the ~B, ~O, and ~X directives) print like ~A when the argument is not an integer. Also, clarify that in these cases (and ~D) the mincol and padchar arguments are passed along appropriately to the ~A directive, and that the *PRINT-BASE* is bound appropriately.

<li> _(Issue FORMAT-RADIX-MISSING-RADIX): Clarify the meaning of the ~R directive when the first parameter is missing but later parameters are not. Also, clarify whether ~VR means the same thing as ~R when the V parameter is NIL.

<li> _(Issue FORMAT-G-NONNUMBER): Clarify that the ~G directive behaves like the ~E, ~F and ~dollars directives on non-numeric arguments.

<li> Specify that the tabsize argument to PPRINT-TABULAR may be present and be NIL. This makes ~v/pprint-tabular/ work properly in FORMAT when the argument is NIL, and is consistent with the sample imeplementation given for PPRINT-TABULAR.

<li>The treatment of ~T is inconsistent depending on the presence of the colon modifier. As stated, the versions with the colon modifier are the same as calls to pprint-tab, but those without are not. This means the former get turned off when printing to something that is not a pretty printing stream or when *print-pretty* is nil, but the latter are always on. Clarify whether this was intended. Note that Lispworks appears to treat all versions as calls to pprint-tab.

<li>In the ~A format directive, the behavior of minpad format parameter is described as follows: 'The string is padded on the right (or on the left if the @ modifier is used) with at least minpad copies of padchar; padding characters are then inserted colinc characters at a time until the total width is at least mincol.' Clarify that the implementation uses the minimum number of padding characters consistent with this requirement.

<li>_(Issue PRINT-LENGTH-AND-STRUCTURES): clarify the effect the :(CLHS "*PRINT-LENGTH*") printer control variable has on the default method for printing structure objects.

<li>Clarify that there should be a predefined method for PRINT-OBJECT on the class CONDITION, not only on the classes STANDARD-OBJECT and STRUCTURE-OBJECT. Rationale: The description of DEFINE-CONDITION says "Condition reporting is mediated through the print-object method..." and "Specifying :REPORT ... is equivalent to (DEFMETHOD PRINT-OBJECT ...)". This implies that conditions are printed through PRINT-OBJECT, and therefore a predefined method needs to be in place.

<li>The notes about :(CLHS "WITH-ACCESSORS") claim it'll give a binding like (<var>variable-namei</var> () (<var>accessor-namei</var> in)) to :(CLHS "SYMBOL-MACROLET"), which however does not accept that syntax. The empty parentheses should be removed.

<li>Issue CLASS-OBJECT-SPECIALIZER:AFFIRM: ANSI CL 7.6.2 says that class objects are usable as parameter-specializer-names. This is consistent with the vote on issue CLASS-OBJECT-SPECIALIZER:AFFIRM. However, in the Syntax section of the macros :(CLHS "DEFMETHOD") and :(CLHS "DEFGENERIC"), only symbols and <t>(eql ...)</t> lists are allowed as parameter specializer names in a method lambda list. Proposal: Update the syntax section of :(CLHS "DEFMETHOD") and :(CLHS DEFGENERIC). Otherwise classes without proper name are nearly useless - since no methods can be defined for them using only ANSI CL facilities.

<li> _(Issue TIME-ALWAYS-PRINTS): The :(CLHS TIME) macro prints timing information on a form. Clarify whether it does so only when the form terminates normally, or also when control is transfered from the form by a :(CLHS GO), :(CLHS THROW), :(CLHS RETURN), :(CLHS RETURN-FROM), or by the raising of a condition.

<li> _(Issue READ-DELIMITED-LIST:END-OF-FILE): The :(CLHS READ-DELIMITED-LIST) page of the standard says: "It is an error to reach end-of-file during the operation of read-delimited-list." This means the behavior is undefined (see the glossary entry for "error"), which makes this function useless in practice. This should be defined as an exceptional situation with behavior consistent with :(CLHS READ) and other reader functions.

<li>_(Issue INVALID-CHARACTER-SYNTAX): The invalid constituent characte trait is defined in the standard syntax for whitespace characters. The standard states (glossary and 2.1.4.3) that "Characters with the constituent trait invalid cannot ever appear in a token except under the control of a single escape character." However, the reader algorithm causes such characters to be treated as alphabetic if they are found inside multiple escape characters (so that the last case of step 9 of the reader algorithm never applies). Resolve this contradiction.

<li> :(CLHS BOUNDP) refers to "the function bound". It should be "the function boundp".

<li>_(Issue SOME): In contrast to the paragraphs on :(CLHS EVERY), :(CLHS NOTANY), and :(CLHS NOTEVERY) the detail that "some returns as soon as any invocation of predicate returns a non-nil value" is missing form the paragraph on :(CLHS SOME) in the _(CLHS). This probably doesn't give license to
an implementation to delay the return and process further elements, since a
few paragraphs higher up the text reads "until a termination criterion is met or the end of the shortest of the sequences is reached".

<li>_(Issue ADJOIN-KEY): The standard is inconsistent in its treatment of the KEY parameter to the :(CLHS ADJOIN) function. In the examples and notes, the key function is applied to the item being added, as it is in the related macro :(CLHS PUSHNEW). However, the page points to section 17.2.1, which states explicitly that the key function is never applied to the item being searched for. All implementations do the former, not the latter, so this is probably a spec bug.

<li>:(CLHS POP) states that the value of the place argument is "possibly, but necessarily, a dotted list or circular list". It should read "possibly, but not necessarily".

<li>Incomplete classes: :(CLHS DEFCLASS) states that for standard classes, "It is not required that the superclasses of a class be defined before the defclass form for that class is evaluated." Let's call such a class with a not-yet-defined superclass an "incomplete class". One can now argue whether an incomplete class is a class or not, i.e. if :(CLHS FIND-CLASS) is required to return it, given its name. <ul><li>Since :(CLHS DEFCLASS) says "defclass defines a new named class", an incomplete class should be considered as a class.</li> <li>CLHS 4.3.1 says that a class determines the structure of a set of objects. This is not true for incomplete classes, as they cannot be instantiated.</li> <li>CLHS 4.3.1 says that each class has a class precedence list. Incomplete classes don't, since the complete list of superclasses is unknown.</li> <li>CLHS 4.3.1 says that the class t is a superclass of every class except itself. So there should be a chain of direct-superclass relations from an incomplete class to t. But for incomplete classes for which all direct superclasses don't exist yet there is no such chain.</li></ul>

<li> :(CLHS WITH-PACKAGE-ITERATOR) doesn't specify behavior when no symbol-types is presented. It should be PROGRAM-ERROR. The spec seems clear to me: "with-package-iterator signals an error of type program-error if no symbol-types are supplied". How is this unspecified? --Nikodemus
</li>

<li> Issue UNLESS: Fix typo in :(CLHS "UNLESS") form action specifications to read "In an unless form, if the test-form yields false, the forms are evaluated in order from left to right and the values returned by the forms are returned from the unless form. Otherwise, if the test-form yields *true*, the forms are not evaluated, and the unless form returns nil."
</li>

<li> :(CLHS LOG) specifies two-argument logarithm in terms of division of two on-argument calls to :(CLHS log). There are two separate problems here; the first is trivial, in that the definition <code>(log base number) == (/ (log number) (log base))</code> has <tt>base</tt> and <tt>number</tt> inverted. The second is that this definition in conjunction with the Rule of Float Substitutability (:(CLHS 12.1.3.3)) will introduce intermediate single-floats into the computation of <tt>(log (fact 1000) 10d0)</tt>, leading to inaccuracy in the final result. Proposed resolution: clarify that the (corrected) definition of two-argument :(CLHS log) is for locating the branch cuts rather than for an explicit evaluation strategy.</li>

<li>Issue AREF-EXCEPTIONS: The page for :(CLHS AREF) says "Exceptional situations: none." It should specify that an error of class :(CLHS TYPE-ERROR) "should be" (1.4.2) signaled if the subscripts are out of bounds. This also applies to :(CLHS CHAR).</li>

<li>:(CLHS 2.3.1) says that float exponents are read �in the current input radix�. :(CLHS 22.1.3.1.3) says that float exponents are �printed as a decimal integer�. This would imply that floats are not readably printable under the condition that :(clhs *read-base*) is not 10. � _(Kevin Reid) thinks this ought to be revised to consistently use whichever radix is used by most existing CL implementations.</li>

</ul>

<h2>Proposed changes to the standard:</h2>

<ul>
<li>Un-deprecate :(CLHS "REMOVE-IF-NOT"), :(CLHS "DELETE-IF-NOT").

<li>_(Issue UNDEPRECATE-IF-NOT): Un-deprecate all *-if-not functions.

<li>_(Issue REMOVE-SET): Remove :(CLHS "SET") (already deprecated).

<li>_(Issue CONSTANTLY-MULTIPLE-VALUES): Extend :(CLHS "CONSTANTLY") to return multiple values if given other than 1 argument.

<li>_(Issue PRINT-OBJECT-RETURNS): The requirements that :(CLHS "PRINT-UNREADABLE-OBJECT") returns nil and that user-defined methods for :(CLHS "PRINT-OBJECT") must return the object don't fit well together. The example in :(CLHS "PRINT-UNREADABLE-OBJECT") demonstrates the problem: It is in error because it returns nil from :(CLHS "PRINT-OBJECT"), in the assumption that the return value of :(CLHS "PRINT-UNREADABLE-OBJECT") is usable as a return value of :(CLHS "PRINT-OBJECT"). It would be a simplification if returning nil from :(CLHS "PRINT-OBJECT") were allowed, or if :(CLHS "PRINT-UNREADABLE-OBJECT") were specified to return the object. (By contrast, :(CLHS "DESCRIBE-OBJECT") may return anything.)
The :REPORT option of :(CLHS "DEFINE-CONDITION") defines a method for :(CLHS "PRINT-OBJECT"), so the issue affects that too. In particular, (:REPORT "foo") defines a method that typically returns the string "foo", rather than the required condition object.

<li>_(Issue BOOLEAN-RETURNS): Many functions are specified to return true when they could just as easily return :(CLHS "T"). Since most (all?) implementations already return :(CLHS "T") for these functions, tighten the standard so this is required. Why would this be a good thing? <a href="http://clhs.lisp.se/Issues/iss235_w.htm">Issue MACROEXPAND-RETURN-VALUE</a> changed the language to the opposite direction.
(Actually, that issue just noted the inconsistency; the proposed solution there
would change the requirement to 'true'. Another possible solution would be to
change everything else to require T.) It would be a good thing because it would remove a gratuitous and unnecessary incompatibility between implementations, which would make it slightly easier to write portable programs. GCL ansi-tests would have been noticably easier to write had all the predicates returned :(CLHS "T") for true. -- Paul Dietz

<li>_(Issue NO-NEXT-METHOD): :(CLHS "NO-APPLICABLE-METHOD") is specified to be called/signalled only when there are no applicable methods. However, there is an error situation for built-in method combinations that is not covered by this: when there is no primary method. Specify an analogous NO-PRIMARY-METHOD generic-function/condition pair.

<li> _(Issue UNDEPRECATE-REQUIRE): [ may be contentious ] Undeprecate single-argument :(CLHS "require"), reflecting its continuing usage by Lisp implementors to load optional bolt-on modules that are supplied with the implementation. This is not supposed to be a means for the user to load his own or third-party libraries, for which a real DEFSYSTEM is a better solution. Note that a real DEFSYSTEM is outside the scope of this page. If cl:require is actually removed, implementations can still have ext:require, which doesn't seem too bad if the names of the modules are already not portable. Alternatively some parts of the REQUIRE mechanism might be specified -- eg. *REQUIRE-HOOK* or *REQUIRE-HOOKS*. You're right. REQUIRE should be removed and implementations that use it can have EXT:REQUIRE or something

<li>_(Issue TYPE-OF-BIGNUM): The definition of :(CLHS "TYPE-OF") implies that :(CLHS "BIGNUM") or :(CLHS "FIXNUM") cannot be the types returned (due to requirement 1 and the presence of :(CLHS "UNSIGNED-BYTE") in figure 4-2.) This was probably not intended. Fix this.

<li>_(Issue COMPILER-MACRO-IMPLICIT-BLOCK). Specify that :(CLHS DEFINE-COMPILER-MACRO) should establish an implicit block around the body.

<li>_(Issue SXHASH-NEGATIVE-ZERO): :(CLHS "SXHASH") and the file compiler are affected by a loose specification of similarity with respect to negative zeros. It would appear that an implementation is permitted to dump negative zeros as positive ones (and vice versa), to the extent that (defconstant foo 0.0) (defvar *bar* (eql foo foo)) need not return true; also, it requires (sxhash 0.0) to be equal to (sxhash -0.0) even though (equal 0.0 -0.0) is false. Specify that negative zeros are not similar to positive zeros.

<li>_(Issue IMAGPART-NEGATIVE-ZERO): The :(CLHS "IMAGPART") and :(CLHS "COMPLEX") functions are inconsistent in their treatment of objects of type (:(CLHS "REAL") * (0)): <tt>(complex -2.0)</tt> returns an object whose imaginary part is <tt>(coerce 0 'single-float)</tt>, while <tt>(imagpart -2.0)</tt> returns <tt>(* 0 -2.0)</tt>, which is different in implementations supporting negative zeros. This has ramifications in the treatment of branch cuts for real numbers.

<li>_(Issue FORMAT-VERBATIM): :(CLHS "FORMAT") should offer a directive that prints a string verbatim to the output stream, character by character, ignoring printer settings such as :(CLHS "*PRINT-CIRCLE*") and :(CLHS "*PRINT-LEVEL*"); i.e., one that corresponds to :(CLHS "WRITE-STRING") and not :(CLHS "PRINC") or :(CLHS "PRIN1").
The section on Formatted Output almost reads as if <tt>~A</tt> is supposed to ignore printer settings when printing strings ("If arg is a string, its characters will be output verbatim"); however, under this interpretation, <tt>~S</tt> will also ignore those variables when printing strings, since it's specified as "just like ~A, but arg is printed with escape characters", while it is clearly desirable to honor printer settings in <tt>~S</tt>. So, at least some clarification is needed here.
Consider the following code snippet.
<pre>(defparameter *separator* ",")

(defstruct foo (a 'a) (b 'b))

(defmethod print-object ((foo foo) stream)
  (print-unreadable-object (foo stream)
    (format stream "~A~A~A" (foo-a foo) *separator* (foo-b foo))))

(let ((*print-circle* t)) (print (list (make-foo) (make-foo))))
</pre>
The intended output is <tt>(#<a,b> #<a,b>)</tt>. However, in at least one CL implementation, the output will be <tt>(#<a#1=,b> #<a#1#b>)</tt>, i.e., the printer will detect the shared structure and use sharpsign notation instead of printing the string verbatim. [Side note: There's no way to tell for sure where the printed representation of the object the <tt>#1=</tt> refers to ends, so the output is not very useful.] It's hard to argue that this output is non-conforming because of the wording in the description of <tt>~S</tt>. So I don't think there's a way to write this <tt>print-object</tt> method without resorting to an explicit <tt>write-string</tt> (or <tt>copy-seq</tt>, but this will cons needlessly; or using a symbol, which is counter-intuitive). It's a pity <tt>format</tt> has this limitation.
Issue PRINC-READABLY seems to be related to this.

<li>_(Issue DEFCONSTANT-REDEFINE): Change the behavior of :(CLHS "DEFCONSTANT") so that it assigns a value to the given symbol only if that symbol is not already bound (much like :(CLHS "DEFVAR"))

I think that's a bad idea. DEFCONSTANT is only problematic for values that cannot be compared with EQL but only, for example, with EQUAL. This may lead to the situation that one wants to use, for example, constant strings, but everytime the respective DEFCONSTANT form is reevaluated an error is issued because two EQUAL strings are not necessarily EQL. Here is another proposal: Add a TEST keyword to DEFCONSTANT that allows programmers to specify how they intend to use the constant, i.e. under what equivalence semantics. In the case of string constants they can say, for example: (DEFCONSTANT +example+ "example" :test #'equal). The idea here is that this is a promise to the compiler that the rest of the program does not rely on the EQL identity of the value of +example+. In turn, if the value of +example+ is indeed changed to another value that is not EQUAL in a subsequent DEFCONSTANT form the compiler can issue a warning / error as before.

<li>_(Issue COMPILE-FILE-EXTENSIONS): Change :(CLHS "COMPILE-FILE") to allow implementation-defined keys (much like SBCL / CMUCL's use of :TRACE-FILE or LispWorks's :LOAD; I'm sure other implementations have similar extensions)

<li>_(Issue FORMAT-LOGICAL-BLOCK-PREFIX-SUFFIX): Allow <a href="http://www.lisp.org/HyperSpec/Body/sec_22-3-1-5.html">~~ (Tilde)</a> in the prefix and suffix segments of <a href="http://www.lisp.org/HyperSpec/Body/sec_22-3-5-2.html">~<...~:> (Logical Block)</a>. Currently, those segments cannot contain any format directives, so the corresponding output strings cannot contain tilde characters. It is not necessary to allow other directives (~%) or parameters (~V~, ~1~) to fix this.

<li>_(Issue CONDITIONS-NOT-EXTERNALIZABLE): Clarify the intention and interaction between :(CLHS MAKE-LOAD-FORM), that specifies primary methods on conditions to signal an error, and :(CLHS 3.2.4.4) that specifies that the file compiler uses MAKE-LOAD-FORM to externalize conditions. Taken togather with :(CLHS 11.1.2.1.2.19) this implies that given a portable program and a conforming implementation standardized conditions can never appear as externalized objects in compiled code, which probably was not the intention.

Options:
<ul>
<li>Clarify that standardized conditions cannot be externalized.
<li>Allowing (but not requiring) implementations to use something else then MAKE-LOAD-FORM to externalize standardized conditions.
<li>Allowing implementations to define methods on MAKE-LOAD-FORM for standard conditions that signal an error only if the real class of the condition is not a standardized condition.
</ul>

<li>_(Issue MAP-INTO-SAMPLE-DEFINITION): The notes section on :(CLHS MAP-INTO) section give an example of how it could be implemented; the example is incorrect in the way it handles the fill-pointer of result-sequence. MAP-INTO is specified to ignore the fill-pointer when deciding how many iterations to perform, and afterwards change it to the number of iterations performed.

<li>_(Issue KEYWORD-TYPE): :(CLHS "KEYWORD") and :(CLHS "KEYWORDP") are inconsistent (and the former is inconsistent with the glossary definition of 'keyword'.) A symbol is in the :(CLHS "KEYWORD") type if it is accessible in the package, but :(CLHS "KEYWORDP") is true if the symbol has the package named KEYWORD as its home package. The latter was probably intended. Fix this by either prohibiting importing (and shadow importing) of symbols into the keyword package, or force the home package of the symbol to be changed when this is done.

<li>_(Issue MAKE-CONDITION-ERROR): :(CLHS "MAKE-CONDITION") should be allowed to signal an error on <code>type</code> arguments that do not name classes, like <code>(or type-error program-error)</code>.</li>

<li>_(Issue PATHNAME-PRINT-READABLY): :(CLHS "NAMESTRING"), :(CLHS "PARSE-NAMESTRING"), :(CLHS "PATHNAME") et al use (in the examples sections) a readable syntax for printing pathnames: <code>#S(PATHNAME ...)</code>. It should be specified as such, instead of requiring <code>#P"..."</code> which is not always readable.</li>

<li> :(CLHS "PRINT-UNREADABLE-OBJECT")'s specification, if taken literally, requires that an ugly space be printed after the type description but before the closing bracket if type is true, identity is false, and the forms don't print anything. This may not have been intended; change so that the space is not printed in this situation (and the mirror case with identity being true.)

<li><a href="http://www.lisp.org/HyperSpec/Body/glo_s.html#single_escape">The glossary entry for "single escape"</a> includes this parenthetical comment: "In the standard readtable, slash is the only single escape." This should reference "backslash", not "slash".

<li>:(CLHS "ARITHMETIC-ERROR-OPERATION") is specified to return a function designator in Arguments and Values, but a list in Description. Those types are disjoint; presumably the description is wrong.

<li> Section 2.4.8.4 (Sharpsign Asterisk) states that an error of type :(CLHS READER-ERROR) is signaled if [...] "n is greater than one, but no bits were specified." This should be "n is greater than or equal to one, but no bits were specified."

<li>:(CLHS *PRINT-READABLY*) states that the printed form should be readable within the "standard readtable". This implies that the printed representation is not allowed to be expressed in terms of user-defined reader macros. Although it leads to "normalized" representations, it can be considered overly restrictive if the printed representation is only read in when the user-defined readtable is in effect (reading and writing become asymmetric). Proposal: remove the restriction on "standard readtable", but perhaps "encourage" users to give representations that work in the "standard readtable". <a href="http://groups.google.com/group/comp.lang.lisp/msg/a049a23dbc0c337b">c.l.l March 7, 2007</a>

<li>Section 23.1.2 (Effect of Readtable Case on the Lisp Reader) states: "When the readtable case is :invert, then if all of the unescaped letters in the extended token are of the same case, those (unescaped) letters are converted to the opposite case." The term "extended token" is not well defined, but presumably means the entire symbol token, including package name, separators, and symbol name. This has the (likely unintended) consequence that "common-lisp-user::Foo" references package "common-lisp-user" instead of "COMMON-LISP-USER". This should be amended to treat the package name and symbol name parts of the token separately. As a point of information, LispWorks 4.4.6 appears to be faithful to the standard, whereas CLisp 5.1 uses the proposed behavior.

<li>The dictionary entry for <a href="http://www.lispworks.com/reference/HyperSpec/Body/f_mapc_.htm">mapc and company</a> discusses 'result-type' in the text ("result-type specifies the type of the resulting sequence."), however none of these functions appear to implement the functionality of allowing the user to specify the result-type in the actual function specifications. It has been speculated that this is an erroneous copy and paste from the entry for map.</li>

<li><a
href="http://www.lisp.org/HyperSpec/Body/fun_complement.html">COMPLEMENT</a>
is specified to take a FUNCTION, while most other higher-order
operators in CL take designators for functions. (Additionally,
the Notes section for COMPLEMENT is incorrect, since APPLY takes
a function designator.) For similarity with the rest of the
language, COMPLEMENT should take a function designator.</li>

<li>:(CLHS "NCONC") has a few tiny bugs in its specification. First, it would be nicely specified as a right fold instead of a left fold, i.e. (nconc list-1 list-2 . lists) == (nconc list-1 (nconc list-2) . lists) instead of (nconc (nconc list-1 list-2) . lists) � an overly literal reading of the left-folding definition leads to quadratic evaluation time (though optimizations are possible). Second, the example (setq x '(a b c)) (setq y '(d e f)) (nconc x y) flies in the face of <a href="http://www.lispworks.com/documentation/HyperSpec/Body/03_ga.htm">Section 3.7.1 Modification of Literal Objects</a>.
As for me, I'd like to see a note somewhere that NCONC is very seldom a good idea, since its time complexity class is no better than APPEND, its space complexity class also is no better than APPEND in the common case where no one else is sharing the side-effected list, and its bug complexity class is way higher than APPEND. If the small enhancement factor due to APPEND vs NCONC is a limiting resource in your program, you have a big problem and are probably using the wrong data structure. I'd like to see the use of NCONC explicitly discouraged. If it weren't for legacy code that may rely on it, I would make the order or even existence of its side-effects made explicitly unspecified, so that APPEND be a valid implementation of NCONC.
</li>
</ul>

Please put outright extensions (not fixups) in _(Proposed Extensions To ANSI). 
<h2>Minor corrections to CLHS (errata)</h2>

Not clear if this is the right place for it, but minor (e.g. typographical) corrections to the CLHS:

<ul>
<li>Body/m_defcla.htm#defclass: replace "Form---a form. :init-form can be supplied once at most for a given slot." with "Form---a form. :initform can be supplied once at most for a given slot."</li>
<li>Body/f_reduce.htm#reduce: replace "If key is supplied, it is used is used to extract the values to reduce." with "If key is supplied, it is used to extract the values to reduce."
<li>Body/f_call_n.htm#call-next-method: replace "arg---an object." by "args---arguments to the method." (Just like "args" is described on the page Body/f_funcal.htm#funcall. (There it is "arguments to the function", of course.))
<li>Body/m_rst_ca.htm: Under "Examples": In "defun read-new-value" the format string is "Enter a new value: ". In the restart output it shows up as "Enter a new ice cream: ".
<li>Body/26_glo_s.htm#symbol_macro: replace "See the macro symbol-macrolet." with "See the special operator symbol-macrolet."
<li>In the description of :(CLHS "ROTATEF"): it seems that "read and written" should be "read and saved".</li>
<li>Body/m_w_out_.htm#with-output-to-string refers to "with-output-from-string" which presumably should be "with-output-to-string."</li>
<li>Body/f_pn_hos.htm: the second example of <tt>(pathname-directory (parse-namestring "/foo/bar/baz.lisp") :case :local)</tt> should probably be using :common instead of :local. Also, the ".*." in the VMS example is suspect and might be just a ".", and/or a :wild might be missing in the example result, but I'll let an expert opine.</li>
</ul>

<hr>
*(standards)

Please supply your name and a summary of changes for the Recent Changes page. If you are making a minor alteration to a page you recently edited, you can avoid making another Recent Changes entry by leaving the Summary box blank
Summary of changes:
Captcha (enter the word "lisp" here):
Your name:
Check this box to fill in your name automatically next time (uses a cookie)

Please note: other readers will see your changes immediately, but external search engines will continue to see the old version for another 24 hours. Spamming this site to improve your PageRank is therefore a particularly fruitless activity.

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively