[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
- To: firstname.lastname@example.org
- Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
- From: Jon L White <email@example.com>
- Date: Thu, 6 Oct 88 22:17:28 PDT
- In-reply-to: masinter.pa@Xerox.COM's message of 23 Sep 88 01:19 PDT <880923-011851-3969@Xerox>
References: MAKE-PACKAGE, CLtL p183
"USER" package, CLtL p181
Related issues: PACKAGE-CLUTTER
Edit history: JonL White, 6-Oct-88 (version 1)
CLtL is underspecified as how to treat vendor-specific extensions to
the language; and every vendor has a fairly large set of such extensions.
A general understanding came over the community during 1986 that vendors
should "home" their extensions in a vendor-specific package, and not in
any of the packages named in CLtL section 11.6 "Built-in Packages". Just
how these symbols would be accessible to the user, however, was not stated.
All current means of providing "unqualified accessibility" to the
vendors' extensions will violate either some trivial part of CLtL, such
as the default :use list for MAKE-PACKAGE, or the prohibition of adding
non-standard symbols to the LISP package, or the apparent charge that
the USER package should use (only) the LISP package.
Specify that the default value for the :use argument to MAKE-PACKAGE is
implementation-dependent; portable code would thus have to explicitly
designate the LISP package as the :use argument. Vendors are encouraged
to put their vendor-specific package on the default list, along with the
LISP package and any other packages so specified by the new standard.
(package-use-list (make-package "SOME-USER"))
(subsetp `(,(find-package "LISP"))
(package-use-list (or (find-package "SOME-USER")
Every vendor either already does the equivalent of this, or else has
a confusing assymetry about the USER package (i.e., their propietary
extensions are "available" in USER, but not in SOME-USER).
TI and Lucid's 3.0 versions "implement" this proposal in that they set
the default :use argument to be a list of the LISP package and the
VAXLISP has renamed the LISP package to be the same as the vendor-specific
package, which contains the 775 symbols supposed to be in the LISP packge
along with all the vendors extensions; the package named COMMON-LISP
has only the 775. Thus this "implements" the proposal in the sense that
the inheritance of a package made with a default :use list contains
all the vendor-specific symbols -- not just the 775 "LISP" ones.
Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
default MAKE-PACKAGE use list, but have the aforementioned assymetry
about the USER package.
Cost to Implementors:
None; this relaxes a constraint imposed by CLtL.
Cost to Users:
In theory, every user porting code from one vendor to another would
have to ensure that every package definition, via IN-PACKAGE or
MAKE-PACKAGE, had an explicit :use list. This is probably at most
a 5-minute text editor search. But in fact this imposition is moot,
since virtually every such user has *already* supplied explicit
:use lists; given the current practice, he has had no alternative.
Cost of non-adoption:
There will continue to be a lack of clear standardization in this area,
especially since vendors are more willing to violate this apparently
unuseful mandate from CLtL than they are to give up a minor bias towards
their customer base.
This new default behaviour for package creation will permit a vendor's
documented extensions to appear on equal footing with the basic facilities
in the LISP package. It appears as though the _majority_ of any vendors'
customers are developing and running their code totally within the
enviornment provided by that one vendor; hence it seems reasonable for
vendors to bias their default use list towards those customers making
frequent use of their specific extensions to Common Lisp.
Some feel that fewer implementation-dependent loopholes in the language
is preferable, even when the practical import is virtually moot.
Lucid "exposes" the default :use list as the value of the special
variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
time, one could do
(setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
to return to the 1984 CLtL behaviour. [This is not being proposed
at this time.]