putting CLOS objects in binfiles

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

    Date: Fri, 15 Jul 88 12:42:03 PDT
    From: jrose@Sun.COM (John Rose)

    It's a shame that there's no provision in CLOS for
    saving objects in binfiles.

CLOS doesn't address this because Common Lisp doesn't.
Note that CL provides no way to write a "binfile" other than
COMPILE-FILE.  Of course you can trick COMPILE-FILE into
doing anything, using macros, so that's no real limitation.

    The reason is that the default object fasdumper
    does a GC-style walk over the object, dumping not
    only the object but also its class hierarchy.

That's a statement about some particular implementation,
not about Common Lisp.

    Can a fix for this get sneaked into Chapter 3 of
    the CLOS spec?

Chapter 3 would be the wrong place.  This is logically
a Chapter 2 facility, in the same vein as PRINT-OBJECT.

The status of CLOS is that it has been accepted by X3J13
into the same status as CLtL.  This means that it is open to
cleaning up and improvement through the normal X3J13
mechanisms, and I think your suggestion makes a great deal
of sense and should be done through those mechanisms.  Do
you want to make the proposal (I don't know if you're
familiar with X3J13), or do want to ask someone on the
CLOS committee to do it?

    Here's essentially what's needed:  A generic function
    (called, say, RECONSTRUCTOR-FORM) which returns a
    Lisp form to evaluate to reconstruct any given
    object.  

This is fine.  It's how Flavors does it, so there is some
precedent.  The only problem with this technique is that it
doesn't cope well with circular structures, which can only
be handled by separating creation of the objects from filling
them in (and even that doesn't work in general, for reasons
too complicated to get into here).

	     It can return NIL, which means to do
    some system default, like a GC-style walk.

I think this is a really bad idea.  My experience is that there is no
default that is right for all objects and any attempt to offer a default
does users more harm than good, because the default gets used for cases
where it can't work any causes hard to understand problems.
Furthermore, if there was a default, it should be implemented by a
default method for the generic function, not by special-casing NIL.  I'd
prefer that there be no default and hence if the user has not defined a
method, an error is signalled.

    Here's my immediate problem:  I want to build objects
    which represent predicates in a special purpose query
    language, and I want them to be uniquified, like pathnames
    on the Lisp Machine.  (They cache things like compiled Lisp
    code, so it's expensive to build new copies.)  Such things
    do not dump properly, and even if a simple patch were to
    be applied (say, to dump a class symbol instead of a class),
    a simple-minded load routine would not uniquify them.

I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded.  You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly.
I think most implementations do guarantee object identity within
a single COMPILE-FILE, even though they're not required to.
This is not a CLOS issue, it applies to all objects for which EQ
is defined.