[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Misfeature: macros expanding into declarations
- To: MLY@MIT-MC
- Subject: Misfeature: macros expanding into declarations
- From: Richard Mark Soley <SOLEY@MIT-MC>
- Date: Sun, 5 May 85 21:44:43 EST
- Cc: common-lisp@SU-AI
- In-reply-to: Msg of Sun 5 May 85 21:37:38 EST from Richard Mlynarik <MLY>
Date: Sun, 5 May 85 21:37:38 EST
From: Richard Mlynarik <MLY>
To: SOLEY, common-lisp at SU-AI
Re: Misfeature: macros expanding into declarations
[with additional comments by gsb@mc]
Date: Sun, 5 May 85 20:42:51 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Date: Sat, 4 May 85 18:26:24 EST
From: Tim McNerney <TIM>
Date: Sat, 4 May 1985 07:36 EDT
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return.
Although this "misfeature" makes life much harder on the Lisp
implementor and the macro writer...
Only the wimpy ones.
I agree, and I don't care to heavily support wimpy implementors
(wimplementors?). My point is that we SHOULD support wimpy macro writers.
Anyway, at LEAST if we're going to continue to have this feature,
there must be some flag that is set when we're doing "early"
macro expansion so that the macro writer can tell how to expand,
I don't understand exactly what this means at all.
If the macro expands into "(declare ...)" then it is "exanding for
declarations" as far as I can tell.
[gsb: i don't understand the point of this either, particularly. I
can see a potential for lossage when there is pre-parsing and thus
macroexpansion performed at definition time rather than at runtime in
Exactly. The point is, there are macros that don't want to be
expanded at interpreter-load (eval) time [i.e., when the DEFUN is
loaded], but only when the defun is compiled. REGARDLESS of the
fact that no DECLARE is returned.
What -is- useful for a macro to know is whether it is being expanded
by the compiler or the interpreter or for some other random purpose
(mainly in order to make use of different error-reporting techniques,
particularly those of the compiler) This information is part of the
environment passed to the macroexpansion function and has been in NIL
and the LMIT Lispm software for some time.
Exactly what I was proposing. But this sucker would have to be