Re: 4.2

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> READ is the only place (I think) where the use of a printed
> representation is required. I think we should abandon this requirement.

Then your complaint doesn't really have anything to do with
COMPILE-FILE per se -- if COMPILE-FILE uses READ, and READ is extended
to read structured files, then COMPILE-FILE will do exactly what you
want, and there's no reason to make any chantes to its specification.
(Again, I think it would be legitimate for an implementation to extend
READ in this manner even if the standard only defines its behavior on
character streams.)

> If we say the copy *might* be a fresh copy, we should also say that
> the compiled code *might* work. What I want to see clearly explained
> is a prescription of the structure of a compilation unit, a
> compilation scenario, and a load scenario that is guaranteed to work
> in every conforming Common Lisp.  Maybe some others will work, and we
> can state some general directions for extension that should work. But
> we absolutely must specify the safe scenario.

I've been taking a rather different approach to this -- instead of
trying to specify in what circumstances that loading a compiled file
will "work", I've been thinking more in terms of specifying in what
circumstances a file can be compiled so that it will *always* load
correctly when compiled.  (Of course, a program might not work for
reasons that have nothing to do with compilation, so effectively we're
trying to get loading the compiled version to exhibit the same
behavior as loading the interpreted version.)

Since compilation involves making some decisions about the program
(what forms are macro calls, possibly making inferences about the
types of objects manipulated by the program, etc.) at compile time,
the equivalence of source and compiled code may not hold if the
information the compiler used to make these decisions has changed when
the file is loaded.  So the section we're talking about here is trying
to say what kinds of information the compiler might incorporate into
the code and what happens (whether the consequences are undefined or
unspecified) if the information that was visible at compile time is
not defined consistently with the information that is visible at load
time.  I don't think it's necessary to place any additional
constraints on the Lisp image being "fresh", or the compiled file
being loaded "immediately".  What's more, I don't think there's any
*reason* for adding such an arbitrary constraint.  We might just as
well say that it's only valid to load the compiled code on the night
of a full moon. 

-Sandra
-------