gcl.info-3

This is Info file gcl.info, produced by Makeinfo-1.55 from the input file
gcl.texi.

This is a Texinfo GNU Common Lisp Manual based on the draft ANSI standard
for Common Lisp.

Copyright 1994 William F. Schelter


File: gcl.info,  Node: The ``Class Precedence List'' Section of a Dictionary Entry,  Next: Dictionary Entries for Type Specifiers,  Prev: The ``Binding Types Affected'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Class Precedence List" Section of a Dictionary Entry
.........................................................

This appears in the dictionary entry for a class, and contains an ordered
list of the classes defined by Common Lisp that must be in the class
precedence list of this class.

It is permissible for other (implementation-defined) classes to appear in
the implementation's class precedence list for the class.

It is permissible for either standard-object or structure-object to appear
in the implementation's class precedence list; for details, see *Note Type
Relationships::.

Except as explicitly indicated otherwise somewhere in this specification,
no additional standardized classes may appear in the implementation's
class precedence list.

By definition of the relationship between classes and types, the classes
listed in this section are also supertypes of the type denoted by the
class.


File: gcl.info,  Node: Dictionary Entries for Type Specifiers,  Next: The ``Compound Type Specifier Kind'' Section of a Dictionary Entry,  Prev: The ``Class Precedence List'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

Dictionary Entries for Type Specifiers
......................................

The atomic type specifiers are those defined names listed in Figure~4-2.
Such dictionary entries are of kind "Class," "Condition Type," "System
Class," or "Type." A description of how to interpret a symbol naming one
of these types or classes as an atomic type specifier is found in the
"Description" section of such dictionary entries.

The compound type specifiers are those defined names listed in Figure~4-3.
Such dictionary entries are of kind "Class," "System Class," "Type," or
"Type Specifier." A description of how to interpret as a compound type
specifier a list whose car is such a 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.


File: gcl.info,  Node: The ``Compound Type Specifier Kind'' Section of a Dictionary Entry,  Next: The ``Compound Type Specifier Syntax'' Section of a Dictionary Entry,  Prev: Dictionary Entries for Type Specifiers,  Up: Interpreting Dictionary Entries

The "Compound Type Specifier Kind" Section of a Dictionary Entry
................................................................

An "abbreviating" type specifier is one that describes a subtype for which
it is in principle possible to enumerate the elements, but for which in
practice it is impractical to do so.

A "specializing" type specifier is one that describes a subtype by
restricting the type of one or more components of the type, such as
element type or complex part type.

A "predicating" type specifier is one that describes a subtype containing
only those objects that satisfy a given predicate.

A "combining" type specifier is one that describes a subtype in a
compositional way, using combining operations (such as "and," "or," and
"not") on other types.


File: gcl.info,  Node: The ``Compound Type Specifier Syntax'' Section of a Dictionary Entry,  Next: The ``Compound Type Specifier Arguments'' Section of a Dictionary Entry,  Prev: The ``Compound Type Specifier Kind'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Compound Type Specifier Syntax" Section of a Dictionary Entry
..................................................................

This information about a type describes the syntax of a compound type
specifier for that type.

Whether or not the type is acceptable as an atomic type specifier is not
represented here; see *Note Dictionary Entries for Type Specifiers::.


File: gcl.info,  Node: The ``Compound Type Specifier Arguments'' Section of a Dictionary Entry,  Next: The ``Compound Type Specifier Description'' Section of a Dictionary Entry,  Prev: The ``Compound Type Specifier Syntax'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Compound Type Specifier Arguments" Section of a Dictionary Entry
.....................................................................

This information describes type information for the structures defined in
the "Compound Type Specifier Syntax" section.


File: gcl.info,  Node: The ``Compound Type Specifier Description'' Section of a Dictionary Entry,  Next: The ``Constant Value'' Section of a Dictionary Entry,  Prev: The ``Compound Type Specifier Arguments'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

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.


File: gcl.info,  Node: The ``Constant Value'' Section of a Dictionary Entry,  Next: The ``Description'' Section of a Dictionary Entry,  Prev: The ``Compound Type Specifier Description'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Constant Value" Section of a Dictionary Entry
..................................................

This information describes the unchanging type and value of a constant
variable.


File: gcl.info,  Node: The ``Description'' Section of a Dictionary Entry,  Next: The ``Examples'' Section of a Dictionary Entry,  Prev: The ``Constant Value'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Description" Section of a Dictionary Entry
...............................................

A summary of the operator and all intended aspects of the operator, but
does not necessarily include all the fields referenced below it ("Side
Effects," "Exceptional Situations," etc.)


File: gcl.info,  Node: The ``Examples'' Section of a Dictionary Entry,  Next: The ``Exceptional Situations'' Section of a Dictionary Entry,  Prev: The ``Description'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Examples" Section of a Dictionary Entry
............................................

Examples of use of the operator.  These examples are not considered part
of the standard; see *Note Sections Not Formally Part Of This Standard::.


File: gcl.info,  Node: The ``Exceptional Situations'' Section of a Dictionary Entry,  Next: The ``Initial Value'' Section of a Dictionary Entry,  Prev: The ``Examples'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Exceptional Situations" Section of a Dictionary Entry
..........................................................

Three kinds of information may appear here:
*
     Situations that are detected by the function and formally signaled.

*
     Situations that are handled by the function.

*
     Situations that may be detected by the function.

This field does not include conditions that could be signaled by functions
passed to and called by this operator as arguments or through dynamic
variables, nor by executing subforms of this operator if it is a macro or
special operator.


File: gcl.info,  Node: The ``Initial Value'' Section of a Dictionary Entry,  Next: The ``Argument Precedence Order'' Section of a Dictionary Entry,  Prev: The ``Exceptional Situations'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Initial Value" Section of a Dictionary Entry
.................................................

This information describes the initial value of a dynamic variable.  Since
this variable might change, see type restrictions in the "Value Type"
section.


File: gcl.info,  Node: The ``Argument Precedence Order'' Section of a Dictionary Entry,  Next: The ``Method Signature'' Section of a Dictionary Entry,  Prev: The ``Initial Value'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Argument Precedence Order" Section of a Dictionary Entry
.............................................................

This information describes the argument precedence order.  If it is
omitted, the argument precedence order is the default (left to right).


File: gcl.info,  Node: The ``Method Signature'' Section of a Dictionary Entry,  Next: The ``Name'' Section of a Dictionary Entry,  Prev: The ``Argument Precedence Order'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Method Signature" Section of a Dictionary Entry
....................................................

The description of a generic function includes descriptions of the methods
that are defined on that generic function by the standard.  A method
signature is used to describe the parameters and parameter specializers
for each method.  Methods defined for the generic function must be of the
form described by the method signature.

`F'  (x class) (y t) &optional z &key k

This signature indicates that this method on the generic function F has
two required parameters: x, which must be a generalized instance of the
class class; and y, which can  be any object (i.e., a generalized instance
of the class t).  In addition, there is an optional parameter z and a
keyword parameter k.  This signature also indicates that this method on F
is a primary method and has no qualifiers.

For each parameter, the argument supplied must be in the intersection of
the type specified in the description of the corresponding generic
function and the type given in the signature of some method (including not
only those methods defined in this specification, but also
implementation-defined or user-defined methods in situations where the
definition of such methods is permitted).


File: gcl.info,  Node: The ``Name'' Section of a Dictionary Entry,  Next: The ``Notes'' Section of a Dictionary Entry,  Prev: The ``Method Signature'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

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 defined name appears; if more than one defined
name is to be described by the entry, all such 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:

Accessor
     This is an accessor function.

Class
     This is a class.

Condition Type
     This is a subtype of type condition.

Constant Variable
     This is a constant variable.

Declaration
     This is a declaration identifier.

Function
     This is a function.

Local Function
     This is a function that is defined only lexically within the scope of
     some other macro form.

Local Macro
     This is a macro that is defined only lexically within the scope of
     some other macro form.

Macro
     This is a macro.

Restart
     This is a restart.

Special Operator
     This is a special operator.

Standard Generic Function
     This is a standard generic function.

Symbol
     This is a symbol that is specially recognized in some particular
     situation, such as the syntax of a macro.

System Class
     This is like class, but it identifies a class that is potentially a
     built-in class.  (No class is actually required to be a built-in
     class.)

Type
     This is an atomic type specifier, and depending on information for
     each particular entry, may subject to form other type specifiers.

Type Specifier
     This is a defined name that is not an atomic type specifier, but that
     can be used in constructing valid type specifiers.

Variable
     This is a dynamic variable.


File: gcl.info,  Node: The ``Notes'' Section of a Dictionary Entry,  Next: The ``Pronunciation'' Section of a Dictionary Entry,  Prev: The ``Name'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Notes" Section of a Dictionary Entry
.........................................

Information not found elsewhere in this description which pertains to this
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 conforming implementation or conforming program is permitted to ignore
the presence of this information.


File: gcl.info,  Node: The ``Pronunciation'' Section of a Dictionary Entry,  Next: The ``See Also'' Section of a Dictionary Entry,  Prev: The ``Notes'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Pronunciation" Section of a Dictionary Entry
.................................................

This offers a suggested pronunciation for 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.  For brevity,
it is only provided for entries with names that are specific to Common
Lisp and would not be found in Webster's Third New International Dictionary
the English Language, Unabridged.


File: gcl.info,  Node: The ``See Also'' Section of a Dictionary Entry,  Next: The ``Side Effects'' Section of a Dictionary Entry,  Prev: The ``Pronunciation'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "See Also" Section of a Dictionary Entry
............................................

List of references to other parts of this standard that offer information
relevant to this operator.  This list is not part of the standard.


File: gcl.info,  Node: The ``Side Effects'' Section of a Dictionary Entry,  Next: The ``Supertypes'' Section of a Dictionary Entry,  Prev: The ``See Also'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Side Effects" Section of a Dictionary Entry
................................................

Anything that is changed as a result of the evaluation of the form
containing this operator.


File: gcl.info,  Node: The ``Supertypes'' Section of a Dictionary Entry,  Next: The ``Syntax'' Section of a Dictionary Entry,  Prev: The ``Side Effects'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Supertypes" Section of a Dictionary Entry
..............................................

This appears in the dictionary entry for a type, and contains a list of
the standardized types that must be supertypes of this type.

In implementations where there is a corresponding class, the order of the
classes in the class precedence list is consistent with the order
presented in this section.


File: gcl.info,  Node: The ``Syntax'' Section of a Dictionary Entry,  Next: Special ``Syntax'' Notations for Overloaded Operators,  Prev: The ``Supertypes'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Syntax" Section of a Dictionary Entry
..........................................

This section describes how to use the defined name in code.  The "Syntax"
description for a generic function describes the lambda list of the
generic function itself, while the "Method Signatures" describe the lambda
lists of the defined methods.  The "Syntax" description for an ordinary
function, a macro, or a special operator describes its parameters.

For example, an operator description might say:

`F'  x y &optional z &key k

This description indicates that the function F has two required
parameters, x and y.  In addition, there is an optional parameter z and a
keyword parameter k.

For macros and special operators, syntax is given in modified BNF
notation; see *Note Modified BNF Syntax::.  For functions a lambda list is
given.  In both cases, however, the outermost parentheses are omitted, and
default value information is omitted.


File: gcl.info,  Node: Special ``Syntax'' Notations for Overloaded Operators,  Next: Naming Conventions for Rest Parameters,  Prev: The ``Syntax'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

Special "Syntax" Notations for Overloaded Operators
...................................................

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:

`file-position'  stream =>  position

`file-position'  stream position-spec =>  success-p

is operationally equivalent to this line:

`file-position'  stream &optional position-spec =>  result

and differs only in that it provides on opportunity to introduce different
names for parameter and values for each case.  The separated (multi-line)
notation is used when an operator is overloaded in such a way that the
parameters are used in different ways depending on how many arguments are
supplied (e.g., for the function /) or the return values are different in
the two cases (e.g., for the function file-position).


File: gcl.info,  Node: Naming Conventions for Rest Parameters,  Next: Requiring Non-Null Rest Parameters in the ``Syntax'' Section,  Prev: Special ``Syntax'' Notations for Overloaded Operators,  Up: Interpreting Dictionary Entries

Naming Conventions for Rest Parameters
......................................

Within this specification, if the name of a rest parameter is chosen to be
a plural noun, use of that name in parameter font refers to the list to
which the rest parameter is bound.  Use of the singular form of that name
in parameter font refers to an element of that list.

For example, given a syntax description such as:

`F'  &rest arguments

it is appropriate to refer either to the rest parameter named arguments by
name, or to one of its elements by speaking of "an argument," "some
argument," "each argument" etc.


File: gcl.info,  Node: Requiring Non-Null Rest Parameters in the ``Syntax'' Section,  Next: Return values in the ``Syntax'' Section,  Prev: Naming Conventions for Rest Parameters,  Up: Interpreting Dictionary Entries

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 rest parameter while at the same time requiring at
least one argument.  A variety of imperative and declarative means are
available in code for expressing such a restriction, however they
generally do not manifest themselves in a lambda list.  For descriptive
purposes within this specification,

`F'  &rest arguments^+

means the same as

`F'  &rest arguments

but introduces the additional requirement that there be at least one
argument.


File: gcl.info,  Node: Return values in the ``Syntax'' Section,  Next: No Arguments or Values in the ``Syntax'' Section,  Prev: Requiring Non-Null Rest Parameters in the ``Syntax'' Section,  Up: Interpreting Dictionary Entries

Return values in the "Syntax" Section
.....................................

An evaluation arrow "=> " precedes a list of values to be returned.  For
example:

`F'  a b c =>  x

indicates that F is an operator that has three required parameters (i.e.,
a, b, and c) and that returns one value (i.e., x).  If more than one value
is returned by an operator, the names of the values are separated by
commas, as in:

`F'  a b c =>  x, y, z


File: gcl.info,  Node: No Arguments or Values in the ``Syntax'' Section,  Next: Unconditional Transfer of Control in the ``Syntax'' Section,  Prev: Return values in the ``Syntax'' Section,  Up: Interpreting Dictionary Entries

No Arguments or Values in the "Syntax" Section
..............................................

If no arguments are permitted, or no values are returned, a special
notation is used to make this more visually apparent.  For example,

`F'  <no arguments> =>  <no values>

indicates that F is an operator that accepts no arguments and returns no
values.


File: gcl.info,  Node: Unconditional Transfer of Control in the ``Syntax'' Section,  Next: The ``Valid Context'' Section of a Dictionary Entry,  Prev: No Arguments or Values in the ``Syntax'' Section,  Up: Interpreting Dictionary Entries

Unconditional Transfer of Control in the "Syntax" Section
.........................................................

Some operators perform an unconditional transfer of control, and so never
have any return values.  Such operators are notated using a notation such
as the following:

`F'  a b c =>  #<NoValue>


File: gcl.info,  Node: The ``Valid Context'' Section of a Dictionary Entry,  Next: The ``Value Type'' Section of a Dictionary Entry,  Prev: Unconditional Transfer of Control in the ``Syntax'' Section,  Up: Interpreting Dictionary Entries

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 declaration (i.e., a declare
expression), a proclamation (i.e., a declaim or proclaim form), or both.


File: gcl.info,  Node: The ``Value Type'' Section of a Dictionary Entry,  Prev: The ``Valid Context'' Section of a Dictionary Entry,  Up: Interpreting Dictionary Entries

The "Value Type" Section of a Dictionary Entry
..............................................

This information describes any type restrictions on a dynamic variable.


File: gcl.info,  Node: Conformance,  Next: Language Extensions,  Prev: Definitions,  Up: Introduction (Introduction)

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.

* Menu:

* Conforming Implementations::
* Conforming Programs::


File: gcl.info,  Node: Conforming Implementations,  Next: Conforming Programs,  Prev: Conformance,  Up: Conformance

Conforming Implementations
--------------------------

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

* Menu:

* Required Language Features::
* Documentation of Implementation-Dependent Features::
* Documentation of Extensions::
* Treatment of Exceptional Situations::
* Resolution of Apparent Conflicts in Exceptional Situations::
* Examples of Resolution of Apparent Conflict in Exceptional Situations::
* Conformance Statement::


File: gcl.info,  Node: Required Language Features,  Next: Documentation of Implementation-Dependent Features,  Prev: Conforming Implementations,  Up: Conforming Implementations

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.


File: gcl.info,  Node: Documentation of Implementation-Dependent Features,  Next: Documentation of Extensions,  Prev: Required Language Features,  Up: Conforming Implementations

Documentation of Implementation-Dependent Features
..................................................

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


File: gcl.info,  Node: Documentation of Extensions,  Next: Treatment of Exceptional Situations,  Prev: Documentation of Implementation-Dependent Features,  Up: Conforming Implementations

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


File: gcl.info,  Node: Treatment of Exceptional Situations,  Next: Resolution of Apparent Conflicts in Exceptional Situations,  Prev: Documentation of Extensions,  Up: Conforming Implementations

Treatment of Exceptional Situations
...................................

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


File: gcl.info,  Node: Resolution of Apparent Conflicts in Exceptional Situations,  Next: Examples of Resolution of Apparent Conflict in Exceptional Situations,  Prev: Treatment of Exceptional Situations,  Up: Conforming Implementations

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.


File: gcl.info,  Node: Examples of Resolution of Apparent Conflict in Exceptional Situations,  Next: Conformance Statement,  Prev: Resolution of Apparent Conflicts in Exceptional Situations,  Up: Conforming Implementations

Examples of Resolution of Apparent Conflict 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.


File: gcl.info,  Node: Conformance Statement,  Prev: Examples of Resolution of Apparent Conflict in Exceptional Situations,  Up: Conforming Implementations

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


File: gcl.info,  Node: Conforming Programs,  Prev: Conforming Implementations,  Up: Conformance

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 shall not rely on any particular interpretation of
     implementation-dependent features.

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.

* Menu:

* Use of Implementation-Defined Language Features::
* Use of Read-Time Conditionals::


File: gcl.info,  Node: Use of Implementation-Defined Language Features,  Next: Use of Read-Time Conditionals,  Prev: Conforming Programs,  Up: Conforming Programs

Use of Implementation-Defined Language Features
...............................................

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.

Portable code is written using only standard characters.

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


File: gcl.info,  Node: Use of Read-Time Conditionals,  Prev: Use of Implementation-Defined Language Features,  Up: Conforming Programs

Use of Read-Time Conditionals
.............................

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.


File: gcl.info,  Node: Language Extensions,  Next: Language Subsets,  Prev: Conformance,  Up: Introduction (Introduction)

Language Extensions
===================

A language extension is any documented implementation-defined behavior of
a 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 Note by 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.

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.
Extra return values
     An implementation must return exactly the number of return values
     specified by this standard unless the standard specifically indicates
     otherwise.

Unsolicited messages
     No output can be produced by a function other than that specified in
     the standard or due to the signaling of conditions detected by the
     function.

     Unsolicited output, such as garbage collection notifications and
     autoload heralds, should not go directly to the stream that is the
     value of a stream variable defined in this standard, but can go
     indirectly to terminal I/O by using a synonym stream to *terminal-io*.

     Progress reports from such functions as load and compile are
     considered solicited, and are not covered by this prohibition.

Implementation of macros and special forms
     Macros and special operators defined in this standard must not be
     functions.


File: gcl.info,  Node: Language Subsets,  Next: Deprecated Language Features,  Prev: Language Extensions,  Up: Introduction (Introduction)

Language Subsets
================

The language described in this standard contains no subsets, though
subsets are not forbidden.

For a language to be considered a subset, it must have the property that
any valid program in that language has equivalent semantics and will run
directly (with no extralingual pre-processing, and no special
compatibility packages) in any conforming implementation of the full
language.

A language that conforms to this requirement shall be described as being a
"subset of Common Lisp as specified by ANSI <<standard number>>."


File: gcl.info,  Node: Deprecated Language Features,  Next: Symbols in the COMMON-LISP Package,  Prev: Language Subsets,  Up: Introduction (Introduction)

Deprecated Language Features
============================

Deprecated language features are not expected to appear in future Common
Lisp standards, but are required to be implemented for conformance with
this standard; see *Note Required Language Features::.

Conforming programs can use deprecated features; however, it is considered
good programming style to avoid them.  It is permissible for the compiler
to produce style warnings about the use of such features at compile time,
but there should be no such warnings at program execution time.

* Menu:

* Deprecated Functions::
* Deprecated Argument Conventions::
* Deprecated Variables::
* Deprecated Reader Syntax::


File: gcl.info,  Node: Deprecated Functions,  Next: Deprecated Argument Conventions,  Prev: Deprecated Language Features,  Up: Deprecated Language Features

Deprecated Functions
--------------------

The functions in Figure 1-2 are deprecated.
  assoc-if-not   nsubst-if-not       require            
  count-if-not   nsubstitute-if-not  set                
  delete-if-not  position-if-not     subst-if-not       
  find-if-not    provide             substitute-if-not  
  gentemp        rassoc-if-not                          
  member-if-not  remove-if-not                          

            Figure 1-2: Deprecated Functions           



File: gcl.info,  Node: Deprecated Argument Conventions,  Next: Deprecated Variables,  Prev: Deprecated Functions,  Up: Deprecated Language Features

Deprecated Argument Conventions
-------------------------------

The ability to pass a numeric argument to gensym has been deprecated.

The :test-not argument to the functions in Figure 1-3 are deprecated.

  adjoin             nset-difference    search            
  assoc              nset-exclusive-or  set-difference    
  count              nsublis            set-exclusive-or  
  delete             nsubst             sublis            
  delete-duplicates  nsubstitute        subsetp           
  find               nunion             subst             
  intersection       position           substitute        
  member             rassoc             tree-equal        
  mismatch           remove             union             
  nintersection      remove-duplicates                    

  Figure 1-3: Functions with Deprecated :TEST-NOT Arguments


The use of the situation names compile, load, and eval in eval-when is
deprecated.


File: gcl.info,  Node: Deprecated Variables,  Next: Deprecated Reader Syntax,  Prev: Deprecated Argument Conventions,  Up: Deprecated Language Features

Deprecated Variables
--------------------

The variable *modules* is deprecated.


File: gcl.info,  Node: Deprecated Reader Syntax,  Prev: Deprecated Variables,  Up: Deprecated Language Features

Deprecated Reader Syntax
------------------------

The #S reader macro forces keyword names into the KEYWORD package; see
*Note Sharpsign S::.  This feature is deprecated; in the future, keyword
names will be taken in the package they are read in, so symbols that are
actually in the KEYWORD package should be used if that is what is desired.