Issue MAKE-PACKAGE-USE-DEFAULT Writeup

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