Proposal: keep Data.Map.foldWithKey

Christian Maeder Christian.Maeder at dfki.de
Fri Jan 14 11:27:58 CET 2011


Am 14.01.2011 11:13, schrieb Gregory Collins:
> On Fri, Jan 14, 2011 at 8:56 AM, Sittampalam, Ganesh
> <ganesh.sittampalam at credit-suisse.com> wrote:
>> This isn't aimed at you specifically, but I suggest that if someone
>> objects to a proposal on the grounds that an alternative route is
>> better, they should actually propose that so that we can have a proper
>> debate between the alternatives.
> 
> I agree. Patch attached.

This patch

+            , foldlWithKey
+            , foldrWithKey
+            , foldlWithKey'
+            , foldrWithKey'

is definitely a much bigger API change (than removing a deprecation)
that should only be applied for a new major release.

I support these additions but it is not part of my proposal.

> Side note: there are tons of long lines and lines with dangling
> whitespace in these files. It could use a cleanup. I also fixed the
> docstrings for Data.Map.foldlWithKey and Data.Map.foldrWithKey.
> 
> 
>> Removing foldWithKey from IntMap would (arguably) require foldrWithKey
>> and foldlWithKey to be exposed instead. It seems Milan raised this in
>> http://www.haskell.org/pipermail/libraries/2010-September/014410.html
>> and there was no objection, but nothing further was done.
> 
> So symmetry (assuming one agrees it's so important to have it in the
> first place) is still broken anyways if we roll back the "foldWithKey"
> deprecation?

Yes, the symmetry is still broken because "foldWithKey" will be
deprecated in Data.Map but not in Data.IntMap, yet.

If Data.IntMap.foldWithKey is immediately deprecated, too, and users
follow this deprecation advice they can no longer compile their sources
with "older" compiler (where "old" means ghc-7.0.1).

C.



More information about the Libraries mailing list