Re: Proposal: keep Data.Map.foldWithKey

Am 15.12.2010 15:44, schrieb Johan Tibell:

On Wed, Dec 15, 2010 at 10:57 AM, Christian Maeder wrote:

...

It is the right answer as long as fold{l,r}WithKey are missing in Data.IntMap.

I don't see why being halfway towards a desired state should make us want to go back to the previous state.

{starting point} -> {we are here} -> {here's where we want to be}

because "{we are here}" does not allow to change the import from Data.Map to Data.IntMap for "foldrWithKey".

it seems it would be more work to first revert to the previous state and then make a proposal to move to the final state (where Map and IntMap are symmetric) than to just move to the final state from where we are today.

my proposed change (to the current state) is quite minimal and only irons out the above "halfway" problem.

...

I'm in favour of adding fold{l,r}WithKey to Data.IntMap and then deprecating both foldWithKey functions in one go!

In fact, this should have been happened. (Yet, there is no library proposal for this.)

I didn't need it at the time so I didn't go ahead an made that change. I don't make the change now because I don't feel like participating in the libraries process as I think I could provide more value by writing code and upload it to github/Hackage than by discussing on the libraries list.

...

I simply dislike the destroyed symmetry in the 4 container modules and deprecating a single function.

I can appreciate that. The reason that particular function got singled out was that it was already deprecated (in the documentation).

There's no dissent about the deprecation, only about "when". Christian

Johan