Hello, yesterday, I fell on something extremely weird, or at least, which I currently fail to understand. Basically, after a (defvar *var*), there are times when (setq *var* '(0 0)) doesn't work (the previous value of *var* remains in effect). I cannot currently provide a minimal example because the situation involves several levels of nested macro / function calls in code I didn't write (*var* is solely mine though). At first, I thought I had fallen on a compiler bug, but I get the same behavior with at least 3 lisp implementations. I ultimately found a workaround, consisting in using (list 0 0) instead of '(0 0) in the assignment. I'm hoping this would be a clue to someone here to get at least a direction for investigating... Thanks. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Is it possible to see the not minimal example? Pascal Sent from my iPad
On 3 Oct 2013, at 08:48, Didier Verna <didier@lrde.epita.fr> wrote:
Hello,
yesterday, I fell on something extremely weird, or at least, which I currently fail to understand. Basically, after a (defvar *var*), there are times when (setq *var* '(0 0)) doesn't work (the previous value of *var* remains in effect).
I cannot currently provide a minimal example because the situation involves several levels of nested macro / function calls in code I didn't write (*var* is solely mine though).
At first, I thought I had fallen on a compiler bug, but I get the same behavior with at least 3 lisp implementations.
I ultimately found a workaround, consisting in using (list 0 0) instead of '(0 0) in the assignment. I'm hoping this would be a clue to someone here to get at least a direction for investigating...
Thanks.
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
This sounds really weird. Are you providing the full (setq) form to those macros, or the var and value separately? The fact that '(0 0) does not work but (list 0 0) does smells like there's some compiler macro triggering on (constantp value). On Thu, Oct 3, 2013 at 8:48 AM, Didier Verna <didier@lrde.epita.fr> wrote:
Hello,
yesterday, I fell on something extremely weird, or at least, which I currently fail to understand. Basically, after a (defvar *var*), there are times when (setq *var* '(0 0)) doesn't work (the previous value of *var* remains in effect).
I cannot currently provide a minimal example because the situation involves several levels of nested macro / function calls in code I didn't write (*var* is solely mine though).
At first, I thought I had fallen on a compiler bug, but I get the same behavior with at least 3 lisp implementations.
I ultimately found a workaround, consisting in using (list 0 0) instead of '(0 0) in the assignment. I'm hoping this would be a clue to someone here to get at least a direction for investigating...
Thanks.
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
-- Some gratuitous spam: http://ripple.com <http://ripple-project.org> Ripple, social credit system http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my Lisp open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework
On Thu, Oct 3, 2013 at 8:48 AM, Didier Verna <didier@lrde.epita.fr> wrote:
Basically, after a (defvar *var*), there are times when (setq *var* '(0 0)) doesn't work (the previous value of *var* remains in effect).
I guess you are modifying the value of *var*, which is not allowed if it is a quoted list. That's why you need e.g. (list .. ..) or (copy-tree '(.. ..)) instead of '(.. ..). http://stackoverflow.com/questions/10365470/modifying-a-list-passed-as-a-par... - Willem
On 3 October 2013 15:40, Willem Broekema <metawilm@gmail.com> wrote:
I guess you are modifying the value of *var*, which is not allowed if it is a quoted list. That's why you need e.g. (list .. ..) or (copy-tree '(.. ..)) instead of '(.. ..). http://stackoverflow.com/questions/10365470/modifying-a-list-passed-as-a-par...
(SETQ *var* ...) does not change the list. It merely reassigns the variable.
On Thu, Oct 3, 2013 at 9:44 AM, Elias Mårtenson <lokedhs@gmail.com> wrote:
On 3 October 2013 15:40, Willem Broekema <metawilm@gmail.com> wrote:
I guess you are modifying the value of *var*, which is not allowed if it is a quoted list. That's why you need e.g. (list .. ..) or (copy-tree '(.. ..)) instead of '(.. ..).
http://stackoverflow.com/questions/10365470/modifying-a-list-passed-as-a-par...
(SETQ *var* ...) does not change the list. It merely reassigns the variable.
The value that is assigned, that is the problem. That is probably a modified literal list. If there is literally this in the code: (setq *var* '(. . .)) then the compiler is free to extract that '(. . .) part and reuse it all the time this setq form is executed. It can create one literal object and keep it in memory, and always uses it as value. It does not need to build a new list every time. If you modify that special object, e.g. by setting the car of it, then compiler may ignore that and upon the next setq set the value with modified car. - Willem
Willem Broekema <metawilm@gmail.com> wrote:
The value that is assigned, that is the problem. That is probably a modified literal list.
You're absolutely right. I hadn't realized it but I was doing exactly that: http://stackoverflow.com/questions/8962909/why-does-this-function-return-a-d... Thanks for spotting this! -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
On Thu, Oct 3, 2013 at 10:13 AM, Didier Verna <didier@lrde.epita.fr> wrote:
Willem Broekema <metawilm@gmail.com> wrote:
The value that is assigned, that is the problem. That is probably a modified literal list.
You're absolutely right. I hadn't realized it but I was doing exactly that:
http://stackoverflow.com/questions/8962909/why-does-this-function-return-a-d...
N00b! xD But seriously, it is hard to detect these problems when they're buried deep in layers of code.
Thanks for spotting this!
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
-- Some gratuitous spam: http://ripple.com <http://ripple-project.org> Ripple, social credit system http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my Lisp open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework
Alessio Stalla <alessiostalla@gmail.com> wrote:
N00b! xD
Exactly :-) Sometimes, you have your nose stuck deep in the mess and you can't see the broader picture anymore. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Hi, Side question. If you intend to change the value why do you use 'defvar' instead of 'defparameter' Regards, Ala'a On Thu, Oct 3, 2013 at 10:48 AM, Didier Verna <didier@lrde.epita.fr> wrote:
Hello,
yesterday, I fell on something extremely weird, or at least, which I currently fail to understand. Basically, after a (defvar *var*), there are times when (setq *var* '(0 0)) doesn't work (the previous value of *var* remains in effect).
I cannot currently provide a minimal example because the situation involves several levels of nested macro / function calls in code I didn't write (*var* is solely mine though).
At first, I thought I had fallen on a compiler bug, but I get the same behavior with at least 3 lisp implementations.
I ultimately found a workaround, consisting in using (list 0 0) instead of '(0 0) in the assignment. I'm hoping this would be a clue to someone here to get at least a direction for investigating...
Thanks.
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
"Ala'a Mohammad" <amalawi@gmail.com> wrote:
If you intend to change the value why do you use 'defvar' instead of 'defparameter'
In that particular case, it doesn't really matter because this variable is always reinitialized by a function call before doing anything with it. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
participants (6)
-
Ala'a Mohammad -
Alessio Stalla -
Didier Verna -
Elias Mårtenson -
Pascal Costanza -
Willem Broekema