Proposal: die to System.Exit (and/or Prelude)

[Simon Hengel]

> I agree that this function would be useful for quick&dirty prototyping.
> 
> However, I'm not sure we should encourage its use. What looks to me like
> a superior approach is to throw proper exceptions.
> 
> Here's an example in my own code:
> https://github.com/haskell-suite/haskell-names/blob/master/hs-gen-iface/src/hs-gen-iface.hs#L31
> 
> The main advantage of this is that it's much easier to turn the 'main'
> code into library code, which is not supposed to write to stderr
> anymore. Exceptions carry important semantic information about what
> actually happened, and can be caught and handled if needed. (The
> ExitCode exception can also be caught, but it doesn't tell us anything,
> and the output would have already gone to stderr.)
> 
> As a bonus, this approach forces you to separate (in code) message
> strings from places where you die, which in my experience leads to much
> cleaner code.
> 
> There's a caveat that the standard doesn't specify what happens to
> uncaught exceptions, so we have to rely on the runtime doing the right
> thing for us. Well, GHC's one does.

For my own code, I actually prefer to stick with Maybe/Either instead of
exceptions when ever possible.  I'd use `die` only in a top-level
wrapper, e.g. like so:

    import Acme.Omitted

    main :: IO ()
    main = getContents >>= either die run . parseInput

    run :: UserInput -> IO ()
    run = (...)

    parseInput :: String -> Either String UserInput
    parseInput = (...)

Cheers.