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 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
http://treeowl-containers-general-merge.bitballoon.com/data- 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] https://github.com/conal/total-map/pull/3/commits/09109b7a04 5ffea75e50793a690bd9db4512d540
[2] https://github.com/conal/total-map/pull/5/commits/6fd1cc7b9b ef666a69b2d02de36ff9e98c55cd4b
[3] http://hub.darcs.net/thielema/comfort-graph/browse/src/Data/ Graph/Comfort/Map.hs#28