<div dir="ltr"><div>Dear all,</div><div><br></div><div>Shea has updated his proposal based on the committee's feedback.</div><div><br></div><div>There seem to be two main alternatives being considered at the moment</div><div>- 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.</div><div>- Keep the current behaviour but emit a warning when the return type of `main` isn't `()` or `Void`.</div><div><br></div><div>I have opinions about my preference, but I'd like to hear about everybody's thoughts first. <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 7 Mar 2024 at 10:27, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.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">I've added a comment to the GitHub thread <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>
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>
> <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> <<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>
> 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>>> 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>>> 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>
> <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> <<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>
</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>