Re: **DRAFT** issue QUOTE-MAY-COPY

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

> I believe that QUOTE has to return THE argument it is given.

There is a continuing problem with the language of this proposal.
I think the way we're being asked to think (by JonL and others)
is more or less equivalent to saying that QUOTE returns what it's
given, but what it's given may be a copy of the object that was
in the expression before EVAL ever saw it.  For example,

   (let ((a <expr>))
     (eql a (eval `(quote (quote ,a)))))

might return NIL.  It seems that you are thinking along similar lines,
as was Sandra:

   From: sandra <(Sandra J Loosemore)sandra%defun@edu.utah.cs>
   Date: Sat, 17 Dec 88 14:58:05 MST
   Subject: Re: issue QUOTE-MAY-COPY, version 2

   I'm not real sure if this line of thought is turning out to be
   particularly productive.  To me it seems pretty clear that any copying
   of constants that goes on happens as a result of transforming an
   arbitrary data structure into a program.  In other words, the list

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

   is just a list.  It doesn't become a program until it is passed to
   EVAL or COMPILE or if it appears in a file being compiled with
   COMPILE-FILE.  The question we are trying to resolve is whether pieces
   of the data structure that represent constant objects must appear
   literally in the resulting program, or whether the transformation may
   construct a equivalent copies instead. 

   Perhaps I chose a misleading name for this issue.  I don't think
   anybody is arguing that QUOTE itself must do whatever copying is
   allowed.  We could rename the issue to something less confusing, if
   anybody has a suggestion.  

   -Sandra

> 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"

I'm inclined to agree, but I think the problem is not so much that
we've confused code and data (after all, what is the value returned
by PROMOTE if not data?) as that "processed" is never defined and so
gets confused with "evaluated".  Perhaps something that explains
or replaces "processed by EVAL" should be put in the proposal.

> 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.

We may want to present an evaluation model in which we have an explicit
step called "processing" or whatever.  I'm not sure it makes sense to
make it a separate function (is EVAL going to signal an error on 
unPRMOTEd arguments?), and I think it's ok to have the result be
a Lisp object or the usual sort (lists, etc.) rather than a new type
called "code".

> 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.

Why not?  Perhaps code is the sort of object that can have shared
structure.  I think that at least makes sense, even if we decide it 
shouldn't be true.