I'm sorry for my late reply. This all sounds reasonable. My only concerns are that deprecating the old interfaces seems like a declaration of intent to eventually remove them. I believe that to the extent possible, library development should start with simple low-level interfaces which expose OS-level functionality in a straightforward manner, and then build on top of them. I realise that running processes is an especially difficult area, because different operating systems have different interfaces, there is the possibility of pipes and so forth. Perhaps this is why we have gone through multiple iterations of process-running APIs in the Haskell standard libraries. But I think that especially low-level interfaces like these should be created with the understanding that they will stay around forever, even if the cumulative result is slightly ugly. That can be an incentive to get them right the first time. In my mind, if 'createProcess' could not be implemented via the old interfaces, then that means they weren't low-level enough to start with. And in that case, we should be working on providing better low-level interfaces, rather than new high-level ones (I think 'createProcess' is slightly higher-level than 'runProcess' because it has a notion of a shell, pipes, fancy data structures, etc.). On the other hand, if 'runProcess' and friends were sufficient to implement 'createProcess', then that means they provided a satisfactory low-level foundation. And I think low-level interfaces are built upon, not deprecated. Duncan Coutts wrote:
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.
-- View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p1799354... Sent from the Haskell - Libraries mailing list archive at Nabble.com.