#

## 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.