*print-circle*

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

    Date: Tue, 20 Jan 87 14:06:00 MST
    From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)

    Is there a compelling reason why *print-circle* is not required to identify
    shared substructures, as well as circular structures?  The "obvious" (to me)
    implementation will detect both.  

Circular structures can be identified with a little less overhead, since the
amount of state needed at any moment is proportional to the depth of the
structure rather than to the total size of the structure.  Also the state
has the right lifetime to be stored in a stack, so a non-consing implementation
can be used easily.  Neither of these strikes me as compelling!

				      Being able to write out a complex, linked 
    structure with the guarantee that its topology will be preserved when it
    is read back in again seems like a very useful thing.  I'd be glad to share
    my code to do this if there is sufficient demand for it.

Symbolics' implementation of *print-circle* looks for shared substructures, and
it wouldn't surprise me if a lot of other implementations also do so.  It
seems like a good idea.  I could imagine a user demand for separate control
of circularity detecting and sharing detection; one side-effect of full
shared substructure detection that surprised me when I first saw it was
the result of

  (let ((*print-circle* t))
    (print (macroexpand-all '(dolist (x y)
			       (dolist (w x)
				 (print w))))))

because there is some substructure shared between the two expansions of
the dolist macro; in our case the list (NIL) happens to be shared
and so the second occurrence turns into a #1#.