On Sat, 22 Oct 2005, Christophe Rhodes wrote:
> On the other hand, I'm not sure that we need to document the mechanism
> by which detections at compile-time are converted into either errors
> at compile-time or errors at load-time. That is, there would be no
> need to document the non-error condition in (3), just as we don't
> document COMPILER-ERROR for the user -- it's purely a compiler
> internal. On the other hand, I believe that the mechanism is the
> right one to use.
Uh, not so. The unlike with COMPILER-ERROR the point of the resignalling
we do it to allow users to intervene:
(handler-bind ((package-lock-violation (c) #'hack-around-3rd-party-bugs))
But perhaps this is a part of the interface that is not really needed --
or at least not needed for FLET &co.
> I don't know if option (2) "works" (ahaha) in the presence of nested
> invokations of the compiler, but then again I don't know if what we
> have currently works either.
I should currently we do something like
(handler-bind ((package-lock-violation (lambda (c)
then it would just be
(handler-bind ((package-lock-violation #'compiler-error))
Which brings to mind option 4:
Instead of the above just let the continuable package-lock violation
bubble all the way to the top.
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."