Issue EVALHOOK-STEP-CONFUSION Writeup

Forum:		Cleanup

Issue:		EVALHOOK-STEP-CONFUSION

References:	CLtL p 321, 323, 441

		Issue STEP-ENVIRONMENT (passed)

                Issue APPLYHOOK-ENVIRONMENT (passed)

Category:	CHANGE/CLARIFICATION

Edit History:   V1, 9 Oct 1989, Sandra Loosemore

		V2, 2 Nov 1989, Sandra Loosemore (update discussion)

	        V3, 4 Dec 1990, Pitman (amendment per X3J13)


Problem Description:


Common Lisp permits the evaluator to be implemented by compiling the

form before executing it, but notes that this techniques "renders the

EVALHOOK mechanism relatively useless" (CLtL p. 321).


CLtL also requires the STEP utility to be implemented in terms of

EVALHOOK (p. 323).  The restriction against implementing STEP using

some other technique (such as annotations on code lexically within the

body of the STEP) that make more sense in a compiled-only

implementation is pointless.  It is probably not even desirable for

STEP to be implemented with *EVALHOOK*, since this effectively causes

the stepper to break on user programs that also use *EVALHOOK*.



Proposal (EVALHOOK-STEP-CONFUSION:X3J13-NOV-89):


(a) Remove the requirement that STEP be implemented using *EVALHOOK*.

Make it explicitly vague whether the scope of the code that is affected

by STEP is lexical or dynamic.


(b) Delete *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.


Proposal (EVALHOOK-STEP-CONFUSION:FIX):


(1) Clarify that there is no guarantee that the functions that are the

values of *EVALHOOK* and *APPLYHOOK* will ever be invoked during

evaluation.


(2) Remove the requirement that STEP be implemented using *EVALHOOK*.

Make it explicitly vague whether the scope of the code that is affected

by STEP is lexical or dynamic.


(3) Deprecate *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.



Rationale:


Point by point:


(1) This is merely an explicit statement of the status quo.


(2) This permits compiled-only implementations to support a STEP

utility that does something useful.


(3) The eval hook mechanism is a relic of a particular interpreter

implementation technique and really has no place in a language

standard, especially since one of the stated goals of the language is

consistency between compiled and interpreted code.  Since there is no

guarantee that these functions will ever be invoked, portable programs

should not rely on them.




Current Practice:


According to Kent Pitman:

  I'm told by the guys who did the Cloe implementation that indeed

  neither evalhook nor step do much of anything useful.  If I understood

  them correctly, *evalhook* just never gets called, and step works by a

  different mechanism that may work at a granularity different than what

  people expect.


Loosemore has been implementing an evaluator for Utah Common Lisp that

uses a preprocessor to partially compile programs.  The interpreter

for the processed code does support the use of an *evalhook*-like

special variable, but the information it is passed is in a different

format than that which *evalhook* requires.  In particular, the object

representing the lexical environment contains only bindings and not

syntactic information such as macro definitions.  It also supports a

variety of annotation-based program debugging hooks that are specified

by declarations.  We are in the process of integrating the

preprocessor into the UCL compiler so that most of these debugging

hooks will also work in compiled code.



Cost to implementors:


None.



Cost to users:


None.



Benefits:


Users will not be misled into thinking *evalhook* is more portable

than it actually is.


Compiled-only implementations can make STEP do something reasonable.



Discussion:


There is an article by Parker in Lisp Pointers, Vol 1 #4 which

describes one approach for annotation-based debugging.  Loosemore's

PhD dissertation (soon to be available as a UofU Tech Report) also

discusses alternate approaches for implementing program steppers.


Scott Fahlman says:

  I am staying out of most of these discussions, but thought I'd throw in my

  two cents' worth on this one: I would very much like to see evalhook and

  applyhook removed from the standard.  They have been a constant source of

  confusion, and there are so many different interpretations of what these

  hooks do that facilities built on top of them are not really very portable

  in practice.  I'm now convinced that a really good stepping package cannot

  easily be written using these hooks, but must be integrated into the

  interpreter of a given implementation.


David Moon says:

  Seems okay, except that if we are going to deprecate these things,

  I would much rather just remove them.  You would surely argue that

  no significant program could possibly be depending on EVALHOOK,

  since it has no semantics, so there can't be a compatibility issue.

  If we agree that something is a bad idea, I would rather remove it

  entirely unless there is a compelling compatibility reason to only

  deprecate it.  In fact even if some programs used EVALHOOK, I would

  still want to remove it, as I long ago ceased to believe in any

  fantasy of seamless compatibility between CLtL and ANSI CL.  But

  others might not agree with me there.


  Plus if we remove them, Symbolics doesn't have to fix the bug that

  EVALHOOK and APPLYHOOK accidentally got declared SPECIAL.  I mention

  this only as an example of the costs of deprecating things instead

  of removing them.  They have to be maintained.  Not only do they have

  to be documented, but in addition to documenting them we have to tell

  people not to use them.


Loosemore says:

  I'd rather get rid of these things entirely too, but I have previously

  noted some resistance to the idea from others.  Maybe they've changed

  their minds by now.  Anyway, if we can't agree to delete them now, 

  deprecation is better than the current situation.

-------