issue QUOTE-SEMANTICS, version 1

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

I sent out this new writeup out a couple of weeks ago but haven't
received much response on it yet.  Here it is again in case you've
forgotten about it.  I'd like to send this out to X3J13 as soon as
possible, so let's try to get the bugs out of the writeup now. 

If you have something you want added to the discussion section, let me
know. 

I have one additional thing I'd like to raise on this issue, which is
how it relates to conformance requirements.  To me it seems reasonable
that, if a program conforms to the standard, it ought to be possible
to compile it with COMPILE-FILE.  Supposing we do not allow EVAL and
COMPILE to restrict what kinds of objects may appear as constats, is a
program in a file that contains a troublesome constant (like a quoted
stream object) a conforming program? 


Forum:		Compiler
Issue:		QUOTE-SEMANTICS
Subsumes:	Issue QUOTE-MAY-COPY
References:	CLtL p. 55, 78, 86, 143
		Issue CONSTANT-COLLAPSING
		Issue CONSTANT-COMPILABLE-TYPES
		Issue CONSTANT-CIRCULAR-COMPILATION
Category:	CLARIFICATION
Edit History:   V1, 22 Jan 1989, Sandra Loosemore
Status:		**DRAFT**


Problem Description:

Is it permissible for COMPILE and EVAL to coalesce or copy constants?
Are there constraints upon what kinds of objects may appear as
constants in code processed by COMPILE or EVAL, similar to those for
COMPILE-FILE?

CLtL p86 states that (QUOTE <x>) simply returns <x>.  On p55 it is
mentioned that the only self-evaluating forms that may be copied are
numbers or characters.  It is also stated that an implementation is
permitted to collapse (or coalesce) EQUAL constants "appearing in code
to be compiled" (p78), which is defined to mean self-evaluating forms
or objects contained in a QUOTE form (without reference to whether the
form is processed by EVAL, COMPILE, or COMPILE-FILE).

Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded.  In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced.  There is also
at least one implementation where constants are copied by EVAL in some
circumstances.


Proposal QUOTE-SEMANTICS:NO-COPYING:

State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is not permitted; the resulting program
must reference objects that are EQL to the corresponding objects in
the source code.  The constraints on what kinds of objects may appear
as constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.

  Rationale:

  This proposal is consistent with what many people think of as the
  "traditional" semantics for QUOTE.  It gives users maximum flexibility
  about what kinds of objects may appear as constants.
   


Proposal QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS:

State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted.  Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime.  Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.

Any object may validly appear as a constant in code processed by EVAL
or COMPILE.  The constraints on what kinds of objects may appear as
constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.

  Rationale:

  This proposal is the most consistent with the semantics stated in CLtL.
  It gives users maximum flexibility about what kinds of objects may
  appear as constants.


Proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE:

State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted.  Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime.  Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.

The constraints on what kinds of objects may appear as constants
(described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply to EVAL and COMPILE as well as to
COMPILE-FILE.

  Rationale:

  This makes the rules for handling of constants consistent between
  EVAL, COMPILE, and COMPILE-FILE.  It gives implementors maximum 
  flexibility in handling constants in EVAL and COMPILE.


Current Practice:

Implementations in which COMPILE copies constants include PSL/PCLS and
Kyoto Common Lisp.  In Lucid Common Lisp, constants are not normally
copied by COMPILE, but since COMPILE does coalesce constants, it may
cause QUOTE to return an object which is not EQL to the object which
appeared in the source code.

There is known to be at least one implementation where expanding the
DEFUN macro causes all constants in the body of the function to be
copied.


Cost to implementors:

Proposal NO-COPYING would involve a significant cost in those
implementations where constants are now copied or coalesced by EVAL
and COMPILE.  Some implementations would also require substantial
changes to support proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS.  The
aspect that is likely to cause the most problems is that, in some
implementations, the garbage collector assumes that constants
referenced in compiled code have been copied to read-only storage and
do not need to be scanned or relocated.

Proposal SAME-AS-COMPILE-FILE has no adoption cost above what is
required to support issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION.


Cost to users:

Proposals COPYING-ALLOWED-BUT-NO-CONSTRAINTS and SAME-AS-COMPILE-FILE
may break some existing programs that assume constants in code
processed by EVAL or COMPILE are always EQL to the corresponding
objects in the source code.  Proposal SAME-AS-COMPILE-FILE may also
break existing programs that depend on referencing "undumpable"
constants in code processed by EVAL or COMPILE.  In both cases,
however, the behavior is already nonportable.  Both proposals would
permit implementations in which these programs now work to continue to
provide their existing behavior.


Benefits:

The semantics of QUOTE are clarified.


Discussion:

This issue subsumes issue QUOTE-MAY-COPY, which caused a very lengthy
debate on the cl-compiler mailing list.

Loosemore supports proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE,
since it requires essentially no conversion cost for implementors and
does not break any user programs that are not already nonportable.
-------