[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PACKAGE-CLUTTER (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: PACKAGE-CLUTTER (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 7 Jul 88 16:07 EDT
References: LISP package (p181)
Edit history: 07-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
CLtL specifies that
``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
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL prohibits this, but it leads to problems in general.
- 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 :-).
Specify that the LISP package must contain not only all the symbols
mentioned as part of the LISP package in standard, but only those symbols.
Specify that symbols in the LISP package may not have definitions other
than those specified.
#1: The symbol 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 may
not be bound, defined as a type, or defined as a function, macro or
If extra symbols are permitted in the 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)
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
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.
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Symbolics Genera currently has exactly the set of symbols on it which is
prescribed by CLtL. A few symbols, such as EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables. The symbol LAMBDA is defined
as a macro. There may be a few other exceptions like this.
Cost to Implementors:
The actual cost of moving the symbols out of the 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.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
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
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.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Portability of some programs will be enhanced.
This change probably supports the naive expectation of most programmers
writing portable code.
This issue came up a while back on Common-Lisp list. It got bogged down in
discussions of what the USER package and other system-specific packages might
contain. This proposal avoids the sticky issue of whether the USER package may
contain symbols other than those specified in the standard. The smart programmer
of portable code will never rely on the contents of the USER package anyway.
Pitman supports PACKAGE-CLUTTER:REDUCE.