Hello you happy lispers,
I tried to find a way to check wether a symbol is produced by (gensym) or
something else, and came with this :
;;; builds a tagged gensymed symbol
(defun my-gensym ()
(make-symbol
(concatenate 'string ·@" (string (gensym)))))
;;; test
(defun my-gensym-p (some-sym)
(eq (car (coerce (symbol-name some-sym) 'list)) ···@))
Is this reasonable ? Is there something more straightforward ?
Is it possible to make a distinction between what (gensym) returns and
anything else (other than checking for a '#\G at its beginning, which
doesn't seem like a good idea...) ?
Thank you for your patience.
Aur�lien.
"Aur�lien Camp�as" <···········@wanadoo.fr> writes:
> Hello you happy lispers,
>
> I tried to find a way to check wether a symbol is produced by (gensym) or
> something else, and came with this :
>
> [snip]
>
> Is this reasonable ? Is there something more straightforward ?
Checking the symbol to see if it's interned or not would identify a
superset of symbols produced by GENSYM--but it may be good enough...
(defun interned-p (symbol)
(and (symbol-package symbol) t))
[17]> (interned-p 'foo)
T
[18]> (interned-p (gensym))
NIL
[19]> (interned-p (make-symbol "foo"))
NIL
Gabe Garza
In article <······························@wanadoo.fr>,
Aur�lien Camp�as <···········@wanadoo.fr> wrote:
>Hello you happy lispers,
>
>I tried to find a way to check wether a symbol is produced by (gensym) or
>something else, and came with this :
>
>;;; builds a tagged gensymed symbol
>(defun my-gensym ()
> (make-symbol
> (concatenate 'string ·@" (string (gensym)))))
>
>;;; test
>(defun my-gensym-p (some-sym)
> (eq (car (coerce (symbol-name some-sym) 'list)) ···@))
>
>Is this reasonable ? Is there something more straightforward ?
Coercing to a list seems like a strange thing to do just to get the first
character. More straightforward would be:
(char= (aref (symbol-name some-sym) 0) ··@)
>Is it possible to make a distinction between what (gensym) returns and
>anything else (other than checking for a '#\G at its beginning, which
>doesn't seem like a good idea...) ?
No. All symbols smell alike.
What is it about gensyms that you need to distinguish? Maybe what you
really should be looking for are uninterned symbols. In most applications,
uninterned symbols are pretty rare except for gensyms. Actually, gensyms
in general are pretty rare except in macro expansions.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"Aur�lien Camp�as" <···········@wanadoo.fr> writes:
> ;;; builds a tagged gensymed symbol
> (defun my-gensym ()
If you're going to use a wrapper like that, you could make it
put a property on the symbol.
(defun my-gensym ()
(let ((symbol (gensym)))
(setf (get symbol 'my-gensym) t)
symbol))
(defun my-gensym-p (object)
(and (symbolp object)
(get object 'my-gensym)))
Thank you for your quick and enlightening answers :-)
Symbol properties appear to be the easy way.
Aur�lien.
ps : is there some paper out there that explains the rationale for symbol
properties (how they did come to existence, what they are good for, how a
good lisper would use them...) ?
Aur�lien Camp�as <···········@wanadoo.fr> wrote in message news:<············@news-reader10.wanadoo.fr>...
> Thank you for your quick and enlightening answers :-)
> Symbol properties appear to be the easy way.
>
> Aur�lien.
>
> ps : is there some paper out there that explains the rationale for symbol
> properties (how they did come to existence, what they are good for, how a
> good lisper would use them...) ?
The rationale is that a symbol is used for symbolizing. And
symbolizing takes place in some context, and there can be many more
contexts that then language designer can foresee. So the properties of
a symbol ought to be extensible, so that users can invent their own
contexts, and hook symbols into those contexts.
Out of the box, so to speak, you can independently use symbols to name
functions and variables. So you have two contexts of meaning right
there. You can have a function MYPACKAGE::X and a special variable
MYPACKAGE::X. But what if you want to write a logic programming
system, and you want to define a rule of inference called
MYPACKAGE::X? Or maybe a music composition system, in which you want
to define a composition called MYPACKAGE::X. Suddenly, that symbol has
four independent contexts in which it has different meanings that are
unrelated to each other.
In article <············@news-reader10.wanadoo.fr>,
Aur�lien Camp�as <···········@wanadoo.fr> wrote:
>ps : is there some paper out there that explains the rationale for symbol
>properties (how they did come to existence, what they are good for, how a
>good lisper would use them...) ?
Once upon a time Lisp didn't have hash tables or strings as built-in types.
So the common way to associate data with a name was to put it in the
property list of a symbol. Symbols in Maclisp didn't even have function
slots; the function or macro definitions of a name were in the EXPR or
MACRO property (there was also FEXPR for special functions that didn't have
their arguments evaluated).
These days symbol properties are much less useful, because we have other
data types and structures that serve these purposes; they've been retained
for compatibility. A good Lisper can probably spend their entire career
*never* using them.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.