[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Possible problems in Compiled Macro files for MACSYMA's Transl
- To: GCOOK at MIT-MC, JPG at MIT-MC
- Subject: Possible problems in Compiled Macro files for MACSYMA's Transl
- From: Jon L White <JONL at MIT-MC>
- Date: Thu, 27 Aug 81 02:24:00 GMT
- Cc: MACSYMA-I at MIT-MC, BUG-LISP at MIT-MC
- Original-date: 26 August 1981 22:24-EDT
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
Date: 15 August 1981 13:52-EDT
From: Jon L White <JONL at MIT-MC>
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"),
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
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
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.