keep Data.Map.foldWithKey

[maeder]

Remove the recently introduced deprecation warning for 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.

The deprecation was introduced by  http://hackage.haskell.org/trac/ghc/ticket/4277 that also added foldlWithKey and foldrWithKey.

But at least as long as these functions are not exported also by Data.IntMap, as proposed by  http://hackage.haskell.org/trac/ghc/ticket/3999, the common name foldWithKey should be kept. Such a common name is also used for the simple "fold" functions over maps and sets.

There was already some disagreement on this point in the thread  http://www.haskell.org/pipermail/libraries/2010-December/015274.html which convinced me to create this proposal.

I think two weeks of discussion should be enough, but I'll be happy about a decision by mid January 2011.

The change is almost only cosmetic, delete:

{-# DEPRECATED foldWithKey "Use foldrWithKey instead" #-}

and change "should" to "may" in the documentation:

-- This is identical to 'foldrWithKey', and you should use that one instead of
-- this one.  This name is kept for backward compatibility.

[maeder]

I've got a patch that removes trailing spaces and tabs (of all sources) first and then also bumps the version to 4.0.0.1.

[maeder]

I was tempted to remove foldlStrict from the 4 Set and Map source files and use Data.List.foldl' instead. However, foldlStrict differs by "{-# INLINE foldlStrict #-}" from foldl', which may have a performance impact that needs checking.

[maeder]

http://book.realworldhaskell.org/read/barcode-recognition.html

contains two occurrences of M.foldWithKey

[maeder]

My attached patch should not be used, because the darcs version does not correspond to the released containers-4.0.0.0 version. (Meanwhile strict folding functions have been added.)

This ticket did not intend to make an API change (which should only happen between major versions), but just fix a more or less accidental (and unfortunate) deprecation that should not make it into ghc-7.0.2 and the next haskell platform.

[maeder]

The discussion threads start at  http://www.haskell.org/pipermail/libraries/2010-December/015346.html and  http://www.haskell.org/pipermail/libraries/2011-January/015692.html

[maeder]

Summary: Me, Ian, Gregory, Johan, Ganesh, and Ross (6 people) contributed to the discussion. (ignoring Max' single remark  http://www.haskell.org/pipermail/libraries/2010-December/015367.html)

Johan (and later Ross) defended the deprecation as right step to reduce the Map interface.

Ganesh and I stressed the fact that the current situation is unsatisfying and inconsistent: recommending to use foldrWithKey (in Data.Map), but having to use foldWithKey (in Data.IntMap).

Only Gregory voted clearly against this proposal, although he strongly felt the inconsistency as well by supplying an immediate patch to add foldrWithKey (and friends) to Data.IntMap?.

However, extending the interface would mean an interface change for ghc-7.0.2 (although a minor one, because it only adds functions.)

Ian and Ross did not explicitly vote for or against this proposal. Johan did not confirm his "no" later ( http://www.haskell.org/pipermail/libraries/2011-January/015693.html), and expressed (like Gregory) his reservations against the current library process in general.

A consensus for this proposal was not achieved (which was almost clear from the start), but it remains a two-third majority for Ganesh's and my "yes" against Gregory's "no" in favor of this proposal.

I'll therefore promote this ticket for review, just to indicate that also rejecting this proposal is an active decision that would leave the container package in its current accidental inconsistent stage, that even Gregory disliked. So there is a consensus for change!

Far better options than doing nothing are:

1. reverting the deprecation (as proposed) without interface change 2. adding the missing functions: that changes the interface, but would allow deprecations earlier 3. both of 1. + 2.!

[igloo]

In the absence of a consensus, let's default to sticking to the "no interface changes" rule in the 7.0 branch.

[maeder]

Consensus was that "wontfix" is no possible action. And according to your definition of "no interface changes" in  http://www.haskell.org/pipermail/libraries/2011-January/015717.html namely "that if something compiles with one minor release then it'll also compile with another" removing a deprecation is no interface change.

[maeder]

containers package with undeprecated Map.foldWithKey function

[igloo]

In 7.2.1 we have the opportunity to make interface changes; do you still want this patch to be applied, or does someone want to make a proposal to make corresponding changes in the other modules instead?

[maeder]

I think this ticket can now only serve "as an example of the morass that is our current libraries process" as Greg said.  http://www.haskell.org/pipermail/libraries/2011-January/015695.html