- Do not assume :always does a check on an empty list:
[1]> (loop :for x :in '() :always (oddp x))
is the correct result. But deep inside logic involving "have all entries that property?" it can be surprising.
T - 0 is not NIL. Stop laughing, it took me 2 days to find that one part of the program thought it was talking T/NIL while the other talked 0/1 or 2. One (declare (type boolean result)) and a few runtime errors later the program gives sane results again.
Wednesday, June 07, 2006
stupid CL errors
Subscribe to:
Post Comments (Atom)
3 comments:
Yeah, mixing up 0 and NIL can be insidious.
I once spent hours looking for an obscure bug in the SBCL debugger internals, which turned out the be caused by some code assuming that (LOGAND FOO 1) would return false for even numbers. I read through the code a dozen times thinking "yeah, that part makes sense", "looks ok, the error must be elsewhere", etc.
Then I posted just that one expression (without all of the surrounding junk) on my blog. And many people still couldn't see what the bug was.
(http://jsnell.iki.fi/blog/archive/2005-03-21.html)
I do not find the behavior of loop/always surprising from a logic view at all. If somebody asked me "are all objects in this (empty) set odd numbers?", I'd answer yes of course.
In basic predicate calculus: "for all x in {}: odd(x)" of course yields a true value, just as your example does. You can read it as an implication, if you want: "x is in {}" -> "x is odd" is "x is not in {} or x is odd" is true, no matter what the predicate was.
I don't see where this is surprising involving logic. :-) But it's nice that I haven't know about the always keyboard before and only knew about the "every" function. :->
wouldn't it be better to use (some #'oddp '())
Post a Comment