#285 Values list (etc.) modified destructively

[Stavros Macrakis]

Many of the infolists, including Values, are modified
destructively. This leads to confusing behavior like the
following:

(c1) values;
(d1) [a,b,c]
(c2) kill(values)$
(c3) d1;
(d3) []

or

(c4) values;
(d4) [a,b,c]
(c5) newval: 23$
(c6) d4;
(d6) [a,b,c,newval]

The Values list is modified destructively both for
additions (new variable defined) and for deletions (kill).

In both cases, it is strictly for effiency. In the addition
case, it is to add new variables to the end (rather than
the beginning) of the list efficiently.

Even if we want to keep the value list in order of addition
(rather than reverse order of addition), the efficiency
price of using non-destructive operations is trivial. After
all, how many variables (or functions or rules or
whatever) are you going to add?

User-visible objects should NOT be modified
destructively! It makes for far too confusing semantics!

Maxima 5.9.0 GCL 2.5.0 Windows 2000

[Dieter Kaiser]

I think as long as we do not pass a copy of the lists to the user, but a reference to the global internal variable, the user observes the described effect of destructively modifications of a infolist.

Instead of passing a reference we might support for all infolists a function which passes a copy of the list, e.g.

(%i1) :lisp (defun $values () (copy-list $values))
STYLE-WARNING: redefining $VALUES in DEFUN
$VALUES

(%i1) a:10$ b:20$ c:30$

Both the global variable values and the function values() show three variable:

(%i4) values;
(%o4) [a, b, c]
(%i5) values();
(%o5) [a, b, c]

We kill two variable:

(%i6) kill(a,c);
(%o6) done

The output %o4 has been modified destructively, because it is a reference to the global variable $values. The output %o5 is not modified. We have passed a copy of the list.

(%i7) %o4;
(%o7) [b]
(%i8) %o5;
(%o8) [a, b, c]

I would like to suggest to close this bug report as "Won't fix". If we support in addition a function, we double functionality which might confuse the user and if we change the implementation, a lot of code might be broken.

A user who needs an infolist not to be modified can do a copy, e.g. with the command copy(values).

Setting the status to pending and the resolution to "Won't fix".

Perhaps, I see something completely wrong.

Dieter Kaiser

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).