Compilation and package system

[Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>]

To summarize this discussion, the desired solution that would satisfy
everyone would have the following properties:

(1) Package specifications should not use the -*- stuff at all, because
there's nothing about -*- in the Common Lisp manual.  Not only does this
make it easier to port programs, but it's necessary to allow the
building of portable programs that understand files of Common Lisp code
(e.g. cross referencers).  It's OK to have the -*- in ADDITION to the
portable forms that specify package setups, but it's purely optional
from the point of view of the Common Lisp evaluator and compiler.
(Possibly we could back off and have a yellow-pages package that
Symbolics provides and other implementations pick up.)

(2) The editor needs as much information about packages as the compiler
and the loader.  All programs that read Lisp forms from files must get
the package information from the same place, and work consistently.
Furthermore, it is out of the question for you to have to manually
evaluate forms out of the buffer before you can edit properly.

(3) It should not be required that complex package setups be in their own
file, since you want to be able to use packages flexibly even in
programs that fit in one file.  Use of packages shouldn't force you to
have to split your program into many files, with associated pain in
copying them, etc, etc.

(4) If Symbolics Common Lisp and its editor are to work correctly on
ported unmodified Common Lisp source files, it must be prepared to deal
with CMU files, which use -*- lines that refer to packages that aren't
created until that very file is evaluated.  Right now, the CLCP user
at CMU gets an error.  Strictly speaking, the program is valid Common
Lisp, because Common Lisp doesn't ever look inside comments, and so
the CLCP is technically in error.

As far as I can tell, the only way to meet the first three constraints
is to require the editor to parse through the entire file, finding all
of the package-related forms such as IMPORT, when the file is read in.
It's a bit harder than that, since those forms might be inside of
EVAL-WHEN forms.  Or COND forms.  Or there might be a function defined
in the file and later called at top-level that does an IMPORT.  Worse
yet, the "package environment" might be different at different parts of
the file, as various package-related forms are sprinkled among the
function definitions.

I don't think this is feasible.

Zetalisp has basically taken the stance that each file has exactly one
"package environment" that's the same throughout the file, and the
information that sets up this environment is essentially declarative,
rather than imperative.  These restrictions have not turned out to be a
problem, based on large volumes of sophisticated code turned out over
several years.  In exchange for them, we get point (2) above.  Perhaps
it is our disagreement over (2)'s importance that is really at the
bottom of this discussion.