it's not a corner case, seq returns a seq containing more items if there are more, or nil if there are not. have you looked at clojure's truth table? if distinguishes from nil and not-nil, with true and false thrown in for interop.
On Thu, Mar 11, 2010 at 12:26 PM, Brian Hurt <bhur...@gmail.com> wrote: > > > On Thu, Mar 11, 2010 at 2:36 PM, Chouser <chou...@gmail.com> wrote: >> >> On Thu, Mar 11, 2010 at 2:19 PM, Brian Hurt <bhur...@gmail.com> wrote: >> > So the doc comment on empty? reads, in part: >> > >> >> Please use the idiom (seq x) rather than (not (empty? x)) >> > >> > A heads up to people: these two code sequences are *not* identical in >> > behavior: >> > >> > user=> (seq? '()) >> > true >> > user=> (not (empty? '())) >> > false >> >> What you demonstrated is that (seq x) is not the same as >> (seq? x) -- useful to know, but not the point of the docstring. >> >> Also note that it's not necessary or idiomatic to quote the empty >> list: >> >> user=> (seq ()) >> nil >> > > Point. > > 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. > > 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. > > That being said, I'm just going to agree to disagree, and move on. > > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
