GENSYM variables in system "macros", and destructiveness

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

GENSYM variables:  Apparently it has to be re-iterated again about
the danger of using raw gensym variables in automatically-generated 
code, in MacLISP, NIL, or any other lisp system with numeric 
declarations or with global special declarations.

   Many system facilities automatically generate local variables,
sometimes even with numeric declarations.  If your code-writer
(human possibly, but much more likely some automated system) happens 
to chose a symbol of the same pname, you will quite likely come into 
conflict with the scope of the declaration.  This applies to any 
numeric declaration, whether local or global, and to the global 
(SPECIALS T) declaration.  This problem was accurately diagnosed only 
relatively recently by RLB, RWK and myself.

   Slowly but surely, I've been converting automated system
facilities to use some variant of GENTEMP (an as-yet unadvertised
function in the MACAID utility package) -- this involves ** no **
semantic change to any code -- merely the substitution (typically) of
SI:GEN-LOCAL-VAR for GENSYM in certain macros.  These two facilities
ensure that MacLISP (and COMPLR) will treat the variable truly as local, 
even when some other part of the code introduces a variable of the same
pname.  This should reduce the ocasional random coincidences (with
devastating results!) which have sprung up in this realm now and then.  

   The particular tactic taken in GENTEMP is to ensure a variable that
isn't on the obarray.  Another approach has been considered, that of 
providing truly unique names, perhaps incorporating some stamp of 
date-time-location long enough to insure that no two distinct calls 
to the future GENSYM could ever generate the same pname.  Currently, 
that might require pnames of 12 or more characters, so this could
be somewhat of a problem.

Destructiveness:

    Apparently George Carrette not only doesn't understand this
necessity, but has *deleted* numerous files for which I have made 
the appropriate substitution.  It has been my understanding that if 
someone *thinks* he has a better way to solve a problem, he would 
update a file, with a higher version number -- not merely try to 
destroy another person's work.

   GJC's recent suggestion that this problem is only a COMPLR bug 
is sheer and utter nonsense.   User's of his code, including the
MACSYMA-to-lisp translator, may need to be extra-carefully on the
lookout, since he still refuses acknowledge the GENTEMP problem.

   Also his recent note complaining about the msg 
  "WARNING: Function SI:GEN-LOCAL-VAR being illegally defined by file "MC:LIBMAX;MAXMAC"
seen while building a LISPM macsyma displays a total lack of understanding
about what this means -- it is only that the file was compiled in the
macsyma package, but put a macro into the SI package.  It does not signal 
any redefining of a system facility, nor does it cause any bugs or problems 
whatsoever for the running MACSYMA.   Admittedly, it is more in line with 
LISPM protocol to cons up another intermediate name so that the LISPM system 
won't even have to see the name SI:..., and I have just done this for the 
MAXMAC file (indeed any compotent programmer on these mailing lists could 
have done the same).   The rest of his note of 30 August 1981 22:10-EDT  
may be taken as just so much more of the thoughtless flaming for which he 
has become so infamous.