Consider the following bit of code: (let [ x (new java.lang.Boolean false) ] (if x "trouble" "ok"))
As you might guess from the fact that I'm calling it's a trick question, the above code returns "trouble", not "ok". From experimentation, it looks like clojure's if takes the second branch if the value is nil or referentially equal to java.lang.Boolean/FALSE. If you have a boolean object which is not referentially equal to Boolean/FALSE, but still holds the value false, this is treated as true by Clojure. The problem is, I'm not 100% sure if this is a bug or not. The problem is nil-punning. The if statement can't rely on the test expression evaluating to a boolean. Which means to make this work correctly, if statements would have to do an instanceof test (to see if the object was a Boolean), then a cast and a call to .booleanValue to get the boolean value. Which is way more expensive than a quick nil test and referential equality test. This is, however, more than a little bit surprising and depressing. Somewhere, in my 10K lines of clojure code, boolean values are getting boxed in exactly that way. I've fixed the current problem (dropping in a call to .booleanValue in the test), but having if statements that can fail makes me paranoid. Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
