Macros -> declarations

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Wed, 8 May 85 11:53 EDT
    From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>

	Date: Tue, 7 May 1985  22:50 EDT
	From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
	Is there any hope that we can all agree on flushing macro -> declaration
	expansion and replacing it with something like Skef's "declaration
	macro" proposal?  You state that this is the minimum acceptable position
	(minimun acceptable amount of hair, I guess), and for me it's about the
	maximum acceptable position.  It would seem to cover about 99% of the
	cases where people claim that they need the macro expansion.

    Might I suggest another proposal that I think adds less complexity
    for the same gain (for either side of the issue)?

    Instead of DECLARE forms being allowed to be macros, why not allow the
    forms INSIDE declare forms be macros?  Using macros rather than
    "declaration macros" lets you then use macrolet, and avoids the need for
    any new "DEFDECLARE" special forms to document or implement.

No, this is too confusing. What about things like STRING which are already functions?
Do we propose to have macro syntax available in a context where function syntax is not?
I think that would be very confusing. Also, what if someone did

(DEFMACRO TYPE (X) `(PRINT ,X))

and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people
that the possible declaration names (which are all really good names) weren't available
to them for definition as names for macros (but -were- available to them as function
names)... would you?

    This doesn't quite cover the bases, though, unless we also deal with
    expanding into multiple declarations [i.e. (REGISTER X) ->
    (SPECIAL X) (FIXNUM X)].
    I'll propose two ways to deal with that.

Skef's declaration macros covered this case by making them always return a list of
declarations. (This also allows one to conveniently return no declarations, which is
good since if (REGISTER X) didn't want to expand into any declarations it would
otherwise be stuck expanding into NIL implying (DECLARE NIL) which may be ill-formed
for all I know... or (SPECIAL) implying (DECLARE (SPECIAL)) which is semantically silly.)

    1)  Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
    same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))

    2)  Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))).  I.e.
    Allow DECLARE as a declaration containing declarations.

Yuck.

On the other hand, I'm really bothered by the fact that one can write:

(DEFMACRO DECLARE-FOO (&REST X) `(DECLARE (FOO ,@X)))

and use (DECLARE-FOO ...) at toplevel but not inside a DEFUN. I think people
will find this an ugly inconsistency.

I am also bothered by the idea of checking explicitly for DECLARE because
it means that the thing would not really be an operator at all. It would 
essentially be just a part of the syntax of some other form (eg, DEFUN or
LAMBDA) -- yet another odd kind of keyword (like OTHERWISE in SELECTQ).

And when everything is said and done, the only thing we're trying to avoid
is occasionally having to change:

(DEFMACRO DEFFOO (NAME BVL &BODY FORMS)
  `(DEFUN ,(FOOIFY NAME) BVL ,@FORMS))

Oops, no that's not one of the one that has to change. Lemme see. It's gotta
be more complicated than that before any of this matters. Ah yes, I wrote
something like this just the other day:

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS)
  `(DEFMACRO ,NAME ,BVL
     (MAKE-MY-ENCAPSULATION (PROGN ,@FORMS))))

must be rewritten as

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV)
  (MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION)
      (PARSE-BODY FORMS)
    `(DEFMACRO ,NAME ,BVL
       ,@DECLARATIONS ,DOCUMENTATION
       (MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))))

I just don't see this as a big deal.

Since it is so idiomatic, though, how about if &BODY did the declaration
parsing if you gave it a list of vars instead of a symbol var. Eg,

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY DECLS DOC))
  `(DEFMACRO ,NAME ,BVL
     ,@DECLS ,DOC
     (MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))

could be defined to mean the same as what I had just written. Or maybe

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY BODY DECLS DOC)
  ...)

if you thionk the DECLS and DOC look too much like initializations and
present-p checks the other way. This latter syntax means you could have
defaults for these. Eg,

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...))
				       (DECLS '((DECLARE (SPECIAL *FOO*))))
				       (DOC "a macro"))
  ...)

I believe that attacking the problem of DECLARE at the level people have been
attacking it gives up programmer flexibility to no good end (not to mention
introducing an incompatible change to the language semantics). A change
like these syntax extensions to DEFMACRO that I've been speaking about would
make life easy for the macro writer without giving up the macro-writing 
freedoms I was originally supporting.

Thoughts?