I am having difficulty inspecting the value of the *PRINT-(mumble)*
variables in ACL 6.2. The REPL and APROPOS disagree on what the value
of these variables are. Has anybody else noticed this behavior?
CL-USER(1): (apropos "*PRINT-LE")
*PRINT-LEVEL* value: 3
*PRINT-LENGTH* value: 4
TPL:*PRINT-LEVEL* value: 5
TPL:*PRINT-LENGTH* value: 10
CL-USER(2): *PRINT-LENGTH*
NIL
CL-USER(3): *PRINT-LEVEL*
NIL
CL-USER(4):
"Carl Shapiro" <·············@panix.com> wrote in message ····················@panix3.panix.com...
> I am having difficulty inspecting the value of the *PRINT-(mumble)*
> variables in ACL 6.2. The REPL and APROPOS disagree on what the value
> of these variables are. Has anybody else noticed this behavior?
>
> CL-USER(1): (apropos "*PRINT-LE")
> *PRINT-LEVEL* value: 3
> *PRINT-LENGTH* value: 4
> TPL:*PRINT-LEVEL* value: 5
> TPL:*PRINT-LENGTH* value: 10
> CL-USER(2): *PRINT-LENGTH*
> NIL
> CL-USER(3): *PRINT-LEVEL*
> NIL
> CL-USER(4):
Obviously the code for APROPOS is setting them...
CL-USER(1): (let ((*print-level* 10)
(*print-length* 45))
(apropos '*print-le)
(values *print-level* *print-length*))
*PRINT-LEVEL* value: 3
*PRINT-LENGTH* value: 4
TPL:*PRINT-LEVEL* value: 5
TPL:*PRINT-LENGTH* value: 10
10
45
--
Geoff
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> Obviously the code for APROPOS is setting them...
>
> CL-USER(1): (let ((*print-level* 10)
> (*print-length* 45))
> (apropos '*print-le)
> (values *print-level* *print-length*))
> *PRINT-LEVEL* value: 3
> *PRINT-LENGTH* value: 4
> TPL:*PRINT-LEVEL* value: 5
> TPL:*PRINT-LENGTH* value: 10
> 10
> 45
In a private e-mail somebody suggested that APROPOS may have been
rebinding these specials for its own use. After some minor groveling
with DISASSEMBLE, it seems that EXCL::BRIEFLY-DESCRIBE-SYMBOL, the
function which apparently prints out the matching symbol names and
their information, does rebind both *PRINT-LENGTH* and *PRINT-LEVEL*.
This behavior seems to be an oversight in the design of APROPOS. One
would assume that a tool which is designed to inspect some piece of
state would not be changing that piece of state (even if the change is
temporary) in the process.
Comments?
Carl Shapiro <·············@panix.com> writes:
> "Geoffrey Summerhayes" <·············@hotmail.com> writes:
>
> > Obviously the code for APROPOS is setting them...
> >
> > CL-USER(1): (let ((*print-level* 10)
> > (*print-length* 45))
> > (apropos '*print-le)
> > (values *print-level* *print-length*))
> > *PRINT-LEVEL* value: 3
> > *PRINT-LENGTH* value: 4
> > TPL:*PRINT-LEVEL* value: 5
> > TPL:*PRINT-LENGTH* value: 10
> > 10
> > 45
>
> In a private e-mail somebody suggested that APROPOS may have been
> rebinding these specials for its own use. After some minor groveling
> with DISASSEMBLE, it seems that EXCL::BRIEFLY-DESCRIBE-SYMBOL, the
> function which apparently prints out the matching symbol names and
> their information, does rebind both *PRINT-LENGTH* and *PRINT-LEVEL*.
This is true.
> This behavior seems to be an oversight in the design of APROPOS.
Not at all.
So, why would we explicitly bind *print-level* and *print-length*
around certain functionality that is not explicitly dependent on it?
Answer: Safety. Example:
CL-USER(1): (setq xyzzy '#1=(666 . #1#))
(666 666 666 666 666 666 666 666 666 666 ...)
CL-USER(2): xyzzy
(666 666 666 666 666 666 666 666 666 666 ...)
CL-USER(3): (apropos :xyzzy)
XYZZY value: (666 666 666 666 ...)
:XYZZY value: :XYZZY
CL-USER(4): (print xyzzy)
(666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666
666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666
666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666
666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666 666
...
[at this point, I have to kill the process.]
> One
> would assume that a tool which is designed to inspect some piece of
> state would not be changing that piece of state (even if the change is
> temporary) in the process.
A mandate like that would be a slippery slope. Obviously, it is
desirable to minimize the Heisenberg Effect in an introspective system,
but it's impossible to do fully without in some way removing the
inspecting tool from the system, thereby making it no longer
introspective.
The safety tradeoff is a strong one.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Hi Duane,
Thanks for following up.
Duane Rettig <·····@franz.com> writes:
> A mandate like that would be a slippery slope. Obviously, it is
> desirable to minimize the Heisenberg Effect in an introspective system,
> but it's impossible to do fully without in some way removing the
> inspecting tool from the system, thereby making it no longer
> introspective.
I wholly understand why one would want to constrain the behavior of
the printer when traversing uncharted and possibly hostile corners of
some as yet unexplored package. But, I do not believe that rebinding
specials is an inseparable part of employing the kind of safety
measures which keep APROPOS from spinning out of control. Why not use
WRITE for outputting values? It receives as arguments, variables to
control the printer.
> The safety tradeoff is a strong one.
I do not see a need for this tradeoff. Can't everybody can get what
they want in this particular situation?
I routinely call (apropos "*PRINT-") to determine the state of all the
printer control variables. Discovering that a useful and familiar
tool like APROPOS does not behave as one has come to expect is truly
disheartening.
Carl Shapiro <·············@panix.com> writes:
> Hi Duane,
>
> Thanks for following up.
No problem.
> > The safety tradeoff is a strong one.
>
> I do not see a need for this tradeoff. Can't everybody can get what
> they want in this particular situation?
Yeah, I guess the bindings could be made later, when the printing
actually happens, after values have been collected. This looks
like what Steve saw.
> I routinely call (apropos "*PRINT-") to determine the state of all the
> printer control variables. Discovering that a useful and familiar
> tool like APROPOS does not behave as one has come to expect is truly
> disheartening.
I can understand this.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Steven M. Haflich
Subject: Re: Strange ACL printer variable behavior
Date:
Message-ID: <3E9F4D92.4030203@alum.mit.edu>
Duane Rettig wrote:
>>This behavior seems to be an oversight in the design of APROPOS.
>
> Not at all.
> ...
> The safety tradeoff is a strong one.
Yes, but IMO to make the rebinding visible is an oversight, and
a minor misfeature that is easily fixed. I expect it will be
next release.
Carl Shapiro <·············@panix.com> writes:
> "Geoffrey Summerhayes" <·············@hotmail.com> writes:
>
> > Obviously the code for APROPOS is setting them...
> >
> > CL-USER(1): (let ((*print-level* 10)
> > (*print-length* 45))
> > (apropos '*print-le)
> > (values *print-level* *print-length*))
> > *PRINT-LEVEL* value: 3
> > *PRINT-LENGTH* value: 4
> > TPL:*PRINT-LEVEL* value: 5
> > TPL:*PRINT-LENGTH* value: 10
> > 10
> > 45
>
> In a private e-mail somebody suggested that APROPOS may have been
> rebinding these specials for its own use. After some minor groveling
> with DISASSEMBLE, it seems that EXCL::BRIEFLY-DESCRIBE-SYMBOL, the
> function which apparently prints out the matching symbol names and
> their information, does rebind both *PRINT-LENGTH* and *PRINT-LEVEL*.
>
> This behavior seems to be an oversight in the design of APROPOS. One
> would assume that a tool which is designed to inspect some piece of
> state would not be changing that piece of state (even if the change is
> temporary) in the process.
I certainly wouldn't expect APROPOS to rebind *print-level* any more
than I'd expect it to rebind *standard-output* or *package*.
On the other hand, I *could* see it binding a restart or two so that
errors thrown while generating the output wouldn't cause the function
to go down in flames.
"Carl Shapiro" <·············@panix.com> wrote in message ····················@panix3.panix.com...
> "Geoffrey Summerhayes" <·············@hotmail.com> writes:
>
> > Obviously the code for APROPOS is setting them...
> >
> > CL-USER(1): (let ((*print-level* 10)
> > (*print-length* 45))
> > (apropos '*print-le)
> > (values *print-level* *print-length*))
> > *PRINT-LEVEL* value: 3
> > *PRINT-LENGTH* value: 4
> > TPL:*PRINT-LEVEL* value: 5
> > TPL:*PRINT-LENGTH* value: 10
> > 10
> > 45
>
> In a private e-mail somebody suggested that APROPOS may have been
> rebinding these specials for its own use. After some minor groveling
> with DISASSEMBLE, it seems that EXCL::BRIEFLY-DESCRIBE-SYMBOL, the
> function which apparently prints out the matching symbol names and
> their information, does rebind both *PRINT-LENGTH* and *PRINT-LEVEL*.
>
> This behavior seems to be an oversight in the design of APROPOS. One
> would assume that a tool which is designed to inspect some piece of
> state would not be changing that piece of state (even if the change is
> temporary) in the process.
>
> Comments?
>
But neither APROPOS nor DESCRIBE, which suffers the same 'problem', are
constrained to produce the value of a symbol, let alone the 'correct' one.
In other words, these tools are designed to inspect the state of the Lisp
process, but not in the area of the specific behaviour you want.
--
Geoff