zipmap-with-merge sounds a lot like merge-with, you might want to check
that out. It's also perfectly acceptable to call merge-with with a sequence
of one-entry maps, that gives you what you were suggesting.
On Fri, Jul 29, 2016 at 3:15 PM Daniel Dinnyes wrote:
> Wow, thanks for that, actually t
Wow, thanks for that, actually that looks pretty cool. I haven't thought
about that. Are there any drawbacks / cons of doing that?
I was actually wrong about distinct, it seems it doesn't change the order,
but I am not sure it happens by accident, or it is an intended behavior. It
seems to keep
Distinct on the input values wouldn't solve your problems, as the entries
are indeed distinct even with repeated keys. Calling 'distinct' on the
input keys is about the same cost as building up a map, since it internally
uses a set that is backed by a map ;-), but you seem to be more concerned
abo
Actually, on second thought:
Doing a distinct on the input values is definitely not acceptable, both for
performance, and for behavior as it potentially changes the order of the
pairing of elements.
OTOH, in real life zipmap would be rarely used with the intention to define
the same key multip
Hi All,
This post is just to mention my recent experience with one of the
clojure.core/zipmap, by witch I was burned badly recently. Consider the
following example code
(def ks [:a :b :c :d :e :f :b :c :d])
(def m (zipmap ks (range)))
(get m :b)
> 6
Of course the "ks" in my case was like 10
