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

[Arnaud Spiwack]

@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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240328/43850197/attachment.html>