Number: 1213

Date: 23-May-84 17':14':43

Submitter: Sannella.PA


Subject: DWIM inconsistent with forms where CAR is macro and expressions have CLISP, e.g. (FOO 1 + 3)

Assigned To: 

Attn: Masinter

Status: Open


Problem Type: Bug

Impact: Moderate

Difficulty: Moderate

Frequency: Everytime

Priority: Perhaps

System: Programming Environment

Subsystem: DWIM



Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: [turned this into a more useful AR]'
["masinter.PA" "14-Sep-84 09':16':54" Subject':]

Description: '
DWIM behaves inconsistently when confronted with a MACRO where there is CLISP in the body. For example, if you define a macro (PUTPROPS FOO MACRO ((X Y) (LIST Y X))'
and you call it with (FOO X + 1 Y), it will *not* change X + 1 to (ADD1 X) before expanding the FOO macro, *unless* you explicity DWIMIFY the function, in which case it WILL.'
The problem is that some users have macros which are ''nlambda''s, and others just don''t use CLISP. CLISPIFY also may create some of these, which is also probably a no-no.'
I don''t have an excellent design that I like; I did put in a DWIMINMACROSFLG, initially NIL, which if non-NIL I think should mean that at interpret time to call DWIMIFY before calling the macro to expand.'
Date': 11 Apr 84 18':51':29 PST (Wednesday)'
From': masinter.PA'
Subject': some random ARs'
Problem type':design-impl'
Subject':fix macroexpansion not to use DWIM'
Description': There is no reason that the feature of Interlisp-D '
expanding macros at interpret time has to be done via DWIM. And it is '
embarrassing. And it is easy to fix. I think it might even solve some of'
the problems that the current DWIM-based interpreter has. There is still'
a question about DWIMINMACROSFLG, i.e., whether DWIMify gets called on '
the macro body before the macro is expanded, because otherwise CLISPIFY '
has to be taken out of the standard system'


Test Case: 

Edit-By: masinter.PA

Edit-Date: 14-Sep-84 09':16':56