using setq to create lists based on other lists...

[Jean-Christophe Helary]

I spend most of the day investigating why creating a list with setq was not "working".

For ex:
(setq list0 '(1 2))
(setq list1 list0)

If you do

(setcar list0 0)

then for some reason (for which I could not find an explanation in the elisp reference) the car of list1 also changes, and vice-versa.

Which is totally unexpected since when you do:

(setq list0 0)

list1 does not become 0

I don't suppose that's a bug, but really it ought the be very clearly documented in the reference. Also, I'd like to know why that's happening.

So, to avoid that behavior, I had to resort to using copy-tree:

(setq list1 (copy-tree list0))

Which is really not the first thing I would have thought about.

There are probably better ways to create lists based on other lists without "linking" the two, so I'd like some information about that.

Thanks in advance.



Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Barry Margolin]

In article <mailman.5010.1543748027.1284.help-gnu-***@gnu.org>,
Jean-Christophe Helary <***@gmail.com> wrote:

> I spend most of the day investigating why creating a list with setq was not
> "working".
>
> For ex:
> (setq list0 '(1 2))
> (setq list1 list0)
>
> If you do
>
> (setcar list0 0)
>
> then for some reason (for which I could not find an explanation in the elisp
> reference) the car of list1 also changes, and vice-versa.
>
> Which is totally unexpected since when you do:
>
> (setq list0 0)
>
> list1 does not become 0
>
> I don't suppose that's a bug, but really it ought the be very clearly
> documented in the reference. Also, I'd like to know why that's happening.

list0 and list1 both contain references to the same cons. When you use
setcar, you're changing the contents of one of the cells in that cons.
Since both variables refer to it, the change is visible through either
of them.

The same thing happens in just about all object-oriented languages.
Multiple variables can refer to the same object; if you change the
contents of the object, all of them reflect the change.

But reassigning the variable doesn't affect the others, because now
they're not referring to the same object.

>
> So, to avoid that behavior, I had to resort to using copy-tree:
>
> (setq list1 (copy-tree list0))
>
> Which is really not the first thing I would have thought about.

copy-tree makes a new set of conses, so modifying one of them has no
effect on the other.

If you're familiar with C, you can think of Lisp variables as being like
pointers, and conses are like structures. Your code is equivalent to:

cons *list0 = malloc(sizeof(cons));
list0->car = make_number(1);
list0->cdr = malloc(sizeof(cons));
list0->cdr->car = make_number(2);
list0->cdr->cdr = null;
cons *list1 = list0;
list0->car = make_number(0);

--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Stephen Berman]

On Sun, 02 Dec 2018 06:21:12 -0500 Barry Margolin <***@alum.mit.edu> wrote:

> In article <mailman.5010.1543748027.1284.help-gnu-***@gnu.org>,
> Jean-Christophe Helary <***@gmail.com> wrote:
>
>> I spend most of the day investigating why creating a list with setq was not
>> "working".
>>
>> For ex:
>> (setq list0 '(1 2))
>> (setq list1 list0)
>>
>> If you do
>>
>> (setcar list0 0)
>>
>> then for some reason (for which I could not find an explanation in the elisp
>> reference) the car of list1 also changes, and vice-versa.
>>
>> Which is totally unexpected since when you do:
>>
>> (setq list0 0)
>>
>> list1 does not become 0
>>
>> I don't suppose that's a bug, but really it ought the be very clearly
>> documented in the reference. Also, I'd like to know why that's happening.
>
> list0 and list1 both contain references to the same cons. When you use
> setcar, you're changing the contents of one of the cells in that cons.
> Since both variables refer to it, the change is visible through either
> of them.
[...]
> But reassigning the variable doesn't affect the others, because now
> they're not referring to the same object.

To expand of this, since Jean-Christophe didn't find an explanation of
this behavior of setq in the Lisp reference, but it is in fact
documented:

Special Form: setq [symbol form]...
This special form is the most common method of changing a
variable’s value. Each SYMBOL is given a new value, which is the
result of evaluating the corresponding FORM. The current binding
of the symbol is changed.

In the above case, the symbol `list1' is given the result of evaluating
`list0', which is the list `'(1 2)'. So now both `list0' and `list1'
refer to this list, which is a Lisp object; you can see this with `eq',
which returns t if its arguments are the same Lisp object:

(eq list1 list0)
=>
t

That's why setcar affects both `list0' and `list1'. On the other hand
(setq list0 0) changes the current binding of `list0' to the value of
`0', which is a different object from `'(1 2)', which is still the value
of `list1', so now `list0' and `list1' differ.

Steve Berman

[Jean-Christophe Helary]

Stephen, thank you for the additional explanations.

> On Dec 2, 2018, at 20:51, Stephen Berman <***@gmx.net> wrote:

>>> I don't suppose that's a bug, but really it ought the be very clearly
>>> documented in the reference. Also, I'd like to know why that's happening.
>
> To expand of this, since Jean-Christophe didn't find an explanation of
> this behavior of setq in the Lisp reference, but it is in fact
> documented:

Well, yes and no.

> Special Form: setq [symbol form]...
> This special form is the most common method of changing a
> variable’s value. Each SYMBOL is given a new value, which is the
> result of evaluating the corresponding FORM. The current binding
> of the symbol is changed.
>
> In the above case, the symbol `list1' is given the result of evaluating
> `list0', which is the list `'(1 2)'. So now both `list0' and `list1'
> refer to this list,

That's not clear at all from the paragraph you quote. Because for all practical purposes, when I evaluate list0 I get (1 2) and not "a pointer to an object that is the list (1 2)".

In fact, I just found the explanation, it is in the Introduction to Emacs Lisp and it says:

> When a variable is set to a list with a function such as setq, it stores the address of the first box in the variable.

So, setq has a specific behavior when it applies to lists: it evaluates the form as a pointer to an object and not as a value.

Or am I misunderstanding something ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Stephen Berman]

On Sun, 2 Dec 2018 21:22:54 +0900 Jean-Christophe Helary <***@gmail.com> wrote:

> Stephen, thank you for the additional explanations.
>
>> On Dec 2, 2018, at 20:51, Stephen Berman <***@gmx.net> wrote:
>
>>>> I don't suppose that's a bug, but really it ought the be very clearly
>>>> documented in the reference. Also, I'd like to know why that's happening.
>>
>> To expand of this, since Jean-Christophe didn't find an explanation of
>> this behavior of setq in the Lisp reference, but it is in fact
>> documented:
>
> Well, yes and no.
>
>> Special Form: setq [symbol form]...
>> This special form is the most common method of changing a
>> variable’s value. Each SYMBOL is given a new value, which is the
>> result of evaluating the corresponding FORM. The current binding
>> of the symbol is changed.
>>
>> In the above case, the symbol `list1' is given the result of evaluating
>> `list0', which is the list `'(1 2)'. So now both `list0' and `list1'
>> refer to this list,
>
> That's not clear at all from the paragraph you quote. Because for all
> practical purposes, when I evaluate list0 I get (1 2) and not "a pointer to an
> object that is the list (1 2)".
>
> In fact, I just found the explanation, it is in the Introduction to Emacs Lisp
> and it says:
>
>> When a variable is set to a list with a function such as setq, it stores the
>> address of the first box in the variable.
>
> So, setq has a specific behavior when it applies to lists: it evaluates the
> form as a pointer to an object and not as a value.

I don't think setq is behaving any different with lists than with other
Lisp objects. Lists are defined this way in Lisp, cf. (info "(elisp)
Cons Cell Type"):

A “list” is a series of cons cells, linked together so that the CDR
slot of each cons cell holds either the next cons cell or the empty
list.
[...]
A note to C programmers: a Lisp list thus works as a “linked list”
built up of cons cells. Because pointers in Lisp are implicit, we
do not distinguish between a cons cell slot holding a value versus
pointing to the value.

See also the diagrams and explanations in (info "(elisp) Box Diagrams")
and in the discussion of `append' in (info "(elisp) Building Lists").

Steve Berman

[Jean-Christophe Helary]

> On Dec 2, 2018, at 22:08, Stephen Berman <***@gmx.net> wrote:
>>
>> That's not clear at all from the paragraph you quote. Because for all
>> practical purposes, when I evaluate list0 I get (1 2) and not "a pointer to an
>> object that is the list (1 2)".
>>
>> In fact, I just found the explanation, it is in the Introduction to Emacs Lisp
>> and it says:
>>
>>> When a variable is set to a list with a function such as setq, it stores the
>>> address of the first box in the variable.
>>
>> So, setq has a specific behavior when it applies to lists: it evaluates the
>> form as a pointer to an object and not as a value.
>
> I don't think setq is behaving any different with lists than with other
> Lisp objects. Lists are defined this way in Lisp, cf. (info "(elisp)
> Cons Cell Type"):

Yes, but a list does not generally evaluate to a pointer to the first cell of its cons. Which is the case when setq is used. Which is the reason why the Introduction insists on that aspect of setq, because before that, all the setq examples assigned "straight" values to variables.

For ex. The first sentences of "Global Variables" in the Reference are like this:

> You specify a value for a symbol with setq. For example, (setq x '(a b))
> gives the variable x the value (a b).

They don't say:

(setq x '(a b)) stores the address of the first (cons) cell in the variable.

Which it does, and which is confusing if you expect x to hold '(a b), like I was today.

So I think it would be nice to add a few lines here and there to clarify that behavior.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Michael Heerdegen]

Jean-Christophe Helary <***@gmail.com> writes:

> > I don't think setq is behaving any different with lists than with other
> > Lisp objects. Lists are defined this way in Lisp, cf. (info "(elisp)
> > Cons Cell Type"):
>
> Yes, but a list does not generally evaluate to a pointer to the first
> cell of its cons.

When one is saying that lists are referenced by pointers this is mainly
to help people coming from other programming languages to understand
that multiple variables can be bound to the same object. It's probably
better to say that multiple variables can be bound to the same value (or
object).

Apart from that, note that a list is identical to its first cons.

> Which is the case when setq is used. Which is the reason why the
> Introduction insists on that aspect of setq, because before that, all
> the setq examples assigned "straight" values to variables.

There is nothing special with setq here, really. Whenever you refer to
the same Lisp object in different places in your code in whatever way,
you see the same object modified in all places at the same time when you
modify it. Variables bound to the same value (via setq or in any other
way) is only one case. In Lisp it's always like that, as long as you
look at the same value.

It is also not special to lists: you get the same for all objects that
can be modified, like any conses and trees, strings, arrays, keymaps
(which are actually lists), defstructs, eieio objects, vectors,
bool-vectors, ...

Michael.

[Jean-Christophe Helary]

> On Dec 2, 2018, at 23:40, Michael Heerdegen <***@web.de> wrote:
>
> Apart from that, note that a list is identical to its first cons.

I wish "Lists and Cons Cells" had something as plainly written as that.

Although, I'm a bit confused. Do you mean "first cons cell" ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Michael Heerdegen]

Jean-Christophe Helary <***@gmail.com> writes:

> > On Dec 2, 2018, at 23:40, Michael Heerdegen
> > <***@web.de> wrote:
> >
> > Apart from that, note that a list is identical to its first cons.
>
> I wish "Lists and Cons Cells" had something as plainly written as
> that.

"It says "Lists in Lisp are not a primitive data type; they are built up
from “cons cells”". Doesn't that imply what I wrote?

> Although, I'm a bit confused. Do you mean "first cons cell" ?

Yes, "cons" is often used as abbreviation of "cons cell".


Michael.

[Jean-Christophe Helary]

> On Dec 3, 2018, at 0:44, Michael Heerdegen <***@web.de> wrote:
>
> Jean-Christophe Helary <***@gmail.com> writes:
>
>>> On Dec 2, 2018, at 23:40, Michael Heerdegen
>>> <***@web.de> wrote:
>>>
>>> Apart from that, note that a list is identical to its first cons.
>>
>> I wish "Lists and Cons Cells" had something as plainly written as
>> that.
>
> "It says "Lists in Lisp are not a primitive data type; they are built up
> from “cons cells”". Doesn't that imply what I wrote?

If it were we would not have this exchange, would we?

>> Although, I'm a bit confused. Do you mean "first cons cell" ?
>
> Yes, "cons" is often used as abbreviation of "cons cell".

Thank you.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Stephen Berman]

On Sun, 2 Dec 2018 22:28:39 +0900 Jean-Christophe Helary <***@gmail.com> wrote:

>> On Dec 2, 2018, at 22:08, Stephen Berman <***@gmx.net> wrote:
[...]
>>
>> I don't think setq is behaving any different with lists than with other
>> Lisp objects. Lists are defined this way in Lisp, cf. (info "(elisp)
>> Cons Cell Type"):
>
> Yes, but a list does not generally evaluate to a pointer to the first cell of
> its cons. Which is the case when setq is used. Which is the reason why the
> Introduction insists on that aspect of setq, because before that, all the setq
> examples assigned "straight" values to variables.
>
> For ex. The first sentences of "Global Variables" in the Reference are like this:
>
>> You specify a value for a symbol with setq. For example, (setq x '(a b))
>> gives the variable x the value (a b).
>
> They don't say:
>
> (setq x '(a b)) stores the address of the first (cons) cell in the variable.
>
> Which it does, and which is confusing if you expect x to hold '(a b), like I
> was today.
>
> So I think it would be nice to add a few lines here and there to clarify that
> behavior.

I think your confusion may be due to not distinguishing the value
assigned by setq, which is a particular object, and the form of the
value, which may look the same but nevertheless be a different object.
Look again at your original example:

(setq list0 '(1 2))
(setq list1 list0)

I pointed out that the second setq sets the value of `list1' to the
value of `list0', so they refer to the same object:

(eq list1 list0)
=>
t

But if you now do this:

(setq list1 '(1 2))

you have set the value of `list1' to a new list, which happens to have
the same structure as the value of `list0' but is not the same object:

(eq list1 list0)
=>
nil

And now (setcar list0 3) turns the value of `list0' into (3 2) but the
value of `list1' is still (1 2).

You see the same behavior e.g. with strings (which are implemented in C
as arrays, i.e. a variable whose value is a string points to the address
of the first element of the array holding the characters of the string):

(setq str0 "bla")
(setq str1 str0)

(eq str1 str0)
=>
t

(setq str1 "bla")

(eq str1 str0)
=>
nil

So there is no special behavior of setq, but differences due to the
objects themselves.

Steve Berman

[Jean-Christophe Helary]

> On Dec 3, 2018, at 0:00, Stephen Berman <***@gmx.net> wrote:
>
> I think your confusion may be due to not distinguishing the value
> assigned by setq, which is a particular object, and the form of the
> value, which may look the same but nevertheless be a different object.

You are absolutely right.

But I think the "not distinguishing" the difference between the two is partially caused by the way the Reference is written:

Global Variables:
> You specify a value for a symbol with setq. For example, (setq x '(a b))
> gives the variable x the value (a b).

This is not saying: gives the variable x a pointer to the object (a b)

Setting Variable Values:
> setq [symbol form]. . . [Special Form] This special form is the most common method of changing a variable’s value. Each symbol is given a new value, which is the result of evaluating the corresponding form.

So, I go checking the Evaluation chapter.

And the Evaluation chapter is not very clear. The form in my case is a symbol form. So it is evaluated as a variable, for its value, and I'm not seeing much about the value of lists in that chapter.

So I go to the "Lists and Cons Cells" chapter, and there, I'm not finding anything that tells what the value of a list is.

The only hint I got was when I was looking for the reason for the weird behavior I was seeing, in the Introduction:
> When a variable is set to a list with a function such as setq, it stores the address of the first box in the variable.

That does not say that the value of a list is a "cons", just that for lists, setq works not as expected from what can be read in the previous parts.

Now, if you think that the Reference has something that puts that clearly, I'd love a pointer.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Barry Margolin]

In article <mailman.5026.1543764670.1284.help-gnu-***@gnu.org>,
Jean-Christophe Helary <***@gmail.com> wrote:

> > On Dec 3, 2018, at 0:00, Stephen Berman <***@gmx.net> wrote:
> >
> > I think your confusion may be due to not distinguishing the value
> > assigned by setq, which is a particular object, and the form of the
> > value, which may look the same but nevertheless be a different object.
>
> You are absolutely right.
>
> But I think the "not distinguishing" the difference between the two is
> partially caused by the way the Reference is written:
>
> Global Variables:
> > You specify a value for a symbol with setq. For example, (setq x '(a b))
> > gives the variable x the value (a b).
>
> This is not saying: gives the variable x a pointer to the object (a b)

There are no pointers in Lisp. There are just objects, the pointers are
in the implementation.

The important thing is that

(setq list1 list2)

doesn't make a copy of the value of list2 when assigning to list1. The
two variables refer to the same value when this is done.

--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Jean-Christophe Helary]

Barry, thank you for the reply.

> On Dec 2, 2018, at 20:21, Barry Margolin <***@alum.mit.edu> wrote:
>
>> I spend most of the day investigating why creating a list with setq was not
>> "working".
>>
>> For ex:
>> (setq list0 '(1 2))
>> (setq list1 list0)
>>
>> If you do
>>
>> (setcar list0 0)
>>
>> then for some reason (for which I could not find an explanation in the elisp
>> reference) the car of list1 also changes, and vice-versa.
>>
>> Which is totally unexpected since when you do:
>>
>> (setq list0 0)
>>
>> list1 does not become 0
>>
>> I don't suppose that's a bug, but really it ought the be very clearly
>> documented in the reference. Also, I'd like to know why that's happening.
>
> list0 and list1 both contain references to the same cons.

The reference says:

> Note that the first form is evaluated, then the first symbol is set...

So in my case I expected to have list0 evaluated to (1 2) and list1 set to (1 2).

You mean that list0 evaluates to a pointer to a cons that holds the values (1 2) and that list1 is set to that pointer.

I'm ok if that is true but I wish it were plainly written in the reference. Because I can't find a place where it is clearly written that lists evaluate to a pointer to their cons.

> If you're familiar with C, you can think of Lisp variables as being like
> pointers, and conses are like structures. Your code is equivalent to:

I am not familiar with C but think you for the explanations.

> cons *list0 = malloc(sizeof(cons));
> list0->car = make_number(1);
> list0->cdr = malloc(sizeof(cons));
> list0->cdr->car = make_number(2);
> list0->cdr->cdr = null;
> cons *list1 = list0;
> list0->car = make_number(0);


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Stefan Monnier]

Here's another take on it:

> If you do
> (setcar list0 0)

Why? Just don't use setcar/setcdr!

> There are probably better ways to create lists based on other lists without
> "linking" the two, so I'd like some information about that.

The better way is to not modify the lists, so you're not affected by
whether they're linked or not.


Stefan

[Jean-Christophe Helary]

> On Dec 3, 2018, at 0:07, Stefan Monnier <***@iro.umontreal.ca> wrote:
>
> Here's another take on it:
>
>> If you do
>> (setcar list0 0)
>
> Why? Just don't use setcar/setcdr!

Lovely :)

When I check "Modifying Existing List Structure" the only things I find of any use in my case are setcar/setcdr.

>> There are probably better ways to create lists based on other lists without
>> "linking" the two, so I'd like some information about that.
>
> The better way is to not modify the lists, so you're not affected by
> whether they're linked or not.

I would certainly have considered that if I had known that setq was linking the lists :)

And I'm sure the code I wrote is laughable, because there are probably thousands of more idiomatic ways to write what I want to achieve, but if there had been just a footnote about setq linking lists, I certainly would not have spent the day on that :)


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Stefan Monnier]

> When I check "Modifying Existing List Structure" the only things I find of
> any use in my case are setcar/setcdr.

That's because "modifying" is the wrong way to think about it.

That section should start by telling the user that most likely what they
really want to do is something else (i.e. get a similar list structure
with some differences).

> I would certainly have considered that if I had known that setq was
> linking the lists :)

Clearly, "linking the lists" means something to you, but it means
nothing to me, so the manual can't really say something like that.


Stefan

[Jean-Christophe Helary]

> On Dec 3, 2018, at 1:05, Stefan Monnier <***@iro.umontreal.ca> wrote:
>
>> When I check "Modifying Existing List Structure" the only things I find of
>> any use in my case are setcar/setcdr.
>
> That's because "modifying" is the wrong way to think about it.
>
> That section should start by telling the user that most likely what they
> really want to do is something else (i.e. get a similar list structure
> with some differences).

I see. Eventually I used copy-tree instead to initialize the new lists and then modified them separately with setcar.

>> I would certainly have considered that if I had known that setq was
>> linking the lists :)
>
> Clearly, "linking the lists" means something to you, but it means
> nothing to me, so the manual can't really say something like that.

I think somebody used that term in the thread. I didn't even have that concept before the discussion started :)

Just out of curiosity, let me post what I did. There are probably better ways to do it, but that's the best I could come up with today. I'd love to be able to think in terms closer to what elisp allows though.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune


;; The function takes a date d and returns a (d m y) list where (d m y) is the closest day to today
;; For ex, today is 2018/12/3
;; d=1 -> (1 12 2018)
;; d=30 -> (30 11 2018)
;; d=15 -> (15 12 2018)
;; I use the function in a template for a blog that I write one page a day.
;; When I launch the template for a given day, it creates links for the previous day and the next day
;; I used the "closest" assumption because I'm either writing the blog late, or outputing future days templates for preparation.


(defun getMyDate (myDay)
(interactive)
(if (or (> 1 myDay) (< 32 myDay))
(setq myDay (nth 3 (decode-time))))
(setq now (decode-time (float-time))
myDateLastMonth (copy-tree now)
myDateThisMonth (copy-tree now)
myDateNextMonth (copy-tree now)
now (encode-time now 'integer))

;; need to create "last month", "next month", "last year", "next year"
;; 1 day is 84600 seconds
;; 1 month is approximately 2,592,000 seconds
;; 1 year is approximately 31,536,000 seconds
(setq yesterDay (nth 3 (decode-time (- (float-time) 84600))) ;; not used in the function
toMorrow (nth 3 (decode-time (+ (float-time) 84600))) ;; not used in the function
lastMonth (nth 4 (decode-time (- (float-time) 2592000)))
thisMonth (nth 4 (decode-time)) ;; not used in the function
nextMonth (nth 4 (decode-time (+ (float-time) 2592000)))
lastYear (nth 5 (decode-time (- (float-time) 31536000)))
thisYear (nth 5 (decode-time)) ;; not used in the function
nextYear (nth 5 (decode-time (+ (float-time) 31536000))))

;; create the data for last month
(setcar (cdr (cdr (cdr myDateLastMonth))) myDay)
(setcar (cdr (cdr (cdr (cdr myDateLastMonth)))) lastMonth)
(if (= lastMonth 12)
(setcar (cdr (cdr (cdr (cdr (cdr myDateLastMonth))))) lastYear))

;; create the data for this month
(setcar (cdr (cdr (cdr myDateThisMonth))) myDay)

;; create the data for next month
(setcar (cdr (cdr (cdr myDateNextMonth))) myDay)
(setcar (cdr (cdr (cdr (cdr myDateNextMonth)))) nextMonth)
(if (= nextMonth 1)
(setcar (cdr (cdr (cdr (cdr (cdr myDateNextMonth))))) nextYear))

;; compare the dates to find the closest
(setq a (abs (- now (encode-time myDateLastMonth 'integer)))
b (abs (- now (encode-time myDateThisMonth 'integer)))
c (abs (- (encode-time myDateNextMonth 'integer))))

(if (and (< a b) (< b c))
(setq myMonth (nth 4 myDateLastMonth)
myYear (nth 5 myDateLastMonth))
(if (and (< b a) (< b c))
(setq myMonth (nth 4 myDateThisMonth)
myYear (nth 5 myDateThisMonth))
(setq myMonth (nth 4 myDateNextMonth)
myYear (nth 5 myDateNextMonth))))
;; et voilà
(list myDay myMonth myYear))

(getMyDate 30)

[Stefan Monnier]

> I see. Eventually I used copy-tree instead to initialize the new lists and
> then modified them separately with setcar.

So you're back to using `setcar` :-(

> Just out of curiosity, let me post what I did. There are probably
> better ways to do it, but that's the best I could come up with
> today. I'd love to be able to think in terms closer to what elisp
> allows though.

Those date/time thingies are indeed rather annoying to construct.
copy-sequence + in-place modification is probably the best you can
use, indeed :-(

> (setq now (decode-time (float-time))
> myDateLastMonth (copy-tree now)
> myDateThisMonth (copy-tree now)
> myDateNextMonth (copy-tree now)
> now (encode-time now 'integer))

You're using `setq` on vars you haven't declared/defined yet!
And theses aren't "trees" but lists/sequences, so better use
`copy-sequence` which is also more efficient:

(let* ((decoded-now (decode-time (float-time)))
(myDateLastMonth (copy-tree now))
(myDateThisMonth (copy-tree now))
(myDateNextMonth (copy-tree now))
(encoded-now (encode-time now 'integer)))

I recommend you put `-*- lexical-binding:t -*-` somewhere on the first
line of your file, and that you `M-x byte-compile RET` your file so
Emacs can help you catch some of those issues.

> ;; create the data for last month
> (setcar (cdr (cdr (cdr myDateLastMonth))) myDay)

Better write this as (setf (nth 3 myDateLastMonth) myDay)
It's bad enough that the fields aren't named so you have to refer to
them by position, but having to count `cdr`s is really annoying IMO.


-- Stefan

[Jean-Christophe Helary]

Thank you for the comments :)

> You're using `setq` on vars you haven't declared/defined yet!

The Introduction doesn't even mention that...

> I recommend you put `-*- lexical-binding:t -*-` somewhere on the first
> line of your file, and that you `M-x byte-compile RET` your file so
> Emacs can help you catch some of those issues.

I will.

> Better write this as (setf (nth 3 myDateLastMonth) myDay)

No reference to setf in the Introduction, and it's buried under tons of reference in the Reference...

Thank you again. Now I think there really is too much of a gap between the Introduction and the Reference. The exchange today kind of confirms that there is a need to overhaul the documentation so as to get beginners to produce better code...

Jean-Christophe

> On Dec 3, 2018, at 2:02, Stefan Monnier <***@iro.umontreal.ca> wrote:
>
>> I see. Eventually I used copy-tree instead to initialize the new lists and
>> then modified them separately with setcar.
>
> So you're back to using `setcar` :-(
>
>> Just out of curiosity, let me post what I did. There are probably
>> better ways to do it, but that's the best I could come up with
>> today. I'd love to be able to think in terms closer to what elisp
>> allows though.
>
> Those date/time thingies are indeed rather annoying to construct.
> copy-sequence + in-place modification is probably the best you can
> use, indeed :-(
>
>> (setq now (decode-time (float-time))
>> myDateLastMonth (copy-tree now)
>> myDateThisMonth (copy-tree now)
>> myDateNextMonth (copy-tree now)
>> now (encode-time now 'integer))
>
> You're using `setq` on vars you haven't declared/defined yet!
> And theses aren't "trees" but lists/sequences, so better use
> `copy-sequence` which is also more efficient:
>
> (let* ((decoded-now (decode-time (float-time)))
> (myDateLastMonth (copy-tree now))
> (myDateThisMonth (copy-tree now))
> (myDateNextMonth (copy-tree now))
> (encoded-now (encode-time now 'integer)))
>
> I recommend you put `-*- lexical-binding:t -*-` somewhere on the first
> line of your file, and that you `M-x byte-compile RET` your file so
> Emacs can help you catch some of those issues.
>
>> ;; create the data for last month
>> (setcar (cdr (cdr (cdr myDateLastMonth))) myDay)
>
> Better write this as (setf (nth 3 myDateLastMonth) myDay)
> It's bad enough that the fields aren't named so you have to refer to
> them by position, but having to count `cdr`s is really annoying IMO.
>
>
> -- Stefan
>
>

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Rusi]

On Sunday, December 2, 2018 at 9:11:15 PM UTC+5:30, Jean-Christophe Helary wrote:
> > On Dec 3, 2018, at 0:07, Stefan Monnier wrote:
> >
> > Here's another take on it:
> >
> >> If you do
> >> (setcar list0 0)
> >
> > Why? Just don't use setcar/setcdr!

That one line is succinct no doubt! Do you think its really comprehensible?

>
> Lovely :)
>
> When I check "Modifying Existing List Structure" the only things I find of any use in my case are setcar/setcdr.
>
> >> There are probably better ways to create lists based on other lists without
> >> "linking" the two, so I'd like some information about that.
> >
> > The better way is to not modify the lists, so you're not affected by
> > whether they're linked or not.
>
> I would certainly have considered that if I had known that setq was linking the lists :)

And thats what I mean: "Lovely" ⇏ "Understood"!

More generally assignment ≠ mutation, especially in latent languages like lisp/python

By coincidence I was working on a sequel to my blog post:
http://blog.languager.org/2012/10/functional-programming-lost-booty.html
Out there I had tried to say: functional programming has nice *features* that
may be used without using functional *languages*

Over time I am coming to see that there is an imbalance in the view in that post…

Niklaus Wirth said: The most important choices that a language designer makes
is what to leave out
Yeah that sounds like classical religious morality — the good person is the one
who has/enjoys/etc less.
And that is true — when programmers stopped ‘enjoying’ interrupts, registers, etc
we moved from assembly to (what was then called) hi-level programming

The same is true for FPLs — how to become more powerful by having less powerful
languages??

Here is my (as yet unfilled out) org ode list of these
"impoverishments that are enrichments"
Yeah they are probably not comprehensible as yet
For now I will just say that the second and third points are different:
assignment changes *variables*; mutability changes *constants*
(setq is assignment; set-car is mutation)

* Print Statement
* Assignment
* Mutability
* Pass-by malarchy
* Expressions AND Statements Syntax
* Void function
* Expressions AND Statements Semantics
* General typeless statement construction
* OOP (inheritance)

[My reason for posting this yet: Are there other unnecessarys of imperative/OO
programming that are 'irrelevantized' and thence removed in FPLS?
Would be interested to hear…

Sorry to Jean-Christophe if that is not very helpful
Here are my FP posts, admittedly mostly language neutral
http://blog.languager.org/search/label/FP

[Robert Thorpe]

I agree with you on some things and I disagree with you on others.

Notice also it says this in the Emacs Lisp intro in the node "Using
setq":

> Although I have been using the term ‘assign’, there is another way of
> thinking about the workings of ‘set’ and ‘setq’; and that is to say
> that ‘set’ and ‘setq’ make the symbol _point_ to the list. This
> latter way of thinking is very common and in forthcoming chapters we
> shall come upon at least one symbol that has ‘pointer’ as part of its
> name. The name is chosen because the symbol has a value, specifically
> a list, attached to it; or, expressed another way, the symbol is set
> to “point” to the list.

It also says in the section on setcar:

> As you might guess from their names, the ‘setcar’ and ‘setcdr’
> functions set the CAR or the CDR of a list to a new value. They
> actually change the original list, unlike ‘car’ and ‘cdr’ which leave
> the original list as it was.
...
> Put another way, the variable ‘animals’ points to the list ‘(antelope
> giraffe lion tiger)’.

In the section "How Lists are Implemented" it describes how things work
internally.

So, I think you could have avoided your first problem if you'd read the
intro more carefully.

However, you're quite right in what you wrote most recently...

>> You're using `setq` on vars you haven't declared/defined yet!
>
> The Introduction doesn't even mention that...

It doesn't. It mentions setq, let and defvar. But it never says that
it's the preferred style to define variables with let & defvar first. I
think it should say that.

I've seen lots of beginners write programs that setq undefined symbols
and now I know why.

>> Better write this as (setf (nth 3 myDateLastMonth) myDay)
>
> No reference to setf in the Introduction, and it's buried under tons of reference in the Reference...

I agree here too. I think setf is important enough that the introduction
should mention it at least in passing.

BR,
Robert Thorpe

[Jean-Christophe Helary]

Robert,

Thank you *very much* for the precise pointers.

> On Dec 3, 2018, at 4:11, Robert Thorpe <***@robertthorpeconsulting.com> wrote:
>
> However, you're quite right in what you wrote most recently...

It took me a while to sort things out, as the hints kept coming :)

>>> You're using `setq` on vars you haven't declared/defined yet!
>>
>> The Introduction doesn't even mention that...
>
> It doesn't. It mentions setq, let and defvar. But it never says that
> it's the preferred style to define variables with let & defvar first. I
> think it should say that.
>
> I've seen lots of beginners write programs that setq undefined symbols
> and now I know why.
>
>>> Better write this as (setf (nth 3 myDateLastMonth) myDay)
>>
>> No reference to setf in the Introduction, and it's buried under tons of reference in the Reference...
>
> I agree here too. I think setf is important enough that the introduction
> should mention it at least in passing.

Ok, I'll work on that and will propose something. Thank you again.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Barry Margolin]

In article <mailman.5042.1543777897.1284.help-gnu-***@gnu.org>,
Robert Thorpe <***@robertthorpeconsulting.com> wrote:

> I've seen lots of beginners write programs that setq undefined symbols
> and now I know why.

There's nothing wrong with it in Emacs Lisp and a number of other Lisp
dialects. I think Common Lisp was the first specification that made it
questionable, but it was commonplace in the days of Maclisp, which is
the dialect that Emacs Lisp is most directly descended from.

--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Stefan Monnier]

> There's nothing wrong with it in Emacs Lisp

Actually, there is in the sense that these are global variables and so
can interfere with other Elisp packages.

> and a number of other Lisp dialects.

For most other Lisps what the user writes only creates havoc with its
own code because each program runs in its own process. But Emacs being
its own kind of OS the situation is a bit different. Of course similar
situations occur with "Lisp machine" kind of systems (or Smalltalk
machines, ...).


Stefan

[Barry Margolin]

In article <mailman.5145.1543931778.1284.help-gnu-***@gnu.org>,
Stefan Monnier <***@iro.umontreal.ca> wrote:

> > There's nothing wrong with it in Emacs Lisp
>
> Actually, there is in the sense that these are global variables and so
> can interfere with other Elisp packages.

Declaring the variable with defvar won't change that. Anyway, the code
we're talking about is just example snippets, not a full program.

--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Robert Thorpe]

Barry Margolin <***@alum.mit.edu> writes:

> In article <mailman.5042.1543777897.1284.help-gnu-***@gnu.org>,
> Robert Thorpe <***@robertthorpeconsulting.com> wrote:
>
>> I've seen lots of beginners write programs that setq undefined symbols
>> and now I know why.
>
> There's nothing wrong with it in Emacs Lisp and a number of other Lisp
> dialects. I think Common Lisp was the first specification that made it
> questionable, but it was commonplace in the days of Maclisp, which is
> the dialect that Emacs Lisp is most directly descended from.

Yes. But, there's still the issue of accidentally creating global
variables.

I think the modern learner will expect "setq" to do what "let"
does unless told otherwise.

BR,
Robert Thorpe

[Drew Adams]

> I think the modern learner will expect "setq" to
> do what "let" does unless told otherwise.

"Modern learner"... Why not just say Lisp learner? ;-)

How/why is "the modern learner" different here from
the learner of 2008, 1998, 1988, or 1978? (Or `68
or `58, for that matter?) Am I missing something?

Lexically bound, "ordinary", local variables are as
old as Fortran - nay, assembler. Nothing particularly
modern about them, or about folks who are used to only
them. They were even added to Lisp as long ago as the
'70s (at least).

Lisp is typically not a Lisp learner's first language.
Gunk accumulated on eyeballs can need to be scraped
off, to see more easily and clearly.

[Jean-Christophe Helary]

> On Dec 5, 2018, at 11:32, Drew Adams <***@oracle.com> wrote:
>
> Lisp is typically not a Lisp learner's first language.

I'm straying off topic here but let me suggest that emacs could (and is) used by first learners and that the Introduction could be used as a Lisp manual for such people.

Hence the need to clarify things and slightly bridge the gap between the Introduction and the Reference.

There is nothing intrinsically difficult to emacs lisp, compared to a language (and ecosystem) like AppleScript that *is* advertised as a first learner language, even though both target the same class of people: users who need to do automation on their machine.

That's exactly the spirit of what Stallman wrote when he referred to secretaries who were not conscious of doing "programming" but were still writing programs in Emacs.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Marcin Borkowski]

On 2018-12-05, at 07:45, Jean-Christophe Helary <***@gmail.com> wrote:

>> On Dec 5, 2018, at 11:32, Drew Adams <***@oracle.com> wrote:
>>
>> Lisp is typically not a Lisp learner's first language.
>
> I'm straying off topic here but let me suggest that emacs could (and is) used by first learners and that the Introduction could be used as a Lisp manual for such people.
>
> Hence the need to clarify things and slightly bridge the gap between the Introduction and the Reference.
>
> There is nothing intrinsically difficult to emacs lisp, compared to a language (and ecosystem) like AppleScript that *is* advertised as a first learner language, even though both target the same class of people: users who need to do automation on their machine.
>
> That's exactly the spirit of what Stallman wrote when he referred to secretaries who were not conscious of doing "programming" but were still writing programs in Emacs.

+1 to all Jean-Christophe says.

And your emails make really want to get back to work on my intermediate
Elisp textbook... (I have to finish another book I'm writing right now,
especially that I'm a coauthor and expected to work rather hard on it.)

Best,

--
Marcin Borkowski
http://mbork.pl

[Jean-Christophe Helary]

> On Dec 5, 2018, at 17:00, Marcin Borkowski <***@mbork.pl> wrote:
>
> And your emails make really want to get back to work on my intermediate
> Elisp textbook... (I have to finish another book I'm writing right now,
> especially that I'm a coauthor and expected to work rather hard on it.)

Marcin,

I'm actually working on a rewrite of the Introduction, as I progress through it. It's hard because I need to write code (and play with the kids, and work) more than I have time to read the book and write additional pages...

I feel like a lot of attempts at writing introductions do not reach their objectives because they are written by people who do not remember how it was when they needed the introduction... That's my feeling when I read the Introduction, even though I have a lot of respect for what Chassell did with that book.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

[Drew Adams]

> > Lisp is typically not a Lisp learner's first language.
>
> Emacs could (and is) used by first learners and ...
> the Introduction could be used as a Lisp manual for
> such people.

Yes, of course.

The point is that someone coming to Lisp from another
language, especially (and typically) from a language
where variables are essentially local & lexical, may
have a harder time "getting it" than someone learning
programming with Lisp as her first language.

Things like list structure (including, yes, sharing
structure), symbols (named objects with properties),
dynamic scope/binding, `setq' (which can act on both
global & local vars), and even REPL/interpretation
can seem quite odd if you come to Lisp with only C
or Java or ... eyes.

Years ago I would have added higher-order and
anonymous functions to the list. Even more years
ago I would have added recursion to it. Depending
on the languages you are used to, the list can vary.
But Lisp is not C or Java or Haskell or ...

FWIW, I came to Lisp (and to purely functional,
logic-programming, and OOP languages) from Fortran.
No recursion, no nothin' - nada. Another planet.
But lots of variable-value/common-memory sharing.

[Barry Margolin]

In article <mailman.5218.1544021892.1284.help-gnu-***@gnu.org>,
Drew Adams <***@oracle.com> wrote:

> > > Lisp is typically not a Lisp learner's first language.
> >
> > Emacs could (and is) used by first learners and ...
> > the Introduction could be used as a Lisp manual for
> > such people.
>
> Yes, of course.
>
> The point is that someone coming to Lisp from another
> language, especially (and typically) from a language
> where variables are essentially local & lexical, may
> have a harder time "getting it" than someone learning
> programming with Lisp as her first language.
>
> Things like list structure (including, yes, sharing
> structure), symbols (named objects with properties),
> dynamic scope/binding, `setq' (which can act on both
> global & local vars), and even REPL/interpretation
> can seem quite odd if you come to Lisp with only C
> or Java or ... eyes.

If you come to it from Java, JavaScript, or Python it actually shouldn't
be that hard; they all pass data as references to structures. C and C++
are the only popular languages with explicit pointers. PHP is in between
-- arrays are copied, but objects are not.

--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Barry Margolin]

In article <mailman.5186.1543978155.1284.help-gnu-***@gnu.org>,
Drew Adams <***@oracle.com> wrote:

> Lisp is typically not a Lisp learner's first language.

It often was back in the days of Multics Emacs (30 years ago). It was
pretty common for non-programmers to learn it so they could customize
their editor. Although often they just learned enough to set a few
customization variables, not write complex extensions; that's the kind
of thing that's now automated with M-x customize.

--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***