Proposal: overhaul System.Process

[Frederik Eaton]

David Roundy-2 wrote:
> 
> On Thu, Jun 19, 2008 at 12:57:58PM +0900, Curt Sampson wrote:
>> On 2008-06-18 15:37 -0700 (Wed), Frederik Eaton wrote:
>> 
>> > My only concerns are that deprecating the old interfaces seems like a
>> > declaration of intent to eventually remove them.
>> 
>> Just as one opinion, I prefer that old interfaces get removed. I have
>> no problem updating code to deal with this kind of stuff, and the cost
>> of that is easily paid off (for me) in the benefits I get from having
>> simple interfaces available. I found Java's libraries quite trying due
>> to the amount of cruft one was always wading through.
> 
> Here's an idea: perhaps deprecated functions should be exported in a
> new module System.Process.Deprecated? Then they could be left in that
> module after they've been removed from System.Process, if they ever
> are removed.  That would allow for a slightly easier transition.  I
> don't like the idea of forcing users of System.Process who are happy
> with the existing interface (e.g. darcs... which is not quite happy
> with it, but can get by) to either use #ifdefs (or something like
> that) or to limit their code to specific versions of ghc.  Not too
> long ago, I was bothered by being unable to compile darcs on a system
> with only ghc 6.2.  True, I could have compiled and installed a new
> ghc, but I didn't want to do so just to get a newer version of darcs,
> so I'm still using darcs 1.0.2 on that system (which I don't maintain,
> and is still running debian sarge).
> 
> Of course, moving the functions to a new module doesn't help *that*
> much, but it's easier to change the name of a module imported than to
> maintain two entirely different codebases for calling external
> programs (which is rather a fragile part of almost any code that will
> be using System.Process).
> 
> Perhaps a better option would be to keep the old interface
> indefinitely, but update haddock to allow deprecated interfaces to be
> documented only on a separate page.  Then you needn't break anyone's
> code, and new users would also not need to wade through a half dozen
> ancient functions with weird naming conventions.
> 

What's wrong with Simon Marlow's proposed haddock documentation?

http://darcs.haskell.org/~simonmar/process/System-Process.html

It puts the new stuff at the top. The old stuff goes under "Specific
variants of createProcess". The "Synopsis" section doesn't make this
separation very clear, and that could be improved, but otherwise it seems
good enough. Under 'runProcess' it says "Note: consider using the more
general createProcess instead of runProcess.". Sure, Haddock could be
updated to put certain interfaces on a separate page or under a collapsed
tab. Certainly it would be better to do that than to remove the interfaces
(or even put them under a different module name, which still leads to
compatibility headaches), but who knows when somebody will have time to make
such changes to Haddock.

If people want to have a System.Process package with only createProcess and
no runProcess, then I still think that the best way to do that would be to
make a new package with a new name. That seems preferable to removing names
from an existing package, because it doesn't require people to change their
code.

Frederik

-- 
View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p18020264.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.