Fork me on GitHub

(instance? clojure.lang.IPersistentStack (clojure.lang.PersistentQueue/EMPTY)) returns true. Isn't this a bug, because peek and pop aren't doing the right thing according to the stack's interface?


It does seem a bit odd to me.


The method names and signatures are the same for lists and queues, of course, which is probably why it was coded this way.


(Note: I have never asked this question of anyone who actually wrote the code and/or knew if there was a deeper reason to make that class arrangement as it is, other than common method names and signatures.)


Given that (a) the core team strongly desires to maintain backwards compatibility with earlier Clojure releases and (b) PersistentQueue is less used than most other kinds of Clojure collections, and (c) When PersistentQueue is used, it seems unlikely that many people would use the result of (instance? clojure.lang.IPersistentStack foo) to determine the behavior of their code, it seems unlikely to change.


But if you want a more authoritative answer than mine, you could try asking your question on


by the way clojure.lang.PersistentQueue/EMPTY is a static value, not a function or method, parenthesizing it works for the same reason (Math/PI) does - it's an incidental feature of how interop forms are expanded


@U883WCP5Z what definition of the interface are you going by? there's no commentary in the code for the interface


PersistentQueue extends PersistentList, and PersistentList extends IPersistentStack, IIRC


both PersistentList and IPersistentList implement IPersistentStack, PersistentQueue extends IPersistentList

(ins)user=> (contains? (supers clojure.lang.PersistentList) clojure.lang.IPersistentStack)
(ins)user=> (contains? (supers clojure.lang.PersistentQueue) clojure.lang.PersistentList)
(ins)user=> (contains? (supers clojure.lang.PersistentQueue) clojure.lang.IPersistentList)
(ins)user=> (contains? (supers clojure.lang.IPersistentList) clojure.lang.IPersistentStack)


Doing todays advent of code, I'm in a situation where I have

[{"start "A"} {"start "b"} {"A" "b"} {"A" "c"} {"A" "end"}]
Is their a way I can merge those into one map where I get a vector for the value i.e.
{"start" ["A" "b"]
 "A" ["b" "c" "end"]}
? I thought merge, but I'm unclear. Also tried merge-with conj but that didn't work either. Also tried group-by key


merge-with is indeed the answer, but you need to flip the parameters, take a better look at the docstring (nevermind, you've edited your message, it's ok now)

👍 1
Andrew Byala17:12:03

If some-fn is like an aggregate or and every-pred is an aggregate and, is there any function like no-pred or not-any-fn that I'm not seeing? Or do I just use (not (some-fn p1 p2...))?

Andrew Byala18:12:32

I thought not-any applies a single predicate to all elements in a collection. How would I use it to apply multiple predicates to a single value? • (map (partial (some-fn odd? neg-int?)) [-2 -1 1 2]) returns (true true true false)(map (partial (every-pred odd? neg-int?)) [-2 -1 1 2]) returns (false true false false)(map (partial (complement (some-fn odd? neg-int?))) [-2 -1 1 2]) returns (false false false true) <-- I don't see how to use not-any here.

Sam Ritchie19:12:39

(Comp complement some-fn) perhaps?

👍 1
Ben Sless19:12:03

I remember there being a Jira or ask issue about generalized function combinators

Andrew Byala19:12:12

You're right, @sritchie09, that the following works, but I don't think it's worth it. 🙂(map (partial ((comp complement some-fn) odd? neg-int?)) [-2 -1 1 2]) returns (false false false true)


Are you sure you need the partial?

Tero Matinlassi20:12:50

Or just (def no-pred (comp complement some-fn)) and then use that…?

Sam Ritchie23:12:51

Yup that's what I was suggesting!

Sam Ritchie02:12:43

@U01HHBJ56J1 partial is not doing anything here btw


So I have a map of maps, I want to assoc a new key into the submaps, but something like (map #(assoc % new-key new-value) the-map) says "assoc needs integer for Key"


Oh I think I see what I'm doing wrong. Need to provide a key to assoc to


Mapping over a map is mapping over key value pairs and it seems like vectors at this point. You can assoc on vectors but understandably an index is the key


So mapping over a map is actually mapping over key-value vector


will have to tuck that away into the ol' brain machine


Alright, feelin' like a total newb

(def om {"bob" {:name "bob"
                 :age 21
                 :hobbies "fuudbaal"}
          "jill" {:name "jill"
                  :age 33
                  :hobbies "hotness"}
          "rhona" {:name "rhona"
                   :age 26
                   :hobbies "surfing"}})
 (fn [m [k v]]
   (assoc-in m [k :email-verified?] false))
Trying to add an email-verified? key to each submap


@sova use reduce-kv instead of map.