Why "uninterned" doesn't mean forever, or GENSYMs away!

[Jon L White <JONL at MIT-MC>]

As RWK points out, my note entitled GENLOCAL entirely glossed over 
the problem that symbols may start out life *uninterned* in some lisp 
environment, but when PRINTed out or compiled/faslapped out to a file, 
they then lose their identity except for the pname.  In the two
paragraphs below, I indicate why the GENSYM/GENTEMP problem ought to be 
solved by guaranteeing truly unique pnames (indeed, InterLISP doesn't 
provide for "uninterned" symbols, so they ought to have something like 
this), and  I mention an interesting sloution taken by LISP/370.

The GENTEMP problem arises when code-writing programs are compiled, 
and subsequently loaded back in so that gensym'd variables, 
indistinguishable except by pname, are interned.  The GENTEMP function 
cooperates with faslap to insure identity of a symbol, without intern'ing 
it.  Unfortunately, this doesn't help code-writers which are merely
PRINTed out, and then loaded back in as S-expression -- under such
conditions, all symbols with the same pname will be identified, even
though the original environment may have had hundreds of unique-
but-same-pname'd symbols.  A truly unique gensym name, perhaps one
incorporating a location-date-time component of sufficiently fine
resolution, would solve this.  In fact, the current GENSYM could
continue to be used where conflict of identity doesn't matter,
and the "new, improved" version could be used when one might
anticipate an "identity crisis" such as occurs with program
names and program variables.

LISP/370 had an interesting solution, which I'd like to relate for the 
discussion -- it introduced a new type of data, called say the "gensymbol",
which could be used for function names or variables, but structurally was 
an "immediate" type of data (so no plist in the ordinary sense).  These 
objects printed out with a distinct syntax, something like #G000035, so
that within a given call to READ, each one which printed alike would
be identified, but between calls to READ, they would not be so identified.  
What's even more interesting, when they are read back in, ** they do not 
retain the same pname as occuring in the source file **, even though they 
retain their "identity"!  Thus, two S-expressions as successive calls to
READ, say
   (A #G00235 B #G00235 #G00236)
and 
   (C #G00235 D #G00235 #G00236)
would read in like, say,
   (A #G00001 B #G00001 #G00002)
and 
   (C #G00003 D #G00003 #G00004)