RE: [External] : Re: Appending lists

RE: [External] : Re: Appending lists

[Drew Adams]

> The variable does not change but its value apparently change

What does it mean for a variable's value to change?
Does it mean that the variable points to (returns)
a different value?  Or does it mean that the value
(itself) that it points to, changes?

Put differently, does a variable (itself) change
if it continues to point to the same Lisp object
(thingie) but that object changes?

If variable A evaluates to B at time T1 and later
A evaluates to C, has A's _value_ changed?  Sure.

But there are different ways in which that can
happen, and they can affect what one means.

 (setq A (cons 42 3)) ; A evals to (42 . 3)
 (setq A (cons 6 (cons 7 1))) ; A evals to (6 7 . 1)

That's very different, in terms of Lisp objects,
from this kind of change, though the value of A
is the same as in the previous example.

 (setq A (cons 42 3)) ; A evals to (42 . 3)
 (setcar A 6)
 (setcdr A (cons 7 1)) ; A evals to (6 7 . 1)

In the first case, first A points to one cons,
with car 42 and cdr 3.  Then A points to a
different cons, with car 6 and cdr (7 . 1).

In the second case, first A points to a cons
with car 42 and cdr 4.  Then A points to the
_same_ cons, but that cons now has car 6 and
cdr (7 . 1).

This is Lisp.  Lisp is _not_ a purely
functional language.  It's not even an
impurely functional language, you might say.

If you're using Lisp, it's good to know about
list structure, which (like it or not) is
modifiable.  You may not ever intentionally
modify list structure.  But it helps to be
aware of it.

LISP = LISt Processing language, where "list"
might not mean what you expect.

RE: [External] : Re: Appending lists

[Drew Adams]

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

Read your mail quickly.  HTH.  In general, you can use
a "destructive" function such as `nreverse' on something
that you've created, e.g. as a separate object from
other existing objects.  E.g., if you _copy_ a list then
you can use `nreverse' on your copy without bothering
the list you copied.

Depending on the kind of "destructive" operation, you
might need to make a deep copy.  In all cases, if you
use a destructive operation, you should know what it
does - that's a prerequisite, unless you really enjoy
surprises.

Re: [External] : Re: Appending lists

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

Drew Adams wrote:

>> The variable does not change but its value apparently
>> change
>
> What does it mean for a variable's value to change? Does it
> mean that the variable points to (returns) a different
> value? Or does it mean that the value (itself) that it
> points to, changes? [...]

I'm starting to think this box diagram would be helpful,
didn't one do a minimal example case with `nreverse' (or
`nconc'), i.e. the fewest number of lists and list elements
possible, and then draw a box diagram to show what happens?

I can do it in ASCII tonight, God willing, but I find it hard
to think that no one did it already?

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

Re: [External] : Re: Appending lists

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

Drew Adams wrote:

>> 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?
>
> Read your mail quickly. HTH. In general, you can use
> a "destructive" function such as `nreverse' on something
> that you've created, e.g. as a separate object from other
> existing objects. E.g., if you _copy_ a list then you can
> use `nreverse' on your copy without bothering the list
> you copied.
>
> Depending on the kind of "destructive" operation, you might
> need to make a deep copy. In all cases, if you use
> a destructive operation, you should know what it does -
> that's a prerequisite, unless you really enjoy surprises.

"Copy", you mean to send the value as an argument?

What's a "deep copy"?

I have used `nconc' 7 times and `nreverse'. Still no surprises
so maybe I just haven't committed to them enough.

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

RE: [External] : Re: Appending lists

[Drew Adams]

> "Copy", you mean to send the value as an argument?

I mean create a separate object.
`copy-sequence' does that, for example.

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

RE: [External] : Re: Appending lists

[Drew Adams]

> I'm starting to think this box diagram would be helpful,
> didn't one do a minimal example case with `nreverse' (or
> `nconc'), i.e. the fewest number of lists and list elements
> possible, and then draw a box diagram to show what happens?
> 
> I can do it in ASCII tonight, God willing, but I find it hard
> to think that no one did it already?

Box diagrams in the Elisp manual:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Box-Diagrams.html

https://www.gnu.org/software/emacs/manual/html_node/elisp/Dotted-Pair-Notation.html

https://www.gnu.org/software/emacs/manual/html_node/elisp/Building-Lists.html

https://www.gnu.org/software/emacs/manual/html_node/elisp/Setcar.html

https://www.gnu.org/software/emacs/manual/html_node/elisp/Setcdr.html

https://www.gnu.org/software/emacs/manual/html_node/elisp/Sequence-Functions.html

Re: [External] : Re: Appending lists

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

Drew Adams wrote:

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

-- 
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: 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: [External] : Re: Appending lists

[tomas]

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

On Thu, Jun 17, 2021 at 01:49:21AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Drew Adams wrote:
> 
> >> What's a "deep copy"?

[...]

> deep copy = actual copy
> 
> shallow copy = copy of references?

Assignment = copy at depth 0
Shallow copy = copy at depth 1
...
42 copy = copy at depth 42
...
Deep copy = copy at depth infinite

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

> 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: [External] : Re: Appending lists

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

tomas wrote:

>> deep copy = actual copy
>> 
>> shallow copy = copy of references?
>
> Assignment = copy at depth 0
> Shallow copy = copy at depth 1
> ...
> 42 copy = copy at depth 42
> ...
> Deep copy = copy at depth infinite

But regardless of whatever, why copy something at all?

If it is there there already, I mean?

So destructive use of `nreverse' and `nconc' won't screw
it up?

Wow...

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

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

RE: [External] : Re: Appending lists

[Drew Adams]

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

They're common, old, general, and (yes) relative terms.
And hardly fancy.  But if unacquainted (no shame in that):

https://letmegooglethat.com/?q=deep+copy+lisp
https://letmegooglethat.com/?q=shallow+copy+lisp

This heavily upvoted Q&A is the first search hit:

https://stackoverflow.com/questions/184710/what-is-the-difference-between-a-deep-copy-and-a-shallow-copy

Re: [External] : Re: Appending lists

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

After this discussion, I thought I'd examine my `nconc' once
more and I then realized my use of them resembles a functional
style, while it (nconc) is already destructively doing the
updating, so that's not needed. E.g., this

  ;; (setq completion-ignored-extensions
  ;;       (nconc completion-ignored-extensions '(".bcf" ".elc" ".run.xml")) )

can be changed into (should be changed, since the above makes
no difference - ?) it can be changed into

  (nconc completion-ignored-extensions '(".bcf" ".run.xml"))

(I removed the ".elc" as that seems to be there by default, now.)

Then case 2, same thing, this

  ;; (let ((modes (list
  ;;               '("\\.bal\\'"     . balance-mode)
  ;;               '("\\.grm\\'"     . sml-mode)
  ;;               '("\\.lu\\'"      . lua-mode)
  ;;               '("\\.nqp\\'"     . perl-mode)
  ;;               '("\\.php\\'"     . html-mode)
  ;;               '("\\.pic\\'"     . nroff-mode)
  ;;               '("\\.pl\\'"      . prolog-mode)
  ;;               '("\\.sed\\'"     . conf-mode)
  ;;               '("\\.service\\'" . conf-mode)
  ;;               '("\\.tex\\'"     . latex-mode)
  ;;               '("\\.xr\\'"      . conf-xdefaults-mode)
  ;;               '("*"             . text-mode) )))
  ;;   (setq auto-mode-alist (nconc modes auto-mode-alist)) )

might as well be

  (nconc (list
          '("\\.bal\\'"     . balance-mode)
          '("\\.grm\\'"     . sml-mode)
          '("\\.lu\\'"      . lua-mode)
          '("\\.nqp\\'"     . perl-mode)
          '("\\.php\\'"     . html-mode)
          '("\\.pic\\'"     . nroff-mode)
          '("\\.pl\\'"      . prolog-mode)
          '("\\.sed\\'"     . conf-mode)
          '("\\.service\\'" . conf-mode)
          '("\\.tex\\'"     . latex-mode)
          '("\\.xr\\'"      . conf-xdefaults-mode)
          '("*"             . text-mode) )
         auto-mode-alist)

right?

source:
  https://dataswamp.org/~incal/emacs-init/dired-incal.el
  https://dataswamp.org/~incal/emacs-init/mode-by-filename.el

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

Re: [External] : Re: Appending lists

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

> After this discussion, I thought I'd examine my `nconc' once
> more and I then realized my use of them resembles a functional
> style, while it (nconc) is already destructively doing the
> updateing [...]

What functions are doing this except for `nreverse' and
`nconc'?

I think I have probably used them the same way, should change
it now when I have learned of their true nature...

PS. Except for nreverse and nconc, `sort' was mentioned.
    And the docstring confirms it, "SEQ is modified by side
    effects." Well, my code has the word "sort" 52 times so
    I'll check that out tomorrow, Gw...

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

Re: [External] : Re: Appending lists

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-20 22:51]:
> After this discussion, I thought I'd examine my `nconc' once
> more and I then realized my use of them resembles a functional
> style, while it (nconc) is already destructively doing the
> updating, so that's not needed. E.g., this
> 
>   ;; (setq completion-ignored-extensions
>   ;;       (nconc completion-ignored-extensions '(".bcf" ".elc" ".run.xml")) )
> 
> can be changed into (should be changed, since the above makes
> no difference - ?) it can be changed into
> 
>   (nconc completion-ignored-extensions '(".bcf" ".run.xml"))

I would use it this way:

(setq completion-ignored-extensions 
      (append completion-ignored-extensions '(".bcf" ".run.xml")))

As that follows the habit and logic I am personally used to. It is
style preference. I like that previous variables stay the same:

(setq list-a '(1 2 3)) ⇒ (1 2 3)
(setq list-b '(a b c)) ⇒ (a b c)
(append list-a list-b) ⇒ (1 2 3 a b c)
list-a ⇒ (1 2 3)
list-b ⇒ (a b c)

But then I can use the previously defined variables to define a new
one:

(setq appended (append list-a list-b)) ⇒ (1 2 3 a b c)

and nothing changed in those:

list-a ⇒ (1 2 3)
list-b ⇒ (a b c)

while using function `nconc' would give me a habit that I rather find
detrimental or not pleasing:

(nconc appended list-a list-b) ⇒ (1 2 3 a b c 1 2 3 a b c . #6)
list-a ⇒ (1 2 3 a b c 1 2 3 a b c . #6)
list-b ⇒ (a b c 1 2 3 a b c 1 2 3 . #6)

Question is why do I need to change other lists if all what I want is
to set the first variable `appended' to someting new?

So if I don't need to change other variables I will not use `nconc'
and rather use function `append'


-- 
Jean

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

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

Re: [External] : Re: Appending lists

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-20 23:00]:
> > After this discussion, I thought I'd examine my `nconc' once
> > more and I then realized my use of them resembles a functional
> > style, while it (nconc) is already destructively doing the
> > updateing [...]
> 
> What functions are doing this except for `nreverse' and
> `nconc'?
> 
> I think I have probably used them the same way, should change
> it now when I have learned of their true nature...
> 
> PS. Except for nreverse and nconc, `sort' was mentioned.
>     And the docstring confirms it, "SEQ is modified by side
>     effects." Well, my code has the word "sort" 52 times so
>     I'll check that out tomorrow, Gw...

From: (info "(elisp) Standard Properties")

‘side-effect-free’
     A non-‘nil’ value indicates that the named function is free of side
     effects (*note What Is a Function::), so the byte compiler may
     ignore a call whose value is unused.  If the property’s value is
     ‘error-free’, the byte compiler may even delete such unused calls.
     In addition to byte compiler optimizations, this property is also
     used for determining function safety (*note Function Safety::).

Now... you could make a list of all functions and separate those with
`side-effect-free' and those without, though I don't think it would
guarantee the result.

Then: (info "(elisp) What Is a Function")

13.1 What Is a Function?
========================

In a general sense, a function is a rule for carrying out a computation
given input values called “arguments”.  The result of the computation is
called the “value” or “return value” of the function.  The computation
can also have side effects, such as lasting changes in the values of
variables or the contents of data structures (*note Definition of side
effect::).  A “pure function” is a function which, in addition to having
no side effects, always returns the same value for the same combination
of arguments, regardless of external factors such as machine type or
system state.

Now, you can search in Emacs Lisp manual for "side effect" or
"destruct" and often functions beginning with `n' are such:

 -- Function: nbutlast x &optional n
     This is a version of ‘butlast’ that works by destructively
     modifying the ‘cdr’ of the appropriate element, rather than making
     a copy of the list.

(info "(elisp) Modifying Lists")

(info "(elisp) Rearrangement")

I like following and use it often:

 -- Function: delq object list
     This function destructively removes all elements ‘eq’ to OBJECT
     from LIST, and returns the resulting list.  The letter ‘q’ in
     ‘delq’ says that it uses ‘eq’ to compare OBJECT against the
     elements of the list, like ‘memq’ and ‘remq’.

But I should probably use this one in `let' forms for easier debuggin:

 -- Function: remove object sequence
     This function is the non-destructive counterpart of ‘delete’.  It
     returns a copy of ‘sequence’, a list, vector, or string, with
     elements ‘equal’ to ‘object’ removed.  For example:

More to go:

 -- Function: delete-dups list
     This function destructively removes all ‘equal’ duplicates from
     LIST, stores the result in LIST and returns it.  Of several ‘equal’
     occurrences of an element in LIST, ‘delete-dups’ keeps the first
     one.

Search for "destruct".

-- 
Jean

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

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

Re: [External] : Re: Appending lists

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

Jean Louis wrote:

> (setq appended (append list-a list-b)) ⇒ (1 2 3 a b c)
>
> and nothing changed in those:
>
> list-a ⇒ (1 2 3)
> list-b ⇒ (a b c)
>
> while using function `nconc' would give me a habit that I rather find
> detrimental or not pleasing:
>
> (nconc appended list-a list-b) ⇒ (1 2 3 a b c 1 2 3 a b c . #6)
> list-a ⇒ (1 2 3 a b c 1 2 3 a b c . #6)
> list-b ⇒ (a b c 1 2 3 a b c 1 2 3 . #6)
>
> Question is why do I need to change other lists if all what
> I want is to set the first variable `appended' to
> someting new?

We have been thru this already, the destructive update is what
`nconc' does and one should use it when that's what is
desired...

> So if I don't need to change other variables I will not use
> `nconc' and rather use function `append'

They do different things, and I want both please...

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

Re: [External] : Re: Appending lists

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

Jean Louis wrote:

>   ‘side-effect-free’ A non-‘nil’ value indicates that the
>   named function is free of side effects (*note What Is
>   a Function::), so the byte compiler may ignore a call
>   whose value is unused. If the property’s value is
>   ‘error-free’, the byte compiler may even delete such
>   unused calls. In addition to byte compiler optimizations,
>   this property is also used for determining function safety
>   (*note Function Safety::).
>
> Now... you could make a list of all functions and separate
> those with `side-effect-free' and those without, though
> I don't think it would guarantee the result.

No thanks, but it can be interesting to know and examine...

I didn't use `nbutlast', `delq', or `delete-dups', and
`remove' only once:

  (defun extract-strings (strings match)
    "From STRINGS, get a list with the parts that MATCH."
    (remove nil
      (mapcar
       (lambda (s) (when (string-match match s) (match-string 1 s)))
       strings) ))

Hm...

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

Re: [External] : Re: Appending lists

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

Jean Louis wrote:

> But then I can use the previously defined variables to
> define a new one:
>
> (setq appended (append list-a list-b)) ⇒ (1 2 3 a b c)
>
> and nothing changed in those:
>
> list-a ⇒ (1 2 3)
> list-b ⇒ (a b c)

Actually `append' can also be trouble because the last list
isn't copied, the new list just has a cdr somewhere to it -
yes, to the actual list.

Try this:

  (setq list-head '(1))                          ; (1)

  (setq list-tail '(2 3 4))                      ; (2 3 4)

  (setq whole-list (append list-head list-tail)) ; (1 2 3 4)

  (setcdr list-tail '(3.5 4))                    ; (3.5 4)

  whole-list                                     ; (1 2 3.5 4)

See that "whole-list" changed even tho we did it with `setq',
append, and didn't mention it...

I don't know why append does this, either to speed things up
or it has something to do with the car/cdr dynamic, maybe it
is considered safe enough to move the car out of action with
an actual copy ...

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

Re: [External] : Re: Appending lists

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

> Actually `append' can also be trouble because the last list
> isn't copied, the new list just has a cdr somewhere to it -
> yes, to the actual list [...]
>
> I don't know why append does this, either to speed things up
> or it has something to do with the car/cdr dynamic, maybe it
> is considered safe enough to move the car out of action with
> an actual copy ...

(setq list-head '(1)) ; (1)

(setq list-tail '(2 3 4)) ; (2 3 4)

(setq whole-list (append list-head list-tail)) ; (1 2 3 4)

(setcdr list-tail '(3.5 4)) ; (3.5 4)

whole-list ; (1 2 3.5 4) <-- the tail has changed

(setcar list-head 1.5)

whole-list ; <-- but here, the head is still unaffected, (1 2 3.5 4)

(setcar whole-list 1.33) ; well, of course that will work...

whole-list ; (1.33 2 3.5 4)

list-head ; still (1.5)

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

Re: [External] : Re: Appending lists

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-20 23:43]:
> Actually `append' can also be trouble because the last list
> isn't copied, the new list just has a cdr somewhere to it -
> yes, to the actual list.
> 
> Try this:
> 
>   (setq list-head '(1))                          ; (1)
> 
>   (setq list-tail '(2 3 4))                      ; (2 3 4)
> 
>   (setq whole-list (append list-head list-tail)) ; (1 2 3 4)
> 
>   (setcdr list-tail '(3.5 4))                    ; (3.5 4)
> 
>   whole-list                                     ; (1 2 3.5 4)
> 
> See that "whole-list" changed even tho we did it with `setq',
> append, and didn't mention it...

I see. I wonder if there are some implications in my code. Though
I never used `setcdr' in that combination (or never).

Maybe this is the way to go:

(setq list-head '(1)) ⇒ (1)
(setq list-tail '(2 3 4)) ⇒ (2 3 4)
(setq whole-list (append list-head (copy-sequence list-tail))) ⇒ (1 2 3 4)
(setcdr list-tail '(3.5 4)) ⇒ (3.5 4)
whole-list ⇒ (1 2 3 4)


-- 
Jean

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

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

Re: [External] : Re: Appending lists

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-20 23:50]:
> (setq list-head '(1)) ; (1)
> 
> (setq list-tail '(2 3 4)) ; (2 3 4)
> 
> (setq whole-list (append list-head list-tail)) ; (1 2 3 4)
> 
> (setcdr list-tail '(3.5 4)) ; (3.5 4)
> 
> whole-list ; (1 2 3.5 4) <-- the tail has changed
> 
> (setcar list-head 1.5)
> 
> whole-list ; <-- but here, the head is still unaffected, (1 2 3.5 4)
> 
> (setcar whole-list 1.33) ; well, of course that will work...
> 
> whole-list ; (1.33 2 3.5 4)
> 
> list-head ; still (1.5)

(setq list-head '(1)) ⇒ (1)

(setq list-tail '(2 3 4)) ⇒ (2 3 4)

(setq whole-list (append list-head (copy-sequence list-tail))) ⇒ (1 2 3 4)

(setcdr list-tail '(3.5 4)) ⇒ (3.5 4) ; (3.5 4)

It did not change now:
whole-list ⇒ (1 2 3 4) ; (1 2 3.5 4) <-- the tail has changed

(setcar list-head 1.5) ⇒ 1.5

whole-list ⇒ (1 2 3 4) ; <-- but here, the head is still unaffected, (1 2 3.5 4)

(setcar whole-list 1.33) ⇒ 1.33 ; well, of course that will work...

Look:
whole-list ⇒ (1.33 2 3 4) ; (1.33 2 3.5 4)

list-head ⇒ (1.5) ; still (1.5)

-- 
Jean

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

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

Re: [External] : Re: Appending lists

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

>   ;; (setq completion-ignored-extensions
>   ;;       (nconc completion-ignored-extensions '(".bcf" ".elc" ".run.xml")) )
> can be changed into (should be changed, since the above makes
> no difference - ?) it can be changed into
>   (nconc completion-ignored-extensions '(".bcf" ".run.xml"))

That will fail to do what you want if `completion-ignored-extensions`
was empty just before executing the code.
And it will have undesirable side effects if
`completion-ignored-extensions` happened to hold a list some parts of
which are also used elsewhere, e.g. if it was by a code such as

    (setq completion-ignored-extensions '("some" "constant" "list"))

Since you probably don't perform this operation inside a tight loop
where performance could be significant I'd recommend you just use
`append` instead.

>   ;; (let ((modes (list
>   ;;               '("\\.bal\\'"     . balance-mode)
>   ;;               '("\\.grm\\'"     . sml-mode)
>   ;;               '("\\.lu\\'"      . lua-mode)
>   ;;               '("\\.nqp\\'"     . perl-mode)
>   ;;               '("\\.php\\'"     . html-mode)
>   ;;               '("\\.pic\\'"     . nroff-mode)
>   ;;               '("\\.pl\\'"      . prolog-mode)
>   ;;               '("\\.sed\\'"     . conf-mode)
>   ;;               '("\\.service\\'" . conf-mode)
>   ;;               '("\\.tex\\'"     . latex-mode)
>   ;;               '("\\.xr\\'"      . conf-xdefaults-mode)
>   ;;               '("*"             . text-mode) )))
>   ;;   (setq auto-mode-alist (nconc modes auto-mode-alist)) )
>
> might as well be
>
>   (nconc (list
>           '("\\.bal\\'"     . balance-mode)
>           '("\\.grm\\'"     . sml-mode)
>           '("\\.lu\\'"      . lua-mode)
>           '("\\.nqp\\'"     . perl-mode)
>           '("\\.php\\'"     . html-mode)
>           '("\\.pic\\'"     . nroff-mode)
>           '("\\.pl\\'"      . prolog-mode)
>           '("\\.sed\\'"     . conf-mode)
>           '("\\.service\\'" . conf-mode)
>           '("\\.tex\\'"     . latex-mode)
>           '("\\.xr\\'"      . conf-xdefaults-mode)
>           '("*"             . text-mode) )
>          auto-mode-alist)

Here `nconc` is a safe replace for `append` because indeed the first arg
is a list you just constructed by `list` so you know for sure it's not
shared with anything else.

But the second above code is just an expensive no-op because your
`nconc` will modify its first argument and not its second, so it will
construct a new list, will add the content of `auto-mode-alist` to its
end and then throw away the result.

Here's another way you could write the code:

    (setq auto-mode-alist 
          `(("\\.bal\\'"     . balance-mode)
            ("\\.grm\\'"     . sml-mode)
            ("\\.lu\\'"      . lua-mode)
            ("\\.nqp\\'"     . perl-mode)
            ("\\.php\\'"     . html-mode)
            ("\\.pic\\'"     . nroff-mode)
            ("\\.pl\\'"      . prolog-mode)
            ("\\.sed\\'"     . conf-mode)
            ("\\.service\\'" . conf-mode)
            ("\\.tex\\'"     . latex-mode)
            ("\\.xr\\'"      . conf-xdefaults-mode)
            ("*"             . text-mode)
            ,@auto-mode-alist))


-- Stefan

Re: [External] : Re: Appending lists

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

Jean Louis wrote:

>> (setq list-head '(1)) ; (1)
>> (setq list-tail '(2 3 4)) ; (2 3 4)
>> (setq whole-list (append list-head list-tail)) ; (1 2 3 4)
>> (setcdr list-tail '(3.5 4)) ; (3.5 4)
>> whole-list ; (1 2 3.5 4) <-- the tail has changed
>> (setcar list-head 1.5)
>> whole-list ; <-- but here, the head is still unaffected, (1 2 3.5 4)
>> (setcar whole-list 1.33) ; well, of course that will work...
>> whole-list ; (1.33 2 3.5 4)
>> list-head ; still (1.5)
>
> (setq list-head '(1)) ⇒ (1)
> (setq list-tail '(2 3 4)) ⇒ (2 3 4)
> (setq whole-list (append list-head (copy-sequence list-tail))) ⇒ (1 2 3 4)
> (setcdr list-tail '(3.5 4)) ⇒ (3.5 4) ; (3.5 4)
> It did not change now:
> whole-list ⇒ (1 2 3 4) ; (1 2 3.5 4) <-- the tail has changed

But here it did again, despite `copy-sequence'!

(progn
  (setq list-head '(1))
  (setq list-tail '(2 3 4))
  (setq list-tail-2 (copy-sequence list-tail))
  (setq whole-list (append list-head list-tail-2))
  (setcdr list-tail-2 '(3.5 4))
  whole-list
) ; (1 2 3.5 4)

Oh, no!

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

Re: [External] : 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:

>> might as well be
>>
>>   (nconc (list
>>           '("\\.bal\\'"     . balance-mode)
>>           '("\\.grm\\'"     . sml-mode)
>>           '("\\.lu\\'"      . lua-mode)
>>           '("\\.nqp\\'"     . perl-mode)
>>           '("\\.php\\'"     . html-mode)
>>           '("\\.pic\\'"     . nroff-mode)
>>           '("\\.pl\\'"      . prolog-mode)
>>           '("\\.sed\\'"     . conf-mode)
>>           '("\\.service\\'" . conf-mode)
>>           '("\\.tex\\'"     . latex-mode)
>>           '("\\.xr\\'"      . conf-xdefaults-mode)
>>           '("*"             . text-mode) )
>>          auto-mode-alist)
>
> Here `nconc` is a safe replace for `append` because indeed
> the first arg is a list you just constructed by `list` so
> you know for sure it's not shared with anything else.

Right.

> But the second above code is just an expensive no-op because
> your `nconc` will modify its first argument and not its
> second

Right!

> Here's another way you could write the code:
>
>     (setq auto-mode-alist 
>           `(("\\.bal\\'"     . balance-mode)
>             ("\\.grm\\'"     . sml-mode)
>             ("\\.lu\\'"      . lua-mode)
>             ("\\.nqp\\'"     . perl-mode)
>             ("\\.php\\'"     . html-mode)
>             ("\\.pic\\'"     . nroff-mode)
>             ("\\.pl\\'"      . prolog-mode)
>             ("\\.sed\\'"     . conf-mode)
>             ("\\.service\\'" . conf-mode)
>             ("\\.tex\\'"     . latex-mode)
>             ("\\.xr\\'"      . conf-xdefaults-mode)
>             ("*"             . text-mode)
>             ,@auto-mode-alist))

Hm, isn't that the coolest one by far?

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

Re: [External] : Re: Appending lists

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

>> Here's another way you could write the code:
>>
>>     (setq auto-mode-alist 
>>           `(("\\.bal\\'"     . balance-mode)
>>             ("\\.grm\\'"     . sml-mode)
>>             ("\\.lu\\'"      . lua-mode)
>>             ("\\.nqp\\'"     . perl-mode)
>>             ("\\.php\\'"     . html-mode)
>>             ("\\.pic\\'"     . nroff-mode)
>>             ("\\.pl\\'"      . prolog-mode)
>>             ("\\.sed\\'"     . conf-mode)
>>             ("\\.service\\'" . conf-mode)
>>             ("\\.tex\\'"     . latex-mode)
>>             ("\\.xr\\'"      . conf-xdefaults-mode)
>>             ("*"             . text-mode)
>>             ,@auto-mode-alist))
>
> Hm, isn't that the coolest one by far?

(setq completion-ignored-extensions
      `(".bcf" ".run.xml" ,@completion-ignored-extensions) )

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

Re: [External] : Re: Appending lists

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-21 01:56]:
> But here it did again, despite `copy-sequence'!
> 
> (progn
>   (setq list-head '(1))
>   (setq list-tail '(2 3 4))
>   (setq list-tail-2 (copy-sequence list-tail))
>   (setq whole-list (append list-head list-tail-2))
>   (setcdr list-tail-2 '(3.5 4))
>   whole-list
> ) ; (1 2 3.5 4)

Not like that, you have to use `copy-sequence' on the last element
within `append' 

(progn
  (setq list-head '(1))
  (setq list-tail '(2 3 4))
  (setq whole-list (append list-head (copy-sequence list-tail)))
  (setcdr list-tail '(3.5 4))
  whole-list
) ⇒ (1 2 3 4)

-- 
Jean

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

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

Re: [External] : Re: Appending lists

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

Jean Louis wrote:

> Not like that, you have to use `copy-sequence' on the last
> element within `append'
>
> (progn
>   (setq list-head '(1))
>   (setq list-tail '(2 3 4))
>   (setq whole-list (append list-head (copy-sequence list-tail)))
>   (setcdr list-tail '(3.5 4))
>   whole-list
> ) ; (1 2 3 4)

Clearly doesn't work:

(progn
   (setq list-head '(1))
   (setq list-tail '(2 3 4))
   (setq whole-list (append list-head
                            `(,(car list-tail))
                            (setcdr (copy-sequence list-tail) '(3.5 4))))
   whole-list
 ) ; (1 2 3.5 4)

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