!!! Barmar: Tell me why multiple packags are needed. e.g., to prevent variable and function conflicts.
*package*. When using the Lisp reader, it is possible to refer to symbols in packages other than the current one through the use of package prefixes in the printed representation of the symbol.
11.2.0 5The next figure lists some defined names that are applicable to packages. Shouldn't be needed. This info is all explicit now. -kmp 29-Apr-91
For the \term{operators} listed here, all optional arguments named
\param{package} default to the \term{current package}.Where an operator takes an argument that is either a symbol or a list of symbols, an argument of nil is treated as an empty list of symbols. Any package argument may be either a string, a symbol, or a package. If a symbol is supplied, its name will be used as the package name. \funref{provide}, \funref{require}, and \varref{*modules*} will
be removed from this table (and the language).
PROVIDE and REQUIRE need to be removed, right? -kmp 29-Apr-91
Nope! -kmp 13-Feb-92
Figure 11–1. Some Defined Names related to Packages
11.0.0 20There is a single namespace for packages. The function find-package translates a package name or nickname into the associated package. The function package-name returns the name of a package. The function package-nicknames returns a list of all nicknames for a package. rename-package removes a package's current name and nicknames and replaces them with new ones specified by the caller.
11.0.0 7A symbol has the same name no matter what package it is present in, but it might be an external symbol of some packages and an internal symbol of others.
use-package. A symbol is said to be present in a package if the mapping is in the package itself and is not inherited from somewhere else.
11.4.0There is no way to inherit the internal symbols of another package; to refer to an internal symbol using the Lisp reader, a package containing the symbol must be made to be the current package, a package prefix must be used, or the symbol must be imported into the current package.
use-package.
If a symbol is accessible in a package, it can be referred to when using the Lisp reader without a package prefix when that package is the current package, regardless of whether it is present or inherited.
???Move the following to \secref\Syntax??? A \term{symbol} will not necessarily always have the same printed representation because the way \term{symbols} are printed depends on whether or not they are \term{accessible} in the \term{current package}.
11.0.0 35Symbols from one package can be made accessible in another package in two ways.
11.0.0 36
import. After the call to import the symbol is present in the importing package. The status of the symbol in the package it came from (if any) is unchanged, and the home package for this symbol is unchanged. Once imported, a symbol is present in the importing package and can be removed only by calling unintern.
11.4.0 4A symbol is shadowed3 by another symbol in some package if the first symbol would be accessible by inheritance if not for the presence of the second symbol. See shadowing-import.
11.4.0 39 11.4.0 40
use-package. All of the external symbols of the used package are inherited by the using package. The function unuse-package undoes the effects of a previous use-package.
The following rules apply to name conflicts: 11.0.0 47
string=).
11.0.0 48
import). See shadow and shadowing-import.
11.0.0 50
use-package, import, and export check for name conflicts.
11.0.0 52
shadow and shadowing-import never signal a name-conflict error.
11.0.0 53
unuse-package and unexport do not need to do any name-conflict checking. unintern does name-conflict checking only when a symbol being uninterned is a shadowing symbol.
11.0.0 54
unintern can uncover a name conflict that had previously been resolved by the shadowing.
11.0.0 55 \itemitem{--} Aborting from a name-conflict error leaves the original \term{symbol} \term{accessible}.
package-error before making any change to the package structure. When multiple changes are to be made, it is permissible for the implementation to process each change separately. For example, when export is given a list of symbols, aborting from a name conflict caused by the second symbol in the list might still export the first symbol in the list. However, a name-conflict error caused by export of a single symbol will be signaled before that symbol's accessibility in any package is changed.
11.0.0 56
shadowing-import, unintern, !!! Barmar: The next two bullets don't mention "unexport".or unexport.
11.0.0 57
use-package between a symbol directlypresent in the using package and an external symbol of the used package is resolved in favor of the first symbol by making it a shadowing symbol, or in favor of the second symbol by uninterning the first symbol from the using package.
11.0.0 60
export or unintern due to a package's inheriting two distinct symbols with the same name (under string=) from two other packages can be resolved in favor of either symbol by importing it into the using package and making it a shadowing symbol, just as with use-package.
| Name | Nicknames |
common-lisp | cl |
common-lisp-user | cl-user |
keyword | none |
Figure 11–2. Standardized Package Names
11.6.0 2 Discussion of package LISP and USER removed. -kmp 15-Feb-92
11.6.0 5 Discussion of the CLtL1 package named SYSTEM removed.
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).
Moved this sentence out of previous paragraph. --sjl 7 Mar 92The common-lisp package can have additional internal symbols.
common-lisp package can have a function, macro, or special operator definition, top level value ??? 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. That's the definition of a conforming implementation. -kmp
that is, a \term{conforming program} may assume that this is true.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.
KMP: Initially or for all times? -kmp 2-Jan-91
Sandra: The intent was to cover properties put there by the implementation, not the user.
KMP: I double-checked the issues, and that seems to be right.
No \term{external symbols} of \thepackage{common-lisp}
can have \term{properties} with \term{property indicators}
that are either \term{external symbols} of any \term{standardized} \term{packages}
or otherwise \term{accessible} in \thepackage{common-lisp-user}.
Rewritten. -kmp 15-Feb-92A 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.
Valid programs can assume that the conformal Lisp implementation will not have prohibited properties. The proposal LISP-SYMBOL-REDEFINITION addresses the converse; that is, what user programs are allowed to do.
common-lisp package:
added define-condition --sjl 7 Mar 92
defstruct, defclass, deftype, define-condition).
defstruct).
declaration proclamation.
Barmar notes that this can't be done to any symbols. Sandra complained, too. \itemitem{n.} Altering its name.
trace).
What's this "or lexical" biz? -kmp 13-May-91
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-expander).
define-method-combination).
setf of find-class.
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).
KMP: Maybe clarify that binding CL special variables is ok,
but that their type decls are lexical. Is that right?
I implemented the first half of that suggestion. -kmp 15-Feb-92Unless 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 KMP: Barmar wanted some explication here. I think it was sandra who had
asked for this tracing feature just in case the implementation supported it. (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.
5.1.2 6
11.3.0 5
KMP: This isn't a very apt description!
11.6.0 4
\Thepackage{keyword} contains all of the \newterm{keywords}\meaning{1}
used by built-in or user-defined \term{functions}.
Replaced: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.
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.
Not really needed. This is documented adequately under SYMBOL-VALUE. \Thefunction{symbol-value} can be used to \term{access} the \term{value} of a \term{keyword}\meaning{1}.)
: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.
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.)
package System Classexport Functionfind-symbol Functionfind-package Functionfind-all-symbols Functionimport Functionlist-all-packages Functionrename-package Functionshadow Functionshadowing-import Functiondelete-package Functionmake-package Functionwith-package-iterator Macrounexport Functionunintern Functionin-package Macrounuse-package Functionuse-package Functiondefpackage Macrodo-symbols, do-external-symbols, do-all-symbols Macrointern Functionpackage-name Functionpackage-nicknames Functionpackage-shadowing-symbols Functionpackage-use-list Functionpackage-used-by-list Functionpackagep Function*package* Variablepackage-error Condition Typepackage-error-package Function