Issue: QUOTE-SEMANTICS, or QUOTE-MAY-COPY (Version 4)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 25 Jan 89 05:10:06 PST
    From: Jon L White <jonl@lucid.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
    this case.

 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
    as well.

    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
    occurred.

See above.

    As it stands now, I would oppose any effort to limit the flexibility 
    of implementors on this issue without good cause. 

See above.

    Since we have already passed the proposal that permits constants to 
    be "read-only" -- it is an error to modify them -- 

Right.

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
of this.

    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).

Right.

    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
this action.

[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.