[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GENSYM variables in system "macros", and destructiveness
- To: MACSYMA-I at MIT-MC, BUG-LISP at MIT-MC, NIL at MIT-MC
- Subject: GENSYM variables in system "macros", and destructiveness
- From: Jon L White <JONL at MIT-MC>
- Date: Tue, 1 Sep 81 21:27:00 GMT
- Original-date: 1 September 1981 17:27-EDT
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.
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.