Proposal #5 status

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

    Can somebody PLEASE give me an example of (a) where this is useful and
    (b) where this makes a difference?

In addition to parsing built-in body-taking forms, this would make it
relatively easy for the user to define new macros that take bodies and
declarations, with or without a doc string.  It was pointed out long ago
that every implementation has something like this internally, so we
might as well make it accessible to users.

        1. A documentation string (or NIL if none is present).
    Why isn't the body first.  What if there is more than one doc string?

Things appear in this order in the body (though the doc string and
declarations may be swapped), so people suggested that the returns
follow the "natural" order.  It is an error if more than one doc string
is present (page 67).

        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.

I thought this was clear, at least in context.  You get
((ignore a) (ignore b)), without the DECLARES.

    ??  I assume somebody has convinced themselves that the ordering or
    separation of declares has no semantic meaning in CL?

Yes, unless you have a counter-example.

        4. The macro-expansion for the first form in return value 3, if any.
    Why the macroexpansion of the first form of the body?  Why not the body
    with the first form possibly expanded?

It saves a CONS.

    Why not toss in the kitchen sink?  It looks to me like
    design-by-committee disease is striking.

Why is it always the guy who endlessly nit-picks every last unimportant
detail who accuses others of design by committee?