[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
That's not a bug, that's a feature!
- To: DICK at MIT-MC
- Subject: That's not a bug, that's a feature!
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Mon, 5 Jan 81 01:05:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 4 January 1981 20:05-EST
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. Consider the case of
an FSUBR definition of LET (for efficiency, stepping convenience, etc)
shadowed by a MACRO definition (for the sake of program-understanding
programs which would like to decompose a macro form into something more
primitive and intelligible). In such a case, the FSUBR definition would want
to shadow the MACRO definition, but both would want to be accessible.
It is also the case that certain files like to do the equivalent of the
(DEFUN FIRST (X) (CAR X)) ; In case FIRST gets MAP'd or APPLY'd
(DEFUN FIRST MACRO (X) ; For compiler use
(DISPLACE X `(CAR ,@(CDR X))))
where both a macro and an expr version are available at the same time and get
used in different situations. Here the MACRO shadows the EXPR, but both are
accessible at times.
Moral: If you're going to have more than one definition on your functions,
make them compatible.