<div dir="ltr"><div>@Malte, in my opinion, with the extension on, types which are not covered by the type class should error out.</div><div><br></div><div>I'd like to have some more understanding of what's feasible to implement. Adam, Simon PJ, could you share some insight there?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Mar 2024 at 00:19, Malte Ott <<a href="mailto:malte.ott@maralorn.de">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-19 15:15, Arnaud Spiwack wrote:<br>
> So, my opinion that I promised, is that the best would probably be to have<br>
> add a warning when main doesn't have type `IO ()` or `IO Void` without the<br>
> extension (the behaviour is otherwise unchanged), and then change the<br>
> behaviour to use the typeclass with an extension (which we hope to turn on<br>
> by default in the next language edition). The extension should probably<br>
><br>
> Now, I don't actually know how to implement this properly. So maybe it's a<br>
> bad idea. But I believe that's what I'd like to see.<br>
> disable the warning.<br>
<br>
>From my understanding that is basically equivalent to what I was proposing.<br>
It has the properties:<br>
<br>
* Using a return type which could reasonably be expected to exit with failure<br>
should warn on -Wdefault (no matter whether a potential extension is enabled).<br>
* Concretely this means any return type but (), Void and maybe forall a. a, when the extension is off.<br>
* The warning could point to existing instances and the extension.<br>
* For anything which does not have an ExitCode implementation, when the extension is on.<br>
* Using the ExitCode type class should be possible but gated behind an extension.<br>
<br>
Now the question whether we should have two different warnings, one when the<br>
extension is on and one when it is off or one warning which changes its wording<br>
and behavior slightly depending on the extension being enabled does not matter<br>
that much in my opinion.<br>
<br>
Best<br>
Malte<br>
<br>
> On Fri, 15 Mar 2024 at 15:32, Matthías Páll Gissurarson <<a href="mailto:mpg@mpg.is" target="_blank">mpg@mpg.is</a>> wrote:<br>
> <br>
> > I agree. I like it, but better behind an extension to avoid surprises and<br>
> > enable experimentation.<br>
> ><br>
> > On Fri, 15 Mar 2024 at 13:15, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br>
> ><br>
> >> I also think any change in behaviour should be behind an extension.<br>
> >><br>
> >> Cheers<br>
> >> Simon<br>
> >><br>
> >> On Thu, 14 Mar 2024 at 16:51, Simon Peyton Jones <<br>
> >> <a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
> >><br>
> >>> I like the proposal basically as is. i.e. typeclass + warning<br>
> >>> Especially the fact that it warns everyone and breaks no-one (who<br>
> >>> doesn’t want<br>
> >>> to).<br>
> >>><br>
> >>> I am weakly in favor of gating the usage of the typeclass for anything<br>
> >>> but ()<br>
> >>> and Void behind an extension. That way no program will newly exit with<br>
> >>> failure<br>
> >>> without the user opting in and we might be able to experiment more on<br>
> >>> the type<br>
> >>> class.<br>
> >>><br>
> >>><br>
> >>> I'm with Malte. But I don't have strongly held views.<br>
> >>><br>
> >>> Simon<br>
> >>><br>
> >>> On Thu, 14 Mar 2024 at 14:04, Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>> wrote:<br>
> >>><br>
> >>>> I like the proposal basically as is. i.e. typeclass + warning<br>
> >>>> Especially the fact that it warns everyone and breaks no-one (who<br>
> >>>> doesn’t want<br>
> >>>> to).<br>
> >>>><br>
> >>>> I am weakly in favor of gating the usage of the typeclass for anything<br>
> >>>> but ()<br>
> >>>> and Void behind an extension. That way no program will newly exit with<br>
> >>>> failure<br>
> >>>> without the user opting in and we might be able to experiment more on<br>
> >>>> the type<br>
> >>>> class.<br>
> >>>><br>
> >>>> Best<br>
> >>>> Malte<br>
> >>>><br>
> >>>> On 2024-03-14 14:32, Arnaud Spiwack wrote:<br>
> >>>> > Dear all,<br>
> >>>> ><br>
> >>>> > Shea has updated his proposal based on the committee's feedback.<br>
> >>>> ><br>
> >>>> > There seem to be two main alternatives being considered at the moment<br>
> >>>> > - Having a type class to compute the exit code based on the type.<br>
> >>>> This is<br>
> >>>> > Shea's favourite. It can be done without an extension (as Shea's<br>
> >>>> proposing)<br>
> >>>> > or with an extension.<br>
> >>>> > - Keep the current behaviour but emit a warning when the return type<br>
> >>>> of<br>
> >>>> > `main` isn't `()` or `Void`.<br>
> >>>> ><br>
> >>>> > I have opinions about my preference, but I'd like to hear about<br>
> >>>> everybody's<br>
> >>>> > thoughts first.<br>
> >>>> ><br>
> >>>> > On Thu, 7 Mar 2024 at 10:27, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:<br>
> >>>> ><br>
> >>>> > > I've added a comment to the GitHub thread<br>
> >>>> > > (<br>
> >>>> > ><br>
> >>>> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1983060484" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1983060484</a><br>
> >>>> )<br>
> >>>> > ><br>
> >>>> > > elaborating slightly on Richard's suggestion (albeit with an<br>
> >>>> effectively<br>
> >>>> > > indefinite transition period).<br>
> >>>> > ><br>
> >>>> > > Adam<br>
> >>>> > ><br>
> >>>> > ><br>
> >>>> > > On 05/03/2024 08:52, Arnaud Spiwack wrote:<br>
> >>>> > > > This is Alternative 7.5 in the current version of the proposal<br>
> >>>> > > ><br>
> >>>> > ><br>
> >>>> <a href="https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance" rel="noreferrer" target="_blank">https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance</a><br>
> >>>> > > <<br>
> >>>> > ><br>
> >>>> <a href="https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance" rel="noreferrer" target="_blank">https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance</a><br>
> >>>> ><br>
> >>>> > > .<br>
> >>>> > > ><br>
> >>>> > > > PS: I tend to agree with Richard that requiring an ExitStatus<br>
> >>>> instance<br>
> >>>> > > > is the preferable option. But food for thought for the proposal<br>
> >>>> thread<br>
> >>>> > > > when that conversation happens there: should that be gated behind<br>
> >>>> an<br>
> >>>> > > > extension? In which case it won't become the default before the<br>
> >>>> next<br>
> >>>> > > > language edition.<br>
> >>>> > > ><br>
> >>>> > > > /Arnaud<br>
> >>>> > > ><br>
> >>>> > > > On Mon, 4 Mar 2024 at 21:35, Simon Peyton Jones<br>
> >>>> > > > <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a> <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> >>>> >><br>
> >>>> > > wrote:<br>
> >>>> > > ><br>
> >>>> > > > I left out a key part of my last email -- apologies. I'm<br>
> >>>> > > > floating a counter-proposal where we *require* an<br>
> >>>> instance of<br>
> >>>> > > > ExitStatus on the return type of `main`, with a transition<br>
> >>>> > > > period. In contrast, my understanding of the proposal<br>
> >>>> written is<br>
> >>>> > > > that it would use such an instance if it exists, but<br>
> >>>> issue a<br>
> >>>> > > > warning if it doesn't, in perpetuity.<br>
> >>>> > > ><br>
> >>>> > > ><br>
> >>>> > > > Ah I had not realised that.<br>
> >>>> > > ><br>
> >>>> > > > But why?<br>
> >>>> > > ><br>
> >>>> > > > Rather than answer here (private to SC) why don't you put your<br>
> >>>> > > > proposal on the discussion thread, say why, and invite<br>
> >>>> feedback.<br>
> >>>> > > ><br>
> >>>> > > > Simon<br>
> >>>> > > ><br>
> >>>> > > ><br>
> >>>> > > > On Mon, 4 Mar 2024 at 19:24, Richard Eisenberg<br>
> >>>> > > > <<a href="mailto:reisenberg@janestreet.com" target="_blank">reisenberg@janestreet.com</a> <mailto:<a href="mailto:reisenberg@janestreet.com" target="_blank">reisenberg@janestreet.com</a><br>
> >>>> >><br>
> >>>> > > wrote:<br>
> >>>> > > ><br>
> >>>> > > > I left out a key part of my last email -- apologies. I'm<br>
> >>>> > > > floating a counter-proposal where we *require* an<br>
> >>>> instance of<br>
> >>>> > > > ExitStatus on the return type of `main`, with a transition<br>
> >>>> > > > period. In contrast, my understanding of the proposal<br>
> >>>> written is<br>
> >>>> > > > that it would use such an instance if it exists, but<br>
> >>>> issue a<br>
> >>>> > > > warning if it doesn't, in perpetuity.<br>
> >>>> > > ><br>
> >>>> > > > Richard<br>
> >>>> > > ><br>
> >>>> > > > On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones<br>
> >>>> > > > <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> >>>> > > > <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>> wrote:<br>
> >>>> > > ><br>
> >>>> > > > I am a little worried about breaking programs<br>
> >>>> that end<br>
> >>>> > > > in an innocent-looking `return 0`, just because<br>
> >>>> some<br>
> >>>> > > > other languages like to end programs with that<br>
> >>>> phrase<br>
> >>>> > > ><br>
> >>>> > > ><br>
> >>>> > > > The proposal specifies that such a program returns<br>
> >>>> > > > `ExitSuccess`, but adds a warning. That seems OK to<br>
> >>>> me; it<br>
> >>>> > > > does not break the program.<br>
> >>>> > > ><br>
> >>>> > > > Oh -- maybe you mean that `return 1` means "return<br>
> >>>> with exit<br>
> >>>> > > > code 1" today. Is that really true? I don't think<br>
> >>>> so.<br>
> >>>> > > ><br>
> >>>> > > > Overall this proposal seems fine to me. I'd be happy<br>
> >>>> to see<br>
> >>>> > > > it done.<br>
> >>>> > > ><br>
> >>>> > > > Simon<br>
> >>>> > > ><br>
> >>>> > > > On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg<br>
> >>>> > > > <<a href="mailto:reisenberg@janestreet.com" target="_blank">reisenberg@janestreet.com</a><br>
> >>>> > > > <mailto:<a href="mailto:reisenberg@janestreet.com" target="_blank">reisenberg@janestreet.com</a>>> wrote:<br>
> >>>> > > ><br>
> >>>> > > > I haven't followed this proposal closely. But<br>
> >>>> couldn't<br>
> >>>> > > > we have a transition period toward this eventual<br>
> >>>> goal?<br>
> >>>> > > > That is, introduce a new warning, on by default,<br>
> >>>> if<br>
> >>>> > > > `main` returns anything other than `()`. That<br>
> >>>> goes for a<br>
> >>>> > > > few releases. Then we require that the return<br>
> >>>> type of<br>
> >>>> > > > main has an instance of ExitStatus.<br>
> >>>> > > ><br>
> >>>> > > > I'm not worried about changing the behavior of<br>
> >>>> programs<br>
> >>>> > > > that have type IO ExitCode but expect the program<br>
> >>>> to<br>
> >>>> > > > return 0 unconditionally; that's just begging for<br>
> >>>> > > > confusion. I am a little worried about breaking<br>
> >>>> programs<br>
> >>>> > > > that end in an innocent-looking `return 0`, just<br>
> >>>> because<br>
> >>>> > > > some other languages like to end programs with<br>
> >>>> that<br>
> >>>> > > > phrase. So I'm not sure if we should have an<br>
> >>>> instance<br>
> >>>> > > > ExitStatus Int (or instance ExitStatus Integer)<br>
> >>>> -- but<br>
> >>>> > > > we probably should. If a program ends with<br>
> >>>> `return 1`,<br>
> >>>> > > > the programmer probably wants the OS to return 1<br>
> >>>> as well.<br>
> >>>> > > ><br>
> >>>> > > > Richard<br>
> >>>> > > ><br>
> >>>> > > > On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack<br>
> >>>> > > > <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
> >>>> > > > <mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>> wrote:<br>
> >>>> > > ><br>
> >>>> > > > Dear all,<br>
> >>>> > > ><br>
> >>>> > > > Shea Levy proposes to do something with the<br>
> >>>> values<br>
> >>>> > > > returned by `main`<br>
> >>>> > > ><br>
> >>>> > > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/631" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/631</a> <<br>
> >>>> > > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/631" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/631</a>> .<br>
> >>>> > > ><br>
> >>>> > > > The problem is that `main` is allowed to be<br>
> >>>> of type<br>
> >>>> > > > `IO A` for any `A`. And GHC will simply drop<br>
> >>>> the<br>
> >>>> > > > value returned by `main`. Shea contends that<br>
> >>>> it's<br>
> >>>> > > > surprising. I agree that dropping a value<br>
> >>>> without<br>
> >>>> > > > the compiler being explicitly instructed to is<br>
> >>>> > > > surprising. But Shea says that when `A` is<br>
> >>>> > > > `ExitCode` this is even more surprising.<br>
> >>>> Namely<br>
> >>>> > > > `main :: IO ExitCode; main = return $ Failure<br>
> >>>> 1`<br>
> >>>> > > > actually terminates with exit code 0. And I<br>
> >>>> doubt<br>
> >>>> > > > that it's what anybody expects when reading<br>
> >>>> the code.<br>
> >>>> > > ><br>
> >>>> > > > The proposal is simple, but I have a lot of<br>
> >>>> comments<br>
> >>>> > > > on it. Sorry about that…<br>
> >>>> > > ><br>
> >>>> > > > Now, this sort of proposal is tricky. When the<br>
> >>>> > > > current behaviour is confusing, we want to<br>
> >>>> change<br>
> >>>> > > > the default. But putting the new default<br>
> >>>> behind an<br>
> >>>> > > > extension doesn't really solve the fact that<br>
> >>>> there's<br>
> >>>> > > > a trap. The extension is, therefore, unlikely<br>
> >>>> to be<br>
> >>>> > > > well tested before it becomes part of the next<br>
> >>>> > > > language edition.<br>
> >>>> > > ><br>
> >>>> > > > Shea's main proposition doesn't actually use<br>
> >>>> an<br>
> >>>> > > > extension though. He adds a type class<br>
> >>>> `ExitStatus`,<br>
> >>>> > > > and if `ExistStatus A`, then `main :: IO A`<br>
> >>>> uses the<br>
> >>>> > > > instance to determine the exit code based on<br>
> >>>> the<br>
> >>>> > > > return value.<br>
> >>>> > > ><br>
> >>>> > > > The only change to the current behaviour is<br>
> >>>> that<br>
> >>>> > > > `main :: IO ExitCode` instead of always<br>
> >>>> terminating<br>
> >>>> > > > with exit code 0 when returning now<br>
> >>>> terminates with<br>
> >>>> > > > the expected error code. The argument for not<br>
> >>>> > > > putting this behind an extension is that<br>
> >>>> virtually<br>
> >>>> > > > anybody affected by the change will actually<br>
> >>>> have<br>
> >>>> > > > the behaviour they were expecting. But maybe<br>
> >>>> the<br>
> >>>> > > > argument isn't strong enough (the changes may<br>
> >>>> be<br>
> >>>> > > > more “interesting” if some library exports<br>
> >>>> some<br>
> >>>> > > > `ExistStatus` instance).<br>
> >>>> > > ><br>
> >>>> > > > This design of this proposal is inspired by<br>
> >>>> Rust's<br>
> >>>> > > > design. I've asked our Rust team, and they<br>
> >>>> certainly<br>
> >>>> > > > seem to have internalised the idea of<br>
> >>>> returning an<br>
> >>>> > > > exit code. It really seems a pretty natural<br>
> >>>> feature<br>
> >>>> > > > to have. So I'm rather in favour of some<br>
> >>>> flavour of<br>
> >>>> > > > the type class implementation. Though have a<br>
> >>>> look at<br>
> >>>> > > > the alternatives, where you'll find other<br>
> >>>> approaches<br>
> >>>> > > > such as restricting the type of `main` to<br>
> >>>> > > > unsurprising types.<br>
> >>>> > > ><br>
> >>>> > > > One caveat with respect to the main proposal:<br>
> >>>> it is<br>
> >>>> > > > proposed that when no `ExistStatus A` is<br>
> >>>> found, then<br>
> >>>> > > > we drop the returned value like today. I<br>
> >>>> don't know<br>
> >>>> > > > that it's quite easy to implement this<br>
> >>>> behaviour.<br>
> >>>> > > > But it can be recovered by a catch-all<br>
> >>>> overlapping<br>
> >>>> > > > instance, so maybe it's a better way to<br>
> >>>> specify the<br>
> >>>> > > > desired behaviour.<br>
> >>>> > > ><br>
> >>>> > > > --<br>
> >>>> > > > Arnaud Spiwack<br>
> >>>> > > > Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a><br>
> >>>> > > > <<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a>> and<br>
> >>>> <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a><br>
> >>>> > > > <<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>>.<br>
> >>>> > ><br>
> >>>> > ><br>
> >>>> > > --<br>
> >>>> > > Adam Gundry, Haskell Consultant<br>
> >>>> > > Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
> >>>> > ><br>
> >>>> > > Registered in England & Wales, OC335890<br>
> >>>> > > 27 Old Gloucester Street, London WC1N 3AX, England<br>
> >>>> > ><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>
> >>>> > ><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>
> >>>> > ><br>
> >>>> ><br>
> >>>> ><br>
> >>>> > --<br>
> >>>> > Arnaud Spiwack<br>
> >>>> > Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> >>>><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>
> >>>> ><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>
> >>>><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>
> >>>><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>
> >>><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>
> >><br>
> ><br>
> ><br>
> > --<br>
> > -- Matthías Páll Gissurarson <<a href="http://mpg.is/" rel="noreferrer" target="_blank">http://mpg.is/</a>><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>
> ><br>
> <br>
> <br>
> -- <br>
> Arnaud Spiwack<br>
> Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
<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>
<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>