Proposal: overhaul System.Process

[Don Stewart]

john:
> On Tue, Apr 22, 2008 at 04:09:56PM -0700, Don Stewart wrote:
> > duncan.coutts:
> > > 
> > > On Tue, 2008-04-22 at 15:52 -0700, Don Stewart wrote:
> > > > duncan.coutts:
> > > 
> > > > > > > I would have thought (ExitCode,String) was more appropriate.
> > > > > > 
> > > > > > Yes, definitely.
> > > > > 
> > > > > Yes, I mentioned this to Don previously when he published his popen
> > > > > code. I think he agreed.
> > > 
> > > > I'd changed, but not pushed out, process-light:
> > > 
> > > > readProcess :: FilePath                     -- ^ command to run
> > > >             -> [String]                     -- ^ any arguments
> > > >             -> String                       -- ^ standard input
> > > >             -> IO (Either (ExitCode,String) String)  -- ^ either the stdout, or an exitcode and any output
> > > 
> > > You don't need the Either. ExitCode already covers the case when the
> > > process terminates successfully.
> > > 
> > 
> > But we want to force people to check the failure case. Just returning
> > the tuple doesn't help there.
> 
> But it is much more elegant, cleaner code, and more in line with the
> underlying semantics. A general library API shouldn't force
> complexity on its users. Also, it has two redundant cases (Left
> (ExitSuccess,out)) and (Right out), which is a far worse bug in an API.
> 
> Also, it means you can't have lazy output. since you won't know the
> error code until the process has finished completely.
> 

Yeah, this was originally written for lambdabot, where lazy output just
wasn't an option -- and possibly dangerous.

Finding a good type that encourages the kind of "correctness" approach
to handling errors that we like in Haskell would be good though --
if we can improve safety, cheaply, let's do it!

-- Don