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

[masinter.pa@Xerox.COM]

There's enough debate on this that this might be helpful.
!
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)
               Masinter,  8-Oct-88  (version 2)

Problem description:

The proposal in the issue PACKAGE-CLUTTER would specify that 
implementation-specific extensions are not in the LISP package.

With that restriction, access to implementation-specific features
is awkward; it is necessary to always name the vendor-specific
extensions in the :USE list of MAKE-PACKAGE or (if the proposal
in DEFPACKAGE is adopted) in DEFPACKAGE.

This forces users of a specific implementation to always have
to type something to get the default set of features for that
implementation, even if they have no intention of writing portable
code.


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

Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
adopted) so that the default for the :USE keyword is 
implementation-dependent. Normally, the default will include
the packages containing the implementation-specific features.

Portable programs should instead always specify :USE '("LISP")
explicitly.  

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 implementation either already does the equivalent of this, or
else has a confusing assymetry about the USER package (i.e., their
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 
implementation-specific package. 

In VAXLISP the LISP package is the implementation-specific
package, which contains the 775 symbols supposed to be in the LISP packge
along with all the 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 implementation-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 
documented extensions to appear on equal footing with the basic facilities
in the LISP package.  It appears as though the _majority_ of any  
users are developing and running their code totally within the 
enviornment provided by that one vendor; hence it seems reasonable for
implementations to bias their default use list towards those 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.]