Proposal: keep Data.Map.foldWithKey

[Christian Maeder]

Hi,

it's time to come to a conclusion for this proposal. Two votes are
currently against and basically just mine for it.

Q: So why do I think it is unfortunate?

A:
1. Because globally replacing foldWithKey by foldrWithKey will not work
if you also use Data.IntMap. So, the symmetry to the twin-module
Data.IntMap is lost.

2. The same deprecation procedure for Data.IntMap can only start after
two major release from the current one (ghc-7.0) that does not allow
further API changes. Major release ghc-7.2 is needed to add foldrWithKey
to Data.IntMap and deprecation can follow in major release ghc-7.4. So
foldWithKey can be finally deleted in ghc-7.6.

Q: Why do I think it is urgent?

1. It is the easiest and fastest way to re-establish the symmetry
between Data.Map and Data.IntMap. If we don't do it now, we'll have skew
Data.Map and Data.IntMap modules for the next couple of major releases.

2. Therefore it should also not go as is into the next haskell platform
(that'll soon come out).

I regard the removal of the deprecation warning not as an API change of
ghc-7.0. If you do then please regard the deprecation for ghc-7.0.1 as
an accidental bug to be fixed for ghc-7.0.2.

Seeing
http://www.haskell.org/pipermail/libraries/2010-September/014161.html
I wonder why "fold" was not deprecated together with "foldWithKey".
Therefore I conclude that the decision to deprecate just "foldWithKey"
was more or less an accident.

So why do we deprecated just a single name that we do not get rid of
soon anyway and confuse users that rightly expect consistent (Data.Map
and Data.IntMap) APIs?

Asking for support again (or withdrawals of "no"s)
Christian

Am 14.12.2010 13:28, schrieb Christian Maeder:
> Hi,
> 
> I've now created a proper library proposal to keep Data.Map.foldWithKey.
> Exchange arguments and make up your mind until Jan. 15th.
> 
> http://hackage.haskell.org/trac/ghc/ticket/4842
> 
> Cheers Christian