Appending lists

Appending lists

[henri-biard]

I would like to make a list that is composed of appending three lists together.  Could use append,

but do not know how to put the result into a new list. 



(defvar city
  '( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3))
   "docstring" )

(defvar district
   '( ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) )

   "docstring" )

Re: Appending lists

[Pierpaolo Bernardi]

It is not clear what you want to do. Give an example of inputs and the relative output.

Il giorno 14 giugno 2021, alle ore 18:13, henri-biard@francemel.fr ha scritto:


I would like to make a list that is composed of appending three lists together.  Could use append,

but do not know how to put the result into a new list. 



(defvar city
  '( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3))
   "docstring" )

(defvar district
   '( ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) )

   "docstring" )

Appending lists

[henri-biard]

I want to do 



  (append '(city district))



and put the new list into a new list.





From: Pierpaolo Bernardi <olopierpa@gmail.com>
To: henri-biard@francemel.fr <henri-biard@francemel.fr>;
   help-gnu-emacs@gnu org <help-gnu-emacs@gnu.org>
Subject: Re: Appending lists
Date: 14/06/2021 18:24:21 Europe/Paris

It is not clear what you want to do. Give an example of inputs and the relative output.

Il giorno 14 giugno 2021, alle ore 18:13, henri-biard@francemel.fr ha scritto:


I would like to make a list that is composed of appending three lists together.  Could use append,

but do not know how to put the result into a new list. 



(defvar city
  '( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3))
   "docstring" )

(defvar district
   '( ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) )

   "docstring" )

Re: Appending lists

[Pierpaolo Bernardi]

Then

    (append city district)

does what you say you want. I suspect you want something else, though.

Il giorno 14 giugno 2021, alle ore 18:32, henri-biard@francemel.fr ha scritto:

I want to do 


  (append '(city district))


and put the new list into a new list.



From: Pierpaolo Bernardi <olopierpa@gmail.com>
To: henri-biard@francemel.fr <henri-biard@francemel.fr>;
   help-gnu-emacs@gnu org <help-gnu-emacs@gnu.org>
Subject: Re: Appending lists
Date: 14/06/2021 18:24:21 Europe/Paris

It is not clear what you want to do. Give an example of inputs and the relative output.

Il giorno 14 giugno 2021, alle ore 18:13, henri-biard@francemel.fr ha scritto:


I would like to make a list that is composed of appending three lists together.  Could use append,

but do not know how to put the result into a new list. 



(defvar city
  '( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3))
   "docstring" )

(defvar district
   '( ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) )

   "docstring" )

Appending lists

[henri-biard]

I want to make a new list named newlist to be



 (append city district)



and put the new list into a new list.




I want to end up the equivalent of 

(defvar newlist
'( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3)  ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) ) ) 





From: Pierpaolo Bernardi <olopierpa@gmail.com>
To: henri-biard@francemel fr <henri-biard@francemel.fr>;
   help-gnu-emacs@gnu org <help-gnu-emacs@gnu.org>
Subject: Re: Appending lists
Date: 14/06/2021 18:36:08 Europe/Paris

Then

(append city district)

does what you say you want. I suspect you want something else, though.

Il giorno 14 giugno 2021, alle ore 18:32, henri-biard@francemel.fr ha scritto:

From: Pierpaolo Bernardi <olopierpa@gmail.com>
To: henri-biard@francemel.fr <henri-biard@francemel.fr>;
   help-gnu-emacs@gnu org <help-gnu-emacs@gnu.org>
Subject: Re: Appending lists
Date: 14/06/2021 18:24:21 Europe/Paris

It is not clear what you want to do. Give an example of inputs and the relative output.

Il giorno 14 giugno 2021, alle ore 18:13, henri-biard@francemel.fr ha scritto:


I would like to make a list that is composed of appending three lists together.  Could use append,

but do not know how to put the result into a new list. 



(defvar city
  '( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3))
   "docstring" )

(defvar district
   '( ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) )

   "docstring" )

Re: Appending lists

[Pierpaolo Bernardi]

(defvar newlist 
    (append city district))


Il giorno 14 giugno 2021, alle ore 18:40, henri-biard@francemel.fr ha scritto:



I want to make a new list named newlist to be



 (append city district)



and put the new list into a new list.




I want to end up the equivalent of 

(defvar newlist
'( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3)  ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) ) ) 





From: Pierpaolo Bernardi <olopierpa@gmail.com>
To: henri-biard@francemel fr <henri-biard@francemel.fr>;
   help-gnu-emacs@gnu org <help-gnu-emacs@gnu.org>
Subject: Re: Appending lists
Date: 14/06/2021 18:36:08 Europe/Paris

Then

(append city district)

does what you say you want. I suspect you want something else, though.

Il giorno 14 giugno 2021, alle ore 18:32, henri-biard@francemel.fr ha scritto:

From: Pierpaolo Bernardi <olopierpa@gmail.com>
To: henri-biard@francemel.fr <henri-biard@francemel.fr>;
   help-gnu-emacs@gnu org <help-gnu-emacs@gnu.org>
Subject: Re: Appending lists
Date: 14/06/2021 18:24:21 Europe/Paris

It is not clear what you want to do. Give an example of inputs and the relative output.

Il giorno 14 giugno 2021, alle ore 18:13, henri-biard@francemel.fr ha scritto:


I would like to make a list that is composed of appending three lists together.  Could use append,

but do not know how to put the result into a new list. 



(defvar city
  '( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3))
   "docstring" )

(defvar district
   '( ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) )

   "docstring" )

RE: [External] : Appending lists

[Drew Adams]

> Could use append, but do not know how to put
> the result into a new list.

There's nothing wrong with asking on this help list.
That's what it's for.  But do yourself a favor and
learn also how to *ask Emacs*.

To ask Emacs how to learn Elisp:

Begin by reading some of the manual "Introduction to
Programming in Emacs Lisp".  It takes a reader by the
hand and gently introduces Elisp.  It's provided with
Emacs, as part of Emacs.

You can access it in Emacs using `C-h i' and choosing
this menu item:

 Emacs Lisp Intro: (eintr).  A simple introduction to
                             Emacs Lisp programming.

And you can access it on the web here:

 https://www.gnu.org/software/emacs/manual/html_node/eintr/
___


See also the Emacs Wiki page about learning Elisp:

  https://www.emacswiki.org/emacs/LearnEmacsLisp

Re: Appending lists

[Alexandr Vityazev]

On 2021-06-14, 18:40 +0200, henri-biard@francemel.fr wrote:


> I want to make a new list named newlist to be
>
>
>
>  (append city district)
>
>
>
> and put the new list into a new list.
>
>
>
>
> I want to end up the equivalent of 
>
> (defvar newlist
> '( ("London" . 1)  ("Paris" . 2) ("Madrid" . 3)  ("Greenwich" . 1) ("Louvre" . 2) ("Centro" . 3) ) ) 

(defvar newlist '())
(append `(,city ,district) newlist)

-- 
Best regards,
Alexandr Vityazev

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Alexandr Vityazev wrote:

> (defvar newlist '())
> (append `(,city ,district) newlist)

Okay, but I think (list city district) looks better...

And no need for a default value if one sets it the line
after IMO.

Also, one would try not to mix abstract and applied names too
much, but I get it it was to demonstrate `append'. But since
newlist is nil I don't know how much of a demo it is,
actually. Hm...

(to the OP: an empty list is '() or (list) or nil, so when
something actually _is_ an empty list '() (and not just
something to indicate false, for instance) is a good way of
putting it since that's what an empty list looks like, almost.
this is neat as it works the other way around as well, i.e.
a non-empty list is interpreted as non-nil, so you can check
for a non-empty list e.g. like this (when lst ... ) useful
with recursion (e.g., tail-recursion, with the empty list as
the non-recursive/base case) but also here and there in
general, I'd say...)

Also check out `nconc'

(nconc '(1 2 3) '(4 5) '(6)) ; (1 2 3 4 5 6) - if this works for you, use it
(nconc '(1 2 3) '(4 5)   6 ) ; (1 2 3 4 5 . 6) - see, last "list" isn't a list!

There was a trick with nconc, you could reverse a list in
constant time, right? I think that was it but that's all
I remember.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Pierpaolo Bernardi wrote:

> (defvar newlist 
>     (append city district))

Looks - bad.

Forget about the initvalue, here people will have to agree to
disagree tho. It makes development less "athletic" and fun,
and more confusing when debugging/optimization and so re-eval
start. Instead, use `defvar' to mute the byte-compiler then on
the next line use `setq'. IOM!

newlist - bad name

> Il giorno 14 giugno 2021, alle ore 18:40,
> henri-biard@francemel.fr ha scritto:
>
> I want to make a new list named newlist to be
>
> (append city district)
>
> and put the new list into a new list.

There are many ways to do that. For example

(setq list-one '(1 2)) ; (1 2)
(setq list-one-two-times (list list-one list-one)) ; ((1 2) (1 2))
(setq list-one '(1 2 3)) ; (1 2 3)
list-one-two-times ; ((1 2) (1 2)) <-- still

-- 
underground experts united
https://dataswamp.org/~incal

Appending lists

[henri-biard]

>> Pierpaolo Bernardi wrote:



>> (defvar newlist 
>> (append city district))



>> Emanuel Berg
> Looks - bad.



Now I am really getting wound up !



Should I use (append city district) or (list city district) ?



Using defvar seemed good enough for me. 



Anyway, concatenating all the arguments in "append" make the result a list.





From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Appending lists
Date: 15/06/2021 02:56:16 Europe/Paris

Pierpaolo Bernardi wrote:

> (defvar newlist 
> (append city district))

Looks - bad.

Forget about the initvalue, here people will have to agree to
disagree tho. It makes development less "athletic" and fun,
and more confusing when debugging/optimization and so re-eval
start. Instead, use `defvar' to mute the byte-compiler then on
the next line use `setq'. IOM!

newlist - bad name

> Il giorno 14 giugno 2021, alle ore 18:40,
> henri-biard@francemel.fr ha scritto:
>
> I want to make a new list named newlist to be
>
> (append city district)
>
> and put the new list into a new list.

There are many ways to do that. For example

(setq list-one '(1 2)) ; (1 2)
(setq list-one-two-times (list list-one list-one)) ; ((1 2) (1 2))
(setq list-one '(1 2 3)) ; (1 2 3)
list-one-two-times ; ((1 2) (1 2)) <-- still

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

henri-biard wrote:

>> Looks - bad.
>
> Now I am really getting wound up !
>
> Should I use (append city district) or (list city district) ?

Ha, it is difficult to say in this case :)

But both are easy to understand and very common so you should
know both anyway, then just use what works for you, I mean
that's one way to describe programming even, first collect
knowledge, then use you instinct/intuition to put it to good
use...

> Using defvar seemed good enough for me. 
>
> Anyway, concatenating all the arguments in "append" make the
> result a list.

C-h f append RET

for example to learn whet it does and what the interface is.
Do that for every function you come by, basically, that has
a short name. Because chances are it is a pretty
fundamental/common/useful building block of the language...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Also check out `nconc'
>
> (nconc '(1 2 3) '(4 5) '(6)) ; (1 2 3 4 5 6) - if this works for you, use it
> (nconc '(1 2 3) '(4 5)   6 ) ; (1 2 3 4 5 . 6) - see, last "list" isn't a list!
>
> There was a trick with nconc, you could reverse a list in
> constant time, right? I think that was it but that's all
> I remember.

Probably that wasn't `nconc' but `nreverse', I think!

  (nreverse '(flip six three hole)) ; (hole three six flip)

Yeah, and it didn't take very long either...

Here it says

  Don't use nreverse on quoted list literals; it is undefined
  behavior and may behave in surprising ways, since it is
  de facto self-modifying code. [1]

Hm ... quoted list literals? Is this better?

  (nreverse (list 'flip 'six 'three 'hole)) ; (hole three six flip)

Whats the difference and how does self-modifying code come in?
I did that once but don't remember how it worked. Is that
a function that modifies its own definition when executed?
Funky ... but does that happen here? Where?

But as for reversing the list it seems to "de facto" work
anyway :)

[1] https://stackoverflow.com/a/34423234

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On Tue, Jun 15, 2021 at 10:27:48AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> > Also check out `nconc'
> >
> > (nconc '(1 2 3) '(4 5) '(6)) ; (1 2 3 4 5 6) - if this works for you, use it
> > (nconc '(1 2 3) '(4 5)   6 ) ; (1 2 3 4 5 . 6) - see, last "list" isn't a list!
> >
> > There was a trick with nconc, you could reverse a list in
> > constant time, right? I think that was it but that's all
> > I remember.
> 
> Probably that wasn't `nconc' but `nreverse', I think!
> 
>   (nreverse '(flip six three hole)) ; (hole three six flip)
> 
> Yeah, and it didn't take very long either...
> 
> Here it says
> 
>   Don't use nreverse on quoted list literals; it is undefined
>   behavior and may behave in surprising ways, since it is
>   de facto self-modifying code. [1]

Thing is, '(flip six three hole) is a "constant". It is known
at compile time. The compiler takes its freedom to assume
that it won't be changed. It even might end up in a chunk
of read-only memory if/when the code makes it to a dumped
image. Good luck flipping pointers in cons cells in read-only
memory :)

I'd go even further with the warning: when using nreverse
(and friends), make sure there are no other users of (part
of) your data or be prepared for fun surprises:.

  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)
  ; the above isn't the surprise I was after, just a reminder to do
  ; (setq thing (nreverse thing)) -- nreverse won't change your variable
  ; in-place! The result seems weird, but do your box-and-pointer
  ; homework, and you'll get it.
  
  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?


Hours of fun. Especially when debugging some more involved code :)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

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 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).

?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

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 :-)

Cheers

[1] https://en.wikipedia.org/wiki/Lisp_(programming_language)#Conses_and_lists

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Jean Louis]

* 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.

(setq list-1 '(1 2 3))
(setq list-2 '(A B))
(nconc list-1 list-2) ⇒ (1 2 3 A B)
list-1 ⇒ (1 2 3 A B)
nconc is a built-in function in ‘C source code’.

So it obviously changes the variable `list-1' from (1 2 3) to (1 2 3 A
B) -- how do you explain that?

So far I know from Common Lisp those functions starting with "n" are
common with side effects.

(nreverse list-1) ⇒ (B A 3 2 1)
list-1 ⇒ (1) ⁈⁈⁈⁈⁈⁈⁈⁈⁈⁈⁈

-- 
Jean

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

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

Re: Appending lists

[Jean Louis]

* 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/

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

On Wed, Jun 16, 2021 at 12:13:21PM +0300, Jean Louis wrote:
> * 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.
> 
> (setq list-1 '(1 2 3))
> (setq list-2 '(A B))
> (nconc list-1 list-2) ⇒ (1 2 3 A B)
> list-1 ⇒ (1 2 3 A B)
> nconc is a built-in function in ‘C source code’.
> 
> So it obviously changes the variable `list-1' from (1 2 3) to (1 2 3 A
> B) -- how do you explain that?

No. A thousand times no. The variable list-1 contained a ref to some
cons cell (behind the scenes it's just a (perhaps tagged) pointer).

**THIS VARIABLE HASN'T CHANGED** after you did that nconc. The variable
list-1 still contains a ref to exactly the same cons cell.

What happens is that you changed the list somewhere downstream.

> So far I know from Common Lisp those functions starting with "n" are
> common with side effects.

Judging by what you write, I have the impression that you haven't
quite understood Common Lisp (this part works exactly the same
there). But I might be wrong and this a huge misunderstanding.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Wed, Jun 16, 2021 at 12:19:34PM +0300, Jean Louis wrote:

[..]

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

I think I'd like to bail out of this discussion here. We both have so
different approaches to this that I give up.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-16 12:33]:
> On Wed, Jun 16, 2021 at 12:13:21PM +0300, Jean Louis wrote:

> Judging by what you write, I have the impression that you haven't
> quite understood Common Lisp (this part works exactly the same
> there). But I might be wrong and this a huge misunderstanding.

Of course not, Common Lisp is huge subject never to be finally
understood. I don't consider that a target.

My targets are expressed in money count. If there is money, than it
means I did learn enough of Lisp.

-- 
Jean

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

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

Re: Appending lists

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-16 12:39]:
> On Wed, Jun 16, 2021 at 12:19:34PM +0300, Jean Louis wrote:
> 
> [..]
> 
> > What is it doing in background, or underground, does not really matter
> > for user, what matters is that `x' in following example is changed:
> 
> I think I'd like to bail out of this discussion here. We both have so
> different approaches to this that I give up.

The variable does not change but its value apparently change and that
is so much visible contradictory... though there is something
underground that does not really change, but we can't see that...

It remains a mystery... ♡ƪ(ˆ◡ˆ)ʃ♪

-- 
Jean

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

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

Re: Appending lists

[Yuri Khan]

On Wed, 16 Jun 2021 at 16:35, Jean Louis <bugs@gnu.support> wrote:

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

See, that’s your problem: You think there *is* an underground.

Lisp starts with symbols and cons cells and that’s the ground level.
It then builds up from that to lists and trees and associative lists.
And when you have an associative list binding a symbol to a value,
that’s when you get variables, some three floors above the ground.

And then, when you invoke ‘nreverse’ on a list pointed to by a
variable, you, from high up above, can see it scurrying down there and
re-routing the ‘cdr’s of the cons cells comprising the list, but not
touching the one link from the variable to whatever cons cell had been
the first in the list.

Re: Appending lists

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2021-06-16 14:18]:
> On Wed, 16 Jun 2021 at 16:35, Jean Louis <bugs@gnu.support> wrote:
> 
> > What is it doing in background, or underground, does not really matter
> > for user, what matters is that `x' in following example is changed:
> 
> See, that’s your problem: You think there *is* an underground.
> 
> Lisp starts with symbols and cons cells and that’s the ground level.
> It then builds up from that to lists and trees and associative lists.
> And when you have an associative list binding a symbol to a value,
> that’s when you get variables, some three floors above the ground.

That is why I leave that to engineers like you. You see, today my
friend was mentioning how he does not like one but the other webmail
system. He has no clue about the underlying software, what he wants it
functionality. 

> And then, when you invoke ‘nreverse’ on a list pointed to by a
> variable, you, from high up above, can see it scurrying down there and
> re-routing the ‘cdr’s of the cons cells comprising the list, but not
> touching the one link from the variable to whatever cons cell had been
> the first in the list.

I like your smartness, though I would like to have more practical use
of it. Thomas said that `nconc' does not change `list', unless it is
special form. And I can practically see this:

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

So maybe he was thinking that symbol `list' does not change, and I
understood it that variable value does not change.

Why not come back to that and explain me how the variable `list' did
not change from (A B C) to (A B C 1 2 3)?


-- 
Jean

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

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

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Wed, Jun 16, 2021 at 02:30:51PM +0300, Jean Louis wrote:

[...]

> (setq list '(A B C)) ⇒ (A B C)
> (nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
> list  ⇒ (A B C 1 2 3)
> 
> So maybe he was thinking that symbol `list' does not change, and I
> understood it that variable value does not change.
> 
> Why not come back to that and explain me how the variable `list' did
> not change from (A B C) to (A B C 1 2 3)?

Because the content of 'list' (wasn't it 'list1' last time we talked?)
is *not* the whole list. It is a reference to the list's head.

What changed was the cdr of some cons cell downstream. The variable
doesn't see it.

Now I'm really stopping here. One last recommendation: do some
box-and-pointer diagrams. They are really helpful.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Philip Kaludercic]

Jean Louis <bugs@gnu.support> writes:

> * Yuri Khan <yuri.v.khan@gmail.com> [2021-06-16 14:18]:
>> On Wed, 16 Jun 2021 at 16:35, Jean Louis <bugs@gnu.support> wrote:
>> 
>> > What is it doing in background, or underground, does not really matter
>> > for user, what matters is that `x' in following example is changed:
>> 
>> See, that’s your problem: You think there *is* an underground.
>> 
>> Lisp starts with symbols and cons cells and that’s the ground level.
>> It then builds up from that to lists and trees and associative lists.
>> And when you have an associative list binding a symbol to a value,
>> that’s when you get variables, some three floors above the ground.
>
> That is why I leave that to engineers like you. You see, today my
> friend was mentioning how he does not like one but the other webmail
> system. He has no clue about the underlying software, what he wants it
> functionality. 
>
>> And then, when you invoke ‘nreverse’ on a list pointed to by a
>> variable, you, from high up above, can see it scurrying down there and
>> re-routing the ‘cdr’s of the cons cells comprising the list, but not
>> touching the one link from the variable to whatever cons cell had been
>> the first in the list.
>
> I like your smartness, though I would like to have more practical use
> of it. Thomas said that `nconc' does not change `list', unless it is
> special form. And I can practically see this:
>
> (setq list '(A B C)) ⇒ (A B C)
> (nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
> list  ⇒ (A B C 1 2 3)

Change that to

(let* ((list-1 '(a b c))
       (list-2 (nconc list-1 '(1 2 3))))
  (eq list-1 list-2)) ;; => t

and the point should be obvious. This is a confusion on a superficial
level, just like how beginners in C-like languages find it weird that
you can write something like

    x = x + 1

> So maybe he was thinking that symbol `list' does not change, and I
> understood it that variable value does not change.
>
> Why not come back to that and explain me how the variable `list' did
> not change from (A B C) to (A B C 1 2 3)?

-- 
	Philip K.

Re: Appending lists

[Stefan Monnier via Users list for the GNU Emacs text editor]

tomas@tuxteam.de [2021-06-16 09:28:19] wrote:
> Doing (foo x y) will *never* change "the variable x" -- unless
> foo is a macro/special form.

Just to show that you should never say never:

    (let* ((x 5)
           (y 6))
      (cl-flet ((foo (a b) (setq x (+ a b) y (* a b)) (- a b)))
        (list (foo x y) x y)))

returns

    (-1 11 30)


;-)


        Stefan "helpfully muddying the water"

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On Wed, Jun 16, 2021 at 10:22:23AM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> tomas@tuxteam.de [2021-06-16 09:28:19] wrote:
> > Doing (foo x y) will *never* change "the variable x" -- unless
> > foo is a macro/special form.
> 
> Just to show that you should never say never:
> 
>     (let* ((x 5)
>            (y 6))
>       (cl-flet ((foo (a b) (setq x (+ a b) y (* a b)) (- a b)))
>         (list (foo x y) x y)))

Hey, that's cheating :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Stefan Monnier via Users list for the GNU Emacs text editor]

tomas@tuxteam.de [2021-06-16 17:11:01] wrote:
> On Wed, Jun 16, 2021 at 10:22:23AM -0400, Stefan Monnier via Users list for
> the GNU Emacs text editor wrote:
>> tomas@tuxteam.de [2021-06-16 09:28:19] wrote:
>> > Doing (foo x y) will *never* change "the variable x" -- unless
>> > foo is a macro/special form.
>> 
>> Just to show that you should never say never:
>> 
>>     (let* ((x 5)
>>            (y 6))
>>       (cl-flet ((foo (a b) (setq x (+ a b) y (* a b)) (- a b)))
>>         (list (foo x y) x y)))
>
> Hey, that's cheating :-)

Impredicativity is borderline, indeed.


        Stefan

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Wed, Jun 16, 2021 at 11:31:19AM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> tomas@tuxteam.de [2021-06-16 17:11:01] wrote:
> > On Wed, Jun 16, 2021 at 10:22:23AM -0400, Stefan Monnier via Users list for
> > the GNU Emacs text editor wrote:
> >> tomas@tuxteam.de [2021-06-16 09:28:19] wrote:
> >> > Doing (foo x y) will *never* change "the variable x" -- unless
> >> > foo is a macro/special form.
> >> 
> >> Just to show that you should never say never:
> >> 
> >>     (let* ((x 5)
> >>            (y 6))
> >>       (cl-flet ((foo (a b) (setq x (+ a b) y (* a b)) (- a b)))
> >>         (list (foo x y) x y)))
> >
> > Hey, that's cheating :-)
> 
> Impredicativity is borderline, indeed.

:-)

On a more serious note: I do learn a lot from you and would like
to say thanks.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

>> 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.

Well, OK, I didn't mean that `nreverse' should do it, rather
the programmer didn't use `nreverse' in a setting, perhaps
combined with `setq' as you yourself mention would be the
easiest way...

Maybe that still isn't a guarantee nreverse can't screw up
something else just the same, unsure how to "partition" or
isolate it if you will?

>> 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 :)

OK, get back to you if/when I do it.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> My targets are expressed in money count. If there is money,
> than it means I did learn enough of Lisp.

Money in Lisp :)

Go for Python if you care about money.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> You said vairable did not change, maybe it did not change
> somewhere underground

This is how I understand it:

The variable has a reference to the first cons cell of the
list. The cons cell has a car and a cdr as always, where the
cdr is a reference to the second element of the list, which is
also a cons cell, and so on.

The car of the first element's cons cell remains the same but
the cdr has changed as a side-effect of `nreverse' (or
`nconc').

So when the variable seemingly holding the list, but actually
only holding a reference to the first cons cell, when this
variable is used one will have a different list as a result
even tho the reference is the same, unchanged.

tomas, is this correct? Maybe I won't have to draw the diagram
after all... :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> I think I'd like to bail out of this discussion here.
>> We both have so different approaches to this that
>> I give up.
>
> The variable does not change but its value apparently change
> and that is so much visible contradictory... though there is
> something underground that does not really change, but we
> can't see that...

"We"? :O

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Philip Kaludercic wrote:

> Change that to
>
> (let* ((list-1 '(a b c))
>        (list-2 (nconc list-1 '(1 2 3))))
>   (eq list-1 list-2)) ;; => t
>
> and the point should be obvious. This is a confusion on
> a superficial level, just like how beginners in C-like
> languages find it weird that you can write something like
>
>     x = x + 1

I wouldn't go that far, as that (x = x + 1) is a matter of
syntax, rather this (the lists) is easy when you understand it
and difficult when you don't.

When you can't juggle, it seems and is difficult.
At a superficial level?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-16 14:54]:
> On Wed, Jun 16, 2021 at 02:30:51PM +0300, Jean Louis wrote:
> 
> [...]
> 
> > (setq list '(A B C)) ⇒ (A B C)
> > (nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
> > list  ⇒ (A B C 1 2 3)
> > 
> > So maybe he was thinking that symbol `list' does not change, and I
> > understood it that variable value does not change.
> > 
> > Why not come back to that and explain me how the variable `list' did
> > not change from (A B C) to (A B C 1 2 3)?
> 
> Because the content of 'list' (wasn't it 'list1' last time we talked?)
> is *not* the whole list. It is a reference to the list's head.
> 
> What changed was the cdr of some cons cell downstream. The variable
> doesn't see it.

You speak of some hidden flows? 

How is that useful for programer in Emacs Lisp?

Did variable's value change or not?

-- 
Jean

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

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

Re: Appending lists

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-06-16 16:07]:
> > (setq list '(A B C)) ⇒ (A B C)
> > (nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
> > list  ⇒ (A B C 1 2 3)
> 
> Change that to
> 
(let* ((list-1 '(a b c))
        (list-2 (nconc list-1 '(1 2 3))))
   (eq list-1 list-2)) ;; => t

eq - Return t if the two args are the same Lisp object.

And we talked how variable's value does not change... values or Lisp
objects?

(setq list-1 '(a b c))
list-1 ⇒ (a b c)
(setq list-2 (nconc list-1 '(1 2 3))) ⇒ (a b c 1 2 3)
list-2 ⇒ (a b c 1 2 3)
(eq list-1 list-2) ⇒ t
list-1 ⇒ (a b c 1 2 3)

How I see that is that it is same lisp object, but I can visually see
that the value changed. 

Maybe Thomas wanted to say that lisp object does not change? 

-- 
Jean

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

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

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On Wed, Jun 16, 2021 at 06:54:18PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Jean Louis wrote:
> 
> > You said vairable did not change, maybe it did not change
> > somewhere underground
> 
> This is how I understand it:
> 
> The variable has a reference to the first cons cell of the
> list. The cons cell has a car and a cdr as always, where the
> cdr is a reference to the second element of the list, which is
> also a cons cell, and so on.

Yup :)

> The car of the first element's cons cell remains the same but
> the cdr has changed as a side-effect of `nreverse' (or
> `nconc').

This is a side branch, which isn't really relevant. It's the
content of the variable (the ref to the first car) which we
are focussed on now.

The (content of the) car itself could change, e.g. via `setcar'.

> So when the variable seemingly holding the list, but actually
> only holding a reference to the first cons cell, when this
> variable is used one will have a different list as a result
> even tho the reference is the same, unchanged.

Spot on.

> tomas, is this correct? Maybe I won't have to draw the diagram
> after all... :)

Maybe. Drawing is still always nice and enlightening [1] (my
recommendation was somewhat directed at Jean Louis, but still :)

Cheers
[1] It is to me, at least.
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

On Wed, Jun 16, 2021 at 08:36:00PM +0300, Jean Louis wrote:
> * Philip Kaludercic <philipk@posteo.net> [2021-06-16 16:07]:
> > > (setq list '(A B C)) ⇒ (A B C)
> > > (nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
> > > list  ⇒ (A B C 1 2 3)
> > 
> > Change that to
> > 
> (let* ((list-1 '(a b c))
>         (list-2 (nconc list-1 '(1 2 3))))
                   ^^^^ not recommended: '(a b c) is a "constant object"
                        Some version of elisp might even refuse to do that!
>    (eq list-1 list-2)) ;; => t
> 
> eq - Return t if the two args are the same Lisp object.
> 
> And we talked how variable's value does not change... values or Lisp
> objects?
> 
> (setq list-1 '(a b c))
> list-1 ⇒ (a b c)
> (setq list-2 (nconc list-1 '(1 2 3))) ⇒ (a b c 1 2 3)
> list-2 ⇒ (a b c 1 2 3)
> (eq list-1 list-2) ⇒ t
> list-1 ⇒ (a b c 1 2 3)
> 
> How I see that is that it is same lisp object, but I can visually see
> that the value changed. 
> 
> Maybe Thomas wanted to say that lisp object does not change? 

On the contrary. Mutable objects can change. Cons cells are
mutable objects, and thus lists, which are made of those.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Philip Kaludercic]

<tomas@tuxteam.de> writes:

> On Wed, Jun 16, 2021 at 08:36:00PM +0300, Jean Louis wrote:
>> * Philip Kaludercic <philipk@posteo.net> [2021-06-16 16:07]:
>> > > (setq list '(A B C)) ⇒ (A B C)
>> > > (nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
>> > > list  ⇒ (A B C 1 2 3)
>> > 
>> > Change that to
>> > 
>> (let* ((list-1 '(a b c))
>>         (list-2 (nconc list-1 '(1 2 3))))
>                    ^^^^ not recommended: '(a b c) is a "constant object"
>                         Some version of elisp might even refuse to do that!

True, I wanted to do (list 'a 'b 'c) but I didn't want to change the
example that much.

Also, what versions of elisp wouldn't allow that?

>>    (eq list-1 list-2)) ;; => t
>> 
>> eq - Return t if the two args are the same Lisp object.
>> 
>> And we talked how variable's value does not change... values or Lisp
>> objects?
>> 
>> (setq list-1 '(a b c))
>> list-1 ⇒ (a b c)
>> (setq list-2 (nconc list-1 '(1 2 3))) ⇒ (a b c 1 2 3)
>> list-2 ⇒ (a b c 1 2 3)
>> (eq list-1 list-2) ⇒ t
>> list-1 ⇒ (a b c 1 2 3)
>> 
>> How I see that is that it is same lisp object, but I can visually see
>> that the value changed. 
>> 
>> Maybe Thomas wanted to say that lisp object does not change? 
>
> On the contrary. Mutable objects can change. Cons cells are
> mutable objects, and thus lists, which are made of those.
>
> Cheers
>  - t
>

-- 
	Philip K.

Re: Appending lists

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-16 21:55]:
> Maybe. Drawing is still always nice and enlightening [1] (my
> recommendation was somewhat directed at Jean Louis, but still :)

It is exactly what I said, you talk about underlying structures.

It doesn't keep the variable's value constant as you said. 

To put a point across it would be better to announce or make a title
that you don't talk how "variable never changes", but you talk about
the structures in memory and somewhat interesting though practically
within the spoken context useless information. What matters for
programmer is that variable A instead of holding value 1 now has value
2, that is a change, and how that change was internally accomplished
does not change the fact that A is now not 1 but is 2.  (づ｡◕‿‿◕｡)づ

-- 
Jean

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

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

Re: Appending lists

[Stefan Monnier via Users list for the GNU Emacs text editor]

> To put a point across it would be better to announce or make a title
> that you don't talk how "variable never changes", but you talk about
> the structures in memory and somewhat interesting though practically
> within the spoken context useless information. What matters for
> programmer is that variable A instead of holding value 1 now has value
> 2, that is a change, and how that change was internally accomplished
> does not change the fact that A is now not 1 but is 2.  (づ｡◕‿‿◕｡)づ

That's the problem with mutation.
In a language like Haskell where mutation is not allowed, when you have

    x = [1, 2, 3]

then the value held in variable `x` is really a list of 3 elements.
But in a language like ELisp, when you have

    (let ((x (list 1 2 3))) ...

the value held in variable `x` is not a list of 3 elements: it's really
nothing more than a reference to a location in memory holding a cons
cell (constraints in ELisp's type system ensure that this location in
memory will always hold a cons cell).  The values held in the `car/cdr`
of that cons cell will depend on the current memory state, they are not
part of "the value held in `x`".

The vast majority of ELisp code never uses `setcar/setcdr`, tho, so we
tend to overlook this inconvenient truth and talk (and think) about
those values as if we were in the presence of immutable data.
That's why `nconc`, `nreverse`, `sort`, and other similar side-effecting
functions need to be used with a lot of care.


        Stefan

Re: Appending lists

[Jean Louis]

* Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-17 01:36]:
> > To put a point across it would be better to announce or make a title
> > that you don't talk how "variable never changes", but you talk about
> > the structures in memory and somewhat interesting though practically
> > within the spoken context useless information. What matters for
> > programmer is that variable A instead of holding value 1 now has value
> > 2, that is a change, and how that change was internally accomplished
> > does not change the fact that A is now not 1 but is 2.  (づ｡◕‿‿◕｡)づ
> 
> That's the problem with mutation.
> In a language like Haskell where mutation is not allowed, when you have
> 
>     x = [1, 2, 3]
> 
> then the value held in variable `x` is really a list of 3 elements.
> But in a language like ELisp, when you have
> 
>     (let ((x (list 1 2 3))) ...
> 
> the value held in variable `x` is not a list of 3 elements: it's really
> nothing more than a reference to a location in memory holding a cons
> cell (constraints in ELisp's type system ensure that this location in
> memory will always hold a cons cell).  The values held in the `car/cdr`
> of that cons cell will depend on the current memory state, they are not
> part of "the value held in `x`".

When there is elephant in front of me, and there was one, then
somebody comes across and says, ah, that is not really an elephant in
front of you, it's really nothing more than a reference to a bunch of
walking meat and bones... then there is nothing useful about it. I
have to run anyway, or pee myself.

Or, maybe it would be good changing the Elisp manuals where you can
place the statements like: "the value held in variable `x' is not a
list of 3 elements where by: (let ((x (list 1 2 3))) x) ⇒ (1 2 3) is
not what you see... (irony)

If you wish to go deep, go even deeper and talk how there is no cdr
and car, no cons, and no Lisp, as all we are talking about is about
turning it on and turning it off, you see? There are actually no lists
at all, there is no Lisp, no C programming, as in the reality there is
something else, it is just our consideration... go even deeper and
demand from Emacs Lisp programmer to understand the quantum physics as
in reality, well, there is no matter at all... as what you see is not
really there... go back to the Big Bang, but that is not Emacs Lisp
context.

Emacs Lisp programmer is high level programmer who enjoys the straight
practical language. That is quite a different context.

The value bound to variable `x' makes the variable have that value. As
simple as that.


-- 
Jean

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

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

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> Just to show that you should never say never:
>
>     (let* ((x 5)
>            (y 6))
>       (cl-flet ((foo (a b) (setq x (+ a b) y (* a b)) (- a b)))
>         (list (foo x y) x y)))
>
> returns
>
>     (-1 11 30)

Okay, what does that illustrate?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>>>> Doing (foo x y) will *never* change "the variable x" -- unless
>>>> foo is a macro/special form.
>>> 
>>> Just to show that you should never say never:
>>> 
>>>     (let* ((x 5)
>>>            (y 6))
>>>       (cl-flet ((foo (a b) (setq x (+ a b) y (* a b)) (- a b)))
>>>         (list (foo x y) x y)))
>>
>> Hey, that's cheating :-)
>
> Impredicativity is borderline, indeed.

Impredicativity, what's that, recursion?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> What changed was the cdr of some cons cell downstream.
>> The variable doesn't see it.
>
> You speak of some hidden flows?

He speaks of how a list is implemented as a data structure.

> How is that useful for programer in Emacs Lisp?

Well, in this case, you yourself gave an example with
potentially unexpected results from using `nconc'. So to not
have that, it is good to be aware of.

More broadly, because Lisp is all focused around the universal
data structure, i.e. the list, is it helpful to know your way
around them!

And speaking even more generally, if you are into technology
and use it every day, the more you know and understand, the
higher you can take your own game...

> Did variable's value change or not?

No, the value is a reference to a cons cell and that reference
didn't change.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> (let* ((list-1 '(a b c))
>         (list-2 (nconc list-1 '(1 2 3))))
>    (eq list-1 list-2)) ;; => t
>
> eq - Return t if the two args are the same Lisp object.
>
> And we talked how variable's value does not change... values
> or Lisp objects?

Again, the value, a reference to a cons cell, doesn't change.

Here I think what's demonstrated is that list-1 and list-2 are
the same, i.e. they both hold references to the same
cons cell. It seems `nconc' returns a reference to the first
cons sell of the new list, which is the first of list-1 as
well; and the new list was created by changing the cdr of
list-1's last element so that instead of holding nil (denoting
the end of the list) it holds a reference to the first cons
cell of "list-2"...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> On the contrary. Mutable objects can change. Cons cells are
> mutable objects, and thus lists, which are made of those.

Indeed, I just thought of that :)

(let ((cell (cons 'head 'tail)))
  (list (car cell)
        (cdr cell) )) ; (head tail)

That means maybe I have to take what I just said back, it
isn't the list that is the universal data structure, well, it
is universal as well, but the even more basic and still
universal data structure is the PAIR, or cons cell!

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Philip Kaludercic wrote:

>>> (let* ((list-1 '(a b c))
>>>         (list-2 (nconc list-1 '(1 2 3))))
>>                    ^^^^ not recommended: '(a b c) is a "constant object"
>>                         Some version of elisp might even refuse to do that!
>
> True, I wanted to do (list 'a 'b 'c) but I didn't want to
> change the example that much.
>
> Also, what versions of elisp wouldn't allow that?

Probably a typo, should be dialects of Lisp...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

>> The car of the first element's cons cell remains the same
>> but the cdr has changed as a side-effect of `nreverse' (or
>> `nconc').
>
> This is a side branch, which isn't really relevant. It's the
> content of the variable (the ref to the first car) which we
> are focussed on now.

It is the problem discussed, you yourself posted an example of
how it happens (or could happen) with `nreverse'.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> It is exactly what I said, you talk about
> underlying structures.
>
> It doesn't keep the variable's value constant as you said.

It is the same value, the variable after its assignment
(`setq') holds a reference to the first cons cell of the list,
and after the evaluation of `nreverse' the variable holds
a reference to the same cons cell, i.e. nothing has changed
with respect to that variable, its value remains the
same, untouched since the setq.

> To put a point across it would be better to announce or make
> a title that you don't talk how "variable never changes",
> but you talk about the structures in memory and somewhat
> interesting though practically within the spoken context
> useless information.

:O

> What matters for programmer is that variable A instead of
> holding value 1 now has value 2

Unheard of!

Well, suffice to say, some programmers have pushed their level
of ambition beyond what Super-Jean is trying to say - which
is, tellingly perhaps, also incorrect :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-17 02:16]:
> > Did variable's value change or not?
> 
> No, the value is a reference to a cons cell and that reference
> didn't change.

That is why words and meanings, and precise expressions matter. Not
just symbolic expressions.


-- 
Jean

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

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

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> To put a point across it would be better to announce or
>> make a title that you don't talk how "variable never
>> changes", but you talk about the structures in memory and
>> somewhat interesting though practically within the spoken
>> context useless information. What matters for programmer is
>> that variable A instead of holding value 1 now has value 2,
>> that is a change, and how that change was internally
>> accomplished does not change the fact that A is now not 1
>> but is 2.
>
> That's the problem with mutation. In a language like Haskell
> where mutation is not allowed, when you have

Of course it isn't allowed in Haskell!

In Haskell, if your program does anything, that's not
encouraged and you should put that in a special part of the
code so that everyone can be aware of it and not get to
close :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> When there is elephant in front of me, and there was one,
> then somebody comes across and says, ah, that is not really
> an elephant in front of you, it's really nothing more than
> a reference to a bunch of walking meat and bones... then
> there is nothing useful about it. I have to run anyway, or
> pee myself.
>
> Or, maybe it would be good changing the Elisp manuals where
> you can place the statements like: "the value held in
> variable `x' is not a list of 3 elements where by: (let ((x
> (list 1 2 3))) x) ⇒ (1 2 3) is not what you see... (irony)
>
> If you wish to go deep, go even deeper and talk how there is
> no cdr and car, no cons, and no Lisp, as all we are talking
> about is about turning it on and turning it off, you see?
> There are actually no lists at all, there is no Lisp, no
> C programming, as in the reality there is something else, it
> is just our consideration... go even deeper and demand from
> Emacs Lisp programmer to understand the quantum physics as
> in reality, well, there is no matter at all... as what you
> see is not really there... go back to the Big Bang, but that
> is not Emacs Lisp context.
>
> Emacs Lisp programmer is high level programmer who enjoys
> the straight practical language. That is quite
> a different context.
>
> The value bound to variable `x' makes the variable have that
> value. As simple as that.

It isn't deep, it is the basic. Try to understand instead of
arguing. References to elephants and Big Bang won't
change anything.

Uhm ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Drew Adams]

> >> What's a "deep copy"?
> >
> > It's a copy where every part of the object is separate, not
> > `eq' to the corresponding parts of the object that
> > you copied.
> >
> > For a cons, which is a tree, it would mean that neither car
> > nor cdr are shared between the original and the copy, and
> > that the same is true for any cars and cdrs that are,
> > themselves, conses.
> >
> > IOW, the tree is separate/independent from its copy.
> > When that's the case you can change any parts of either
> > without affecting the other.
> >
> > `C-h f copy-tree' describes the difference between what it
> > does (a deep copy) and what `copy-sequence' does (shallow
> > copy - doesn't copy cars.
> 
> deep copy = actual copy
> shallow copy = copy of references?

Did you read `C-h f copy-tree'?

No.  Everything involving list structure (conses)
uses references.

`copy-sequence' is a shallow copy - it copies only
the conses that make up the cdrs, so that you get
new conses for ONLY those - just the conses that
make up the _sequence_).

It copies only the flat, cdr list structure, not
any list structure in cars.  You get a new sequence,
but the sequence elements (the cars) share list
structure with the input sequence.

E.g., `copy-sequence' on the list `((1 2) 3 (4))'
gives you a new sequence (list) whose elements are
also `(1 2)', `3', and `(4)'.  The first and third
elements are not only `equal' to those of the input
sequence - they are `eq' to them.

`copy-tree' is a deep copy - it copies conses in
both cars and cdrs, so you get new list structure
(conses) everywhere.  There is NO cons in the
output that's `eq' to a cons in the input.

The result of `copy-tree' is a new `((1 2) 3 (4))'
list a new tree through and through.  Its first
element, `(1 2)' is not `eq' to the `(1 2)' of the
input list.  Same thing for its last element.

`copy-tree' results in a list that's `equal' to
the input list, but there is no cons in it that's
`eq' to a cons of the input.  `copy-sequence'
guarantees that conses in cars of the output
sequence ARE `eq' to those in the input.

(setq foo '((1 2) 3 (4)))

(setq sfoo (copy-sequence foo))

(eq foo sfoo)                 ; nil
(eq (car foo) (car sfoo))     ; t
(eq (caddr foo) (caddr sfoo)) ; t

(setq tfoo (copy-tree foo))

(eq foo tfoo)                 ; nil
(eq (car foo) (car tfoo))     ; nil
(eq (caddr foo) (caddr tfoo)) ; nil

`copy-tree' is more expensive.  `copy-sequence'
lets you continue to share sequence elements.

If two lists share any parts, then if you change
such a shared part in one it's changed also in
the other.  That's exactly the point of sharing.

It's also the "danger".  Don't share List
structure unless you intend to.  You may never
need to or want to.

You will need to be aware of list structure
and the possibility that it gets shared, when
playing with Lisp code that you didn't write,
at least.

And know about Lisp functions that can catch
you up on this kind of thing - functions called
"destructive" in the doc, i.e., functions that
can modify or share list structure.

____

[If you happen to know Fortran then think
COMMON blocks plus overlapping DIMENSION specs:
shared bits of overlapping memory, like Venn
diagrams.  Programs can act on different bits
in different ways.  Many large Fortran programs
were all about this sort of thing.  Likewise
some assembler programs.]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

On Wed, Jun 16, 2021 at 09:24:19PM +0000, Philip Kaludercic wrote:
> <tomas@tuxteam.de> writes:
> 
> > On Wed, Jun 16, 2021 at 08:36:00PM +0300, Jean Louis wrote:
> >> * Philip Kaludercic <philipk@posteo.net> [2021-06-16 16:07]:
> >> > > (setq list '(A B C)) ⇒ (A B C)
> >> > > (nconc list '(1 2 3)) ⇒ (A B C 1 2 3)
> >> > > list  ⇒ (A B C 1 2 3)
> >> > 
> >> > Change that to
> >> > 
> >> (let* ((list-1 '(a b c))
> >>         (list-2 (nconc list-1 '(1 2 3))))
> >                    ^^^^ not recommended: '(a b c) is a "constant object"
> >                         Some version of elisp might even refuse to do that!
> 
> True, I wanted to do (list 'a 'b 'c) but I didn't want to change the
> example that much.

That's OK. It works, after all ;-)

I do that all the time, for playing around. But don't do that in
production, that's all.

When publishing as an example, at least, a comment is in order.

In your case, instead of (list 'a 'b 'c), an alternative would
be (copy-sequence '(a b c)).

My comment was there because our current topic is "identity and
mutability", thus it seemed relevant to me. It wasn't to critizice
your code, i /know/ it was just a quick example.

> Also, what versions of elisp wouldn't allow that?

Wait and see :)

I don't think it's planned for now, but I wouldn't exclude it
either, but oh, wait. Have a look at section "E.2 Pure Storage"
of the Emacs Lisp manual. Perhaps there are immutable objects
around, after all :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Thu, Jun 17, 2021 at 01:25:27AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Philip Kaludercic wrote:
> 
> >>> (let* ((list-1 '(a b c))
> >>>         (list-2 (nconc list-1 '(1 2 3))))
> >>                    ^^^^ not recommended: '(a b c) is a "constant object"
> >>                         Some version of elisp might even refuse to do that!
> >
> > True, I wanted to do (list 'a 'b 'c) but I didn't want to
> > change the example that much.
> >
> > Also, what versions of elisp wouldn't allow that?
> 
> Probably a typo, should be dialects of Lisp...

I was actually thinking about possible future versions
of elisp (hey, we're getting a native compiler now, so
that's the direction we're moving).

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

On Thu, Jun 17, 2021 at 01:44:39AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:

[...]

> In Haskell, if your program does anything, that's not
> encouraged [...]

:-D

May I frame that quote?

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

On Thu, Jun 17, 2021 at 03:18:48AM +0000, Drew Adams wrote:
> > >> What's a "deep copy"?

[...]

> > deep copy = actual copy
> > shallow copy = copy of references?
> 
> Did you read `C-h f copy-tree'?
> 
> No.  Everything involving list structure (conses)
> uses references.
> 
> `copy-sequence' is a shallow copy [...]

All this shows that "shallow" and "deep" are relative.
Copy-tree is "as deep as it gets", with some consequences.

Let's do an experiment, shall we?

But before: save all your texts. And, if Emacs behaves
strangely, C-g usually gets you out of the thickets.

So put on your lab coat and your security goggles. For an
awesome experience, best do your session interactive, step
by step:

  (setq lst '(a b c d dacapo))
  => (a b c d dacapo)
  
  (cddddr lst)
  => (dacapo) ;;; OK, it's the last one.
  
  (setcdr (cddddr lst) lst)) ;;; make circular list [1]
  => (a b c d dacapo a b c d dacapo a . #5) ;;; uh, whatever (see below [2])
  
  lst
  => (a b c d dacapo a b c d dacapo a . #5) ;;; (see below [2])
  
  (setq otherlst (copy-tree lst)) ;;; TIGHTEN YOUR GOGGLES!
  => ... ;;; [3]

As I said above: you (most probably) can get your Emacs back with C-g.

Cheers

[1] https://en.wikipedia.org/wiki/Ouroboros
[2] We have a circular list. This funny #5 you see there is print's
   way to tell you "hey, I've been here already. Are you trying to
   pull my leg?". Its behaviour depends on the variable `print-circle',
   which, when true, makes print even smarter -- in our case it's
   nil, but it seems that for simple cases like this one, print
   sometimes doesn't explode. Hold on to your goggles at step 3,
   just in case...
[3] Copy-tree, alas, isn't as smart. It will happily fill your memory
   if you don't hurry up with your C-g.

 - tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Thu, Jun 17, 2021 at 01:04:36AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> 
> >>>> Doing (foo x y) will *never* change "the variable x" -- unless
> >>>> foo is a macro/special form.
> >>> 
> >>> Just to show that you should never say never:
> >>> 
> >>>     (let* ((x 5)
> >>>            (y 6))
> >>>       (cl-flet ((foo (a b) (setq x (+ a b) y (* a b)) (- a b)))
> >>>         (list (foo x y) x y)))
> >>
> >> Hey, that's cheating :-)
> >
> > Impredicativity is borderline, indeed.
> 
> Impredicativity, what's that, recursion?

Kind of. But different [1]

Cheers
[1] https://en.wikipedia.org/wiki/Impredicativity
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> (setq lst '(a b c d dacapo))
> => (a b c d dacapo)
>
> (cddddr lst)
> => (dacapo) ;;; OK, it's the last one.
>
> (setcdr (cddddr lst) lst)) ;;; make circular list [1]
> => (a b c d dacapo a b c d dacapo a . #5) ;;; uh, whatever (see below [2])
>
> lst
> => (a b c d dacapo a b c d dacapo a . #5) ;;; (see below [2])
>
> (setq otherlst (copy-tree lst)) ;;; TIGHTEN YOUR GOGGLES!
> => ... ;;; [3]
>
> As I said above: you (most probably) can get your Emacs back
> with C-g.

Ha ha, how do you come up with these things?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> Kind of. But different [1]
>
> Cheers
> [1] https://en.wikipedia.org/wiki/Impredicativity

"In mathematics, logic and philosophy of mathematics,
something that is impredicative is
a self-referencing definition." [1]

Sounds like recursion to me, a recursive definition.

The example that I found

  A definition is said to be impredicative if it generalizes
  over a totality to which the entity being defined belongs.
  [...] A person x is general-like if and only if, for every
  property P which all great generals have, x too has P. [2]

is also what I would call recursion.

Maybe it is the same thing, only from another branch of
whatever scientific discipline it comes from, so has
another name for that reason?

The world is all about money and intelligence. Ha.

[1] https://en.wikipedia.org/wiki/Impredicativity
[2] https://iep.utm.edu/predicat/

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> All this shows that "shallow" and "deep" are relative.

Then these terms should be dropped, perhaps.

Or one has to do it case-by-case anyway since one cannot be
sure they mean the same thing from one case to another.

For example, recursive copy with cp(1) works in such a way
that it will, and I quote, "copy directories recursively".

:)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Appending lists

[Stefan Monnier via Users list for the GNU Emacs text editor]

> The example that I found
>
>   A definition is said to be impredicative if it generalizes
>   over a totality to which the entity being defined belongs.
>   [...] A person x is general-like if and only if, for every
>   property P which all great generals have, x too has P. [2]
>
> is also what I would call recursion.

Notice that the above defines `general-like` but the definition does not
mention `general-like`.  So it is not the usual kind of recursion like
the definition of factorial which refers to factorial.

The circularity in the example above comes from the fact that
`general-like` is a property, so `P` can also be the property
`general-like`.


        Stefan

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Fri, Jun 18, 2021 at 10:35:17PM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> > The example that I found
> >
> >   A definition is said to be impredicative if it generalizes
> >   over a totality to which the entity being defined belongs.
> >   [...] A person x is general-like if and only if, for every
> >   property P which all great generals have, x too has P. [2]
> >
> > is also what I would call recursion.
> 
> Notice that the above defines `general-like` but the definition does not
> mention `general-like`.  So it is not the usual kind of recursion like
> the definition of factorial which refers to factorial.
> 
> The circularity in the example above comes from the fact that
> `general-like` is a property, so `P` can also be the property
> `general-like`.

Put into another words, with each recursion step you transcend one
level in the Big Meta Game.

Dangerous stuff, I tell you ;-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[tomas]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Sat, Jun 19, 2021 at 01:50:43AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:
> 
> > All this shows that "shallow" and "deep" are relative.
> 
> Then these terms should be dropped, perhaps.

Relative terms are (relatively) useful. Would you drop "left" or
"right" or "up" or "down"?

> Or one has to do it case-by-case anyway since one cannot be
> sure they mean the same thing from one case to another.
> 
> For example, recursive copy with cp(1) works in such a way
> that it will, and I quote, "copy directories recursively".

What about symlinks?

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Appending lists

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

>> Then these terms should be dropped, perhaps.
>
> Relative terms are (relatively) useful. Would you drop
> "left" or "right" or "up" or "down"?

Yes, but everyone knows that, however when someone introduces
fancy terminology (shallow and deep copy) one expects them to
have precise definitions.

At least that's what I expected in this case, maybe that's
relative as well...

-- 
underground experts united
https://dataswamp.org/~incal