This standard presents the syntax and semantics to be implemented by a conforming implementation (and its accompanying documentation). In addition, it imposes requirements on conforming programs.
A conforming implementation shall adhere to the requirements outlined in this section.
A conforming implementation shall accept all features (including deprecated features) of the language specified in this standard, with the meanings defined in this standard.
A 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.
A conforming implementation shall be accompanied by a document that provides a definition of all implementation-defined aspects of the language defined by this specification.
In addition, a conforming implementation is encouraged (but not required) to document items in this standard that are identified as implementation-dependent, although in some cases such documentation might simply identify the item as “undefined.”
A conforming implementation shall be accompanied by a document that separately describes any features accepted by the 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 Common Lisp as specified by ANSI.”
A conforming implementation shall treat exceptional situations in a manner consistent with this specification.
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.
Suppose that function
foo is a member of a set S of functions that operate on numbers. Suppose that one passage states that an error must be signaled if any function in S is ever given an argument of
17. Suppose that an apparently conflicting passage states that the consequences are undefined if
foo receives an argument of
17. Then the second passage (the one specifically about
foo) would dominate because the description of the situational context is the most specific, and it would not be required that
foo signal an error on an argument of
17 even though other functions in the set S would be required to do so.
A 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
“conforms with the requirements of ANSI ”
If the implementation conforms with some but not all of the requirements of this standard, then the conformance statement shall be
“conforms with the requirements of ANSI with the following exceptions: .”
Code conforming with the requirements of this standard shall adhere to the following:
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.
Conforming code may use 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 code.
Conforming code shall not depend on the consequences of undefined or unspecified situations.
Conforming code does not use any constructions that are prohibited by the standard.
Conforming code does not depend on extensions included in an implementation.
Note that conforming code may rely on particular implementation-defined values or features. Also note that the requirements for conforming code and conforming implementations do not require that the results produced by conforming code always be the same when processed by a conforming implementation. The results may be the same, or they may differ.
Conforming code may run in all conforming implementations, but might have allowable implementation-defined behavior that makes it non-portable code. For example, the following are examples of forms that are conforming, but that might return different values in different implementations:
(evenp most-positive-fixnum) → implementation-dependent (random) → implementation-dependent (> lambda-parameters-limit 93) → implementation-dependent (char-name #\A) → implementation-dependent
#- does not automatically disqualify a program from being conforming. A program which uses
#- is considered conforming if there is no set of features in which the program would not be conforming. Of course, conforming programs are not necessarily working programs. The following program is conforming:
(defun foo () #+ACME (acme:initialize-something) (print 'hello-there))
However, this program might or might not work, depending on whether the presence of the feature
ACME really implies that a function named
acme:initialize-something is present in the environment. In effect, using
#- in a conforming program means that the variable *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.
Portable code is written using only standard characters.