In large Lisp systems, it's easy to run into problems with
the order in which files are loaded and compiled.
One often-vexing issue is where to put package
declarations. If a file names an exported symbol
such as foo:bar, the package foo with its
export list must have been loaded earlier.
In general, it seems to me that in a big complicated
system with lots of packages, it would be great
if you could just first load all the files with
defpackage forms, and get all those packages
created and all the external variables externalized,
and then load everything else.
However, in a situation I'm working on now, that
doesn't work, because package X has
(:import-from :y :a1 :a2), and the symbols
:a1 and :a2 are not exported from :y. That
is, X is exporting internal symbols of Y.
This fails, because the symbols :a1 and :a2
do not exist, because they get created only
when the files that define them get loaded.
So doing all the package declarations first
does not work.
Possible approaches:
(1) Too bad; you really do have to load
the Lisp files that created those internal
symbols after defining package X and
before defining package Y.
(2) For Y to export symbols of X that
X does not export, while being valid
Common Lisp, is a bad practice.
It's a little hard to explain why we're doing this
at all. I think it is historical. Originally
there was only package X. Then it was
considered a good idea to classify some
of the functions in package X under a new
package name, Y, to make the rest of
the code clearer. Unfortunately, the symbols
and functions and macros of package X
may be too entangled to separate them
out the way we would have done had the
partition between X and Y been done
from the beginning.
By "too hard" I mean that it's not worth
the trouble to attain the goal, which was
to remove a single ugly use of "::".
But I'm interested in the topic anyway.
-- Dan