Re: Issue: LOAD-OBJECTS (Version 3)

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

There are a couple of small changes that seem warranted:

   MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
   SLOT-VALUE-USING-CLASS.  MAKE-LOAD-FORM-FROM-SLOTS is better,
   except for form/from dyslexia.  MAKE-LOAD-FORM-FOR-SLOTS ?

   Maybe there should be a SIMILAR-AS-CONSTANTS generic function
   for the benefit of CONSTANT-COLLAPSING.  In the absence of that
   we're just using EQ.

On the subject of this proposed alternative:

    Date: Sat, 11 Mar 89 18:42:56 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Have two generic functions, not one.  The first would get called by
    compile-file and it would return a list of components (or whatever)
    that are required to reconstruct the object.  The compiler would dump
    this list of objects in its usual way.  The loader would apply the
    second generic function to this list to reconstruct the object.  

This is exactly the way I did the first implementation of this idea,
back in about 1978.  It didn't work very well, basically for two reasons.
One is that representing information in the form of lists is pretty
impoverished and it's very easy to get the list the wrong length or
out of order; it's also more difficult than it should be to make
upward-compatible changes, because the new format always has to be
a superset of the old format.  Forms are more general.  You can make
upward-compatible changes by inventing a new function name and keeping
the old function name around forever with the old semantics; this also
ensures an undefined-function error if the new format is loaded into
the old system.

The second reason is more serious.  The way you propose cannot be nicely
extended to deal with circular structures, because it fails to separate
object creation from object initialization.  The second generic function
does both operations.  My application used circular structures
extensively and had a fairly horrible kludge for them, involving standin
objects that were replaced with the correct objects later in loading;
this was fragile and permeated the reconstruction methods, all the worst
characteristics for this kind of thing.

On the subject of forms versus functions as the interface, I think
David Gray has expressed very well the reasons why that is not
practical, at least at Common Lisp's present stage of development.

I've read all the mail on the subject, but I stand by LOAD-OBJECTS
version 3.  There may be more thought behind this proposal than is
apparent at first glance.