References: BREAK (pp432-433), *DEBUGGER-HOOK* (Conditions, Rev18, p42)
Edit history: 01-Mar-91, Version 1 by Pitman
Status: For X3J13 consideration
According to v18 of the Conditions Proposal (p42), when INVOKE-DEBUGGER
is executed, ``If the variable *DEBUGGER-HOOK* is not NIL, it will be
According to p432-433 of CLtL, when BREAK is called, ``A particular
implementation may choose, according to its own style and needs, when
BREAK is called to go into a debugger different from the one used for
It isn't clear whether BREAK is affected by *DEBUGGER-HOOK*, or whether
it uses *DEBUGGER-HOOK* to implement any use of an alternate debugger.
1. Define the debugger implemented by BREAK is not affected by
the value of *DEBUGGER-HOOK* upon entry.
2. Define that BREAK binds the value of *DEBUGGER-HOOK* to NIL.
(LET ((*DEBUGGER-HOOK* #'(LAMBDA (C D) (RETURN-FROM FOO NIL))))
enters a breakpoint rather than just returning NIL.
1. BREAK's primary role is to provide access to Lisp debugging.
Anyone who wants to enter the debugger through *DEBUGGER-HOOK*
can use INVOKE-DEBUGGER.
2. *DEBUGGER-HOOK* provides an application/end-user-oriented
debugging interface, while BREAK provides a Lisp debugging
interface. Since BREAK will generally lead to the typing
of Lisp expressions rather than application-specific commands,
it makes sense for the Lisp debugging environment to be visible
here rather than the application debugging environment.
Symbolics Genera returns NIL from the test case and would have to change.
Cost to Implementors:
Very small. They just have to make BREAK bind *DEBUGGER-HOOK* to NIL
before doing anything else.
Cost to Users:
Cost of Non-Adoption:
Users would not know what to expect when moving from implementation to
Less ambiguity in the spec.
Pitman supports this proposal, but would consider any reasonable
alternative which made the expected behavior explicit.