PACKAGE-CLUTTER
``The package named LISP contains the primitives of the Common Lisp system. Its external symbols include all of the user-visible functions and global variables that are present in the Common Lisp system, such as CAR, CDR, *PACKAGE*, etc. Almost all other packages will want to use LISP so that these symbosl will be accessible without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package. Nothing in CLtL explicitly prohibits this, but it leads to problems in general. For example:
- A user defining a function by a name not mentioned in CLtL may be surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.") signalled a correctable error (asking what variable to bind instead of HELP :-).
LISP package contain at least all of the symbols listed in the standard, it will have no other external symbols. (The LISP package may have additional internal symbols.)
External symbols of the LISP package may have function, macro, or special form definitions, setf method definition, top level value or SPECIAL proclamations, or type definitions only if explicitly permitted in the specification. That is, a program is valid Common Lisp if it assumes that this is true; for example, FBOUNDP will be false for all external symbols of the LISP package except those documented to be functions, macros or special forms; no setf method will be defined for such a symbol, and FBOUNDP on (SETF symbol) will be false; BOUNDP will be false for all those except those documented to be variables, and portable programs can use symbols in the LISP package as local lexical variables with the presumption that the variables are not proclaimed special, except for those variables specified as constants or variables.
No external symbols of the LISP package may have properties with property indicators that are either external symbols of packages defined in the standard or are otherwise accessible in the USER package.
This proposal constrains implementations as to what their initial package configuration must be. That is, 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.
Eliminate the requirement that the initial Common Lisp system have a package named "SYSTEM". Specify that implementations may have several other packages available, that these should be documented. If it is appropriate, the standard might contain as an example that implementations might have a package named "SYSTEM".
Clarify that the "USER" package may have additional symbols interned within it and that it may :USE other implementation-specific packages.
HELP may not be on the LISP package because it is not mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because it is a valid second argument to the DOCUMENTATION function). Since it is not defined as a variable, type, or function, however, it will not initially be bound, defined as a type, or defined as a function, macro or special form.
LISP package, users may be surprised by relationships between the LISP package and other packages which they did not expect, or may be surprised by functionality that they did not expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE) (DEFCONSTANT LISP:B 'YOU-LOSE) (DEFCONSTANT LISP:C 'YOU-LOSE) ... (DEFCONSTANT LISP:AA 'YOU-LOSE) (DEFCONSTANT LISP:AB 'YOU-LOSE) (DEFCONSTANT LISP:AB 'YOU-LOSE) ...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not valid because they attempt to bind "system constants". It is necessary that the programmer be able to know for sure that an arbitrary name is "free for use" and best way to conveniently assure this is to require that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional definitions would cause a problem. For example, if a symbol on the Lisp package were declared as a special variable even though that value was not mentioned in the standard, that variable would behave incorrectly when used as a lexical variable. Similarly, if a symbol in the lisp package were defined as an implementation-dependent special form, problems might result if a user redefined or even bound (as by FLET or MACROLET) that name.
The LISP package is the foothold from which portable programs establish their desired environment. Careful control is desirable to make sure everyone is starting off on the right foot.
LISP package.
Several implementations have restricted the LISP package to only contain those symbols in CLtL. (The exact set was difficult to extract because not all LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL, there can be extra definitions for those symbols. For example, in Symbolics Genera, the symbols EVALHOOK, ROOM, and APPLYHOOK are spuriously defined as special variables, and the symbol LAMBDA is defined as a macro.
LISP package in cases where they are not already gone is quite small. However, if any implementation really has to do this, it may have a number of suppositions about what is in what package, and the changes could potentially be extensive.
In many cases where an extension symbol FOO is simply expected to have been directly available (due to :USE "LISP"), it will work to just just do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is declared.
More likely the extension symbols would be moved to one or more extensions packages, e.g. ACME-COMMON-LISP, so user packages in which the extensions were desired could simply :USE the extensions package(s). Implementations might want to use this way of conforming with this proposal in order to minimize cost to users.
In many cases where an extension symbol FOO is used by explicit package prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or even `LISP:' to find the cases.
LISP package to be adulterated and for supposedly portable programs to have difficulty getting a foothold in some implementations will be `noticeably non-zero'.LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those specified in the standard was controversial. The smart programmer of portable code will never rely on the contents of the USER package. However, if someone wants a completely empty package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal symbols in the LISP package (since it affects what DO-SYMBOLS will do) explicitly prohibiting a common practice didn't seem like the best way to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally exporting unwanted additional definitions for symbols,e.g., a variable definition for EVALHOOK which might show through because of an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and the signal mechanism) will reside in their own packages. These externally defined packages should have the same constraints as outlined for the LISP package here.
There has been a suggestion that vendor-specific extensions should be placed in a package named like ACME-COMMON-LISP for the "Acme" company.
A registry of packages (as well as features, modules and other global names) would be useful, although probably not a part of the language standard, per se.
Barrett and Pitman support superseding version 7 with version 8.
---------- Additional comments on the write-up:
"This is clearly correct." --Moon (9 Jan 90)