select-keys on nil map

Fri, 01 Aug 2025 14:42:56 +0000

I know that https://ask.clojure.org/index.php/1913/use-transients-with-select-keys-if-possible exists to optimize select-keys for many keys, but I noticed that it does a lot of work even if the original map is nil. Would there be interest in a patch that returns an empty map when given nil? Something like:

(defn select-keys*
  "Returns a map containing only those entries in map whose key is in keys"
  {:added "1.0"
   :static true}
  [map keyseq]
  (if map
    (loop [ret {} keys (seq keyseq)]
      (if keys
        (let [entry (. clojure.lang.RT (find map (first keys)))]
          (recur
           (if entry
             (conj ret entry)
             ret)
           (next keys)))
        (with-meta ret (meta map))))
    {}))

Could we expose the data behind ranges?

Sat, 10 Jul 2021 12:45:09 +0000

dtype-next, libpython-clj, and tech.ml.dataset all assign special meaning to ranges but they often have to deconstruct them to do so. For libpython, we create actual python ranges in some cases. For dtype-next and friends, a range with increment of 1 may indicate a sub-buffer operation as opposed to an indexed-buffer operation -- sub-buffer retains the ability for System/arraycopy and the like to work correctly and is thus a major optimization in some cases.

I would like to be able to get the start, step, and end (when it exists) from any object created via clojure.core/range. I can currently do this via reflection or via subtraction of the first and second members of the sequence generated via the range along with count but I think it may be a safe and reasonable change to be able to query this information directly.

Most of this could be achieved by simply making the members start, step, and end members of LongRange and Range public as they are already final.

As a separate discussion it may be worth considering having finite ranges work like persistent vectors. I don't want to confuse the above point with this one but it sometimes more efficient to index into ranges via nth or an IFn invoke pathway than it is to use Clojure's sequence abstraction. Finite ranges are logically to me more like persistent vectors in nature and potentially they could behave precisely like persistent vectors including w/r/t hashcode, deriving from java.util.RandomAccess, and having conj produce either a new range or a persistent vector depending on if the value fits properly in the sequence.

Clojure Q&A - Questions without answers in Collections

select-keys on nil map

Could we expose the data behind ranges?