Re: [ghc-steering-committee] Proposal #631: Set program exit code by main return type, recommendation: accept something

15 Mar 2024


      I also think any change in behaviour should be behind an extension.

Cheers
Simon

On Thu, 14 Mar 2024 at 16:51, Simon Peyton Jones <
simon.peytonjones@gmail.com> wrote:
...
I like the proposal basically as is. i.e. typeclass + warning
Especially the fact that it warns everyone and breaks no-one (who doesn’t
want
to).
I am weakly in favor of gating the usage of the typeclass for anything but
()
and Void behind an extension. That way no program will newly exit with
failure
without the user opting in and we might be able to experiment more on the
type
class.
I'm with Malte.   But I don't have strongly held views.
Simon
On Thu, 14 Mar 2024 at 14:04, Malte Ott  wrote:
...
I like the proposal basically as is. i.e. typeclass + warning
Especially the fact that it warns everyone and breaks no-one (who doesn’t
want
to).
I am weakly in favor of gating the usage of the typeclass for anything
but ()
and Void behind an extension. That way no program will newly exit with
failure
without the user opting in and we might be able to experiment more on the
type
class.
Best
Malte
...
Dear all,
Shea has updated his proposal based on the committee's feedback.
There seem to be two main alternatives being considered at the moment
- Having a type class to compute the exit code based on the type. This
is
Shea's favourite. It can be done without an extension (as Shea's
...
or with an extension.
- Keep the current behaviour but emit a warning when the return type of
`main` isn't `()` or `Void`.
I have opinions about my preference, but I'd like to hear about
everybody's
thoughts first.
On Thu, 7 Mar 2024 at 10:27, Adam Gundry  wrote:
...
I've added a comment to the GitHub thread
(
https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1983060...
)
...
elaborating slightly on Richard's suggestion (albeit with an
effectively
...
indefinite transition period).
Adam
On 05/03/2024 08:52, Arnaud Spiwack wrote:
...
This is Alternative 7.5 in the current version of the proposal
https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main...
...
<
https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main...
...
.
...
PS: I tend to agree with Richard that requiring an ExitStatus
instance
...
is the preferable option. But food for thought for the proposal
...
...
...
when that conversation happens there: should that be gated behind an
extension? In which case it won't become the default before the next
language edition.
/Arnaud
On Mon, 4 Mar 2024 at 21:35, Simon Peyton Jones
mailto:simon.peytonjones@gmail.com>
wrote:
I left out a key part of my last email -- apologies. I'm
        floating a counter-proposal where we *require* an instance
of
        ExitStatus on the return type of `main`, with a transition
        period. In contrast, my understanding of the proposal
written is
        that it would use such an instance if it exists, but issue a
        warning if it doesn't, in perpetuity.
Ah  I had not realised that.
But why?
Rather than answer here (private to SC) why don't you put your
    proposal on the discussion thread, say why, and invite feedback.
Simon
On Mon, 4 Mar 2024 at 19:24, Richard Eisenberg
    mailto:reisenberg@janestreet.com>
wrote:
I left out a key part of my last email -- apologies. I'm
        floating a counter-proposal where we *require* an instance
of
        ExitStatus on the return type of `main`, with a transition
        period. In contrast, my understanding of the proposal
written is
        that it would use such an instance if it exists, but issue a
        warning if it doesn't, in perpetuity.
Richard
On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones
        mailto:simon.peytonjones@gmail.com> wrote:
I am a little worried about breaking programs that
end
                in an innocent-looking `return 0`, just because some
                other languages like to end programs with that
...
...
...
The proposal specifies that such a program returns
            `ExitSuccess`, but adds a warning. That seems OK to me;
it
...
does not break the program.
Oh -- maybe you mean that `return 1` means "return with
exit
...
code 1" today.  Is that really true?  I don't think so.
Overall this proposal seems fine to me.  I'd be happy
to see
...
it done.
Simon
On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg
            mailto:reisenberg@janestreet.com> wrote:
I haven't followed this proposal closely. But
couldn't
...
we have a transition period toward this eventual
goal?
...
That is, introduce a new warning, on by default, if
                `main` returns anything other than `()`. That goes
for a
...
few releases. Then we require that the return type
of
...
main has an instance of ExitStatus.
I'm not worried about changing the behavior of
...
...
...
that have type IO ExitCode but expect the program to
                return 0 unconditionally; that's just begging for
                confusion. I am a little worried about breaking
...
...
...
that end in an innocent-looking `return 0`, just
because
...
some other languages like to end programs with that
                phrase. So I'm not sure if we should have an
instance
...
ExitStatus Int (or instance ExitStatus Integer) --
but
...
we probably should. If a program ends with `return
1`,
...
the programmer probably wants the OS to return 1 as
well.
...
Richard
On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack
                mailto:arnaud.spiwack@tweag.io> wrote:
Dear all,
Shea Levy proposes to do something with the
values
...
returned by `main`
https://github.com/ghc-proposals/ghc-proposals/pull/631 <
https://github.com/ghc-proposals/ghc-proposals/pull/631> .
...
The problem is that `main` is allowed to be of
type
...
`IO A` for any `A`. And GHC will simply drop the
                    value returned by `main`. Shea contends that
it's
...
surprising. I agree that dropping a value
without
...
the compiler being explicitly instructed to is
                    surprising. But Shea says that when `A` is
                    `ExitCode` this is even more surprising. Namely
                    `main :: IO ExitCode; main = return $ Failure 1`
                    actually terminates with exit code 0. And I
doubt
...
that it's what anybody expects when reading the
code.
...
The proposal is simple, but I have a lot of
comments
...
on it. Sorry about that…
Now, this sort of proposal is tricky. When the
                    current behaviour is confusing, we want to
change
...
the default. But putting the new default behind
an
...
extension doesn't really solve the fact that
...
...
...
a trap. The extension is, therefore, unlikely
to be
...
well tested before it becomes part of the next
                    language edition.
Shea's main proposition doesn't actually use an
                    extension though. He adds a type class
`ExitStatus`,
...
and if `ExistStatus A`, then `main :: IO A`
uses the
...
instance to determine the exit code based on the
                    return value.
The only change to the current behaviour is that
                    `main :: IO ExitCode` instead of always
terminating
...
with exit code 0 when returning now terminates
with
...
the expected error code. The argument for not
                    putting this behind an extension is that
virtually
...
anybody affected by the change will actually
have
...
the behaviour they were expecting. But maybe the
                    argument isn't strong enough (the changes may be
                    more “interesting” if some library exports some
                    `ExistStatus` instance).
This design of this proposal is inspired by
Rust's
...
design. I've asked our Rust team, and they
certainly
...
seem to have internalised the idea of returning
an
...
exit code. It really seems a pretty natural
feature
...
to have. So I'm rather in favour of some
flavour of
...
the type class implementation. Though have a
look at
...
the alternatives, where you'll find other
approaches
...
such as restricting the type of `main` to
                    unsurprising types.
One caveat with respect to the main proposal:
it is
...
proposed that when no `ExistStatus A` is found,
...
...
...
we drop the returned value like today. I don't
know
...
that it's quite easy to implement this
behaviour.
...
But it can be recovered by a catch-all
overlapping
...
instance, so maybe it's a better way to specify
On 2024-03-14 14:32, Arnaud Spiwack wrote:
proposing)
thread
phrase
programs
programs
there's
then
the
...
...
...
desired behaviour.
--
                    Arnaud Spiwack
                    Director, Research at https://moduscreate.com
                    https://moduscreate.com and https://tweag.io
                    https://tweag.io.
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
...
--
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
...
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Re: [ghc-steering-committee] Proposal #631: Set program exit code by main return type, recommendation: accept something

Simon Marlow