Proposal: overhaul System.Process

David Roundy droundy at darcs.net
Thu Jun 19 13:39:29 EDT 2008


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.

David


More information about the Libraries mailing list