Standard-objects in quoted constants

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 14 Nov 88 11:54:29 PST
    From: cperdue@Sun.COM (Cris Perdue)

    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; 

I think this issue was discussed at length by the CLOS committee a year
or more ago, but I don't have the results of the discussion on hand.
It was not put into 88-002R, being outside the purview of that document
I guess.

This can only be done with a protocol, because only the programmer of
a particular object class knows how to do it correctly.  Not all of the
state of an object is necessarily directly visible as slot values, and
indeed it is generally a violation of abstraction for any outside agent
(which includes the file compiler) to call SLOT-VALUE rather than
interfacing through generic functions.

There should be a generic function of one argument that returns a Lisp
form which, when evaluated, returns an object "equivalent" to the
argument.  You can call it COPY-FOR-COMPILE-FILE if you can't think of a
better name (which should not be hard!).  This generic function ought to
work for built-in and structure types also, since methods might call it
recursively, although in general a method would just return a form and
assume that the file compiler would take care of all the subforms.

I strongly believe that the default method should signal an error,
although I know there are proponents of various default implementations
that they think meet the needs of some fraction of users.  It would
be reasonable to provide one or more of these default implementations
as functions so that it would be easy to write a method that uses a
particular implementation, when you know it's the right one for you.

		     how references to classes are resolved, e.g. in some
    fashion by name; etc..  

In general it would be done by name, but again only the programmer of
a particular object class knows how to do it correctly.

    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.

I think only the programmer of a particular object class knows the answer
to this, therefore Common Lisp and CLOS should not impose an answer.

I think I would object to your proposed rules for arrays and hash tables
if I thought about them more, but since that wasn't the subject of this
particular message, and since I don't have time to think about them more
right now, I'll let that go with just the remark that your array rules
may be overdoing it (why preserve adjustableness if they are immutable?
preserving displacedness is likely to cause trouble), and your hash
table key coalescing rules may not be possible to implement if it
implies that keys that start out EQ to other constant references (in the
same file? or what?) must remain so, when those other constant references
are subject to coalescence and may have appeared earlier in the file.