From: Christophe R. <cs...@ca...> - 2003-04-03 14:35:08
|
Tony Martinez <to...@te...> writes: > * (handler-case > (with-input-from-string (*query-io* " no") > (yes-or-no-p)) > (simple-type-error () 'error)) > ; in: LAMBDA NIL > ; (SB-KERNEL:FLOAT-WAIT) > ; > ; note: deleting unreachable code > ; compilation unit finished > ; printed 1 note > > Should this note be printed? The HANDLER-CASE expansion introduces > the (FLOAT-WAIT) call. Are implementation-disclosing notes bugs? It probably shouldn't be printed, but fixing it is a little nasty. This is related to bug #238, and is an artefact of our implementation of EVAL. The point is that, when deciding whether or not to print code deletion notes, the system has a heuristic to see whether the form in question existed in the original code, and only if so, print the note. Clearly, (SB-KERNEL:FLOAT-WAIT) doesn't appear in your original code. The problem is that it _does_ appear in the original code as seen by the compiler, because the first stage of evaluation is a fair amount of macroexpansion. By the time the compiler proper sees the code, it's been macroexpanded to something that does contain SB-KERNEL:FLOAT-WAIT, and so when it deletes that clause, it does trigger the heuristic and the note is printed. So, to fix this (and bug #238) the compiler needs to be notified a little bit more about what the original source actually was. Sadly, it's a little trickier that one might expect, because of the need to get the top-level semantics of PROGN, SYMBOL-MACROLET and friends right -- one can't just feed the original expression into the compiler willy-nilly. In any case, I'll add this report to bug 238. Thanks, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |