[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: **DRAFT** issue QUOTE-MAY-COPY
- To: Jon L White <jonl%lucid.com@NSS.Cs.Ucl.AC.UK>, jeff <@NSS.Cs.Ucl.AC.UK:jeff@aiai.edinburgh.ac.uk>
- Subject: Re: **DRAFT** issue QUOTE-MAY-COPY
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Wed, 11 Jan 89 18:54:12 GMT
- Cc: alarson@altura.honeywell.com, cl-compiler@sail.stanford.edu
- In-reply-to: Jon L White's message of Wed, 11 Jan 89 00:09:20 PST
> The only conceivable reason why the EQ/EQL version of identity could
> matter is if you allow runtime updating of "constants" -- in that case,
> you need a pointer to the real place that was updated rather than a
> pointer to an equivalent copy. But we are outlawing constant modification,
> right?
You might want an EQ- or EQL-unique object to use as an index into
a table or hash table. But in general, the fact that EQ or EQL can
tell the difference may mean that the user wants to make that
distinction even though it can't be made in any other way.
LOAD-TIME-VALUE might help in all of these cases (whether you want
to modify or just to have a unique object), except that we might
end up deciding that LOAD-TIME-VALUE gives a new object each time
in interpreted code and that QUOTE does not. The situation would
be better in compiled code.
My remaining concern is that, as much as possible, EQL uninterned
symbols stay EQL and non-EQL ones stay non-EQL. Except for the
possibility that this will not happen, such symbols might be pretty
good as EQL-unique objects.