* bug#40692: 28.0.50; Constant list modified inside function
@ 2020-04-17 23:45 Ivan Andrus
2020-04-18 3:05 ` Ivan Andrus
2020-04-18 9:18 ` Štěpán Němec
0 siblings, 2 replies; 6+ messages in thread
From: Ivan Andrus @ 2020-04-17 23:45 UTC (permalink / raw)
To: 40692
Starting from Emacs -Q (I am building off of trunk, but my brother verified the same behavior in 26.3), if I evaluate the following code I get an error the second time I call withdraw.
(defmacro show (var)
`(message ,(format "%S %%S" var) ,var))
(defun my-test-fun (amount params)
(when (memq 'tricked-ya params)
(error "What happened here?"))
(show amount)
(show params)
(setcdr (cdr params) (list 'tricked-ya))
(show params))
(defun fun-withdraw (amount)
(my-test-fun amount
`((amount . , amount)
(const . some-constant))))
(fun-withdraw 12)
(fun-withdraw 12) ;; The second time it's called it will error because the "constant" list was modified.
I believe this is the root cause of a bug in magit/forge https://github.com/magit/forge/issues/267 in which all subsequent pull requests created have the same name. The maintainer of magit/forge (tarsius) was unable to reproduce that bug, so I tried my hand at creating a minimal test case, and I was able to get it down to this.
Now, I understand reference semantics of lists in general, but it seems like this should be different. If this behavior is intentional, what's the best way to for creation of a new list every time so that functions using the alist don't have to worry about not changing the list?
-Ivan Andrus
In GNU Emacs 28.0.50 (build 18, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G4032))
of 2020-04-10 built on iandrus-macOS
Repository revision: 965390ca5f206c6358014574fe5140ba40850391 -- some local changes on top of e18c24b35a7cf9bb1b91288b706fa448ed28a7c2
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1671
System Description: Mac OS X 10.14.6
Configured using:
'configure
PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/opt/libxml2/lib/pkgconfig
--with-sound=yes --with-ns --with-modules --with-file-notification=yes
--enable-gcc-warnings=warn-only --with-xpm --with-jpeg --with-tiff
--with-gif --with-png --with-rsvg --with-xml2 --with-imagemagick
--with-json --with-xft --with-libotf --with-gnutls=no --with-makeinfo
--with-libgmp'
Configured features:
RSVG IMAGEMAGICK GLIB NOTIFY KQUEUE ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS
XIM NS MODULES THREADS JSON PDUMPER GMP
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#40692: 28.0.50; Constant list modified inside function
2020-04-17 23:45 bug#40692: 28.0.50; Constant list modified inside function Ivan Andrus
@ 2020-04-18 3:05 ` Ivan Andrus
2020-04-18 9:18 ` Štěpán Němec
1 sibling, 0 replies; 6+ messages in thread
From: Ivan Andrus @ 2020-04-18 3:05 UTC (permalink / raw)
To: 40692
On Apr 17, 2020, at 5:45 PM, Ivan Andrus <darthandrus@gmail.com> wrote:
>
> I believe this is the root cause of a bug in magit/forge https://github.com/magit/forge/issues/267 in which all subsequent pull requests created have the same name. The maintainer of magit/forge (tarsius) was unable to reproduce that bug, so I tried my hand at creating a minimal test case, and I was able to get it down to this.
>
> Now, I understand reference semantics of lists in general, but it seems like this should be different. If this behavior is intentional, what's the best way to for creation of a new list every time so that functions using the alist don't have to worry about not changing the list?
I tracked down the function doing the actual changing: json-encode-alist. I filed https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40693
I still find the behavior here confusing, but I expect it will be considered expected behavior.
-Ivan
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#40692: 28.0.50; Constant list modified inside function
2020-04-17 23:45 bug#40692: 28.0.50; Constant list modified inside function Ivan Andrus
2020-04-18 3:05 ` Ivan Andrus
@ 2020-04-18 9:18 ` Štěpán Němec
2020-04-18 22:49 ` Michael Heerdegen
1 sibling, 1 reply; 6+ messages in thread
From: Štěpán Němec @ 2020-04-18 9:18 UTC (permalink / raw)
To: Ivan Andrus; +Cc: 40692
On Fri, 17 Apr 2020 17:45:12 -0600
Ivan Andrus wrote:
> Starting from Emacs -Q (I am building off of trunk, but my brother verified the same behavior in 26.3), if I evaluate the following code I get an error the second time I call withdraw.
>
> (defmacro show (var)
> `(message ,(format "%S %%S" var) ,var))
>
> (defun my-test-fun (amount params)
> (when (memq 'tricked-ya params)
> (error "What happened here?"))
> (show amount)
> (show params)
> (setcdr (cdr params) (list 'tricked-ya))
> (show params))
>
> (defun fun-withdraw (amount)
> (my-test-fun amount
> `((amount . , amount)
> (const . some-constant))))
>
> (fun-withdraw 12)
>
> (fun-withdraw 12) ;; The second time it's called it will error because the "constant" list was modified.
>
>
> I believe this is the root cause of a bug in magit/forge https://github.com/magit/forge/issues/267 in which all subsequent pull requests created have the same name. The maintainer of magit/forge (tarsius) was unable to reproduce that bug, so I tried my hand at creating a minimal test case, and I was able to get it down to this.
>
> Now, I understand reference semantics of lists in general, but it
> seems like this should be different. If this behavior is intentional,
I think it is, although I admit I was confused by it, too, as I've
somehow come to believe that e.g. `(list) macroexpands to (list 'list),
but that's not the case: it expands to '(list).
> what's the best way to for creation of a new list every time so that
> functions using the alist don't have to worry about not changing the
> list?
If you change the backquoted form in `fun-withdraw' to
(list `(amount . ,amount)
'(const . some-constant))
it works as desired.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#40692: 28.0.50; Constant list modified inside function
2020-04-18 9:18 ` Štěpán Němec
@ 2020-04-18 22:49 ` Michael Heerdegen
2020-04-19 7:08 ` Štěpán Němec
0 siblings, 1 reply; 6+ messages in thread
From: Michael Heerdegen @ 2020-04-18 22:49 UTC (permalink / raw)
To: Štěpán Němec; +Cc: Ivan Andrus, 40692
Štěpán Němec <stepnem@gmail.com> writes:
> > Now, I understand reference semantics of lists in general, but it
> > seems like this should be different. If this behavior is intentional,
>
> I think it is, although I admit I was confused by it, too, as I've
> somehow come to believe that e.g. `(list) macroexpands to (list 'list),
> but that's not the case: it expands to '(list).
Yes, I had been bitten by this as well some time ago. I don't find the
discussion anymore, I had asked somewhere and the answer was that it's
an intended feature of backquote to produce an expansion like that.
Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#40692: 28.0.50; Constant list modified inside function
2020-04-18 22:49 ` Michael Heerdegen
@ 2020-04-19 7:08 ` Štěpán Němec
2021-08-29 22:18 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Štěpán Němec @ 2020-04-19 7:08 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Ivan Andrus, 40692
On Sun, 19 Apr 2020 00:49:02 +0200
Michael Heerdegen wrote:
> Štěpán Němec <stepnem@gmail.com> writes:
>
>> > Now, I understand reference semantics of lists in general, but it
>> > seems like this should be different. If this behavior is intentional,
>>
>> I think it is, although I admit I was confused by it, too, as I've
>> somehow come to believe that e.g. `(list) macroexpands to (list 'list),
>> but that's not the case: it expands to '(list).
>
> Yes, I had been bitten by this as well some time ago. I don't find the
> discussion anymore, I had asked somewhere and the answer was that it's
> an intended feature of backquote to produce an expansion like that.
The "optimization" in absence of unquoted terms seems reasonable, and
e.g. SBCL behaves the same.
I find http://www.lispworks.com/documentation/HyperSpec/Body/02_df.htm
somewhat ambiguous, but http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html
is quite clear:
"Semantics: If no unquote or unquote-splicing forms appear within the <qq
template>, the result of evaluating (quasiquote <qq template>) is
equivalent to the result of evaluating (quote <qq template>)."
Also:
"A quasiquote expression may return either fresh, mutable objects or
literal structure for any structure that is constructed at run time
during the evaluation of the expression. Portions that do not need to be
rebuilt are always literal."
--
Štěpán
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#40692: 28.0.50; Constant list modified inside function
2020-04-19 7:08 ` Štěpán Němec
@ 2021-08-29 22:18 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-29 22:18 UTC (permalink / raw)
To: Štěpán Němec; +Cc: Michael Heerdegen, Ivan Andrus, 40692
Štěpán Němec <stepnem@gmail.com> writes:
>> Yes, I had been bitten by this as well some time ago. I don't find the
>> discussion anymore, I had asked somewhere and the answer was that it's
>> an intended feature of backquote to produce an expansion like that.
>
> The "optimization" in absence of unquoted terms seems reasonable, and
> e.g. SBCL behaves the same.
So it seems like this behaves as intended, and I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-08-29 22:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-17 23:45 bug#40692: 28.0.50; Constant list modified inside function Ivan Andrus
2020-04-18 3:05 ` Ivan Andrus
2020-04-18 9:18 ` Štěpán Němec
2020-04-18 22:49 ` Michael Heerdegen
2020-04-19 7:08 ` Štěpán Němec
2021-08-29 22:18 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).