[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: QUOTE-MAY-COPY (Version 4)
- To: CL-Compiler@SAIL.STANFORD.EDU
- Subject: Issue: QUOTE-MAY-COPY (Version 4)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 24 Jan 89 22:10 EST
- Cc: Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
You said you were going to completely rewrite this issue, so these
comments may be useless. On the other hand, I may as well send them
on the off-chance that they might assist with the rewrite.
QUOTE-MAY-COPY:ALWAYS version 4 -- No
QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE -- Yes
QUOTE-MAY-COPY:NOT-EVAL -- No
Note that I have changed my position on this (formerly was ALWAYS). I
might change back though. Kent likes NOT-EVAL-OR-COMPILE or a
restricted version of ALWAYS that doesn't limit what can be used as a
constant except in COMPILE-FILE. If I switch to ALWAYS I would agree
with Kent's amendment that all objects are allowed as constants and
copying is permitted only for the objects where equivalence is defined.
Symbolics Genera current practice is that COMPILE copies list, string,
(non-structure, non-displaced) array, and (I-Machine only) closure
constants. However, I think this is wrong. Everything within a single
Lisp world should remain EQL. COMPILE-FILE obviously can't make things
in the output be EQL to things in the input, but it can preserve the
relationship that if x and y are EQL in the input, then compile(x) and
compile(y) are EQL in the output. In addition, coalescing of equivalent
constants should be allowed so that x and y not EQL does not imply
compile(x) and compile(y) not EQL. When not using COMPILE-FILE, the
rule should be that EQL is preserved and copying is allowed only if
the compiler can somehow prove that no other references to the object
exist. At least for Symbolics this means that using COMPILE-FILE
can give more efficient (in terms of virtual memory locality) code
than you can get with COMPILE. I don't know Symbolics Cloe current
practice and forgot to find out.
I oppose anything that makes EVAL and COMPILE different from each other.
Is the output of LOAD-TIME-EVAL supposed to be subject to copying or not?
Answer explicitly in the proposal so no one can stay confused.
There is a claim that QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE would require
major revamping of some implementations (PSL/PCLS and maybe KCL). I
find this hard to believe, but if it's true I might change my vote
to ALWAYS on the grounds of that. I'd have to hear more about the
specific implementation problems first. It seems to me that constant
copying in COMPILE can only be a matter of efficiency, and compiled
functions always have to have access to normal Lisp objects.
Note that it isn't safe, I contend, to copy constants in COMPILE-FILE if
the constant object is referenced from elsewhere in the file. EQL needs
to be preserved within one file. I think I see how to implement this
correctly but it will take some work (in Symbolics Genera).
Nonetheless, it's right. Fundamentally the issue is whether we care
more about doing what's best or about the cost for implementors. I
don't think there is any significant cost to users on any of these.
Note that on compatibility issues I care very strongly about cost to
users, but I don't care hardly at all about cost to implementors.
Implementors are tough and they can take it, or they wouldn't still be