#4842: keep Data.Map.foldWithKey
----------------------------------+-----------------------------------------
Reporter: maeder | Owner:
Type: proposal | Status: patch
Priority: normal | Milestone: Not GHC
Component: libraries (other) | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
----------------------------------+-----------------------------------------
Changes (by maeder):
* status: new => patch
Comment:
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.!
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4842#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
