Number: 1470

Date: 19-Jun-84 17':04':20

Submitter: Sannella.PA

Source: MMODEL@BBNG.ARPA

Subject: Provide user interface to forcing redwimification of expressions

Lisp Version: 

Description: Return-Path': <MMODEL@BBNG.ARPA>'
Received': from BBNG.ARPA by Xerox.ARPA ; 08 JUN 84 16':07':06 PDT'
Date': 8 Jun 84 19':05 EDT'
Sender': MMODEL@BBNG.ARPA'
Subject': CLISP'
From': MMODEL@BBNG.ARPA'
To': LispSupport.PA'
Cc': Greenfeld@BBNG.ARPA'
Message-ID': <[BBNG.ARPA] 8-Jun-84 19':05':28.MMODEL>'
'
A user here had a problem that surprised me -- I need some help'
too.  He had defined a CLISPWORD and a translation function.'
Then, he tested the translation on a function whose body was'
simply an expression beginning with that clisp word.  He didn''t'
like the result, so he changed the translation function.  Of'
course, when he ran the function again, it didn''t redwimify - I'
suggested he turn on PPRETRANFLG, but this didn''t help!'
Apparently the interpreter checks for an entry in the CLISP'
translation array before even evaling an expression; thus DWIM is'
never invoked and PPRETRANFLG has no effect.'
'
Main question':'
'
How do you force redwimification of expressions?'
'
'
Similar question':'
'
the CLISP word he was defining could be typed in at top level.'
However, a later FIX retrieves the translation (of course), not'
the original form.  Is there a straightforward way to have FIX'
retrieve original type-in or do I have to write a'
LISPXHISTORYMACRO that first undoes the dwimification (is this'
ALWAYS side effect 1?) then calls FIX?  [Or is there no'
straightforward way but a better unstraightforward way?]'
'
'
These are simple questions; I can''t really understand why I'
couldn''t help.'
'
        --- Mitchell'
'
-----'
'
Date':  8 Jun 84 16':31 PDT'
From': JonL.pa'
Subject': Re': CLISP'
In-reply-to': MMODEL@BBNG.ARPA''s message of 8 Jun 84 19':05 EDT'
To': MMODEL@BBNG'
cc': LispSupport.PA, Greenfeld@BBNG'
'
I''m not sure about all the CLISP questions (especially the FIX one), but you know that translations, as well as macroexpansions, are cached in CLISPARRAY; it doesn''t hurt to do (CLRHASH CLISPARRAY) once in a while.  [actually, it may "hurt" if you have re-declared some system datatypes like ARRAYP etc, and have cached forms, and ... oh well, you get the idea; it''s almost always safe except for when hacking system code.]'
'
One note':  be prepared for a humongous garbage collection the first time or three after the (CLRHASH CLISPARRAY).'
'
-- JonL --'
'
-----'
'
Date': 10 JUN 84 21':05 PDT'
From': MASINTER.PA'
Subject': CLEARCLISPARRAY'
To':   JonL'
cc':   LispSupport, MModel@bbng, Greenfeld@bbng'
'
there is a function CLEARCLISPARRAY(name type reason) that''s used by the file package for erasing CLISPARRAY entries for "name". If you change a macro, the file package will call (CLEARCLISPARRAY macroname ''MACROS --). In this users case, however, it looked like his ''clispword'' was ''displacing'' rather than CLISPTRANing the translation.'
'
I suggest that the guy use a macro instead, and that we make that same suggestion in the manual -- don''t tell users how to define their own clisp words at all.'
'
(It is my intention when I get around to it to make most of the CLISPWORDs be macros instead.)'
'


Workaround: 

Test Case: 

Edit-By: masinter.PA

Edit-Date: 13-Jul-84 18':44':46

Attn: Documentation

Assigned To: 

In/By: 

Disposition: 

System: Programming Environment

Subsystem: DWIM

Machine: 

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: Moderate

Frequency: Everytime

Impact: Minor

Priority: Perhaps

Status: Open

Problem Type: Documentation

Source Files: