Proposal: keep Data.Map.foldWithKey

[Christian Maeder]

Am 15.12.2010 15:44, schrieb Johan Tibell:
> On Wed, Dec 15, 2010 at 10:57 AM, Christian Maeder
> <Christian.Maeder at dfki.de> 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