Forum: Public Review
References: Moon's public review comment #14 (X3J13/92-3214)
Section 18.104.22.168.1 (purpose of compiler macros), p 3-17
Section 22.214.171.124.2.2 (macro forms), p 3-7
Edit history: 21 Dec 1992, Version 1 by Loosemore
08 Jan 1993, Version 2 by Loosemore (comment from Moon)
Status: Proposal FORBID accepted 7-2-0, March 1993
The last sentence of the second paragraph of section 126.96.36.199.1 on page
3-17 says compiler-macro expanders aren't allowed to modify the source
code. Is there a similar restriction on normal macro expanders? I
expect that there would be, but I couldn't find it.
Add to section 188.8.131.52.2.2 a statement that the consequences are
undefined if a macro function destructively modifies any part of its
This would make the specification more complete.
Cost to implementors:
Cost to users:
Conceivably this proposal might cause some existing conforming programs
to become non-conforming, but we don't know of any such programs.
I think everybody agrees that writing self-modifying code is a
The DEFINE-COMPILER-MACRO proposal included the explicit prohibition
against modification of the form argument because of the way a
compiler macro function must return the original form to indicate it
declines to expand it. Ordinary macros don't have to deal with this
problem, but it's generally accepted that self-modifying macros are
bad for other reasons. The problem description section of issue
MACRO-CACHING, for example, touches upon this problem: "Caching by
displacement won't work because the same (EQ) macro call form may
appear in distinct lexical contexts. In addition, the macro call form
may be a read-only constant."
I agree with SELF-MODIFYING-CODE:FORBID (Version 1).
This is consistent with the chucking-out of displacing macros from