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.
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
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!
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
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.
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.
-
Ala'a Mohammad -
Alessio Stalla -
Didier Verna -
Elias Mårtenson -
Pascal Costanza -
Willem Broekema