
On Sun, 2008-05-25 at 16:27 -0700, Frederik Eaton wrote:
Hello,
I think it's great to improve System.Process, and the new interface looks good... I just wanted to say that I found it quite easy to write my own wrappers around those functions, which implement an interface that I find easier to use, several years ago. The hardest part was not so much writing the new interface, but updating it whenever the standard interface changed and broke my code. So I'd like to cast my vote for backwards compatibility. The standard libraries will never be perfect, but constantly deprecating and removing functionality can really impair their usefulness for large projects. I don't mean to be negative but I wanted to voice that concern.
The proposal is to deprecate several functions but not to remove anything. The decision to remove anything is independent. One this issue, one thing that I think may help is to have a period where the deprecated functions still exist but are removed from the documentation. The rationale is that one of the main reasons for removing functions that are essentially duplicated by newer variants is because they clutter the API docs. So the deprecation cycle would be something like: 1. normal 2. deprecated and still documented 3. deprecated and removed from documentation 4. removed Another thing that would help is if haddock marked deprecated functions as such and kept them in a separate section of the index, at least in the synopsis. It should be easy for haddock 2.x to find deprecated functions since it can just look at the pragmas which are presumably preserved by the GHC api. Duncan