Names for general merge tactics in Data.Map

David Feuer david.feuer at gmail.com
Sun Aug 21 03:20:13 UTC 2016


Argh! It probably actually is possible to emulate generalMergeA using
mergeWithKey, although it won't be pretty. I'll see if I can work up a
compat package in case someone needs one, but that probably won't happen
before the next containers release.

On Aug 20, 2016 3:19 PM, "David Feuer" <david.feuer at gmail.com> wrote:

> 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 henning-thielemann.de> wrote:
>
>>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160820/172dc657/attachment.html>


More information about the Libraries mailing list