Hi,
Excuse the simplicity of this question, but I am a noob and lost. I
have;
(defvar key nil)
(defvar name nil)
(setq key "foo")
(setq name "bar")
and I want to get to
(list :foo "bar")
But I don't seem to be able to quote : or key in such a way that I
could do this. For example I have tried (please don't laugh);
(eval (format t "(list :~a ~S)" key name))
and
(defvar f1 nil)
(setq f1 (format t "(list :~a ~S)" key name))
(eval f1)
and
`(list ,(format t ":~a" key) ,name)
And those are just the things that came closest, there were about 50
failed experiments before getting that far.
Any and all help appreciated.
Ian
iant wrote:
> Hi,
>
> Excuse the simplicity of this question, but I am a noob and lost. I
> have;
> (defvar key nil)
> (defvar name nil)
> (setq key "foo")
> (setq name "bar")
>
> and I want to get to
> (list :foo "bar")
>
> But I don't seem to be able to quote : or key in such a way that I
> could do this. For example I have tried (please don't laugh);
>
> (eval (format t "(list :~a ~S)" key name))
To get the :foo you can do:
(intern "FOO" :keyword)
If you do (intern "foo" :keyword) you'll get :|foo|
The bars mean the symbol name really is lowercase, loosely speaking.
btw, I am thinking classic Lisp, if you have a case sensitive Lisp, uh,
I am not sure what happens. :) (intern "foo" :keyword) might give you
:foo but just note that it would be diff than :FOO. Again, I am just
guessing at the behavior of case-sensitive lisps.
As for the eval approach, once you have built up the string you could
use (read-from-string <the string>):
(read-from-string "(list :foo \"bar\")")
That will give you (LIST :FOO "bar") in classic lisp, which would be the
same as (list :foo "bar).
It is not clear how much you needed converted from string to lisp
symbols, but if you just need the list you could:
(list (intern key :keyword) name)
In general you can create a symbol using (intern string [package]),
where if you omit the package it defaults to the current package (which
can be determined by looking at the special variable *package*. The
keyword package is a little unique in that interned symbols are printed
and accessed with the leading colon, tho the symbol name (in your case)
would still be "FOO".
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Hi,
I wish I read your reply before replying to Rainer.
> To get the :foo you can do:
>
> (intern "FOO" :keyword)
>
> If you do (intern "foo" :keyword) you'll get :|foo|
OK, now I can proceed with;
(setq key "FOO")
(intern key :keyword)
Thanks.
>
> The bars mean the symbol name really is lowercase, loosely speaking.
Kind of like "\f\o\o"?
>
> btw, I am thinking classic Lisp, if you have a case sensitive Lisp, uh,
> I am not sure what happens. :) (intern "foo" :keyword) might give you
> :foo but just note that it would be diff than :FOO. Again, I am just
> guessing at the behavior of case-sensitive lisps.
No, I'm using clisp, which converts everything to uppercase (unless
you force it do otherwise such as above).
>
> As for the eval approach, once you have built up the string you could
> use (read-from-string <the string>):
>
> (read-from-string "(list :foo \"bar\")")
>
> That will give you (LIST :FOO "bar") in classic lisp, which would be the
> same as (list :foo "bar).
>
> It is not clear how much you needed converted from string to lisp
> symbols, but if you just need the list you could:
>
> (list (intern key :keyword) name)
That's what I will do, once I have converted KEY to uppercase.
Thanks again.
Ian
iant wrote:
> Hi,
>
> I wish I read your reply before replying to Rainer.
>
>
>>To get the :foo you can do:
>>
>> (intern "FOO" :keyword)
>>
>>If you do (intern "foo" :keyword) you'll get :|foo|
>
>
> OK, now I can proceed with;
>
> (setq key "FOO")
> (intern key :keyword)
>
> Thanks.
>
>
>>The bars mean the symbol name really is lowercase, loosely speaking.
>
>
> Kind of like "\f\o\o"?
No, that might be necessary in some computer language unknown to me, but
the ones I know will give you lowercase if you type lowercase between
double-quotes.
I am not a language lawyer, but the bars are used by printer and reader
both to convey non-uppercase symbol names. In your case you are coming
from a string so you have to convert to uppercase or simply arrange for
your input always to be uppercase if you have control over it (but why
gamble). On the other hand, if you just want the symbol '|camelCase|,
that is how you can get it, no need to type (intern "camelCase"). And as
you learned, with (intern "foo") the symbol created has "foo" (not
"FOO") as the symbol name and the printer conveys this by adding the
bars when printing that symbol back to you.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Hi,
Ken Tilton <···········@optonline.net> writes:
> iant wrote:
>>>The bars mean the symbol name really is lowercase, loosely speaking.
>>
>>
>> Kind of like "\f\o\o"?
>
> No, that might be necessary in some computer language unknown to me,
> but the ones I know will give you lowercase if you type lowercase
> between double-quotes.
It actually does what he said. \ are single-character quotes while the
| quotes until the next |. See this:
[5]> '|foo(bar baz|
|foo(bar baz|
[6]> '\f\o\o\(\b\a\r\ \b\a\z
|foo(bar baz|
Everything between the bars is part of the symbol and the whole thing is
read as one token afaiu. The single characters are read literally.
Hannes
Johannes Weiner wrote:
> Hi,
>
> Ken Tilton <···········@optonline.net> writes:
>
>
>>iant wrote:
>>
>>>>The bars mean the symbol name really is lowercase, loosely speaking.
>>>
>>>
>>>Kind of like "\f\o\o"?
>>
>>No, that might be necessary in some computer language unknown to me,
>>but the ones I know will give you lowercase if you type lowercase
>>between double-quotes.
>
>
> It actually does what he said.
You mean it actually makes the characters come out lowercase whereas if
he did not have the backslashes in there they would come out uppercase?
kenny
\ are single-character quotes while the
> | quotes until the next |. See this:
>
> [5]> '|foo(bar baz|
> |foo(bar baz|
> [6]> '\f\o\o\(\b\a\r\ \b\a\z
> |foo(bar baz|
>
> Everything between the bars is part of the symbol and the whole thing is
> read as one token afaiu. The single characters are read literally.
>
> Hannes
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Hi,
Ken Tilton <···········@optonline.net> writes:
> You mean it actually makes the characters come out lowercase whereas
> if he did not have the backslashes in there they would come out
> uppercase?
Yes:
>>>>>The bars mean the symbol name really is lowercase, loosely speaking.
>>>>
>>>>
>>>>Kind of like "\f\o\o"?
Hannes
In article
<····································@e10g2000prf.googlegroups.com>,
iant <··········@iankthompson.org> wrote:
> Hi,
>
> Excuse the simplicity of this question, but I am a noob and lost. I
> have;
> (defvar key nil)
> (defvar name nil)
> (setq key "foo")
> (setq name "bar")
>
> and I want to get to
> (list :foo "bar")
>
> But I don't seem to be able to quote : or key in such a way that I
> could do this. For example I have tried (please don't laugh);
>
> (eval (format t "(list :~a ~S)" key name))
>
> and
>
> (defvar f1 nil)
> (setq f1 (format t "(list :~a ~S)" key name))
> (eval f1)
>
> and
>
> `(list ,(format t ":~a" key) ,name)
>
> And those are just the things that came closest, there were about 50
> failed experiments before getting that far.
>
> Any and all help appreciated.
>
> Ian
Usually symbol names are uppercase by default.
? (intern "FOO" "KEYWORD")
:FOO
Thanks for replying.
>
> > Excuse the simplicity of this question, but I am a noob and lost. I
> > have;
> > (defvar key nil)
> > (defvar name nil)
> > (setq key "foo")
> > (setq name "bar")
>
> > and I want to get to
> > (list :foo "bar")
>
> > But I don't seem to be able to quote : or key in such a way that I
> > could do this. For example I have tried (please don't laugh);
>
> > (eval (format t "(list :~a ~S)" key name))
>
> > and
>
> > (defvar f1 nil)
> > (setq f1 (format t "(list :~a ~S)" key name))
> > (eval f1)
>
> > and
>
> > `(list ,(format t ":~a" key) ,name)
>
>
> Usually symbol names are uppercase by default.
>
> ? (intern "FOO" "KEYWORD")
> :FOO
I tried;
(INTERN KEY "KEYWORD")
and get;
:|foo|
:EXTERNAL
I don't want the |bars| around foo, because then this doesn't work.
(defvar *test* (list (intern KEY "KEYWORD") name))
(getf *test* :foo)
But this does;
(getf *test* :|foo|)
Is there some way I can quote the value of KEY so that I don't get the
bars in the property name?
Thanks again,
Ian
On Feb 23, 8:58 am, iant <··········@iankthompson.org> wrote:
> Thanks for replying.
>
>
>
>
>
> > > Excuse the simplicity of this question, but I am a noob and lost. I
> > > have;
> > > (defvar key nil)
> > > (defvar name nil)
> > > (setq key "foo")
> > > (setq name "bar")
>
> > > and I want to get to
> > > (list :foo "bar")
>
> > > But I don't seem to be able to quote : or key in such a way that I
> > > could do this. For example I have tried (please don't laugh);
>
> > > (eval (format t "(list :~a ~S)" key name))
>
> > > and
>
> > > (defvar f1 nil)
> > > (setq f1 (format t "(list :~a ~S)" key name))
> > > (eval f1)
>
> > > and
>
> > > `(list ,(format t ":~a" key) ,name)
>
> > Usually symbol names are uppercase by default.
>
> > ? (intern "FOO" "KEYWORD")
> > :FOO
>
> I tried;
> (INTERN KEY "KEYWORD")
> and get;
> :|foo|
> :EXTERNAL
>
> I don't want the |bars| around foo, because then this doesn't work.
> (defvar *test* (list (intern KEY "KEYWORD") name))
> (getf *test* :foo)
>
> But this does;
> (getf *test* :|foo|)
>
> Is there some way I can quote the value of KEY so that I don't get the
> bars in the property name?
>
> Thanks again,
>
> Ian
See the function STRING-UPCASE .
? (string-upcase "foo")
"FOO"
iant <··········@iankthompson.org> writes:
> I am a noob and lost. I have ... (defvar key nil)
I saw answers go by to your question, so I'll take a moment to make a
different remark, one you're not asking about.
It is recommended that, absent some strong compelling reason (not in
evidence), you always use global variables that have *...* around
their names. The *'s are just alphabetic characters, but this
different naming is commonly used and helpful for reasons I'll
explain.
Doing what you have done here will make programs like:
(defun foo (key) (lambda () key))
(funcall (foo 3))
"mysteriously" fail, returning NIL instead of 3. (I put mysteriously in
quotes because the failure is not mysterious, but does nevertheless confuse
newbies.)
Doing DEFVAR tells the system that ALL future uses of that name in that
package are NOT to be treated lexically. Experience shows that this
almost always leads to an unpleasant surprise later unless you help yourself
remember, which is why the *...*'s are suggested, as in:
(defvar *key* nil)
because then later when you do
(defun foo (key) (lambda () key))
it will work lexically or when you do:
(defun foo (*key*) (lambda () *key*))
someone can say "you know, special binding key and then returning a closure
will not capture the special binding."
On Feb 24, 1:49 am, Kent M Pitman <······@nhplace.com> wrote:
Hi,
> It is recommended that, absent some strong compelling reason (not in
> evidence), you always use global variables that have *...* around
> their names. The *'s are just alphabetic characters, but this
> different naming is commonly used and helpful for reasons I'll
> explain.
Is this because there are no variables with local scope?
>
> because then later when you do
>
> (defun foo (key) (lambda () key))
>
> it will work lexically or when you do:
>
> (defun foo (*key*) (lambda () *key*))
>
> someone can say "you know, special binding key and then returning a closure
> will not capture the special binding."
OK, thanks for the advanced warning.
If you have a minute, I have another problem :)
I have a line that comes very close to doing what I need it to, but
not quite.
(setq *fval* (eval `(,(intern (string-upcase (getf
type :function))))))
The 'eval' works perfectly, extracting the name of function from
'type' and executing (evaluating) it. Unfortunately, that is exactly
what it does, it does not 'return' then output of the evaluated
function to be stored in '*fval*'.
I know that there is something other than 'eval' I should be using
here, but I don't know what it is. I have tried 'lambda' functions and
funcall without much success.
As always, any and all help appreciated.
Ian
iant <··········@iankthompson.org> wrote:
+---------------
| Kent M Pitman <······@nhplace.com> wrote:
| > It is recommended that, absent some strong compelling reason (not in
| > evidence), you always use global variables that have *...* around
| > their names. The *'s are just alphabetic characters, but this
| > different naming is commonly used and helpful for reasons I'll
| > explain.
|
| Is this because there are no variables with local scope?
+---------------
[I assume by "local scope" here you really mean "lexical scope"...]
No, there are certainly variables with lexical scope, but in
standard CL there are no global variables with lexical scope.[1]
Said another way, the global environment contains only variables
with dynamic scope (with the exception noted in [1]), and if you
rebind one with LET or LAMBDA you will give it a new *dynamic*
binding, which is not "local", and thus have effects you might not
expect if coming from languages with global lexical variables, e.g.:
> (defparameter foo 13)
FOO
> (defun foo () foo)
FOO
> (defun bar () 27)
BAR
> (let ((foo 54)
(bar 91))
(list foo (foo) bar (bar)))
(54 54 91 27)
>
For this reason the Lisp community style [a *very* strong convention!]
is to use the *FOO* form for global (dynamic) variables so you won't
accidentally rebind one dynamically when you were intending to just
create a fresh lexical binding.
-Rob
[1] You can fake up global lexical variables by using symbol
macros -- Google for DEFLEX, DEFLEXICAL, or DEFGLOBAL.
Such "variables" are reliably shadowed by lexical rebindings,
so there's no reason to use the *...* convention in their case.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
iant <··········@iankthompson.org> writes:
> (eval (format t "(list :~a ~S)" key name))
Other people have set you right concerning intern and string-upcase.
I just wanted to point out a possible additional source of confusion.
It looks like you want format to return a string. It's perfectly
capable of that, but what you're doing above will make format print
its string to standard output, instead of returning it for further
processing. If you want format to return its string instead of
printing it, use (format nil ...) instead of (format t ...).
Even if you had gotten that part to work, the eval would probably not
have done what you wanted. Evaluating a string will just yield the
same string. You were possibly looking for the function
read-from-string here, which would have returned the s-expression
(list :foo "bar"), as you stated you wanted.
That expression could in turn have been sent to eval to be evaluated
as a lisp program, and _that_ evaluation would have yielded the list
(:foo "bar"). In general - avoid eval unless you are writing a
program to run other lisp programs.
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
Hi Peder,
>
> That expression could in turn have been sent to eval to be evaluated
> as a lisp program, and _that_ evaluation would have yielded the list
> (:foo "bar"). In general - avoid eval unless you are writing a
> program to run other lisp programs.
>
I have got it to work with eval, but I will Google for "read-from-
string" for future use. One of the atoms in my LIST contains a
(arbitary) function name as a string, that I needed the evaluator to
evaluate (execute?). The return value from the function would be a
used as a new value (atom) for another list. Phew ... that was a lot
harder to describe that it was for me to conceptualize.
Anyway, the line:
(setq *fval* (eval `(,(intern (string-upcase (getf
type :function))))))
Was eventually replaced by:
(push (eval `(,(intern (string-upcase (getf type :function)))))
*item*)
because I didn't really need *fval*, I just wanted to see what was
going on. As you correctly suggested, the FORMAT in the evaluated
function was sending the format output to stream T, so I changed it to
NIL and all was well.
So now I am off to learn about mapping CARS and CADS, or is it CONS?
No doubt I will return to this newsgroup with more silly questions. I
thank you all for your patience so far.
Regards,
ian
iant <··········@iankthompson.org> writes:
> but I will Google for "read-from-string" for future use.
No need to google. Definitive references for Common Lisp are
available online. See for example
<http://www.lispworks.com/documentation/HyperSpec/Front/index.htm>.
It has several nice indices. You will find read-from-string (and all
other Common Lisp functions) in the symbol index.
> One of the atoms in my LIST contains a (arbitary) function name as a
> string, that I needed the evaluator to evaluate (execute?).
Are you absolutely sure? Eval can (and should) usually be avoided
(except when it should be used). Eval will lose the lexical
environment of the call site, will run your code interpreted (or force
a compilation at runtime), will prevent your compiler from doing some
optimizations, and may be a security risk (depending on the source and
trustworthyness of its input).
> Anyway, the line:
> (setq *fval* (eval `(,(intern (string-upcase (getf
> type :function))))))
>
> Was eventually replaced by:
> (push (eval `(,(intern (string-upcase (getf type :function)))))
> *item*)
In both of these, the eval is unneccessary. I would use
(funcall (intern (string-upcase (getf type :function))))
Look, ma! No eval.
> As you correctly suggested, the FORMAT in the evaluated function was
> sending the format output to stream T, so I changed it to NIL and
> all was well.
Except, as others pointed out, it was probably the wrong solution to
your problem.
> So now I am off to learn about mapping CARS and CADS, or is it CONS?
A CONS is a data structure made up of a CAR and a CDR.
> No doubt I will return to this newsgroup with more silly questions. I
> thank you all for your patience so far.
You really should pick up a decent introductory text. For instance Practical
Common Lisp by Peter Seibel <http://www.gigamonkeys.com/book/>
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.