Misfeature: macros expanding into declarations

[Richard Mlynarik <MLY@MIT-MC>]

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

It isn't that hard. It has at least some utility. I did it quite some
time ago when this whole mess originally came up n months ago (and
implemented the DOCUMENTATION declaration at the same time for reasons
which were discussed then).

Let's not rehash things discussed before, which is where the present
discussion seems to be leading.

        Although this "misfeature" makes life much harder on the Lisp
	implementor and the macro writer...
Only the wimpy ones.
[gsb:  I don't actually see how this makes life "much" harder.  The
whole deal of declaration parsing (or separation from the "body") is
enough of a pain, that adding in macroexpansion was fairly trivial.
Of course, NIL has its own set of internal "language tools" which
handle various levels of declaration hacking, but they don't really
amount to all that much.  Obviously what we are lacking in CL are some
additional tools for dealing with declarations, macroexpansion, etc.]

    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.e., *EXPANDING-FOR-DECLARATIONS*.

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
interpreted code.]

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.
[gsb:  NIL uses the environment given to macro functions as a pointer
to more information than just the current set of macro definitions.
For instance, it is used by SETF which keeps separate databases for
runtime and compiletime definitions.  We have a set of utilities for
dealing with this sort of thing trivially, and basically all one has
to do is pass around the macroexpansion-environment to keep the
context straight.]