Proposal: overhaul System.Process

[Frederik Eaton]

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-tp16844161p17993548.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.