MAKE-PACKAGE-USE-DEFAULTPACKAGE-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.
SOME-USER")) (package-use-list "USER")LISP")) (package-use-list (or (find-package "SOME-USER") (make-package "SOME-USER")))))USER package (i.e., their extensions are "available" in USER, but not in SOME-USER).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.
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.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.: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."