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

[Malte Ott]

I am not thrilled by having this three voting options. e.g. I think the
behaviour in 4. is fine and maybe even better than the type class approach, but
since this is coupled with not having a warning, its definitely worse.

3a
2
4

Also: If we implement 3a and then later people are against adding the
extension to a language edition because it might error on a few programs I will
be annoyed.

Best
Malte



On 2024-04-22 16:15, Arnaud Spiwack wrote:
> Ok, so, after an extended period of time (which, obviously, is my fault),
> we essentially have one option per opinion (well, I guess 3a and 4 have
> two, but that's not really what consensus is like). Simon, the other day,
> advised me to reduce the number of choices based on Shea's preferences. I
> decided to not include Shea's original proposal of doing the backward
> incompatible change without extension as I believe that it is contrary to
> the spirit of the language editions and all that.
> 
> *I'm calling for a vote* on the three following options. As per our
> customs, this is preference voting please order the following options. If
> you want to vote against an option, rank it after “That's it” (or omit it
> altogether). Explanation of the summary below
> 
> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll
> tally, and synthesise the committee's final position.
> 
> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when `main`
> has a type that isn't `main :: IO ()` or `main :: IO Void`, very much
> including `main :: IO ExitCode` (Shae's second favourite alternative)
> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added as
> in 2, but, additionally, an extension is introduced. When the extension is
> turned on, we always call the proposed `ExitStatus` type class on the
> returned value to determine the program's exit code. (Shae's favourite
> alternative)
> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
> introduced, but an extension is. When the extension is turned on,
> everything is as today, except when `main :: IO ExitCode`, in which case we
> program's exit code is the exit code returned by `main` (Simon PJ's
> favourite)
> That's it
> 
> ------
> 
> The summaries are based on the following examples. Each get a letter
> representing the behaviour under the proposal, as described in the legend
> 
> The examples:
> module Ex1 where {  ..; main :: IO Void }
> module Ex2 where {  ..; main :: IO () }
> module Ex3 where {  ..; main :: IO Int }
> module Ex4 where { ...; main :: IO ExitCode }   -- ExitCode exists already
> module Ex5 where { ...; main :: IO Bool }         -- No ExitStatus instance
> for Bool
> module Ex6 where { ...; data T = ..; main :: IO T; instance ExitStatus T
> where ... }
> 
> The legend:
> - 0: main exits with exit code 0 (success)
> - E: type error
> - W: a warning is emitted
> - T: the `ExitStatus` type class is used to select the exit code.
> - I: The exit code is the returned value (only apply to `main :: IO
> ExitCode`).
> - N: not available under this alternative
> 
> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> 
> > @SImonPJ I didn't include these two options because I hadn't understood
> > that they had any backing.
> >
> > Personally: I don't like (1c) and (4)
> >   - (1c) doesn't really address Shea's concern that the behaviour is
> > currently surprising, as you need to actively turn an extension on to have
> > the new behaviour, so you need to already know that the default behaviour
> > is counterintuitive.
> >   - (4) is weird without type classes. Like what happens if I `type T =
> > ExitCode; main :: IO T`? Certainly `main` must not return with exit code 0.
> >
> > We are having an issue here, the typical bikeshedding issue I imagine,
> > that there's about 1 proposal per member of the committee. I'm not sure how
> > to solve this efficiently, but I don't think it'll be easy to drive
> > consensus.
> >
> > I did ask Shea for his favoured options. He told me that if he can't have
> > 1a, he prefers 3a (I promise I didn't influence him!).
> >
> > On Thu, 28 Mar 2024 at 09:18, Simon Marlow <marlowsd at gmail.com> wrote:
> >
> >> I think we can discount 1a because it doesn't satisfy the stability
> >> principles, right?
> >>
> >> Out of the others, I would probably go with 1b or 3a as the most
> >> predictable behaviours. I also like Simon's (4) (gated by an extension,
> >> that we hope to enable in GHC2027).
> >>
> >> Cheers
> >> Simon
> >>
> >> On Tue, 26 Mar 2024 at 09:35, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> >> wrote:
> >>
> >>> Alright, so here are the plausible alternatives
> >>>
> >>> 1a. New type-class-based behaviour without extension
> >>> 1b. New type-class-based behaviour gated by an extension
> >>> 2. Just a warning (when main isn't at type IO () or IO Void)
> >>> 3a. A warning + the new type-class-based behaviour gated by an
> >>> extension. With the extension, types that don't implement the type class
> >>> raise an error.
> >>> 3b. A warning + the new type-class-based behaviour gated by an
> >>> extension. With the extension, types that don't implement the type class
> >>> raise a warning (which could have a different phrasing than without the
> >>> extension).
> >>>
> >>> Let's vote!
> >>>
> >>> On Fri, 22 Mar 2024 at 15:30, Malte Ott <malte.ott at maralorn.de> wrote:
> >>>
> >>>> On 2024-03-22 08:58, Arnaud Spiwack wrote:
> >>>> > @Malte, in my opinion, with the extension on, types which are not
> >>>> covered
> >>>> > by the type class should error out.
> >>>>
> >>>> Ah, I see. Well, I am fine either way.
> >>>>
> >>>> I just don’t see much value in deciding for the user which code
> >>>> problems are
> >>>> unacceptable. Especially since this will make the corresponding language
> >>>> extension more breaking and thus harder to make the default.
> >>>> Others have voiced similar opinions in the GitHub thread.
> >>>>
> >>>> Best
> >>>> Malte
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>
> >
> > --
> > Arnaud Spiwack
> > Director, Research at https://moduscreate.com and https://tweag.io.
> >
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.