Re: Appending lists

[Jean Louis <bugs@gnu.support>]

* tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-16 10:29]:
> On Wed, Jun 16, 2021 at 03:11:43AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> > tomas wrote:
> > 
> > > (setq thing (copy-sequence '(one two three four five six)))
> > > (setq thang (cddr thing))
> > >
> > > thang => (three four five six)
> > >
> > > (nreverse thing) => (six five four three two one)
> > >
> > > thing => (one)
> > >
> > > thang => (three two one)
> > >   ; now this is what I was after. Who the heck "changed my
> > >   ; variable!?" Who is General Failure and why is he reading
> > >   ; my disk?
> > 
> > Well, let's see, `nreverse' has updated the data without
> > setting the variables to whatever desired values they should
> > take
> 
> It can't. It's a function.
> 
> Doing (foo x y) will *never* change "the variable x" -- unless
> foo is a macro/special form.
> 
> > so what is left is the variables reference to the first
> > data item (the car), after that tho 1 doesn't have a cdr
> > anymore and 3 has '(2 1), not '(4 5 6).
> 
> You can put it this way... if you want to prevent yourself
> from wrapping your head around it.
> 
> You should draw your box-and-pointer diagrams [1]. Then, you'd
> get that talking about "the 3" is dangerous talk :)
> 
> > ?
> 
> What happens is that thing holds a reference to the cons cell
> which makes up the original list (one two...).
> 
> Once nreverse runs over it, it just flips the pointers to point
> the other way around. Now thing /still/ holds a reference to
> that cons cell, but now it happens to be at the tail of the
> (modified) list! Since it's a tail (now), it only "sees" one
> element. What it doesn't see is that some other cons cell (one
> whose car is "two" or thereabout) is pointing at it.
> 
> No, I won't draw the box-and-pointer diagrams for you. It's
> something that, like riding a bicycle, is fun when you do it
> yourself :-)

What is it doing in background, or underground, does not really matter
for user, what matters is that `x' in following example is changed:

> Doing (foo x y) will *never* change "the variable x" -- unless
> foo is a macro/special form.

Well nconc is apparently function:

(setq list '(A B C)) ⇒ (A B C)
list ⇒ (A B C)
(nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
list ⇒ (A B C 1 2 3)

What matters is that variable `list' is changed for user. As user need
not know the C or underlying functions or whatever you explained. 

You said vairable did not change, maybe it did not change somewhere
underground, but then it should be better explained in the manner that
first:

- acknowledges that value of variable did visibly change as that is
  what we can see, and empirically sense and agree upon;

- then to explain how maybe in the underground C or memory structures
  maybe variable did not change; which is probably not useful for Lisp
  high-level programma and mentioning the usefulness or lack of it is
  also good;


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/