Re: Appending lists

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

[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]

> 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

[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

[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

[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

Using Emacs for business

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-16 19:46]:
> 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.

There is pleasure and there is money result. Any programming language
is fine. Emacs has a fast ready interface and libraries that speeds up
necessary functions. 

Sample report of a week (without money count):

       Objects Today        | Count 
----------------------------+-------
 Emails sent                |   488
 Hyperscope, new objects    |   280
 Hyperscope, objects sent   |   290
 Hyperscope objects tagged  | 20268
 Hyperscope, people related |   291
 Mailings sent              |  3982
 People                     |    56
 People, tagged             |   256
 SMS Sent                   |   239
 Tags                       |   167
(11 rows)


-- 
Jean

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

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

Re: Using Emacs for business

[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.
>
> There is pleasure and there is money result. Any programming
> language is fine. Emacs has a fast ready interface and
> libraries that speeds up necessary functions.

If you care about money, you should learn a language with
a strong presence in the commercial and business world.
Python is such a language and Python also has very fast devel
time, where even a beginner programmer in Python can get
pretty advanced stuff up-and-running in one or two weeks
or so.

Lisp on the other hand has some footing in the university and
CS world but even there it isn't so widespread anymore, and as
for the business world it is very, very uncommon compared to
other languages.

Development time in Lisp is also much slower than in Python
and there are other disadvantages as well from a business
point of view, for example try googling a problem you just
encountered in Lisp, then do the same in Python, in Python you
get tons of quality hits instantly, in Lisp, for an uncommon
problem you might not get a single one, Lisp also tends to be
much more varied in terms of style which I think is a good
thing, but the boss of a company don't like it since new
employees must understand and get into code written by others,
and so on. And there are more examples/reasons.

>        Objects Today        | Count 
> ----------------------------+-------
>  Emails sent                |   488
>  Hyperscope, new objects    |   280
>  Hyperscope, objects sent   |   290
>  Hyperscope objects tagged  | 20268
>  Hyperscope, people related |   291
>  Mailings sent              |  3982
>  People                     |    56
>  People, tagged             |   256
>  SMS Sent                   |   239
>  Tags                       |   167
> (11 rows)

Well, as the Americans put it during their industrialization
process, which no one can deny the success of nevermind what
opinions one may have of it, "What you cannot measure you
cannot control." And I agree 100%. The US/Canadian obsession
with stats in sports is a echo of this process and attitude.
That said, I don't know what you are trying to communicate by
showing that table?

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

Re: Using Emacs for business

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-17 02:00]:
> If you care about money, you should learn a language with
> a strong presence in the commercial and business world.
> Python is such a language and Python also has very fast devel
> time, where even a beginner programmer in Python can get
> pretty advanced stuff up-and-running in one or two weeks
> or so.

Any language is like that. There is nothing so special about any
language, I could do it. Emacs Lisp has a main advantage of being
bundled with the editor and thus has nice ready made interfaces. For
example, I would not like re-inventing the editor. I think that is
main feature of it.

> Lisp on the other hand has some footing in the university and CS
> world but even there it isn't so widespread anymore, and as for the
> business world it is very, very uncommon compared to other
> languages.

What is common or not, that matters maybe for people who apply with
companies to get employed. If you do programming for yourself, you may
do it in any language you wish and mixture of languages. The place and
time I started to learn programming taught me that each computer user
is asked to rather program whatever is necessary, and I still keep
that opinion today. We may observe plethora of passive computer
users who don't even think of learning programming. We started
learning it with maybe 7-8 years without computer just by answering
programming quiz questions in children's magazines.

Any language there is may be good for almost anything. I would be
using Icon or Unicon as one of choices, or Racket.

Unicon Programming — Unicon Programming v0.6.148
http://btiffin.users.sourceforge.net/up/index.html

Icon (programming language) - Wikipedia
https://en.wikipedia.org/wiki/Icon_(programming_language)

The Icon Programming Language
https://www2.cs.arizona.edu/icon/

> Development time in Lisp is also much slower than in Python and
> there are other disadvantages as well from a business point of view

I cannot judge about that, not that I have made the experience, so I
have nothing to compare to. Though I remember times when I was a
proponent of this or that programming language. Technically there are
many reasons, practically is what matters. I wish I could just tell to
computer to do what I mean, but we are not yet there.

> for example try googling a problem you just encountered in Lisp,

With googling you mean searching Internet? I don't use Google, mostly
other search engines.  And I consider good books or manuals more
valuable than online searches for solutions to specific practical
problems. Within Logo programming language context I have been using
Lisp in that sense since long time and it helped me later switch from
Perl to Lisp (what a relief). It was breeze to learn Common Lisp,
first books were the Gigabook and Common Lisp Cookbook. But I don't
like the instability of packages as this or that package would work
with this or that implementation... too complex. Sooner or later I
will move everything to Emacs Lisp, then later who knows... Boredom
causes me to re-write programs.

> then do the same in Python, in Python you get tons of quality hits
> instantly, in Lisp, for an uncommon problem you might not get a
> single one,

You see, with Lisp I have not have the same urge to search as whatever
I needed was there, my experience is different. Things that may be
harder to find are cryptographic functions to be compatible to
previous language or some external libraries like those related to
email sending or processing and database access. Emacs has it about
all.

> Lisp also tends to be much more varied in terms of style which I
> think is a good thing, but the boss of a company don't like it since
> new employees must understand and get into code written by others,
> and so on. And there are more examples/reasons.

I knew you talk about slav... sorry, employee - boss relations. So in
that case both are guided by what is popular and not what is
practical. It is corrupt and brainwashed world. Almost any kind of
Lisp is just find, including other languages, any is fine. Forth would
be just fine language for anything. Icon, any kind is fine as long as
the language can technically satisfy the need. Brainstorming is a
process that may result with quite nice results and both bosses and
slav...sorry, employees should participate in such. Just that world is
not so friendly obviously. 

A government contract somewhere provided requirements to create a
database of people and it was for a fat price many months project that
in reality could be finished in a single day would those programmes
know that technical requirements are already met with some other tools
or languages. So they re-wrote whatever already existed from
scratch. Reminds me much of the today's Org Mode which would like to
be a relational database.

If language gives you results, that is it. Using few languages is
fine, if it gives result, go and use it. Any language may be good. I
think everybody should learn programming, it should be part of
elementary school curriculum.


-- 
Jean

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

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

Re: Using Emacs for business

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

Jean Louis wrote:

>> If you care about money, you should learn a language with
>> a strong presence in the commercial and business world.
>> Python is such a language and Python also has very fast
>> devel time, where even a beginner programmer in Python can
>> get pretty advanced stuff up-and-running in one or two
>> weeks or so.
>
> Any language is like that.

No.

> There is nothing so special about any language, I could
> do it.

No.

> Emacs Lisp has a main advantage of being bundled with the
> editor and thus has nice ready made interfaces. For example,
> I would not like re-inventing the editor. I think that is
> main feature of it.

The editor? I'm talking about programming languages, of course
one should have a good editor for Python - Emacs, just to give
you an example...

> What is common or not, that matters maybe for people who
> apply with companies to get employed.

If you care about getting employed do Python, not Lisp.

> Any language there is may be good for almost anything

???

No!

There are languages that are more powerful than others in
general, there are languages that are powerful in specific
fields, and so on.

>> for example try googling a problem you just encountered in
>> Lisp,
>
> With googling you mean searching Internet? I don't use
> Google, mostly other search engines. And I consider good
> books or manuals more valuable than online searches for
> solutions to specific practical problems.

Jean, I'm not talking about you, I speak of the business
computer world.

>> then do the same in Python, in Python you get tons of
>> quality hits instantly, in Lisp, for an uncommon problem
>> you might not get a single one,
>
> You see, with Lisp I have not have the same urge to search

Again, I'm not talking about you.

> what is popular and not what is practical

Python is popular and practical, Lisp a fringe language and
some of its impractical sides are part of the reason for that.

> Almost any kind of Lisp is just find, including other
> languages, any is fine.

100% incorrect.

A programming language is a tool. To create something any tool
isn't fine, you need a tool that is suited for the purpose.
You need many tools and knowing your tools and picking the
right one is a huge part of the skill of the creator.

You can verify this easily, check out some genre or sub-genre
of computer programs. Modern first person shooters, for
example. What language or languages are they typically
written in?

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

Re: Using Emacs for business

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-06-17 03:17]:
> > Emacs Lisp has a main advantage of being bundled with the
> > editor and thus has nice ready made interfaces. For example,
> > I would not like re-inventing the editor. I think that is
> > main feature of it.
> 
> The editor? I'm talking about programming languages, of course
> one should have a good editor for Python - Emacs, just to give
> you an example...

Python does not have nice ready made interface like Emacs has. Editing
is integral part of the work. I have been doing the same work outside
of Emacs and have been using HTTP interface where nice editing is
almost impossible. One has to use browser text fields, eventually
extensions to edit objects. I have been using console and launching
any editor and I can say that is more tedious than having Emacs run
the program and launch editing of values or objects. Emacs offers
ready made GUI that may be used by programmers, for example:

- various nice and handy input functions are there, completing-read
  and similar; 

  Is there equivalent in Python for following in 2 lines?

  (let ((collection '("one" "two" "thre")))
    (completing-read "Choice: " collection))

- various completing and selection packages like helm, ivy, are there
  making the work so much easier with automatic improvements; those
  work straight and automatic, is there such equivalent in Python?
  Like just load a library and start choosing visually and easy?

- tabulated-list-mode -- good reporting interface, is there
  Python or other language equivalent? I wish if it would be, I
  would like it so. Idea and implementation of it in Emacs is
  fantastic.

- easy key binding configurations? 

- easy menu generation, any equivalents?

- opening new GUI windows, closing, splitting?

I would like to implement same programs in other languags but the
above are major obstacles which demand programming from scratch. 

Features in Emacs on the other hand allow easy and rapid development. 

Helm or ivy or other completing packages for example help in
creating easy invoice, receipts or supermarket management
sotware. Find a product rapidly, add to list, print invoice, add
to database. 

There is fat overhead in other languages without integrated GUI
like Emacs editor.

-- 
Jean

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

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

Re: Using Emacs for business

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

Jean Louis wrote:

> Python does not have nice ready made interface like Emacs
> has.

Python is a _programming language_, Emacs, among other things,
a _text editor_.

> Editing is integral part of the work. I have been doing the
> same work outside of Emacs and have been using HTTP
> interface where nice editing is almost impossible.

... ?

The built-in mode for Python:

  https://github.com/fgallina/python.el

Much more:

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

> One has to use browser text fields, eventually extensions to
> edit objects.

... :)

See this simple IRC bot, written in Python, using ONLY Emacs:

  https://dataswamp.org/~incal/#bot

> I have been using console and launching any editor and I can
> say that is more tedious than having Emacs run the program
> and launch editing of values or objects. Emacs offers ready
> made GUI that may be used by programmers, for example:

???

> - various nice and handy input functions are there,
>   completing-read and similar;
>
>   Is there equivalent in Python for following in 2 lines?
>
>   (let ((collection '("one" "two" "thre")))
>     (completing-read "Choice: " collection))

A language war, and I'm pro-Python against Lisp... :))

I like Lisp much more. But Python has a much stronger grip
everywhere, almost. Lisp is an underground/elite thing.
But not elite as in big bucks I'm afraid. You can go ask
people working with computers to make money everywhere, but
also young, ambitious people who study CS around the world at
the universities. All of them will have some experience from
Python, almost, but only a few (of the university guys) will
be Lispers.

It wasn't always like this, Lisp had a much stronger following
in the "old" computer world when universities were much
stronger players, there were even "Lisp Wars" between
dialects. But now other languages, Python for example, are
much stronger, including at the universities.

I can't say I like Python but development _is_ very quick and
there are just so many people doing it almost any issue you
come across you get tons of good hits when you google even
issues you yourself thought to be rare/exotic. Try do the same
with Lisp :) Oh, no, that's why it is a secluded company these
days, rather. There is just so many books, webpages,
communities around Python, it is a no contest compared with
what we have with Lisp.

Tell the little guys running the "greedy" little computer
business world - compared to big business, which is 100%
altruistic, of course - well, you might tell them bosses as
well actually just as well - a lot of these guys have never
HEARD of Lisp!

> - various completing and selection packages like helm, ivy,
>   are there making the work so much easier with automatic
>   improvements; those work straight and automatic, is there
>   such equivalent in Python? Like just load a library and
>   start choosing visually and easy?

Just Google Helm or Ivy plus Python, there should be tons.
Do you think Emacs only works for Lisp?

  https://www.fusionbox.com/blog/detail/exploring-large-and-unfamiliar-python-projects-in-emacs/640/
  https://oremacs.com/2015/08/26/counsel-jedi/

> - tabulated-list-mode -- good reporting interface, is there
>   Python or other language equivalent? I wish if it would
>   be, I would like it so. Idea and implementation of it in
>   Emacs is fantastic.
>
> - easy key binding configurations? 
>
> - easy menu generation, any equivalents?
>
> - opening new GUI windows, closing, splitting?
>
> I would like to implement same programs in other languags
> but the above are major obstacles which demand programming
> from scratch.

You can use Emacs for not only Python and Elisp but zsh, C++,
Ada, the SQLs, Erlang, SML, the other Lisps, Haskell, Java,
all web layout/programming, C, etc etc etc, even really rare
things like Microsoft's dafny (to do formal verification on
the fly) has a mode somewhere in the MELPAs, I remember...

> Features in Emacs on the other hand allow easy and
> rapid development.
>
> Helm or ivy or other completing packages for example help in
> creating easy invoice, receipts or supermarket management
> sotware. Find a product rapidly, add to list, print invoice,
> add to database.
>
> There is fat overhead in other languages without integrated GUI
> like Emacs editor.

Get real ...

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

Re: Using Emacs for business

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-07-06 06:23]:
> Jean Louis wrote:
> 
> > Python does not have nice ready made interface like Emacs
> > has.
> 
> Python is a _programming language_, Emacs, among other things,
> a _text editor_.

Yes, true, but the longer or more extensively I use Emacs Lisp, I am
happy to have editor with it. The viewpoint changes slowly.

> I like Lisp much more. But Python has a much stronger grip
> everywhere, almost. Lisp is an underground/elite thing.

I have never got that impression. To me Lisp and Scheme were lookig so
much simpler than any other language due to how it was written when I
was reading it: there were smaller sized and well named functions,
that it made it easy to understand like:

(defun cook-my-coffee ()
  (put-water)
  (put-coffee)
  (heat-until-degree 100))

But then again functions may be written in a terrible different manner
to be very unreadable. Though readability in Lisp is so much overall
better than in other language.
  
> But not elite as in big bucks I'm afraid. You can go ask
> people working with computers to make money everywhere, but
> also young, ambitious people who study CS around the world at
> the universities. All of them will have some experience from
> Python, almost, but only a few (of the university guys) will
> be Lispers.

It is just a generational trail.

> It wasn't always like this, Lisp had a much stronger following
> in the "old" computer world when universities were much
> stronger players, there were even "Lisp Wars" between
> dialects. But now other languages, Python for example, are
> much stronger, including at the universities.

Maybe in Sweden. Not everywhere on the planet universities advance or
progress. 

> I can't say I like Python but development _is_ very quick and
> there are just so many people doing it almost any issue you
> come across you get tons of good hits when you google even
> issues you yourself thought to be rare/exotic. Try do the same
> with Lisp :) Oh, no, that's why it is a secluded company these
> days, rather. There is just so many books, webpages,
> communities around Python, it is a no contest compared with
> what we have with Lisp.

Still I find that it is so much better relying on offline resources
like books than online references. One should first read and
thoroughly understand the programming language manual by doing the
examples provided and then program. 

btw. I don't "google" as it is not a verb, I use other search engines,
I search. 

What you said "try to do same with Lisp" -- actually I have tried and
I have got so much less dependencies on outside libraries. Often I am
minimizing the important scripts and resolving it without use of
outside libraries. My demand for searching on Internet for Lisp
related solutions minimized so much since I switched from Perl.

> Tell the little guys running the "greedy" little computer
> business world - compared to big business, which is 100%
> altruistic, of course - well, you might tell them bosses as
> well actually just as well - a lot of these guys have never
> HEARD of Lisp!

Generational trail, of course, nothing to wonder about, life changes.

> > Features in Emacs on the other hand allow easy and
> > rapid development.
> >
> > Helm or ivy or other completing packages for example help in
> > creating easy invoice, receipts or supermarket management
> > sotware. Find a product rapidly, add to list, print invoice,
> > add to database.
> >
> > There is fat overhead in other languages without integrated GUI
> > like Emacs editor.
> 
> Get real ...

Get real... help me get real with a concrete example that may replace
the tabulated-list-mode in some other language. I would need the
features from that mode with keybindings. Do you have an example?

I have tried in Chicken, there is GUI but how I see that, I have to
build too many things until I come to the same feature. I would like
to heave it for example in CLISP or Chicken.

-- 
Jean

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

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

Re: Using Emacs for business

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

Jean Louis wrote:

>> But not elite as in big bucks I'm afraid. You can go ask
>> people working with computers to make money everywhere, but
>> also young, ambitious people who study CS around the world
>> at the universities. All of them will have some experience
>> from Python, almost, but only a few (of the university
>> guys) will be Lispers.
>
> It is just a generational trail.

It is reality.

Python isn't that new BTW, it is from 1991 (CL is from 1984,
Elisp from 1985).

> Maybe in Sweden. Not everywhere on the planet universities
> advance or progress.

Well, Sweden has a strong history as an IT nation, this should
be a US thing rather, to a large extent.

> Still I find that it is so much better relying on offline
> resources like books than online references.

Even so, but there is much, much more on Python than on Lisp.
Go to the local techno-science bookshop and count.

> btw. I don't "google" as it is not a verb, I use other
> search engines, I search

... :)

> What you said "try to do same with Lisp" -- actually I have
> tried and I have got so much less dependencies on outside
> libraries. [...]

But it isn't about what you do or what language you prefer how
how you go about using it. It is something that can be counted
and compared. There is much, much more on Python both
digitally and available as books and anything else you can
think of. It just has a much stronger position than Lisp.

> Get real... help me get real with a concrete example that
> may replace the tabulated-list-mode in some other language.
> I would need the features from that mode with keybindings.
> Do you have an example?

You are in for the language war, but I'm not. It isn't about
what language you or I prefer or which is best according to
some ... way of comparing them, I guess? It is about what
other people use. People use Python to a large extent, and
Lisp to a very small extent. In the business world, the same
holds, only even more so...

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

Re: Using Emacs for business

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-07-06 23:42]:
> > It is just a generational trail.
> 
> It is reality.

Reality of "now", and now changes always. 

> Python isn't that new BTW, it is from 1991 (CL is from 1984,
> Elisp from 1985).

As of this time now, I would not have any benefit of going into
that. My needs are satisfied with Emacs Lisp, it does so much. When I
need something for the server there is Common Lisp or Chicken, MIT
Scheme, etc. It is not hard to re-write from Common Lisp to Emacs
Lisp, vice versa, even to Scheme. Not so with other types of languages
without parenthesis.

Look, if there are parenthesis it is futile to recommend me. Problem
is in the mind's automatic expectation of parenthesis, and then there
are delays, I start writing something and then I wait.... parenthesis
not automatically appearing... and I wait... I get confused. 
(づ◔ ͜ʖ◔)づ

> > Still I find that it is so much better relying on offline
> > resources like books than online references.
> 
> Even so, but there is much, much more on Python than on Lisp.
> Go to the local techno-science bookshop and count.

I am in the under-developed part of the world. To enter the public
library I am passing soldiers with kalashnikovs ready to even undress
me if necessary. And it is smaller than library in Germany in
Münsingen bei Reutlingen. I don't think there is anything about Python
there, maybe there is something about programming.

It is maybe in Sweden.

I don't think it matters. We have been programming in a computer club
without any manuals, neither access to Internet, there was just
nothing. We did not even know all possible BASIC commands, we had to
peek and poke to find them first! Then by testing we found what some
of them do. Some games were manually modified by using peek and poke
for 65536 times until the lives have been broken, a single memory
address had to be changed multiple times, game restarted and verified
if there is any change, totally blind modifications. The CPU
declaration we got from the local army headquarters, it was treated
like intelligence. We could get the sense of what computer can do from
TV only and games and duplicated and created upon it whatever we
could. Then I learned that PC computers come with the GW-BASIC book
and MS-DOS -- and since then I use books as references.

> But it isn't about what you do or what language you prefer how
> how you go about using it. It is something that can be counted
> and compared. There is much, much more on Python both
> digitally and available as books and anything else you can
> think of. It just has a much stronger position than Lisp.

I am sure, though, I have zero personal use from there. Switching is
expensive. My workflow works well, everything is integrated and
getting more and more integrated. I would gladly like to build some
better interface for Hyperscope Dynamic Knowledge Repository but I
don't have ready GUI.

> > Get real... help me get real with a concrete example that
> > may replace the tabulated-list-mode in some other language.
> > I would need the features from that mode with keybindings.
> > Do you have an example?
> 
> You are in for the language war, but I'm not.

Definitely not. My question is real. If you know a listing, like
spreadsheed like universal GUI where I can make keybindings as I wish,
I would like to know about it.

> It isn't about what language you or I prefer or which is best
> according to some ... way of comparing them, I guess? It is about
> what other people use. People use Python to a large extent, and Lisp
> to a very small extent. In the business world, the same holds, only
> even more so...

Maybe, but I don't make my business how others make it. Maybe I would,
but my workflow is specific, so nothing that other people do is not
related to me as we have individual needs.

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

[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

[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

[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

[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

[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

[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

[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]

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

[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

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

[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]

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

[OT] Underground (was: Appending lists)

[tomas]

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

On Wed, Jun 16, 2021 at 06:16:47PM +0700, Yuri Khan wrote:
> 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 /is/ the underground. But don't tell anyone :-)

cheers
 - t

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

Re: [OT] Underground (was: Appending lists)

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

tomas wrote:

> Lisp /is/ the underground. But don't tell anyone :-)

You better believe it :)

            ###   ###
 ###   ####  ### ###  ###   ####
 ###    ###   #####   ###    ###
 ###    ###    ###    ###    ###
 ###    ###   #####   ###    ###
 ##########  ### ###  ##########
            ###   ###
           ###     ###

https://dataswamp.org/~incal/figures/tty-colors.png

(Also see the signature.)

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

[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

[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]

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

[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

[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

[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

[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

[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]

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

[OFFTOPIC] Re: Appending lists

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

>>>> Just to show that you should never say never:
>>> Hey, that's cheating :-)
>> Impredicativity is borderline, indeed.
> Impredicativity, what's that, recursion?

(with-lecture-mode

Kind of, except the cycle is not "definition refers to itself" (the
"traditional" form of recursion) but rather "definition can be applied
to itself" as in the first sentence quoted above ;-)

These forms of circularity have been a great source of hilarity for
logicians and philosophers over the years, but more relevantly for
programmers they've been the source of the invention of the notion of
"type", introduced by Bertrand Russel about a century ago to try and
rule out those forms of circularity by stratifying logical
statements.                                                        )


        Stefan

Re: [OFFTOPIC] Re: Appending lists

[Arthur Miller]

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>>>>> Just to show that you should never say never:
>>>> Hey, that's cheating :-)
>>> Impredicativity is borderline, indeed.
>> Impredicativity, what's that, recursion?
>
> (with-lecture-mode
>
> Kind of, except the cycle is not "definition refers to itself" (the
> "traditional" form of recursion) but rather "definition can be applied
> to itself" as in the first sentence quoted above ;-)
>
> These forms of circularity have been a great source of hilarity for
> logicians and philosophers over the years, but more relevantly for
> programmers they've been the source of the invention of the notion of
> "type", introduced by Bertrand Russel about a century ago to try and
> rule out those forms of circularity by stratifying logical
> statements.                                                        )

Can you anyhow apply type theory to a definition of time, without refering
to time itself?

//arthur -- in some philosophical doubts

Re: [OFFTOPIC] Re: Appending lists

[Stefan Monnier]

Arthur Miller [2021-06-17 08:09:08] wrote:
> Can you anyhow apply type theory to a definition of time, without refering
> to time itself?

I think it depends on when you ask the question,


        Stefan

Re: [OFFTOPIC] Re: Appending lists

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Arthur Miller [2021-06-17 08:09:08] wrote:
>> Can you anyhow apply type theory to a definition of time, without refering
>> to time itself?
>
> I think it depends on when you ask the question,

:-)

Sure, but that sounds like we are still refering recursively to time
when saying so.

It seems like it is impossible, or at least very difficult, to give a
definition of what time is without referring to time itself, in some
form. Just wonder if it is possible to aplly the type theory to solve
the problem, I never had time to read those works by Russel myself.

Re: [OFFTOPIC] Re: Appending lists

[Stefan Monnier]

> It seems like it is impossible, or at least very difficult, to give a
> definition of what time is without referring to time itself, in some
> form. Just wonder if it is possible to aplly the type theory to solve
> the problem, I never had time to read those works by Russel myself.

That reminds me of:

    https://www.quantamagazine.org/does-time-really-flow-new-clues-come-from-a-century-old-approach-to-math-20200407/

[ The relationship being that type theory is generally associated with
  constructive logic rather than with classical logic.  ]


-- Stefan

Re: [OFFTOPIC] Re: Appending lists

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

Stefan Monnier wrote:

> https://www.quantamagazine.org/does-time-really-flow-new-clues-come-from-a-century-old-approach-to-math-20200407/
>
> [ The relationship being that type theory is generally
>   associated with constructive logic rather than with
>   classical logic. ]

Eh, "type theory"? Are we talking types like in
a programming language? There is a theory behind that?

I always thought it was just a matter of arranging 0s and 1 in
a way that was agreed-upon locally to denote that something is
something so it can be recognized and operated upon/used in
certain ways?

Much like a network communication protocol. Like question one,
what does the messages look like (how are they organized)?
Question two, in what order are they supposed to come?
Question three, what does it all mean?

And that's it?

Well, maybe there is a theory to networks as well, now that
I think about it. Of course there is. Bad example. But that
still feels more theoretic than types, with node diagrams and
stuff...

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

Re: [OFFTOPIC] Re: Appending lists

[Eduardo Ochs]

On Fri, 18 Jun 2021 at 21:06, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Stefan Monnier wrote:
>
> > https://www.quantamagazine.org/does-time-really-flow-new-clues-come-from-a-century-old-approach-to-math-20200407/
> >
> > [ The relationship being that type theory is generally
> >   associated with constructive logic rather than with
> >   classical logic. ]
>
> Eh, "type theory"? Are we talking types like in
> a programming language? There is a theory behind that?
>
> I always thought it was just a matter of arranging 0s and 1 in
> a way that was agreed-upon locally to denote that something is
> something so it can be recognized and operated upon/used in
> certain ways?
>
> Much like a network communication protocol. Like question one,
> what does the messages look like (how are they organized)?
> Question two, in what order are they supposed to come?
> Question three, what does it all mean?
>
> And that's it?
>
> Well, maybe there is a theory to networks as well, now that
> I think about it. Of course there is. Bad example. But that
> still feels more theoretic than types, with node diagrams and
> stuff...


Hi Emanuel,

take a look at Benjamin Pierce's "Types and Programming Languages" -

  https://www.cis.upenn.edu/~bcpierce/tapl/

and at Chapter 1 of the HOTT book:

  http://saunders.phil.cmu.edu/book/hott-online.pdf

Cheers,
  Eduardo Ochs
  http://angg.twu.net/#eev

Re: [OFFTOPIC] Re: Appending lists

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

Eduardo Ochs wrote:

> take a look at Benjamin Pierce's "Types and Programming
> Languages" -
>
>   https://www.cis.upenn.edu/~bcpierce/tapl/
>
> and at Chapter 1 of the HOTT book:
>
>   http://saunders.phil.cmu.edu/book/hott-online.pdf

OK, thanks! I don't know, Computer Science...

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

Re: [OFFTOPIC] Re: Appending lists

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

>> [ The relationship being that type theory is generally
>>   associated with constructive logic rather than with
>>   classical logic. ]
> Eh, "type theory"? Are we talking types like in
> a programming language? There is a theory behind that?

You might also want to start with

    https://en.wikipedia.org/wiki/Type_theory

What you're thinking of is usually called "(computational) type systems"
instead, as in

    https://en.wikipedia.org/wiki/Type_system

As the first says:

    Type theory is closely related to, and in some cases overlaps with,
    computational type systems, which are a programming language feature
    used to reduce bugs.


-- Stefan

Re: [OFFTOPIC] Re: Appending lists

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It seems like it is impossible, or at least very difficult, to give a
>> definition of what time is without referring to time itself, in some
>> form. Just wonder if it is possible to aplly the type theory to solve
>> the problem, I never had time to read those works by Russel myself.
>
> That reminds me of:
>
>     https://www.quantamagazine.org/does-time-really-flow-new-clues-come-from-a-century-old-approach-to-math-20200407/

Interesting article. Haven't heard of Gisin and "intuitionists math", so
I will have a lot to read. Thanks.

Re: [OFFTOPIC] Re: Appending lists

[tomas]

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

On Wed, Jun 16, 2021 at 10:41:18PM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> >>>> Just to show that you should never say never:
> >>> Hey, that's cheating :-)
> >> Impredicativity is borderline, indeed.
> > Impredicativity, what's that, recursion?
> 
> (with-lecture-mode

:-)

> Kind of, except the cycle is not "definition refers to itself" (the
> "traditional" form of recursion) but rather "definition can be applied
> to itself" as in the first sentence quoted above ;-)

...of that kind "All type theorists shave those philosophers who don't
shave themselves" or some such ;-)

Cheers
 - t

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

> 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

[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

[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]

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

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

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

[OFFTOPIC] Re: Appending lists

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

tomas@tuxteam.de [2021-06-17 09:54:33] wrote:
> 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

In the wonderful world of Haskell, of course, we have

   assignment is not allowed
   copy at depth 0 == copy at depth N == deep copy == no-op


-- Stefan

Re: [OFFTOPIC] Re: Appending lists

[tomas]

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

On Thu, Jun 17, 2021 at 08:41:08AM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:

[...]

> In the wonderful world of Haskell, of course, we have
> 
>    assignment is not allowed
>    copy at depth 0 == copy at depth N == deep copy == no-op

In Haskell, all depths are infinite. Or something :-)

Cheers
 - t

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

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

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

[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" )

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