Re: [Sbcl-devel] Re: *debugger-hook* and break

[Daniel B. <da...@te...>]

William Harold Newman <wil...@ai...> writes:

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

I'm seesawing.  After attempting to write a correct docstring for the
multiple-hooks version, I realise it's not obvious what it should do.

The ordinary debugger hook is executed with *debugger-hook* bound to
NIL, so that errors in the hook don't trash the call stack, and the
previous value is passed to the hook.  If we have a list of hooks,
should *invoke-debugger-hook* be bound to NIL, or to (remove this-hook
*invoke-debugger-hook*) (all the hooks except this one), or to (cdr
(member this-hook *invoke-debugger-hook*)) (all the hooks after this
one) or what?  What should the second argument be?  The whole list, or
the current element?

If we could have another round on what the need for multiple debugger
hooks is, I think that'd be productive.  Does a user really have LEP
and SLIME and a CLIM listener in the same image and want all of those
hooks to be checked every time?  If there's a thread listening on 
a socket for LEP, can't it locally bind *invoke-debugger-hook* 
to #'lep-debugger-hook, and similarly for the other applications?


-dan

-- 

   http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro