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 stuart.hallo...@gmail.com wrote:
Useful? Am I crazy? (Not mutually exclusive.)
I'm inclined to think both. :-)
I think that a
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-reduce
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
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
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
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
