<div dir="ltr"><div>I forgot to vote. Great job me!</div><div><br></div><div>Here's my vote:</div><div><br></div><div>3a</div><div>2</div><div>That's it.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 22 Apr 2024 at 16:30, Matthías Páll Gissurarson <<a href="mailto:mpg@mpg.is" target="_blank">mpg@mpg.is</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">My ranking is</div><div dir="auto"><br></div><div dir="auto">4</div><div dir="auto">3a</div><div dir="auto">2</div><div dir="auto"><br></div><div dir="auto">That’s it.</div><div dir="auto"><br clear="all"><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature">/Matti Palli</div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2024 at 16:15 Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div><b>I'm calling for a vote</b> 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</div><div><br></div><div>I'm leaving the vote open until <b>Wednesday 1st May</b>. After which, I'll tally, and synthesise the committee's final position.<br></div><div><br></div><div>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)<br></div><div>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)<br></div><div>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)</div><div>That's it<br></div><div><br></div><div>------</div><div><br></div><div>The summaries are based on the following examples. Each get a letter representing the behaviour under the proposal, as described in the legend<br></div><div><div><br></div><div>The examples:</div><div><span><div class="gmail_default" style="font-family:tahoma,sans-serif">
<div class="gmail_default" style="font-family:tahoma,sans-serif">module Ex1 where {  ..; <span>main</span> :: IO Void }</div>


<div class="gmail_default" style="font-family:tahoma,sans-serif">module Ex2 where {  ..; <span>main</span> :: IO () }</div>

module Ex3 where {  ..; <span>main</span> :: IO Int }</div><div class="gmail_default" style="font-family:tahoma,sans-serif">module Ex4 where { ...; <span>main</span> :: IO ExitCode }   -- ExitCode exists already</div><div class="gmail_default" style="font-family:tahoma,sans-serif">module Ex5 where { ...; <span>main</span> :: IO Bool }         -- No ExitStatus instance for Bool<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">module Ex6 where { ...; data T = ..; <span>main</span> :: IO T; instance ExitStatus T where ... }</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></span></div></div><div><div>The legend:</div><div>- 0: <span>main</span> exits with exit code 0 (success)<br></div><div>- E: type error</div><div>- W: a warning is emitted</div><div>- T: the `ExitStatus` type class is used to select the exit code.</div><div>- I: The exit code is the returned value (only apply to `main :: IO ExitCode`).<br></div></div></div><div dir="ltr"><div><div>- N: not available under this alternative<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>@SImonPJ I didn't include these two options because I hadn't understood that they had any backing.</div><div><br></div><div>Personally: I don't like (1c) and (4)</div><div>  - (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.</div><div>  - (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.</div><div><br></div><div>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.</div><div><br></div><div>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!).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Mar 2024 at 09:18, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I think we can discount 1a because it doesn't satisfy the stability principles, right?</div><div><br></div><div>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).<br></div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Mar 2024 at 09:35, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Alright, so here are the plausible alternatives</div><div><br></div><div>1a. New type-class-based behaviour without extension</div><div>1b.  New type-class-based behaviour gated by an extension</div><div>2. Just a warning (when main isn't at type IO () or IO Void)</div><div>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.</div><div>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).</div><div><br></div><div>Let's vote!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Mar 2024 at 15:30, Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2024-03-22 08:58, Arnaud Spiwack wrote:<br>
> @Malte, in my opinion, with the extension on, types which are not covered<br>
> by the type class should error out.<br>
<br>
Ah, I see. Well, I am fine either way.<br>
<br>
I just don’t see much value in deciding for the user which code problems are<br>
unacceptable. Especially since this will make the corresponding language<br>
extension more breaking and thus harder to make the default.<br>
Others have voiced similar opinions in the GitHub thread.<br>
<br>
Best<br>
Malte<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>