Misfeature: macros expanding into declarations

[Richard Mark Soley <SOLEY@MIT-MC>]

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

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
well documented.

	-- Richard