[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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