bug#12314: 24.2.50; `add-to-history': use `setq' with `delete'

[Eli Zaretskii <eliz@gnu.org>]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@gnu.org>, <12314@debbugs.gnu.org>
> Date: Sat, 8 Sep 2012 15:26:04 -0700
> 
> > > > Why is it even necessary to talk about destructive 
> > > > modifications, if we are to advise to assign the result anyway?
> > > 
> > > Not sure I understand the question.  It is because these 
> > > operations can be destructive of list structure that we advise that.
> > 
> > If you need to forget about the old value and assign the new one
> > returned by 'delete', why does it matter that the modification was
> > destructive?  That pertains to the old value that you need to toss
> > anyway.
> 
> Perhaps we are miscommunicating.
> 
> That general advice about assigning the variable is only a general guideline; it
> is not absolute.  You will NOT always want to assign the variable to the return
> value.  It all depends on what you want/need.

Please describe the situations with using 'delete' when the old value
will be wanted.  (Please try to do that succinctly, because I get lost
in your longish deliberations.)

> The doc about these operations needs to describe what they do, and what they do
> is typically destructive; that is, they typically modify list structure.
> 
> The bit about variables here is only a heads-up about a classic gotcha, nothing
> more.  It is because we often have variables that are assigned/bound to the list
> structure that we might be modifying that we should BE AWARE that these
> operations do NOT do ANYTHING wrt variables.  

Being aware doesn't solve problems.  To write reliable code, one needs
to always do certain things.  My understanding is that one must always
assign the new value, because the old one is unpredictable in general.

> > > If you have variables that point to some list structure 
> > > that you modify somehow, then it is up to you to ensure that
> > > the variables point to what you want them to point to after
> > > such modification.
> > 
> > Variables that point to that list structure will point to something
> > whose value is unpredictable, a.k.a. "garbage".  It is enough to say
> > that the old value is garbage and shouldn't be used, IMO.
> 
> No.  It all depends.  Lisp programs that use list modification do so sometimes
> for performance in calculating the new list, but more often they do so in order
> to take advantage of SHARING list structure.
> 
> (This too is something not so obvious to newbies - they can get the impression
> that these operations are mainly about saving cycles in calculating the return
> value.)

But the manual should cater first and foremost to newbies.  The rest
will get the point when they read the detailed description of how the
list is modified.

> (setq a  '(1 2 3 4))
> (setq b  (cddr a))
> 
> a => (1 2 3 4)
> b => (3 4)
> 
> (delq 4 b)
> 
> a => (1 2 3)
> b => (3)
> 
> The fact that modifying the list pointed to by `b' also modifies the list
> pointed to by `a' is an advantage for certain kinds of programs.  Without a
> separate `setq' operation, the variables point to the same cons cells they
> pointed to at the outset.  And in some cases that is exactly what you want: you
> want to remove the last link in the list that is shared by `a' and `b'.

I fail to see the utility of this.  Building code that relies on
internal implementation details is never a good idea.  But that's me;
please don't bother to argue.