Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)

[Jon L White <jonl@lucid.com>]

Issue:        MAKE-PACKAGE-USE-DEFAULT 

References:    MAKE-PACKAGE, CLtL p183
               "USER" package, CLtL p181

Related issues: PACKAGE-CLUTTER


Category:      CHANGE

Edit history:  JonL White, 6-Oct-88 (version 1)

Problem description:

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.


Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT

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.


Examples:

(package-use-list (make-package "SOME-USER"))
(package-use-list "USER")


Test Cases:

(assert 
    (subsetp `(,(find-package "LISP"))
              (package-use-list (or (find-package "SOME-USER")
				    (make-package "SOME-USER")))))


Rationale:

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).


Current practice:

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 
vendor-specific package. 

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.


Performance impact:

None.

Benefits:

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.


Esthetics:

Some feel that fewer implementation-dependent loopholes in the language
is preferable, even when the practical import is virtually moot.


Discussion:

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.]