Hi Dave,
thanks for pointing out the containsKey bug! I had it fixed locally
and the (comment ...) at the top was written & tested with the fix in
place, but for some reason I left the old version in the Gist... fixed
now.
If merge & merge-with were to coexist with a new "merge-with*" /
"merge-re
Hi Stuart,
I agree that the main problem here should be solved at the
merge(-with) level. A couple of thoughts on this issue:
On 8 July 2010 21:16, Stuart Halloway wrote:
> Useful? Am I crazy? (Not mutually exclusive.)
I'm inclined to think both. :-)
I think that a "merge-reduce" function woul
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
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 du
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 oth
