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