Packages & Compiling

[Rob MacLachlan <RAM@C.CS.CMU.EDU>]

    This is another thing that the compiler subcommittee should clear
up.  In this case, it is not reasonable for the compiler to be
required to maintain the interpreted semantics.  The problem is that
the compiler presumably uses the reader to read the source code, and
READ is not an information preserving operation.

    Since CLTL doesn't admit this problem, it also doesn't properly
specify the package semantics of fasloading.  There was some
discussion of this a while back, and we found that different
implementations were doing different things.

    Although this part of the language is poorly specified, any
compiler which can't compile the same file twice is clearly broken.

    I would "clarify" the requirement for an identical compile and
load environment to the following:
  "To the extent which it matters, the package environment at the time
   the compiler interns a symbol must be equivalent to the package
   environment in which the loader interns the symbol."

This requirement isn't very useful to users, since it makes references
to the times at which the interning is done by the compiler and
loader.  Especially in the loader, the time of interning may be
non-obvious.

In practice, there shouldn't be any problem as long as either:
  1] The package environment used by a file is initialized using
     top-level package manipulation code.  The compiler will guarantee
     that package operations done by such forms are properly sequenced
     with respect to INTERN operations both in the compiler and the
     loader.
  2] Any other required aspects of the package environment are present
     both at the beginning of the compilation of the file and the
     beginning of the load of the fasl file.

The most common violation of these rules that I have seen it that a
user changes the package environment at load time, but doesn't use
obvious top-level package manipulation forms.  In this case, the
compiler tends to get confused, causing the loader to attempt to
find packages that don't exist yet, or other bad things.

The real problem is that package manipulation forms look like ordinary
Lisp code, yet must be treated in a totally magical way by the
compiler.

  Rob