[ghc-steering-committee] Proposal #631: Set program exit code by main return type, recommendation: accept something
Arnaud Spiwack
arnaud.spiwack at tweag.io
Fri Mar 22 07:58:47 UTC 2024
@Malte, in my opinion, with the extension on, types which are not covered
by the type class should error out.
I'd like to have some more understanding of what's feasible to implement.
Adam, Simon PJ, could you share some insight there?
On Thu, 21 Mar 2024 at 00:19, Malte Ott <malte.ott at maralorn.de> wrote:
> On 2024-03-19 15:15, Arnaud Spiwack wrote:
> > So, my opinion that I promised, is that the best would probably be to
> have
> > add a warning when main doesn't have type `IO ()` or `IO Void` without
> the
> > extension (the behaviour is otherwise unchanged), and then change the
> > behaviour to use the typeclass with an extension (which we hope to turn
> on
> > by default in the next language edition). The extension should probably
> >
> > Now, I don't actually know how to implement this properly. So maybe it's
> a
> > bad idea. But I believe that's what I'd like to see.
> > disable the warning.
>
> From my understanding that is basically equivalent to what I was proposing.
> It has the properties:
>
> * Using a return type which could reasonably be expected to exit with
> failure
> should warn on -Wdefault (no matter whether a potential extension is
> enabled).
> * Concretely this means any return type but (), Void and maybe forall a.
> a, when the extension is off.
> * The warning could point to existing instances and the extension.
> * For anything which does not have an ExitCode implementation, when the
> extension is on.
> * Using the ExitCode type class should be possible but gated behind an
> extension.
>
> Now the question whether we should have two different warnings, one when
> the
> extension is on and one when it is off or one warning which changes its
> wording
> and behavior slightly depending on the extension being enabled does not
> matter
> that much in my opinion.
>
> Best
> Malte
>
> > On Fri, 15 Mar 2024 at 15:32, Matthías Páll Gissurarson <mpg at mpg.is>
> wrote:
> >
> > > I agree. I like it, but better behind an extension to avoid surprises
> and
> > > enable experimentation.
> > >
> > > On Fri, 15 Mar 2024 at 13:15, Simon Marlow <marlowsd at gmail.com> wrote:
> > >
> > >> 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 at 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 <malte.ott at maralorn.de>
> 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
> > >>>>
> > >>>> On 2024-03-14 14:32, Arnaud Spiwack wrote:
> > >>>> > 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
> > >>>> proposing)
> > >>>> > 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 <adam at well-typed.com>
> wrote:
> > >>>> >
> > >>>> > > I've added a comment to the GitHub thread
> > >>>> > > (
> > >>>> > >
> > >>>>
> https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1983060484
> > >>>> )
> > >>>> > >
> > >>>> > > 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-return-types.rst#75require-an-exitstatus-instance
> > >>>> > > <
> > >>>> > >
> > >>>>
> https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance
> > >>>> >
> > >>>> > > .
> > >>>> > > >
> > >>>> > > > PS: I tend to agree with Richard that requiring an ExitStatus
> > >>>> instance
> > >>>> > > > is the preferable option. But food for thought for the
> proposal
> > >>>> thread
> > >>>> > > > 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
> > >>>> > > > <simon.peytonjones at gmail.com <mailto:
> simon.peytonjones at 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
> > >>>> > > > <reisenberg at janestreet.com <mailto:
> reisenberg at 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
> > >>>> > > > <simon.peytonjones at gmail.com
> > >>>> > > > <mailto:simon.peytonjones at 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
> > >>>> phrase
> > >>>> > > >
> > >>>> > > >
> > >>>> > > > 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
> > >>>> > > > <reisenberg at janestreet.com
> > >>>> > > > <mailto:reisenberg at 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
> > >>>> programs
> > >>>> > > > 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
> > >>>> programs
> > >>>> > > > 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
> > >>>> > > > <arnaud.spiwack at tweag.io
> > >>>> > > > <mailto:arnaud.spiwack at 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
> > >>>> there's
> > >>>> > > > 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, then
> > >>>> > > > 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 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 at 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 at haskell.org
> > >>>> >
> > >>>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >>>>
> > >>>> _______________________________________________
> > >>>> ghc-steering-committee mailing list
> > >>>> ghc-steering-committee at haskell.org
> > >>>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >>>>
> > >>> _______________________________________________
> > >>> ghc-steering-committee mailing list
> > >>> ghc-steering-committee at haskell.org
> > >>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >>>
> > >> _______________________________________________
> > >> ghc-steering-committee mailing list
> > >> ghc-steering-committee at haskell.org
> > >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >>
> > >
> > >
> > > --
> > > -- Matthías Páll Gissurarson <http://mpg.is/>
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at 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 at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240322/e66d9254/attachment-0001.html>
More information about the ghc-steering-committee
mailing list