Re: Recursive printing.

[Dan Hoey <hoey@nrl-aic.ARPA>]

    Date: 0  0 00:00:00 EST
    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>

    What exactly is Hoey's proposal?  It seems to be twofold.

    1.  Depth abbreviation is performed automatically by WRITE.

    2.  A top-level print is started when you print to a different stream
        from the last print.

    Is this correct?

No, that isn't what I proposed.

Point 1 is the rationale for the proposal.  I would like to avoid
forcing people to scatter :RECURSIVELY-P's throughout their print
functions.

I proposed that a depth be maintained for every stream, and that WRITE
to a stream should increment that stream's depth at entry and restore
the depth on exit.

Your point 2, if I understand it correctly, is that there be some
notion of the current stream, and a single depth that applies to
whatever stream is current.  A WRITE to the current stream increments
the depth; a WRITE to another stream sets the depth to 1 and sets the
current stream to that stream.  Both depth and current stream are
restored on exit from WRITE.

Both proposals work for the normal case, when the user's printing
function does no output except for the object being printed.

Both proposals work for the case I am most concerned about, where
printing an object involves normal output on another stream.

Where the proposals differ is when printing an object involves output
on another stream, and the output on the other stream involves output
on the first stream.  For instance, with

    (defun astronaut-print-fn (obj s depth)
        (format s "[ ~S in space ]"
		(or (astro-name obj)
		    (progn (format (astro-control obj)
				   "My buddy is ~S.  Who am I?~%"
				   (astro-buddy obj))
			   (read (astro-control obj))))))

if two anonymous astronauts are each other's buddies, they will try to
print each other to their respective name servers.  If the name servers
are different, your proposal does not allow a depth cutoff, whereas mine
does.

I can't think of any reason why we should prefer one proposal over the
other, but they are different.

Dan