Issue DEBUGGER-HOOK-VS-BREAK Writeup

Issue:        DEBUGGER-HOOK-BREAK

Forum:	      Editorial

References:   BREAK (pp432-433), *DEBUGGER-HOOK* (Conditions, Rev18, p42)

Category:     CHANGE

Edit history: 01-Mar-91, Version 1 by Pitman

Status:	      For X3J13 consideration


Problem Description:


  According to v18 of the Conditions Proposal (p42), when INVOKE-DEBUGGER 

  is executed, ``If the variable *DEBUGGER-HOOK* is not NIL, it will be 

  funcalled ...''


  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 

  handling errors.''


  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.


Proposal (DEBUGGER-HOOK-BREAK:CLARIFY):


  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.


Test Case:


  (BLOCK FOO

    (LET ((*DEBUGGER-HOOK* #'(LAMBDA (C D) (RETURN-FROM FOO NIL))))

      (BREAK)))


  enters a breakpoint rather than just returning NIL.


Rationale:


  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.


Current Practice:


  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:


  Probably none.


Cost of Non-Adoption:


  Users would not know what to expect when moving from implementation to

  implementation.


Benefits:


  Less ambiguity in the spec.


Aesthetics:


  Negligible.


Discussion:


  Pitman supports this proposal, but would consider any reasonable 

  alternative which made the expected behavior explicit.