[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Macros -> declarations
- To: Guy Steele <gls%AQUINAS@THINK.ARPA>
- Subject: Macros -> declarations
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Mon, 6 May 85 17:43 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <850506114342.2.GLS@DESIDERIUS.THINK>
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
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
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.