CLHS: Issue SELF-MODIFYING-CODE Writeup

#

## Issue SELF-MODIFYING-CODE Writeup

    Forum:		Public Review
    Issue:		SELF-MODIFYING-CODE
    References:	Moon's public review comment #14 (X3J13/92-3214)
                    Section 3.2.2.1.1 (purpose of compiler macros), p 3-17
                    Section 3.1.2.1.2.2 (macro forms), p 3-7
                    Issue DEFINE-COMPILER-MACRO
                    Issue MACRO-CACHING
    Category:	CLARIFICATION/CHANGE
    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

    Problem description:

      The last sentence of the second paragraph of section 3.2.2.1.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.

    Proposal (SELF-MODIFYING-CODE:FORBID):

      Add to section 3.1.2.1.2.2 a statement that the consequences are
      undefined if a macro function destructively modifies any part of its
      form argument.

    Rationale:

      This would make the specification more complete.

    Current practice:

      Unknown.

    Cost to implementors:

      None.

    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.

    Aesthetics:

      I think everybody agrees that writing self-modifying code is a
      bletcherous practice.

    Editorial impact:

      Trivial.

    Discussion:

      Loosemore says:
       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."

      Moon says:
       I agree with SELF-MODIFYING-CODE:FORBID (Version 1).

       This is consistent with the chucking-out of displacing macros from
       Common Lisp.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.