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


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


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