Packages & Compiling

[edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)]

The quotation you attribute to me is a little bit out of context in that 
the phrase
    ". . . requirement that the package world be EXACTLY the same at 
     load time that it was at compile time."
wasn't meant to imply that you will be guaranteed to lose when that
"requirement" is violated -- only that you can't be guaranteed to win.
In particular, lots of trivial such violations occur all the time, with
no lossage.

The kind of lossage you and Tom Gross had experienced may have been 
caused by a different set of using packages between the compilation
environment and the load time environment.  At any rate, such a
difference (in the package-use-list of your application package) may
or may not cause trouble -- depends upon whether your compiled file
uses any of the symbols that were accessible via inheritance from the
package that was "used" at compile time but missing at load time, or
has any symbols which are expected to be created in the application
package but which are spuriously inherited from a used package that 
wasn't also used at compile time.

There are other possible problems too, but they are not all related to
compilation.  For example, it is not at all difficult to cook up a 
little test file that will "act differently" when merely loaded in 
interpretively two times in a row.  But of course, loading a compiled 
file compounds the number of cases in which you may lose because,  
typicaly, the compiled-file "reader" is not at all the same as READ.

In general, however, you are touching on the issue of insulating the 
compilation environment from *any* side-effects occuring in the lisp
before the file compilation in question, including those caused by 
previous compilations.  You specifically bring up only the issue of 
compiling a file twice, and seeing a different package environment the 
second time.  But the potential for lossage is much more complex than 
merely package side effects; for example, think of macro definitions -- 
do you want them visible or not?  maybe sometimes "yes" and sometimes "no".

There was a paper in the 1986 Lisp Conference on an "Un-Common Lisp" 
that mentioned one partial solution the the issue.  There is also an 
ANSI sub-committee addressing the issue of compilation semantics -- perhaps 
they will attempt to define just how much insulation you can expect.  Quite
possibly, they should address the semantics of just how the compiled file 
reader can differ from READ.


-- JonL --