I can see the points being made, and now I'm also thinking that accepting
infinite sequences wouldn't always work, for example if the infinite
sequence wouldn't contain one of the elements of one of the other
sequences, like:
(clojure.set/intersection #{1 2} (drop 10 (range)))
And I'm not sure it would be acceptable for a function that accepts
sequences to hang depending on the input.
Which also makes me wonder: shouldn't intersection throw a "cannot be cast
to clojure.lang.IPersistentSet" when called with (range), rather than
consume all memory and crash the jvm ?
I still think though that accepting sequences rather then sets could be
worth consideration for other reasons:
- vectors would just work without having to call set on them:
(clojure.set/intersection
[2 3 4] [4 5 6]) (I think duplicate elements shouldn't cause problems)
- it would also work on maps
- sets can be treated as sequences, and operating on sequences whenever
possible is very idiomatic in Clojure
- no previous code would be broken, neither should performance decrease and
maybe increase by removing the calls to count
- the doc would simply change to "Returns a set with the elements in common
between the input seqs."
- the implementation would call contains? if the sequence is a set, for
performance reasons, and would call (some #{el} seq) otherwise
--
--
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
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
