Why is using (not (empty? coll)) not idiomatic?

[Nico Balestra]

I'm not sure this question has been asked already, but I really want to know the "principle" behind (not (empty? coll)) not being idiomatic.

I find it much more readable than (seq coll) and I don't understand why (empty?) exists if it's not idiomatic. But my real doubt is:

What's the "idiom" in (seq coll)?

Thanks and sorry if the question sounds a bit pedantic :)

Nico

"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures" - A.J. Perlis

[Kelker Ryan]

(seq coll) will return a true value if the collection isn't empty. It will also return nil (false) if it is.

11.05.2013, 17:37, "Nico Balestra" <nicoba...@gmail.com>:

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Kelker Ryan]

Here's an example.

user=> (if (seq []) (println 1))
nil
user=> (if (seq [1]) (println 1))
1
nil


11.05.2013, 18:40, "Kelker Ryan"

> (seq coll) will return a true value if the collection isn't empty. It will also return nil (false) if it is.
>
> 11.05.2013, 17:37, "Nico Balestra" <nicoba...@gmail.com>:
>

>> О©╫I'm not sure this question has been asked already, but I really want to know the "principle" behind (not (empty? coll)) not being idiomatic.
>>
>> О©╫I find it much more readable than (seq coll) and I don't understand why (empty?) exists if it's not idiomatic. But my real doubt is:
>>
>> О©╫What's the "idiom" in (seq coll)?
>>
>> О©╫Thanks and sorry if the question sounds a bit pedantic :)
>>
>> О©╫Nico
>>
>> О©╫"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures" - A.J. Perlis
>>
>> О©╫--
>> О©╫--
>> О©╫You received this message because you are subscribed to the Google
>> О©╫Groups "Clojure" group.
>> О©╫To post to this group, send email to clo...@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+u...@googlegroups.com
>> О©╫For more options, visit this group at
>> О©╫http://groups.google.com/group/clojure?hl=en
>> О©╫---
>> О©╫You received this message because you are subscribed to the Google Groups "Clojure" group.
>> О©╫To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
>> О©╫For more options, visit https://groups.google.com/groups/opt_out.

[Chris Ford]

IMHO it's a bit subjective, but empty? is defined as (not (seq coll)), so using (not (empty? coll)) is really saying (not (not (seq coll))), which feels a bit backwards.

Using seq also plays nicely with if-let:

(if-let [foo (seq "hey")] (print foo))

(if-let [foo (seq "")] (print foo))

Chris

On 11 May 2013 12:48, Kelker Ryan <thein...@yandex.com> wrote:

Here's an example.

user=> (if (seq []) (println 1))
nil
user=> (if (seq [1]) (println 1))
1
nil


11.05.2013, 18:40, "Kelker Ryan"

> (seq coll) will return a true value if the collection isn't empty. It will also return nil (false) if it is.
>
> 11.05.2013, 17:37, "Nico Balestra" <nicoba...@gmail.com>:
>

>>  I'm not sure this question has been asked already, but I really want to know the "principle" behind (not (empty? coll)) not being idiomatic.
>>

>>  I find it much more readable than (seq coll) and I don't understand why (empty?) exists if it's not idiomatic. But my real doubt is:
>>

>>  What's the "idiom" in (seq coll)?
>>

>>  Thanks and sorry if the question sounds a bit pedantic :)
>>

>>  Nico

>>
>>  "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures" - A.J. Perlis
>>

[Karsten Schmidt]

> What's the "idiom" in (seq coll)?

Maybe one could say that, generally, in Clojure it's more meaningful
to work with truthy values instead of the boolean true... ?

[Alex Baranosky]

Most of the code I see and write at work at Runa uses (not (empty? foo)).  I'll continue to defend the position that it is more obvious code, and therefore better (imo :) )

Alex

[Jonathan Fischer Friberg]

On Sat, May 11, 2013 at 9:25 PM, Alex Baranosky <alexander...@gmail.com> wrote:

Most of the code I see and write at work at Runa uses (not (empty? foo)).  I'll continue to defend the position that it is more obvious code, and therefore better (imo :) )

Alex

Completely agree. (seq foo) says "nothing", but (empty? foo) says exactly what's going on.

Jonathan

[Sean Corfield]

But then instead of

(if (not (empty? foo))
(do-something-to foo)
base-expr)

you could just write

(if (empty? foo)
base-expr
(do-something-to foo))

which maintains the "idiomatic" approach but is still "more obvious code", yes?

Sean

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[AtKaaZ]

I agree

[Alex Baranosky]

Sean,

I'd tend to write things like that, yeah.

[Rob Lachlan]

Doesn't anyone use "not-empty"?

http://clojuredocs.org/clojure_core/clojure.core/not-empty

[Jean Niklas L'orange]

On Saturday, May 11, 2013 11:28:34 PM UTC+2, Sean Corfield wrote:

you could just write [...]

In some cases, this is even more readable:  

(if-not (empty? foo)
  (do-something-to foo) 
  base-expr)

which has the same effect, but in some cases, having (do-something-to foo) first may be more readable than having base-expr first.

I'd generally write code as evident as possible. (if-not (empty? x) is a recurring pattern as I feel it conveys its purpose better than (if (seq x), but I suppose that's preference.

-- JN

[Gavin Grover]

Or even define `if-not-empty` or `when-not-empty` without the double `not`.

[Meikel Brandmeyer (kotarak)]

Hi,

Am Samstag, 11. Mai 2013 21:25:11 UTC+2 schrieb Alex Baranosky:

Most of the code I see and write at work at Runa uses (not (empty? foo)).  I'll continue to defend the position that it is more obvious code, and therefore better (imo :) )

seq belongs to seq-land. empty? belongs to data structure land. It should actually be implemented as #(zero? (count %)). But unfortunately it is not. Maybe I'm to green (and too much a premature optimiser) , but I don't like allocating and initialising a new object just to throw it away immediately.

Meikel

[Mike Thvedt]

A good implementation of ISeq won't return a new object, and new short-lived objects are cheap on the JVM anyway. OTOH count can be slow for some data structures. if you don't like instantiating lots of new objects only to throw them away, you're missing out on one of HotSpot's most significant performance/convenience sweet spots, so it's strange you call that premature optimization.

There is however an optimization story against seq: Hotspot (at least on my machine) refuses to inline the call to seq by default (it might still inline if the stars are right or something, the JVM is mysterious). My guess is it's because the code in seq and seqFrom is too big, on my box it exceeds the inline threshold by one byte...

[Meikel Brandmeyer]

2013/5/13 Mike Thvedt <cynic...@gmail.com>

A good implementation of ISeq won't return a new object, and new short-lived objects are cheap on the JVM anyway. OTOH count can be slow for some data structures. if you don't like instantiating lots of new objects only to throw them away, you're missing out on one of HotSpot's most significant performance/convenience sweet spots, so it's strange you call that premature optimization.

There is however an optimization story against seq: Hotspot (at least on my machine) refuses to inline the call to seq by default (it might still inline if the stars are right or something, the JVM is mysterious). My guess is it's because the code in seq and seqFrom is too big, on my box it exceeds the inline threshold by one byte...

I'm not sure what you mean. For an ISeq seq won't return a new object.  But for everything else it will. And count is cheap (a simple field access) for clojure data structures (a seq is not a data structure). While initialising an immediately-to-be-thrown-away object might be (relatively) expensive even when allocation is cheap.

I called my point of view "premature optimisation" because it's probably like you said: allocation is cheap and initialisation usually not worth worrying about. So worrying about it is "premature optimisation".

I still feel empty? to be too ugly in its current implementation. (And to be honest: I almost never needed it, up to now...)

Meikel

[Herwig Hochleitner]

2013/5/13 Meikel Brandmeyer (kotarak) <m...@kotka.de>

seq belongs to seq-land. empty? belongs to data structure land. It should actually be implemented as #(zero? (count %)). But unfortunately it is not.

I'd argue it shouldn't

(empty? (cycle [1 2 3])) => false

(zero? (count (cycle [1 2 3]))) ... infinite loop

This is also a problem for finite seqs, where count is a O(n) operation.

With that in mind, the single seq object allocated by empty? doesn't seem so bad.

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 13. Mai 2013 13:57:57 UTC+2 schrieb Herwig Hochleitner:

2013/5/13 Meikel Brandmeyer (kotarak) <m...@kotka.de>

seq belongs to seq-land. empty? belongs to data structure land. It should actually be implemented as #(zero? (count %)). But unfortunately it is not.

I'd argue it shouldn't

(empty? (cycle [1 2 3])) => false

(zero? (count (cycle [1 2 3]))) ... infinite loop

You misunderstood my argument. cycle returns a sequence => use seq. count is the wrong thing to call here. And calling seq without using its return value (with a name) is a smell. count should not be called in sequences. (In fact I believe that count should be O(1).)

(Shameless plug in case it clarifies what I mean: http://kotka.de/blog/2010/11/Beware_the_unnamed_seq.html )

Meikel

[Mark]

That's a fair point, but do you always know that what you've gotten back is a sequence or a data structure, if you aren't looking directly at the code that you're calling?

[Sean Corfield]

On Mon, May 13, 2013 at 7:08 AM, Meikel Brandmeyer (kotarak)
<m...@kotka.de> wrote:
> You misunderstood my argument. cycle returns a sequence => use seq. count is
> the wrong thing to call here. And calling seq without using its return value
> (with a name) is a smell. count should not be called in sequences. (In fact
> I believe that count should be O(1).)

So you think (count (map inc [1 2 3])) should be illegal?

(I'm just trying to understand your logic here)

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 13. Mai 2013 16:16:36 UTC+2 schrieb Mark:

That's a fair point, but do you always know that what you've gotten back is a sequence or a data structure, if you aren't looking directly at the code that you're calling?

Most of my code are either sequence-y things (mostly transformations). Then I call seq on the argument and work with the result together with a when-let. (maybe transforming things back into the original type of thing afterwards) Or it's about data structures. Then - most of the time - you have to know anyway what you are working on, because the data structures have different usage scenarios.

Typical case:

(into (empty x) (map some-fn (take some-number (filter some-pred x))))

That said: my code is usually not representative.

Meikel

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 13. Mai 2013 16:16:57 UTC+2 schrieb Sean Corfield:

So you think (count (map inc [1 2 3])) should be illegal?

(I'm just trying to understand your logic here)

In the hardcore version, yes. In the practical version, probably not. I never had to call count on a seq. (Various versions of partition-by or split being a notable exception.) (Still a promised O(1) count would be nice for reasoning as we have it for contains?. What is clojure.lang.Counted good for anyway?)

Meikel

[Mark Tomko]

Even so, what do you do when you're using someone else's code as a library?

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/WEoAo6BcCV0/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Jim]

So the following is not encouraged because we disregard the result of calling seq?

(def dummy
  {:a [1 2 3]
   :b [4 5 6]
   :c []
  })

=>(every? seq (vals dummy)) ;make sure all values are non-empty
false

Jim

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 13. Mai 2013 16:48:13 UTC+2 schrieb Jim foo.bar:

So the following is not encouraged because we disregard the result of calling seq?

I would prefer (not-any? empty? ...) with empty? being #(zero? (count %)) if all the values are data structures. If there might be sequences in there, you are in sequence land and should use seq as you did.

But this is just my opinion, which - as you can see - is not mainstream. :)

So don't worry and just use seq (you are on the safe side then, anyway).

Meikel

  

[Timothy Baldridge]

Let's not forget that allocations on the JVM are super, super cheap. In the order of something like 10 cycles. So don't worry so much about throw-away objects. 

Timothy

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 13. Mai 2013 16:56:11 UTC+2 schrieb tbc++:

Let's not forget that allocations on the JVM are super, super cheap. In the order of something like 10 cycles. So don't worry so much about throw-away objects. 

seq involves realization of the first step of the sequence which can be arbitrary expensive. allocation < allocation + initialization + realization

Meikel

 

[Gary Trakhman]

If there is no one-size fits all solution for your use case, it might become idiomatic to use a protocol or some other polymorphism. One could imagine a version of clojure that has protocols for every core function :).

Can you ever have too many cakes to eat them, too?

--

[Christophe Grand]

I second: using seq to test for emptiness is only one half of the idiom, the second half is to bind and to destructure (usually with if-let) the returned value.

Christophe

On Clojure http://clj-me.cgrand.net/
Clojure Programming http://clojurebook.com
Training, Consulting & Contracting http://lambdanext.eu/

[Herwig Hochleitner]

2013/5/13 Meikel Brandmeyer (kotarak) <m...@kotka.de>

You misunderstood my argument. cycle returns a sequence => use seq. count is the wrong thing to call here. And calling seq without using its return value (with a name) is a smell. count should not be called in sequences. (In fact I believe that count should be O(1).)

Ok, I see the point you're trying to get at. Though I'm not entirely convinced, that seqs and data structures should be that much bifurcated. After all seqs _are_ data structures + possible laziness. 

I agree that seq should only be called if the result is used as a sequence, but I also do think it's OK to call collection/data-structure functions on seqs. There are even optimizations for that:

e.g. (count (seq [1 2 3])) is O(1): https://github.com/clojure/clojure/blob/1428d43c9a5f9d0e7e89a55707868df76c69d549/src/jvm/clojure/lang/APersistentVector.java#L444

[Philip Potter]

In fact, the way that count works on ISeqs is rather roundabout -- it
only works because all implementations of ISeq in clojure.jar also
happen to implement java.util.List, so count calls Collection.size().
In theory, some user-provided ISeq which didn't implement List would
not respond to count.

It's probably a good idea for interop reasons to have seqs implement
the java collection types, but I don't feel too happy about clojure
code which uses the java Collection interface on seqs.

Phil

[Timothy Baldridge]

>> In fact, the way that count works on ISeqs is rather roundabout -- it
only works because all implementations of ISeq in clojure.jar also
happen to implement java.util.List, so count calls Collection.size().
In theory, some user-provided ISeq which didn't implement List would
not respond to count.

------

That is just completely untrue: 

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L536
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L826

Timothy

[Philip Potter]

On 13 May 2013 17:30, Timothy Baldridge <tbald...@gmail.com> wrote:
>>> In fact, the way that count works on ISeqs is rather roundabout -- it
> only works because all implementations of ISeq in clojure.jar also
> happen to implement java.util.List, so count calls Collection.size().
> In theory, some user-provided ISeq which didn't implement List would
> not respond to count.
>

> ------
>
> That is just completely untrue:
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L536
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L826

Thanks for the correction.

I had read this code before and I read it again and couldn't see any
mistake, until I looked at ISeq and realized it implements
IPersistentCollection. That came as a surprise to me.

I guess I'm used to treating seqs and colls as very separate ideas
that I simply didn't expect that ISeq would implement
IPersistentCollection.

Phil

[Timothy Baldridge]

Why shouldn't that be the case? A seq is a collection of data. And it's immutable, why would it bein its own category of collections?

Timothy

[Mike Thvedt]

In regards to the allocation objection--how often are you calling seq millions of times on something that's not already a seq? In re using count instead of seq, a lazy seq's count might be arbitrarily expensive to calculate and might not be able to tell if it's empty without realizing its head.

[Cedric Greevey]

To that excellent analysis I would add that, if you're going to iterate through a whole collection, it's much more efficient to call seq on it at the outset, and then use (next s) to progress through the seq; (next s) returns nil when there are no more elements, and is semantically equivalent to (seq (rest s)) but much more efficient (both in characters of source code and at runtime).

On Sun, May 26, 2013 at 6:47 AM, Alex L. <alexand...@gmail.com> wrote:

Hello,

I just wanted to share the following piece from The Joy of Clojure, Chapter 3, page 45, since I found it interesting and it might be valuable to the thread:

3.2

Nil pun with care

Because empty collections act like true in Boolean contexts, we need an idiom for

testing whether there’s anything in a collection to process. Thankfully, Clojure pro­

vides just such a technique:

(seq [1 2 3])

;=> (1 2 3)

(seq [])

;=> nil

The seq function returns a sequence view of a collection, or nil if the collection is

empty. In a language like Common Lisp, an empty list acts as a false value and can be

used as a pun (a term with the same behavior) for such in determining a looping ter­

mination. As you saw in section 2.3, Clojure’s empty sequences are instead truthy, and

therefore to use one as a pun for falsity will lead to heartache and despair. One solu­

tion that might come to mind is to use empty? in the test, leading to the awkward

phrase (when-not (empty? s) ...). Though it would work, this isn’t idiomatic. A

better solution would be to use seq as a termination condition, as in the following

function print-seq:

(defn print-seq [s]

  (when (seq s)

    (prn (first s))

(recur (rest s))))

(print-seq [1 2])

; 1

; 2

;=> nil

(print-seq [])

;=> nil

There are a number of points to take away from this example. First, the use of seq as a

terminating condition is the idiomatic way to test whether a sequence is empty. If we

tested just s instead of (seq s), then the terminating condition wouldn’t occur even

for empty collections, leading to an infinite loop.

Regards,

Alexander

[Brian Marick]

On May 26, 2013, at 5:47 AM, "Alex L." <alexand...@gmail.com> wrote:
> First, the use of seq as a
> terminating condition is the idiomatic way to test whether a sequence is empty.

In natural languages, idioms change. Sometimes it's to the despair of purists: for example, I've had to accept that "hopefully" at the beginning of a sentence doesn't act as an adverb:

Hopefully, he will ascend to a higher plane.
Having consumed the HOPE1 drug, he will hopefully ascend to a higher plane.

The same is true of programming languages. When I was programming on the PDP-11, it was idiomatic to use pre-increment instead of post-increment when either would do:

for (i=0; i<N; ++i) … /* right */
for (i=0; i<N; i++) … /* wrong */

That was because the former compiled into one machine language instruction, but the latter required two. PDP-11s were slow, so it could matter.

There exists in 2013 a person who, in a code review, insists that every post-increment be changed to a pre-increment, even though (1) compilers are way smarter than they were in 1981, (2) computers are way faster too, and (3) insisting on a stylistic point only relevant in the distant past is the sign of a mind past its sell-by date. I've met that person.

There is no one who understands `(if (seq thing)` who wouldn't understand
`(if (not (empty? thing))` or, better, `(if (not-empty? thing)`. The converse is not true. That suggests that the latter should be the idiom, given that the difference between them is as consequential as the difference between `++i` and `i++`.

It's fun to make use of esoterica like `seq`'s behavior with an empty list. Back in the early days, it was necessary. Witness Guy Steele's StrangeLoop talk that began with the need to get a program to fit onto a single punched card. And language implementors still need to care about those things.

But, for the rest of us, the necessity has drained out of that kind of esoterica. It's now more of a shibboleth, a way to identify yourself as one of the tribe. That's actually tolerable human behavior, but those who indulge in it shouldn't feel *smug*. Rather, the opposite.

--------
Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

[Alexander L.]

I really liked your take on this Brian. You kinda convinced me to use (if (not-empty? foo)) from now on :)

Alexander

[Armando Blancas]

There is no one who understands `(if (seq thing)` who wouldn't understand
`(if (not (empty? thing))` or, better, `(if (not-empty? thing)`. The converse is not true. That suggests that the latter should be the idiom

No, it doesn't. That simply illustrates that idioms must be learned, as in any kind of language.

 

But, for the rest of us,

I don't believe you speak for the rest of us. Not for me, anyway.

[Brian Marick]

On May 27, 2013, at 1:38 PM, Armando Blancas <abm2...@gmail.com> wrote:

>> It's fun to make use of esoterica like `seq`'s behavior with an empty list. Back in the early days, it was necessary. [2 examples]

>>
>> But, for the rest of us, the necessity has drained out of that kind of esoterica.
>

> I don't believe you speak for the rest of us. Not for me, anyway.

So, for you, it is *necessary* that you use `seq` instead of `not-empty`. That is, there is some way in which your applications, or your life, would be worse if you used the latter - a way that is different than just "it's the way my gang does it". I'd be happy to convinced there's a difference, as I'd learn something new. What is that difference?