Re: issue QUOTE-SEMANTICS, version 2

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

> Date: Fri, 17 Mar 89 18:55 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> If an implementation is allowed
> to extend "similar as a constant", then copying is consistent with the
> definition of "similar as a constant" actually in force in that
> implementation, not with the book definition.

That has been my interpretation all along, too, but as I was looking over
the proposal to incorporate your suggested changes, I realized that it
didn't explicitly say that anywhere.

>     If copying is entirely forbidden in such a case, the implementation 
>     cost for this proposal will be just as high as for proposal NO-COPYING.
> 
> Does this mean that as long as there is one data type for which copying
> is forbidden, perhaps some user-defined data type, there is no implementation
> advantage of COPYING-ALLOWED-BUT-NO-CONSTRAINTS over NO-COPYING?
> If so, that would seem to knock COPYING-ALLOWED-BUT-NO-CONSTRAINTS
> pretty completely out of the running.

There would be an implementation advantage in that you could still
copy constants into some part of memory that is not GC'ed, for
example.  That could be beneficial from a memory-management point of
view.  But yes, those implementations that would have problems with
proposal NO-COPYING would have exactly the same problems with
COPYING-ALLOWED-BUT-NO-CONSTRAINTS unless they define what "similar as
a constant" means for all possible data types.

Incidentally, this afternoon I discussed this issue in some detail
with Leigh Stoller, who is the chief compiler hacker for Utah Common
Lisp.  UCL now implements COMPILE in a manner similar to KCL -- it
creates a temporary FASL file which it then LOADs in the usual way,
and the GC assumes that compiled constants never need to be relocated
or scanned.  Leigh says he thinks UCL will probably never be changed
to implement COMPILE any other way, regardless of the outcome of this
issue.  Partly it's a matter of the work involved, but it's also
because he feels pretty strongly that having different conformance
requirements for compiled and interpreted code would just encourage
people to write programs that would break when compiled.  I mentioned
the alternative of just implementing COMPILE as a simple-minded code
walker and not having it produce a "real" compiled function at all,
but he said he thought that would be a giant step backwards.  UCL will
probably never be a conforming implementation for other reasons, but
on this issue it looks like they'd rather be deliberately nonconforming 
than do something which Leigh described as being "really dumb". 

-Sandra
-------