[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Packages: a modest solution.
Date: 18 Nov 1986 1257-PST (Tuesday)
Aha! I finally figured out the solution to the package problem!
I believe inclusion of packages is the worst mistake in Common LISP's
design. There isn't a day goes by (when I actually get to program or
debug) when I don't have package problems. Often, they dominate the
debugging time. I now type <pkg>::<symbol> all the time, just so I don't
have to think about whether the reader can figure out the right default.
This seems like a problem to me, since you have no control over internal
and external names anymore. I have a similarly explicit approach, but
it preserves the internal/external symbol distinction:
The biggest problem with packages is lack of education about how to
avoid most of their pitfalls. I have found that if you avoid
use-package or the options for :use to in-package and relatives,
and you explicitly export and inport names, then package problems go
away. The only packages which should be used are those which define
the lisp language, i.e., lisp, but not SYS. This avoids most snafu's.
The rule of thumb is "don't use a package unless you personally know
every single exported symbol of that package and know that it doesn't
conflict with any name you are using." This means basically that you
should never use-package anything except package lisp. (even this
causes problems, since lisp is such a big language that people
frequently begin accidently redefining primitives like check-type,
assert, etc. in embedded language systems.....)
For example, we had a major problem with the function
sys:lambda-list, which is supposed to take a symbol and print the
lambda-list, and a bunch of code which uses an internal symbol
"lambda-list" just as a local lexical var. If you load the files in
the wrong order, you get a package problem. This is only since
package lisp uses package sys, an unfortunate situation that can't be
rectified easily. The solution was to make a moby export file which
is read before almost anything, but this is really a kludge. The
problem is really that lisp code has no business using the symbol
"lambda-list" internally anywhere without recognizing the existance
of that name as an internal part of the sys package.
If you explicitly export and import the right symbols manually, then
the code to do this automatically interns all the right things in the
right places, i.e., in order to say that you are importing certain
symbols you must introduce them to the reader properly qualified with
a package prefix. Hence you won't die having to unintern some symbol
which was read into the wrong place before the export/import happened.
I'm in favor of leaving the package system as it is, but I think the
manual (or a later spec) should contain alot of warnings about the
kinds of problems that use-package causes. The naive user almost
always thinks the easiest thing to do is have all his packages use
each-other. And if he does experience package problems, then the
naive view again is that making everything use everything solves
these problems. There is no "DWIM-with-all-the-symbols"; the control
of names in large systems requires a methodical, explicit approach.
Gold Hill Computers