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

Mon Apr 29 07:26:54 UTC 2024

Let me remind everybody of this thread: votes close on Wednesday.

Simon M, Simon PJ, Chris, Moritz, I'd love to have your opinion.

PS: Malte, I agree and I don't love the reduced choice either. But many
choices seemed to prevent opinions from coalescing. I don't think there's
an easy solution here. Generally, my opinion is that bikeshedding issues
aren't very-well suited to being resolved by committees. So we have to
compromise to move forward.

/Arnaud

On Mon, 22 Apr 2024 at 16:15, Arnaud Spiwack <arnaud.spiwack at tweag.io>
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.
>

-- 
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/20240429/613f9749/attachment.html>