DEPRECATED foldWithKey "Use foldrWithKey instead"

[Johan Tibell]

On Thu, Dec 9, 2010 at 7:56 PM, Christian Maeder
<Christian.Maeder at dfki.de> wrote:
> I did not mean to "yell", in fact, I asked.
> I wasn't curious about the reason, because the reason looked obvious to me:
>  - avoid different names for the same thing
>  - orthogonality to the prelude (foldl and foldr and no fold)
>
> The counter-arguments:
>  - orthogonality to Data.IntMap is lost
>  - there are other different names for the same thing (like toList)
>  - intents to destroy backwards compatibility (for weak reasons)
>  - may distract from more important deprecation warnings

We did consider these counter-arguments. I in particular felt that
making the API smaller (it has a whopping 150 functions) and more
maintainable (less code internally) was very important to get the
package to a state where it's easier to use for newbies (who are used
to 15 method APIs) and experience developers (quick: what's the
difference between update, adjust, and alter) alike.

In fact, I'm working on a tool that will allow you to ask Hackage wide
questions on the form like "Who uses Data.Map.insert?" just in order
to see if there are API functions that are unused and could be removed
(assuming that the functionality is still available through the rest
of the API.)

I like the Python PEP approach to making decisions: list the pros and
cons, make a decision and don't revisit them unless the pros/cons
changed. My hope in helping putting together the HP package addition
process was to use this method in debating Haskell packages (whether
we actually achieved that goal is a different question.)

In summary: given all the arguments above, we decided to try to start
shrinking the API. At the moment the one thing we really felt we could
remove right then and there was a function that had already been
deprecated for some time. You may weigh the arguments differently (and
I'm sure others do as well), which is of course fine, but I don't
think it's worth revisiting the issue unless something changed since
we last made the decision.

> Why is it a problem to regret a decision being made? Is it such a big
> deal to remove (or keep) a deprecation warning? If this is the case,
> maybe someone (more patiently) wants to go ahead.

It's somewhat annoying technically: create a ticket, attach a patch,
follow up to make sure it gets applied etc. That's not a huge issue.
No decisions are set in stone, but I don't see a good reason to
revisit this one.

Johan