Best Practices for (INTERN ...)?
in [Lisp]
|
Prev: Young girls showing off their bodies on personal webcams
Next: ☆☉☉☆ Barely Legal Babes - Free downloads! Videos Images, Barely Legal young teens
From: Patrick Stein on 24 Apr 2010 09:51 Occasionally, I want to (INTERN ...) some data strings and see if there is already a (SYMBOL-FUNCTION ...) binding for it or some such. Every time I do something like this, I worry that someone might have messed with the Lisp reader at some point (even temporarily) so I should be looking for '|foo| or '|Foo| or '|FoO| instead of '|FOO|. Is there a good or canonical way to deal with this? Is (INTERN (STRING-UPCASE my-string)) what I should really be doing? Or, should I loop through all symbols doing caseless compares? And, if the latter, then I just shot symbols in the foot... Thanks, Patrick
From: Frode V. Fjeld on 24 Apr 2010 11:47 Patrick Stein <pat(a)nklein.com> writes: > Occasionally, I want to (INTERN ...) some data strings and see if > there is already a (SYMBOL-FUNCTION ...) binding for it or some such. Use FIND-SYMBOL to query wheter a symbol with a particular name exists in some package. Unlike INTERN, FIND-SYMBOL will return NIL if the symbol doesn't already exist. -- Frode V. Fjeld
From: Pascal J. Bourguignon on 24 Apr 2010 14:28 Patrick Stein <pat(a)nklein.com> writes: > Occasionally, I want to (INTERN ...) some data strings and see if > there is already a (SYMBOL-FUNCTION ...) binding for it or some such. > > Every time I do something like this, I worry that someone might have > messed with the Lisp reader at some point (even temporarily) so I > should be looking for '|foo| or '|Foo| or '|FoO| instead of '|FOO|. > > Is there a good or canonical way to deal with this? Is (INTERN > (STRING-UPCASE my-string)) what I should really be doing? Or, should I > loop through all symbols doing caseless compares? And, if the latter, > then I just shot symbols in the foot... You need to know what you're worrying about, then you will be able to choose one way or another to get your symbols: INTERN will take the string as is for the symbol name. (WITH-STANDARD-IO-SYNTAX (read-from-string "Symbol-Name")) --> SYMBOL-NAME ;; will use the standard syntax. (read-from-string "Symbol-Name") --> SYMBOL-NAME ; or |Symbol-Name| or ; |symbol-name| ;; will use the current syntax. But read-from-string may also read a number, since a lot of symbols are potential numbers in higher bases: (read-from-string "Hello") --> 6873049 ; with *read-base* bound to 25. -- __Pascal Bourguignon__
From: Thomas A. Russ on 26 Apr 2010 11:55
Patrick Stein <pat(a)nklein.com> writes: > Occasionally, I want to (INTERN ...) some data strings and see if > there is already a (SYMBOL-FUNCTION ...) binding for it or some such. > > Every time I do something like this, I worry that someone might have > messed with the Lisp reader at some point (even temporarily) so I > should be looking for '|foo| or '|Foo| or '|FoO| instead of '|FOO|. I suppose that if you wanted to be really careful, you could look for all combinations. There really are only three choices for the string. Either as is, upcased or downcased. > Is there a good or canonical way to deal with this? Is (INTERN > (STRING-UPCASE my-string)) what I should really be doing? Or, should I > loop through all symbols doing caseless compares? And, if the latter, > then I just shot symbols in the foot... What would be nice would be to have a standard function that will take a string and transform it according to the current read settings. But unfortunately, there isn't one of those. Now, one knows that somewhere each implementation has something that does that, since it is needed at some stage of the reader process, but it isn't exposed to outside users. Has anyone written a utility function like that? READ-FROM-STRING seems to be the common hack, but it does have the disadvantage that it will intern a symbol if it doesn't already exist. So a separate function that handles just the string conversion part would be nice so that one could choose between INTERN or FIND-SYMBOL. -- Thomas A. Russ, USC/Information Sciences Institute |