Macros -> declarations

[Tim McNerney <TIM@MIT-MC>]

    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.

IFF we have to flush macros -> declarations, I think Kerns' user-extensible
DECLARE is the most palatable suggestion so far.  Unfortunately, there are a
number of problems with allowing macros inside of DECLARE, and indeed with
nearly any user-extensible DECLARE.

Perhaps the biggest problem is that the namespace available for use as
declaration names has already been "given away."  The sort naming conflict
that KMP bought up could be solved by having a declarations package which
does not use the LISP package, but CL implementations are free to use any
names not explicitly mentioned in CLTL for implementation-dependent
declarations.  Thus, allowing macros inside of DECLARE could potentially
reduce the portability of code that used this proposed feature.

Whereas

  (declare-private-specials) -> (declare (special *foo* *bar*))

would pose no problems with portability, 

  (declare (private-specials)) -> (declare (special *foo* *bar*))

might conflict with an existing PRIVATE-SPECIALS declaration specific to a
given target implementation (unless the user is allowed to override
implementation-dependent declaration names with his own, yuk!).

I vote for keeping macros -> declarations and augmenting the language 
with a set a standard tools for keeping hairy macro writers out of trouble.