Compilation and package system

[perdue%hplabs.csnet@csnet-relay.arpa]

It is surprising to me that there has not been discussion of
the problems of compiling when there is a package system.
The specific problem I have in mind is in the handling of
symbols that are referred to in the input text without a package
qualifier.

The user of a Common LISP implementation sees the problem as a
difference between the behavior of a module (file) loaded in its
interpretive form and loaded in its compiled form.  Specifically,
references to symbols will in some cases be resolved differently
depending on whether or not the file was compiled before being loaded.

The source of the problem is that LISP compilers use READ to get
forms to compile and READ loses all information about whether a symbol
was specified with a package qualifier and whether a single or double
colon.  If the file has an IN-PACKAGE at the beginning it is only
pathological cases that cause problems, but if the file does not,
needed information has clearly been lost.

The CLM specifies that loading a compiled file shall be equivalent
to loading an interpretive file, but the packages of symbols in
a compiled file have in effect been DETERMINED AT COMPILE TIME,
and load-time binding can only be faked.

Various heuristics are used by implementations to try to do more
or less the right thing.  For example, any symbol available without
name qualification when read can be assumed to have been named
without a package qualifier.  At loadtime the reference can be
resolved as though it had no qualifier.  But the knowledge of
whether it was actually written with qualification has been lost.
If the module (file) is loaded with a current package different than
the current package when it was compiled, loading of the compiled
version will not necessarily result in references to the same symbols
as loading the interpretive version of the module.
-------