308 lines
21 KiB
HTML
308 lines
21 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 DEFPACKAGE 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/iss107_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss108.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss109_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/iss107_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss108.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss109_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue DEFPACKAGE Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A><P>
|
|
<P>
|
|
<B>References:</B> CLtL section 11.7.<P>
|
|
Issue: <A HREF="iss195.htm">IN-PACKAGE-FUNCTIONALITY</A><P>
|
|
Issue: <A HREF="iss238.htm">MAKE-PACKAGE-USE-DEFAULT</A><P>
|
|
Issue: <A HREF="iss253.htm">PACKAGE-DELETION</A><P>
|
|
<P>
|
|
<B>Category:</B> ADDITION<P>
|
|
<P>
|
|
<B>Edit history:</B> Version 1, 12-Mar-88, Moon<P>
|
|
Version 2, 23-Mar-88, Moon, changes based on discussion<P>
|
|
Version 3, 27-Sep-88, JonL <P>
|
|
(<A REL=DEFINITION HREF="../Body/f_rm_rm.htm#remove"><B>remove</B></A> :import, :shadowing-import; allow :export to work on<P>
|
|
imported <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A> inherited; update references to <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>in-package</B></A>, etc.)<P>
|
|
Version 4, 1-Oct-88, Masinter<P>
|
|
Version 5, 6-Oct-88, Moon<P>
|
|
Version 6, 6-Oct-88, JonL (little nits)<P>
|
|
Version 7, 2-Nov-88, JonL <P>
|
|
(incorporate further discussion; simplify handling of<P>
|
|
syntactic errors; specify ordering constraints).<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
Many users incorrectly think that package operations can be performed<P>
|
|
in any order. CLtL (p.192) contributes to this misconception.<P>
|
|
Programmers need direction on the ordering constraint, especially for<P>
|
|
creating packages, since doing things out of order can lead to<P>
|
|
confusing or even intractable problems.<P>
|
|
<P>
|
|
If the definition of a package is scattered throughout a program as a <P>
|
|
number of individual forms, it is very easy to read a symbol before the <P>
|
|
package setup needed to read that symbol correctly has been accomplished. <P>
|
|
Three examples: an inherited symbol that should have been shadowed might <P>
|
|
be accessed; a single-colon prefix might be used for a symbol that hasn't<P>
|
|
yet been exported; an internal symbol might be created afresh where a <P>
|
|
symbol that will later be imported or inherited was intended. These <P>
|
|
problems can be difficult to understand or even to recognize; in some <P>
|
|
cases it is difficult or impossible to correct the situation in the<P>
|
|
same Lisp image.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal (DEFPACKAGE:ADDITION):<P>
|
|
</B> <P>
|
|
Add a <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> macro to the language. In the description below,<P>
|
|
'<A REL=DEFINITION HREF="../Body/f_pkg_na.htm#package-name"><B>package-name</B></A>' and '<A REL=DEFINITION HREF="../Body/f_symb_2.htm#symbol-name"><B>symbol-name</B></A>' can be a symbol or a string; if a <P>
|
|
symbol, only its name matters, not what package it is in.<P>
|
|
<P>
|
|
The syntax of <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> is<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> <A REL=DEFINITION HREF="../Body/f_pkg_na.htm#package-name"><B>package-name</B></A> {option}*)<P>
|
|
<P>
|
|
where each option is a list of a keyword and arguments. Nothing in a<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> form is evaluated.<P>
|
|
<P>
|
|
Standard options for <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> are listed below. Except for :SIZE, <P>
|
|
options may appear more than once (this is useful primarily for <P>
|
|
:IMPORT-FROM and :SHADOWING-IMPORT-FROM).<P>
|
|
<P>
|
|
(:NICKNAMES {package-name}*)<P>
|
|
Set the package's nicknames to the specified names.<P>
|
|
<P>
|
|
(:USE {package-name}*)<P>
|
|
The package is to "use" the other designated packages; that is,<P>
|
|
it will inherit from them. The default value for this option <P>
|
|
should be the same as it is for <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A> (also see the issue<P>
|
|
<A HREF="iss238.htm">MAKE-PACKAGE-USE-DEFAULT</A>).<P>
|
|
<P>
|
|
(:SHADOW {symbol-name}*)<P>
|
|
Create the specified symbols in the package being defined, <P>
|
|
making them shadows, just as the function <A REL=DEFINITION HREF="../Body/f_shadow.htm#shadow"><B>SHADOW</B></A> would do.<P>
|
|
<P>
|
|
(:SHADOWING-IMPORT-FROM <A REL=DEFINITION HREF="../Body/f_pkg_na.htm#package-name"><B>package-name</B></A> {symbol-name}*)<P>
|
|
Find the specified symbols in the specified package, import<P>
|
|
them into the package being defined, and place them on the <P>
|
|
shadowing symbols list. In no case will symbols be created in <P>
|
|
any package other than the one being defined; a continuable error <P>
|
|
is signaled if no symbol is accessible in the package named <P>
|
|
<A REL=DEFINITION HREF="../Body/f_pkg_na.htm#package-name"><B>package-name</B></A> for one of the symbol-names.<P>
|
|
<P>
|
|
(:IMPORT-FROM <A REL=DEFINITION HREF="../Body/f_pkg_na.htm#package-name"><B>package-name</B></A> {symbol-name}*)<P>
|
|
Find the specified symbols in the specified package and import<P>
|
|
them into the package being defined. In no case will symbols be <P>
|
|
created in a package other than the one being defined; a continuable<P>
|
|
error is signaled if no symbol is accessible in the package named <P>
|
|
<A REL=DEFINITION HREF="../Body/f_pkg_na.htm#package-name"><B>package-name</B></A> for one of the symbol-names.<P>
|
|
<P>
|
|
(:EXPORT {symbol-name}*)<P>
|
|
Find or create symbols with the specified names and <A REL=DEFINITION HREF="../Body/f_export.htm#export"><B>export</B></A> them.<P>
|
|
Note an interaction with the :USE option, since inherited symbols <P>
|
|
can be used rather than new ones created; note also an interaction <P>
|
|
with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since <P>
|
|
imported symbols can be used rather than new ones created.<P>
|
|
<P>
|
|
(:INTERN {symbol-name}*)<P>
|
|
Find or create symbols with the specified names. Note an <P>
|
|
interaction with the :USE option, since inherited symbols <P>
|
|
can be used rather than new ones created. This option is useful if <P>
|
|
an :IMPORT-FROM or a :SHADOWING-IMPORT-FROM option in a subsequent <P>
|
|
call to <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> (for some other package) expects to find these <P>
|
|
symbols accessible but not necessarily external.<P>
|
|
<P>
|
|
(:SIZE <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>integer</B></A>)<P>
|
|
Declare the approximate number of symbols expected in the package.<P>
|
|
This is an efficiency hint only, so that the package's table will<P>
|
|
not have to be frequently re-expanded when new symbols are added<P>
|
|
to it (e.g., by reading in a large file "in" that package).<P>
|
|
<P>
|
|
The order in which the options occur in a <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> form is irrelevant;<P>
|
|
but since the effects of the entry-making options are context-sensitive, <P>
|
|
the order in which they will be executed is as follows:<P>
|
|
(1) :SHADOW and :SHADOWING-IMPORT-FROM <P>
|
|
(2) :USE <P>
|
|
(3) :IMPORT-FROM and :INTERN<P>
|
|
(4) :EXPORT<P>
|
|
Shadows are established first, since they may be necessary to block <P>
|
|
spurious name conflicts when the use link is established. Use links are <P>
|
|
established next so that :intern and :export may refer to normally <P>
|
|
inherited symbols. The :export is done last so that it may refer to <P>
|
|
symbols created by any of the other options; in particular, shadows and <P>
|
|
imported symbols can be made external. Note also the prescription on CLtL <P>
|
|
p.178 to cover the case of calling <A REL=DEFINITION HREF="../Body/f_export.htm#export"><B>EXPORT</B></A> on an inherited symbol.<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> creates the package as specified and returns it as its value.<P>
|
|
It has no other side effects; e.g., it does not alter the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A>.<P>
|
|
The function <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> should treat top-level <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> forms the<P>
|
|
same way it treats the other package-effecting functions (see CLtL p.182).<P>
|
|
<P>
|
|
If the specified name already refers to an existing package, then the <P>
|
|
name-to-package mapping for that name is not changed. At most, the <P>
|
|
existing package will be modified to reflect the new definition; it is <P>
|
|
undefined what happens if the new definition is at variance with the <P>
|
|
current state of that package. If one of the specified nicknames already<P>
|
|
refers to an existing package, then an error is signaled just the same<P>
|
|
as <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A> would. See the issue <A HREF="iss253.htm">PACKAGE-DELETION</A> for undoing the<P>
|
|
name-to-package mapping.<P>
|
|
<P>
|
|
Some <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> errors are, however, purely syntactic.<P>
|
|
(1) An error should be signaled if :SIZE appears than once.<P>
|
|
(2) Since extended options might be allowed by other implementations, <P>
|
|
an error should be signaled if an option is present that is not <P>
|
|
actually supported in this implementation.<P>
|
|
(3) The collection of <A REL=DEFINITION HREF="../Body/f_symb_2.htm#symbol-name"><B>symbol-name</B></A> arguments given to the options <P>
|
|
:SHADOW, :INTERN, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must <P>
|
|
all be disjoint; additionally, the <A REL=DEFINITION HREF="../Body/f_symb_2.htm#symbol-name"><B>symbol-name</B></A> arguments given to <P>
|
|
:EXPORT and :INTERN must be disjoint. If either condition is <P>
|
|
violated, an error should be signaled.<P>
|
|
Name conflict errors will, of course, be handled by the underlying calls to <P>
|
|
<A REL=DEFINITION HREF="../Body/f_use_pk.htm#use-package"><B>USE-PACKAGE</B></A>, <A REL=DEFINITION HREF="../Body/f_import.htm#import"><B>IMPORT</B></A>, and <A REL=DEFINITION HREF="../Body/f_export.htm#export"><B>EXPORT</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Examples:<P>
|
|
</B><P>
|
|
;;; An example that "plays it super-safe" by using only strings as names; <P>
|
|
;;; does not even assume that the package it is read in to "uses" LISP; <P>
|
|
;; *never* creates any symbols whatsoever in the package that it is read <P>
|
|
;; in to.<P>
|
|
<P>
|
|
(LISP:DEFPACKAGE "MY-PACKAGE"<P>
|
|
(:NICKNAMES "MYPKG" "MY-PKG")<P>
|
|
(:USE "LISP")<P>
|
|
(:SHADOW "CAR" "CDR")<P>
|
|
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")<P>
|
|
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")<P>
|
|
(:EXPORT "EQ" "CONS" "FROBOLA")<P>
|
|
)<P>
|
|
<P>
|
|
;;; A similar call, mostly using symbols rather than strings as names.<P>
|
|
;;; Expects to be read in to a package that "uses" LISP and *may* create<P>
|
|
;;; random internal symbols in that package (such as MY-PACKAGE etc).<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>defpackage</B></A> my-package<P>
|
|
(:nicknames mypkg :MY-PKG) ;remember CL conventions for <A REL=DEFINITION HREF="../Body/m_case_.htm#case"><B>case</B></A><P>
|
|
(:use lisp) ; conversion on symbols<P>
|
|
(:shadow <A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>CAR</B></A> :cdr #:cons)<P>
|
|
(:export "CONS") ;yes, this is <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>the</B></A> shadowed one.<P>
|
|
)<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
The availability of <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> encourages putting the entire package <P>
|
|
definition in a single place. It also encourages putting all the package <P>
|
|
definitions of a program in a single file, which can be loaded before <P>
|
|
loading or compiling anything else that depends on those packages; such a<P>
|
|
file can be read in the USER package, avoiding any initial state issues.<P>
|
|
<P>
|
|
In addition, <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> allows a programming environment to process<P>
|
|
the whole package setup as a unit, providing better error-checking and<P>
|
|
more assistance with package problems, by dint of global knowledge of<P>
|
|
the package setup.<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
Symbolics Common Lisp (SCL) has always had a <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A>, and users<P>
|
|
prefer it to individual calls to <A REL=DEFINITION HREF="../Body/f_export.htm#export"><B>EXPORT</B></A>, <A REL=DEFINITION HREF="../Body/f_import.htm#import"><B>IMPORT</B></A>, <A REL=DEFINITION HREF="../Body/f_shadow.htm#shadow"><B>SHADOW</B></A>, etc. The SCL<P>
|
|
version of <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> has quite a few additional options, but none of<P>
|
|
them appears to be necessary to propose for Common Lisp at this time.<P>
|
|
This proposal is incompatible with Symbolics <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> in some ways<P>
|
|
that will probably not cause major problems.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Small--DEFPACKAGE can be implemented simply as a bunch of<P>
|
|
calls to existing functions.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
Small, this is upward compatible.<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B><P>
|
|
Packages continue to be difficult to use correctly.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Guide users away from using packages in ways that get them into trouble.<P>
|
|
<P>
|
|
<B>Esthetics:<P>
|
|
</B><P>
|
|
Neutral.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
It has been suggested that the "Put IN Seven EXtremely Random USEr<P>
|
|
Interface COmmands" mnemonic described in CLtL p.191 could be removed;<P>
|
|
and with possibly a few exceptions, the special handling of them by<P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> could be removed. As this would be an incompatible change, <P>
|
|
it is not part of this proposal. However, a new mnemonic can be offered, <P>
|
|
to help remember the ordering constraints mentioned above:<P>
|
|
I REmember Six USEr Interface Expressions<P>
|
|
Each word in the sentence corresponds to one operation listed below:<P>
|
|
I <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A> ;"foot" to stand on<P>
|
|
REmember <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>REQUIRE</B></A> ;ensure pre-requisite packages<P>
|
|
Six <A REL=DEFINITION HREF="../Body/f_shadow.htm#shadow"><B>SHADOW</B></A> ;block multiple-inheritances<P>
|
|
USEr <A REL=DEFINITION HREF="../Body/f_use_pk.htm#use-package"><B>USE-PACKAGE</B></A> ;go for it!<P>
|
|
Interface <A REL=DEFINITION HREF="../Body/f_import.htm#import"><B>IMPORT</B></A> ;bring in "foreign" symbols<P>
|
|
EXpressions <A REL=DEFINITION HREF="../Body/f_export.htm#export"><B>EXPORT</B></A> ;a "face" to show to others.<P>
|
|
<P>
|
|
It is noted that <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> cannot be used to create two "mutually<P>
|
|
recursive" packages, such as:<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>defpackage</B></A> my-package<P>
|
|
(:use lisp your-package) ;requires 'your-package' to exist <A REL=DEFINITION HREF="../Body/f_firstc.htm#first"><B>first</B></A><P>
|
|
(:export "MY-FUN"))<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>defpackage</B></A> your-package<P>
|
|
(:use lisp)<P>
|
|
(:import-from my-package "MY-FUN") ;requires 'my-package' to exist <A REL=DEFINITION HREF="../Body/f_firstc.htm#first"><B>first</B></A><P>
|
|
(:export "MY-FUN"))<P>
|
|
However, nothing prevents one from using the package-effecting functions <P>
|
|
such as <A REL=DEFINITION HREF="../Body/f_use_pk.htm#use-package"><B>USE-PACKAGE</B></A>, <A REL=DEFINITION HREF="../Body/f_import.htm#import"><B>IMPORT</B></A>, and <A REL=DEFINITION HREF="../Body/f_export.htm#export"><B>EXPORT</B></A> to establish such links (which<P>
|
|
ought to be very rare) after a more <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> use of <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A>.<P>
|
|
<P>
|
|
The macroexpansion of <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> could usefully canonicalize the names<P>
|
|
into strings, so that even if a source file has random symbols in the<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> form, the compiled file would only contain strings.<P>
|
|
<P>
|
|
Frequently additional implementation-dependent options take the<P>
|
|
form of a keyword standing by itself as an abbreviation for a list<P>
|
|
(<A REL=DEFINITION HREF="../Body/t_kwd.htm#keyword"><B>keyword</B></A> T); this syntax should be properly reported as an unrecognized<P>
|
|
option in implementations that do not support it.<P>
|
|
<P>
|
|
Definition forms in Common Lisp usually just establish a name-to-object<P>
|
|
mapping; there is little precedent for them to modify other global-context<P>
|
|
state. For this reason, we didn't want <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> also to "go" into the <P>
|
|
new package. If it did so, like <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A>, then the following reasonable <P>
|
|
file would become confused, because it wouldn't all be in one package:<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>in-package</B></A> "USER")<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>defpackage</B></A> "WATER" (:use "LISP") (:export "FISH"))<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>defpackage</B></A> "ALCHEMY" (:use "LISP" "PHLOGISTON) (:export gold))<P>
|
|
Should the token 'gold' be read while in the USER package, or in the<P>
|
|
the WATER package?<P>
|
|
<P>
|
|
The issue <A HREF="iss195.htm">IN-PACKAGE-FUNCTIONALITY</A> recommends that <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A> be <P>
|
|
incompatibly changed to recognize only existing packages, not to create <P>
|
|
them. <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A> would then not accept any keyword arguments.<P>
|
|
<P>
|
|
The function <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A> might also be extended to take all the keywords<P>
|
|
that <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> does. This could be the subject of a separate cleanup.<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>
|