EVALHOOK-STEP-CONFUSIONEVALHOOK 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*.
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.
*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.
(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.
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.
Compiled-only implementations can make STEP do something reasonable.
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. -------