[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.