QUOTE and compiled/interpreted consistency

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

What seems to be happening is that we have several issues about
how the file compiler treats constants and one (QUOTE-MAY-COPY)
that says whether these things apply to interpreted and COMPILE'd
code too.  For example:

    Issue: CONSTANT-CIRCULAR-COMPILATION (v4)

    Problem Description:

    [...]
    The proposals below apply to COMPILE-FILE, since it must inherently
    copy structures.  If issue QUOTE-MAY-COPY is resolved in favor of
    allowing COMPILE and possibly EVAL to copy structures, the same
    constraints would also apply in those situations.

This means that it is difficult to vote on these issues in isolation,
and I'm worried that the results might not fit together very well.

Some people have argued for QUOTE-MAY-COPY:ALWAYS on the grounds that
it advances the cause of consistency between interpreted and compiled
code.  But there are a large number of issues involved there, and not
just the ones involving QUOTE.  For exmaple:

   COMPILER-LET works when code is compiled, because it's body is also
   fully macroexopanded during the extent of the COMPILER-LET, but runs
   into problems in interpreted code because the body might not be
   fully expanded until later on.

   LOAD-TIME-EVAL can be used to return an object that can then be
   modified.  It therefore supplies "static data".  But in interpreted
   code it might return a new object each time, if for no other reason
   than because repeated macroexpansion might keep making new LOAD-TIME-
   EVAL forms.

Now, if LOAD-TIME-EVAL worked in interpreted code (by which I mean were
guaranteed to return the same object each time), then there would be less
reason to want QUOTE to preserve EQL realationships.  So here again the
issues are related.  Actually, if you look at LOAD-TIME-VALUE(8), the true
situation is even worse: it's interpreted semantics are explicitly made
equivalent to something involving QUOTE; so it might turn out that it
couldn't return circular objects or ones that couldn't be dumped!

I submit that this situation is unreasonable and that we should try
to at least suggest a consistent view (rather than simply present all
the different issues).

-- Jeff