Hi Dave,
Yes, merge-reduce is the name I like too.
Stu
> 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
--
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
