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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Simon Hengel
Hi!
I propose to add

    die :: String -> IO ()
    die err = hPutStrLn stderr err >> exitFailure

to System.Exit.

Reasoning:

(1) It's a frequently required functionality.  Almost every command-line
    program has code similar to this.

(2) The definition is relatively short, but in addition to the
    definition, you need two import statements.

(3) It's frequently done wrong (e.g. writing to stdout instead of
    stderr, or not using exitFailure, or both).
   
I haven't done any extensive research on Hackage, but I quickly looked
at Haddock.  Here we have a definition of die [1], but we also print to
stdout at a couple of place and then call exitFailure [2].

Personally, I think it should be re-exported from Prelude.  But this may
be controversial.  So let's have two separate votes:

Add System.Exit.die:            +1
Re-export it from Prelude:      +1

(discussion until December, 28th)

Cheers,
Simon

[1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
[2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Simon Hengel
On Sat, Dec 14, 2013 at 11:56:11AM +0100, Simon Hengel wrote:
> I propose to add
>
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.

An alternative implementation would be:

    die :: String -> IO ()
    die err = do
      name <- getProgramName
      hPutStrLn stderr (name ++ ": " ++ err) >> exitFailure

(not sure what's preferable)

Cheers.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Vo Minh Thu
In reply to this post by Simon Hengel
2013/12/14 Simon Hengel <[hidden email]>:

> Hi!
> I propose to add
>
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.
>
> Reasoning:
>
> (1) It's a frequently required functionality.  Almost every command-line
>     program has code similar to this.
>
> (2) The definition is relatively short, but in addition to the
>     definition, you need two import statements.
>
> (3) It's frequently done wrong (e.g. writing to stdout instead of
>     stderr, or not using exitFailure, or both).
>
> I haven't done any extensive research on Hackage, but I quickly looked
> at Haddock.  Here we have a definition of die [1], but we also print to
> stdout at a couple of place and then call exitFailure [2].
>
> Personally, I think it should be re-exported from Prelude.  But this may
> be controversial.  So let's have two separate votes:

Isn't your `die` function a special case of `error :: String -> a`,
which is in the Prelude ?

I think variants of what you propose are often used: different exit
codes, not exiting and flushing stderr, displaying an arbitrary `Show
a` instead of `String`, using `Text`, and so on.

Actually I think some (all ?) `IO` things from the Prelude should not
be in the Prelude. For instance I may want to use the `bytestring`
`readFile`.

- 1 (for both)

Thu
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Roman Cheplyaka-2
In reply to this post by 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.

Roman

* Simon Hengel <[hidden email]> [2013-12-14 11:56:11+0100]

> Hi!
> I propose to add
>
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.
>
> Reasoning:
>
> (1) It's a frequently required functionality.  Almost every command-line
>     program has code similar to this.
>
> (2) The definition is relatively short, but in addition to the
>     definition, you need two import statements.
>
> (3) It's frequently done wrong (e.g. writing to stdout instead of
>     stderr, or not using exitFailure, or both).
>    
> I haven't done any extensive research on Hackage, but I quickly looked
> at Haddock.  Here we have a definition of die [1], but we also print to
> stdout at a couple of place and then call exitFailure [2].
>
> Personally, I think it should be re-exported from Prelude.  But this may
> be controversial.  So let's have two separate votes:
>
> Add System.Exit.die:            +1
> Re-export it from Prelude:      +1
>
> (discussion until December, 28th)
>
> Cheers,
> Simon
>
> [1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
> [2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Roman Cheplyaka-2
In reply to this post by Vo Minh Thu
* Vo Minh Thu <[hidden email]> [2013-12-14 12:09:20+0100]
> Isn't your `die` function a special case of `error :: String -> a`,
> which is in the Prelude ?

There are two differences:

* die throws an exception in the IO monad (i.e. it uses `throwIO`,
  whereas `error` uses `throw`).
* error adds "*** Exception: " to the message

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon Hengel
In reply to this post by Vo Minh Thu
On Sat, Dec 14, 2013 at 12:09:20PM +0100, Vo Minh Thu wrote:
> Isn't your `die` function a special case of `error :: String -> a`,
> which is in the Prelude ?

No, it's not.  I'm not going into the details of imprecise exceptions
(and GHC's interpretation of them + all the bugs that various versions
of GHC have when it comes to that topic), but `error` indicates a
programmer error and should not be part of a valid path in your program.
In contrast, `die` is meant to be used when a user e.g. passes wrong
input to a program (which is a user error, not a programmer error).

> I think variants of what you propose are often used: different exit
> codes, not exiting and flushing stderr

You can just use hPutStrLn here, stderr is unbuffered by default.

> displaying an arbitrary `Show a` instead of `String`

Yes, that is actually a good point.  But

    die (show x)

is still much more concise than using hPrint + exitFailure.

> using `Text`

Valid point.  Still, I think for the particular case of error messages
it's ok to stick with String.

Cheers.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann
In reply to this post by Simon Hengel

On Sat, 14 Dec 2013, Simon Hengel wrote:

> Hi!
> I propose to add
>
>    die :: String -> IO ()
>    die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.

I have written this definition several times and called it exitFailureMsg.
I used it only for the argument handling in shell programs. I agree with
Roman that the proper way are exceptions. However, the implicit nature of
IO exceptions is the wrong way, too. This is confirmed by Roman's
observation that it is not clear how uncaught IO exceptions are handled.
In an explicit ErrorT way you cannot accidentally ignore exceptions.

Thus, I think neither 'die'/exit nor IO exceptions are the right way to
go. Consequently I hesitate to add further steps in wrong directions to
'base'. Maybe it would be better to add an exception handler containing
"hPutStrLn stderr" to ErrorT module.


> Add System.Exit.die:

0

> Re-export it from Prelude:

-1
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Simon Hengel
In reply to this post by Roman Cheplyaka-2
> 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.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Niklas Hambüchen
I also think that people should generally use exceptions which I can
catch by names (as opposed to error), especially in libraries, but in
simple top-level cases as you described, your `die` makes a lot of sense
to me. "Easy things should be easy", and removing another case for
`error` sounds like a good thing.

  Add System.Exit.die:     +1

I'd prefer your simple, first version though, since `getProgramName`
might not always print the thing you would like. Glad to be convinced
otherwise though (how do unix tools do this? Is it hardcoded or do they
check their program name)?

  Re-export it from Prelude:  -1

(At least for now, let's have it around firstr.)


On 14/12/13 11:54, Simon Hengel wrote:

>> 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.
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Ivan Lazar Miljenovic
In reply to this post by Roman Cheplyaka-2
On 14 December 2013 22:19, Roman Cheplyaka <[hidden email]> wrote:
> 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.

I've written something similar to this die function specifically to
deal with these exceptions (or to exit early out of main if I know
nothing more can proceed) rather than relying upon GHC to deal with
them.

That said, I'm not sure if it's worth adding; +0.5 to having it in System.Exit.

>
> 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.
>
> Roman
>
> * Simon Hengel <[hidden email]> [2013-12-14 11:56:11+0100]
>> Hi!
>> I propose to add
>>
>>     die :: String -> IO ()
>>     die err = hPutStrLn stderr err >> exitFailure
>>
>> to System.Exit.
>>
>> Reasoning:
>>
>> (1) It's a frequently required functionality.  Almost every command-line
>>     program has code similar to this.
>>
>> (2) The definition is relatively short, but in addition to the
>>     definition, you need two import statements.
>>
>> (3) It's frequently done wrong (e.g. writing to stdout instead of
>>     stderr, or not using exitFailure, or both).
>>
>> I haven't done any extensive research on Hackage, but I quickly looked
>> at Haddock.  Here we have a definition of die [1], but we also print to
>> stdout at a couple of place and then call exitFailure [2].
>>
>> Personally, I think it should be re-exported from Prelude.  But this may
>> be controversial.  So let's have two separate votes:
>>
>> Add System.Exit.die:            +1
>> Re-export it from Prelude:      +1
>>
>> (discussion until December, 28th)
>>
>> Cheers,
>> Simon
>>
>> [1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
>> [2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel
In reply to this post by Vo Minh Thu
On 2013-12-14 at 12:09:20 +0100, Vo Minh Thu wrote:

[...]

>> I propose to add
>>
>>     die :: String -> IO ()
>>     die err = hPutStrLn stderr err >> exitFailure
>>
>> to System.Exit.

[...]

> Isn't your `die` function a special case of `error :: String -> a`,
> which is in the Prelude ?

Imho, it'd be more comparable to the effect of `fail :: Monad m =>
String -> m a` for 'm == IO' (which throws an 'userError' exception).

E.g.:

  $ cat > foo.hs <<EOF
  main = fail "I'm outta here"
  EOF
 
  $ ghc --make foo.hs
 
  $ ./foo.hs
 
  foo: user error (I'm outta here)


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Lato-2
In reply to this post by Simon Hengel
+1 to adding 'die' to System.Exit
-1 to adding to Prelude

I've pretty much only wanted this in command-line type programs, but as the proposal notes, it's very frequently required in that situation.

John L.


On Sat, Dec 14, 2013 at 2:56 AM, Simon Hengel <[hidden email]> wrote:
Hi!
I propose to add

    die :: String -> IO ()
    die err = hPutStrLn stderr err >> exitFailure

to System.Exit.

Reasoning:

(1) It's a frequently required functionality.  Almost every command-line
    program has code similar to this.

(2) The definition is relatively short, but in addition to the
    definition, you need two import statements.

(3) It's frequently done wrong (e.g. writing to stdout instead of
    stderr, or not using exitFailure, or both).

I haven't done any extensive research on Hackage, but I quickly looked
at Haddock.  Here we have a definition of die [1], but we also print to
stdout at a couple of place and then call exitFailure [2].

Personally, I think it should be re-exported from Prelude.  But this may
be controversial.  So let's have two separate votes:

Add System.Exit.die:            +1
Re-export it from Prelude:      +1

(discussion until December, 28th)

Cheers,
Simon

[1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
[2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

amindfv
+1 adding to System.Exit
-0.5 adding to Prelude

Tom


El Dec 15, 2013, a las 18:50, John Lato <[hidden email]> escribió:

+1 to adding 'die' to System.Exit
-1 to adding to Prelude

I've pretty much only wanted this in command-line type programs, but as the proposal notes, it's very frequently required in that situation.

John L.


On Sat, Dec 14, 2013 at 2:56 AM, Simon Hengel <[hidden email]> wrote:
Hi!
I propose to add

    die :: String -> IO ()
    die err = hPutStrLn stderr err >> exitFailure

to System.Exit.

Reasoning:

(1) It's a frequently required functionality.  Almost every command-line
    program has code similar to this.

(2) The definition is relatively short, but in addition to the
    definition, you need two import statements.

(3) It's frequently done wrong (e.g. writing to stdout instead of
    stderr, or not using exitFailure, or both).

I haven't done any extensive research on Hackage, but I quickly looked
at Haddock.  Here we have a definition of die [1], but we also print to
stdout at a couple of place and then call exitFailure [2].

Personally, I think it should be re-exported from Prelude.  But this may
be controversial.  So let's have two separate votes:

Add System.Exit.die:            +1
Re-export it from Prelude:      +1

(discussion until December, 28th)

Cheers,
Simon

[1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
[2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
I'm neutral on adding or removing it to System.Exit in the first place. 

On one hand it incurs the extra clutter of another name for a simple composition, but on the other it is exiled to a fairly appropriate place and I can see that there is a worldview in which would be the right way to deal with exceptional situations that have no recovery mechanism.

That said, I'm pretty strongly -1 on adding it to the Prelude.

-Edward


On Sun, Dec 15, 2013 at 7:40 PM, <[hidden email]> wrote:
+1 adding to System.Exit
-0.5 adding to Prelude

Tom


El Dec 15, 2013, a las 18:50, John Lato <[hidden email]> escribió:

+1 to adding 'die' to System.Exit
-1 to adding to Prelude

I've pretty much only wanted this in command-line type programs, but as the proposal notes, it's very frequently required in that situation.

John L.


On Sat, Dec 14, 2013 at 2:56 AM, Simon Hengel <[hidden email]> wrote:
Hi!
I propose to add

    die :: String -> IO ()
    die err = hPutStrLn stderr err >> exitFailure

to System.Exit.

Reasoning:

(1) It's a frequently required functionality.  Almost every command-line
    program has code similar to this.

(2) The definition is relatively short, but in addition to the
    definition, you need two import statements.

(3) It's frequently done wrong (e.g. writing to stdout instead of
    stderr, or not using exitFailure, or both).

I haven't done any extensive research on Hackage, but I quickly looked
at Haddock.  Here we have a definition of die [1], but we also print to
stdout at a couple of place and then call exitFailure [2].

Personally, I think it should be re-exported from Prelude.  But this may
be controversial.  So let's have two separate votes:

Add System.Exit.die:            +1
Re-export it from Prelude:      +1

(discussion until December, 28th)

Cheers,
Simon

[1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
[2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Evan Laforge
In reply to this post by amindfv
I always thought it was kind of bizarre how other languages (even
wordy old java) have "exit :: Int -> IO ()", but haskell has
"System.Exit.exitSuccess" and "System.Exit.exitWith (ExitFailure 42)".
 Yes it's higher level to say "success" and "failure" than "0" and
">0", but wow that's a lot of bureaucracy for something trivial.  And
it still lets you write (ExitFailure 0).

Anyway, +1 for System.Exit, -1 for Prelude, because I sometimes define
my own 'die'.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Roman Cheplyaka-2
* Evan Laforge <[hidden email]> [2013-12-15 17:54:14-0800]
> I always thought it was kind of bizarre how other languages (even
> wordy old java) have "exit :: Int -> IO ()", but haskell has
> "System.Exit.exitSuccess" and "System.Exit.exitWith (ExitFailure 42)".
>  Yes it's higher level to say "success" and "failure" than "0" and
> ">0", but wow that's a lot of bureaucracy for something trivial.  And
> it still lets you write (ExitFailure 0).

System.Exit.exitFailure :: IO a has existed for a long time, FWIW.

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Evan Laforge
On Sun, Dec 15, 2013 at 6:16 PM, Roman Cheplyaka <[hidden email]> wrote:
> * Evan Laforge <[hidden email]> [2013-12-15 17:54:14-0800]
>> I always thought it was kind of bizarre how other languages (even
>> wordy old java) have "exit :: Int -> IO ()", but haskell has
>> "System.Exit.exitSuccess" and "System.Exit.exitWith (ExitFailure 42)".
>>  Yes it's higher level to say "success" and "failure" than "0" and
>> ">0", but wow that's a lot of bureaucracy for something trivial.  And
>> it still lets you write (ExitFailure 0).
>
> System.Exit.exitFailure :: IO a has existed for a long time, FWIW.

Yeah, that's what I was saying.  One module, one type, two
constructors, and three functions, just to do what everyone else does
with one 'exit' function.  It's the windows vista shutdown menu of
exit functions.  It's almost as if haskell doesn't want to let us out.

Um.  Anyway.  Ignore me and carry on.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel
In reply to this post by Simon Hengel
Hello Simon,

On 2013-12-14 at 11:56:11 +0100, Simon Hengel wrote:
> I propose to add
>
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.

Why not simply use the existing `fail :: String -> IO a` method instead?

The differences & similiarities I see wrt `fail`:

 - `die` throws an `ExitCode` exception, whereas `fail` throws an
   `IOError` exception

 - Both result in the message written to stderr and a non-zero exit code

 - As both use exceptions, `die` does guarantee termination (as it can
   be caught)

 - `die` writes to stderr at invocation time, whereas `fail` attaches
   the message to the exception, which is then output by the top
   exception handler.

   Due to that, catching a `die`-caused exception will print the
   termination message even though the process-exit was
   cancelled. Whereas attaching the message to the exception allows for
   more flexibility as well as for atomicity wrt message-output and
   termination.
   
 - `fail` is available from Prelude (and part of Haskell98/2010),
   whereas `System.Exit.die` would require an import of "System.Exit"
   (with the small risk of breaking code that expects only
   Haskell2010-known entities exported by "System.Exit")

Therefore I'm not convinced (yet), that the suggested `die`
implementation has sensible semantics in the context of exceptions, and
that it offers enough benefits over the already existing `fail` method.

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Luposchainsky
In reply to this post by John Lato-2
On 16.12.2013 00:50, John Lato wrote:
> +1 to adding 'die' to System.Exit
> -1 to adding to Prelude

Dito. Prelude should shrink rather than grow, especially with respect to
ad-hoc functions.

David

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Roman Cheplyaka-2
In reply to this post by Herbert Valerio Riedel
* Herbert Valerio Riedel <[hidden email]> [2013-12-16 10:53:21+0100]
> Why not simply use the existing `fail :: String -> IO a` method instead?

The purpose of 'fail' is to handle monadic pattern-match failures.
I consider explicit use of 'fail' in user code a hack.

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
12