[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursive printing.
- To: "BACH::GREEK" <greek%bach.decnet@dec-hudson.ARPA>
- Subject: Re: Recursive printing.
- From: Dan Hoey <hoey@nrl-aic.ARPA>
- Date: Thu, 21 Nov 1985 22:18:00 -0000
- Cc: Common-lisp@su-ai.ARPA
- In-reply-to: "BACH::GREEK"'s message of 0 0 000000 EST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <email@example.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
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?~%"
(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
I can't think of any reason why we should prefer one proposal over the
other, but they are different.