[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: QUOTE-SEMANTICS, or QUOTE-MAY-COPY (Version 4)
- To: firstname.lastname@example.org
- Subject: Issue: QUOTE-SEMANTICS, or QUOTE-MAY-COPY (Version 4)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 25 Jan 89 12:11 EST
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: <8901251310.AA08200@bhopal>
Date: Wed, 25 Jan 89 05:10:06 PST
From: Jon L White <email@example.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]. ...
I found it somewhat difficult to understand this message because Moon
spoke about EQL and you replied about EQ. It took me a while to assure
myself that this discrepancy wasn't relevant to your argument. Let's just
all refer to EQL from now on if at all possible.
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.
Well, yes, they have:
1. The case of #, is one. I have always assumed that #, was capable of
delivering up a value which could be depended upon not to change.
Now that there's LOAD-TIME-VALUE, presumably you mean to exempt
2. The case of circular structure is another.
'#1=(A . #1#)
If permitting copying implies that the copier might blow out, then
I it means that writing (DEFUN FOO () '#1=(A . #1#)) is not useful
because I must always assume that some implementation somewhere might
blow out. On the other hand, I've suggested a restriction on copying
that would obviate this concern, too. Perhaps you're presupposing it
The problem is that a lot of copying advocates have been going around
trying to use "the need for copying" as leverage for restricting
the set of things which I may quote. My view is that it is my write
to quote whatever I want, and it's up to the person who thinks they
can do something fun with copying to not get themselves in deeper than
they can handle.
If both of these issues is taken as exempted from your discussion, then
I concur. But in previous discussions neither of these have been taken
as given, and certainly for me these issues are -very- real.
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 --
Objection 1 above addresses the question of whether #, things are part of
the quoted structure and hence not covered. By making LOAD-TIME-VALUE a
special form that doesn't live in QUOTE, we gloss that issue entirely.
On the other hand, objection 2 above addresses a problem which does not
arise due to trying to modify anything. It is at the heart of why this
issue matters at all to me.
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.
Right. Previous discussions have not been able to assume the existence
People who have mistakenly used structured constants as updatable
data should convert over to either LOAD-TIME-EVAL or DEFPARAMETER.
Right. But that doesn't address objection 2.
Some have suggested that quoted non-symbols might be good for use
as unique markers.
Right. I always use (LIST NIL), not '(NIL) myself.
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.
This is a very good example because it highlights some interesting issues.
However, note that my objection 2 still applies because that problemsome
situation [the circularity or whatever] will be correctly reproduced by
[As a sidelight, note that all my uses of #, were insensitive to this
because my most common use of #, was something like
#,(OR (GETHASH 'symbol table) (SETF (GETHASH 'symbol table) (compute)))
Since the first read would create the hash table entry and the second
read would re-access the table, my uses of #, were not affected by this
test. This is a non-issue now that there's LOAD-TIME-VALUE, but was
a commonly overlooked issue prior: multiple evaluation didn't have to
mean a new frob was consed.]
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?
I think these points are well-taken. As long as my objection 2 above is
dealt with, I'm happy with this line of reasoning.