Re: macro/expr property selection by funcall

[Glenn S. Burke <GSB at MIT-ML>]

    Having the funcall mechanism ignore a macro property preceding
some other applicable property is a loss, and will probably cause
bugs and confusion if people try to redefine things.  Crocks like
this should be limited to the compiler, if they are allowed at all;
i believe that it is defined behaviour for complr to use any macro
property, even one preceded on the plist by another functional
property.  I know i have seen this used in the past.  So if you need
to have both of them present, make the macro come last.
    A somewhat nicer alternative would be to have a property used
similarly to the MACRO property, but ONLY used by the compiler.  The
multics lisp compiler has such a beast, but the property name is not
available to the user (wrong obarray).  Then again, an appropriately
constructed OPTIMIZER (ala lispm) could subsume such a function, and
would be more useful in the long run.
    My own solution, which is neither pretty nor easy to use without
support code, has been to use MACROLIST in pdp-10 maclisp, the *MACRO
property on multics (would you believe a load-time-eval to get the
symbol off the right obarray?), and the COMPILER:OPTIMIZERS property
on the lispm.
    As for open coding, if i were doing it by using the ordering of
the macro/expr properties, i would want random interpreted calls to
go through the expr version rather than the macro.  That if nothing
else would determine the order i would put the properties on in.