[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Loading of DEFMAX
- To: BUG-LISP at MIT-MC
- Subject: Loading of DEFMAX
- From: Carl W. Hoffman <CWH at MIT-MC>
- Date: Sun, 30 Dec 79 01:12:00 GMT
- Cc: JPG at MIT-MC
- Original-date: 29 December 1979 20:12-EST
Date: 27 DEC 1979 0436-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
Why does L^K (LOAD '|MACSYM;GRAMI FASL|) cause the DEFMAX
stuff to be loaded in? [Ignore the error message about MDISPATCH
which occurs afterwards.] After all this is a FASL file! The
previous version of MACSYM;GRAMI FASL (which I can retrieve from tape
if such is desired) did not require the loading in of the DEFMAX stuff
while creating a new version of MACSYMA.
This happens not only with MRG;GRAM, but with any file containing a
DEFMACRO, even if the DEFMACRO-FOR-COMPILING switch is turned off, which is
clearly wrong. The DEFMACRO-DISPLACE-CALL switch should not be the one to
control whether the FORGET-MACROMEMOS form is present in the fasl file. The
DEFMACRO-FOR-COMPILING switch should control this. If the macro is not
present in the fasl file, then there is no need to communicate any
information about it to the memoizer, so the FORGET-MACROMEMOS form
shouldn't be present. Likewise, if the macro is present in the fasl file,
the FORGET-MACROMEMOS form should be there, regardless of the setting of
DEFMACRO-DISPLACE-CALL at compile time.
Date: 27 DEC 1979 1158-EST
From: JONL at MIT-MC (Jon L White)
I've edited the one line necessary into MRG;GRAM >, and will leave it to you
to redo the splitting and rebuilding of MACSYMA. the needed line is
(declare (setq defmacro-displace-call () )).
Did you really make this change? MRG;GRAM > was last updated by JPG. In
any case, I put the form in LIBMAX;PRELUD >, which is the correct place for
it. This way it will affect all Macsyma files which use DEFMACRO.
In case you are still wondering, if you use DEFMACRO with intention
of using any of the MACROMEMO features at runtime, then you need the
runtime support package (which is only about 333. words); the default
is to have DEFMACRO-DISPLACE-CALL non-null, but you clearly don't want
to be bothered with that for the two little macros MATCH and TELL.
Why don't you code FORGET-MACROMEMOS as a small subr which looks to see if
MACROMEMOS is non-NIL before loading the macromemo package. Alternately,
the macromemo displacer could keep track of the macro properties of symbols
and check to see if they've changed. In any case, I suspect that
the MACROEXPANDED scheme is used most of the time and the macromemo package
shouldn't be loaded whenever DEFMACRO is used.
Incidentally, why is the DEFMACRO-DISPLACE-CALL switch needed at all?
Isn't the same thing accomplished by setting MACRO-EXPANSION-USE to NIL?