On 11 March 2010 21:26, Brian Hurt <bhur...@gmail.com> wrote: > I think I still disagree with this idiom, for two reasons. First, I have > the hope that some day Clojure will be smart enough to realize that the > boolean returned from empty? can be unboxed, and unbox it (with all the > performance optimizations this allows). seq doesn't allow this > optimization- in the non-empty case it returns a cons cell, which will > (almost certainly) never be unboxable.
Branching on nil has got to be the fastest kind possible -- I'd venture a guess that it comes down to a branch-if-zero CPU instruction on most architectures. True, there's no unboxing optimisation, but that's because it's meaningless to try to unbox nil. So, I'd expect using seq in place of a composition of not and empty to be the "more optimised" thing to do, not the other way around. > My second objection is that it sets a bad precedent. The core library sets > the tone for the language- it's the main example of how you write code in > the language. Caesar's wife must be above reproach. And depending upon a > specific, corner-case behavior of a function whose main purpose is do > something else is a practise that will burn you badly. Given the way Clojure's core library is written, plus the above mentioned docstring, I'd say that it's wrong to say that seq's "main purpose is to do something else". On the contrary, it would appear to me that part of its purpose is to return a value which is false in a Boolean context when given an "empty" seqable object. Sincerely, Michał -- 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
