Prev: Is there a better way to store this?
Next: Lisp sucks!
From: vj on 6 Nov 2009 22:26 Hi All, I have been programming in LISP for couple of months now. Today, came across a new notation and had a question on that. Let me give an example: I have an access to an "object" [i don't know what the technical term is for a variable of this data-type]. (setq some_var data.some_val) by doing the above, i can read the value into some_var. but the following piece of code is not working and i am not sure if i am even on the right track. (setq read_var data.some_val) # read the value (print read_var) # say the value was originally set to 5, we would see 5 here (setq some_var 18) # sets the value to 18 (setq data.some_val some_var) # i expect data.some_val to be set to 18 now (setq read_var data.some_val) # read the value just set (print read_var) # i would expect 18 to be displayed. but i still see 5. why would this be? TIA
From: Pascal J. Bourguignon on 6 Nov 2009 23:15 vj <harikris(a)gmail.com> writes: > I have been programming in LISP for couple of months now. To really answer to your following question, we would have to know what decendent of LISP do you really use? Is that Common Lisp, ISOLisp, LeLisp, Scheme, MacLisp, emacs lisp, ZetaLisp, InterLisp, etc, etc, etc? > Today, came across a new notation and had a question on that. > Let me give an example: > > I have an access to an "object" [i don't know what the technical term > is for a variable of this data-type]. > > (setq some_var data.some_val) > > by doing the above, i can read the value into some_var. Assuming it's Common Lisp, and no special reader trick is active, data.some_val is a mere symbol and therefore it is either a normal variable as well as some_var, or it is a symbol macro, and probably represents some place that is both readable and writeable like a normal variable. In either case, you can get its value by evaluating directly data.some_val, you don't need to store it in some_var. Actually, since you've not shown us that you defined the variable some_var, some strange things may occur in a Common Lisp implementation when you evaluate this setq out of white at the toplevel... > but the following piece of code is not working and i am not sure if i > am even on the right track. > > (setq read_var data.some_val) # read the value > (print read_var) # say the value was originally set to 5, we would see > 5 here > (setq some_var 18) # sets the value to 18 > (setq data.some_val some_var) # i expect data.some_val to be set to 18 > now > (setq read_var data.some_val) # read the value just set > (print read_var) # i would expect 18 to be displayed. but i still see > 5. > > why would this be? It could occur that data.some_val is a symbol macro that expands to an accessor, and that the writer method for this accessor doesn't write the value for some reason (perhaps the new value is invalid for this object?). In any case you are not giving us the context, we don't even know what language you're speaking of! So how can we give you a meaningful answer? -- __Pascal Bourguignon__
From: Anti Vigilante on 6 Nov 2009 23:33 On Sat, 2009-11-07 at 05:15 +0100, Pascal J. Bourguignon wrote: > vj <harikris(a)gmail.com> writes: > > I have been programming in LISP for couple of months now. > > To really answer to your following question, we would have to know > what decendent of LISP do you really use? > > Is that Common Lisp, ISOLisp, LeLisp, Scheme, MacLisp, emacs lisp, > ZetaLisp, InterLisp, etc, etc, etc? > > > > > Today, came across a new notation and had a question on that. > > Let me give an example: > > > > I have an access to an "object" [i don't know what the technical term > > is for a variable of this data-type]. > > > > (setq some_var data.some_val) > > > > by doing the above, i can read the value into some_var. > > Assuming it's Common Lisp, and no special reader trick is active, > data.some_val is a mere symbol and therefore it is either a normal > variable as well as some_var, or it is a symbol macro, and probably > represents some place that is both readable and writeable like a > normal variable. > > In either case, you can get its value by evaluating directly > data.some_val, you don't need to store it in some_var. > > Actually, since you've not shown us that you defined the variable > some_var, some strange things may occur in a Common Lisp > implementation when you evaluate this setq out of white at the > toplevel... > > > > > but the following piece of code is not working and i am not sure if i > > am even on the right track. > > > > (setq read_var data.some_val) # read the value > > (print read_var) # say the value was originally set to 5, we would see > > 5 here > > (setq some_var 18) # sets the value to 18 > > (setq data.some_val some_var) # i expect data.some_val to be set to 18 > > now > > (setq read_var data.some_val) # read the value just set > > (print read_var) # i would expect 18 to be displayed. but i still see > > 5. > > > > why would this be? > > It could occur that data.some_val is a symbol macro that expands to an > accessor, and that the writer method for this accessor doesn't write > the value for some reason (perhaps the new value is invalid for this > object?). > > In any case you are not giving us the context, we don't even know what > language you're speaking of! So how can we give you a meaningful answer? > > > wouldn't setf also cause interesting effects?
From: Pascal J. Bourguignon on 6 Nov 2009 23:42 Anti Vigilante <antivigilante(a)pyrabang.com> writes: > wouldn't setf also cause interesting effects? SETF would be more explicit. SETQ must actually work like SETF when given a symbol macro as target. -- __Pascal Bourguignon__
From: Thomas A. Russ on 6 Nov 2009 23:14
vj <harikris(a)gmail.com> writes: > Hi All, > > I have been programming in LISP for couple of months now. > Today, came across a new notation and had a question on that. Um, what "new notation" did you come across? Having a "." as part of a symbol name doesn't mean anything special in lisp. It is similar to having an "_", a "-", or any other character in the name. Are you expecting something different? > Let me give an example: > > I have an access to an "object" [i don't know what the technical term > is for a variable of this data-type]. > > (setq some_var data.some_val) > > by doing the above, i can read the value into some_var. > > but the following piece of code is not working and i am not sure if i > am even on the right track. > > (setq read_var data.some_val) # read the value OK. What happens here is that the value of read_var [more lisp-like would be read-var] is set to the value of data.some_val. This only sets teh value of read_var. It doesn't establish any other link between those variables. I also wonder about your use of the unusual (for lisp) dot notation in the names of your variables. This doesn't really create objects with slots. It just creates ordinary variables that happen to have a "." in their name. > (print read_var) # say the value was originally set to 5, we would see > 5 here Even simpler is to just type "read_var" at the interactive prompt. It will then print the value for you. > (setq some_var 18) # sets the value to 18 > (setq data.some_val some_var) # i expect data.some_val to be set to 18 > now OK. This should set the value as you expect. > (setq read_var data.some_val) # read the value just set OK. > (print read_var) # i would expect 18 to be displayed. but i still see > 5. Well, this seems a bit odd. What lisp system are you using when doing this? # isn't a line comment character in any lisp system that I'm aware of. Can you paste the actual transcript of your session? When I try your example, I get the expected results: CL-USER> (setq data.some_val 5) 5 CL-USER> (setq read_var data.some_val) 5 CL-USER> (print read_var) 5 5 CL-USER> (setq some_var 18) 18 CL-USER> (setq data.some_val some_var) 18 CL-USER> (setq read_var data.some_val) 18 CL-USER> (print read_var) 18 18 -- Thomas A. Russ, USC/Information Sciences Institute |