On Sun, Nov 09, 2003 at 10:23:43PM +0000, Daniel Barlow wrote:
> David Lichteblau <david@...> writes:
> > My patch adds *INVOKE-DEBUGGER-HOOK*, which is observed by
> > INVOKE-DEBUGGER and not touched by any other SBCL function. To play
> > fair, I decided that a list of hook functions would be better than a
> > single function. For example, both LEP and SLIME might want to install
> > their hooks, but only the one actually connected to an emacs would grab
> > control.
> I vote for this change. I think the same hook could also be used for
> DISABLE-DEBUGGER and for some part of the background-threads-wait-for-debugger
It basically sounds reasonable to me too, based on my experience of
being bitten by the ANSI requirement that BREAK bypass
CL:*DEBUGGER-HOOK*. That made CL:*DEBUGGER-HOOK* less than useful for
--disable-debugger, and now I find it unsurprising that other
applications would find CL:*DEBUGGER-HOOK* inappropriate too. So it's
hard to avoid multiple applications (like David's GUI, Dan's threads,
and Bill's --disable-debugger) having valid reasons to want to come in
below the ANSI hook, and the new extended hook sounds like a better
mechanism than having everyone do
(SETF (FDEFINITION 'CL:INVOKE-DEBUGGER) ...).
I'm not completely sure it should have multiple hook functions,
instead of doing as ANSI does with CL:*DEBUGGER-HOOK*. (I haven't
thought through the implications either way.) But whether it does
or doesn't, it's probably better than SETF FDEFINITION.
William Harold Newman <william.newman@...>
We were bedevilled by the daemons of diagrammatic overdesign. My God,
three little boxes drawn on the back of a napkin, Game, Frame, and
Throw, and it was still too complicated and just plain wrong.
-- Robert C. Martin, _Agile Software Development_, p. 72
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C