Number: 1168

Date: 21-May-84 16':09':29

Submitter: Sannella.PA

Source: Masinter.pa

Subject: New function': EVALHOOK

Assigned To: 

Attn: 

Status: Closed

In/By: Harmony

Problem Type: Documentation

Impact: Annoying

Difficulty: Moderate

Frequency: Everytime

Priority: Perhaps

System: Language Support

Subsystem: Stack and Interpreter

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Sannella" "20-Aug-84 19':10':46" Status':(Fixed->Closed) In/By':]

Description: '
Date':  8 May 84 17':19 PDT'
From': Masinter.pa'
Subject': EVALHOOK'
To': LispDiscussion↑'
cc': Masinter.pa'
'
I was gonna fix a bug in the Interlisp-D EVALHOOK package and wound up building it into the standard interpreter. Here''s the documentation as it shows up in the manual sources. Does this roughly correspond to the Interlisp-VAX version? Does the Jericho have this feature?'
'
'
{FnDef {FnName EVALHOOK} {FnArgs FORM EVALHOOKFN}}'
{Text'
{fn EVALHOOK} evaluates the expression {arg FORM} in a special way. While evaluating {arg FORM}, {fn EVAL} behaves in a special way. The argument {arg EVALHOOKFN} should be a function of one argument. The first time a list is to be evaluated (except for {arg FORM} itself), whether implicitly or via an explicit call to {fn EVAL}, no attempt is made to evaluate the form. Instead, {arg EVALHOOKFN} is invoked, and passed the form to be evaluated as its argument. {arg EVALHOOKFN} is then responsible for evaluating the form; whatever is returned is assumed to be the result of evaluating the form. (Note': {fn EVALHOOK} is not implemented in Interlisp-10.)'
'
Here is an example of a simple tracing routine that uses the {fn EVALHOOK} feature':'
'
{lispcode'
'
←(DEFINEQ (PRINTHOOK (FORM) '
	(printout T "eval': " FORM T) '
	(EVALHOOK FORM (FUNCTION PRINTHOOK]'
(PRINTHOOK)'
}'
Using {lisp PRINTHOOK}, one might see the following interaction':'
'
{lispcode'
'
←(EVALHOOK ''(LIST (CONS 1 2) (CONS 3 4)) ''PRINTHOOK)'
eval': (CONS 1 2)'
eval': (CONS 3 4)'
((1 . 2) (3 . 4))'
}}'
'
     ----- Next Message -----'
'
Date':  8 May 84 21':41 PDT'
From': JonL.pa'
Subject': Re': EVALHOOK'
In-reply-to': Masinter.pa''s message of 8 May 84 17':19 PDT'
To': Masinter.pa'
cc': LispDiscussion↑.pa'
'
This implementation is lacking half of the Common Lisp part -- the use of EVALHOOK as a variable.  As a function, it is merely shorthand for a trivial 3-line usage of the variable, as described in the various manuals of the Common Lisp dialects (MacLisp manual, ZetaLisp manual, Common Lisp manual).  A summary of them would read  "The first arg to EVALHOOK is evaluated with (the variable) EVALHOOK lambda-bound to the second arg, which should be a function of two arguments (just like EVAL is)"'
'
I realize the difficulties of implementing something that would require a SPECVAR lookup on each call to EVAL, but note the incompatibility of the Interlisp-D version -- no lambda-binding of a variable which the client can inspect or modify.  Would any of the Common Lisp clients of EVALHOOK work when translated to Interlisp?'
'
Has anyone in fact tried to transliterate any of the so-called STEPper packages from the CommonLisp world?  These are essentially '
a "single-step" debugging facility for interpretive code.  The original motivation for EVALHOOK in the MacLisp world was just that -- to provide the absolutely minimal change in the interpreter so that users could write these "stepper" packages.  I don''t know of any serious usage of EVALHOOK other than the several "steppers", and the Common Lisp Manual, Page 268, seems to imply that it is provided just for the STEP facility (page 363).'
'
Minor incompatibility of Common Lisp with MacLisp and Lisp Machine Lisp -- the variable "EVALHOOK" was renamed to "*EVALHOOK*" to abide by the convention that globalvars are wrapped in *''s.  But this causes at most a minor hiccup when moving from MacLisp/LML into CL.'
'
     ----- Next Message -----'
'
From': masinter.pa'
Date':  9-May-84  3':05':16 PDT'
Subject': Re': EVALHOOK'
In-reply-to': JonL''s message of 8 May 84 21':41 PDT'
To': JonL'
cc': Masinter, LispDiscussion↑'
'
JonL,'
'
Yes, I chose to include the easy-to-implement subset of the commonLisp definition, rather than the whole banana.'
'
This facility is used by (and sufficient for) the TRACEIN stepper package produced by Don Cohen (DonC@ISI). '
'
TRACEIN is on <LispUsers>. Don (and Lipkis) verified that the EVALHOOK library package was adequate for TRACEIN. All I did was take the library package, import it into the system, document it in the manual, and test it out.'
'
I thought that a subset was better than nothing if it was known to be useful.'
'
You may also note that CommonLisp says that EVALHOOK hits on ALL expressions evaluated (including atoms), while at least in Interlisp-D it only is triggered on LISTP forms. '
'
It made little difference for Tracein, and adding that feature would have had a lot more impact on the code (and possibly performance of the interpreter.)'
'
Generally, I don''t like adding features and calling them ''CommonLisp'' unless they are really the same. '
'
(you may want to refer to ARs 776 and 777 for more background on this one.)'
'
     ----- Next Message -----'
'
Date':  9 May 84 03':34 PDT'
From': JonL.pa'
Subject': Re': EVALHOOK'
In-reply-to': masinter.pa''s message of 9-May-84  3':05':16 PDT'
To': masinter.pa'
cc': JonL.pa, LispDiscussion↑.pa'
'
Uh, I take it then that this is just the EVALHOOK mentioned on Page 7 of the Interlisp/VAX  Users Manual?'
'
     ----- Next Message -----'
'
Return-Path': JGIBBONS@BBNG.ARPA'
Redistributed': LispDiscussion↑.pa'
Received': from BBNG.ARPA by Xerox.ARPA ; 09 MAY 84 11':56':59 PDT'
Date': 9 May 84 14':56 EDT'
Sender': JGIBBONS@BBNG.ARPA'
Subject': Re': EVALHOOK'
From': Jeff Gibbons <JGibbons@BBNA.ARPA>'
To': Masinter.pa'
Cc': LispDiscussion↑.pa'
Cc': JGibbons@BBNG.ARPA'
Message-ID': <[BBNG] 9-May-84 14':56':22.JGIBBONS>'
In-Reply-To': The message of 8 May 84 17':19 PDT from Masinter.pa@XEROX.ARPA'
'
Larry, Interlisp-Jericho does not currently implement the EVALHOOK'
feature and probably will not unless a pressing need presents itself.'
'
jeff'
'
     ----- Next Message -----'
'
Date':  9 May 84 12':24':59 PDT (Wednesday)'
From': masinter.PA'
Subject': Re': EVALHOOK'
In-reply-to': JonL''s message of 9 May 84 03':34 PDT'
To': JonL'
cc': masinter, LispDiscussion↑'
'
More or less. I started with DDyer''s implementation....'
'
The difference is that the VAX hits EVALHOOK on litatoms.'
'
'
     ----- Next Message -----'
'
Return-Path': DDYER@USC-ISIB'
Redistributed': LispDiscussion↑.PA'
Received': from USC-ISIB (USC-ISIB.ARPA) by Xerox.ARPA ; 10 MAY 84 12':33':53 PDT'
Date': 10 May 84 11':39':24 PDT'
Subject': Re': EVALHOOK'
From': Dave Dyer <DDYER@USC-ISIB.ARPA>'
To': masinter.PA, JonL.PA'
cc': LispDiscussion↑.PA'
In-Reply-To': (Message from "masinter.PA@XEROX" of 9 May 84 12':24':59 PDT (Wednesday))'
'
'
 On the vax, EVALHOOK doesn''t affect the "real" eval at all, except '
for a NIL test on the global variable EVALHOOK.  If EVALHOOK is not NIL,'
EVAL applies EVALHOOK. (period).  The function EVALHOOK is a complete'
duplicate of the skeleton of EVAL, which does the first step of'
evaluation and then "continues" into the rea eval.'
'
 This way, arbitrarily fancy evalhook features have strictly limited'
impact on the cost of ordinary eval.'
'
 The GLOBAL vs. SPECIAL problem is more serious.  The vax uses a globalvar,'
which doesn''t hurt because there is normally no multiprocessing.  I can'
see that on the dolphin this might cause problems.  It has been'
suggested that the global cell act as a flag that there might be a binding,'
and EVAL would run the lookup only if the global cell was set.'
'
-------'


Workaround: 

Test Case: 

Edit-By: Sannella

Edit-Date: 20-Aug-84 19':10':47