Macros -> declarations

[Robert W. Kerns <RWK@SCRC-YUKON.ARPA>]

    Date: Fri, 10 May 85 01:51 EDT
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

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

	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. 

It certainly would be confusing to define a declaration named STRING,
since there's already a function of that name.  In our system, you'd
get redefinition warnings.  Why not call it STRING-DECL?  How is this
any more confusing than any other naming conflict?

					  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?

No, of course not.  I see no reason why DECLARE should macroexpand things
it already understands.  To do so would be to allow gratiutous confusion,
such as this.

	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.

Hey, remember that this is the expanded output of a macro, not
something that you write in your code.  I think the macro definition
ends up looking pretty obvious, and besides, the compiler is likely
to give you a useful error message if you put one of these macros
in an inappropriate place.

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

I don't, either, since you need that, regardless of whether
or not macros can expand into DECLARE's.  However, thinking
of humans, I have to say that I don't like macros expanding
into entire DECLARE forms because it gets in the way of my
adding my own declaration, and because *I* might not recognize
something as a declaration.  I'm not too worried about it
being "too hard" for programs to handle.

I believe that DECLARE is already structural, rather than
an operator, and that allowing macros to expand into it
merely confuses that issue.

The other reason I proposed making them macros is so that
MACROLET could be used.  Most of the uses I can think of
would be to allow declarations inside of calls to macros,
where MACROLET would be just the right thing to define
any declarations.

    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))))

This (and its varients I omit for brevity) is a very interesting
suggestion, and is worth of discussion independently of of the
declaration/macro issue.