From: Mika P. <mik...@ik...> - 2008-03-28 15:12:46
|
Dear developers, This may be a small bug or just an inconvenience. It seems like unnecessary notes of deleting unreachable code is printed. Results from computations seem to be right at least in these cases. Problem arises when variable is declared symbol after its value is assigned nil. It may also be a mistake of mine. Then please forgive me. Thank you for excellent sbcl which I like very much to use. Mika ;; --- Usage and version information --- ;; sbcl version 1.0.15 x86-64 linux binary from sourceforge ;; setup ;; with this test-4 gives 11 notes (proclaim '(optimize (speed 3) (safety 1) (space 0) (debug 0) (compilation-speed 0))) ;; with this or default settings test-4 gives 1 note (proclaim '(optimize (speed 3) (safety 1) (space 1) (debug 0) (compilation-speed 0))) ;; All examples are typed to repl ;; --- Simple case --- ;; Ok (defun test-1 (a) (declare (type symbol a)) (if a 'is-true)) (test-1 :test) ;; Gives 1 note of deleting unreachable code ;; although logic is similar to test-1 (defun test-2 () (let ((a nil)) (declare (type symbol a)) (if a 'is-true))) (test-2) ;; --- More complicated case --- ;; Ok (defun test-3 (element listing) (declare (type list listing) (type symbol element)) (if element (member element listing :test 'equal))) (test-3 :test '(:a :b)) ;; Gives 11 notes of deleting unreachable code ;; although logic is similar to test-3. ;; This example is synthetic and not real production code. (defun test-4 () (let ((listing (list :a :b)) (element nil)) (declare (type list listing) (type symbol element)) (if element (member element listing :test 'equal)))) (test-4) ;; --- Another case --- ;; Gives note of deleting unreachable code. ;; Results are ok. (defun test-5 (&key (element nil)) (declare (type symbol element)) (if element (assert (member element '(:a :b :c) :test 'equal) nil "Not allowed..."))) (test-5) (test-5 :element nil) (test-5 :element :a) (test-5 :element :x) |
From: Rupert S. <rsw...@go...> - 2008-03-28 15:36:00
Attachments:
signature.asc
|
Dear Mika, I think this is not a bug - rather SBCL is correct: > ;; --- Simple case --- > > ;; Ok > (defun test-1 (a) > (declare (type symbol a)) > (if a 'is-true)) > > (test-1 :test) > > ;; Gives 1 note of deleting unreachable code > ;; although logic is similar to test-1 > (defun test-2 () > (let ((a nil)) > (declare (type symbol a)) > (if a 'is-true))) > > (test-2) test-1 doesn't complain, since it's perfectly reasonable: a might be nil or not. However, in test-2, sbcl _knows_ that a is nil, since you've made it so in the let and the declare can't change this. Thus a must be nil at the if and 'is-true can never be evaluated. > > ;; --- More complicated case --- > > ;; Ok > (defun test-3 (element listing) > (declare (type list listing) > (type symbol element)) > (if element > (member element listing :test 'equal))) > > (test-3 :test '(:a :b)) > > ;; Gives 11 notes of deleting unreachable code > ;; although logic is similar to test-3. > ;; This example is synthetic and not real production code. > (defun test-4 () > (let ((listing (list :a :b)) > (element nil)) > (declare (type list listing) > (type symbol element)) > (if element > (member element listing :test 'equal)))) > > (test-4) > Similarly here, element must be nil. > ;; --- Another case --- > > ;; Gives note of deleting unreachable code. > ;; Results are ok. > (defun test-5 (&key (element nil)) > (declare (type symbol element)) > (if element > (assert (member element '(:a :b :c) :test 'equal) > nil "Not allowed..."))) > > (test-5) > (test-5 :element nil) > (test-5 :element :a) > (test-5 :element :x) > Here I'm not so sure what's supposed to happen - maybe someone more knowledgeable can weigh in. Clearly, when presented with (test-5), sbcl knows that element is nil etc. but I don't know how far the inferences are carried. Rupert |
From: Nikodemus S. <nik...@ra...> - 2008-03-28 15:41:26
|
On Fri, Mar 28, 2008 at 5:12 PM, Mika Pihlajamäki <mik...@ik...> wrote: > This may be a small bug or just an inconvenience. It seems > like unnecessary notes of deleting unreachable code is printed. > Results from computations seem to be right at least in these cases. > > Problem arises when variable is declared symbol after its value is > assigned nil. > ;; Gives 1 note of deleting unreachable code > ;; although logic is similar to test-1 > (defun test-2 () > (let ((a nil)) > (declare (type symbol a)) > (if a 'is-true))) I'm not sure I follow: since A is always NIL, the first leg is dead, hence the note. What's the problem? > ;; Gives 11 notes of deleting unreachable code > ;; although logic is similar to test-3. > ;; This example is synthetic and not real production code. > (defun test-4 () > (let ((listing (list :a :b)) > (element nil)) > (declare (type list listing) > (type symbol element)) > (if element > (member element listing :test 'equal)))) Same thing -- ELEMENT is always NIL. > ;; Gives note of deleting unreachable code. > ;; Results are ok. > (defun test-5 (&key (element nil)) > (declare (type symbol element)) > (if element > (assert (member element '(:a :b :c) :test 'equal) > nil "Not allowed..."))) I don't get a note with this. What version of SBCL are you using? Cheers, -- Nikodemus |
From: Mika P. <mik...@ik...> - 2008-03-28 19:02:25
|
Nikodemus Siivola wrote: > I'm not sure I follow: since A is always NIL, the first leg is > dead, hence the note. What's the problem? Yes you are right. While trying to rephrase the original code to a simpler self-contained example, I unfortunately created a silly error in tests 1-4 which gave the same note but for another and real reason. But the original problem remains which is shown in test-5. Here is a new dump from console running Intel 64 bit Kubuntu and sbcl 1.0.15 x86-64 version which is loaded from existing binary tar in Sourceforge. Notes about deleting unreachable code have frustrated and bewildered me many times. They sometimes take serious time to clean. Now that I could not reason why it happened, I wished I could ask your kind checking. Thank you all sbcl developers, Mika * mika@quad64:~$ sbcl This is SBCL 1.0.15, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (proclaim '(optimize (speed 3) (safety 1) (space 0) (debug 0) (compilation-speed 0))) * (defun test-5 (&key (element nil)) (declare (type symbol element)) (if element (assert (member element '(:a :b :c) :test 'equal) nil "Not allowed..."))) ; in: LAMBDA NIL ; (MEMBER ELEMENT '(:A :B :C) :TEST 'EQUAL) ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 1 note TEST-5 * |
From: David B. <li...@da...> - 2008-03-28 16:29:11
|
On Fri, Mar 28, 2008 at 05:12:33PM +0200, Mika Pihlajamäki wrote: >This may be a small bug or just an inconvenience. It seems >like unnecessary notes of deleting unreachable code is printed. >Results from computations seem to be right at least in these cases. Actually, it's more of an extra convenience. >Problem arises when variable is declared symbol after its value is >assigned nil. Which is invalid, NIL is not of type symbol. If you need the construct, you could declare it to be: (declare (type (or null symbol) a)) Have a look at: <http://www.sbcl.org/manual/Declarations-as-Assertions.html> <http://www.sbcl.org/manual/Getting-Existing-Programs-to-Run.html> Also see the second part of the example in <http://www.lisp.org/HyperSpec/Body/speope_letcm_letst.html> where it clearly states that this is incorrect. David |
From: Christophe R. <cs...@ca...> - 2008-03-28 16:52:57
|
David Brown <li...@da...> writes: > On Fri, Mar 28, 2008 at 05:12:33PM +0200, Mika Pihlajamäki wrote: > >>Problem arises when variable is declared symbol after its value is >>assigned nil. > > Which is invalid, NIL is not of type symbol. NIL is of type SYMBOL. In future, please check your assertions before posting them to this mailing list; if you're unsure, phrase your statements less authoritatively. Best, Christophe |
From: David B. <li...@da...> - 2008-03-28 17:00:07
|
On Fri, Mar 28, 2008 at 04:52:27PM +0000, Christophe Rhodes wrote: >NIL is of type SYMBOL. In future, please check your assertions before >posting them to this mailing list; if you're unsure, phrase your >statements less authoritatively. Sorry about that. I got distracted by the wrong part of the question, and rambled nonsense. The problem was that I was sure, just wrong. David |