Names for general merge tactics in Data.Map

David Feuer david.feuer at
Sat Aug 20 19:19:42 UTC 2016

As for a compatibility package, I believe that should be possible. I don't
think mergeWithKey can implement generalMergeA, but I'm pretty sure it can
be written using splitRoot. I'm not personally very interested in writing
this shim, especially since it would only be really useful for packages
using both generalMerge and the GHC API, but I may get around to it at some
point if no one else does it first.

I think you may be right about the name merge rather than generalMerge; if
others agree I'll use that name.

On Aug 20, 2016 3:40 AM, "Henning Thielemann" <lemming at>

> On Thu, 18 Aug 2016, David Feuer wrote:
> I realized that it would probably be helpful to put up the actual
>> documentation for the proposed functions. This can be found at
>> map-lazy-merge
> The description of 'generalMerge' mentions diffPreserve, diffDrop,
> diffMapWithKey, but they are not shown in the Haddock page.
> Since there are pretty many functions around 'generalMerge' I would keep
> that stuff in one module and also rename 'generalMerge' to 'merge' because
> the new module provides enough distinction from Data.Map.mergeWithKey.
> Your solution looks pretty elegant to me but for a definitive judgement I
> would like to test it in real applications first. I remember some actual
> and potential uses of 'mergeWithKey' in my code. [1][2][3] It is
> unfortunate that depending on a newer version of containers also forces me
> to depend on new GHC versions. Could you provide the Merge modules in a
> separate package, say containers-merge or containers-compat? Would it be
> possible to implement the Merge modules using the existing mergeWithKey
> function?
> [1]
> 5ffea75e50793a690bd9db4512d540
> [2]
> ef666a69b2d02de36ff9e98c55cd4b
> [3]
> Graph/Comfort/Map.hs#28
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list