On Thu, Dec 9, 2010 at 7:56 PM, Christian Maeder
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