Proposal #5 status

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Here is the first of the status reports on pending proposals.  This is
culled from a lot of old mail; my apologies in advance if I missed some
key suggestion.  I suggest that we use this as the starting point for
further discussion of this issue (and similarly with the others) and
that we try to converge on a final set of proposals for the technical
committee fairly soon.  All of these summaries are from me as moderator;
where I have seen fit in inject one of my personal opinions on some
technical matter, that is marked.

-- Scott
---------------------------------------------------------------------------

There seems to be no opposition to the idea of PARSE-BODY per se.  There
have been numerous suggestions about the exact form of the arguments and
return values, and I have incorporated most of these suggestions into
revised proposal 5A below: making the environment and doc-p arguments
optional, reordering the returns into what some consider a more natural
order, and returning the declarations as a combined list of
decl-specs (as the book calls them), without the surrounding DECLAREs.

One suggestion by Nick Gall is to add a declaration-allowed-p form.  If
this is NIL, then PARSE-BODY has the task of ensuring that the body does
NOT contain declarations.  Some people have responded that this
functionality does not belong in PARSE-BODY.  (Speaking as SEF, I agree
with this view.  Nick is free to pursue this further if he wants to,
but I suspect that the idea is not going anywhere.)

One complex issue is whether the body should be returned in its original
form or with any macro-expansion that was computed while looking for
initial decls replacing the original body forms.  (There will only be
one of these, since the first non-declaration stops the expansion.)  One
would like to avoid doing the work of expansion a second time, but
sometimes it is necessary to get at the original body.  In 5A below, I
propose a solution that may get get the best of both worlds: the body is
returned in original form, but there are two additional return values,
one indicating the availability of a macro-expansion for the first body
form, and the other being that expansion.  (Two extra values are
necessary because the macro might perversely expand into NIL after doing
a lot of work.)
---------------------------------------------------------------------------
Proposal #5A: PARSE-BODY

Extension:

Add a new function:
(PARSE-BODY body &optional environment documentation-allowed-p)

The default for environment is NIL, meaning to use a null lexical
environment.  The default for documentation-allowed-p is NIL, meaning
that this form is NOT allowed to have a documentation string.

PARSE-BODY extracts the documentation string and declarations from BODY,
expanding initial macros as necessary to determine if they contain
declarations.  It returns five values:

1. A documentation string (or NIL if none is present).
2. A combined list of declaration specs, extracted from all 
   DECLARE forms found at the start of the body, whether present in the
   body itself or obtained via macro-expansion.
3. The remainder of the BODY argument, following any initial
   doc-strings, declarations, or forms that expand into declarations.
4. The macro-expansion for the first form in return value 3, if any.
5. T if return 4 is a valid macro-expansion for the first form
   in return 3, NIL otherwise.