Macros -> declarations

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Monday, 6 May 1985, 11:43-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    I would be not at all unhappy if this feature were to go away.
    I agree that Scott's assessment that it is unlikely that any
    existing code (outside of diagnostic tests for this very feature)
    would be harmed.

I have no opinion one way or the other about whether the feature of macros
expanding into DECLARE forms should be retained or flushed.  Maybe we'll
hear from KMP what he had in mind when he suggested it, back in 1982 or
thereabouts, before we make a decision.

I would like to point out, though, that anyone claiming that no one uses
the feature is on very thin ice.  A hell of a lot of copies of Common
Lisp: The Language have been sold.  I have heard of more than one
implementation existing "off in left field".  My experience has been
that users will often use features that you wouldn't have expected them
to use, or even discover, and then will get mad when you remove the
feature.  The worst case of this, of course, is when the user thought it
was a feature and the implementor thought it was a bug.

    I am persuaded not at all by the argument that it is hard to implement.
    I am mildly swayed by the efficiency considerations for the interpreter.

I found it easy enough to implement an interpreter that handles these efficiently.
It pre-processes certain special forms the first time it encounters them.  No
big deal.

    The convincing point to me, however, is that the facility is likely
    to confuse macro-writers (who do, indeed, frequently find it necessary
    to find the division point between declarations/documentation and body).

    As a proposal separate from the question of eliminating the expansion
    of macros into declarations, I suggest the following primitive
    for consideration:

    PARSE-BODY list

    The list is treated as a body (a list of forms) that may have declarations
    and a documentation string at its head.

    Three values are returned.  The first is some tail of the list,
    the executable part of the body.  The second value is a list
    of declarations (lists whose car is DECLARE) at the head of the body.
    The third value is the documentation string, or NIL if there was
    no documentation string.

This is a good suggestion.  We already have this, but haven't documented it
pending standardization or other reasons why we might want to change it.  Our
implementation of this raises some points:

 - It needs to take a lexical environment argument so it can expand macros
   so it can look for declarations.

 - It needs to take an argument that tells it whether documentation strings
   are allowed in this kind of body.

 - It's convenient for the caller if PARSE-BODY peels off the DECLARE's and
   simply returns a one-level list of declarations.  The caller can cons
   DECLARE back onto the front of this list if desired.

 - For our system's applications, we found it convenient to split the
   declarations into four kinds returned as separate lists.  I don't
   know that it would make sense to standardize this in Common Lisp,
   though.  The four kinds were SPECIAL declarations, type declarations,
   declarations that need to be saved until run time for the Debugger
   (not a portable concept), and all others.