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 <dinny...@gmail.com> wrote:
> 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 the order of the first appearance of the each element in the
> seq:
>
> (distinct [1 2 3 4 4 3 2 1 0 0])
> >(1 2 3 4 0)
>
> Another idea which came to mind: if zipmap would take an extra optional
> argument called merge (which takes a function), it could be reflected in
> the docstring as well, it would be quite good in itself to raise awareness
> of the possibility of having keys appearing multiple times in the input
> sequence, while also giving some extra features and use-cases. like someone
> could just add a function to merge which just throws an exception or logs a
> warning with my logging library of choice, or conjoin the values in a list
> or set, etc.
>
>
>
> On Friday, 29 July 2016 17:56:20 UTC+1, Gary Trakhman wrote:
>
>> 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
>> about the order of overriding, expecting the first value to when, when the
>> behavior of zipmap and things like 'into' is 'as if by repeated conj', in
>> other words, last wins. If you are concerned about keys overriding, there
>> is an alternative with map literals and 'apply hash-map', so you can do
>> your zipping without zipmap, then apply it to a hash-map call.
>>
>> > (hash-map :a 1 :a 2)
>> java.lang.IllegalArgumentException: Duplicate key: :a
>>
>> > (defn my-zipmap [s1 s2] (apply hash-map (interleave s1 s2)))
>> #'sandbox10223/my-zipmap
>> > (my-zipmap [:a :b :c] (range))
>> {:a 0, :c 2, :b 1}
>> > (my-zipmap [:a :b :a] (range))
>> java.lang.IllegalArgumentException: Duplicate key: :a
>>
>>
>>
>> On Fri, Jul 29, 2016 at 12:33 PM Daniel Dinnyes <dinn...@gmail.com>
>> wrote:
>>
> 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 multiple times. It would be definitely a human-friendly
>>> addition to log some warning when a key is to be defined multiple times,
>>> especially if it can avoid impact on performance.
>>>
>>> Cheers,
>>> D.
>>>
>>>
>>> On Friday, 29 July 2016 17:07:14 UTC+1, Daniel Dinnyes wrote:
>>>>
>>>> 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 100-and-something names, which I
>>>> didn't notice got concatenated twice by accident. Alright I accept, it was
>>>> a ridiculously stupid mistake, but finding out what went wrong was
>>>> definitely not straightforward (kind of questioning your sanity feeling)...
>>>> I had to grab a friend for some "second pair of eyes" and her immediate
>>>> reaction was "(= (count (distinct ks)) (count ks))", and said there you go.
>>>>
>>>> Not sure if there is anything which could be improved on the docstring,
>>>> or the behavior. Maybe if the docstring has put a tiny bit more emphasis on
>>>> the implementation details: that it's going to be a reduce over the
>>>> key-value pairs into an empty map, that would have triggered the "aha"
>>>> moment for me.
>>>>
>>>> Anyways, I am not claiming there is something to be improved / changed
>>>> here, especially without affecting performance. This is just "for the
>>>> record" / "future reference".
>>>>
>>>> Cheers,
>>>>
>>>> D.
>>>>
>>> --
>>> 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/d/optout.
>>>
>> --
> 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/d/optout.
>
--
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/d/optout.
