Number: 1074

Date: 10-May-84 11':42':38

Submitter: vanMelle

Source: vanMelle

Subject: DWIMINMACROSFLG & INFO prop=NOEVAL control whether args to macros are dwimified

Assigned To: vanMelle

Attn: 

Status: Closed

In/By: Harmony

Problem Type: Documentation

Impact: Annoying

Difficulty: Moderate

Frequency: 

Priority: Perhaps

System: Programming Environment

Subsystem: DWIM

Machine: 1132

Disk: 

Lisp Version:  7-May-84 16':18':26

Source Files: 

Microcode Version: 5124

Memory Size: 4096

File Server: 

Server Software Version: 

Disposition: '
["Sannella.PA" "21-Aug-84 18':13':46" Attn': Status':(Fixed->Closed) In/By':]

Description: '
The variable DWIMINMACROSFLG, introduced to "handle" the problem of whether or not dwim should dwimify the arguments to forms whose car is a macro, is rather crude and hence not very useful.  If you have ANY macros for which dwim should not look at the args, then you must set this flag to NIL, even though most of the time you want the flag T (for all those macros which ultimately cause their args to be evaled).'
'
DWIM already has a related mechanism, the INFO property of a function.  Among other things, an INFO property of EVAL on an NLAMBDA function tells dwim that the function really does eval its args.  Propose that this mechanism be slightly extended': an INFO prop of EVAL should override DWIMINMACROSFLG=NIL, and an INFO prop of NOEVAL should override DWIMINMACROSFLG=T.'
'
-----'
'
Date': 21 Jun 84 15':22 PDT'
From': vanMelle.pa'
Subject': DWIMINMACROSFLG update'
To': LispCore^, LispSupport'
'
Not too long ago, Larry added a flag whereby you can control whether or not dwim thinks the arguments to your macros should be recursively dwimified, i.e., whether the macros should be treated as if they were LAMBDA functions.  If DWIMINMACROSFLG is true, the answer is "yes", otherwise "no".  This is a little bit coarse, since it means if you have even one macro whose args are implicitly quoted, you cannot have ANY of your macro arguments dwimified.'
'
Accordingly, I have made a small extension to the INFO prop': if the INFO prop of a macro is or contains the atom NOEVAL, then the arguments to the macro are not dwimified, even if DWIMINMACROSFLG is true.  (The other way around already worked': if the INFO prop is or contains the atom EVAL, then the arguments to the macro are dwimified even if DWIMINMACROSFLG if NIL.)'
'
	Bill '
'
-----'
'
From': kaplan.pa'
Date': 22-Jun-84  9':41':57 PDT'
Subject': Re':  DWIMINMACROSFLG'
To': Vanmelle, Masinter'
cc': Lispcore^'
'
Seems kludgy for the user to have to save the INFO property for some macros and not for others.  Means that if he changes a macro from one kind to the other, he has to go and edit his file coms, etc.'
'
What about flagging the macro definition itself, i.e., allow the proprty to be (NOEVAL . oldformsofmacrodefs).'
'
Dwim would see this, the compiler etc would simply peel it off.'
'
--Ron'
'
-----'
'
Date': 22 Jun 84 09':53 PDT'
From': vanMelle.pa'
Subject': Re':  DWIMINMACROSFLG'
In-reply-to': kaplan.pa''s message of 22-Jun-84  9':41':57 PDT'
To': kaplan.pa'
cc': Lispcore^.pa'
'
No kludgier than doing the same for your NLAMBDA functions that have an INFO prop of EVAL.  It''s not like I invented a new mechanism--the INFO prop has long been used to tell DWIM about forms that it is trying to dwimify.'
'
Changing the form of the macro definition would be backwards incompatible.  Remember, we have published what MACRO properties look like.'
'
	Bill'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 21-Aug-84 18':13':47