[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: QUOTE-SEMANTICS, or QUOTE-MAY-COPY (Version 4)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: QUOTE-SEMANTICS, or QUOTE-MAY-COPY (Version 4)
- From: Jon L White <firstname.lastname@example.org>
- Date: Wed, 25 Jan 89 05:10:06 PST
- Cc: CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: David A. Moon's message of Tue, 24 Jan 89 22:10 EST <19890125031059.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: I oppose anything that makes EVAL and COMPILE different from each other.
Suppose an implementation has an EVAL which doesn't _guarantee_ that
any two successive calls on a function similar to:
(DEFUN FOO () (QUOTE <frob>))
will return EQ things [unless, of course, the equivalence class of
coalescings of <frob> has only one element in it; this is true of
symbols and most implementations of fixnums]. In that implementation,
COMPILE should be permitted to "copy" constants, right? [Please be
aware that I'm not suggesting this as a good idea -- but some have
noted that unless you require a "prepass" type evaluator, it may
be impossible to preclude macro-expansions from being done repeatedly
and thus returning non-EQ values on each call to some function].
Put another way, no one has ever proposed to "make EVAL and COMPILE
[be] different". Rather, the proposal is to be explicitly vague
about guarantees of EQness of constants for portable code.
Although the call has long been sounded, no one yet has offered
realistic applications where coalescing of constants -- either by
COMPILE or COMPILE-FILE -- would hinder either the application or
the coding thereof. The only comments have been micro-examples made
with malice-aforethought to demonstrate that in some circumstance is
it *possible* to determine whether or not non-trivial coalescing has
As it stands now, I would oppose any effort to limit the flexibility
of implementors on this issue without good cause.
Since we have already passed the proposal that permits constants to
be "read-only" -- it is an error to modify them -- and have already
passed the proposal that allows access to updateable structures --
LOAD-TIME-EVAL -- then there is no excuse for being overly concerned
with the storage address of quoted data. People who have mistakenly
used structured constants as updatable data should convert over to
either LOAD-TIME-EVAL or DEFPARAMETER.
Some have suggested that quoted non-symbols might be good for use
as unique markers. This does not accord with what I have seen in
very extensive use. By far, the majority of cases I've seen use
keywords (a classic use!); those that don't, seem generally to have
had the good sense to use devar or defparameter (which in fact is
how some implementations achive EQLness in support for DEFCONSTANT).
However the final killer, I believe, in this scenario, is not EVAL
followed by COMPILE, but rather EVAL followed by reading in a new
definition followed by EVAL. Even though QUOTE didn't copy anything,
and even though EVAL didn't copy anything, the output of the newly
defined constant-returning fuction is no longer EQL to what it was
before. And we do want to facilitate redefining functions on
the fly, don't we?
-- JonL --