[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.