Packages & Compiling

[Timothy.Freeman@theory.cs.cmu.edu]

Jon L. White from Lucid said in a mail message to me (among other people):

   Indeed, the most prevalent "obscurity" in the compilation process that
   snares many users is the requirement that the package world be EXACTLY
   the same at load time that it was at compile time.  The act of compiling
   a file with calls to IMPORT in it changes the package world structure; and
   so does loading such a file (or indeed, any file with calls to  IMPORT,
   EXPORT, IN-PACKAGE, USE-PACKAGE, INTERN, etc in it).

He isn't clear about whether he is claiming this for Lucid
Common Lisp only or for all common lisps anywhere.  He didn't give me
permission to repeat his words to a mailing list, so please don't
crucify him if what he said is wrong.

Since most of the lisp I write lives in its own package, most of my
source files have calls to import & such.  Thus, if I took his statement
seriously, I would hardly ever be able to compile the same file twice
in the same lisp image and expect the same results from the
compilations, because the first compilation's calls to import would
cause the second compilation to have a different package environment.

CLtL specifies the compiler by saying that "compiling a file of code
should produce an equivalent but more efficient program".  Jon is
saying "compiling a file of code should produce an equivalent but more
efficient program, provided that the package environment at compile
time is the same as the package environment at load time; otherwise
all bets are off".  I can imagine ways of implementing compilers so
that the qualifier about the package environment is unneccessary.
(I'll elaborate my imagination if it becomes apparent that people
don't believe me.)

Should Jon's statement be true of the common lisp standard?  If so,
why is doing it that way better than avoiding the repeated compilation
problem that is described above?