[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


There's enough debate on this that this might be helpful.

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


Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
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")


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

Test Cases:

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


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:



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.


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
to return to the 1984 CLtL behaviour.  [This is not being proposed
at this time.]