For clarifications and errata, see ANSI Clarifications and Errata.
- Un-deprecate REMOVE-IF-NOT, DELETE-IF-NOT.
- Issue UNDEPRECATE-IF-NOT: Un-deprecate all *-if-not functions.
- Issue REMOVE-SET: Remove SET (already deprecated).
- Issue CONSTANTLY-MULTIPLE-VALUES: Extend CONSTANTLY to return multiple values if given other than 1 argument.
- Issue PRINTING-SPACE: Change the behavior of character printing such that invisible graphic characters such as space can be printed by name. The ~:C format directive does this already.
-
Issue PRINT-OBJECT-RETURNS: The requirements that PRINT-UNREADABLE-OBJECT returns nil and that user-defined methods for PRINT-OBJECT must return the object don't fit well together. The example in PRINT-UNREADABLE-OBJECT demonstrates the problem: It is in error because it returns nil from PRINT-OBJECT, in the assumption that the return value of PRINT-UNREADABLE-OBJECT is usable as a return value of PRINT-OBJECT. It would be a simplification if returning nil from PRINT-OBJECT were allowed, or if PRINT-UNREADABLE-OBJECT were specified to return the object. (By contrast, DESCRIBE-OBJECT may return anything.)
The :REPORT option of DEFINE-CONDITION defines a method for 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.
- Issue BOOLEAN-RETURNS: Many functions are specified to return true when they could just as easily return T. Since most (all?) implementations already return T for these functions, tighten the standard so this is required. Why would this be a good thing? Issue MACROEXPAND-RETURN-VALUE 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 T for true. -- Paul Dietz
- Issue NO-NEXT-METHOD: 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.
- Issue UNDEPRECATE-REQUIRE: [ may be contentious ] Undeprecate single-argument 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
- Issue TYPE-OF-BIGNUM: The definition of TYPE-OF implies that BIGNUM or FIXNUM cannot be the types returned (due to requirement 1 and the presence of UNSIGNED-BYTE in figure 4-2.) This was probably not intended. Fix this.
- Issue COMPILER-MACRO-IMPLICIT-BLOCK. Specify that DEFINE-COMPILER-MACRO should establish an implicit block around the body.
- Issue SXHASH-NEGATIVE-ZERO: 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.
- Issue IMAGPART-NEGATIVE-ZERO: The IMAGPART and COMPLEX functions are inconsistent in their treatment of objects of type (REAL * (0)): (complex -2.0) returns an object whose imaginary part is (coerce 0 'single-float), while (imagpart -2.0) returns (* 0 -2.0), which is different in implementations supporting negative zeros. This has ramifications in the treatment of branch cuts for real numbers.
- Issue FORMAT-VERBATIM: FORMAT should offer a directive that prints a string verbatim to the output stream, character by character, ignoring printer settings such as *PRINT-CIRCLE* and *PRINT-LEVEL*; i.e., one that corresponds to WRITE-STRING and not PRINC or PRIN1. The section on Formatted Output almost reads as if ~A is supposed to ignore printer settings when printing strings ("If arg is a string, its characters will be output verbatim"); however, under this interpretation, ~S 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 ~S. So, at least some clarification is needed here. Consider the following code snippet.
(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))))
The intended output is (# #). However, in at least one CL implementation, the output will be (# #), 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 #1= 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 ~S. So I don't think there's a way to write this print-object method without resorting to an explicit write-string (or copy-seq, but this will cons needlessly; or using a symbol, which is counter-intuitive). It's a pity format has this limitation.
Issue PRINC-READABLY seems to be related to this.
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.
Options:
- Clarify that standardized conditions cannot be externalized.
- Allowing (but not requiring) implementations to use something else then MAKE-LOAD-FORM to externalize standardized conditions.
- 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.
type arguments that do not name classes, like (or type-error program-error).#S(PATHNAME ...). It should be specified as such, instead of requiring #P"..." which is not always readable.#. returns no values. The most popular answer, and arguably the most useful, is for nothing to be read, so that
> '(#.(values) foo) => (FOO)SBCL, Clozure CL, Allegro CL, and LispWorks all do this. It should accordingly be required by the standard.
Please put outright extensions (not fixups) in Proposed Extensions To ANSI.
standards