214 lines
11 KiB
HTML
214 lines
11 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
||
<HTML>
|
||
<HEAD>
|
||
<TITLE>CLHS: Issue MAKE-PACKAGE-USE-DEFAULT Writeup</TITLE>
|
||
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
||
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
||
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
||
<LINK REL=TOP HREF="../Front/index.htm">
|
||
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
||
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
||
<LINK REL=PREV HREF="../Issues/iss237_w.htm">
|
||
<LINK REL=UP HREF="../Issues/iss238.htm">
|
||
<LINK REL=NEXT HREF="../Issues/iss239_w.htm">
|
||
</HEAD>
|
||
<BODY>
|
||
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss237_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss238.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss239_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
||
|
||
<HR>
|
||
|
||
|
||
|
||
<H2>Issue MAKE-PACKAGE-USE-DEFAULT Writeup</H2>
|
||
|
||
<PRE><B>Status:</B> Passed, as amended<P>
|
||
<B>Issue:</B> <A HREF="iss238.htm">MAKE-PACKAGE-USE-DEFAULT</A> <P>
|
||
<P>
|
||
<B>References:</B> <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A>, CLtL p183<P>
|
||
"USER" package, CLtL p181<P>
|
||
<P>
|
||
Related issues: <A HREF="iss252.htm">PACKAGE-CLUTTER</A><P>
|
||
<P>
|
||
<B>Category:</B> CHANGE<P>
|
||
<P>
|
||
<B>Edit history:</B> JonL White, 6-Oct-88 (version 1)<P>
|
||
Masinter, 8-Oct-88 (version 2)<P>
|
||
Masinter, 16-Mar-89, Version 3 (make amendments <P>
|
||
per Jan 89 X3J13)<P>
|
||
<P>
|
||
<B>Problem description:<P>
|
||
</B><P>
|
||
The proposal in the issue <A HREF="iss252.htm">PACKAGE-CLUTTER</A> would specify that <P>
|
||
implementation-specific extensions are not in the LISP package.<P>
|
||
<P>
|
||
With that restriction, access to implementation-specific features<P>
|
||
is awkward; it is necessary to always name the vendor-specific<P>
|
||
extensions in the :USE list of <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A> or (if the proposal<P>
|
||
in <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> is adopted) in <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A>.<P>
|
||
<P>
|
||
This forces users of a specific implementation to always have<P>
|
||
to type something to get the default set of features for that<P>
|
||
implementation, even if they have no intention of writing portable<P>
|
||
code.<P>
|
||
<P>
|
||
<P>
|
||
Proposal <A HREF="iss238.htm">MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT</A><P>
|
||
<P>
|
||
Change the specification of <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A> (and <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A>, if<P>
|
||
adopted, and <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A>, if <A HREF="iss195.htm">IN-PACKAGE-FUNCTIONALITY</A> is not<P>
|
||
adopted) so that the default for the :USE keyword is <P>
|
||
undefined. Normally, the default will include<P>
|
||
the packages containing the implementation-specific features.<P>
|
||
<P>
|
||
Portable programs should instead always specify :USE '("LISP")<P>
|
||
explicitly. <P>
|
||
<P>
|
||
<B>Examples:<P>
|
||
</B><P>
|
||
(<A REL=DEFINITION HREF="../Body/f_pkg_us.htm#package-use-list"><B>package-use-list</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>make-package</B></A> "SOME-USER"))<P>
|
||
(<A REL=DEFINITION HREF="../Body/f_pkg_us.htm#package-use-list"><B>package-use-list</B></A> "USER")<P>
|
||
<P>
|
||
<P>
|
||
<B>Test Cases:<P>
|
||
</B><P>
|
||
(<A REL=DEFINITION HREF="../Body/m_assert.htm#assert"><B>assert</B></A> <P>
|
||
(<A REL=DEFINITION HREF="../Body/f_subset.htm#subsetp"><B>subsetp</B></A> `(,(<A REL=DEFINITION HREF="../Body/f_find_p.htm#find-package"><B>find-package</B></A> "LISP"))<P>
|
||
(<A REL=DEFINITION HREF="../Body/f_pkg_us.htm#package-use-list"><B>package-use-list</B></A> (<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>or</B></A> (<A REL=DEFINITION HREF="../Body/f_find_p.htm#find-package"><B>find-package</B></A> "SOME-USER")<P>
|
||
(<A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>make-package</B></A> "SOME-USER")))))<P>
|
||
<P>
|
||
<P>
|
||
<B>Rationale:<P>
|
||
</B><P>
|
||
Every implementation either already does the equivalent of this, or<P>
|
||
else has a confusing assymetry about the USER package (i.e., their<P>
|
||
extensions are "available" in USER, but not in SOME-USER).<P>
|
||
<P>
|
||
<B>Current practice:<P>
|
||
</B><P>
|
||
TI and Lucid's 3.0 versions "implement" this proposal in that they set <P>
|
||
the default :USE argument to be a list of the LISP package and the <P>
|
||
implementation-specific package. <P>
|
||
<P>
|
||
In VAXLISP the LISP package is the implementation-specific<P>
|
||
package, which contains the 775 symbols supposed to be in the LISP packge<P>
|
||
along with all the extensions; the package named COMMON-LISP<P>
|
||
has only the 775. Thus this implements the proposal in the sense that<P>
|
||
the inheritance of a package made with a default :USE list contains<P>
|
||
all the implementation-specific symbols -- not just the 775 "LISP" ones.<P>
|
||
<P>
|
||
Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the<P>
|
||
default <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A> use list, but have the aforementioned assymetry<P>
|
||
about the USER package.<P>
|
||
<P>
|
||
<B>Cost to Implementors:<P>
|
||
</B><P>
|
||
None; this relaxes a constraint imposed by CLtL.<P>
|
||
<P>
|
||
<B>Cost to Users:<P>
|
||
</B><P>
|
||
In theory, every user porting code from one vendor to another would<P>
|
||
have to ensure that every package definition, via <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A> or<P>
|
||
<A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A>, had an explicit :USE list. This is probably at most<P>
|
||
a 5-minute text editor search. But in fact this imposition is moot,<P>
|
||
since virtually every such user has *already* supplied explicit<P>
|
||
:USE lists; given the current practice, he has had no alternative.<P>
|
||
<P>
|
||
<P>
|
||
<B>Cost of non-adoption:<P>
|
||
</B><P>
|
||
There will continue to be a lack of clear standardization in this area,<P>
|
||
especially since vendors are more willing to violate this apparently<P>
|
||
unuseful mandate from CLtL than they are to give up a minor bias towards<P>
|
||
their customer base.<P>
|
||
<P>
|
||
<B>Performance impact:<P>
|
||
</B><P>
|
||
None.<P>
|
||
<P>
|
||
<B>Benefits:<P>
|
||
</B><P>
|
||
This new default behaviour for package creation will permit <P>
|
||
documented extensions to appear on equal footing with the basic facilities<P>
|
||
in the LISP package. It appears as though the _majority_ of any <P>
|
||
users are developing and running their code totally within the <P>
|
||
enviornment provided by that one vendor; hence it seems reasonable for<P>
|
||
implementations to bias their default use list towards those making <P>
|
||
frequent use of their specific extensions to Common Lisp.<P>
|
||
<P>
|
||
<P>
|
||
<B>Esthetics:<P>
|
||
</B><P>
|
||
Some feel that fewer implementation-dependent loopholes in the language<P>
|
||
is preferable, even when the practical import is virtually moot.<P>
|
||
<P>
|
||
<B>Discussion:<P>
|
||
</B><P>
|
||
Lucid "exposes" the default :use list as the value of the special<P>
|
||
variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration<P>
|
||
time, one could do<P>
|
||
(<A REL=DEFINITION HREF="../Body/s_setq.htm#setq"><B>setq</B></A> *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))<P>
|
||
to return to the 1984 CLtL behaviour. [This is not being proposed<P>
|
||
at this time.]<P>
|
||
<P>
|
||
<P>
|
||
<P>
|
||
----- Additional Comments -----<P>
|
||
<P>
|
||
<P>
|
||
" I don't like this proposal, but I made a note to myself about another<P>
|
||
reason that just occurred to me: There is no syntax for getting the default<P>
|
||
(ie, system-dependent) package included if you want to -also- use some other<P>
|
||
package."<P>
|
||
<P>
|
||
- - - - - -<P>
|
||
<P>
|
||
"MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.<P>
|
||
I think it might be better to strengthen it and say that the<P>
|
||
default for :USE is identical to the use list of the USER package.<P>
|
||
Does anyone agree?<P>
|
||
<P>
|
||
In response to Kent's remarks, the issue is whether the default should<P>
|
||
be a portable way to get the local extensions, or a portable way to<P>
|
||
get the portable language without the extensions. I think either of<P>
|
||
those choices is portable and reasonable, it just depends on what you<P>
|
||
want to make easier, which probably depends on whether a package is<P>
|
||
being set up for use only by a predefined program or for use by user<P>
|
||
typein and/or user-written programs, either of which are likely to<P>
|
||
expect the local extensions.<P>
|
||
<P>
|
||
Hence I would also accept a proposal to make the default for :USE<P>
|
||
continue to be the LISP package, rather than incompatibly changing it,<P>
|
||
and add a portable name for the local extensions."<P>
|
||
- - - - - -<P>
|
||
<P>
|
||
"re: I think it might be better to strengthen it and say that the<P>
|
||
default for :USE is identical to the use list of the USER package.<P>
|
||
Does anyone agree?<P>
|
||
<P>
|
||
I agree, sort of. Especially since one of the motivating factors for <P>
|
||
this proposal was that some Lucid 2.1 user's were complaining that <P>
|
||
"things" look a lot different from the USER package than from a <P>
|
||
user-created package.<P>
|
||
<P>
|
||
The only question is whether or not you really want the default to be<P>
|
||
sensitive to subsequent alterations of USER's :use list. As mentioned<P>
|
||
in the Discussion section of the proposal, Lucid's implementation<P>
|
||
exposes the default as the value of a global variable, which happens<P>
|
||
to be a copy of the initial :use list of USER; but subsequent changes <P>
|
||
to USER have no affect on this global variable."<P>
|
||
- - - - - -<P>
|
||
<P>
|
||
"The point: non-portable programs should declare that intent up-front.<P>
|
||
This is a virtue of the current situation: if the program uses a<P>
|
||
non-portable package, they have to state that at the head of the file. Us<P>
|
||
poor losers who try to load it into the wrong environment get a error<P>
|
||
before we've gotten on with the load."<P>
|
||
<P>
|
||
</PRE>
|
||
<HR>
|
||
|
||
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
||
|
||
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
||
</BODY>
|
||
</HTML>
|