From: Kent M Pitman
Subject: Re: Default value for :USE arg of MAKE-PACKAGE
Date:
Message-ID: <sfwitcqmyyd.fsf@world.std.com>
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Which value commonly used as default for USE argument
> in MAKE-PACKAGE ? Is this :CL ?
First, if you're just making a package to program in, use DEFPACKAGE,
not MAKE-PACKAGE. MAKE-PACKAGE is a programmatic interface usually
used for creating packages as "data" rather than packages as "program
spaces", though the line is subjective and sometimes blurry.
Second, I can't tell if you're asking "what would this default to if I
omitted it?" or "what should I choose if I supplied it explicitly and
didn't know a good value?"
To the former question, the answer is that CLHS tells you it's
implementation-defined, which means only your vendor can tell you,
both for MAKE-PACKAGE and DEFPACKAGE (which fortunately have a consistent
answer on this point):
http://www.xanalys.com/software_tools/reference/HyperSpec/FrontMatter/
To the latter question, my answer is longer, and includes information
about the default:
Picking your arguments on the basis of a statistical probability
that others would have done them that way is not the best way to program.
You're better off asking what it would mean if you used this or that
argument, and then deciding whether you like the effects.
(defpackage "MY-PACKAGE"
(:use "CL"))
says "I want to create a package called MY-PACKAGE which inherits all the
operators and variables and things that I know ANSI CL has in it."
This is most likely to make your programs portable because it won't
have any vendor-specific stuff in it, forcing you refer to such
vendor-specific stuff with explicit package prefixes.
(defpackage "MY-PACKAGE")
says to default the use-list to something vendor-specific, so means "I
trust my vendor to start me out a package that has good stuff in it,
even though that stuff is probably different than whatever any other
vendor has".
I personally regard it as unfortunate that omitting a :USE is not
required to have a portable meaning equivalent to (:USE "CL"), but
it just isn't. Vendors could still make it be so, but many don't.
I personally do not recommend EVER doing this, but some vendors like
you to because they think it save you work to not type their package
prefixes when you use the extra goodies they throw in that are
vendor-specific. This makes for awful porting problems if you ever
try to run your code elsewhere, and can lead to your not understanding
where the language ends and the vendor implementation begins. It
provides no additional power since you could always still use vendor
packages with explicit prefixes.
As you become more advanced, you may want to use some of these:
(defpackage "MY-COLLABORATIVE-PACKAGE"
(:use "CL" "FREDS-PACKAGE" "SALLYS-PACKAGE"))
This creates a package which initially contains the symbols defined by
Common Lisp, and two other packages FREDS-PACKAGE and SALLYS-PACKAGE,
which are presumably things you want to inherit additional symbols from.
(All :USE references grab only the external symbols of the package, so they
ignore anything that was not :EXPORT'd from that package.)
(defpackage "MY-SPECIAL-PACKAGE"
(:use))
This creates a package that has an empty use-list, which therefore
basically has no inherited symbols. This package is very hard to
program in because it doesn't have any predefined names and everything
has to be referred to using package prefixes. This can be useful for
creating shared sets of symbols. Consider:
(defpackage "FRUITS"
(:use)
(:export "APPLE" "ORANGE" "BANANA"))
(defpackage "FREDS-PACKAGE"
(:use "CL" "FRUITS")
(:export "APPLE" "ORANGE" "PORK"))
(defpackage "SALLYS-PACKAGE"
(:use "CL" "FRUITS")
(:export "ORANGE" "BANANA" "GREEN"))
This will assure that Fred and Sally (who presumably own those two packages)
both share the symbols named in the FRUITS package. This means that
definitions made by either Fred or Sally on those shared symbols will be seen
by the other, but it also means that if someone later uses both of those
packages, as in "MY-COLLABORATIVE-PACKAGE" above, there will be no symbol
conflict over the symbol "ORANGE", which is defined by both packages.
Had the symbols not been shared this way (or by some other equivalent means),
"MY-COLLABORATIVE-PACKAGE" would have required a :SHADOWING-IMPORT declaration
in order to break the tie between using FREDS-PACKAGE:ORANGE and
SALLYS-PACKAGE:ORANGE.
Thank you Kent.
I do appreciate your brilliant explanations.
Although I meant 'what this default to if I omitted it'
all parts of your explanation are equally useful and
valuable for me.
--
Vladimir Zolotykh ······@eurocom.od.ua
On Sun, 4 Nov 2001 13:45:46 GMT, Kent M Pitman <······@world.std.com>
wrote:
> not MAKE-PACKAGE. MAKE-PACKAGE is a programmatic interface usually
> used for creating packages as "data" rather than packages as "program
> spaces", though the line is subjective and sometimes blurry.
Could you elaborate on this? While I seem to understand what it means to
create a package as data, I don't understand under what circumstances this
may be used instead of data made of more "traditional" building blocks such
as lists, structures, classes, etc.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Paolo Amoroso <·······@mclink.it> writes:
> On Sun, 4 Nov 2001 13:45:46 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> > not MAKE-PACKAGE. MAKE-PACKAGE is a programmatic interface usually
> > used for creating packages as "data" rather than packages as "program
> > spaces", though the line is subjective and sometimes blurry.
>
> Could you elaborate on this? While I seem to understand what it means to
> create a package as data, I don't understand under what circumstances this
> may be used instead of data made of more "traditional" building blocks such
> as lists, structures, classes, etc.
Well, you might use packages in meta programming as data when establishing
a foothold. Some environments are a little rough when they start up and
you have to poke around in various packages to find where the symbols you
want are and program up a package. This can be done by #. in defpackage
but is sometimes more convenient to do longhand by a regular program.
Very big systems with lots of dependencies that have had to port to a
million very unlike environments might do package bootstrapping this way.
You might wish for a DEFPACKAGE, but it might just not be the easiest way
to build up a package definition. I'm thinking maybe Macsyma or CLIM could
be examples, but I can't recall for sure.
Also, probably closer to theq question you're asking, you might use
packages as a kind of token hash table. Especially if you're building
embedded languages that will want the tokens to be mixable into Lisp code.
e.g.,
(defvar *token-table-counter* 0)
(defun make-token-table (&optional kind)
(loop (let ((name (format nil "Token ······@[ ~A~] ~D"
kind (incf *token-table-counter*))))
(unless (find-package name) (make-package name :use nil)))))
(defvar *op-tokens* (make-token-table "Op"))
(defun intern-op (name)
(intern (string-upcase name) *op-tokens*))
Sometimes I also do this when creating packages I don't plan to use for
my program but plan to export to users. e.g., having made a FOOSYS
package, I might do:
(defvar *foosys-user* (make-package "FOOSYS-USER" :use '("CL" "FOOSYS")))