Comments on DCP's revised &BODY proposal

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

I mostly like this variation of the &BODY proposal.

I would prefer the name &DOCUMENTATION. 

In fact, given that we have &ENV instead of &ENVIRONMENT, it might be more 
consistent to have a short names like &DOC and &DECLS. I'm won't champion
that very strongly, but I think it's worth pointing out both for the sake
of consistency and the sake of reducing indentation. By using &DOCUMENTATION
and &DECLARATIONS you're virtually assuring that things like:
(DEFUN SOMETHING (NAME BVL &DECLARATIONS DECLS &DOCUMENTATION DOC &BODY FORMS)
 ...)
will be pushing the right margin on an 80-column screen even given reasonably
concice choices of macro and variable names.

In the presence of displacing macros, I feel fairly strongly that we can't 
currently guarantee that the &BODY will contain unexpanded forms. My feeling
is that we should either guarantee that the expanded (rather than unexpanded)
form be returned if an expansion happened, or that we should be explicitly
vague. It would be very unwise to document something we couldn't reliably 
provide.

With regard to your aside about &KEY, I agree that &KEY and &BODY should be
exclusive. Alternatively, though, we could revise the description of &KEY to
do something useful. It comes up in the current error proposal that there
are a lot of forms with bodies that have leading keywords. ie,
   (name bvl :key1 :value1 :key2 :value2 ... . body)
The body is defined to start when the keyword pairs run out. Right now, these
have to be "manually" parsed. It would be amazingly convenient to be able to 
say
   (NAME BVL &KEY KEY1 KEY2 &BODY FORMS)
I'd be content for now to just leave this syntax undefined and let people
think about a proposal on this subject later, but my desire to have this 
work makes this it seem very desirable to at least just disallow the current
meaning to a coupled &BODY/&KEY configuration for the interim.