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

[Simon Peyton Jones]

I'm sorry Arnaud, but my brain is insufficiently large to accommodate the
implications of five different briefly specified options.   Would you (or
Shea) like to specify them more precisely, perhaps on GH since email
threads are harder to follow (and it allows others to contribute).  I think
it would help to give some examples to illustrate the consequences of each.

Here's the kind of thing I mean (below).

Also can we check with Shea that he is content with these options?  It's
his proposal

Simon


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 ... }

*Option 1: a warning when main isn't at type IO () or IO Void*

   - A warning on Ex3-6.
   - Ex4 returns exit code 0
   - Is this warning on by default?  Can it be suppressed?  (Rather than
   provide -Wnoxxx flag, we could just say "change the code to return ()"

*Option 2: New type-class-based behaviour without extension *

   - Ex1,2,4.6 work fine
   - Ex4 returns the specified exit code.
   - Ex3, and Ex5 yields "no instance for ExitStatus Int" (and Bool resp)

*Option 2a: Like Option 2 but with warning*

   - Ex3 and Ex5 yield a warning not at error; but run fine


*Option 3: New type-class-based behaviour with extension *

   - Without -XWombat: like Option 1
   - With -XWombat: like Option

*Option 3a: Like Option 3 but with warning*

   - With -XWombat, Ex3 and Ex5 yield a warning not at error; but run fine


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