[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
circular structures and bin files
Date: 22 Dec 87 14:08:50 EST
From: Timothy Daly <DALY@ibm.com>
Symbolics cannot handle the following in a compile-file.
(defun foo () '#1=(#1#))
This will fail complaining that bin files cannot handle
circular objects. We create circular objects all over the
place in our data structures and need to write them out.
Symbolics customer service recommends that we un-circularize
the objects first. Ha.
Does anyone have a fix for this behavior?
"Un-circularization" is not such a bad idea. If you have structs or
instances that point to each other, replacing such pointers with unique
identifiers is an easy way of linearizing the pointer structure to
preserve interconnectivity info without dumping objects to binary
redundantly. Circularity is also removed in the process, and all
structure is recreated at load time when unique identifiers are replaced
with new pointers (I have rudimentary code for this in flavors).
As for circular list structures, I'm not sure, although sys:%pointer
appears useful if you don't have another way of uniquely identifying
In the general case, how is the binary dumper/loader to know that you
don't 1want0 to dump the same object (or the contents of the same location
"circularly," considering that side-effects of dumping/loading may 1)
change the object and/or 2) remove the circularity before it becomes
a problem (e.g. creates a "very large" binary file). I think I agree
that the preferred 2default0 behavior might be for the dumper/loader to
automagically un- and re- circularize, but also that you can do that
much more easily and efficiently yourself given what you know about
your data types and structures.
Problems with circular structure in lisp are not unique to symbolics
software. The reference-counting garbage collectors used in many
lisp systems typically don't succeed at detecting that dangling circular
structures are garbage, for example.
IBM T.J.Watson Research
Yorktown Heights, N.Y.
-- William D. Gooch