Loading of DEFMAX

[Carl W. Hoffman <CWH at MIT-MC>]

    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?