print-circle and describe-variable

print-circle and describe-variable

[Lennart Borgman (gmail)]

Sometime ago we had a discussion about printing variables with recursive 
structures. As I remember it the conclusion was that we could not set 
print-circle to t generally now. But is there something that prevents 
describe-variable from let-bounding `print-circle' to t? I think this 
would be convenient.

Re: print-circle and describe-variable

[Richard Stallman]

    Sometime ago we had a discussion about printing variables with recursive 
    structures. As I remember it the conclusion was that we could not set 
    print-circle to t generally now. But is there something that prevents 
    describe-variable from let-bounding `print-circle' to t? I think this 
    would be convenient.

It sounds like a good idea to me.  Does anyone know of a reason not to
do it?

Re: print-circle and describe-variable

[Stefan Monnier]

>     Sometime ago we had a discussion about printing variables with recursive 
>     structures. As I remember it the conclusion was that we could not set 
>     print-circle to t generally now. But is there something that prevents 
>     describe-variable from let-bounding `print-circle' to t? I think this 
>     would be convenient.

> It sounds like a good idea to me.  Does anyone know of a reason not to
> do it?

I can think of one: too late.


        Stefan

Re: print-circle and describe-variable

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>     Sometime ago we had a discussion about printing variables with recursive 
>>     structures. As I remember it the conclusion was that we could not set 
>>     print-circle to t generally now. But is there something that prevents 
>>     describe-variable from let-bounding `print-circle' to t? I think this 
>>     would be convenient.
> 
>> It sounds like a good idea to me.  Does anyone know of a reason not to
>> do it?
> 
> I can think of one: too late.


But we do believe that print-circle makes it possible to print out 
recursive structures, or? And we do not believe that it disturbs 
printing out non-recursive structures (except that it gets a bit 
slower), or?

Could it make much harm then if we let describe-variable use it? And is 
it not a bug that Emacs hangs and eats all memory if you try to display 
a recursive structure with describe-variable?

Re: print-circle and describe-variable

[Eli Zaretskii]

> Date: Mon, 09 Apr 2007 03:00:46 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> > I can think of one: too late.
> 
> But we do believe that print-circle makes it possible to print out 
> recursive structures, or? And we do not believe that it disturbs 
> printing out non-recursive structures (except that it gets a bit 
> slower), or?
> 
> Could it make much harm then if we let describe-variable use it? And is 
> it not a bug that Emacs hangs and eats all memory if you try to display 
> a recursive structure with describe-variable?

Lennart, there will always be ``one more bug''.  If we strive to
release Emacs without bugs at all, we will never release!

This particular bug is not serious enough to risk postponing the
release.

Re: print-circle and describe-variable

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Mon, 09 Apr 2007 03:00:46 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: rms@gnu.org, emacs-devel@gnu.org
>>
>>> I can think of one: too late.
>> But we do believe that print-circle makes it possible to print out 
>> recursive structures, or? And we do not believe that it disturbs 
>> printing out non-recursive structures (except that it gets a bit 
>> slower), or?
>>
>> Could it make much harm then if we let describe-variable use it? And is 
>> it not a bug that Emacs hangs and eats all memory if you try to display 
>> a recursive structure with describe-variable?
> 
> Lennart, there will always be ``one more bug''.  If we strive to
> release Emacs without bugs at all, we will never release!


I am disturbed by this particular bug, but of course recursive 
structures are not that common. However describe-variable is one of the 
few places where print-circle really makes a difference and where the 
chance that it disturbs something is quite small.

Re: print-circle and describe-variable

[Stefan Monnier]

> But we do believe that print-circle makes it possible to print out
> recursive structures, or? And we do not believe that it disturbs printing
> out non-recursive structures (except that it gets a bit slower), or?

Actually, I believe it does affect printing non-circular structures in more
ways than just by making it slower.

Try (let ((print-circle t) (toto (list 2))) (prin1 (list toto toto)))

In some cases, this is a good feature, but in many other cases it can be
very confusing.


        Stefan

Re: print-circle and describe-variable

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> But we do believe that print-circle makes it possible to print out
>> recursive structures, or? And we do not believe that it disturbs printing
>> out non-recursive structures (except that it gets a bit slower), or?
> 
> Actually, I believe it does affect printing non-circular structures in more
> ways than just by making it slower.
> 
> Try (let ((print-circle t) (toto (list 2))) (prin1 (list toto toto)))
> 
> In some cases, this is a good feature, but in many other cases it can be
> very confusing.


Interesting, but is not that just another bug?

Re: print-circle and describe-variable

[Richard Stallman]

    >     Sometime ago we had a discussion about printing variables with recursive 
    >     structures. As I remember it the conclusion was that we could not set 
    >     print-circle to t generally now. But is there something that prevents 
    >     describe-variable from let-bounding `print-circle' to t? I think this 
    >     would be convenient.

    > It sounds like a good idea to me.  Does anyone know of a reason not to
    > do it?

    I can think of one: too late.

It's not too late for this.  This is a fix for a problem that can
cause errors showing the value of a variable.  It can't cause any
problem worse than the existing problem.

Do you see any technical reason why this change would be bad?

Re: print-circle and describe-variable

[Chong Yidong]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Stefan Monnier wrote:
>>> But we do believe that print-circle makes it possible to print out
>>> recursive structures, or? And we do not believe that it disturbs printing
>>> out non-recursive structures (except that it gets a bit slower), or?
>>
>> Actually, I believe it does affect printing non-circular structures in more
>> ways than just by making it slower.
>>
>> Try (let ((print-circle t) (toto (list 2))) (prin1 (list toto toto)))
>>
>> In some cases, this is a good feature, but in many other cases it can be
>> very confusing.
>
>
> Interesting, but is not that just another bug?

Nope.  When print-circle is on, the printer takes note of shared
substructures.  It's just that in this case, taking note of shared
substructure obfuscates the value.

Re: print-circle and describe-variable

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Stefan Monnier wrote:
>>>> But we do believe that print-circle makes it possible to print out
>>>> recursive structures, or? And we do not believe that it disturbs printing
>>>> out non-recursive structures (except that it gets a bit slower), or?
>>> Actually, I believe it does affect printing non-circular structures in more
>>> ways than just by making it slower.
>>>
>>> Try (let ((print-circle t) (toto (list 2))) (prin1 (list toto toto)))
>>>
>>> In some cases, this is a good feature, but in many other cases it can be
>>> very confusing.
>>
>> Interesting, but is not that just another bug?
> 
> Nope.  When print-circle is on, the printer takes note of shared
> substructures.  It's just that in this case, taking note of shared
> substructure obfuscates the value.

But the result I see is

   (#1=(2) #1#)((2) (2))

Why are the two printed representations of toto different? Hm. The doc 
is a bit unclear. To me it seems like

   #2=(#1=(2) #1#) #2

or

   (#1=(2) #1#) (#1=(2) #1#)

could both be possible. But not the one I actually see.

Yes (disregarding the output inconsistency above), I can see this is a 
difficulty. print-circle does not do exactly what I supposed. I believed 
it only jumped in when there were recursive structures (as the name 
suggests). Is there any function for checking if a structure is recursive?

RE: print-circle and describe-variable

[Drew Adams]

> But the result I see is
>
>    (#1=(2) #1#)((2) (2))
>
> Why are the two printed representations of toto different?

I think you are seeing: 1) the side-effect result of `prin1' printing,
followed by 2) the returned value, printed normally. (#1=(2) #1#) is the
former; ((2) (2)) is the latter.

Re: print-circle and describe-variable

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> But the result I see is
>>
>>    (#1=(2) #1#)((2) (2))
>>
>> Why are the two printed representations of toto different?
> 
> I think you are seeing: 1) the side-effect result of `prin1' printing,
> followed by 2) the returned value, printed normally. (#1=(2) #1#) is the
> former; ((2) (2)) is the latter.


But it is the output of (prin1 (list toto toto)), isn't it?

Re: print-circle and describe-variable

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> Try (let ((print-circle t) (toto (list 2))) (prin1 (list toto toto)))
>
> Interesting, but is not that just another bug?

No, it's the correct behavior.

-Miles

-- 
80% of success is just showing up.  --Woody Allen

Re: print-circle and describe-variable

[Richard Stallman]

    Try (let ((print-circle t) (toto (list 2))) (prin1 (list toto toto)))

    In some cases, this is a good feature, but in many other cases it can be
    very confusing.

That is a good point.  So I guess it is better not to make this change.

How about binding print-length and print-level instead?
They could be bound to eval-expression-print-length, etc.

Re: print-circle and describe-variable

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     Try (let ((print-circle t) (toto (list 2))) (prin1 (list toto toto)))
>
>     In some cases, this is a good feature, but in many other cases it can be
>     very confusing.
>
> That is a good point.  So I guess it is better not to make this change.
>
> How about binding print-length and print-level instead?
> They could be bound to eval-expression-print-length, etc.

I think only Lisp hackers will encounter/care about such complicated
structures, and they are surely able to customize print-length and
print-level if necessary.

RE: print-circle and describe-variable

[Drew Adams]

> >> But the result I see is
> >>
> >>    (#1=(2) #1#)((2) (2))
> >>
> >> Why are the two printed representations of toto different?
> >
> > I think you are seeing: 1) the side-effect result of `prin1' printing,
> > followed by 2) the returned value, printed normally. (#1=(2) #1#) is the
> > former; ((2) (2)) is the latter.
>
> But it is the output of (prin1 (list toto toto)), isn't it?

I'm not sure what you mean (by "it" and by "the output", for instance).

During the invocation of `prin1', the `print-circle' binding is in effect,
so (#1=(2) #1#) is what is printed (by the side effect of `prin1').

The binding is finished after the expression evaluation, and that is when
the command loop prints the value that is returned by the expression.
Printing of this value is thus done using the default value of
`print-circle', nil, so you see ((2) (2)).

If you use setq, the command-loop printing of the value also shows (#1=(2)
#1#):

(setq toto (list 2))    => (2)
(setq print-circle t)
(prin1 (setq bar (list toto toto))) => (#1=(2) #1#)(#1=(2) #1#)
C-h v bar  => (#1=(2) #1#)(#1=(2) #1#)
(setq print-circle nil)
C-h v bar  => ((2) (2))
(prin1 (setq bar (list toto toto))) => ((2) (2))((2) (2))

Both the printout from `prin1' and the printout from the command-loop are
done using the same variable environment, here, so the effect is the same
for both.

You see different printouts using the `let' expression, because one is done
with the non-nil `print-circle' binding in effect, and the other is done
using the default value of `print-circle'.

Re: print-circle and describe-variable

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>>> But the result I see is
>>>>
>>>>    (#1=(2) #1#)((2) (2))
>>>>
>>>> Why are the two printed representations of toto different?
>>> I think you are seeing: 1) the side-effect result of `prin1' printing,
>>> followed by 2) the returned value, printed normally. (#1=(2) #1#) is the
>>> former; ((2) (2)) is the latter.
>> But it is the output of (prin1 (list toto toto)), isn't it?
> 
> I'm not sure what you mean (by "it" and by "the output", for instance).
> 
> During the invocation of `prin1', the `print-circle' binding is in effect,
> so (#1=(2) #1#) is what is printed (by the side effect of `prin1').
> 
> The binding is finished after the expression evaluation, and that is when
> the command loop prints the value that is returned by the expression.
> Printing of this value is thus done using the default value of
> `print-circle', nil, so you see ((2) (2)).

Yes, but the let binding is in effect when printing the second toto too, 
or? The argument to print1 is (list toto toto).

RE: print-circle and describe-variable

[Drew Adams]

> >>>> But the result I see is
> >>>>
> >>>>    (#1=(2) #1#)((2) (2))
> >>>>
> >>>> Why are the two printed representations of toto different?
> >>> I think you are seeing: 1) the side-effect result of `prin1' printing,
> >>> followed by 2) the returned value, printed normally. (#1=(2)
> >>> #1#) is the former; ((2) (2)) is the latter.
> >>
> >> But it is the output of (prin1 (list toto toto)), isn't it?
> >
> > I'm not sure what you mean (by "it" and by "the output", for instance).
> >
> > During the invocation of `prin1', the `print-circle' binding is
> > in effect, so (#1=(2) #1#) is what is printed (by the side effect
> > of `prin1').
> >
> > The binding is finished after the expression evaluation, and
> > that is when the command loop prints the value that is returned
> > by the expression. Printing of this value is thus done using
> > the default value of `print-circle', nil, so you see ((2) (2)).
>
> Yes, but the let binding is in effect when printing the second toto too,
> or? The argument to print1 is (list toto toto).

I probably still don't understand what you're saying. HTH:

toto = (2)
(list toto toto) = ((2) (2))

(list toto toto) is printed twice when you eval the overall `let'
expression:

* First, by `prin1', within a context where `print-circle' = t. The printout
is (#1=(2) #1#). You don't explicitly see the value of toto printed twice
here, as (2) each time, because that's how `print-circle' works: it
represents the list without showing the normal, full representation of each
list element; it uses #1 as an abbreviation (placeholder) for the first
element, and so on.

* Second, by the command loop, in a context where `print-circle' = nil. The
printout is ((2) (2)). Here, you see the value of toto printed twice
explicitly, and it is printed the same each time.

Re: print-circle and describe-variable

[Chong Yidong]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>>>> I think you are seeing: 1) the side-effect result of `prin1' printing,
>>>> followed by 2) the returned value, printed normally. (#1=(2) #1#) is the
>>>> former; ((2) (2)) is the latter.
>>> But it is the output of (prin1 (list toto toto)), isn't it?
>>
>> I'm not sure what you mean (by "it" and by "the output", for instance).
>>
>> During the invocation of `prin1', the `print-circle' binding is in effect,
>> so (#1=(2) #1#) is what is printed (by the side effect of `prin1').
>>
>> The binding is finished after the expression evaluation, and that is when
>> the command loop prints the value that is returned by the expression.
>> Printing of this value is thus done using the default value of
>> `print-circle', nil, so you see ((2) (2)).
>
> Yes, but the let binding is in effect when printing the second toto
> too, or? The argument to print1 is (list toto toto).

No, the second list is the result of the `eval-expression', and
print-circle is not in effect there.

Here is another example:

  M-: (setq toto-list (let ((toto (list 2))) (list toto toto))) RET
  M-: (insert (format "%s" (let ((print-circle t)) (prin1 toto-list)))) RET
     => ((2) (2))
  M-: (let ((print-circle t)) (insert (format "%s" (prin1 toto-list)))) RET
     => (#1=(2) #1#)

Re: print-circle and describe-variable

[Lennart Borgman (gmail)]

Drew Adams wrote:

> toto = (2)
> (list toto toto) = ((2) (2))


Thanks Chong and Drew. I thought toto was ((2) (2)).

Re: print-circle and describe-variable

[Richard Matthew Stallman]

    I think only Lisp hackers will encounter/care about such complicated
    structures, and they are surely able to customize print-length and
    print-level if necessary.

Lots of users will see these variables in values shown by
describe-variable.  And even if they know how to customize,
it is pure inconvenience to require them to do so.

It would be useful for the help buffer to let RET expand the partly
hidden value, just as evaluation in the buffer does.  And the code
is already written.

Re: print-circle and describe-variable

[Chong Yidong]

Richard Matthew Stallman <rms@gnu.org> writes:

>     I think only Lisp hackers will encounter/care about such complicated
>     structures, and they are surely able to customize print-length and
>     print-level if necessary.
>
> Lots of users will see these variables in values shown by
> describe-variable.  And even if they know how to customize,
> it is pure inconvenience to require them to do so.
>
> It would be useful for the help buffer to let RET expand the partly
> hidden value, just as evaluation in the buffer does.  And the code
> is already written.

My point is whether this is even necessary for realistic Emacs usage.
In practice, are there any significant Emacs variables containing
circular structures, that users will want to look up using
describe-variable?  I can't think of any off the top of my head.

Re: print-circle and describe-variable

[Richard Matthew Stallman]

    My point is whether this is even necessary for realistic Emacs usage.
    In practice, are there any significant Emacs variables containing
    circular structures, that users will want to look up using
    describe-variable?

We are now talking about setting print-level and print-length.
Those are useful for looking at any sort of large value.
Not only for circular values.

Re: print-circle and describe-variable

[Kim F. Storm]

Richard Matthew Stallman <rms@gnu.org> writes:

>     My point is whether this is even necessary for realistic Emacs usage.
>     In practice, are there any significant Emacs variables containing
>     circular structures, that users will want to look up using
>     describe-variable?
>
> We are now talking about setting print-level and print-length.
> Those are useful for looking at any sort of large value.
> Not only for circular values.

Can we postpone this until after the release?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: print-circle and describe-variable

[Richard Stallman]

    > We are now talking about setting print-level and print-length.
    > Those are useful for looking at any sort of large value.
    > Not only for circular values.

    Can we postpone this until after the release?

Yes, it can wait.  Long values can be hard to grasp, but people can
manage.

Re: print-circle and describe-variable

[Herbert Euler]

>Richard Matthew Stallman <rms@gnu.org> writes:
>
> >     I think only Lisp hackers will encounter/care about such complicated
> >     structures, and they are surely able to customize print-length and
> >     print-level if necessary.
> >
> > Lots of users will see these variables in values shown by
> > describe-variable.  And even if they know how to customize,
> > it is pure inconvenience to require them to do so.
> >
> > It would be useful for the help buffer to let RET expand the partly
> > hidden value, just as evaluation in the buffer does.  And the code
> > is already written.
>
>My point is whether this is even necessary for realistic Emacs usage.
>In practice, are there any significant Emacs variables containing
>circular structures, that users will want to look up using
>describe-variable?  I can't think of any off the top of my head.

There is a standard, but perhaps not significant Emacs variable may
cause Emacs hanging for the sake of reasons described in this
thread: `custom-options' in any customize buffer.

Regards,
Guanpeng Xu

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/