bug#40692: 28.0.50; Constant list modified inside function

bug#40692: 28.0.50; Constant list modified inside function

[Ivan Andrus]

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

bug#40692: 28.0.50; Constant list modified inside function

[Ivan Andrus]

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

bug#40692: 28.0.50; Constant list modified inside function

[Štěpán Němec]

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.

bug#40692: 28.0.50; Constant list modified inside function

[Michael Heerdegen]

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

bug#40692: 28.0.50; Constant list modified inside function

[Štěpán Němec]

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

bug#40692: 28.0.50; Constant list modified inside function

[Lars Ingebrigtsen]

Š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