lread.c's `values' variable

lread.c's `values' variable

[Stefan Monnier]

  DEFVAR_LISP ("values", &Vvalues,
	       doc: /* List of values of all expressions which were read, evaluated and printed.
Order is reverse chronological.  */);

Does anybody know what is the `values' variable for (defined in lread.c) ?


	Stefan

Re: lread.c's `values' variable

[Richard Stallman]

    Does anybody know what is the `values' variable for (defined in lread.c) ?

See lisp-mode.el.

Re: lread.c's `values' variable

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Does anybody know what is the `values' variable for (defined in lread.c) ?
> 
> See lisp-mode.el.

Yes, it uses (car values).

However, that doesn't explain why `values' needs to be a list of all
expressions "which were read, evaluated and printed".  Since it grows
without ever being truncated, it is a memory leak IMO.

AFAICS, a simple `last-value' variable would do just fine as a
replacement.

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

Re: lread.c's `values' variable

[Richard Stallman]

    Yes, it uses (car values).

values is supposed to provide a history that you can look at whenever
you wish.  It's not just meant for the functions that look at it.

    However, that doesn't explain why `values' needs to be a list of all
    expressions "which were read, evaluated and printed".  Since it grows
    without ever being truncated, it is a memory leak IMO.

It probably is not a significant leak, but if it is, we could make GC
truncate it to a certain length.

Re: lread.c's `values' variable

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Yes, it uses (car values).
> 
> values is supposed to provide a history that you can look at whenever
> you wish.

Has anyone ever needed to look at that list?

Isn't the information typically found in the *Messages* buffer, in the
command history, or in the buffer where you evalled the expression
(e.g. *scratch*).

>  It's not just meant for the functions that look at it.

It is quite obvious that functions can only really look at the car of
that list.  So it is really _never_ for functions to look at (as a list).

> 
>     However, that doesn't explain why `values' needs to be a list of all
>     expressions "which were read, evaluated and printed".  Since it grows
>     without ever being truncated, it is a memory leak IMO.
> 
> It probably is not a significant leak, but if it is, we could make GC
> truncate it to a certain length.

If we keep it as a list, I think that is a reasonable compromise.

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

Re: lread.c's `values' variable

[Richard Stallman]

    Has anyone ever needed to look at that list?

    Isn't the information typically found in the *Messages* buffer, in the
    command history, or in the buffer where you evalled the expression
    (e.g. *scratch*).

The printed representation would be found there, but at least in theory
one could want to get at the actual Lisp object (to see if it is eq
to something else, for instance, or to modify it).

At present we don't have any convenient way to access it except to do
(nth N values).  And that has the inconvenience that the index of any
object changes by 1 each time you evaluate something.

    It is quite obvious that functions can only really look at the car of
    that list.

To make `values' conveniently useful, it would be nice to have an
interface that would show you the printed reps of the elements of the
list in a menu, let you select one of the values, and put it into some
other variable, without changing the value of `values'.  This is far
from the most important feature to add to Emacs, and I wouldn't spend
time on it myself.  But maybe someone would like to do it.