Compilation implications

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

[Responding to only one portion of your message]

    Date: Thu, 29 Dec 88 04:52:47 PST
    From: Jon L White <jonl@lucid.com>

		  (A) "Reconstructor" functions for instances

    We at Lucid are getting more and more requests for a coherent "Reconstructor"
    protocol (well, they are usually couched in ill-advised terms about making
    FASLOUT user-extensible, but we've already seen this issue before).  Does 
    anyone have any plans to work on this problem?  Didn't someone recently
    say that Symbolics has some possibly-private Reconstructor capability?
    What is the feeling about the Symbolics facility  (I don't know anything
    about it).

It's very simple and effective.  There is a generic function (never mind its
name, the current stupid name was chosen about a dozen years ago) that is
applied to one argument and returns a Lisp form.  The intent is that when
that form is evaluated at some later time, it should return an object that
is equivalent to the argument.  Using EVAL provides full generality.  Of
course the compiler/fasdumper/fasloader is allowed to optimize special-case
forms that it recognizes, rather than always calling EVAL at load time.
This generic function is supported for standard-object and structure-object
(using CLOS terminology).  A good name would be MAKE-RECONSTRUCTION-FORM or
perhaps MAKE-LOAD-FORM (why introduce a new word "reconstruct" when we
already have the word "load" which really means the same thing?).

In addition, there is a level of protocol built on top of this that some
things use.  There is a mixin flavor that provides a method for the
first generic function; it returns a form that calls MAKE-INSTANCE with
(TYPE-OF SELF) as the first argument, and the remaining arguments
obtained by calling another generic function whose methods' results are
usually combined with APPEND.  This provides a convenient way for
multiple classes to contribute to the reconstruction of an object;
each class supplies the initargs that are relevant to that class.
I'd suggest MAKE-LOAD-INITARGS for the name of this generic function
and LOAD-USING-INITARGS-MIXIN for the name of the class.  I haven't put
a great deal of thought into these names.

There is also a method that uses the simple-minded reconstruction
technique of just looking at the slots that have :INITARGs and calling
MAKE-INSTANCE with the reconstructed values of those slots.

An important thing to realize is that the default for a standard-object
is to signal an error; there is no default method on standard-object
for either of these generic functions.  That's important because no
default reconstruction method can be correct for all objects, and we
feel it's better to make the programmer pick a method explicitly than
to supply a default that might just make trouble.

I don't remember why the CLOS committee didn't put anything like this
into the proposed standard.  Maybe we thought it was the Compiler
committee's business, maybe we had some disagreement, or maybe we
just ran out of time.

    One might ask, "How do ``instances'' come to the attention of FASLOUT?"
    They can appear as a quoted constant; hence, Cris Perdue's query:
	Date: Mon, 14 Nov 88 11:54:29 PST
	From: cperdue@Sun.COM (Cris Perdue)
	To: cl-object-oriented-programming@sail.stanford.edu
	Subject: Standard-objects in quoted constants
    to which Moon replied later that day about the need for a reconstructor
    protocol.  I should think it rare for quoted instances to appear directly
    in code files.  But there are some important exceptions that, indirectly,
    introduce "constants" into a file; for example, the use of #. to emulate 
    a FASDMP facility; and also macro-generated code that produces otherwise
    unREADable forms.

Rare, but not unheard of.  Note also two other common sources of non-built-in
type objects in compiled-code files:  1. Any type that has a read syntax is
likely to appear as a quoted constant or inside a quoted constant.  Pathnames
are one example, user programs often define others.  2. Symbolics has a
facility for creating a compiled-code file full of data (rather than compiled
Lisp programs), which is convenient because it's an efficient binary file
that you can load with LOAD instead of having to write your own loader.
(This can be simulated in any Common Lisp implementation by creating a dummy
file that consists of just one call to a special macro, defining the macro
to expand into forms to put the data where you want it, then using COMPILE-FILE
on that dummy file).

Most of the rest of your message concerns the metaobject protocol and I can't
answer it.  I'll just note that in Flavors we generate metaobjects at compile
time, but we never put them (to speak loosely) into the compiled-code file;
instead macros like DEFFLAVOR and DEFMETHOD expand into Lisp code that obtains
new metaobjects at load time, based on the class name and generic function name.
I don't see how any other way could work, actually, since two distinct compiled
files that refer to a class by the same name must end up referring to the
same metaobject after loading.  In Flavors we don't have anonymous classes nor
anonymous generic functions, so we don't have to solve those issues.