[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Status: Passed, as amended


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



Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if


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



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

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


- - - - - -


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

[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.