Nikodemus Siivola <tsiivola@...> writes:
> Looking at the bug 387, I see a few ways this can be dealt with:
> 1. Change WITH-TEST to use *DEBUGGER-HOOK* instead of HANDLER-BIND to
> detect errors.
> 2. Remove the resignaling behaviour from
> COMPILER-ASSERT-SYMBOL-HOME-PACKAGE-UNLOCKED, and amend the
> documentation: currently we claim that package-lock violations
> are continuable errors, and say that lexical violations cause
> a compile-time error.
> 3. Extend the package-lock interface: separate PACKAGE-LOCK-VIOLATION from
> PACKAGE-LOCK-ERROR. Only the latter would be a subtype of ERROR. In
> this scenario detecting a violation would cause PACKAGE-LOCK-VIOLATION
> to be signalled, which when unhadled would be escalated to
> The key issue here is whether
> (handler-bind ((foo-condition (lambda (c) (signal c) (error ...))))
> is sane if FOO-CONDITION is a subtype of error. No:2 and no:3 would
> fix this, whereas no:1 would leave this alone.
> I was going to say that I've no real preference here, but on further
> consideration I'd rather do no:1 or no:2.
I think (1) is a really bad idea; conditions of type ERROR (a subtype
of SERIOUS-CONDITION) are by convention expected to invoke the
debugger if unhandled, and I think it's perfectly reasonable for user
code, not just our own regression tests, to attempt to handle errors
around a compilation, say. I think it is an anomaly to allow these
compile-time detections to propagate to user handlers, and I think
that the right behaviour, as with other static detections in the
compiler like type-errors, is to convert to a run-time error
irrespective of what user handlers for ERROR (as opposed to any
subtype) there are around the compilation.
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.
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.