[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PACKAGE-CLUTTER (Version 4)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: PACKAGE-CLUTTER (Version 4)
- From: masinter.pa@Xerox.COM
- Date: 7 Oct 88 18:54 PDT
As for removing SYSTEM; it is no worse than the other packages that might
be in an implementation. Its not just package names, its also package
I don't see any reason not to also allow USER to have symbols, if it can
:USE other packages. For example, what if your system first reads an init
file and the init file is in-package "USER", then the first thing that the
"real" user will see might have a few symbols from the init file actually
interned in "USER". As long as it doesn't have to be empty, there's no
reason to make it only :USE other packages, is there?
I've modified the proposal in response to Kent's other comments.
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
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 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 :-).
Specify that, not only must the 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.)
Symbols on the LISP package may have function or macro
definitions, 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 or macros; 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.
(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
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
#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 will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
If extra symbols are permitted in the LISP package, users may be
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
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.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in
there can be extra definitions for those symbols. For example, in
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is
as a macro.
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
about what is in what package, and the changes could potentially be
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 proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
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
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
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"
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.