178 lines
9.4 KiB
HTML
178 lines
9.4 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue EVALHOOK-STEP-CONFUSION Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss148_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss149_m.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss151_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss148_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss149_m.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss151_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue EVALHOOK-STEP-CONFUSION Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Cleanup<P>
|
|
<B>Issue:</B> <A HREF="iss149_m.htm">EVALHOOK-STEP-CONFUSION</A><P>
|
|
<B>References:</B> CLtL p 321, 323, 441<P>
|
|
Issue <A HREF="iss325.htm">STEP-ENVIRONMENT</A> (passed)<P>
|
|
Issue APPLYHOOK-ENVIRONMENT (passed)<P>
|
|
<B>Category:</B> CHANGE/CLARIFICATION<P>
|
|
<B>Edit History:</B> V1, 9 Oct 1989, Sandra Loosemore<P>
|
|
V2, 2 Nov 1989, Sandra Loosemore (update discussion)<P>
|
|
V3, 4 Dec 1990, Pitman (amendment per X3J13)<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Common Lisp permits the evaluator to be implemented by compiling the<P>
|
|
form before executing it, but notes that this techniques "renders the<P>
|
|
EVALHOOK mechanism relatively useless" (CLtL p. 321).<P>
|
|
<P>
|
|
CLtL also requires the <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> utility to be implemented in terms of<P>
|
|
EVALHOOK (p. 323). The restriction against implementing <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> using<P>
|
|
some other technique (such as annotations on code lexically within the<P>
|
|
body of the <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A>) that make more sense in a compiled-only<P>
|
|
implementation is pointless. It is probably not even desirable for<P>
|
|
<A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> to be implemented with *EVALHOOK*, since this effectively causes<P>
|
|
the stepper to break on user programs that also use *EVALHOOK*.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal (EVALHOOK-STEP-CONFUSION:X3J13-NOV-89):<P>
|
|
</B><P>
|
|
(a) Remove the requirement that <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> be implemented using *EVALHOOK*.<P>
|
|
Make it explicitly vague whether the scope of the code that is affected<P>
|
|
by <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> is lexical or dynamic.<P>
|
|
<P>
|
|
(b) Delete *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.<P>
|
|
<P>
|
|
<B>Proposal (EVALHOOK-STEP-CONFUSION:FIX):<P>
|
|
</B><P>
|
|
(1) Clarify that there is no guarantee that the functions that are the<P>
|
|
values of *EVALHOOK* and *APPLYHOOK* will ever be invoked during<P>
|
|
evaluation.<P>
|
|
<P>
|
|
(2) Remove the requirement that <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> be implemented using *EVALHOOK*.<P>
|
|
Make it explicitly vague whether the scope of the code that is affected<P>
|
|
by <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> is lexical or dynamic.<P>
|
|
<P>
|
|
(3) Deprecate *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.<P>
|
|
<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
Point by point:<P>
|
|
<P>
|
|
(1) This is merely an explicit statement of the status quo.<P>
|
|
<P>
|
|
(2) This permits compiled-only implementations to support a <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A><P>
|
|
utility that does something useful.<P>
|
|
<P>
|
|
(3) The <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>eval</B></A> hook mechanism is a relic of a particular interpreter<P>
|
|
implementation technique and really has no place in a language<P>
|
|
<A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>, especially since one of the stated goals of the language is<P>
|
|
consistency between compiled and interpreted code. Since there is no<P>
|
|
guarantee that these functions will ever be invoked, portable programs<P>
|
|
should not rely on them.<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
According to Kent Pitman:<P>
|
|
I'm told by the guys who did the Cloe implementation that indeed<P>
|
|
neither evalhook nor step do much of anything useful. If I understood<P>
|
|
them correctly, *evalhook* just never gets called, and step works by a<P>
|
|
different mechanism that may work at a granularity different than what<P>
|
|
people expect.<P>
|
|
<P>
|
|
Loosemore has been implementing an evaluator for Utah Common Lisp that<P>
|
|
uses a preprocessor to partially compile programs. The interpreter<P>
|
|
for the processed code does support the use of an *evalhook*-like<P>
|
|
special variable, but the information it is passed is in a different<P>
|
|
format than that which *evalhook* requires. In particular, the object<P>
|
|
representing the lexical environment contains only bindings and not<P>
|
|
syntactic information such as macro definitions. It also supports a<P>
|
|
variety of annotation-based program debugging hooks that are specified<P>
|
|
by declarations. We are in the process of integrating the<P>
|
|
preprocessor into the UCL compiler so that most of these debugging<P>
|
|
hooks will also work in compiled code.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
None.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
None.<P>
|
|
<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Users will not be misled into thinking *evalhook* is more portable<P>
|
|
than it actually is.<P>
|
|
<P>
|
|
Compiled-only implementations can make <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A> do something reasonable.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
There is an article by Parker in Lisp Pointers, Vol 1 #4 which<P>
|
|
describes one approach for annotation-based debugging. Loosemore's<P>
|
|
PhD dissertation (soon to be available as a UofU Tech Report) also<P>
|
|
discusses alternate approaches for implementing program steppers.<P>
|
|
<P>
|
|
Scott Fahlman says:<P>
|
|
I am staying out of most of these discussions, but thought I'd throw in my<P>
|
|
two cents' worth on this one: I would very much like to see evalhook and<P>
|
|
applyhook removed from the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>. They have been a constant source of<P>
|
|
confusion, and there are so many different interpretations of what these<P>
|
|
hooks do that facilities built on top of them are not really very portable<P>
|
|
in practice. I'm now convinced that a really good stepping package cannot<P>
|
|
easily be written using these hooks, but must be integrated into the<P>
|
|
interpreter of a given implementation.<P>
|
|
<P>
|
|
David Moon says:<P>
|
|
Seems okay, except that if we are going to deprecate these things,<P>
|
|
I would much rather just remove them. You would surely argue that<P>
|
|
no significant program could possibly be depending on EVALHOOK,<P>
|
|
since it has no semantics, so there can't be a compatibility issue.<P>
|
|
If we agree that something is a bad idea, I would rather remove it<P>
|
|
entirely unless there is a compelling compatibility reason to only<P>
|
|
deprecate it. In fact even if some programs used EVALHOOK, I would<P>
|
|
still want to remove it, as I long ago ceased to believe in any<P>
|
|
fantasy of seamless compatibility between CLtL and ANSI CL. But<P>
|
|
others might not agree with me there.<P>
|
|
<P>
|
|
Plus if we remove them, Symbolics doesn't have to fix the bug that<P>
|
|
EVALHOOK and APPLYHOOK accidentally got declared <A REL=DEFINITION HREF="../Body/d_specia.htm#special"><B>SPECIAL</B></A>. I mention<P>
|
|
this only as an example of the costs of deprecating things instead<P>
|
|
of removing them. They have to be maintained. Not only do they have<P>
|
|
to be documented, but in addition to documenting them we have to tell<P>
|
|
people not to use them.<P>
|
|
<P>
|
|
Loosemore says:<P>
|
|
I'd rather get rid of these things entirely too, but I have previously<P>
|
|
noted some resistance to the idea from others. Maybe they've changed<P>
|
|
their minds by now. Anyway, if we can't agree to delete them now, <P>
|
|
deprecation is better than the current situation.<P>
|
|
-------<P>
|
|
<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|