saving CLOS objects

[IRA@ELROND.RAD.WASHINGTON.EDU (Ira Kalet)]

Jerry Crane writes:

>Trying to find a method to save the slot values of a series of instantiated
>CLOS objects as a cohesive block vs. recording individual values and 
>re-instantiating all objects each time this program is needed.  Several of
>the slots are pointers to the same or different classes of objects.  Ideally,
>should be able to save to file and reload without total reprocessing.

We are writing a radiation treatment simulation system that needs to do 
this also, since we create cases, run simulations and save the results.
Although there are research projects looking at the idea of "persistent 
objects" and object databases, we don't see anything simple enough or 
settled enough to simply use.  We created a simple scheme for writing 
the data from the slots of an object to a text file, and recreating the 
instances from the contents of the text file.  The scheme supports 
having slots whose values are lists of other object instances, not 
necessarily of the same class, as well as ordinary writeable and 
readable lisp objects.

The functions that read and write data are implemented as ordinary
functions and are not dependent directly on the type of objects they
read and write.  They achieve this by calling generic functions that
provide class-specific information, namely, (slot-type object slotname)
returns a keyword specifying whether the slot named slotname is a simple
lisp object (in which case ordinary lisp input and output will do), a
list of objects, in which case an iterative, recursive call takes care
of the list, or a large (binary) array, in which case we put the data in
a separate file.  Also, since there is no way to get a list of slot
names for a class, that I know of, we provide a generic function
slots-to-save so the put-object function knows what slots to write out. 
It is a few pages of code, in entirety.

The class names are written to the file as well, so the get-object 
function can call make-instance as it reads the data.  The format is 
simple.

This scheme still incurs the overhead of make-instance, but it is hard 
to see short of solving the full-blown persistent object problem how you 
would avoid that.

We also support "references" to other objects, in that some slots have 
the name of another object instance (of a different class) as the value. 
In this case, the names persist because the objects referenced 
(descriptions of radiation treatment machines) are explicitly named 
externally anyway, so when they are read in, the names are always the 
same (and the symbols they are bound to are the same as well).

If anyone wants a copy of this stuff, let me know and I will mail the 
source files (maybe ten pages of text).

Ira Kalet
Radiation Oncology Dept.
University of Washington
Seattle, WA