Hi Michal,
I needed to change your containsKey implementation to always return
true in order to support the merge-with use case.

Hi Stu,
merge-with* seems like a useful addition, though its semantics differ
slightly from merge-with's.  The original merge-with modifies the vals
only if there are duplicate keys.  Perhaps call it merge-reduce?

For what it's worth, when I had this particular problem, I only wanted
duplicates vector-ized.  I used a non-trivial merge function:
(let [merge-fn (fn [result latter]
                 (if (vector? result)
                   (conj result latter)
                   [result latter]))]
  (merge-with merge-fn {:a 1} {:a 2} {:a 3 :b 1}))
;{:b 1, :a [1 2 3]}


On Thu, Jul 8, 2010 at 3:16 PM, Stuart Halloway
<stuart.hallo...@gmail.com> wrote:
> Hi Michał,
>
> The underlying problem (using merge-with plus an accumulating fn) has come up 
> before on the list. One proposal was a variant of merge-with that always 
> applies the merge function [1].
>
> I think the underlying issue needs to be solved at merge-with, not at the map 
> data structure. In other words, why isn't merge-with like reduce, with a 
> second variant taking an initial seed value [2]?
>
> Useful? Am I crazy? (Not mutually exclusive.)
>
> Stu
>
> [1] 
> http://groups.google.com/group/clojure/browse_thread/thread/b8a5195439c7b435
> [2] http://gist.github.com/468449
>
>> Hi Group,
>>
>> I've just written an implementation of a persistent map which provides
>> a default value -- fixed at creation time the way it's currently
>> implemented -- and claims that it .containsKey every key thrown at it.
>> The code is here:
>>
>> http://gist.github.com/468332
>>
>> As mentioned in a comment, the small parts which aren't entirely
>> trivial are taken more or less directly from emit-defrecord (minus its
>> generic nature).
>>
>> My primary purpose was to devise a helper map type for use with
>> merge-with, so that I can say
>>
>> (merge-with conj (DefaultMap. [] {}) {:a 1} {:a 2} {:a 3})
>>
>> and get back
>>
>> {:a [1 2 3]}
>>
>> Any comments? In particular, do the implementations of hashCode,
>> equals and getLookupThunk look alright?
>>
>> Sincerely,
>> Michał
>>
>> --
>> 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 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 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

Reply via email to