Hi,
sorry for touching this subject, but I have a question which looks to me
related to the thread.
There is not-empty function in the sequences library.
If not-empty is there should we use it instead of (seq c) to check if a
sequence is not empty?
The doc does not propose to use (not-empty
(seq x) will return a sequence if x is not empty, regardless of what
type x was, e.g., (seq [1 2 3]) = (1 2 3)
(not-empty x) will return the original collection if it is not empty,
e.g., (not-empty [1 2 3]) = [1 2 3]
If you need a sequence, you'll want to use seq; if you need the
original
Hi,
On Fri, Mar 12, 2010 at 08:25:23AM +1100, Alex Osborne wrote:
The list equivalent to the vec or set functions is (apply list ...) --
there's no shorthand for it as you shouldn't be using lists much
explicitly, use a vector instead.
In fact there is a short-hand:
user= (seq [])
nil
user=
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
user=
Brian
--
You received this message because you
seq is not seq?
On Thu, Mar 11, 2010 at 11:19 AM, 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? '())
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
On Thu, Mar 11, 2010 at 2:33 PM, Kevin Downey redc...@gmail.com wrote:
seq is not seq?
No- it's just that empty lists are still seqs (seq? returns true).
The only thing that is wrong here is the doc comment for empty?- it makes
sense (to me at least) that empty lists are seqs, just like
who said they are?
On Thu, Mar 11, 2010 at 11:36 AM, Brian Hurt bhur...@gmail.com wrote:
On Thu, Mar 11, 2010 at 2:33 PM, Kevin Downey redc...@gmail.com wrote:
seq is not seq?
No- it's just that empty lists are still seqs (seq? returns true).
The only thing that is wrong here is the doc
On 11 March 2010 20:36, Brian Hurt bhur...@gmail.com wrote:
On Thu, Mar 11, 2010 at 2:33 PM, Kevin Downey redc...@gmail.com wrote:
seq is not seq?
No- it's just that empty lists are still seqs (seq? returns true).
The only thing that is wrong here is the doc comment for empty?- it makes
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
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
On Thu, Mar 11, 2010 at 3:40 PM, Kevin Downey redc...@gmail.com wrote:
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
given that rhickey wrote seq, and rhickey recommends using it for this
purpose, I doubt you need to worry about it changing radically without
warning. the behavior of seq is not just incidental, it has a history
stretching back to before seqs became as lazy as they are now, and
it's behavior made
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
14 matches
Mail list logo
