Packages & Compiling

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

Although it is not currently stated anywhere, it is definitely
required that the compiler use READ to parse input files.  The whole
reason for having an extensible reader is that it allows people to
define read macros that can be used in code.  Normal macros also
demand that source be represented as a s-expression, making life very
difficult for any scheme that tries to pass extra information from the
reader to the fasl-dumper.

It may be possible to preserve package qualification information
somehow, but I think any implementation would be unreasonably
difficult.  It isn't worth "fixing" this problem, since there are
dozens of other equally intractable problems that prevent
COMPILE-FILE/LOAD from being identical to LOAD of the source. 

The real problem is that LOAD of a source is over-specified, since
"everyone knows" that it is implemented by sequentially reading and
evaluating forms.  What we need to do is come up with a more
restrictive semantics for a "code file" such that a well-formed code
file will do the same thing across the full range of legal
implementations of Common Lisp evaluation.

I won't discuss the non-package compiler issues that you mentioned,
since they open a moby can of worms.  The rules you give are certainly
sufficient, but are not necessary.

I said "to the extent which it matters, the package environments must
be equivalent" to emphasize the unknown nature of "package
equivalence".  All I can really say right now is that requiring the
package state to be "identical" is too restrictive.

  Rob