[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No, it's a bug.
- To: KMP at MIT-MC
- Subject: No, it's a bug.
- From: Alan Bawden <ALAN at MIT-MC>
- Date: Wed, 7 Jan 81 08:12:00 GMT
- Cc: DICK at MIT-MC, BUG-LISP at MIT-MC
- Original-date: 7 January 1981 03:12-EST
Date: 4 January 1981 20:05-EST
From: Kent M. Pitman <KMP at MIT-MC>
Date: Tue, 1 Apr 81 18:27:15 GMT
Original-Date: 01/04/81 14:27:15 EDT
From: DICK at MIT-ML
To: (BUG LISP) at MIT-ML
There is a bug in macroexpand that is seen in the following
scenario ... macroexpand uses a macro even if it is not the current
functional property in force....
This is a widely taken-advantage-of feature, actually. ...
This is not the not-so-widely taken-advantage-of feature that I am
familiar with, look again:
(defun bar macro (body) (cons '1+ (cdr body)))
(defun bar (x) (+ x x))
(macroexpand '(bar 4))
bar is defined as a macro first and THEN redefined to be an expr.
Eval and apply will BOTH find the expr property, the function bar has
been 100% redefined to be (lambda (x) (+ x x)). You may recall that
defun (and defprop) go to a great deal of hair to move properties to
the front of property lists so that such redefinitions work.
Now there is this kludge where apply, mapxxx, funcall, etc. ignore a
macro property in favor of one that can be applied, but that is a
kludge in the language to fix a defficiency (at small expense, since
nothing that otherwise works is effected), and it doesn't imply a
general philosophy that macro properties must ALWAYS represent correct
translations. You HAVE to be able to redefine a macro as an expr
(with a possibly different definition) and have everybody agree on it.
If you wish to make shadowed macro properties mean what you suggest,
then defun had better start doing remprops of macro properties.
This is a real bug in macroexpand, and it should be fixed.