[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: macro/expr property selection by funcall
- To: Multics-Lisp-People at MIT-MC
- Subject: Re: macro/expr property selection by funcall
- From: Glenn S. Burke <GSB at MIT-ML>
- Date: Tue ,19 Aug 80 22:39:00 EDT
- Cc: LISP-FORUM 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.