Proposal #6 Status: Parsing in &BODY

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

    Date: Sun, 27 Jul 1986  21:01 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


    Nobody seems to oppose this.  One or two people have questioned its
    usefulness, but the discussion we had on this a year or so ago
    demonstrated considerable demand for this as an alternative to making
    users handle environment objects directly.

    Most people who commented on this prefer KMP's proposed syntax, though
    there seems to be little enthusiasm for the inclusion of default and
    supplied-p values.  (Speaking for myself, I'm happy to go along with
    this if we don't get into default/supplied-p complexities.)  So, we have
    a revised proposal:
    ---------------------------------------------------------------------------
    Proposal #6A: Parsing in &BODY

    Extension:

    Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
    (DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]]) ...)

    If DECLARATIONS-VAR is present, it means to give the original body to
    PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
    present) 
This will break existing code.  One can no longer write
	(defmacro defun (name bvl &body body) ...)
because doc-string-var is not supplied and therefore PARSE-BODY, given
the direction people want to be taking it, will err because
documentation-allowed-p will be false.
	     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.
Sorry for the broken record: A body is a body is a body is a body...  A
body has declarations and a doc string.

    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.