[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No. Don't let macros expand into prog tags.
- To: Guy.Steele at CMU-10A
- Subject: No. Don't let macros expand into prog tags.
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Wed, 27 Oct 1982 08:35:00 -0000
- Cc: COMMON-LISP at SU-AI
No. Macros shouldn't be able to expand to prog tags. An example hopefully
suffices:
(defmacro do-something-returning-*foo* (&rest ignore) ;dummy definition
; just return *foo* for now until we figure out how to implement the something
'*foo*)
(defun huh? ()
(prog ()
(do-something-returning-*foo*) ;supposedly for side-effect
...))
this PROG should not be able to be said to have a *FOO* tag. There are probably
many macros that expand into symbols and macro writers should not have to take
the odd context of a prog body expansion into account.
note that this is not contradictory with the idea of letting macros expand
into declare forms because we allow macros to expand only into declare forms
or normal code, but never a mixture. so it's in the semantics of the macro
already that it will be used in a declare position or it won't. macro writers
will not be "surprised" by the context `declare-macros' expand in. the user
will know he has such a macro and will use it right.
this could be better worded but i'm tired. i hope what i'm saying is
sufficiently obvious that clarification won't be needed.
-kmp
ps macros expanding into prog tags would also thwart people who wanted to
implement interpreted go by just doing memq in the relevant prog bodies.