Proposal #5

[Richard Mlynarik <MLY@AI.AI.MIT.EDU>]

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

    Proposal #5: PARSE-BODY

    Extension:

    Add a new function (PARSE-BODY body environment documentation-allowed-p).

    It pulls apart the body into three parts: a list of DECLARE forms, a
    documentation string (or NIL if none), and the body proper.  These are
    returned in the order body, declarations, and doc-string as three
    values.  PARSE-BODY may perform macro-expansion (using the given
    environment) in order to determine whether an initial macro-call expands
    into a DECLARE form or documentation string.

There could be an &optional before then environment and doc-p args
(environment args are optional everywhere else: ie macroexpand and (proposed) eval.)

I have found it more convenient to return a list of declarations
(ie the "insides" of declare forms) rather than declare forms themselves.
That is, I would have
  (parse-body '((declare (type atom x) (weird y)) (declare (special z y))))
  return a decls value of ((atom x) (weird y) (special z y)).
This makes it easier for the caller to do assoc tests for certain kinds
of relevant declarations.

A sample call to this style of parse-body looks like:
(multiple-value-bind (body decls)
    (parse-body body environment)
  `#'(lambda ,arglist
      (declare ,@decls)
      (return-from ,block-name (progn . ,body))))


What ever happened to the (declare (documentation "foo")) proposal?
(The documentation declaration being equivalent to supplying a doc-string)
KMP (I believe) suggested this a long time ago and a lot of people seemed
to think that it was a good and necessary thing (some going as far as to
implement it)
If there were such a documentation declaration, a doc-string could just
be returned from PARSE-BODY as part of the declarations rather than as a
separate value.  (The doc-string-valid-p arg is still needed, though)