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
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__
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__
> 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
Aha! Interesting difference in idioms here: in the U.S. one would say
"out of the blue" instead of "white".
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
> +---------------
> | 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...
> +---------------
>
> Aha! Interesting difference in idioms here: in the U.S. one would say
> "out of the blue" instead of "white".
Well, not being a native speaker, I must have misremembered the idiom.
So: s/white/the blue/
--
__Pascal Bourguignon__
Naw -- Europe's cloudier than the US; white skies rather than blue
skies.
> Naw -- Europe's cloudier than the US; white skies rather than blue
> skies.
Surely even grass is greener in the US, am I right?
--
Adam Michalik
vel Dodek Dodecki
<dodek[]dodecki.net>
Your comments were useful and made me dig further. Turns out that lisp
was running on top of a plugin. So, data.some_val would actually
execute a method [data here] in the plugin and return the value for
the variable of name some_val.
As Pascal rightly expected, the some_val was only "readable" and not
"writeable" (for lack of a corresponding method in the plugin
implementation).
hagw.
On Nov 7, 8:33 pm, Adam Michalik <dode...@gmail.com> wrote:
Actually, looking at Wiktionary[1] it would seem that in most European
countries the analogous idiom to the English "out of the blue" has
more to do with "clear sky" rather than "the blue" [albeit clear skies
*are* typically blue], and *not* "white" [though see (Russia#2) below]:
- From clear sky (Germany)
- Like a lightning bolt out of a clear sky (Finland, Sweden)
- Like a thunder {from,in} {the,a} clear sky (Bosnia, Serbia,
Croatia, Lithuania, Russia#1, Iceland#1)
Some more... indirect phrases were also given as alternates:
- Like snow onto the head (Russia#2)
- Like the devil from the sheep's leg (Iceland#2)
Alternatives in English include "out of nowhere" and "[a] bolt from
the blue", the latter being *quite* similar to the Finnish/Swedish,
since "bolt" here means a lightening bolt.
But I'm sorry, Pascal. I couldn't find one that was uniquely French...
-Rob
[1] http://en.wiktionary.org/wiki/out_of_the_blue
I guess the corresponding expression would be "un �clair en plein jour",
which is quite rareley used. (Google finds 13 occurences, of which
only 3 have the English idiom meaning, the others being literal
meaning).
--
__Pascal Bourguignon__
Add Bulgaria to this list.
As a sidenote, there is (at least in Bulgarian) an expression that
literally means "see stars in the middle of a white day", which
refers to the "stars" one "sees" after a strike on the head, but
that is a rather special case of surprise.
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
>"webmasterATflymagnetic.com" <webm...@flymagnetic.com> writes:
>
>> Naw -- Europe's cloudier than the US; white skies rather than blue
>> skies.
>
>Surely even grass is greener in the US, am I right?
You mean browner - the US being the source of global warming and
whatnot.
My sister (who speaks *much* better French than I!) says that the
Harper/Collins/Robert dictionary lists "coup de tonnerre" -- literally
"a clap of thunder" or "thunderclap", but figuratively meaning
"bombshell", "bolt from the blue", or "thunderbolt". Does that
sound appropriate here?
[A friend of hers also suggested "sans crier gare" -- "without any
warning or unexpectedly" -- but I'm not sure that's quite the same.]
-Rob
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
> +---------------
> | rp...@rpw3.org (Rob Warnock) writes:
> | > But I'm sorry, Pascal. I couldn't find one that was uniquely French...
> |
> | I guess the corresponding expression would be "un �clair en plein jour",
> | which is quite rareley used.
> +---------------
>
> My sister (who speaks *much* better French than I!) says that the
> Harper/Collins/Robert dictionary lists "coup de tonnerre" -- literally
> "a clap of thunder" or "thunderclap", but figuratively meaning
> "bombshell", "bolt from the blue", or "thunderbolt". Does that
> sound appropriate here?
>
> [A friend of hers also suggested "sans crier gare" -- "without any
> warning or unexpectedly" -- but I'm not sure that's quite the same.]
Yes, "sans crier gare" would mean the same.
On the other hand, I'm not sure about "coup de tonnerre", since it's
usually preceded by the flash...
--
__Pascal Bourguignon__
http://www.informatimago.com
In Italian we have "fulmine a ciel sereno", which is essentially the
same as the Finnish and Swedish expression above. It's normally used for
things that are totally surprising and unexpected, so it has a
"stronger" meaning than the English idiom...
Alberto
Ah, the things I learn in c.l.l that bring a smile to my face.