<div dir="ltr"><div>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 disable the warning.</div><div><br></div><div>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.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Mar 2024 at 15:32, Matthías Páll Gissurarson <<a href="mailto:mpg@mpg.is">mpg@mpg.is</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"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I agree. I like it, but better behind an extension to avoid surprises and enable experimentation.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Mar 2024 at 13:15, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</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"><div dir="ltr"><div dir="ltr">I also think any change in behaviour should be behind an extension.<br></div><br><div class="gmail_quote"><div class="gmail_attr">Cheers</div><div class="gmail_attr">Simon<br></div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Thu, 14 Mar 2024 at 16:51, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</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"><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 style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">I'm with Malte. But I don't have strongly held views.</div><div style="font-family:tahoma,sans-serif"><br></div><div 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" target="_blank">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>
_______________________________________________<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></div>
_______________________________________________<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><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="font-family:arial,helvetica,sans-serif;font-size:small">-- </span><a href="http://mpg.is/" style="font-family:arial,helvetica,sans-serif;font-size:small" target="_blank">Matthías Páll Gissurarson</a><br></div></div></div>
_______________________________________________<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><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>