This section describes the packages that are available in every conforming implementation. A summary of the names and nicknames of those standardized packages is given in the next figure.
|
Figure 11.2: Standardized Package Names
The COMMON-LISP
package contains the primitives of the Common Lisp system as
defined by this specification. Its external symbols include
all of the defined names (except for defined names in
the KEYWORD
package) that are present in the Common Lisp system,
such as car
, cdr
, *package*
, etc.
The COMMON-LISP
package has the nickname CL
.
The COMMON-LISP
package has as external symbols those
symbols enumerated in the figures in Section 1.9 (Symbols in the COMMON-LISP Package), and no others.
These external symbols are present in the COMMON-LISP
package
but their home package need not be the COMMON-LISP
package.
For example, the symbol HELP
cannot be an external symbol of
the COMMON-LISP
package because it is not mentioned in Section 1.9 (Symbols in the COMMON-LISP Package).
In contrast, the symbol variable
must be an external symbol of the COMMON-LISP
package
even though it has no definition
because it is listed in that section
(to support its use as a valid second argument to the function documentation
).
The COMMON-LISP
package can have additional internal symbols.
In a conforming implementation,
an external symbol of the COMMON-LISP
package can have
a function, macro, or special operator definition,
a global variable definition
(or other status as a dynamic variable
due to a special
proclamation),
or a type definition
only if explicitly permitted in this standard.
For example,
fboundp
yields false
for any external symbol of the COMMON-LISP
package
that is not the name of a standardized
function, macro or special operator,
and
boundp
returns false
for any external symbol of the COMMON-LISP
package
that is not the name of a standardized global variable.
It also follows that
conforming programs can use external symbols of the COMMON-LISP
package
as the names of local lexical variables
with confidence that those names have not been proclaimed special
by the implementation
unless those symbols are
names of standardized global variables.
A conforming implementation must not place any property on
an external symbol of the COMMON-LISP
package using a property indicator
that is either an external symbol of any standardized package
or a symbol that is otherwise accessible in the COMMON-LISP-USER
package.
Except where explicitly allowed, the consequences are undefined if any
of the following actions are performed on an external symbol
of the COMMON-LISP
package:
defstruct
,
defclass
,
deftype
,
define-condition
).
defstruct
).
declaration
proclamation.
trace
).
special
(via declare,
declaim
,
or proclaim
).
type
or ftype
(via declare,
declaim
,
or proclaim
).
(Some exceptions are noted below.)
COMMON-LISP
package.
defsetf
or define-setf-method
).
define-method-combination
).
setf
of find-class
.
If an external symbol of the COMMON-LISP
package
is not globally defined as a standardized dynamic variable
or constant variable,
it is allowed to lexically bind it
and to declare the type
of that binding,
and
it is allowed to locally establish it as a symbol macro
(e.g., with symbol-macrolet
).
Unless explicitly specified otherwise,
if an external symbol of the COMMON-LISP
package
is globally defined as a standardized dynamic variable,
it is permitted to bind or assign that dynamic variable
provided that the “Value Type” constraints on the dynamic variable
are maintained, and that the new value of the variable
is consistent with the stated purpose of the variable.
If an external symbol of the COMMON-LISP
package is not defined
as a standardized function, macro, or special operator,
it is allowed to lexically bind it as a function (e.g., with flet
),
to declare the ftype
of that binding,
and
(in implementations which provide the ability to do so)
to trace
that binding.
If an external symbol of the COMMON-LISP
package is not defined
as a standardized function, macro, or special operator,
it is allowed to lexically bind it as a macro (e.g., with macrolet
).
If an external symbol of the COMMON-LISP
package is not defined
as a standardized function, macro, or special operator,
it is allowed to lexically bind its setf function name
as a function,
and to declare the ftype
of that binding.
The COMMON-LISP-USER
package is the current package when
a Common Lisp system starts up. This package uses the COMMON-LISP
package.
The COMMON-LISP-USER
package has the nickname CL-USER
.
The COMMON-LISP-USER
package can have additional symbols interned within it;
it can use other implementation-defined packages.
The KEYWORD
package contains symbols, called keywords1,
that are typically used as special markers in programs
and their associated data expressions1.
Symbol tokens that start with a package marker
are parsed by the Lisp reader as symbols
in the KEYWORD
package; see Section 2.3.4 (Symbols as Tokens).
This makes it notationally convenient to use keywords
when communicating between programs in different packages.
For example, the mechanism for passing keyword parameters in a call uses
keywords1 to name the corresponding arguments;
see Section 3.4.1 (Ordinary Lambda Lists).
Symbols in the KEYWORD
package are, by definition, of type keyword
.
The KEYWORD
package is treated differently than other packages
in that special actions are taken when a symbol is interned in it.
In particular, when a symbol is interned in the KEYWORD
package,
it is automatically made to be an external symbol
and is automatically made to be a constant variable with itself as a value.
It is generally best to confine the use of keywords to situations in which there are a finitely enumerable set of names to be selected between. For example, if there were two states of a light switch, they might be called :on and :off.
In situations where the set of names is not finitely enumerable
(i.e., where name conflicts might arise)
it is frequently best to use symbols in some package
other than KEYWORD
so that conflicts will be naturally avoided.
For example, it is generally not wise for a program to use a keyword1
as a property indicator, since if there were ever another program that did the same thing, each would clobber the other's data.
Other, implementation-defined packages might be present in the initial Common Lisp environment.
It is recommended, but not required, that the documentation for a
conforming implementation contain a full list of all package names
initially present in that implementation but not specified in this specification.
(See also the function list-all-packages
.)