Barry Margolin  <barmar@alum.mit.edu> wrote:
+---------------
|  Tamas K Papp <tkpapp@gmail.com> wrote:
| > Thanks Marco.  But I thought symbol-name returned a string,
| > so a string  must be involved somewhere.  ...
| 
| Yes, it returns a string.  But it doesn't have to create a new string to 
| do it.  A symbol is likely to be implemented internally something like:
|   (defstruct symbol name value function plist package)
| and SYMBOL-NAME simply reads what's in the NAME slot.
+---------------

Yup, hence this word of warning from the CLHS:

    Function SYMBOL-NAME
    Syntax:
    symbol-name SYMBOL => NAME
    ...
    SYMBOL-NAME returns the NAME of SYMBOL.
    The consequences are undefined if NAME is ever modified.
    ...

Why is this restiction there? Probably because [in almost every
conceivable Common Lisp implementation] the symbol name is used
as a key in the internal hash table implementing its home package,
and the CLHS has a similar caveat about hash table keys:

    18.1.2 Modifying Hash Table Keys
    ...
    If an object O1 is used as a key in a hash table H and is then
    visibly modified with regard to the equivalence test of H, then
    the consequences are unspecified if O1, or any object O2 equivalent
    to O1 under the equivalence test (either before or after the
    modification), is used as a key in further operations on H.
    The consequences of using O1 as a key are unspecified even if
    O1 is visibly modified and then later modified again in such
    a way as to undo the visible modification.
    ...

So be careful not to modify the result of SYMBOL-NAME or pass it to
any functions that *might* modify it, or "undefined/unspecified
consequences" might ensue.

[Cue Kenny to list some examples of "the consequences are undefined"...]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607