Possible problems in Compiled Macro files for MACSYMA's Transl

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

I've just compiled your file, which you mention below as causing
troubles (this may be the same problem which JPG found in ADK's
case a couple of weeks ago):
    Date: 26 August 1981 19:55-EDT
    From: "Grant O. Cook, Jr." <GCOOK at MIT-MC>
    I have just uncovered a LISP bug.  The compiler record is
    in GCOOK;JACOBF _UNFA_  where the LISP source is indicated to be
    the translated MACSYMA file GCOOK;JACOBF TRLISP .  It is JACOBIAN_MATRIX
    which is crashing the compiler.
    Having made changes to the names of dummy do-loop indices (to make them 
    unique) when the UMCL compiler failed to work (in the same fashion as 
    indicated in the _UNFA_ file above), and then having it work (but generate 
    code that bombed in MACSYMA: write into read-only memory while in NRECONC),
    it seems that there might be some problem with variable declarations.

Well, I changed the name G0018 to GLOSES0018 and managed to win totally.
After compilation, I noticed that the interned symbol G0018 had a
NUMVAR property indicating that it had been globally declared FIXNUM.
The MACSYMA transl package seems to be picking upon pooor G0018 for
a temporary *non-numeric* variable, and is thus causing the poor COMPLR
to be schrod.

This problem has got to be a manifestation of the compiled macros bug
for which there is a simple solution.  Nowhere in your TRLISP file does
the variable G0018 appear except in JACOBIAN_MATRIX, and it certainly
doesn't do any declarations on it (as I mentioned, changing the name
to something else causes things to win), so some macro package is
managing to snarf this totally random name, and cause it to have
a FIXNUM property (and possibly other properties?).

I sent out a note explaining this problem a couple of weeks ago
as follows:

    Date: 15 August 1981 13:52-EDT
    From: Jon L White <JONL at MIT-MC>
    Subject: LIBDOC;TTY 
    To: GJC at MIT-MC
    cc: BUG-LISP at MIT-MC
	Date: 14 August 1981 17:02-EDT
	From: George J. Carrette <GJC at MIT-MC>
	In a bare lisp, do (LOAD "LIBLSP;TTY"),
	then (DO-WITH-TTY-OFF),
	you get a call to an undefined function: GENTEMP.
    Missing AUTOLOAD property for GENTEMP, which I added to TTY file -- 
    any other "real" usage of TTY would not have been bothered since most
    other files would already have put the AUTOLOAD property.  Probably
    GENTEMP should have an AUTOLOAD property in the initial LISP.
	.  .  . Furthermore, I challange you to prove
	why GENSYM is not sufficient for this case. (Excepting
	the bad practice of using read-time-macroexpansion inside
	macros of course.)
    The availability of local declarations in MacLISP, and of the compiler 
    switch  SPECIALS  which makes all user variables special -- unless properly 
    constructed with SI:GEN-LOCAL-VAR as in the TTY file --  means that system 
    facilites ** must not ** depend upon GENSYM.

    The "cross-talk" of local declarations between 'gensym'd variables used by 
    compiled macros can occur in the TTY file during usages of the  
    DO-WITH-TTY-insomestate  macros which are embedded in other macros usages;
    and also subsequent macros can occur in the code incorporated by the line
	      ,@(CDR X))
    of the DO-WITH-TTY-insomestate macros.  

    The all-specials problem is ever-present

    If you still don't understand why GENSYM is buggy under these conditions, 
    you'd better talk to someone who does before taking matters into your own 
    hands.

Well, GJC apparently didn't listen to the reply to his "challenge"
but instead sent out a vituperative on some irrelevant subpart thereof.
Too bad, since it is probably the failure of some of his code to use 
SI:GEN-LOCAL-VAR (as opposed to GENSYM) which has caused all this problem.