putting CLOS objects in binfiles

[jrose@Sun.COM (John Rose)]

It's a shame that there's no provision in CLOS for
saving objects in binfiles.  It's going to blow up
in our faces when CLOS gets ubiquitous enough for
people to use CLOS objects without being aware of it.
(I.e., when lower layers of layered products use
CLOS without advertising the fact.)

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.
Saving one object got me a binary file of over 100Kb.
(In Lucid 3.0.)

People expect to use binary files to store data in!
If CLOS objects can't be dumped, it will effectively
mean that you can't store data in Common Lisp binary files.

It's like that ancient MIT story about Lisp packages:
The first time they tried to fasdump a package object,
much of the Lisp world went along with it.  This kind
of behavior has to be fixed in real systems.  (As
with our future unaware user of CLOS, the MIT package
fasdump meltdown happened unexpectedly.  A bare "FOO:"
used to mean the FOO package object, instead of its present
meaning.)

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

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.  It can return NIL, which means to do
some system default, like a GC-style walk.
The reconstructor form would be stored in
lieu of the real object into the binary file,
adorned with #, for evaluation at load time.

A different way to factor things would be to
have a function RECONSTRUCTOR-INITS which
computes at dump time a class name and keyword/value
plist, and a function RECONSTRUCT-INSTANCE analogous
to and equivalent by default to MAKE-INSTANCE,
which is called at load time on the saved data.

The fasdumper (and other utilities, like an object
migrator) could use protocols like these to handle
user-defined types correctly.

Using #, is not a solution:  A fasdumper needs to
correctly handle CLOS objects wherever they occur
in the data structures being dumped.

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.

			-- John