Status: Passed, as amended
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)
               Masinter, 16-Mar-89, Version 3 (make amendments 
			per Jan 89 X3J13)

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



     ----- Additional Comments -----


" I don't like this proposal, but I made a note to myself about another
 reason that just occurred to me:  There is no syntax for getting the default
 (ie, system-dependent) package included if you want to -also- use some other
 package."

 - - - - - -

"MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.
I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?

In response to Kent's remarks, the issue is whether the default should
be a portable way to get the local extensions, or a portable way to
get the portable language without the extensions.  I think either of
those choices is portable and reasonable, it just depends on what you
want to make easier, which probably depends on whether a package is
being set up for use only by a predefined program or for use by user
typein and/or user-written programs, either of which are likely to
expect the local extensions.

Hence I would also accept a proposal to make the default for :USE
continue to be the LISP package, rather than incompatibly changing it,
and add a portable name for the local extensions."
 - - - - - -

"re: I think it might be better to strengthen it and say that the
    default for :USE is identical to the use list of the USER package.
    Does anyone agree?

I agree, sort of.  Especially since one of the motivating factors for 
this proposal was that some Lucid 2.1 user's were complaining that 
"things" look a lot different from the USER package than from a 
user-created package.

The only question is whether or not you really want the default to be
sensitive to subsequent alterations of USER's :use list.  As mentioned
in the Discussion section of the proposal, Lucid's implementation
exposes the default as the value of a global variable, which happens
to be a copy of the initial :use list of USER; but subsequent changes 
to USER have no affect on this global variable."
 - - - - - -

"The point:  non-portable programs should declare that intent up-front.
This is a virtue of the current situation:  if the program uses a
non-portable package, they have to state that at the head of the file.  Us
poor losers who try to load it into the wrong environment get a error
before we've gotten on with the load."

