**DRAFT** issue QUOTE-MAY-COPY

[alarson@src.honeywell.com (Aaron Larson)]

I have several problems with this proposal, although I support what I
believe to be the intent of :ALWAYS.

This proposal brings up once again the ever present confusion between code
and data.  I don't think that the lagnuage as defined in CLtL is adequate
to describe this problem.  For example (from the proposal):

  Change the description of QUOTE to indicate that (QUOTE <x>) returns
  an object equivalent to <x>, which may or may not be EQ to <x>.  
  Likewise, a self-evaluating form may also return an equivalent copy 
  of the object.
   ...
  If an implementation chooses to copy constants, the copying may only
  happen once each time the form containing the constant is processed
  with COMPILE or EVAL (see examples below). ...

I believe that QUOTE has to return THE argument it is given.  Secondly
since CLtL describes the derivation of values from language constructs as
evaluation, it makes little sense to talk about "each time the form ... is
processed by eval" in any way that would allow repeated calls to the
function FOO to return EQ objects if QUOTE were permitted to copy its
argument each time it was "processed by EVAL"

        (defun foo () '(a b c))

I think that some extra (conceptual) machinery is necessary.  For example,
lets suppose that the language was changed as follows:

  EVAL only works on code, not data,
  there exists a function called PROMOTE that converts data into code.

(I'm not acutally advocating that we change the language, just a thought
experiment).  We would now talk about READ PROMOTE EVAL PRINT loops.  If
there existed machinery like this in the language, then the statement of
this problem becomes trivial:  "Is PROMOTE permitted to copy its argument?"
COMPILE, and COMPILE-FILE could either be defined to be synonyms for
PROMOTE, or required to take PROMOTEd arguments.  Similarly PROMOTE would
be permitted to collapse EQUAL parts of its substructure if it so desired. 

If PROMOTE were permitted to copy its argument, then part of the confusion
in the example in the statement of the proposal LOAD-TIME-EVAL (recall "(eq
#1=stuff #1#)") would also be eliminated because it no longer makes sense
to talk about shared structure in CODE.

Perhaps only things that can be reliably put in object files should be
permitted to be PROMOTEd (e.g. only those things wich are "equivalent as
constants" or some such verbiage), even if that does not include circular
structures.