Proposal: keep Data.Map.foldWithKey

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

My vote on this would be "no", Milan was right to deprecate this
crufty function.
G
On Tue, Dec 14, 2010 at 1:28 PM, 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
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
--
Gregory Collins

On Tue, Dec 14, 2010 at 01:28:14PM +0100, Christian Maeder wrote:
I've now created a proper library proposal to keep Data.Map.foldWithKey.
In the ticket you say: [keep] Data.Map.foldWithKey as the aim to finally remove this function is bad as long as Data.IntMap.foldWithKey is the primary folding function for the specialized maps. but why is keeping foldWithKey the right answer, rather than adding fold{l,r}WithKey to Data.IntMap (and removing foldWithKey from it)? Thanks Ian

Am 14.12.2010 18:42, schrieb Ian Lynagh:
On Tue, Dec 14, 2010 at 01:28:14PM +0100, Christian Maeder wrote:
I've now created a proper library proposal to keep Data.Map.foldWithKey.
In the ticket you say:
[keep] Data.Map.foldWithKey as the aim to finally remove this function is bad as long as Data.IntMap.foldWithKey is the primary folding function for the specialized maps.
but why is keeping foldWithKey the right answer, rather than adding fold{l,r}WithKey to Data.IntMap (and removing foldWithKey from it)?
It is the right answer as long as fold{l,r}WithKey are missing in Data.IntMap. 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.) Maybe it is even a good idea to add foldr and foldl functions to Data.{Set,IntSet,Map,IntMap} first and deprecate also the plain fold functions. And maybe toList (and assocs) should be deprecated in favour of toAscList, toDescList. I simply dislike the destroyed symmetry in the 4 container modules and deprecating a single function. Christian
Thanks Ian

On Wed, Dec 15, 2010 at 10:57 AM, Christian Maeder
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} 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.
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). Johan

Johan Tibell wrote:
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}
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.
But we don't have a proposal for "where we want to be", so if "we are here" is worse than "starting point", we should consider what the prospects of that other proposal materialising are. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

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

Am 14.12.2010 18:42, schrieb Ian Lynagh:
On Tue, Dec 14, 2010 at 01:28:14PM +0100, Christian Maeder wrote:
I've now created a proper library proposal to keep Data.Map.foldWithKey.
In the ticket you say:
[keep] Data.Map.foldWithKey as the aim to finally remove this function is bad as long as Data.IntMap.foldWithKey is the primary folding function for the specialized maps.
but why is keeping foldWithKey the right answer, rather than adding fold{l,r}WithKey to Data.IntMap (and removing foldWithKey from it)?
If Data.IntMap.foldWithKey is removed, code for ghc-6.12. would break. I see an urgent need to re-establish the symmetry between Data.Map and Data.IntMap. (Deprecation can wait for the next major ghc release.) Christian

Hi all,
On Tue, Dec 14, 2010 at 1:28 PM, Christian Maeder
I've now created a proper library proposal to keep Data.Map.foldWithKey. Exchange arguments and make up your mind until Jan. 15th.
My vote is "no", there are already too many fold variants in Data.Map. We have {left,right} x {non-strict,strict} x {with key, without key} = 8 combinations together. Adding back the "directionless" version would mean another 4 versions of we want symmetry. This in a module that already has 150 functions. We need to do something about the large amount of both API (i.e. usability tax) and implementation (maintainer overhead) duplication in the containers library. Throwing out functions that don't add much to expressibility* only gets us so far, but I think it's a step in the right direction. * I appreciate that being able to use a "directionless" fold lets the author communicate his intent slightly better, but I think it's outweighed by the API growth and code duplication. Johan

Am 15.12.2010 15:38, schrieb Johan Tibell:
Hi all,
On Tue, Dec 14, 2010 at 1:28 PM, Christian Maeder
wrote: I've now created a proper library proposal to keep Data.Map.foldWithKey. Exchange arguments and make up your mind until Jan. 15th.
My vote is "no", there are already too many fold variants in Data.Map. We have
{left,right} x {non-strict,strict} x {with key, without key} = 8 combinations together.
Currently only two of these 8 are visible and a third foldlWithKey' is commented out. Is there a demand for the strict variants (to be expressed by a proposal)? It would need some more documentation to choose the right version. foldr' is also missing for list probably because foldr is not tail recursive. Control.Monad.foldM is also only a left version (and I do not propose to add foldrM and foldlM and deprecate foldM later). For the "without key" variants I see no need. Omitting an unused first argument can be easily done using "const". foldx = foldxWithKey . const (Maybe "foldxWithKey" should have been named just "foldx" in the first place.)
Adding back the "directionless" version would mean another 4 versions of we want symmetry. This in a module that already has 150 functions.
My count of exported names is 97 (via ":browse Data.Map" inside ghci) Cheers Christian
We need to do something about the large amount of both API (i.e. usability tax) and implementation (maintainer overhead) duplication in the containers library. Throwing out functions that don't add much to expressibility* only gets us so far, but I think it's a step in the right direction.
* I appreciate that being able to use a "directionless" fold lets the author communicate his intent slightly better, but I think it's outweighed by the API growth and code duplication.
Johan

Am 16.12.2010 12:35, schrieb Christian Maeder:
For the "without key" variants I see no need.
Omitting an unused first argument can be easily done using "const".
foldx = foldxWithKey . const
This does not apply to foldlWithKey, though. C.

Am 16.12.2010 12:35, schrieb Christian Maeder:
Am 15.12.2010 15:38, schrieb Johan Tibell:
Hi all,
On Tue, Dec 14, 2010 at 1:28 PM, Christian Maeder
wrote: I've now created a proper library proposal to keep Data.Map.foldWithKey. Exchange arguments and make up your mind until Jan. 15th.
My vote is "no", there are already too many fold variants in Data.Map. We have
{left,right} x {non-strict,strict} x {with key, without key} = 8 combinations together.
Currently only two of these 8 are visible and a third foldlWithKey' is commented out. Is there a demand for the strict variants (to be expressed by a proposal)? It would need some more documentation to choose the right version.
Sorry, I've looked into the old containers-0.3.0.0 version. So the release notes are also not accurate. foldrWithKey' was added, too. http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.html 1.5.10.7. containers * Version number 0.4.0.0 (was 0.3.0.0) * Strictness is now more consistent, with containers being strict in their elements even in singleton cases. * There is a new function insertLookupWithKey' in Data.Map. * The foldWithKey function in Data.Map has been deprecated in favour of foldrWithKey. Christian
foldr' is also missing for list probably because foldr is not tail recursive. Control.Monad.foldM is also only a left version (and I do not propose to add foldrM and foldlM and deprecate foldM later).
For the "without key" variants I see no need.
Omitting an unused first argument can be easily done using "const".
foldx = foldxWithKey . const
(Maybe "foldxWithKey" should have been named just "foldx" in the first place.)
Adding back the "directionless" version would mean another 4 versions of we want symmetry. This in a module that already has 150 functions.
My count of exported names is 97 (via ":browse Data.Map" inside ghci)
Cheers Christian
We need to do something about the large amount of both API (i.e. usability tax) and implementation (maintainer overhead) duplication in the containers library. Throwing out functions that don't add much to expressibility* only gets us so far, but I think it's a step in the right direction.
* I appreciate that being able to use a "directionless" fold lets the author communicate his intent slightly better, but I think it's outweighed by the API growth and code duplication.
Johan

On Wed, Dec 15, 2010 at 03:38:37PM +0100, Johan Tibell wrote:
My vote is "no", there are already too many fold variants in Data.Map. We have
{left,right} x {non-strict,strict} x {with key, without key} = 8 combinations together.
Adding back the "directionless" version would mean another 4 versions of we want symmetry. This in a module that already has 150 functions.
We need to do something about the large amount of both API (i.e. usability tax) and implementation (maintainer overhead) duplication in the containers library.
Well, once you have withKeys :: Map k a -> Map k (k,a) withKeys = mapWithKey (,) and the Foldable instance, all those fold variants are redundant, as are all the WithKey variants.

On 16 December 2010 23:04, Ross Paterson
Well, once you have
 withKeys :: Map k a -> Map k (k,a)  withKeys = mapWithKey (,)
and the Foldable instance, all those fold variants are redundant, as are all the WithKey variants.
Not as efficient though, because using withKeys and then folding requires two traversals and allocates an intermediate map compared to just folding withKey. More broadly, I don't really see the argument for removing stuff from Data.Map. The code is already written and the core implementation of Data.Map is unlikely to change very much since Milan already confirmed it's almost optimal. So there doesn't seem to be a big maintainer burden to keeping the current interface. Is there some reason that maintaing Data.Map is more difficult than I expect? There may be a burden to the new user of Data.Map if they are overwhelmed by the sheer number of different functions (though this is not a problem I had personally), but that could be solved by having a Data.Map.Simple module or just reorganising the Haddock docs so the most commonly used functions appear first on the page. Is this not a better approach than breaking existing code by removing functionality? Cheers, Max

On Fri, Dec 17, 2010 at 8:45 AM, Max Bolingbroke
On 16 December 2010 23:04, Ross Paterson
wrote: Well, once you have
 withKeys :: Map k a -> Map k (k,a)  withKeys = mapWithKey (,)
and the Foldable instance, all those fold variants are redundant, as are all the WithKey variants.
Not as efficient though, because using withKeys and then folding requires two traversals and allocates an intermediate map compared to just folding withKey.
One could try to separate traversal from combining the elements using using toList and e.g. Data.List.foldl', assuming Data.List was implemented using stream fusion. I think this would be an interesting experiment to run.
More broadly, I don't really see the argument for removing stuff from Data.Map. The code is already written and the core implementation of Data.Map is unlikely to change very much since Milan already confirmed it's almost optimal. So there doesn't seem to be a big maintainer burden to keeping the current interface. Is there some reason that maintaing Data.Map is more difficult than I expect?
Actually there's more work to do on Data.Map (and the other modules as well). For example, the 6 adjust*, update*, and alter functions are all non-strict and thus mostly useless (i.e. you rarely want to leave thunks in the map.) To address this problem we would have to add strict versions of (some of them). I just noticed that we're missing strict folds as well (I thought we added those) so those need to be added as well. There are a bunch of other high-order functions that might need strict versions as well. Given that we have to add a load of function to make the API usable for e.g. keeping a simple map of strings to integer counters, I'd like to see if we can counterbalance that growth by removing something. There are a bunch of functions of dubious value (i.e. don't add expressiveness or performance). The old foldWithKey was one of them, but there are others such as findWithDefault, (!), etc. There's also an overhead in creating and running tests/benchmarks for all these functions.
There may be a burden to the new user of Data.Map if they are overwhelmed by the sheer number of different functions (though this is not a problem I had personally), but that could be solved by having a Data.Map.Simple module or just reorganising the Haddock docs so the most commonly used functions appear first on the page. Is this not a better approach than breaking existing code by removing functionality?
Perhaps, the Haddock docs could need an overhaul for sure. I don't argue for removing "functionality", just removing things from the API that don't really add any expressiveness or performance. Cheers, Johan

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

I support the proposal. -----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Christian Maeder Sent: 13 January 2011 19:12 To: Haskell Libraries Subject: Re: Proposal: keep Data.Map.foldWithKey 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
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Thu, Jan 13, 2011 at 8:12 PM, Christian Maeder
Asking for support again (or withdrawals of "no"s)
So if the vote/discussion doesn't go as you like, you bring it up
again until people are too tired to argue with you anymore?
Still no from me. My preferred resolution would be to remove
foldWithKey from Intmap also. And I point to this thread as an example
of the morass that is our current libraries process :(
G
--
Gregory Collins

Gregory Collins wrote:
On Thu, Jan 13, 2011 at 8:12 PM, Christian Maeder
wrote: Asking for support again (or withdrawals of "no"s)
So if the vote/discussion doesn't go as you like, you bring it up again until people are too tired to argue with you anymore?
Still no from me. My preferred resolution would be to remove foldWithKey from Intmap also. And I point to this thread as an example of the morass that is our current libraries process :(
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. 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. Previous to that there was apparently a patch in http://hackage.haskell.org/trac/ghc/ticket/3999 - it seems to have been proposed in http://www.haskell.org/pipermail/libraries/2010-April/013541.html without objections, but was never applied and I suspect the code has moved on enough that it can't just be applied as is any more. If we do nothing at all, then we have a situation that is (IMO) worse than either going back or going forwards. If noone wants to push through the changes that are needed to move forwards, we should go back until someone is ready. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Fri, Jan 14, 2011 at 8:56 AM, Sittampalam, Ganesh
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. 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?
G
--
Gregory Collins

Am 14.01.2011 11:13, schrieb Gregory Collins:
On Fri, Jan 14, 2011 at 8:56 AM, Sittampalam, Ganesh
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.

Am 14.01.2011 11:27, schrieb Christian Maeder:
Am 14.01.2011 11:13, schrieb Gregory Collins: [...] 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. [...]
In fact your proposed patch is part of the proposal http://hackage.haskell.org/trac/ghc/ticket/4313 that isn't closed yet, although discussion finished 23. July 2010. C.

Gregory Collins wrote:
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?
I guess the point is that there should be an acceptable subset of the API that is available for switching, and not having any "fold with key" operation in that subset is a bad thing. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Fri, Jan 14, 2011 at 11:13:31AM +0100, Gregory Collins wrote:
hunk ./Data/IntMap.hs 117 -- ** Fold , fold , foldWithKey + , foldlWithKey + , foldrWithKey + , foldlWithKey' + , foldrWithKey'
[...] +{-# DEPRECATED foldWithKey "Use foldrWithKey instead" #-}
The additions improve consistency between Data.Map and Data.IntMap, which is clearly the right thing to do. I also believe that deprecating the redundant foldWithKey in both modules is also a good first step toward trimming the redundancy from these APIs. I would also favour deprecating fold in all four modules in favour of Data.Foldable.foldr.

I wouldn't mind the additions even if committed for ghc-7.0.2, but can we please start deprecations a major release later (and revert the current spurious deprecation of Data.Map.foldWithKey). Christian Am 14.01.2011 12:07, schrieb Ross Paterson:
On Fri, Jan 14, 2011 at 11:13:31AM +0100, Gregory Collins wrote:
hunk ./Data/IntMap.hs 117 -- ** Fold , fold , foldWithKey + , foldlWithKey + , foldrWithKey + , foldlWithKey' + , foldrWithKey'
[...] +{-# DEPRECATED foldWithKey "Use foldrWithKey instead" #-}
The additions improve consistency between Data.Map and Data.IntMap, which is clearly the right thing to do.
I also believe that deprecating the redundant foldWithKey in both modules is also a good first step toward trimming the redundancy from these APIs. I would also favour deprecating fold in all four modules in favour of Data.Foldable.foldr.

On Fri, Jan 14, 2011 at 12:32:29PM +0100, Christian Maeder wrote:
I wouldn't mind the additions even if committed for ghc-7.0.2, but can we please start deprecations a major release later (and revert the current spurious deprecation of Data.Map.foldWithKey).
We can't do additions until 7.2 either. We're talking about deprecations for 7.2 and removals in 7.4. If we decide to do that, surely it would make sense for the deprecation of Data.Map.foldWithKey to stay in.

Hi Ross,
On Fri, Jan 14, 2011 at 12:48 PM, Ross Paterson
On Fri, Jan 14, 2011 at 12:32:29PM +0100, Christian Maeder wrote:
I wouldn't mind the additions even if committed for ghc-7.0.2, but can we please start deprecations a major release later (and revert the current spurious deprecation of Data.Map.foldWithKey).
We can't do additions until 7.2 either. Â We're talking about deprecations for 7.2 and removals in 7.4. Â If we decide to do that, surely it would make sense for the deprecation of Data.Map.foldWithKey to stay in.
Could you please clarify why containers cannot process (i.e. bump major/minor version numbers) independently of GHC. GHC can pick a version by the time of each release, but in between releases it seems fine for the library to be out of sync. I have two version of containers installed without problem. Johan

On Fri, Jan 14, 2011 at 12:56 PM, Johan Tibell
Could you please clarify why containers cannot process (i.e. bump major/minor version numbers) independently of GHC. GHC can pick a version by the time of each release, but in between releases it seems fine for the library to be out of sync. I have two version of containers installed without problem.
Not only that, but these additions and the deprecation are consistent with a minor version bump as per the package versioning policy: Quote:
A.B is known as the major version number, and C the minor version number. When a package is updated, the following rules govern how the version number must change relative to the previous version:
1. If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or instances were added or removed, then the new A.B must be greater than the previous A.B. Note that modifying imports or depending on a newer version of another package may cause extra instances to be exported and thus force a major version change.
2. Otherwise, if only new bindings, types, classes or modules (but see below) were added to the interface, then A.B may remain the same but the new C must be greater than the old C.
3. Otherwise, A.B.C may remain the same (other version components may change).
If you want to wait until 7.2, that's fine, but if I'm not mistaken
"foldWithKey" has already been deprecated in the GHC 7 release of
containers and so the horse has already left the barn.
G
--
Gregory Collins

Am 14.01.2011 12:48, schrieb Ross Paterson:
On Fri, Jan 14, 2011 at 12:32:29PM +0100, Christian Maeder wrote:
I wouldn't mind the additions even if committed for ghc-7.0.2, but can we please start deprecations a major release later (and revert the current spurious deprecation of Data.Map.foldWithKey).
We can't do additions until 7.2 either. We're talking about deprecations for 7.2 and removals in 7.4. If we decide to do that, surely it would make sense for the deprecation of Data.Map.foldWithKey to stay in.
The problem of adding a new function and deprecating an old one in the same release is, that sources modified according to the deprecation cannot be compiled with a previous compiler release. So we should be talking about deprecations in 7.4 if we do additions in 7.2. Doesn't the deprecation of Data.Map.foldWithKey indicate it will be gone in 7.2? To catch up with deprecating Data.IntMap.foldWithKey, Data.Map.foldWithKey would need to stay deprecated in 7.0, 7.2 and 7.4 C.

On Fri, Jan 14, 2011 at 01:13:46PM +0100, Christian Maeder wrote:
The problem of adding a new function and deprecating an old one in the same release is, that sources modified according to the deprecation cannot be compiled with a previous compiler release.
Yes, you'd need ifdefs to do this, but waiting another year is just too slow. It's a trade-off, to be sure.

Am 14.01.2011 13:47, schrieb Ross Paterson:
On Fri, Jan 14, 2011 at 01:13:46PM +0100, Christian Maeder wrote:
The problem of adding a new function and deprecating an old one in the same release is, that sources modified according to the deprecation cannot be compiled with a previous compiler release.
Yes, you'd need ifdefs to do this, but waiting another year is just too slow. It's a trade-off, to be sure.
This can be decided before ghc-7.2. I want a decision for my proposal before ghc-7.0.2 (actually tomorrow according to http://hackage.haskell.org/trac/ghc/ticket/4842). C.

Christian Maeder wrote:
Am 14.01.2011 13:47, schrieb Ross Paterson:
On Fri, Jan 14, 2011 at 01:13:46PM +0100, Christian Maeder wrote:
The problem of adding a new function and deprecating an old one in the same release is, that sources modified according to the deprecation cannot be compiled with a previous compiler release.
Yes, you'd need ifdefs to do this, but waiting another year is just too slow. It's a trade-off, to be sure.
This can be decided before ghc-7.2. I want a decision for my proposal before ghc-7.0.2 (actually tomorrow according to http://hackage.haskell.org/trac/ghc/ticket/4842).
Is it actually possible to get this change (removal of the deprecation) in to 7.0.2/the next HP? If so I think it should happen because it's essentially a bug fix, and then we can proceed with the proper fix for 7.2 etc. If not then we can proceed straight to the proper fix, assuming that's now agreed. Your proposal only makes sense for the longer term if those changes are not accepted. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Am 14.01.2011 14:30, schrieb Sittampalam, Ganesh:
Is it actually possible to get this change (removal of the deprecation) in to 7.0.2/the next HP?
Doesn't this proposal make it possible?
If so I think it should happen because it's essentially a bug fix, and then we can proceed with the proper fix for 7.2 etc.
If not then we can proceed straight to the proper fix, assuming that's now agreed. Your proposal only makes sense for the longer term if those changes are not accepted.
The only support the additions but not the immediate deprecations. C.

Christian Maeder wrote:
Am 14.01.2011 14:30, schrieb Sittampalam, Ganesh:
Is it actually possible to get this change (removal of the deprecation) in to 7.0.2/the next HP?
Doesn't this proposal make it possible?
That depends on whether they will actually pick up the change once committed. If the people responsible for that can't or won't, this proposal is moot. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Fri, Jan 14, 2011 at 03:15:56PM +0100, Christian Maeder wrote:
Am 14.01.2011 14:30, schrieb Sittampalam, Ganesh:
Is it actually possible to get this change (removal of the deprecation) in to 7.0.2/the next HP?
Doesn't this proposal make it possible?
We try not to change the APIs of libraries that come with GHC within a GHC major release, so that if something compiles with one minor release then it'll also compile with another. We do occasionally make exceptions (and most compiler bugfixes etc are effectively exceptions), if there is strong motivation to do so. Given how contentious this proposal has been, personally I don't think there is a strong case for making an exception, though. Thanks Ian

Ian Lynagh wrote:
On Fri, Jan 14, 2011 at 03:15:56PM +0100, Christian Maeder wrote:
Am 14.01.2011 14:30, schrieb Sittampalam, Ganesh:
Is it actually possible to get this change (removal of the deprecation) in to 7.0.2/the next HP?
Doesn't this proposal make it possible?
We try not to change the APIs of libraries that come with GHC within a GHC major release, so that if something compiles with one minor release then it'll also compile with another.
Is removing a deprecation warning an API change? Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Fri, Jan 14, 2011 at 03:12:03PM -0000, Sittampalam, Ganesh wrote:
Ian Lynagh wrote:
On Fri, Jan 14, 2011 at 03:15:56PM +0100, Christian Maeder wrote:
Am 14.01.2011 14:30, schrieb Sittampalam, Ganesh:
Is it actually possible to get this change (removal of the deprecation) in to 7.0.2/the next HP?
Doesn't this proposal make it possible?
We try not to change the APIs of libraries that come with GHC within a GHC major release, so that if something compiles with one minor release then it'll also compile with another.
Is removing a deprecation warning an API change?
Yes, but a very minor one (and thus relatively easy to justify an exception for). Thanks Ian

Am 14.01.2011 16:10, schrieb Ian Lynagh:
On Fri, Jan 14, 2011 at 03:15:56PM +0100, Christian Maeder wrote:
Am 14.01.2011 14:30, schrieb Sittampalam, Ganesh:
Is it actually possible to get this change (removal of the deprecation) in to 7.0.2/the next HP?
Doesn't this proposal make it possible?
We try not to change the APIs of libraries that come with GHC within a GHC major release, so that if something compiles with one minor release then it'll also compile with another.
It is no API change. It fixes the bug that a program using Data.Map.foldWithKey called with the flag -Werror is rejected.
We do occasionally make exceptions (and most compiler bugfixes etc are effectively exceptions), if there is strong motivation to do so. Given how contentious this proposal has been, personally I don't think there is a strong case for making an exception, though.
If you (the community) were willing to allow API changes I would suggest to add the fold{l,r}WithKey functions to Data.IntMap and the strict variants fold{l,r}WithKey' to Data.Map and Data.IntMap (to support later deprecation in 7.2) C.
Thanks Ian

Am 14.01.2011 13:47, schrieb Ross Paterson:
On Fri, Jan 14, 2011 at 01:13:46PM +0100, Christian Maeder wrote:
The problem of adding a new function and deprecating an old one in the same release is, that sources modified according to the deprecation cannot be compiled with a previous compiler release.
Yes, you'd need ifdefs to do this, but waiting another year is just too slow. It's a trade-off, to be sure.
Before using ifdefs I (and maybe others too) would revert the change and ignore the deprecation warning (for one major release), thus defeating the purpose of deprecations. Why the hurry to deprecate? Christian

On Fri, 14 Jan 2011, Ross Paterson wrote:
On Fri, Jan 14, 2011 at 12:32:29PM +0100, Christian Maeder wrote:
I wouldn't mind the additions even if committed for ghc-7.0.2, but can we please start deprecations a major release later (and revert the current spurious deprecation of Data.Map.foldWithKey).
We can't do additions until 7.2 either. We're talking about deprecations for 7.2 and removals in 7.4. If we decide to do that, surely it would make sense for the deprecation of Data.Map.foldWithKey to stay in.
Deprecation only makes sense if there's an alternative. The argument here is that there's no "portable" alternative to foldWithKey, and so it shouldn't be deprecated. Under those circumstances, undeprecating for 7.0.2 and redeprecating along with the additions in 7.2 would seem like a reasonable approach. Ganesh

Am 14.01.2011 00:26, schrieb Gregory Collins:
On Thu, Jan 13, 2011 at 8:12 PM, Christian Maeder
wrote: Asking for support again (or withdrawals of "no"s)
So if the vote/discussion doesn't go as you like, you bring it up again until people are too tired to argue with you anymore?
Yes, until I'm too tired to do it (or facts are committed beyond my influence).
Still no from me. My preferred resolution would be to remove foldWithKey from Intmap also.
And leave the container package for three major releases (7.0 to 7.4) as construction side?
And I point to this thread as an example of the morass that is our current libraries process :(
G
C

Am 14.01.2011 00:26, schrieb Gregory Collins:
On Thu, Jan 13, 2011 at 8:12 PM, Christian Maeder
wrote: Asking for support again (or withdrawals of "no"s)
So if the vote/discussion doesn't go as you like, you bring it up again until people are too tired to argue with you anymore?
Still no from me. My preferred resolution would be to remove foldWithKey from Intmap also. And I point to this thread as an example of the morass that is our current libraries process :(
G
According to http://www.haskell.org/haskellwiki/Library_submissions we are in the "rare event" of "A deeply held disagreement". Who or what is going to resolve it? Cheers Christian

On Fri, Jan 14, 2011 at 06:55:19PM +0100, Christian Maeder wrote:
According to http://www.haskell.org/haskellwiki/Library_submissions we are in the "rare event" of "A deeply held disagreement".
Who or what is going to resolve it?
I haven't been following this proposal too closely, but I'd suggest "by default, no action". Thanks Ian

On Fri, 14 Jan 2011, Christian Maeder wrote:
Am 14.01.2011 00:26, schrieb Gregory Collins:
On Thu, Jan 13, 2011 at 8:12 PM, Christian Maeder
wrote: Asking for support again (or withdrawals of "no"s)
So if the vote/discussion doesn't go as you like, you bring it up again until people are too tired to argue with you anymore?
Still no from me. My preferred resolution would be to remove foldWithKey from Intmap also. And I point to this thread as an example of the morass that is our current libraries process :(
G
According to http://www.haskell.org/haskellwiki/Library_submissions we are in the "rare event" of "A deeply held disagreement".
I'm not sure that we are. There now seems to be agreement about the long-term solution (add foldrWithKey etc), even if the details of the deprecation cycle are not agreed. So it's clear that removing the deprecation of foldWithKey just for this release would only be a short-term measure. Gregory, are you willing to accept it on that basis? Cheers, Ganesh

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.
The discussion period is over. I've finished my share for the ticket with a summary and moved to burden (and chance) to those with commit rights. Cheers Christian
participants (8)
-
Christian Maeder
-
Ganesh Sittampalam
-
Gregory Collins
-
Ian Lynagh
-
Johan Tibell
-
Max Bolingbroke
-
Ross Paterson
-
Sittampalam, Ganesh