Standard-objects in quoted constants

[cperdue@Sun.COM (Cris Perdue)]

The compiler committee has been discussing the following proposal
(among others) on the cl-compiler mailing list.  Treatment of CLOS
objects in quoted constants compiled into files is a nontrivial issue,
and I think it is very important for the CLOS committee to contribute
to this aspect of quoted constants.

Here is the latest version of CONSTANT-COMPILABLE-TYPES:SPECIFY, which
intends to support CLOS objects in file-compiled constants but does
not yet actually do so.  Issues are whether the result of
file-compiling and then loading simply retains slot names and slot
values, or whether there is a protocol to reconstruct a file-compiled
standard-object; how references to classes are resolved, e.g. in some
fashion by name; etc..  

Note that it is likely that we will permit implementations to make the
"basic attributes" of objects of almost all built-in types immutable
when appearing in file-compiled constants.  It is important for us to
hear from you if you want slot values in file-compiled
standard-objects in quoted constants to be mutable.

We are also in the process of requesting information on current
practice from implementors.


Issue:		CONSTANT-COMPILABLE-TYPES
References:	CLtL pp. 56, 77-80, 324
		Issue CONSTANT-MODIFICATION
		Issue CONSTANT-CIRCULAR-COMPILATION
		Issue CONSTANT-ARRAY-ATTRIBUTES
Category:	CLARIFICATION, ADDITION
Edit history:	11/07/88, V1 by Cris Perdue
		11/14/88, V2 by Cris Perdue
Status:		DRAFT

Problem description:

A Common Lisp compiler must record information about constants so that
a "corresponding" constant can be created at load-time.  This is
fundamentally a problem of file-compilation.  For in-core compilation
it appears to be acceptable to use the constants appearing in the
interpreted code exactly as-is, though this is not required.  We
assume that compiled constants may be stored (i.e. on disk) in an
implementation-dependent manner.

Proposal:  CONSTANT-COMPILABLE-TYPES

- References to symbols are left for load-time resolution.
- Aggregate objects are traversed and their components are also
  recorded.
- Numbers and characters, i.e. objects that must be compared with EQL
  rather than EQ, are not aggregate in the sense being discussed here.
  They may appear in constants, and numbers and characters appearing
  in constants have the same requirements on their behavior as numbers
  and characters in any other context.

For aggregate objects there must be some policy on supporting
circular structures and otherwise shared structures.  That is not
specified here.

Each aggregate object has certain Basic Attributes (B.A.'s?)
These are recorded as the constant is compiled and they are also
traversed.

Symbol	     No symbol is a constant in the sense considered here, but
	     references to symbols are permitted in any constant.

Cons	     CAR, CDR

Array	     All elements, fill pointer existence,
	     fill pointer value if present,
	     dimensions, element-type, adjustable-array-p, displaced-to,
	     displaced-index-offset

Structure    Slot values, name of structure type

Hash-table   Keys and values.  The table's test is of course unchanged also.
	     In an EQ hash table, keys that are not EQ must not be
	     coalesced.  In an EQL hash table, keys that are not EQL
	     must not be coalesced (or made EQL).  (These are
	     exceptions to the general rule that constants may be
	     coalesced.)  In short, hash table keys that are initially
	     distinct must remain distinct across the process of
	     file-compilation and loading.

Readtable    Character syntax type for each character in the table;
	     function for each readmacro character, mappings for
	     dispatch macros; terminating or nonterminating for each
	     readmacro.

Pathname     Each pathname component

Package, Stream
             It is an error for a package, stream, or compiled-function
	     to appear ina compiled constant, but the
	     language may be extended in the future to support certain
	     cases.

Random-state
	     Random-states have no basic attributes, and only the
	     "random" operation applies to them (other than PRINT).
	     Let us say that two random-states are functionally
	     equivalent if applying "random" to them repeatedly always
	     produces the same pseudo-random numbers.  Since compiled
	     constants may become immutable, applying "random" to a
	     compiled-constant random-state is an error.  However,
	     all copies made via make-random-state must be
	     functionally equivalent and functionally equivalent to
	     the one that appeared in the source code.

Function     Function constants that are not compiled-functions are
	     permitted in compiled constants.

Generic-function, Method
	     Help is needed from the CLOS committee to determine what
	     to do here.

Standard-object
	     Help is needed from the CLOS committee to determine what
	     do do here.

Rationale:

This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.

Current practice:

This appears to be a reasonable approximation to what is done by the
Franz and Lucid implementations.  The Explorer apparently does not
currently guarantee retention of displaced-to and
displaced-index-offset attributes.

Adoption cost:

Not known.  Probably moderate.  The cost would be to implementors
rather than users since this part of the language is currently
underspecified.

Benefits:

Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.

Conversion cost:

Nil.  Less than the cost of leaving things unspecified.

Esthetics:

Since there is no adequate definition at present, a fuller definition
would be more esthetic.

Discussion:

This would subsume isse CONSTANT-ARRAY-ATTRIBUTES if accepted.