That's not a bug, that's a feature!

[Kent M. Pitman <KMP at MIT-MC>]

From:     Date:
Date: Tue, 1 Apr 81 18:27:15 GMT
Original-Date: 01/04/81 14:27:15 EDT
Subject:
    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 
following:

(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.

-kmp