[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: :Structure-Print and *print-level*
- To: Guy Steele <gls@THINK-AQUINAS.ARPA>
- Subject: Re: :Structure-Print and *print-level*
- From: Dan Hoey <hoey@nrl-aic.ARPA>
- Date: Thu, 21 Nov 1985 17:26:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Guy Steele's message of Thu, 21 Nov 85 1125 EST
The idea I had had in mind was that the defstruct printing function
would look something like
(defun astronaut-print-fn (obj s depth)
(format s "[***>>> ASTRONAUT! Name: ")
(write (astro-name obj) :stream s :level (- *print-level* depth))
(format s " <<<***]"))
However, this is not quite the right thing if the originally specified
:level argument had not defaulted to the value of *print-level*.
Which arises if the printed representation of an astronaut can contain
the p. r. of another astronaut. But the real problem with this method
is that it confuses the two notions of print level and of print depth.
I see no problem with the hidden variable representing the depth in
printing functions. My expectation is that this variable should always
be incremented on entry to the function WRITE, and restored on exit.
In this way a user's printing functions that call PRINT or WRITE behave
the same way that WRITE does when it calls itself recursively.
One thing that may not be immediately apparent is that the depth should
be specific to each stream, so that a printing function that uses WRITE
on another stream (presumably as part of determining what its output
should be) is not affected by the depth of the stream that it is to
print its object on.
The assumption here is that during the period when a WRITE to a stream
is in progress, any recursive call to WRITE on that stream is for the
purpose of printing a part of the object for which the first WRITE was
issued. I can imagine cases for which this assumption might not be
-- some sort of random access scheme with an automatically-maintained
index of astronauts in some other part of the file, or
-- a debugging trap or trace output that occurs during printing,
where some extraneous material will appear in the middle of the
printed representation of the object,
but I think that both of these uses can be implemented in ways that do
not need to know how to access the hidden variable.