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

Mon Apr 22 15:11:21 UTC 2024

I forgot to vote. Great job me!

Here's my vote:

3a
2
That's it.

On Mon, 22 Apr 2024 at 16:30, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

> My ranking is
>
> 4
> 3a
> 2
>
> That’s it.
>
>
> /Matti Palli
>
>
> On Mon, Apr 22, 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.
>> _______________________________________________
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240422/e5fe05d5/attachment.html>