&BODY

[yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA]

    Date: Mon, 21 Jul 1986  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   common-lisp@SU-AI.ARPA
    Subject: Some easy ones (?)
    Message-ID: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
    
    Proposal #6: Parsing in &BODY
    
    Change (could conceivably break existing code which destructures &body
    arguments, but this should be rare as such destructuring is generally
    too complex to do via the built in mmechanism):
    
    Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
    &body (body-var [declarations-var [doc-string-var]]).  If only body-var
    appears in parentheses, it means the same as a body-var with no
    parentheses.  Otherwise, it means to give the original body to
    PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
    specified) and then bind the variables to the corresponding values
    returned by PARSE-BODY.  This is purely a syntactic convenience for the
    user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
    call PARSE-BODY himself.
    
    Note: This extension is proposed only for &BODY, not for &REST, so &BODY
    will no longer be exactly equivalent to &REST in a DEFMACRO arglist.
    
This is confusing.  CLtL (page 146) says that

	Anywhere in the lambda-list where a parameter name may appear ...,
	a lambda-list may appear in place of the parameter name.

Thus, the following is a valid DEFMACRO form.

	(DEFMACRO FOO (&REST (X Y Z)) ...)

which is equivalent to

	(DEFMACRO FOO (X Y Z) ...)

But a similar DEFMACRO form

	(DEFMACRO BAR (&BODY (X Y Z)) ...)

is regarded as

	(DEFMACRO BAR (&BODY X) ...)

if doc-strings and declarations are ignored.  Thus KMP's suggestion below
is less confusing.

    [Note: KMP has suggested the syntax (...&body body-var decl-var doc-var).
    This does not break any existing code and would allow default and
    supplied-p values for the three variables.  I (sef) don't think these are
    important advantages, and I prefer the syntax proposed above, which is
    less confusing to the eye -- my eye, ayway.  The proposed format is the
    one we discussed on the mailing list earlier and seemed to be favored by
    most people.]