Skip to main content

1.5 Conformance

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.

1.5.1 Conforming Implementations​

A conforming implementation shall adhere to the requirements outlined in this section.

1.5.1.1 Required Language Features​

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.

1.5.1.2 Documentation of Implementation​

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.”

1.5.1.3 Documentation of Extensions​

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 ⟨standard number ⟩.”

1.5.1.4 Treatment of Exceptional Situations​

A conforming implementation shall treat exceptional situations in a manner consistent with this specification.

1.5.1.4.1 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.

1.5.1.4.1.1 Examples of Resolution of Apparent Conflicts in Exceptional Situations​
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.

1.5.1.5 Conformance Statement​

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

“⟨Implementation⟩ conforms with the requirements of ANSI ⟨standard number ⟩”

If the implementation conforms with some but not all of the requirements of this standard, then the conformance statement shall be

“⟨Implementation⟩ conforms with the requirements of ANSI ⟨standard number ⟩ with the following exceptions: ⟨reference to or complete list of the requirements of the standard with which the implementation does not conform⟩.”

1.5.2 Conforming Programs​

Code conforming with the requirements of this standard shall adhere to the following:

1. 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.

2. 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.

3. Conforming code shall not depend on the consequences of undefined or unspecified situations.

4. Conforming code does not use any constructions that are prohibited by the standard. 5. Conforming code does not depend on extensions included in an implementation.

1.5.2.1 Use of 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

1.5.2.1.1 Use of Read​

Use of #+ and #- does not automatically disqualify a program from being conforming. A program which uses #+ and #- 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 #+ or #- 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.

1.5.2.2 Character Set for Portable Code​

Portable code is written using only standard characters.