From simon.peytonjones at gmail.com  Mon Mar  4 11:13:50 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 4 Mar 2024 11:13:50 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
Message-ID: <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>

I am a little worried about breaking programs that end in an
innocent-looking `return 0`, just because some other languages like to end
programs with that phrase


The proposal specifies that such a program returns `ExitSuccess`, but adds
a warning. That seems OK to me; it does not break the program.

Oh -- maybe you mean that `return 1` means "return with exit code 1"
today.  Is that really true?  I don't think so.

Overall this proposal seems fine to me.  I'd be happy to see it done.

Simon

On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg <reisenberg at janestreet.com>
wrote:

> I haven't followed this proposal closely. But couldn't we have a
> transition period toward this eventual goal? That is, introduce a new
> warning, on by default, if `main` returns anything other than `()`. That
> goes for a few releases. Then we require that the return type of main has
> an instance of ExitStatus.
>
> I'm not worried about changing the behavior of programs that have type IO
> ExitCode but expect the program to return 0 unconditionally; that's just
> begging for confusion. I am a little worried about breaking programs that
> end in an innocent-looking `return 0`, just because some other languages
> like to end programs with that phrase. So I'm not sure if we should have an
> instance ExitStatus Int (or instance ExitStatus Integer) -- but we probably
> should. If a program ends with `return 1`, the programmer probably wants
> the OS to return 1 as well.
>
> Richard
>
> On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> Shea Levy proposes to do something with the values returned by `main`
>> https://github.com/ghc-proposals/ghc-proposals/pull/631 .
>>
>> The problem is that `main` is allowed to be of type `IO A` for any `A`.
>> And GHC will simply drop the value returned by `main`. Shea contends that
>> it's surprising. I agree that dropping a value without the compiler being
>> explicitly instructed to is surprising. But Shea says that when `A` is
>> `ExitCode` this is even more surprising. Namely `main :: IO ExitCode; main
>> = return $ Failure 1` actually terminates with exit code 0. And I doubt
>> that it's what anybody expects when reading the code.
>>
>> The proposal is simple, but I have a lot of comments on it. Sorry about
>> that…
>>
>> Now, this sort of proposal is tricky. When the current behaviour is
>> confusing, we want to change the default. But putting the new default
>> behind an extension doesn't really solve the fact that there's a trap. The
>> extension is, therefore, unlikely to be well tested before it becomes part
>> of the next language edition.
>>
>> Shea's main proposition doesn't actually use an extension though. He adds
>> a type class `ExitStatus`, and if `ExistStatus A`, then `main :: IO A` uses
>> the instance to determine the exit code based on the return value.
>>
>> The only change to the current behaviour is that `main :: IO ExitCode`
>> instead of always terminating with exit code 0 when returning now
>> terminates with the expected error code. The argument for not putting this
>> behind an extension is that virtually anybody affected by the change will
>> actually have the behaviour they were expecting. But maybe the argument
>> isn't strong enough (the changes may be more “interesting” if some library
>> exports some `ExistStatus` instance).
>>
>> This design of this proposal is inspired by Rust's design. I've asked our
>> Rust team, and they certainly seem to have internalised the idea of
>> returning an exit code. It really seems a pretty natural feature to have.
>> So I'm rather in favour of some flavour of the type class implementation.
>> Though have a look at the alternatives, where you'll find other approaches
>> such as restricting the type of `main` to unsurprising types.
>>
>> One caveat with respect to the main proposal: it is proposed that when no
>> `ExistStatus A` is found, then we drop the returned value like today. I
>> don't know that it's quite easy to implement this behaviour. But it can be
>> recovered by a catch-all overlapping instance, so maybe it's a better way
>> to specify the desired behaviour.
>>
>> --
>> 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
>>
> _______________________________________________
> 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/20240304/1e9ec1c1/attachment.html>

From reisenberg at janestreet.com  Mon Mar  4 19:24:06 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Mon, 4 Mar 2024 14:24:06 -0500
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
Message-ID: <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>

I left out a key part of my last email -- apologies. I'm floating a
counter-proposal where we *require* an instance of ExitStatus on the return
type of `main`, with a transition period. In contrast, my understanding of
the proposal written is that it would use such an instance if it exists,
but issue a warning if it doesn't, in perpetuity.

Richard

On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I am a little worried about breaking programs that end in an
> innocent-looking `return 0`, just because some other languages like to end
> programs with that phrase
>
>
> The proposal specifies that such a program returns `ExitSuccess`, but adds
> a warning. That seems OK to me; it does not break the program.
>
> Oh -- maybe you mean that `return 1` means "return with exit code 1"
> today.  Is that really true?  I don't think so.
>
> Overall this proposal seems fine to me.  I'd be happy to see it done.
>
> Simon
>
> On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg <reisenberg at janestreet.com>
> wrote:
>
>> I haven't followed this proposal closely. But couldn't we have a
>> transition period toward this eventual goal? That is, introduce a new
>> warning, on by default, if `main` returns anything other than `()`. That
>> goes for a few releases. Then we require that the return type of main has
>> an instance of ExitStatus.
>>
>> I'm not worried about changing the behavior of programs that have type IO
>> ExitCode but expect the program to return 0 unconditionally; that's just
>> begging for confusion. I am a little worried about breaking programs that
>> end in an innocent-looking `return 0`, just because some other languages
>> like to end programs with that phrase. So I'm not sure if we should have an
>> instance ExitStatus Int (or instance ExitStatus Integer) -- but we probably
>> should. If a program ends with `return 1`, the programmer probably wants
>> the OS to return 1 as well.
>>
>> Richard
>>
>> On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>> Shea Levy proposes to do something with the values returned by `main`
>>> https://github.com/ghc-proposals/ghc-proposals/pull/631 .
>>>
>>> The problem is that `main` is allowed to be of type `IO A` for any `A`.
>>> And GHC will simply drop the value returned by `main`. Shea contends that
>>> it's surprising. I agree that dropping a value without the compiler being
>>> explicitly instructed to is surprising. But Shea says that when `A` is
>>> `ExitCode` this is even more surprising. Namely `main :: IO ExitCode; main
>>> = return $ Failure 1` actually terminates with exit code 0. And I doubt
>>> that it's what anybody expects when reading the code.
>>>
>>> The proposal is simple, but I have a lot of comments on it. Sorry about
>>> that…
>>>
>>> Now, this sort of proposal is tricky. When the current behaviour is
>>> confusing, we want to change the default. But putting the new default
>>> behind an extension doesn't really solve the fact that there's a trap. The
>>> extension is, therefore, unlikely to be well tested before it becomes part
>>> of the next language edition.
>>>
>>> Shea's main proposition doesn't actually use an extension though. He
>>> adds a type class `ExitStatus`, and if `ExistStatus A`, then `main :: IO A`
>>> uses the instance to determine the exit code based on the return value.
>>>
>>> The only change to the current behaviour is that `main :: IO ExitCode`
>>> instead of always terminating with exit code 0 when returning now
>>> terminates with the expected error code. The argument for not putting this
>>> behind an extension is that virtually anybody affected by the change will
>>> actually have the behaviour they were expecting. But maybe the argument
>>> isn't strong enough (the changes may be more “interesting” if some library
>>> exports some `ExistStatus` instance).
>>>
>>> This design of this proposal is inspired by Rust's design. I've asked
>>> our Rust team, and they certainly seem to have internalised the idea of
>>> returning an exit code. It really seems a pretty natural feature to have.
>>> So I'm rather in favour of some flavour of the type class implementation.
>>> Though have a look at the alternatives, where you'll find other approaches
>>> such as restricting the type of `main` to unsurprising types.
>>>
>>> One caveat with respect to the main proposal: it is proposed that when
>>> no `ExistStatus A` is found, then we drop the returned value like today. I
>>> don't know that it's quite easy to implement this behaviour. But it can be
>>> recovered by a catch-all overlapping instance, so maybe it's a better way
>>> to specify the desired behaviour.
>>>
>>> --
>>> 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
>>>
>> _______________________________________________
>> 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/20240304/886d3912/attachment.html>

From simon.peytonjones at gmail.com  Mon Mar  4 20:35:10 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 4 Mar 2024 20:35:10 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
Message-ID: <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>

>
> I left out a key part of my last email -- apologies. I'm floating a
> counter-proposal where we *require* an instance of ExitStatus on the return
> type of `main`, with a transition period. In contrast, my understanding of
> the proposal written is that it would use such an instance if it exists,
> but issue a warning if it doesn't, in perpetuity.


Ah  I had not realised that.

But why?

Rather than answer here (private to SC) why don't you put your proposal on
the discussion thread, say why, and invite feedback.

Simon


On Mon, 4 Mar 2024 at 19:24, Richard Eisenberg <reisenberg at janestreet.com>
wrote:

> I left out a key part of my last email -- apologies. I'm floating a
> counter-proposal where we *require* an instance of ExitStatus on the return
> type of `main`, with a transition period. In contrast, my understanding of
> the proposal written is that it would use such an instance if it exists,
> but issue a warning if it doesn't, in perpetuity.
>
> Richard
>
> On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I am a little worried about breaking programs that end in an
>> innocent-looking `return 0`, just because some other languages like to end
>> programs with that phrase
>>
>>
>> The proposal specifies that such a program returns `ExitSuccess`, but
>> adds a warning. That seems OK to me; it does not break the program.
>>
>> Oh -- maybe you mean that `return 1` means "return with exit code 1"
>> today.  Is that really true?  I don't think so.
>>
>> Overall this proposal seems fine to me.  I'd be happy to see it done.
>>
>> Simon
>>
>> On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg <
>> reisenberg at janestreet.com> wrote:
>>
>>> I haven't followed this proposal closely. But couldn't we have a
>>> transition period toward this eventual goal? That is, introduce a new
>>> warning, on by default, if `main` returns anything other than `()`. That
>>> goes for a few releases. Then we require that the return type of main has
>>> an instance of ExitStatus.
>>>
>>> I'm not worried about changing the behavior of programs that have type
>>> IO ExitCode but expect the program to return 0 unconditionally; that's just
>>> begging for confusion. I am a little worried about breaking programs that
>>> end in an innocent-looking `return 0`, just because some other languages
>>> like to end programs with that phrase. So I'm not sure if we should have an
>>> instance ExitStatus Int (or instance ExitStatus Integer) -- but we probably
>>> should. If a program ends with `return 1`, the programmer probably wants
>>> the OS to return 1 as well.
>>>
>>> Richard
>>>
>>> On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> Shea Levy proposes to do something with the values returned by `main`
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/631 .
>>>>
>>>> The problem is that `main` is allowed to be of type `IO A` for any `A`.
>>>> And GHC will simply drop the value returned by `main`. Shea contends that
>>>> it's surprising. I agree that dropping a value without the compiler being
>>>> explicitly instructed to is surprising. But Shea says that when `A` is
>>>> `ExitCode` this is even more surprising. Namely `main :: IO ExitCode; main
>>>> = return $ Failure 1` actually terminates with exit code 0. And I doubt
>>>> that it's what anybody expects when reading the code.
>>>>
>>>> The proposal is simple, but I have a lot of comments on it. Sorry about
>>>> that…
>>>>
>>>> Now, this sort of proposal is tricky. When the current behaviour is
>>>> confusing, we want to change the default. But putting the new default
>>>> behind an extension doesn't really solve the fact that there's a trap. The
>>>> extension is, therefore, unlikely to be well tested before it becomes part
>>>> of the next language edition.
>>>>
>>>> Shea's main proposition doesn't actually use an extension though. He
>>>> adds a type class `ExitStatus`, and if `ExistStatus A`, then `main :: IO A`
>>>> uses the instance to determine the exit code based on the return value.
>>>>
>>>> The only change to the current behaviour is that `main :: IO ExitCode`
>>>> instead of always terminating with exit code 0 when returning now
>>>> terminates with the expected error code. The argument for not putting this
>>>> behind an extension is that virtually anybody affected by the change will
>>>> actually have the behaviour they were expecting. But maybe the argument
>>>> isn't strong enough (the changes may be more “interesting” if some library
>>>> exports some `ExistStatus` instance).
>>>>
>>>> This design of this proposal is inspired by Rust's design. I've asked
>>>> our Rust team, and they certainly seem to have internalised the idea of
>>>> returning an exit code. It really seems a pretty natural feature to have.
>>>> So I'm rather in favour of some flavour of the type class implementation.
>>>> Though have a look at the alternatives, where you'll find other approaches
>>>> such as restricting the type of `main` to unsurprising types.
>>>>
>>>> One caveat with respect to the main proposal: it is proposed that when
>>>> no `ExistStatus A` is found, then we drop the returned value like today. I
>>>> don't know that it's quite easy to implement this behaviour. But it can be
>>>> recovered by a catch-all overlapping instance, so maybe it's a better way
>>>> to specify the desired behaviour.
>>>>
>>>> --
>>>> 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
>>>>
>>> _______________________________________________
>>> 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/20240304/f01413b9/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Mar  5 08:52:51 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 5 Mar 2024 09:52:51 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
Message-ID: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>

This is Alternative 7.5 in the current version of the proposal
https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance
.

PS: I tend to agree with Richard that requiring an ExitStatus instance is
the preferable option. But food for thought for the proposal thread when
that conversation happens there: should that be gated behind an extension?
In which case it won't become the default before the next language edition.

/Arnaud

On Mon, 4 Mar 2024 at 21:35, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> I left out a key part of my last email -- apologies. I'm floating a
>> counter-proposal where we *require* an instance of ExitStatus on the return
>> type of `main`, with a transition period. In contrast, my understanding of
>> the proposal written is that it would use such an instance if it exists,
>> but issue a warning if it doesn't, in perpetuity.
>
>
> Ah  I had not realised that.
>
> But why?
>
> Rather than answer here (private to SC) why don't you put your proposal on
> the discussion thread, say why, and invite feedback.
>
> Simon
>
>
> On Mon, 4 Mar 2024 at 19:24, Richard Eisenberg <reisenberg at janestreet.com>
> wrote:
>
>> I left out a key part of my last email -- apologies. I'm floating a
>> counter-proposal where we *require* an instance of ExitStatus on the return
>> type of `main`, with a transition period. In contrast, my understanding of
>> the proposal written is that it would use such an instance if it exists,
>> but issue a warning if it doesn't, in perpetuity.
>>
>> Richard
>>
>> On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I am a little worried about breaking programs that end in an
>>> innocent-looking `return 0`, just because some other languages like to end
>>> programs with that phrase
>>>
>>>
>>> The proposal specifies that such a program returns `ExitSuccess`, but
>>> adds a warning. That seems OK to me; it does not break the program.
>>>
>>> Oh -- maybe you mean that `return 1` means "return with exit code 1"
>>> today.  Is that really true?  I don't think so.
>>>
>>> Overall this proposal seems fine to me.  I'd be happy to see it done.
>>>
>>> Simon
>>>
>>> On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg <
>>> reisenberg at janestreet.com> wrote:
>>>
>>>> I haven't followed this proposal closely. But couldn't we have a
>>>> transition period toward this eventual goal? That is, introduce a new
>>>> warning, on by default, if `main` returns anything other than `()`. That
>>>> goes for a few releases. Then we require that the return type of main has
>>>> an instance of ExitStatus.
>>>>
>>>> I'm not worried about changing the behavior of programs that have type
>>>> IO ExitCode but expect the program to return 0 unconditionally; that's just
>>>> begging for confusion. I am a little worried about breaking programs that
>>>> end in an innocent-looking `return 0`, just because some other languages
>>>> like to end programs with that phrase. So I'm not sure if we should have an
>>>> instance ExitStatus Int (or instance ExitStatus Integer) -- but we probably
>>>> should. If a program ends with `return 1`, the programmer probably wants
>>>> the OS to return 1 as well.
>>>>
>>>> Richard
>>>>
>>>> On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> Shea Levy proposes to do something with the values returned by `main`
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/631 .
>>>>>
>>>>> The problem is that `main` is allowed to be of type `IO A` for any
>>>>> `A`. And GHC will simply drop the value returned by `main`. Shea contends
>>>>> that it's surprising. I agree that dropping a value without the compiler
>>>>> being explicitly instructed to is surprising. But Shea says that when `A`
>>>>> is `ExitCode` this is even more surprising. Namely `main :: IO ExitCode;
>>>>> main = return $ Failure 1` actually terminates with exit code 0. And I
>>>>> doubt that it's what anybody expects when reading the code.
>>>>>
>>>>> The proposal is simple, but I have a lot of comments on it. Sorry
>>>>> about that…
>>>>>
>>>>> Now, this sort of proposal is tricky. When the current behaviour is
>>>>> confusing, we want to change the default. But putting the new default
>>>>> behind an extension doesn't really solve the fact that there's a trap. The
>>>>> extension is, therefore, unlikely to be well tested before it becomes part
>>>>> of the next language edition.
>>>>>
>>>>> Shea's main proposition doesn't actually use an extension though. He
>>>>> adds a type class `ExitStatus`, and if `ExistStatus A`, then `main :: IO A`
>>>>> uses the instance to determine the exit code based on the return value.
>>>>>
>>>>> The only change to the current behaviour is that `main :: IO ExitCode`
>>>>> instead of always terminating with exit code 0 when returning now
>>>>> terminates with the expected error code. The argument for not putting this
>>>>> behind an extension is that virtually anybody affected by the change will
>>>>> actually have the behaviour they were expecting. But maybe the argument
>>>>> isn't strong enough (the changes may be more “interesting” if some library
>>>>> exports some `ExistStatus` instance).
>>>>>
>>>>> This design of this proposal is inspired by Rust's design. I've asked
>>>>> our Rust team, and they certainly seem to have internalised the idea of
>>>>> returning an exit code. It really seems a pretty natural feature to have.
>>>>> So I'm rather in favour of some flavour of the type class implementation.
>>>>> Though have a look at the alternatives, where you'll find other approaches
>>>>> such as restricting the type of `main` to unsurprising types.
>>>>>
>>>>> One caveat with respect to the main proposal: it is proposed that when
>>>>> no `ExistStatus A` is found, then we drop the returned value like today. I
>>>>> don't know that it's quite easy to implement this behaviour. But it can be
>>>>> recovered by a catch-all overlapping instance, so maybe it's a better way
>>>>> to specify the desired behaviour.
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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/20240305/0078e522/attachment.html>

From adam at well-typed.com  Wed Mar  6 07:53:22 2024
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 6 Mar 2024 07:53:22 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
 =?utf-8?q?s=2C_and_other_membership_changes?=
Message-ID: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>

Dear all,

Following the recent nomination round, the committee is delighted to 
welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank 
you both for your willingness to volunteer. I will add your details to 
the GitHub repo, and you are encouraged to contribute to the discussion 
of any of the proposals under committee review.

Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching 
the end of their terms, and have decided to step down. On behalf of the 
Haskell community, we are very grateful for your dedicated service over 
the years, which has been instrumental in helping GHC flourish.

Given that this results in a net reduction in size of the committee, we 
have decided to open a second round of nominations where we will 
consider appointing up to 3 more members. I will post an update to the 
announcement on Discourse [1], and I strongly encourage all members of 
the committee to consider whom they could personally invite to join us.

Best wishes,

Adam

[1] 
https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

From arnaud.spiwack at tweag.io  Wed Mar  6 07:59:26 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 6 Mar 2024 08:59:26 +0100
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
Message-ID: <CAGwnsn=Z0B8N0bQ+hFyywz3pWd-2Uv-_Fa+tuFTyh6mUTQTc3g@mail.gmail.com>

Welcome both!

On Wed, 6 Mar 2024 at 08:53, Adam Gundry <adam at well-typed.com> wrote:

> Dear all,
>
> Following the recent nomination round, the committee is delighted to
> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
> you both for your willingness to volunteer. I will add your details to
> the GitHub repo, and you are encouraged to contribute to the discussion
> of any of the proposals under committee review.
>
> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
> the end of their terms, and have decided to step down. On behalf of the
> Haskell community, we are very grateful for your dedicated service over
> the years, which has been instrumental in helping GHC flourish.
>
> Given that this results in a net reduction in size of the committee, we
> have decided to open a second round of nominations where we will
> consider appointing up to 3 more members. I will post an update to the
> announcement on Discourse [1], and I strongly encourage all members of
> the committee to consider whom they could personally invite to join us.
>
> Best wishes,
>
> Adam
>
> [1]
>
> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> 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/20240306/58da4b5f/attachment.html>

From adam at well-typed.com  Wed Mar  6 08:09:56 2024
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 6 Mar 2024 08:09:56 +0000
Subject: [ghc-steering-committee] Please review #638: Prefix form for
	MkSolo# (amendment of #475)
Message-ID: <969891d0-3e7c-4130-93be-ac467675fec9@well-typed.com>

Dear Committee,

Vlad proposes to amend Richard's proposal #475 (Non-punning list and 
tuple syntax) to define an unambiguous prefix form for the Solo# 
constructor:

https://github.com/ghc-proposals/ghc-proposals/pull/638

I'd like to nominate Matthías as the shepherd (welcome Matthías!).

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

From simon.peytonjones at gmail.com  Wed Mar  6 09:07:15 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 6 Mar 2024 09:07:15 +0000
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
Message-ID: <CAJKmMz8O1okjtHk+4mHQxOz_XaLH-BsLyUw6nM=8dr9ZzKBNPQ@mail.gmail.com>

Welcome Malte and Matthias!

Simon

On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com> wrote:

> Dear all,
>
> Following the recent nomination round, the committee is delighted to
> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
> you both for your willingness to volunteer. I will add your details to
> the GitHub repo, and you are encouraged to contribute to the discussion
> of any of the proposals under committee review.
>
> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
> the end of their terms, and have decided to step down. On behalf of the
> Haskell community, we are very grateful for your dedicated service over
> the years, which has been instrumental in helping GHC flourish.
>
> Given that this results in a net reduction in size of the committee, we
> have decided to open a second round of nominations where we will
> consider appointing up to 3 more members. I will post an update to the
> announcement on Discourse [1], and I strongly encourage all members of
> the committee to consider whom they could personally invite to join us.
>
> Best wishes,
>
> Adam
>
> [1]
>
> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> 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/20240306/699518b5/attachment-0001.html>

From moritz.angermann at gmail.com  Wed Mar  6 22:40:11 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 7 Mar 2024 06:40:11 +0800
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <CAJKmMz8O1okjtHk+4mHQxOz_XaLH-BsLyUw6nM=8dr9ZzKBNPQ@mail.gmail.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz8O1okjtHk+4mHQxOz_XaLH-BsLyUw6nM=8dr9ZzKBNPQ@mail.gmail.com>
Message-ID: <CAKfdd-wcLyJ_GtfpdQ7me8xmm3i4mC2WbHr_Y5HM3Y9xOzg_jg@mail.gmail.com>

Welcome to the new joiners! And a heartfelt thank you to the parting
members!

On Wed, 6 Mar 2024 at 5:07 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Welcome Malte and Matthias!
>
> Simon
>
> On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear all,
>>
>> Following the recent nomination round, the committee is delighted to
>> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
>> you both for your willingness to volunteer. I will add your details to
>> the GitHub repo, and you are encouraged to contribute to the discussion
>> of any of the proposals under committee review.
>>
>> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
>> the end of their terms, and have decided to step down. On behalf of the
>> Haskell community, we are very grateful for your dedicated service over
>> the years, which has been instrumental in helping GHC flourish.
>>
>> Given that this results in a net reduction in size of the committee, we
>> have decided to open a second round of nominations where we will
>> consider appointing up to 3 more members. I will post an update to the
>> announcement on Discourse [1], and I strongly encourage all members of
>> the committee to consider whom they could personally invite to join us.
>>
>> Best wishes,
>>
>> Adam
>>
>> [1]
>>
>> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240307/96bc0aa8/attachment.html>

From malte.ott at maralorn.de  Thu Mar  7 00:45:08 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Thu, 7 Mar 2024 01:45:08 +0100
Subject: [ghc-steering-committee]
 =?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
 =?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <CAKfdd-wcLyJ_GtfpdQ7me8xmm3i4mC2WbHr_Y5HM3Y9xOzg_jg@mail.gmail.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz8O1okjtHk+4mHQxOz_XaLH-BsLyUw6nM=8dr9ZzKBNPQ@mail.gmail.com>
 <CAKfdd-wcLyJ_GtfpdQ7me8xmm3i4mC2WbHr_Y5HM3Y9xOzg_jg@mail.gmail.com>
Message-ID: <ubmw7bbnadble3r5rf5ums6de7hwlxwt4dqflmcwy3cot3xwbf@hera.m-0.eu>

Dear all,

thank you for the warm welcome. I am looking forward to contribute to the
committees work and I am also very grateful for the work of the parting members.

Malte


On 2024-03-07 06:40, Moritz Angermann wrote:
> Welcome to the new joiners! And a heartfelt thank you to the parting
> members!
> 
> On Wed, 6 Mar 2024 at 5:07 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> 
> > Welcome Malte and Matthias!
> >
> > Simon
> >
> > On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com> wrote:
> >
> >> Dear all,
> >>
> >> Following the recent nomination round, the committee is delighted to
> >> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
> >> you both for your willingness to volunteer. I will add your details to
> >> the GitHub repo, and you are encouraged to contribute to the discussion
> >> of any of the proposals under committee review.
> >>
> >> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
> >> the end of their terms, and have decided to step down. On behalf of the
> >> Haskell community, we are very grateful for your dedicated service over
> >> the years, which has been instrumental in helping GHC flourish.
> >>
> >> Given that this results in a net reduction in size of the committee, we
> >> have decided to open a second round of nominations where we will
> >> consider appointing up to 3 more members. I will post an update to the
> >> announcement on Discourse [1], and I strongly encourage all members of
> >> the committee to consider whom they could personally invite to join us.
> >>
> >> Best wishes,
> >>
> >> Adam
> >>
> >> [1]
> >>
> >> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
> >>
> >>
> >> --
> >> Adam Gundry, Haskell Consultant
> >> Well-Typed LLP, https://www.well-typed.com/
> >>
> >> Registered in England & Wales, OC335890
> >> 27 Old Gloucester Street, London WC1N 3AX, England
> >> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >

From simon.peytonjones at gmail.com  Thu Mar  7 09:06:08 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 7 Mar 2024 09:06:08 +0000
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
Message-ID: <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>

Dear GHC SC members,

You'll remember that we agreed to have a second round of nominations.
(Malte and Matthais you won't have seen this, but the idea is to give us a
few more members, so that we can broaden and deepen our pool of expertise
and bandwidth.)  Adam announced this (below).

*We also agreed that each of us would personally invite three people to
nominate themselves.  A personal invitation is FAR more effective than a
blanket invitation.*

So can each of you think of three people, and tell Adam (cc the rest of us)
who you are going to invite?  That way we'll avoid duplication, and it'll
give each of us a little incentive to do it.

I will invite

   - David Binder
   - Sebastian Graf
   - Krzysztof Gogolewski
   - Ryan Scott
   - Matthew Craven

I was wondering about

   - Jaro Reinders
   - Mark Seeman -- I don't know him at all but his blog post are regularly
   featured on HWN
   - Brandon Chinn -- active on Haskell Discourse
   - Teo Camarasu -- ditto
   - maxigit  -- I'm not sure who they are but they post a lot on Discourse

If you have reservations about any of these, drop me a line.  I'll wait a
day or two.

And do send in your list of three (or more!) who you will invite.

Simon

---------- Forwarded message ---------
From: Adam Gundry via Haskell Community <discourse at haskell.org>
Date: Thu, 7 Mar 2024 at 08:26
Subject: Re: [Haskell Community] [Announcements] GHC Steering Committee
Call for Nominations 2024
To: <simon.peytonjones at gmail.com>


adamgundry <https://discourse.haskell.org/u/adamgundry> Haskell Foundation
Working Group
March 7

Following the recent nomination round, the GHC Steering Committee is
delighted to welcome @maralorn <https://discourse.haskell.org/u/maralorn>
and @Tritlo <https://discourse.haskell.org/u/tritlo> as new members. In
addition, @rae <https://discourse.haskell.org/u/rae>, @nomeata
<https://discourse.haskell.org/u/nomeata> and @int-index
<https://discourse.haskell.org/u/int-index> are reaching the end of their
terms, and have decided to step down. Many thanks to all of them for their
service to the Haskell community!

Given that a larger committee would help spread out the work of reviewing
proposals, we have decided to open a second round of nominations where we
will consider appointing up to 3 more members. If you would like to
nominate yourself, please get in touch with me by email to
adam at well-typed.com as soon as possible. Or if you know someone else who
would be a suitable member of the committee, please encourage them to apply.

On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com> wrote:

> Dear all,
>
> Following the recent nomination round, the committee is delighted to
> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
> you both for your willingness to volunteer. I will add your details to
> the GitHub repo, and you are encouraged to contribute to the discussion
> of any of the proposals under committee review.
>
> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
> the end of their terms, and have decided to step down. On behalf of the
> Haskell community, we are very grateful for your dedicated service over
> the years, which has been instrumental in helping GHC flourish.
>
> Given that this results in a net reduction in size of the committee, we
> have decided to open a second round of nominations where we will
> consider appointing up to 3 more members. I will post an update to the
> announcement on Discourse [1], and I strongly encourage all members of
> the committee to consider whom they could personally invite to join us.
>
> Best wishes,
>
> Adam
>
> [1]
>
> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> 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/20240307/4dfc15db/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Mar  7 09:18:59 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 7 Mar 2024 17:18:59 +0800
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
Message-ID: <CAKfdd-xwSF2gnBgJNjp5Ki=+YyUv66MS2TVrcxZZ2bEN491zVQ@mail.gmail.com>

I have reach out to a few but don’t want to put them on the spot by sharing
their details. I hope at least one of them follows through to apply. Maybe
two.

On Thu, 7 Mar 2024 at 5:06 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC SC members,
>
> You'll remember that we agreed to have a second round of nominations.
> (Malte and Matthais you won't have seen this, but the idea is to give us a
> few more members, so that we can broaden and deepen our pool of expertise
> and bandwidth.)  Adam announced this (below).
>
> *We also agreed that each of us would personally invite three people to
> nominate themselves.  A personal invitation is FAR more effective than a
> blanket invitation.*
>
> So can each of you think of three people, and tell Adam (cc the rest of
> us) who you are going to invite?  That way we'll avoid duplication, and
> it'll give each of us a little incentive to do it.
>
> I will invite
>
>    - David Binder
>    - Sebastian Graf
>    - Krzysztof Gogolewski
>    - Ryan Scott
>    - Matthew Craven
>
> I was wondering about
>
>    - Jaro Reinders
>    - Mark Seeman -- I don't know him at all but his blog post are
>    regularly featured on HWN
>    - Brandon Chinn -- active on Haskell Discourse
>    - Teo Camarasu -- ditto
>    - maxigit  -- I'm not sure who they are but they post a lot on
>    Discourse
>
> If you have reservations about any of these, drop me a line.  I'll wait a
> day or two.
>
> And do send in your list of three (or more!) who you will invite.
>
> Simon
>
> ---------- Forwarded message ---------
> From: Adam Gundry via Haskell Community <discourse at haskell.org>
> Date: Thu, 7 Mar 2024 at 08:26
> Subject: Re: [Haskell Community] [Announcements] GHC Steering Committee
> Call for Nominations 2024
> To: <simon.peytonjones at gmail.com>
>
>
> adamgundry <https://discourse.haskell.org/u/adamgundry> Haskell
> Foundation Working Group
> March 7
>
> Following the recent nomination round, the GHC Steering Committee is
> delighted to welcome @maralorn <https://discourse.haskell.org/u/maralorn>
> and @Tritlo <https://discourse.haskell.org/u/tritlo> as new members. In
> addition, @rae <https://discourse.haskell.org/u/rae>, @nomeata
> <https://discourse.haskell.org/u/nomeata> and @int-index
> <https://discourse.haskell.org/u/int-index> are reaching the end of their
> terms, and have decided to step down. Many thanks to all of them for their
> service to the Haskell community!
>
> Given that a larger committee would help spread out the work of reviewing
> proposals, we have decided to open a second round of nominations where we
> will consider appointing up to 3 more members. If you would like to
> nominate yourself, please get in touch with me by email to
> adam at well-typed.com as soon as possible. Or if you know someone else who
> would be a suitable member of the committee, please encourage them to apply.
>
> On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear all,
>>
>> Following the recent nomination round, the committee is delighted to
>> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
>> you both for your willingness to volunteer. I will add your details to
>> the GitHub repo, and you are encouraged to contribute to the discussion
>> of any of the proposals under committee review.
>>
>> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
>> the end of their terms, and have decided to step down. On behalf of the
>> Haskell community, we are very grateful for your dedicated service over
>> the years, which has been instrumental in helping GHC flourish.
>>
>> Given that this results in a net reduction in size of the committee, we
>> have decided to open a second round of nominations where we will
>> consider appointing up to 3 more members. I will post an update to the
>> announcement on Discourse [1], and I strongly encourage all members of
>> the committee to consider whom they could personally invite to join us.
>>
>> Best wishes,
>>
>> Adam
>>
>> [1]
>>
>> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240307/d0406f92/attachment.html>

From simon.peytonjones at gmail.com  Thu Mar  7 09:24:38 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 7 Mar 2024 09:24:38 +0000
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <CAKfdd-xwSF2gnBgJNjp5Ki=+YyUv66MS2TVrcxZZ2bEN491zVQ@mail.gmail.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
 <CAKfdd-xwSF2gnBgJNjp5Ki=+YyUv66MS2TVrcxZZ2bEN491zVQ@mail.gmail.com>
Message-ID: <CAJKmMz9MpN8-+-TccrGRJ5P76Q2vtDtL6hd7jvTNJHuy1TBrrw@mail.gmail.com>

>
> I have reach out to a few but don’t want to put them on the spot by
> sharing their details. I hope at least one of them follows through to
> apply. Maybe two.


That's fine, Moritz.  The important thing is that you have personally
invited a few possible members.  Thank you!

Simon

On Thu, 7 Mar 2024 at 09:19, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I have reach out to a few but don’t want to put them on the spot by
> sharing their details. I hope at least one of them follows through to
> apply. Maybe two.
>
> On Thu, 7 Mar 2024 at 5:06 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC SC members,
>>
>> You'll remember that we agreed to have a second round of nominations.
>> (Malte and Matthais you won't have seen this, but the idea is to give us a
>> few more members, so that we can broaden and deepen our pool of expertise
>> and bandwidth.)  Adam announced this (below).
>>
>> *We also agreed that each of us would personally invite three people to
>> nominate themselves.  A personal invitation is FAR more effective than a
>> blanket invitation.*
>>
>> So can each of you think of three people, and tell Adam (cc the rest of
>> us) who you are going to invite?  That way we'll avoid duplication, and
>> it'll give each of us a little incentive to do it.
>>
>> I will invite
>>
>>    - David Binder
>>    - Sebastian Graf
>>    - Krzysztof Gogolewski
>>    - Ryan Scott
>>    - Matthew Craven
>>
>> I was wondering about
>>
>>    - Jaro Reinders
>>    - Mark Seeman -- I don't know him at all but his blog post are
>>    regularly featured on HWN
>>    - Brandon Chinn -- active on Haskell Discourse
>>    - Teo Camarasu -- ditto
>>    - maxigit  -- I'm not sure who they are but they post a lot on
>>    Discourse
>>
>> If you have reservations about any of these, drop me a line.  I'll wait a
>> day or two.
>>
>> And do send in your list of three (or more!) who you will invite.
>>
>> Simon
>>
>> ---------- Forwarded message ---------
>> From: Adam Gundry via Haskell Community <discourse at haskell.org>
>> Date: Thu, 7 Mar 2024 at 08:26
>> Subject: Re: [Haskell Community] [Announcements] GHC Steering Committee
>> Call for Nominations 2024
>> To: <simon.peytonjones at gmail.com>
>>
>>
>> adamgundry <https://discourse.haskell.org/u/adamgundry> Haskell
>> Foundation Working Group
>> March 7
>>
>> Following the recent nomination round, the GHC Steering Committee is
>> delighted to welcome @maralorn <https://discourse.haskell.org/u/maralorn>
>> and @Tritlo <https://discourse.haskell.org/u/tritlo> as new members. In
>> addition, @rae <https://discourse.haskell.org/u/rae>, @nomeata
>> <https://discourse.haskell.org/u/nomeata> and @int-index
>> <https://discourse.haskell.org/u/int-index> are reaching the end of
>> their terms, and have decided to step down. Many thanks to all of them for
>> their service to the Haskell community!
>>
>> Given that a larger committee would help spread out the work of reviewing
>> proposals, we have decided to open a second round of nominations where we
>> will consider appointing up to 3 more members. If you would like to
>> nominate yourself, please get in touch with me by email to
>> adam at well-typed.com as soon as possible. Or if you know someone else who
>> would be a suitable member of the committee, please encourage them to apply.
>>
>> On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> Dear all,
>>>
>>> Following the recent nomination round, the committee is delighted to
>>> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
>>> you both for your willingness to volunteer. I will add your details to
>>> the GitHub repo, and you are encouraged to contribute to the discussion
>>> of any of the proposals under committee review.
>>>
>>> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
>>> the end of their terms, and have decided to step down. On behalf of the
>>> Haskell community, we are very grateful for your dedicated service over
>>> the years, which has been instrumental in helping GHC flourish.
>>>
>>> Given that this results in a net reduction in size of the committee, we
>>> have decided to open a second round of nominations where we will
>>> consider appointing up to 3 more members. I will post an update to the
>>> announcement on Discourse [1], and I strongly encourage all members of
>>> the committee to consider whom they could personally invite to join us.
>>>
>>> Best wishes,
>>>
>>> Adam
>>>
>>> [1]
>>>
>>> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
>>>
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> 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/20240307/3bae46fe/attachment-0001.html>

From adam at well-typed.com  Thu Mar  7 09:26:19 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 7 Mar 2024 09:26:19 +0000
Subject: [ghc-steering-committee]
 =?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
 =?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
Message-ID: <056da03a-b32b-4b5c-bec0-cbc2b1c158c2@well-typed.com>

Thanks Simon!

As a side note, can I just remind everyone that 
ghc-steering-committee at haskell.org is a mailing list with public 
archives, so if you would like to share reservations about inviting any 
individuals, please keep them to private email between the committee 
members. Similarly, once I've received nominations, I will circulate 
them for discussion privately.

Cheers,

Adam



On 07/03/2024 09:06, Simon Peyton Jones wrote:
> Dear GHC SC members,
> 
> You'll remember that we agreed to have a second round of nominations.  
> (Malte and Matthais you won't have seen this, but the idea is to give us 
> a few more members, so that we can broaden and deepen our pool of 
> expertise and bandwidth.)  Adam announced this (below).
> 
> *We also agreed that each of us would personally invite three people to 
> nominate themselves.  A personal invitation is FAR more effective than a 
> blanket invitation.*
> 
> So can each of you think of three people, and tell Adam (cc the rest of 
> us) who you are going to invite?  That way we'll avoid duplication, and 
> it'll give each of us a little incentive to do it.
> 
> I will invite
> 
>   * David Binder
>   * Sebastian Graf
>   * Krzysztof Gogolewski
>   * Ryan Scott
>   * Matthew Craven
> 
> I was wondering about
> 
>   * Jaro Reinders
>   * Mark Seeman -- I don't know him at all but his blog post are
>     regularly featured on HWN
>   * Brandon Chinn -- active on Haskell Discourse
>   * Teo Camarasu -- ditto
>   * maxigit  -- I'm not sure who they are but they post a lot on Discourse
> 
> If you have reservations about any of these, drop me a line.  I'll wait 
> a day or two.
> 
> And do send in your list of three (or more!) who you will invite.
> 
> Simon
> 
> ---------- Forwarded message ---------
> From: *Adam Gundry via Haskell Community* <discourse at haskell.org 
> <mailto:discourse at haskell.org>>
> Date: Thu, 7 Mar 2024 at 08:26
> Subject: Re: [Haskell Community] [Announcements] GHC Steering Committee 
> Call for Nominations 2024
> To: <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> 
> 
> __
> [adamgundry] 	adamgundry <https://discourse.haskell.org/u/adamgundry> 
> Haskell Foundation Working Group
> March 7
> 
> Following the recent nomination round, the GHC Steering Committee is 
> delighted to welcome @maralorn 
> <https://discourse.haskell.org/u/maralorn> and @Tritlo 
> <https://discourse.haskell.org/u/tritlo> as new members. In addition, 
> @rae <https://discourse.haskell.org/u/rae>, @nomeata 
> <https://discourse.haskell.org/u/nomeata> and @int-index 
> <https://discourse.haskell.org/u/int-index> are reaching the end of 
> their terms, and have decided to step down. Many thanks to all of them 
> for their service to the Haskell community!
> 
> Given that a larger committee would help spread out the work of 
> reviewing proposals, we have decided to open a second round of 
> nominations where we will consider appointing up to 3 more members. If 
> you would like to nominate yourself, please get in touch with me by 
> email to adam at well-typed.com <mailto:adam at well-typed.com> as soon as 
> possible. Or if you know someone else who would be a suitable member of 
> the committee, please encourage them to apply.
> 
> 
> On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com 
> <mailto:adam at well-typed.com>> wrote:
> 
>     Dear all,
> 
>     Following the recent nomination round, the committee is delighted to
>     welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
>     you both for your willingness to volunteer. I will add your details to
>     the GitHub repo, and you are encouraged to contribute to the discussion
>     of any of the proposals under committee review.
> 
>     Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
>     the end of their terms, and have decided to step down. On behalf of the
>     Haskell community, we are very grateful for your dedicated service over
>     the years, which has been instrumental in helping GHC flourish.
> 
>     Given that this results in a net reduction in size of the committee, we
>     have decided to open a second round of nominations where we will
>     consider appointing up to 3 more members. I will post an update to the
>     announcement on Discourse [1], and I strongly encourage all members of
>     the committee to consider whom they could personally invite to join us.
> 
>     Best wishes,
> 
>     Adam
> 
>     [1]
>     https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666 <https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666>

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From adam at well-typed.com  Thu Mar  7 09:26:55 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 7 Mar 2024 09:26:55 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
Message-ID: <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>

I've added a comment to the GitHub thread 
(https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1983060484) 
elaborating slightly on Richard's suggestion (albeit with an effectively 
indefinite transition period).

Adam


On 05/03/2024 08:52, Arnaud Spiwack wrote:
> This is Alternative 7.5 in the current version of the proposal 
> https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance <https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance> .
> 
> PS: I tend to agree with Richard that requiring an ExitStatus instance 
> is the preferable option. But food for thought for the proposal thread 
> when that conversation happens there: should that be gated behind an 
> extension? In which case it won't become the default before the next 
> language edition.
> 
> /Arnaud
> 
> On Mon, 4 Mar 2024 at 21:35, Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>         I left out a key part of my last email -- apologies. I'm
>         floating a counter-proposal where we *require* an instance of
>         ExitStatus on the return type of `main`, with a transition
>         period. In contrast, my understanding of the proposal written is
>         that it would use such an instance if it exists, but issue a
>         warning if it doesn't, in perpetuity.
> 
> 
>     Ah  I had not realised that.
> 
>     But why?
> 
>     Rather than answer here (private to SC) why don't you put your
>     proposal on the discussion thread, say why, and invite feedback.
> 
>     Simon
> 
> 
>     On Mon, 4 Mar 2024 at 19:24, Richard Eisenberg
>     <reisenberg at janestreet.com <mailto:reisenberg at janestreet.com>> wrote:
> 
>         I left out a key part of my last email -- apologies. I'm
>         floating a counter-proposal where we *require* an instance of
>         ExitStatus on the return type of `main`, with a transition
>         period. In contrast, my understanding of the proposal written is
>         that it would use such an instance if it exists, but issue a
>         warning if it doesn't, in perpetuity.
> 
>         Richard
> 
>         On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones
>         <simon.peytonjones at gmail.com
>         <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>                 I am a little worried about breaking programs that end
>                 in an innocent-looking `return 0`, just because some
>                 other languages like to end programs with that phrase 
> 
> 
>             The proposal specifies that such a program returns
>             `ExitSuccess`, but adds a warning. That seems OK to me; it
>             does not break the program.
> 
>             Oh -- maybe you mean that `return 1` means "return with exit
>             code 1" today.  Is that really true?  I don't think so.
> 
>             Overall this proposal seems fine to me.  I'd be happy to see
>             it done.
> 
>             Simon
> 
>             On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg
>             <reisenberg at janestreet.com
>             <mailto:reisenberg at janestreet.com>> wrote:
> 
>                 I haven't followed this proposal closely. But couldn't
>                 we have a transition period toward this eventual goal?
>                 That is, introduce a new warning, on by default, if
>                 `main` returns anything other than `()`. That goes for a
>                 few releases. Then we require that the return type of
>                 main has an instance of ExitStatus.
> 
>                 I'm not worried about changing the behavior of programs
>                 that have type IO ExitCode but expect the program to
>                 return 0 unconditionally; that's just begging for
>                 confusion. I am a little worried about breaking programs
>                 that end in an innocent-looking `return 0`, just because
>                 some other languages like to end programs with that
>                 phrase. So I'm not sure if we should have an instance
>                 ExitStatus Int (or instance ExitStatus Integer) -- but
>                 we probably should. If a program ends with `return 1`,
>                 the programmer probably wants the OS to return 1 as well.
> 
>                 Richard
> 
>                 On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack
>                 <arnaud.spiwack at tweag.io
>                 <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>                     Dear all,
> 
>                     Shea Levy proposes to do something with the values
>                     returned by `main`
>                     https://github.com/ghc-proposals/ghc-proposals/pull/631 <https://github.com/ghc-proposals/ghc-proposals/pull/631> .
> 
>                     The problem is that `main` is allowed to be of type
>                     `IO A` for any `A`. And GHC will simply drop the
>                     value returned by `main`. Shea contends that it's
>                     surprising. I agree that dropping a value without
>                     the compiler being explicitly instructed to is
>                     surprising. But Shea says that when `A` is
>                     `ExitCode` this is even more surprising. Namely
>                     `main :: IO ExitCode; main = return $ Failure 1`
>                     actually terminates with exit code 0. And I doubt
>                     that it's what anybody expects when reading the code.
> 
>                     The proposal is simple, but I have a lot of comments
>                     on it. Sorry about that…
> 
>                     Now, this sort of proposal is tricky. When the
>                     current behaviour is confusing, we want to change
>                     the default. But putting the new default behind an
>                     extension doesn't really solve the fact that there's
>                     a trap. The extension is, therefore, unlikely to be
>                     well tested before it becomes part of the next
>                     language edition.
> 
>                     Shea's main proposition doesn't actually use an
>                     extension though. He adds a type class `ExitStatus`,
>                     and if `ExistStatus A`, then `main :: IO A` uses the
>                     instance to determine the exit code based on the
>                     return value.
> 
>                     The only change to the current behaviour is that
>                     `main :: IO ExitCode` instead of always terminating
>                     with exit code 0 when returning now terminates with
>                     the expected error code. The argument for not
>                     putting this behind an extension is that virtually
>                     anybody affected by the change will actually have
>                     the behaviour they were expecting. But maybe the
>                     argument isn't strong enough (the changes may be
>                     more “interesting” if some library exports some
>                     `ExistStatus` instance).
> 
>                     This design of this proposal is inspired by Rust's
>                     design. I've asked our Rust team, and they certainly
>                     seem to have internalised the idea of returning an
>                     exit code. It really seems a pretty natural feature
>                     to have. So I'm rather in favour of some flavour of
>                     the type class implementation. Though have a look at
>                     the alternatives, where you'll find other approaches
>                     such as restricting the type of `main` to
>                     unsurprising types.
> 
>                     One caveat with respect to the main proposal: it is
>                     proposed that when no `ExistStatus A` is found, then
>                     we drop the returned value like today. I don't know
>                     that it's quite easy to implement this behaviour.
>                     But it can be recovered by a catch-all overlapping
>                     instance, so maybe it's a better way to specify the
>                     desired behaviour.
> 
>                     -- 
>                     Arnaud Spiwack
>                     Director, Research at https://moduscreate.com
>                     <https://moduscreate.com> and https://tweag.io
>                     <https://tweag.io>.


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Thu Mar  7 11:32:17 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 7 Mar 2024 11:32:17 +0000
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <056da03a-b32b-4b5c-bec0-cbc2b1c158c2@well-typed.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
 <056da03a-b32b-4b5c-bec0-cbc2b1c158c2@well-typed.com>
Message-ID: <CAJKmMz-86bxhfJWpuJNb6X+PQMApiAAKsp6utVdj2VgX8RdB1A@mail.gmail.com>

As a side note, can I just remind everyone that
ghc-steering-committee at haskell.org is a mailing list with public archives,
so if you would like to share reservations about inviting any individuals,
please keep them to private email between the committee members. Similarly,
once I've received nominations, I will circulate


Good point.   That said, I think there is no harm in suggesting names in a
positive way.  Maybe even some readers of the list will want to suggest
others!

One new thought:

   - maralorn <https://github.com/maralorn?tab=repositories>makes lots of
   great contributions, though I don't think I know them personally.  Does
   anyone else know them?

Simon

On Thu, 7 Mar 2024 at 09:26, Adam Gundry <adam at well-typed.com> wrote:

> Thanks Simon!
>
> As a side note, can I just remind everyone that
> ghc-steering-committee at haskell.org is a mailing list with public
> archives, so if you would like to share reservations about inviting any
> individuals, please keep them to private email between the committee
> members. Similarly, once I've received nominations, I will circulate
> them for discussion privately.
>
> Cheers,
>
> Adam
>
>
>
> On 07/03/2024 09:06, Simon Peyton Jones wrote:
> > Dear GHC SC members,
> >
> > You'll remember that we agreed to have a second round of nominations.
> > (Malte and Matthais you won't have seen this, but the idea is to give us
> > a few more members, so that we can broaden and deepen our pool of
> > expertise and bandwidth.)  Adam announced this (below).
> >
> > *We also agreed that each of us would personally invite three people to
> > nominate themselves.  A personal invitation is FAR more effective than a
> > blanket invitation.*
> >
> > So can each of you think of three people, and tell Adam (cc the rest of
> > us) who you are going to invite?  That way we'll avoid duplication, and
> > it'll give each of us a little incentive to do it.
> >
> > I will invite
> >
> >   * David Binder
> >   * Sebastian Graf
> >   * Krzysztof Gogolewski
> >   * Ryan Scott
> >   * Matthew Craven
> >
> > I was wondering about
> >
> >   * Jaro Reinders
> >   * Mark Seeman -- I don't know him at all but his blog post are
> >     regularly featured on HWN
> >   * Brandon Chinn -- active on Haskell Discourse
> >   * Teo Camarasu -- ditto
> >   * maxigit  -- I'm not sure who they are but they post a lot on
> Discourse
> >
> > If you have reservations about any of these, drop me a line.  I'll wait
> > a day or two.
> >
> > And do send in your list of three (or more!) who you will invite.
> >
> > Simon
> >
> > ---------- Forwarded message ---------
> > From: *Adam Gundry via Haskell Community* <discourse at haskell.org
> > <mailto:discourse at haskell.org>>
> > Date: Thu, 7 Mar 2024 at 08:26
> > Subject: Re: [Haskell Community] [Announcements] GHC Steering Committee
> > Call for Nominations 2024
> > To: <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> >
> >
> > __
> > [adamgundry]  adamgundry <https://discourse.haskell.org/u/adamgundry>
> > Haskell Foundation Working Group
> > March 7
> >
> > Following the recent nomination round, the GHC Steering Committee is
> > delighted to welcome @maralorn
> > <https://discourse.haskell.org/u/maralorn> and @Tritlo
> > <https://discourse.haskell.org/u/tritlo> as new members. In addition,
> > @rae <https://discourse.haskell.org/u/rae>, @nomeata
> > <https://discourse.haskell.org/u/nomeata> and @int-index
> > <https://discourse.haskell.org/u/int-index> are reaching the end of
> > their terms, and have decided to step down. Many thanks to all of them
> > for their service to the Haskell community!
> >
> > Given that a larger committee would help spread out the work of
> > reviewing proposals, we have decided to open a second round of
> > nominations where we will consider appointing up to 3 more members. If
> > you would like to nominate yourself, please get in touch with me by
> > email to adam at well-typed.com <mailto:adam at well-typed.com> as soon as
> > possible. Or if you know someone else who would be a suitable member of
> > the committee, please encourage them to apply.
> >
> >
> > On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com
> > <mailto:adam at well-typed.com>> wrote:
> >
> >     Dear all,
> >
> >     Following the recent nomination round, the committee is delighted to
> >     welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
> >     you both for your willingness to volunteer. I will add your details
> to
> >     the GitHub repo, and you are encouraged to contribute to the
> discussion
> >     of any of the proposals under committee review.
> >
> >     Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are
> reaching
> >     the end of their terms, and have decided to step down. On behalf of
> the
> >     Haskell community, we are very grateful for your dedicated service
> over
> >     the years, which has been instrumental in helping GHC flourish.
> >
> >     Given that this results in a net reduction in size of the committee,
> we
> >     have decided to open a second round of nominations where we will
> >     consider appointing up to 3 more members. I will post an update to
> the
> >     announcement on Discourse [1], and I strongly encourage all members
> of
> >     the committee to consider whom they could personally invite to join
> us.
> >
> >     Best wishes,
> >
> >     Adam
> >
> >     [1]
> >
> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
> <
> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
> >
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240307/129f4076/attachment-0001.html>

From malte.ott at maralorn.de  Thu Mar  7 11:44:26 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Thu, 7 Mar 2024 12:44:26 +0100
Subject: [ghc-steering-committee]
 =?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
 =?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <CAJKmMz-86bxhfJWpuJNb6X+PQMApiAAKsp6utVdj2VgX8RdB1A@mail.gmail.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
 <056da03a-b32b-4b5c-bec0-cbc2b1c158c2@well-typed.com>
 <CAJKmMz-86bxhfJWpuJNb6X+PQMApiAAKsp6utVdj2VgX8RdB1A@mail.gmail.com>
Message-ID: <ssup7ivy353flsoa2hbixj66thkiytisxx6p3tci7ckhuegwhs@hera.m-0.eu>

On 2024-03-07 11:32, Simon Peyton Jones wrote:
> One new thought:
> 
>    - maralorn <https://github.com/maralorn?tab=repositories>makes lots of
>    great contributions, though I don't think I know them personally.  Does
>    anyone else know them?

Yes, I know them. It’s me. I am glad that you like my contributions.

Until now I had made an effort to not connect my online persona with my real
name, so not knowing the connection is understandable.

Cheers,
Malte

From adam at well-typed.com  Fri Mar  8 21:12:43 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 8 Mar 2024 21:12:43 +0000
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b
Message-ID: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>

Dear Committee,

Vlad proposes to change the order of implicit quantification for type 
variables occurring as type operators or in multiplicity annotations:

https://github.com/ghc-proposals/ghc-proposals/pull/640

https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst

I'd like to nominate Malte as the shepherd (welcome Malte!).

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

From mpg at mpg.is  Sat Mar  9 00:12:04 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Sat, 9 Mar 2024 01:12:04 +0100
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
	(Recommend Accept)
Message-ID: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>

Greetings committee!

In [proposal #638](https://github.com/ghc-proposals/ghc-proposals/pull/638),
@int-index proposes that we introduce a prefix form of MkSolo#, and
apparent oversight in proposal #475 [Non-punning list and tuple syntax](
https://github.com/ghc-proposals/ghc-proposals/pull/475).

Previously, you would write `(# a #)` to construct a `Solo# a`.
But the question is: what would be the prefix form of this constructor?
It can't be `(# #)`, because this is already defined as a constructor of
`Unit#`!

This amendment proposes the `MkSolo#` constructor, having us write `MkSolo#
a` for the prefix form. The discussion seems unanimous, after care was
taken to clarify that a fully applied `MkSolo# a` would still be pretty
printed as `(# a #)`, avoiding programmer confusion.

It seems quite straightforward to me, so:

I recommend accepting this amendment to #475.


-- 
--  Matthías Páll Gissurarson <http://mpg.is/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240309/486897bc/attachment.html>

From mpg at mpg.is  Sat Mar  9 00:18:09 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Sat, 9 Mar 2024 01:18:09 +0100
Subject: [ghc-steering-committee]
	=?utf-8?q?Welcome_Malte_and_Matth=C3=ADa?=
	=?utf-8?q?s=2C_and_other_membership_changes?=
In-Reply-To: <CAJKmMz9MpN8-+-TccrGRJ5P76Q2vtDtL6hd7jvTNJHuy1TBrrw@mail.gmail.com>
References: <ef5c7621-4f6b-46cd-90d0-3a260640abed@well-typed.com>
 <CAJKmMz-ZBC1EHvytehO94bJBNWd7POOFzWgaNd6V59TTm=rq8Q@mail.gmail.com>
 <CAKfdd-xwSF2gnBgJNjp5Ki=+YyUv66MS2TVrcxZZ2bEN491zVQ@mail.gmail.com>
 <CAJKmMz9MpN8-+-TccrGRJ5P76Q2vtDtL6hd7jvTNJHuy1TBrrw@mail.gmail.com>
Message-ID: <CAAyWr_kJmNif+ryH8n8XBK6iNV1owEhHDtUx+roLjiVJPZehfg@mail.gmail.com>

Greetings all, and thanks for the welcome!

I've also nudged two to apply, hopefully they come through. Do we have a
deadline for this second round? I think it would be helpful for those that
delay evaluation as long as possible.

On Thu, Mar 7, 2024 at 10:24 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I have reach out to a few but don’t want to put them on the spot by
>> sharing their details. I hope at least one of them follows through to
>> apply. Maybe two.
>
>
> That's fine, Moritz.  The important thing is that you have personally
> invited a few possible members.  Thank you!
>
> Simon
>
> On Thu, 7 Mar 2024 at 09:19, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> I have reach out to a few but don’t want to put them on the spot by
>> sharing their details. I hope at least one of them follows through to
>> apply. Maybe two.
>>
>> On Thu, 7 Mar 2024 at 5:06 PM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear GHC SC members,
>>>
>>> You'll remember that we agreed to have a second round of nominations.
>>> (Malte and Matthais you won't have seen this, but the idea is to give us a
>>> few more members, so that we can broaden and deepen our pool of expertise
>>> and bandwidth.)  Adam announced this (below).
>>>
>>> *We also agreed that each of us would personally invite three people to
>>> nominate themselves.  A personal invitation is FAR more effective than a
>>> blanket invitation.*
>>>
>>> So can each of you think of three people, and tell Adam (cc the rest of
>>> us) who you are going to invite?  That way we'll avoid duplication, and
>>> it'll give each of us a little incentive to do it.
>>>
>>> I will invite
>>>
>>>    - David Binder
>>>    - Sebastian Graf
>>>    - Krzysztof Gogolewski
>>>    - Ryan Scott
>>>    - Matthew Craven
>>>
>>> I was wondering about
>>>
>>>    - Jaro Reinders
>>>    - Mark Seeman -- I don't know him at all but his blog post are
>>>    regularly featured on HWN
>>>    - Brandon Chinn -- active on Haskell Discourse
>>>    - Teo Camarasu -- ditto
>>>    - maxigit  -- I'm not sure who they are but they post a lot on
>>>    Discourse
>>>
>>> If you have reservations about any of these, drop me a line.  I'll wait
>>> a day or two.
>>>
>>> And do send in your list of three (or more!) who you will invite.
>>>
>>> Simon
>>>
>>> ---------- Forwarded message ---------
>>> From: Adam Gundry via Haskell Community <discourse at haskell.org>
>>> Date: Thu, 7 Mar 2024 at 08:26
>>> Subject: Re: [Haskell Community] [Announcements] GHC Steering Committee
>>> Call for Nominations 2024
>>> To: <simon.peytonjones at gmail.com>
>>>
>>>
>>> adamgundry <https://discourse.haskell.org/u/adamgundry> Haskell
>>> Foundation Working Group
>>> March 7
>>>
>>> Following the recent nomination round, the GHC Steering Committee is
>>> delighted to welcome @maralorn
>>> <https://discourse.haskell.org/u/maralorn> and @Tritlo
>>> <https://discourse.haskell.org/u/tritlo> as new members. In addition,
>>> @rae <https://discourse.haskell.org/u/rae>, @nomeata
>>> <https://discourse.haskell.org/u/nomeata> and @int-index
>>> <https://discourse.haskell.org/u/int-index> are reaching the end of
>>> their terms, and have decided to step down. Many thanks to all of them for
>>> their service to the Haskell community!
>>>
>>> Given that a larger committee would help spread out the work of
>>> reviewing proposals, we have decided to open a second round of nominations
>>> where we will consider appointing up to 3 more members. If you would like
>>> to nominate yourself, please get in touch with me by email to
>>> adam at well-typed.com as soon as possible. Or if you know someone else
>>> who would be a suitable member of the committee, please encourage them to
>>> apply.
>>>
>>> On Wed, 6 Mar 2024 at 07:53, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> Dear all,
>>>>
>>>> Following the recent nomination round, the committee is delighted to
>>>> welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank
>>>> you both for your willingness to volunteer. I will add your details to
>>>> the GitHub repo, and you are encouraged to contribute to the discussion
>>>> of any of the proposals under committee review.
>>>>
>>>> Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching
>>>> the end of their terms, and have decided to step down. On behalf of the
>>>> Haskell community, we are very grateful for your dedicated service over
>>>> the years, which has been instrumental in helping GHC flourish.
>>>>
>>>> Given that this results in a net reduction in size of the committee, we
>>>> have decided to open a second round of nominations where we will
>>>> consider appointing up to 3 more members. I will post an update to the
>>>> announcement on Discourse [1], and I strongly encourage all members of
>>>> the committee to consider whom they could personally invite to join us.
>>>>
>>>> Best wishes,
>>>>
>>>> Adam
>>>>
>>>> [1]
>>>>
>>>> https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations-2024/8666
>>>>
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> 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/20240309/c147146b/attachment-0001.html>

From malte.ott at maralorn.de  Sat Mar  9 21:45:53 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Sat, 9 Mar 2024 22:45:53 +0100
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
Message-ID: <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>

Dear all,

Vlad proposes to change the order of implicit quantification for type
variables occurring as type operators or in multiplicity annotations:

https://github.com/ghc-proposals/ghc-proposals/pull/640

https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst

The proposal is thankfully very simple. Change the implicit quantification order for

"a `op` b" from "forall op a b" to "forall a op b".

and 

"a %m -> b" from "forall a b m" to "forall a m b".

The proposed new behavior corresponds to the original paper and our user guide.
This can be considered a bug fix and while we could also just change the
specification I think having a simple and memorable rule for quantification
order is valuable. Especially the currently implemented quantification order for
multiplicities is weird.

The only painful point here is as usual a question of stability. What I don’t
like about this change is, that if any code base uses it (which Vlad doubts and
I tend to agree), the type error on GHC upgrade will be very incomprehensible
for users who didn’t read and understand the changelog.

However multiplicities are new and explicitely unstable and I don’t really see a
reason why anyone would use infix notation on a qantified function. So I agree
that this very unlikely to happen in the wild. Also, users who rely on the type
application order right now should have noticed that something is off.

Thus I recommend acceptance as is.

Please voice your opinions!

Malte

From malte.ott at maralorn.de  Sat Mar  9 22:43:27 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Sat, 9 Mar 2024 23:43:27 +0100
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
References: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
Message-ID: <ubrdfiz3zrsh7o7uehthg4cpaktzlxj24ll7wfto4xfm2g4ssw@hera.m-0.eu>

On 2024-03-09 01:12, Matthías Páll Gissurarson wrote:
> I recommend accepting this amendment to #475.

I agree, this looks sensible.

Best
Malte

From simon.peytonjones at gmail.com  Mon Mar 11 10:48:15 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Mar 2024 10:48:15 +0000
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
References: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
Message-ID: <CAJKmMz-pMu8dmUcFt2tbZs_G_3gxnNrLiVS=wCHNOrP4EOsebA@mail.gmail.com>

Thanks Matthias

I'm generally supportive, but please see my comment exploring a minor
alternative
<https://github.com/ghc-proposals/ghc-proposals/pull/638#issuecomment-1988147639>
.

Simon

On Sat, 9 Mar 2024 at 00:12, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

> Greetings committee!
>
> In [proposal #638](https://github.com/ghc-proposals/ghc-proposals/pull/638
> ),
> @int-index proposes that we introduce a prefix form of MkSolo#, and
> apparent oversight in proposal #475 [Non-punning list and tuple syntax](
> https://github.com/ghc-proposals/ghc-proposals/pull/475).
>
> Previously, you would write `(# a #)` to construct a `Solo# a`.
> But the question is: what would be the prefix form of this constructor?
> It can't be `(# #)`, because this is already defined as a constructor of
> `Unit#`!
>
> This amendment proposes the `MkSolo#` constructor, having us write
> `MkSolo# a` for the prefix form. The discussion seems unanimous, after care
> was taken to clarify that a fully applied `MkSolo# a` would still be pretty
> printed as `(# a #)`, avoiding programmer confusion.
>
> It seems quite straightforward to me, so:
>
> I recommend accepting this amendment to #475.
>
>
> --
> --  Matthías Páll Gissurarson <http://mpg.is/>
> _______________________________________________
> 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/20240311/038b97b8/attachment.html>

From arnaud.spiwack at tweag.io  Tue Mar 12 09:32:17 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 12 Mar 2024 10:32:17 +0100
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
Message-ID: <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>

I think that the linear types part is a no-brainer.

The infix operator one is less clear. Adam feels that it'd be weird if “a
`op` b” yielded a different order than “op a b” as is being proposed. It's
definitely something you could go both ways about. I'm personally worried
about backward compatibility. Admittedly, this case where we quantify
implicitly over a variable in infix position is probably rare. But the
breakage would be quite subtle. I'm just not sure it's worth it. Do we care
enough about the order of implicit quantification that we want to change
this long established one? Richard is more optimistic
https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968

So, anyway, I'm open to be swayed by arguments, but my current thinking is:
make the change for a %m -> b, but not for a `op` b.

On Sat, 9 Mar 2024 at 22:46, Malte Ott <malte.ott at maralorn.de> wrote:

> Dear all,
>
> Vlad proposes to change the order of implicit quantification for type
> variables occurring as type operators or in multiplicity annotations:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/640
>
>
> https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst
>
> The proposal is thankfully very simple. Change the implicit quantification
> order for
>
> "a `op` b" from "forall op a b" to "forall a op b".
>
> and
>
> "a %m -> b" from "forall a b m" to "forall a m b".
>
> The proposed new behavior corresponds to the original paper and our user
> guide.
> This can be considered a bug fix and while we could also just change the
> specification I think having a simple and memorable rule for quantification
> order is valuable. Especially the currently implemented quantification
> order for
> multiplicities is weird.
>
> The only painful point here is as usual a question of stability. What I
> don’t
> like about this change is, that if any code base uses it (which Vlad
> doubts and
> I tend to agree), the type error on GHC upgrade will be very
> incomprehensible
> for users who didn’t read and understand the changelog.
>
> However multiplicities are new and explicitely unstable and I don’t really
> see a
> reason why anyone would use infix notation on a qantified function. So I
> agree
> that this very unlikely to happen in the wild. Also, users who rely on the
> type
> application order right now should have noticed that something is off.
>
> Thus I recommend acceptance as is.
>
> Please voice your opinions!
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240312/611bed4b/attachment.html>

From arnaud.spiwack at tweag.io  Tue Mar 12 09:34:21 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 12 Mar 2024 10:34:21 +0100
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAJKmMz-pMu8dmUcFt2tbZs_G_3gxnNrLiVS=wCHNOrP4EOsebA@mail.gmail.com>
References: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
 <CAJKmMz-pMu8dmUcFt2tbZs_G_3gxnNrLiVS=wCHNOrP4EOsebA@mail.gmail.com>
Message-ID: <CAGwnsnmci5a3C2EcjDn4gfWWDkOt4T8dbpeGfBvaFp=qqHiQ9Q@mail.gmail.com>

In favour.

Simon: I don't think your objection pertains to this particular proposal
amendment, does it? Rather it's a further change to the original proposal
that you'd like to see.

On Mon, 11 Mar 2024 at 11:48, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Thanks Matthias
>
> I'm generally supportive, but please see my comment exploring a minor
> alternative
> <https://github.com/ghc-proposals/ghc-proposals/pull/638#issuecomment-1988147639>
> .
>
> Simon
>
> On Sat, 9 Mar 2024 at 00:12, Matthías Páll Gissurarson <mpg at mpg.is> wrote:
>
>> Greetings committee!
>>
>> In [proposal #638](
>> https://github.com/ghc-proposals/ghc-proposals/pull/638),
>> @int-index proposes that we introduce a prefix form of MkSolo#, and
>> apparent oversight in proposal #475 [Non-punning list and tuple syntax](
>> https://github.com/ghc-proposals/ghc-proposals/pull/475).
>>
>> Previously, you would write `(# a #)` to construct a `Solo# a`.
>> But the question is: what would be the prefix form of this constructor?
>> It can't be `(# #)`, because this is already defined as a constructor of
>> `Unit#`!
>>
>> This amendment proposes the `MkSolo#` constructor, having us write
>> `MkSolo# a` for the prefix form. The discussion seems unanimous, after care
>> was taken to clarify that a fully applied `MkSolo# a` would still be pretty
>> printed as `(# a #)`, avoiding programmer confusion.
>>
>> It seems quite straightforward to me, so:
>>
>> I recommend accepting this amendment to #475.
>>
>>
>> --
>> --  Matthías Páll Gissurarson <http://mpg.is/>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240312/938a2366/attachment.html>

From simon.peytonjones at gmail.com  Tue Mar 12 09:38:18 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 12 Mar 2024 09:38:18 +0000
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAGwnsnmci5a3C2EcjDn4gfWWDkOt4T8dbpeGfBvaFp=qqHiQ9Q@mail.gmail.com>
References: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
 <CAJKmMz-pMu8dmUcFt2tbZs_G_3gxnNrLiVS=wCHNOrP4EOsebA@mail.gmail.com>
 <CAGwnsnmci5a3C2EcjDn4gfWWDkOt4T8dbpeGfBvaFp=qqHiQ9Q@mail.gmail.com>
Message-ID: <CAJKmMz-HJ_BGpVgT31RbO-s=AsM1vzyR7bU22Z_O1rmEp5iUJQ@mail.gmail.com>

Well this proposal deepens the commitment to an exception for Solo and
Solo#.   But I'm not really objecting, just asking.

Simon

On Tue, 12 Mar 2024 at 09:34, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> In favour.
>
> Simon: I don't think your objection pertains to this particular proposal
> amendment, does it? Rather it's a further change to the original proposal
> that you'd like to see.
>
> On Mon, 11 Mar 2024 at 11:48, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Thanks Matthias
>>
>> I'm generally supportive, but please see my comment exploring a minor
>> alternative
>> <https://github.com/ghc-proposals/ghc-proposals/pull/638#issuecomment-1988147639>
>> .
>>
>> Simon
>>
>> On Sat, 9 Mar 2024 at 00:12, Matthías Páll Gissurarson <mpg at mpg.is>
>> wrote:
>>
>>> Greetings committee!
>>>
>>> In [proposal #638](
>>> https://github.com/ghc-proposals/ghc-proposals/pull/638),
>>> @int-index proposes that we introduce a prefix form of MkSolo#, and
>>> apparent oversight in proposal #475 [Non-punning list and tuple syntax](
>>> https://github.com/ghc-proposals/ghc-proposals/pull/475).
>>>
>>> Previously, you would write `(# a #)` to construct a `Solo# a`.
>>> But the question is: what would be the prefix form of this constructor?
>>> It can't be `(# #)`, because this is already defined as a constructor of
>>> `Unit#`!
>>>
>>> This amendment proposes the `MkSolo#` constructor, having us write
>>> `MkSolo# a` for the prefix form. The discussion seems unanimous, after care
>>> was taken to clarify that a fully applied `MkSolo# a` would still be pretty
>>> printed as `(# a #)`, avoiding programmer confusion.
>>>
>>> It seems quite straightforward to me, so:
>>>
>>> I recommend accepting this amendment to #475.
>>>
>>>
>>> --
>>> --  Matthías Páll Gissurarson <http://mpg.is/>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> 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/20240312/411c98f6/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Mar 12 09:43:01 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 12 Mar 2024 10:43:01 +0100
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAJKmMz-HJ_BGpVgT31RbO-s=AsM1vzyR7bU22Z_O1rmEp5iUJQ@mail.gmail.com>
References: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
 <CAJKmMz-pMu8dmUcFt2tbZs_G_3gxnNrLiVS=wCHNOrP4EOsebA@mail.gmail.com>
 <CAGwnsnmci5a3C2EcjDn4gfWWDkOt4T8dbpeGfBvaFp=qqHiQ9Q@mail.gmail.com>
 <CAJKmMz-HJ_BGpVgT31RbO-s=AsM1vzyR7bU22Z_O1rmEp5iUJQ@mail.gmail.com>
Message-ID: <CAGwnsn=d+uwVzyJrnYNFiLOXysj=ciC48_bcSUtuj4CcY2ZWtQ@mail.gmail.com>

Unless I'm misreading, the proposal is only about the constructors' name.
Which you don't propose to change, do you?

(that being said, I think I agree with your comment that the name of the
type ought to have been `Tuple1`, it'd make more sense)

On Tue, 12 Mar 2024 at 10:38, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Well this proposal deepens the commitment to an exception for Solo and
> Solo#.   But I'm not really objecting, just asking.
>
> Simon
>
> On Tue, 12 Mar 2024 at 09:34, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> In favour.
>>
>> Simon: I don't think your objection pertains to this particular proposal
>> amendment, does it? Rather it's a further change to the original proposal
>> that you'd like to see.
>>
>> On Mon, 11 Mar 2024 at 11:48, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Thanks Matthias
>>>
>>> I'm generally supportive, but please see my comment exploring a minor
>>> alternative
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/638#issuecomment-1988147639>
>>> .
>>>
>>> Simon
>>>
>>> On Sat, 9 Mar 2024 at 00:12, Matthías Páll Gissurarson <mpg at mpg.is>
>>> wrote:
>>>
>>>> Greetings committee!
>>>>
>>>> In [proposal #638](
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/638),
>>>> @int-index proposes that we introduce a prefix form of MkSolo#, and
>>>> apparent oversight in proposal #475 [Non-punning list and tuple syntax](
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/475).
>>>>
>>>> Previously, you would write `(# a #)` to construct a `Solo# a`.
>>>> But the question is: what would be the prefix form of this constructor?
>>>> It can't be `(# #)`, because this is already defined as a constructor
>>>> of `Unit#`!
>>>>
>>>> This amendment proposes the `MkSolo#` constructor, having us write
>>>> `MkSolo# a` for the prefix form. The discussion seems unanimous, after care
>>>> was taken to clarify that a fully applied `MkSolo# a` would still be pretty
>>>> printed as `(# a #)`, avoiding programmer confusion.
>>>>
>>>> It seems quite straightforward to me, so:
>>>>
>>>> I recommend accepting this amendment to #475.
>>>>
>>>>
>>>> --
>>>> --  Matthías Páll Gissurarson <http://mpg.is/>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240312/ef7b9701/attachment.html>

From simon.peytonjones at gmail.com  Tue Mar 12 09:49:04 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 12 Mar 2024 09:49:04 +0000
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAGwnsn=d+uwVzyJrnYNFiLOXysj=ciC48_bcSUtuj4CcY2ZWtQ@mail.gmail.com>
References: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
 <CAJKmMz-pMu8dmUcFt2tbZs_G_3gxnNrLiVS=wCHNOrP4EOsebA@mail.gmail.com>
 <CAGwnsnmci5a3C2EcjDn4gfWWDkOt4T8dbpeGfBvaFp=qqHiQ9Q@mail.gmail.com>
 <CAJKmMz-HJ_BGpVgT31RbO-s=AsM1vzyR7bU22Z_O1rmEp5iUJQ@mail.gmail.com>
 <CAGwnsn=d+uwVzyJrnYNFiLOXysj=ciC48_bcSUtuj4CcY2ZWtQ@mail.gmail.com>
Message-ID: <CAJKmMz-xxB1Z9VjpMTWT-JJfaD95GQGSz+WeVQCcw1GK2J-YBw@mail.gmail.com>

>
> Unless I'm misreading, the proposal is only about the constructors' name.
> Which you don't propose to change, do you?


Yes. I was questioning the proposal itself rather than the amendment.

S

On Tue, 12 Mar 2024 at 09:43, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Unless I'm misreading, the proposal is only about the constructors' name.
> Which you don't propose to change, do you?
>
> (that being said, I think I agree with your comment that the name of the
> type ought to have been `Tuple1`, it'd make more sense)
>
> On Tue, 12 Mar 2024 at 10:38, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Well this proposal deepens the commitment to an exception for Solo and
>> Solo#.   But I'm not really objecting, just asking.
>>
>> Simon
>>
>> On Tue, 12 Mar 2024 at 09:34, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> In favour.
>>>
>>> Simon: I don't think your objection pertains to this particular proposal
>>> amendment, does it? Rather it's a further change to the original proposal
>>> that you'd like to see.
>>>
>>> On Mon, 11 Mar 2024 at 11:48, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Thanks Matthias
>>>>
>>>> I'm generally supportive, but please see my comment exploring a minor
>>>> alternative
>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/638#issuecomment-1988147639>
>>>> .
>>>>
>>>> Simon
>>>>
>>>> On Sat, 9 Mar 2024 at 00:12, Matthías Páll Gissurarson <mpg at mpg.is>
>>>> wrote:
>>>>
>>>>> Greetings committee!
>>>>>
>>>>> In [proposal #638](
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/638),
>>>>> @int-index proposes that we introduce a prefix form of MkSolo#, and
>>>>> apparent oversight in proposal #475 [Non-punning list and tuple syntax](
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/475).
>>>>>
>>>>> Previously, you would write `(# a #)` to construct a `Solo# a`.
>>>>> But the question is: what would be the prefix form of this constructor?
>>>>> It can't be `(# #)`, because this is already defined as a constructor
>>>>> of `Unit#`!
>>>>>
>>>>> This amendment proposes the `MkSolo#` constructor, having us write
>>>>> `MkSolo# a` for the prefix form. The discussion seems unanimous, after care
>>>>> was taken to clarify that a fully applied `MkSolo# a` would still be pretty
>>>>> printed as `(# a #)`, avoiding programmer confusion.
>>>>>
>>>>> It seems quite straightforward to me, so:
>>>>>
>>>>> I recommend accepting this amendment to #475.
>>>>>
>>>>>
>>>>> --
>>>>> --  Matthías Páll Gissurarson <http://mpg.is/>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>> _______________________________________________
>>>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240312/41b6489d/attachment.html>

From simon.peytonjones at gmail.com  Tue Mar 12 10:59:28 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 12 Mar 2024 10:59:28 +0000
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
Message-ID: <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>

I think we should accept the proposal as-is.  See my comment:
https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204

Simon

On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I think that the linear types part is a no-brainer.
>
> The infix operator one is less clear. Adam feels that it'd be weird if “a
> `op` b” yielded a different order than “op a b” as is being proposed. It's
> definitely something you could go both ways about. I'm personally worried
> about backward compatibility. Admittedly, this case where we quantify
> implicitly over a variable in infix position is probably rare. But the
> breakage would be quite subtle. I'm just not sure it's worth it. Do we care
> enough about the order of implicit quantification that we want to change
> this long established one? Richard is more optimistic
> https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968
>
> So, anyway, I'm open to be swayed by arguments, but my current thinking
> is: make the change for a %m -> b, but not for a `op` b.
>
> On Sat, 9 Mar 2024 at 22:46, Malte Ott <malte.ott at maralorn.de> wrote:
>
>> Dear all,
>>
>> Vlad proposes to change the order of implicit quantification for type
>> variables occurring as type operators or in multiplicity annotations:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/640
>>
>>
>> https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst
>>
>> The proposal is thankfully very simple. Change the implicit
>> quantification order for
>>
>> "a `op` b" from "forall op a b" to "forall a op b".
>>
>> and
>>
>> "a %m -> b" from "forall a b m" to "forall a m b".
>>
>> The proposed new behavior corresponds to the original paper and our user
>> guide.
>> This can be considered a bug fix and while we could also just change the
>> specification I think having a simple and memorable rule for
>> quantification
>> order is valuable. Especially the currently implemented quantification
>> order for
>> multiplicities is weird.
>>
>> The only painful point here is as usual a question of stability. What I
>> don’t
>> like about this change is, that if any code base uses it (which Vlad
>> doubts and
>> I tend to agree), the type error on GHC upgrade will be very
>> incomprehensible
>> for users who didn’t read and understand the changelog.
>>
>> However multiplicities are new and explicitely unstable and I don’t
>> really see a
>> reason why anyone would use infix notation on a qantified function. So I
>> agree
>> that this very unlikely to happen in the wild. Also, users who rely on
>> the type
>> application order right now should have noticed that something is off.
>>
>> Thus I recommend acceptance as is.
>>
>> Please voice your opinions!
>>
>> 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/20240312/3bdc66f4/attachment-0001.html>

From chris at chrisdornan.com  Tue Mar 12 16:38:50 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 12 Mar 2024 16:38:50 +0000
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#343)
In-Reply-To: <B839D8A8-DC07-408D-A140-9A4A877AB35F@chrisdornan.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
 <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
 <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@mail.gmail.com>
 <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>
 <7cce68ec-f48c-45cd-9c2e-c0180ac3b3cc@app.fastmail.com>
 <CAKfdd-wTAwa2LHivLP1U6XhKu3nNRzg8GJCz4qyA9rALrru81g@mail.gmail.com>
 <CAJKmMz_WHTLHWfDb-ALtZaeiJ3rQJv6v3kUrbdNApELnFTz5Sg@mail.gmail.com>
 <B839D8A8-DC07-408D-A140-9A4A877AB35F@chrisdornan.com>
Message-ID: <60432BC9-E40C-409E-8CB1-DED8FCDDD6F5@chrisdornan.com>

Folks,

Proposal: Fine-Grained Unused Warnings (#42)
Author: Jakob Brünker
Rendered proposal: https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
Recommendation: Acceptance

## Summary

The proposal partitions warning about unused identifiers into 

a) bindings that are truly unused (not mentioned anywhere) and 
b) bindings that are mentioned exclusively in code that is itself (transitively) unused,

and controls the latter with the new flag -Windirectly-unused-binds, which is enabled by default (to preserve existing behaviour).

Everybody seems to be in favour of the proposal in general and it has been extensively revised for clarity and to ensure in interoperates consistently with the existing warning-flags mechanisms.

I propose that we accept this proposal if nobody objects by the start of next week (Monday, 2024-03-18).

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240312/7e33e08f/attachment.html>

From simon.peytonjones at gmail.com  Tue Mar 12 16:50:46 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 12 Mar 2024 16:50:46 +0000
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#343)
In-Reply-To: <60432BC9-E40C-409E-8CB1-DED8FCDDD6F5@chrisdornan.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
 <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
 <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@mail.gmail.com>
 <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>
 <7cce68ec-f48c-45cd-9c2e-c0180ac3b3cc@app.fastmail.com>
 <CAKfdd-wTAwa2LHivLP1U6XhKu3nNRzg8GJCz4qyA9rALrru81g@mail.gmail.com>
 <CAJKmMz_WHTLHWfDb-ALtZaeiJ3rQJv6v3kUrbdNApELnFTz5Sg@mail.gmail.com>
 <B839D8A8-DC07-408D-A140-9A4A877AB35F@chrisdornan.com>
 <60432BC9-E40C-409E-8CB1-DED8FCDDD6F5@chrisdornan.com>
Message-ID: <CAJKmMz_QwFjyX-eOYQwLRehG=qFGXphbZe09bAFdxLUi_aMEtA@mail.gmail.com>

I support this.  I worked a lot with the author to make the spec precise.
(It was pretty confusing and incomplete before.)

TL;DR: the intent is clear and useful; the details are actually
surprisingly tricky.  But (like type inference) users won't really care!

Simon

On Tue, 12 Mar 2024 at 16:39, Chris Dornan <chris at chrisdornan.com> wrote:

> Folks,
>
> Proposal: Fine-Grained Unused Warnings (#42)
> Author: Jakob Brünker
> Rendered proposal:
> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
> Recommendation: Acceptance
>
> ## Summary
>
> The proposal partitions warning about unused identifiers into
>
> a) bindings that are truly unused (not mentioned anywhere) and
> b) bindings that are mentioned exclusively in code that is itself
> (transitively) unused,
>
> and controls the latter with the new flag -Windirectly-unused-binds,
> which is enabled by default (to preserve existing behaviour).
>
> Everybody seems to be in favour of the proposal in general and it has been
> extensively revised for clarity and to ensure in interoperates consistently
> with the existing warning-flags mechanisms.
>
> I propose that we accept this proposal if nobody objects by the start of
> next week (Monday, 2024-03-18).
>
> Chris
> _______________________________________________
> 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/20240312/eda2ac0f/attachment.html>

From moritz.angermann at gmail.com  Wed Mar 13 07:50:17 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 13 Mar 2024 15:50:17 +0800
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#343)
In-Reply-To: <CAJKmMz_QwFjyX-eOYQwLRehG=qFGXphbZe09bAFdxLUi_aMEtA@mail.gmail.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
 <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
 <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@mail.gmail.com>
 <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>
 <7cce68ec-f48c-45cd-9c2e-c0180ac3b3cc@app.fastmail.com>
 <CAKfdd-wTAwa2LHivLP1U6XhKu3nNRzg8GJCz4qyA9rALrru81g@mail.gmail.com>
 <CAJKmMz_WHTLHWfDb-ALtZaeiJ3rQJv6v3kUrbdNApELnFTz5Sg@mail.gmail.com>
 <B839D8A8-DC07-408D-A140-9A4A877AB35F@chrisdornan.com>
 <60432BC9-E40C-409E-8CB1-DED8FCDDD6F5@chrisdornan.com>
 <CAJKmMz_QwFjyX-eOYQwLRehG=qFGXphbZe09bAFdxLUi_aMEtA@mail.gmail.com>
Message-ID: <CAKfdd-y-xxeFrotgdro3x=nGsTTTN061GvVMjo5YRXS3AStgdw@mail.gmail.com>

This looks like a good change to me. There is no discussion around the
breaking implications of this, and only Joachim seems to have
called them out. E.g. tooling that tries to read GHC's human readable
output, and do something with that. The improved clarity of the
error messages though is arguably enough. And as far as breakage is
concerned, this would only happen to tools that use already a
fragile pass parsing log output of another program. I hope this won't cause
too much trouble down the line, and am I favour of this
proposal.

On Wed, 13 Mar 2024 at 00:51, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I support this.  I worked a lot with the author to make the spec precise.
> (It was pretty confusing and incomplete before.)
>
> TL;DR: the intent is clear and useful; the details are actually
> surprisingly tricky.  But (like type inference) users won't really care!
>
> Simon
>
> On Tue, 12 Mar 2024 at 16:39, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> Folks,
>>
>> Proposal: Fine-Grained Unused Warnings (#42)
>> Author: Jakob Brünker
>> Rendered proposal:
>> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
>> Recommendation: Acceptance
>>
>> ## Summary
>>
>> The proposal partitions warning about unused identifiers into
>>
>> a) bindings that are truly unused (not mentioned anywhere) and
>> b) bindings that are mentioned exclusively in code that is itself
>> (transitively) unused,
>>
>> and controls the latter with the new flag -Windirectly-unused-binds,
>> which is enabled by default (to preserve existing behaviour).
>>
>> Everybody seems to be in favour of the proposal in general and it has
>> been extensively revised for clarity and to ensure in interoperates
>> consistently with the existing warning-flags mechanisms.
>>
>> I propose that we accept this proposal if nobody objects by the start of
>> next week (Monday, 2024-03-18).
>>
>> Chris
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240313/d754c74a/attachment-0001.html>

From moritz.angermann at gmail.com  Wed Mar 13 07:57:00 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 13 Mar 2024 15:57:00 +0800
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
Message-ID: <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>

I feel myself agreeing with Arnaud on this. The LH part is a no brainer,
the infix op, i'm not fully convinced. But I'll trust Simon's intuition
here.

Simons comment reminded me I need to urgently get back to the -experimental
proposal.

On Tue, 12 Mar 2024 at 18:59, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I think we should accept the proposal as-is.  See my comment:
> https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204
>
> Simon
>
> On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> I think that the linear types part is a no-brainer.
>>
>> The infix operator one is less clear. Adam feels that it'd be weird if “a
>> `op` b” yielded a different order than “op a b” as is being proposed. It's
>> definitely something you could go both ways about. I'm personally worried
>> about backward compatibility. Admittedly, this case where we quantify
>> implicitly over a variable in infix position is probably rare. But the
>> breakage would be quite subtle. I'm just not sure it's worth it. Do we care
>> enough about the order of implicit quantification that we want to change
>> this long established one? Richard is more optimistic
>> https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968
>>
>> So, anyway, I'm open to be swayed by arguments, but my current thinking
>> is: make the change for a %m -> b, but not for a `op` b.
>>
>> On Sat, 9 Mar 2024 at 22:46, Malte Ott <malte.ott at maralorn.de> wrote:
>>
>>> Dear all,
>>>
>>> Vlad proposes to change the order of implicit quantification for type
>>> variables occurring as type operators or in multiplicity annotations:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/640
>>>
>>>
>>> https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst
>>>
>>> The proposal is thankfully very simple. Change the implicit
>>> quantification order for
>>>
>>> "a `op` b" from "forall op a b" to "forall a op b".
>>>
>>> and
>>>
>>> "a %m -> b" from "forall a b m" to "forall a m b".
>>>
>>> The proposed new behavior corresponds to the original paper and our user
>>> guide.
>>> This can be considered a bug fix and while we could also just change the
>>> specification I think having a simple and memorable rule for
>>> quantification
>>> order is valuable. Especially the currently implemented quantification
>>> order for
>>> multiplicities is weird.
>>>
>>> The only painful point here is as usual a question of stability. What I
>>> don’t
>>> like about this change is, that if any code base uses it (which Vlad
>>> doubts and
>>> I tend to agree), the type error on GHC upgrade will be very
>>> incomprehensible
>>> for users who didn’t read and understand the changelog.
>>>
>>> However multiplicities are new and explicitely unstable and I don’t
>>> really see a
>>> reason why anyone would use infix notation on a qantified function. So I
>>> agree
>>> that this very unlikely to happen in the wild. Also, users who rely on
>>> the type
>>> application order right now should have noticed that something is off.
>>>
>>> Thus I recommend acceptance as is.
>>>
>>> Please voice your opinions!
>>>
>>> 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
>>
> _______________________________________________
> 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/20240313/8fb0387b/attachment.html>

From rae at richarde.dev  Wed Mar 13 12:22:35 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 13 Mar 2024 12:22:35 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <0EA6A746-6D88-48C5-9F94-C222E2A134F6@richarde.dev>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <0EA6A746-6D88-48C5-9F94-C222E2A134F6@richarde.dev>
Message-ID: <010f018e37c3aef4-15e1786c-5456-47e4-a133-c10c75d1d24f-000000@us-east-2.amazonses.com>

Given the quiet here -- and the fact that this proposal seems to have a pretty small impact -- I've accepted.

Richard

> On Feb 26, 2024, at 8:29 AM, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> 
> 
>> On Jan 29, 2024, at 6:03 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>> 
>> I might be a bit confused, but doesn't this proposal change the meaning of an existing extension (PatternSignatures)? In which case shouldn't we do it properly according to our stability principles and either introduce the new behaviour as a new extension, or restrict the change to GHC2024 and later only?
>> 
> 
> Picking up this thread again (sorry for the delay).
> 
> As a reminder to all, about where we stand: This is about a small change to the deprecated extension -XPatternSignatures (which has been deprecated for at least as long as I've been doing Haskell). I personally don't see much merit in the change (it seems to achieve its goal only in a world where -XScopedTypeVariables is somehow deprecated, and that world seems unlikely to me), but neither do I see much downside. John Ericson, the proposer, sees an upside to the change, as does Joachim. We had basically settled leaning toward acceptance. Simon M wonders above about how this interacts with our stability principles.
> 
> In response to Simon: I think this is fine w.r.t. our stability principles, which include (GR3), saying that any change should come with a deprecation period. -XPatternSignatures has been deprecated for over a decade, which I think is sufficiently long. On the other hand, the deprecation doesn't describe the upcoming change, but I still think it's OK.
> 
> Richard


From rae at richarde.dev  Wed Mar 13 12:22:35 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 13 Mar 2024 12:22:35 +0000
Subject: [ghc-steering-committee] Proposal #606: small syntax change
 around types in terms; recommendation: vote
In-Reply-To: <EB9F1097-68CF-4FFC-A495-29E62DE01701@richarde.dev>
References: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
 <CAJKmMz9MVHJWyipdWo1HxGcDG+fSXOA-iVkTQVfUf-br7y19qA@mail.gmail.com>
 <EB9F1097-68CF-4FFC-A495-29E62DE01701@richarde.dev>
Message-ID: <010f018e37c3b018-d1a7967c-2c7c-45b4-a51d-a21963512756-000000@us-east-2.amazonses.com>

Let's call this one accepted. I've merged the MR.

Richard

> On Feb 26, 2024, at 8:42 AM, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> I've been on the fence, as have others here. Simon PJ describes himself as being far from the fence -- and in the same place as Vlad, our proposer and intrepid implementer. So while I'm not deeply convinced in my soul about this, I think the right choice as a committee is to go with option (2) in this thread (which is what the proposer is asking for).
> 
> I don't see much of a reason to keep extending this debate (everyone who is saying they care strongly is getting their way), but out of courtesy let's extend this to the end of the month (one extra day this year!). If I don't hear further comments, I'll accept this on Thursday.
> 
> Thanks!
> Richard
> 
>> On Jan 25, 2024, at 7:07 AM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> 
>> I vote (2), fairly strongly
>> 
>> Remember this comment from Vlad:
>> 
>> @phadej <https://github.com/phadej> For what it's worth, this was my initial thinking when I put ktype there, so past me agrees with you. What changed my opinion is that two years later (i.e. now) I looked at the examples like fn (type Int -> [a]) and had to double check the specification if it was supposed to be fn ((type Int) -> [a]) or fn (type (Int -> [a])).
>> 
>> The point is that the `type` namespace changer can appear deep within a type.  It's not like "@"!    For exmaple
>> fn ((type K) -> [a])
>> makes perfect sense.  fn has a required type argument, but in the (type K) sub-part of the type do we switch to the type namespace.  (Maybe K is in scope also as a data constructor.)  Without the parens, do you really want to wonder about how this parses?
>> fn (type K -> [a])
>> 
>> I prefer code that is slightly longer, but much clearer, than saving two characters but requiring reference to the user manual to parse.
>> 
>> Let's make it simple and unambiguous for now.  If it seems painful in practice we can debate liberalising it.
>> 
>> Simon
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto: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/20240313/0852cac0/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar 14 07:58:54 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 14 Mar 2024 08:58:54 +0100
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#343)
In-Reply-To: <CAKfdd-y-xxeFrotgdro3x=nGsTTTN061GvVMjo5YRXS3AStgdw@mail.gmail.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
 <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
 <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@mail.gmail.com>
 <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>
 <7cce68ec-f48c-45cd-9c2e-c0180ac3b3cc@app.fastmail.com>
 <CAKfdd-wTAwa2LHivLP1U6XhKu3nNRzg8GJCz4qyA9rALrru81g@mail.gmail.com>
 <CAJKmMz_WHTLHWfDb-ALtZaeiJ3rQJv6v3kUrbdNApELnFTz5Sg@mail.gmail.com>
 <B839D8A8-DC07-408D-A140-9A4A877AB35F@chrisdornan.com>
 <60432BC9-E40C-409E-8CB1-DED8FCDDD6F5@chrisdornan.com>
 <CAJKmMz_QwFjyX-eOYQwLRehG=qFGXphbZe09bAFdxLUi_aMEtA@mail.gmail.com>
 <CAKfdd-y-xxeFrotgdro3x=nGsTTTN061GvVMjo5YRXS3AStgdw@mail.gmail.com>
Message-ID: <CAGwnsn=YLY4ynSBmC=5b39kL_2aMiqRP4cRmrHfQUmtVFNz=8w@mail.gmail.com>

I'm in favour.

On Wed, 13 Mar 2024 at 08:50, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> This looks like a good change to me. There is no discussion around the
> breaking implications of this, and only Joachim seems to have
> called them out. E.g. tooling that tries to read GHC's human readable
> output, and do something with that. The improved clarity of the
> error messages though is arguably enough. And as far as breakage is
> concerned, this would only happen to tools that use already a
> fragile pass parsing log output of another program. I hope this won't
> cause too much trouble down the line, and am I favour of this
> proposal.
>
> On Wed, 13 Mar 2024 at 00:51, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I support this.  I worked a lot with the author to make the spec
>> precise.  (It was pretty confusing and incomplete before.)
>>
>> TL;DR: the intent is clear and useful; the details are actually
>> surprisingly tricky.  But (like type inference) users won't really care!
>>
>> Simon
>>
>> On Tue, 12 Mar 2024 at 16:39, Chris Dornan <chris at chrisdornan.com> wrote:
>>
>>> Folks,
>>>
>>> Proposal: Fine-Grained Unused Warnings (#42)
>>> Author: Jakob Brünker
>>> Rendered proposal:
>>> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
>>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
>>> Recommendation: Acceptance
>>>
>>> ## Summary
>>>
>>> The proposal partitions warning about unused identifiers into
>>>
>>> a) bindings that are truly unused (not mentioned anywhere) and
>>> b) bindings that are mentioned exclusively in code that is itself
>>> (transitively) unused,
>>>
>>> and controls the latter with the new flag -Windirectly-unused-binds,
>>> which is enabled by default (to preserve existing behaviour).
>>>
>>> Everybody seems to be in favour of the proposal in general and it has
>>> been extensively revised for clarity and to ensure in interoperates
>>> consistently with the existing warning-flags mechanisms.
>>>
>>> I propose that we accept this proposal if nobody objects by the start
>>> of next week (Monday, 2024-03-18).
>>>
>>> Chris
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240314/9b92a0b2/attachment-0001.html>

From mpg at mpg.is  Thu Mar 14 10:33:19 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Thu, 14 Mar 2024 10:33:19 +0000
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAJKmMz-xxB1Z9VjpMTWT-JJfaD95GQGSz+WeVQCcw1GK2J-YBw@mail.gmail.com>
References: <CAPxmXQwVjc1_XGuP6-V0BQ2-+rhJFJZ1A3xtyVb3SL53exwEYg@mail.gmail.com>
 <CAJKmMz-pMu8dmUcFt2tbZs_G_3gxnNrLiVS=wCHNOrP4EOsebA@mail.gmail.com>
 <CAGwnsnmci5a3C2EcjDn4gfWWDkOt4T8dbpeGfBvaFp=qqHiQ9Q@mail.gmail.com>
 <CAJKmMz-HJ_BGpVgT31RbO-s=AsM1vzyR7bU22Z_O1rmEp5iUJQ@mail.gmail.com>
 <CAGwnsn=d+uwVzyJrnYNFiLOXysj=ciC48_bcSUtuj4CcY2ZWtQ@mail.gmail.com>
 <CAJKmMz-xxB1Z9VjpMTWT-JJfaD95GQGSz+WeVQCcw1GK2J-YBw@mail.gmail.com>
Message-ID: <CAPxmXQxD3U2WJCTvOASFoxYK_oixNSvHn32K1swhHw_+4dUKFw@mail.gmail.com>

I agree with the sentiment here, having Type0 and Type1 as the canonical
names would have been preferable in the original proposal.
However, this amendment doesn't touch on that: it only changes the
constructor.

We'd still want MkSolo# even if Solo was the synonym, due to the ambiguity
described in the amendment.
Renaming the canonical types would be a further, separate amendment to the
original proposal.

I believe we should accept the amendment, and consider a
separate amendment later.

On Tue, 12 Mar 2024 at 09:49, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Unless I'm misreading, the proposal is only about the constructors' name.
>> Which you don't propose to change, do you?
>
>
> Yes. I was questioning the proposal itself rather than the amendment.
>
> S
>
> On Tue, 12 Mar 2024 at 09:43, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Unless I'm misreading, the proposal is only about the constructors' name.
>> Which you don't propose to change, do you?
>>
>> (that being said, I think I agree with your comment that the name of the
>> type ought to have been `Tuple1`, it'd make more sense)
>>
>> On Tue, 12 Mar 2024 at 10:38, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Well this proposal deepens the commitment to an exception for Solo and
>>> Solo#.   But I'm not really objecting, just asking.
>>>
>>> Simon
>>>
>>> On Tue, 12 Mar 2024 at 09:34, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> In favour.
>>>>
>>>> Simon: I don't think your objection pertains to this particular
>>>> proposal amendment, does it? Rather it's a further change to the original
>>>> proposal that you'd like to see.
>>>>
>>>> On Mon, 11 Mar 2024 at 11:48, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>>> Thanks Matthias
>>>>>
>>>>> I'm generally supportive, but please see my comment exploring a minor
>>>>> alternative
>>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/638#issuecomment-1988147639>
>>>>> .
>>>>>
>>>>> Simon
>>>>>
>>>>> On Sat, 9 Mar 2024 at 00:12, Matthías Páll Gissurarson <mpg at mpg.is>
>>>>> wrote:
>>>>>
>>>>>> Greetings committee!
>>>>>>
>>>>>> In [proposal #638](
>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/638),
>>>>>> @int-index proposes that we introduce a prefix form of MkSolo#, and
>>>>>> apparent oversight in proposal #475 [Non-punning list and tuple syntax](
>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/475).
>>>>>>
>>>>>> Previously, you would write `(# a #)` to construct a `Solo# a`.
>>>>>> But the question is: what would be the prefix form of this
>>>>>> constructor?
>>>>>> It can't be `(# #)`, because this is already defined as a constructor
>>>>>> of `Unit#`!
>>>>>>
>>>>>> This amendment proposes the `MkSolo#` constructor, having us write
>>>>>> `MkSolo# a` for the prefix form. The discussion seems unanimous, after care
>>>>>> was taken to clarify that a fully applied `MkSolo# a` would still be pretty
>>>>>> printed as `(# a #)`, avoiding programmer confusion.
>>>>>>
>>>>>> It seems quite straightforward to me, so:
>>>>>>
>>>>>> I recommend accepting this amendment to #475.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --  Matthías Páll Gissurarson <http://mpg.is/>
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org
>>>>>>
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>
>

-- 
--  Matthías Páll Gissurarson <http://mpg.is/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240314/1cd70f88/attachment.html>

From malte.ott at maralorn.de  Thu Mar 14 11:02:54 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Thu, 14 Mar 2024 12:02:54 +0100
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#343)
In-Reply-To: <60432BC9-E40C-409E-8CB1-DED8FCDDD6F5@chrisdornan.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
 <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
 <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@mail.gmail.com>
 <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>
 <7cce68ec-f48c-45cd-9c2e-c0180ac3b3cc@app.fastmail.com>
 <CAKfdd-wTAwa2LHivLP1U6XhKu3nNRzg8GJCz4qyA9rALrru81g@mail.gmail.com>
 <CAJKmMz_WHTLHWfDb-ALtZaeiJ3rQJv6v3kUrbdNApELnFTz5Sg@mail.gmail.com>
 <B839D8A8-DC07-408D-A140-9A4A877AB35F@chrisdornan.com>
 <60432BC9-E40C-409E-8CB1-DED8FCDDD6F5@chrisdornan.com>
Message-ID: <tea2ii5orav6kn6pstpu3q5rhkm4bm52xgihm35sxfdfhqc5ug@hera.m-0.eu>

Dear all,

this proposal is great. I added a few comments about details on GitHub.

Best
Malte

On 2024-03-12 16:38, Chris Dornan wrote:
> Folks,
> 
> Proposal: Fine-Grained Unused Warnings (#42)
> Author: Jakob Brünker
> Rendered proposal: https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
> Recommendation: Acceptance
> 
> ## Summary
> 
> The proposal partitions warning about unused identifiers into 
> 
> a) bindings that are truly unused (not mentioned anywhere) and 
> b) bindings that are mentioned exclusively in code that is itself (transitively) unused,
> 
> and controls the latter with the new flag -Windirectly-unused-binds, which is enabled by default (to preserve existing behaviour).
> 
> Everybody seems to be in favour of the proposal in general and it has been extensively revised for clarity and to ensure in interoperates consistently with the existing warning-flags mechanisms.
> 
> I propose that we accept this proposal if nobody objects by the start of next week (Monday, 2024-03-18).
> 
> Chris

> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From arnaud.spiwack at tweag.io  Thu Mar 14 13:32:43 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 14 Mar 2024 14:32:43 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
Message-ID: <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>

Dear all,

Shea has updated his proposal based on the committee's feedback.

There seem to be two main alternatives being considered at the moment
- Having a type class to compute the exit code based on the type. This is
Shea's favourite. It can be done without an extension (as Shea's proposing)
or with an extension.
- Keep the current behaviour but emit a warning when the return type of
`main` isn't `()` or `Void`.

I have opinions about my preference, but I'd like to hear about everybody's
thoughts first.

On Thu, 7 Mar 2024 at 10:27, Adam Gundry <adam at well-typed.com> wrote:

> I've added a comment to the GitHub thread
> (
> https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1983060484)
>
> elaborating slightly on Richard's suggestion (albeit with an effectively
> indefinite transition period).
>
> Adam
>
>
> On 05/03/2024 08:52, Arnaud Spiwack wrote:
> > This is Alternative 7.5 in the current version of the proposal
> >
> https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance
> <
> https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main-return-types.rst#75require-an-exitstatus-instance>
> .
> >
> > PS: I tend to agree with Richard that requiring an ExitStatus instance
> > is the preferable option. But food for thought for the proposal thread
> > when that conversation happens there: should that be gated behind an
> > extension? In which case it won't become the default before the next
> > language edition.
> >
> > /Arnaud
> >
> > On Mon, 4 Mar 2024 at 21:35, Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >
> >         I left out a key part of my last email -- apologies. I'm
> >         floating a counter-proposal where we *require* an instance of
> >         ExitStatus on the return type of `main`, with a transition
> >         period. In contrast, my understanding of the proposal written is
> >         that it would use such an instance if it exists, but issue a
> >         warning if it doesn't, in perpetuity.
> >
> >
> >     Ah  I had not realised that.
> >
> >     But why?
> >
> >     Rather than answer here (private to SC) why don't you put your
> >     proposal on the discussion thread, say why, and invite feedback.
> >
> >     Simon
> >
> >
> >     On Mon, 4 Mar 2024 at 19:24, Richard Eisenberg
> >     <reisenberg at janestreet.com <mailto:reisenberg at janestreet.com>>
> wrote:
> >
> >         I left out a key part of my last email -- apologies. I'm
> >         floating a counter-proposal where we *require* an instance of
> >         ExitStatus on the return type of `main`, with a transition
> >         period. In contrast, my understanding of the proposal written is
> >         that it would use such an instance if it exists, but issue a
> >         warning if it doesn't, in perpetuity.
> >
> >         Richard
> >
> >         On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones
> >         <simon.peytonjones at gmail.com
> >         <mailto:simon.peytonjones at gmail.com>> wrote:
> >
> >                 I am a little worried about breaking programs that end
> >                 in an innocent-looking `return 0`, just because some
> >                 other languages like to end programs with that phrase
> >
> >
> >             The proposal specifies that such a program returns
> >             `ExitSuccess`, but adds a warning. That seems OK to me; it
> >             does not break the program.
> >
> >             Oh -- maybe you mean that `return 1` means "return with exit
> >             code 1" today.  Is that really true?  I don't think so.
> >
> >             Overall this proposal seems fine to me.  I'd be happy to see
> >             it done.
> >
> >             Simon
> >
> >             On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg
> >             <reisenberg at janestreet.com
> >             <mailto:reisenberg at janestreet.com>> wrote:
> >
> >                 I haven't followed this proposal closely. But couldn't
> >                 we have a transition period toward this eventual goal?
> >                 That is, introduce a new warning, on by default, if
> >                 `main` returns anything other than `()`. That goes for a
> >                 few releases. Then we require that the return type of
> >                 main has an instance of ExitStatus.
> >
> >                 I'm not worried about changing the behavior of programs
> >                 that have type IO ExitCode but expect the program to
> >                 return 0 unconditionally; that's just begging for
> >                 confusion. I am a little worried about breaking programs
> >                 that end in an innocent-looking `return 0`, just because
> >                 some other languages like to end programs with that
> >                 phrase. So I'm not sure if we should have an instance
> >                 ExitStatus Int (or instance ExitStatus Integer) -- but
> >                 we probably should. If a program ends with `return 1`,
> >                 the programmer probably wants the OS to return 1 as well.
> >
> >                 Richard
> >
> >                 On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack
> >                 <arnaud.spiwack at tweag.io
> >                 <mailto:arnaud.spiwack at tweag.io>> wrote:
> >
> >                     Dear all,
> >
> >                     Shea Levy proposes to do something with the values
> >                     returned by `main`
> >
> https://github.com/ghc-proposals/ghc-proposals/pull/631 <
> https://github.com/ghc-proposals/ghc-proposals/pull/631> .
> >
> >                     The problem is that `main` is allowed to be of type
> >                     `IO A` for any `A`. And GHC will simply drop the
> >                     value returned by `main`. Shea contends that it's
> >                     surprising. I agree that dropping a value without
> >                     the compiler being explicitly instructed to is
> >                     surprising. But Shea says that when `A` is
> >                     `ExitCode` this is even more surprising. Namely
> >                     `main :: IO ExitCode; main = return $ Failure 1`
> >                     actually terminates with exit code 0. And I doubt
> >                     that it's what anybody expects when reading the code.
> >
> >                     The proposal is simple, but I have a lot of comments
> >                     on it. Sorry about that…
> >
> >                     Now, this sort of proposal is tricky. When the
> >                     current behaviour is confusing, we want to change
> >                     the default. But putting the new default behind an
> >                     extension doesn't really solve the fact that there's
> >                     a trap. The extension is, therefore, unlikely to be
> >                     well tested before it becomes part of the next
> >                     language edition.
> >
> >                     Shea's main proposition doesn't actually use an
> >                     extension though. He adds a type class `ExitStatus`,
> >                     and if `ExistStatus A`, then `main :: IO A` uses the
> >                     instance to determine the exit code based on the
> >                     return value.
> >
> >                     The only change to the current behaviour is that
> >                     `main :: IO ExitCode` instead of always terminating
> >                     with exit code 0 when returning now terminates with
> >                     the expected error code. The argument for not
> >                     putting this behind an extension is that virtually
> >                     anybody affected by the change will actually have
> >                     the behaviour they were expecting. But maybe the
> >                     argument isn't strong enough (the changes may be
> >                     more “interesting” if some library exports some
> >                     `ExistStatus` instance).
> >
> >                     This design of this proposal is inspired by Rust's
> >                     design. I've asked our Rust team, and they certainly
> >                     seem to have internalised the idea of returning an
> >                     exit code. It really seems a pretty natural feature
> >                     to have. So I'm rather in favour of some flavour of
> >                     the type class implementation. Though have a look at
> >                     the alternatives, where you'll find other approaches
> >                     such as restricting the type of `main` to
> >                     unsurprising types.
> >
> >                     One caveat with respect to the main proposal: it is
> >                     proposed that when no `ExistStatus A` is found, then
> >                     we drop the returned value like today. I don't know
> >                     that it's quite easy to implement this behaviour.
> >                     But it can be recovered by a catch-all overlapping
> >                     instance, so maybe it's a better way to specify the
> >                     desired behaviour.
> >
> >                     --
> >                     Arnaud Spiwack
> >                     Director, Research at https://moduscreate.com
> >                     <https://moduscreate.com> and https://tweag.io
> >                     <https://tweag.io>.
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20240314/0e12a8c2/attachment-0001.html>

From malte.ott at maralorn.de  Thu Mar 14 14:04:17 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Thu, 14 Mar 2024 15:04:17 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
Message-ID: <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>

I like the proposal basically as is. i.e. typeclass + warning
Especially the fact that it warns everyone and breaks no-one (who doesn’t want
to).

I am weakly in favor of gating the usage of the typeclass for anything but ()
and Void behind an extension. That way no program will newly exit with failure
without the user opting in and we might be able to experiment more on the type
class.

Best
Malte

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


From simon.peytonjones at gmail.com  Thu Mar 14 16:51:03 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 14 Mar 2024 16:51:03 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
Message-ID: <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>

I like the proposal basically as is. i.e. typeclass + warning
Especially the fact that it warns everyone and breaks no-one (who doesn’t
want
to).

I am weakly in favor of gating the usage of the typeclass for anything but
()
and Void behind an extension. That way no program will newly exit with
failure
without the user opting in and we might be able to experiment more on the
type
class.


I'm with Malte.   But I don't have strongly held views.

Simon

On Thu, 14 Mar 2024 at 14:04, Malte Ott <malte.ott at maralorn.de> wrote:

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

From marlowsd at gmail.com  Fri Mar 15 13:15:29 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 15 Mar 2024 13:15:29 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
Message-ID: <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>

I also think any change in behaviour should be behind an extension.

Cheers
Simon

On Thu, 14 Mar 2024 at 16:51, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

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

From mpg at mpg.is  Fri Mar 15 14:31:39 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Fri, 15 Mar 2024 14:31:39 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
Message-ID: <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>

I agree. I like it, but better behind an extension to avoid surprises and
enable experimentation.

On Fri, 15 Mar 2024 at 13:15, Simon Marlow <marlowsd at gmail.com> wrote:

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


-- 
--  Matthías Páll Gissurarson <http://mpg.is/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240315/4e86bdc6/attachment-0001.html>

From eric at seidel.io  Sun Mar 17 14:15:40 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 17 Mar 2024 09:15:40 -0500
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
Message-ID: <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>

I agree with Simon's intuition on GH, and support acceptance as-is.

On Wed, Mar 13, 2024, at 02:57, Moritz Angermann wrote:
> I feel myself agreeing with Arnaud on this. The LH part is a no 
> brainer, the infix op, i'm not fully convinced. But I'll trust Simon's 
> intuition here.
>
> Simons comment reminded me I need to urgently get back to the 
> -experimental proposal.
>
> On Tue, 12 Mar 2024 at 18:59, Simon Peyton Jones 
> <simon.peytonjones at gmail.com> wrote:
>> I think we should accept the proposal as-is.  See my comment: https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204
>> 
>> Simon
>> 
>> On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>> I think that the linear types part is a no-brainer.
>>> 
>>> The infix operator one is less clear. Adam feels that it'd be weird if “a `op` b” yielded a different order than “op a b” as is being proposed. It's definitely something you could go both ways about. I'm personally worried about backward compatibility. Admittedly, this case where we quantify implicitly over a variable in infix position is probably rare. But the breakage would be quite subtle. I'm just not sure it's worth it. Do we care enough about the order of implicit quantification that we want to change this long established one? Richard is more optimistic https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968
>>> 
>>> So, anyway, I'm open to be swayed by arguments, but my current thinking is: make the change for a %m -> b, but not for a `op` b.
>>> 
>>> On Sat, 9 Mar 2024 at 22:46, Malte Ott <malte.ott at maralorn.de> wrote:
>>>> Dear all,
>>>> 
>>>> Vlad proposes to change the order of implicit quantification for type
>>>> variables occurring as type operators or in multiplicity annotations:
>>>> 
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/640
>>>> 
>>>> https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst
>>>> 
>>>> The proposal is thankfully very simple. Change the implicit quantification order for
>>>> 
>>>> "a `op` b" from "forall op a b" to "forall a op b".
>>>> 
>>>> and 
>>>> 
>>>> "a %m -> b" from "forall a b m" to "forall a m b".
>>>> 
>>>> The proposed new behavior corresponds to the original paper and our user guide.
>>>> This can be considered a bug fix and while we could also just change the
>>>> specification I think having a simple and memorable rule for quantification
>>>> order is valuable. Especially the currently implemented quantification order for
>>>> multiplicities is weird.
>>>> 
>>>> The only painful point here is as usual a question of stability. What I don’t
>>>> like about this change is, that if any code base uses it (which Vlad doubts and
>>>> I tend to agree), the type error on GHC upgrade will be very incomprehensible
>>>> for users who didn’t read and understand the changelog.
>>>> 
>>>> However multiplicities are new and explicitely unstable and I don’t really see a
>>>> reason why anyone would use infix notation on a qantified function. So I agree
>>>> that this very unlikely to happen in the wild. Also, users who rely on the type
>>>> application order right now should have noticed that something is off.
>>>> 
>>>> Thus I recommend acceptance as is.
>>>> 
>>>> Please voice your opinions!
>>>> 
>>>> 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
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From adam at well-typed.com  Tue Mar 19 08:18:10 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 19 Mar 2024 08:18:10 +0000
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
Message-ID: <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>

As I wrote on GH, I'm not convinced by the change for infix type 
operators (the linear arrows change is fine). The odds of breakage are 
slight, but non-zero, and it's a particularly nasty form of breakage 
because a library may use an infix operator but the changed 
quantification order only affect downstream code using that library with 
TypeApplications. Perhaps nobody will be affected, but if someone is, 
they would have some justification to feel aggrieved at this change!

If there was a compelling benefit to changing the status quo, this could 
be justifiable, but in this case I don't really see the harm in carving 
out an exception for infix operators from the usual "quantification is 
left-to-right" rule.

Adam


On 17/03/2024 14:15, Eric Seidel wrote:
> I agree with Simon's intuition on GH, and support acceptance as-is.
> 
> On Wed, Mar 13, 2024, at 02:57, Moritz Angermann wrote:
>> I feel myself agreeing with Arnaud on this. The LH part is a no
>> brainer, the infix op, i'm not fully convinced. But I'll trust Simon's
>> intuition here.
>>
>> Simons comment reminded me I need to urgently get back to the
>> -experimental proposal.
>>
>> On Tue, 12 Mar 2024 at 18:59, Simon Peyton Jones
>> <simon.peytonjones at gmail.com> wrote:
>>> I think we should accept the proposal as-is.  See my comment: https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204
>>>
>>> Simon
>>>
>>> On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>>> I think that the linear types part is a no-brainer.
>>>>
>>>> The infix operator one is less clear. Adam feels that it'd be weird if “a `op` b” yielded a different order than “op a b” as is being proposed. It's definitely something you could go both ways about. I'm personally worried about backward compatibility. Admittedly, this case where we quantify implicitly over a variable in infix position is probably rare. But the breakage would be quite subtle. I'm just not sure it's worth it. Do we care enough about the order of implicit quantification that we want to change this long established one? Richard is more optimistic https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968
>>>>
>>>> So, anyway, I'm open to be swayed by arguments, but my current thinking is: make the change for a %m -> b, but not for a `op` b.
>>>>
>>>> On Sat, 9 Mar 2024 at 22:46, Malte Ott <malte.ott at maralorn.de> wrote:
>>>>> Dear all,
>>>>>
>>>>> Vlad proposes to change the order of implicit quantification for type
>>>>> variables occurring as type operators or in multiplicity annotations:
>>>>>
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/640
>>>>>
>>>>> https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst
>>>>>
>>>>> The proposal is thankfully very simple. Change the implicit quantification order for
>>>>>
>>>>> "a `op` b" from "forall op a b" to "forall a op b".
>>>>>
>>>>> and
>>>>>
>>>>> "a %m -> b" from "forall a b m" to "forall a m b".
>>>>>
>>>>> The proposed new behavior corresponds to the original paper and our user guide.
>>>>> This can be considered a bug fix and while we could also just change the
>>>>> specification I think having a simple and memorable rule for quantification
>>>>> order is valuable. Especially the currently implemented quantification order for
>>>>> multiplicities is weird.
>>>>>
>>>>> The only painful point here is as usual a question of stability. What I don’t
>>>>> like about this change is, that if any code base uses it (which Vlad doubts and
>>>>> I tend to agree), the type error on GHC upgrade will be very incomprehensible
>>>>> for users who didn’t read and understand the changelog.
>>>>>
>>>>> However multiplicities are new and explicitely unstable and I don’t really see a
>>>>> reason why anyone would use infix notation on a qantified function. So I agree
>>>>> that this very unlikely to happen in the wild. Also, users who rely on the type
>>>>> application order right now should have noticed that something is off.
>>>>>
>>>>> Thus I recommend acceptance as is.
>>>>>
>>>>> Please voice your opinions!
>>>>>
>>>>> Malte


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Tue Mar 19 09:25:51 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 19 Mar 2024 09:25:51 +0000
Subject: [ghc-steering-committee] Fwd: Please review #640: Fix
 quantification order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
 <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
Message-ID: <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>

As I wrote on GH, I'm not convinced by the change for infix type
operators (the linear arrows change is fine).


I don't agree with your intuition on infix operators.  As I wrote on GH:

I sympathise with this, but *any* specification amounts to specify some
> linearisation of the tree. Your mental linearisation puts the function of
> (a op b) first; and mine does to. BUT I don't want us to have to specify
> a linearisation function, because *we already have one*: it's called
> "look at the left to right order of what the user wrote". It may not be a
> great linearisation function, but it is simple, easy to specify, no further
> explanation needed.


But I think you are now saying that *even if a left-to-right order was
"best", *there is a long-standing bug in GHC that puts `b` first in (a `b`
c`), and it's not worth the risk of change.   So instead we should
institutionalise the bug into the spec.

A change would break code like
f :: a `m` b -> (a,b)
...
foo = ...(f @Either @Int @Bool)...

where we have

   - An infix type operator that is a variable
   - Other type variables in the first argument of the infix application
   - No type-class constraint  (Wombat m => a `m` b) would put `m` first.
   - Visible type applications in at least one calls site

So yes, it's an un-forced breakage.  So maybe institutionalising the
exception into the spec is the right thing to do.

I would love to hear from other members of the committee with more
user-centric experience.

Simon

On Tue, 19 Mar 2024 at 08:18, Adam Gundry <adam at well-typed.com> wrote:

> As I wrote on GH, I'm not convinced by the change for infix type
> operators (the linear arrows change is fine). The odds of breakage are
> slight, but non-zero, and it's a particularly nasty form of breakage
> because a library may use an infix operator but the changed
> quantification order only affect downstream code using that library with
> TypeApplications. Perhaps nobody will be affected, but if someone is,
> they would have some justification to feel aggrieved at this change!
>
> If there was a compelling benefit to changing the status quo, this could
> be justifiable, but in this case I don't really see the harm in carving
> out an exception for infix operators from the usual "quantification is
> left-to-right" rule.
>
> Adam
>
>
> On 17/03/2024 14:15, Eric Seidel wrote:
> > I agree with Simon's intuition on GH, and support acceptance as-is.
> >
> > On Wed, Mar 13, 2024, at 02:57, Moritz Angermann wrote:
> >> I feel myself agreeing with Arnaud on this. The LH part is a no
> >> brainer, the infix op, i'm not fully convinced. But I'll trust Simon's
> >> intuition here.
> >>
> >> Simons comment reminded me I need to urgently get back to the
> >> -experimental proposal.
> >>
> >> On Tue, 12 Mar 2024 at 18:59, Simon Peyton Jones
> >> <simon.peytonjones at gmail.com> wrote:
> >>> I think we should accept the proposal as-is.  See my comment:
> https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204
> >>>
> >>> Simon
> >>>
> >>> On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> >>>> I think that the linear types part is a no-brainer.
> >>>>
> >>>> The infix operator one is less clear. Adam feels that it'd be weird
> if “a `op` b” yielded a different order than “op a b” as is being proposed.
> It's definitely something you could go both ways about. I'm personally
> worried about backward compatibility. Admittedly, this case where we
> quantify implicitly over a variable in infix position is probably rare. But
> the breakage would be quite subtle. I'm just not sure it's worth it. Do we
> care enough about the order of implicit quantification that we want to
> change this long established one? Richard is more optimistic
> https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968
> >>>>
> >>>> So, anyway, I'm open to be swayed by arguments, but my current
> thinking is: make the change for a %m -> b, but not for a `op` b.
> >>>>
> >>>> On Sat, 9 Mar 2024 at 22:46, Malte Ott <malte.ott at maralorn.de> wrote:
> >>>>> Dear all,
> >>>>>
> >>>>> Vlad proposes to change the order of implicit quantification for type
> >>>>> variables occurring as type operators or in multiplicity annotations:
> >>>>>
> >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/640
> >>>>>
> >>>>>
> https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst
> >>>>>
> >>>>> The proposal is thankfully very simple. Change the implicit
> quantification order for
> >>>>>
> >>>>> "a `op` b" from "forall op a b" to "forall a op b".
> >>>>>
> >>>>> and
> >>>>>
> >>>>> "a %m -> b" from "forall a b m" to "forall a m b".
> >>>>>
> >>>>> The proposed new behavior corresponds to the original paper and our
> user guide.
> >>>>> This can be considered a bug fix and while we could also just change
> the
> >>>>> specification I think having a simple and memorable rule for
> quantification
> >>>>> order is valuable. Especially the currently implemented
> quantification order for
> >>>>> multiplicities is weird.
> >>>>>
> >>>>> The only painful point here is as usual a question of stability.
> What I don’t
> >>>>> like about this change is, that if any code base uses it (which Vlad
> doubts and
> >>>>> I tend to agree), the type error on GHC upgrade will be very
> incomprehensible
> >>>>> for users who didn’t read and understand the changelog.
> >>>>>
> >>>>> However multiplicities are new and explicitely unstable and I don’t
> really see a
> >>>>> reason why anyone would use infix notation on a qantified function.
> So I agree
> >>>>> that this very unlikely to happen in the wild. Also, users who rely
> on the type
> >>>>> application order right now should have noticed that something is
> off.
> >>>>>
> >>>>> Thus I recommend acceptance as is.
> >>>>>
> >>>>> Please voice your opinions!
> >>>>>
> >>>>> Malte
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20240319/062d2f31/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Mar 19 14:12:33 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 19 Mar 2024 15:12:33 +0100
Subject: [ghc-steering-committee] Fwd: Please review #640: Fix
 quantification order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
 <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
 <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>
Message-ID: <CAGwnsnkEO4no6HdNMXXCvXW=TxM2m4yfJNEj638Cj-n=YyA0xw@mail.gmail.com>

On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> But I think you are now saying that *even if a left-to-right order was
> "best", *there is a long-standing bug in GHC that puts `b` first in (a
> `b` c`), and it's not worth the risk of change.   So instead we should
> institutionalise the bug into the spec.
>

This is, at least, my position. This is a bug fix, but the bug is so tiny,
that even if the breakage is rare, it's not necessarily worth it, and it
may be better to bake the exception into the spec. I'm weakly on the side
that baking the exception is better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240319/ff3454db/attachment.html>

From arnaud.spiwack at tweag.io  Tue Mar 19 14:15:25 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 19 Mar 2024 15:15:25 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
 <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>
 <CAJKmMz-sODQ2ytatOCZ7VUkQB-Exeqg7Qqi4wt3rDsDj9qcoLg@mail.gmail.com>
 <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
Message-ID: <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>

So, my opinion that I promised, is that the best would probably be to have
add a warning when main doesn't have type `IO ()` or `IO Void` without the
extension (the behaviour is otherwise unchanged), and then change the
behaviour to use the typeclass with an extension (which we hope to turn on
by default in the next language edition). The extension should probably
disable the warning.

Now, I don't actually know how to implement this properly. So maybe it's a
bad idea. But I believe that's what I'd like to see.


On Fri, 15 Mar 2024 at 15:32, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

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

From malte.ott at maralorn.de  Wed Mar 20 23:19:15 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Thu, 21 Mar 2024 00:19:15 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
References: <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
Message-ID: <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>

On 2024-03-19 15:15, Arnaud Spiwack wrote:
> So, my opinion that I promised, is that the best would probably be to have
> add a warning when main doesn't have type `IO ()` or `IO Void` without the
> extension (the behaviour is otherwise unchanged), and then change the
> behaviour to use the typeclass with an extension (which we hope to turn on
> by default in the next language edition). The extension should probably
>
> Now, I don't actually know how to implement this properly. So maybe it's a
> bad idea. But I believe that's what I'd like to see.
> disable the warning.

>From my understanding that is basically equivalent to what I was proposing.
It has the properties:

* Using a return type which could reasonably be expected to exit with failure
  should warn on -Wdefault (no matter whether a potential extension is enabled).
  * Concretely this means any return type but (), Void and maybe forall a. a, when the extension is off.
    * The warning could point to existing instances and the extension.
  * For anything which does not have an ExitCode implementation, when the extension is on.
* Using the ExitCode type class should be possible but gated behind an extension.

Now the question whether we should have two different warnings, one when the
extension is on and one when it is off or one warning which changes its wording
and behavior slightly depending on the extension being enabled does not matter
that much in my opinion.

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


From malte.ott at maralorn.de  Wed Mar 20 23:42:23 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Thu, 21 Mar 2024 00:42:23 +0100
Subject: [ghc-steering-committee] Fwd: Please review #640: Fix
 quantification order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAGwnsnkEO4no6HdNMXXCvXW=TxM2m4yfJNEj638Cj-n=YyA0xw@mail.gmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
 <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
 <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>
 <CAGwnsnkEO4no6HdNMXXCvXW=TxM2m4yfJNEj638Cj-n=YyA0xw@mail.gmail.com>
Message-ID: <2ocr3mtaqcolqnii63pyru2tio5nzbuc7y4h4ua5rpxfp5hw6e@hera.m-0.eu>

Okay, let me summarize the voiced opinions:

We have agreement on the change to multiplicities.

On the infix type operator we are a bit stuck:

* Richard, Eric and I are in favor of fixing the bug.
* Adam and Arnaud are in favor of staying stable, living with the exception
* Simon was on the fix side but switched to undecided, waiting for more opinions
* Moritz preferred staying stable, but deferred to Simon before his switch

Overall slightly more votes for the change but subjectively hold less strongly
than the opinions against it.

Since I am unclear on how to proceed I’d love to hear more opinions (especially
of committee members who haven’t voiced theirs about this proposal).

I am generally not a fan of enshrining historic coincidence in the language when
the cost of fixing it is bareable. On the other hand this is such a minor detail
that I don’t think it will matter much in either direction.

If we cannot come to a consensus soon I will put it a to a vote. We
shouldn’t spend too much time on this.

Best
Malte

On 2024-03-19 15:12, Arnaud Spiwack wrote:
> On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> 
> > But I think you are now saying that *even if a left-to-right order was
> > "best", *there is a long-standing bug in GHC that puts `b` first in (a
> > `b` c`), and it's not worth the risk of change.   So instead we should
> > institutionalise the bug into the spec.
> >
> 
> This is, at least, my position. This is a bug fix, but the bug is so tiny,
> that even if the breakage is rare, it's not necessarily worth it, and it
> may be better to bake the exception into the spec. I'm weakly on the side
> that baking the exception is better.

> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From adam at well-typed.com  Thu Mar 21 08:06:37 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 21 Mar 2024 08:06:37 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders in
	type declarations
Message-ID: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder 
forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

From adam at well-typed.com  Thu Mar 21 09:07:53 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 21 Mar 2024 09:07:53 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
Message-ID: <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>

Apologies for letting this thread linger.

The current de facto situation is that GHC 9.10 will ship with GHC2024 
available but not enabled by default. (Given the timing, it did not seem 
feasible to change the default, and but leaving GHC2024 out of the 
release entirely would seem unnecessary.)

Several people have expressed the opinion that we should actively plan 
to switch the default, to benefit one-off use (especially in ghci), 
rather than simply leaving GHC2021 as the default indefinitely. So the 
question is what level of messaging is appropriate before that happens. 
I can see a few options, none of which are entirely satisfying:

  * Mention in the release notes (done for 9.10, and easily done in the 
next release).

  * Add an off-by-default warning about failure to specify a language 
edition (maybe in -Wall or -Wcompat). Unclear this benefits many people 
because if they aren't specifying a language edition or reading the 
release notes, they may well not be enabling non-default warnings either.

  * Enable the warning about failure to specify a language edition by 
default. A bit noisy for ad hoc use.

  * Add a warning where NoMonoLocalBinds is used and changing to 
MonoLocalBinds would break the program (since this is the most likely 
source of breakage in practice). This warning could be enabled by 
default if no language edition is specified. Nice for users, but 
probably quite a bit of implementation overhead, so unclear if it would 
be implemented.

  * Wait for a super-major release (e.g. the 10.x series) before 
changing the default language. Not clear when this will be.

Any other options? Opinions?

Adam


On 19/02/2024 21:34, Eric Seidel wrote:
> It seems to me that this particular proposal could make sense
> tactically, but I agree with Chris and Arnaud that it feels
> like the wrong thing strategically.
> 
> I don't see us getting away from a notion of a "default language".
> GCC/Clang similarly implement many C/C++ standards and let users
> choose, but still define a default standard per compiler version.
> And this default changes across compiler releases. Forcing even
> adhoc ghc[i] sessions to specify a language standard feels
> excessive.
> 
> Thus, we need *some* cadence for updating the default language.
> It could be that GHC 9.10 is too soon to make that change, but
> we should commit to making the change at some point, with proper
> messaging.
> 
> Eric
> 
> On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:
>> Thanks everyone for sharing your thoughts.
>>
>> I would point out that this is not just about "the handful of people
>> that have ghci scripts" but rather anyone compiling modules with ghc
>> directly (not using Cabal). Were it about ghci alone, I agree that the
>> latest language edition would be preferable. But it seems likely to be a
>> larger class, e.g. including educators teaching Haskell, and users with
>> small programs where they have not created a Cabal package.
>>
>> Adam
>>
>>
>> On 16/02/2024 08:36, Arnaud Spiwack wrote:
>>> (I won't be able to follow this conversation as I'll be on holiday for
>>> the next week so dropping my thoughts a little unstructured)
>>>
>>> I'm not keen on giving people gratuitous work. I think staging making
>>> GHC2024 the default borders on gratuitous work (because I'm not
>>> convinced that the transition period will achieve anything, but on the
>>> other hand, it gives us a little bit of time to warn people). The idea
>>> that we will want to make a decision for each edition in the future
>>> regarding whether it's to be the default is definitely gratuitous work
>>> (I can be convinced otherwise, of course: this is my current train of
>>> thoughts).
>>> Generally speaking, all cabal projects have a fixed `default-language`
>>> (which, we learnt, is Haskell98 if omitted). So really we're doing this
>>> for the handful of people that have ghci scripts. And we're making
>>> everybody else's life worse (because ghci is worse). I'm, obviously, a
>>> strong believer in the power of defaults.
>>>
>>> So, anyway, without having had much time to think about this: maybe ok
>>> for staging GHC2024 in particular, just this once. I think it's a bad
>>> idea, but not a hill I'll die on. The rest of the proposal I'm rather
>>> opposed to.
>>>
>>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan <chris at chrisdornan.com
>>> <mailto:chris at chrisdornan.com>> wrote:
>>>
>>>      Sorry, I misunderstood the proposal — for some reason I thought we
>>>      were going to delay the default for ghci.
>>>
>>>      If we think the new language is going to be particularly disruptive
>>>      then we might want a transition period where it is available before
>>>      making it the default — I really have no objection to this at all in
>>>      general.
>>>
>>>      I will just suggest that we might want to enable these defaults
>>>      quite aggressively — and I say this having been bitten by GHC2021
>>>      myself. We are committed to breaking stuff — is there much to be
>>>      gained by delaying. Is it not going to delay take-up? It makes the
>>>      whole process more complicated.
>>>
>>>      Chris
>>>
>>>
>>>>      On 15 Feb 2024, at 16:08, Simon Peyton Jones
>>>>      <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>>>      wrote:
>>>>
>>>>      I'm not understanding  your point, Chris.
>>>>
>>>>      I think we are planning to increasingly encourage people to
>>>>      specify an explicit language edition for everything.  (Indeed
>>>>      there is discussion of an on-by-default warning that complains if
>>>>      you don't.)  For these users, the "default language edition" is
>>>>      irrelevant.
>>>>
>>>>      So the only issue is people who don't specify a language edition
>>>>      at all.   Changing the default language edition risks breaking
>>>>      their code.  Why would we do that? What compelling reason is there
>>>>      for breaking code that we don't have to break?
>>>>
>>>>      For the short term,
>>>>
>>>>        * GHC2024 is particularly likely to break code
>>>>        * We have not yet educated our users to use explicit language
>>>>          editions
>>>>
>>>>      So making GHC2024 be the default language for GHC 9.10 seems (to
>>>>      me) to lead to entirely-unnecessary breakage, with no compelling
>>>>      reason to do so.
>>>>
>>>>      Simon
>>>>
>>>>      On Thu, 15 Feb 2024 at 13:21, Chris Dornan <chris at chrisdornan.com
>>>>      <mailto:chris at chrisdornan.com>> wrote:
>>>>
>>>>          I have been a strongly in favour of minimising surprises but I
>>>>          mildly resistant to this proposal.
>>>>
>>>>          After GHC2021 broke my code quite severly (though PolyKinds)
>>>>          there was an initial adjustment phase but I quickly got used
>>>>          to specifying the exact language I want to use everywhere.
>>>>          Indeed the propensity for GHCi to pick up the new breakage
>>>>          caused some surprises but I quickly adjusted when I realised
>>>>          what was going on.
>>>>
>>>>          The point is not that change is bad but change that is
>>>>          difficult to anticipate and control is bad.
>>>>
>>>>          I now see the GHC adoption of the new default languages, that
>>>>          can very selectively break things when needed, as a fantastic
>>>>          development. It allows us to roll out changes in a very
>>>>          controlled way where at synchronisation points that are easy
>>>>          to understand and where developers retain control. This
>>>>          strikes me as a really great sweet spot for Haskell.
>>>>
>>>>          If we make this scheme more complicated by making some the
>>>>          tools adopt languages on different schedules then it risks
>>>>          creating confusion. Folks that want to tie down advanced
>>>>          features strike me as just the kind that should find it easy
>>>>          to fill out the appropriate settings in configuration files.
>>>>
>>>>          So I say lets get this rolled out ASAP (as Adam says) but roll
>>>>          it out consistently everywhere.
>>>>
>>>>          Chris
>>>>
>>>>
>>>>>          On 15 Feb 2024, at 09:15, Simon Peyton Jones
>>>>>          <simon.peytonjones at gmail.com
>>>>>          <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>
>>>>>          I'm ok with this proposal.  The whole concept of a default
>>>>>          language seems a bit flaky to me, if we are going to start
>>>>>          warning any time someone doesn't explicitly specify an
>>>>>          explicit addition.  While this is settling down, causing
>>>>>          minimum disruption is good.
>>>>>
>>>>>          Simon
>>>>>
>>>>>          On Thu, 15 Feb 2024 at 08:50, Adam Gundry
>>>>>          <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>>>
>>>>>              Dear committee,
>>>>>
>>>>>              In #632, I propose amending the GHC2024 proposal to
>>>>>              specify that the
>>>>>              default language used by ghc/ghci when run directly will
>>>>>              remain GHC2021
>>>>>              for now, since changing to GHC2024 is not backwards
>>>>>              compatible. (This
>>>>>              does not affect Cabal packages either way, since Cabal
>>>>>              specifies its own
>>>>>              default.)
>>>>>
>>>>>              https://github.com/ghc-proposals/ghc-proposals/pull/632
>>>>>              <https://github.com/ghc-proposals/ghc-proposals/pull/632>
>>>>>
>>>>>              https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024 <https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024>
>>>>>
>>>>>              On the discussion thread, some people expressed a
>>>>>              preference that GHC
>>>>>              should default to the latest language edition anyway.
>>>>>              There is also
>>>>>              Richard's suggestion of wider changes of approach in
>>>>>              #636. However,
>>>>>              given that the GHC 9.10 fork date is fast approaching,
>>>>>              introducing
>>>>>              GHC2024 but not making it the default seems like the best
>>>>>              short-term
>>>>>              solution to me. We can always reassess our approach to
>>>>>              this for future
>>>>>              releases as part of the wider discussion.
>>>>>
>>>>>              If you object to the proposed approach, please speak up
>>>>>              ASAP. Otherwise
>>>>>              I plan to merge in a week or so.
>>>>>
>>>>>              Cheers,
>>>>>
>>>>>              Adam
>>


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Thu Mar 21 09:56:37 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 21 Mar 2024 09:56:37 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
Message-ID: <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>

Dear Steering Committee

Vlad proposes to amend proposal #425
<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
permit more wildcard binder forms in type declarations:
  https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff
<https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
.

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens.  The
change is *not driven by user need*, but rather solely by *uniformity*:
these same forms are permitted in function definitions:

f :: forall (a :: k). blah
f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data
types, etc.  Nothing hard, but more.

It's not a big deal either way.  Very few people expressed a view on
GitHub.  My personal view is that the modest (albeit non-zero) gain does
not justify the definite (albeit modest) pain. I would leave this until
someone actually wants it.

Vlad argues for future-proofing, but my experience is that an eye to the
future is sensible when you are making changes anyway; but making unforced
changes solely for the future risks incurring pain now that, when the
future comes, turns out to have been a poor investment.  We may have
correctly anticipated, or we may not.

So my recommendation is to park this until we get a real user demand.

It's a perfectly sensible proposal, but adopting it is a judgement call.
I'll leave a week for committee responses, and then we can just vote.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:

> Dear Committee,
>
> Vlad proposes to amend proposal #425 to permit more wildcard binder
> forms in type declarations:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/641
>
> I'd like to nominate Simon PJ as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Cheers,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> 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/20240321/ba83520b/attachment.html>

From simon.peytonjones at gmail.com  Thu Mar 21 10:08:02 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 21 Mar 2024 10:08:02 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
Message-ID: <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>

It's hard to answer this without addressing the following question

   - Do we want to actively encourage Haskell users to specify a language
   edition for every module (via a LANGUAGE pragma, cabal file, or command
   line option)?

I think we should thus encourage them.  Because that greatly increases the
chances that if the module compiles with GHC(X) then it'll compile with
GHC(X+k).

If they do this, then the "default language edition" barely matters.

Indeed, I want to question the merit of having a "default language edition"
at all.  Suppose the default language edition was GHC2021 forever.  All by
itself that would encourage the use of an explicit language edition, to get
hold a coherent bundle of extensions beyond GHC2021.  We might not need to
do any more than that.

Simon



On Thu, 21 Mar 2024 at 09:08, Adam Gundry <adam at well-typed.com> wrote:

> Apologies for letting this thread linger.
>
> The current de facto situation is that GHC 9.10 will ship with GHC2024
> available but not enabled by default. (Given the timing, it did not seem
> feasible to change the default, and but leaving GHC2024 out of the
> release entirely would seem unnecessary.)
>
> Several people have expressed the opinion that we should actively plan
> to switch the default, to benefit one-off use (especially in ghci),
> rather than simply leaving GHC2021 as the default indefinitely. So the
> question is what level of messaging is appropriate before that happens.
> I can see a few options, none of which are entirely satisfying:
>
>   * Mention in the release notes (done for 9.10, and easily done in the
> next release).
>
>   * Add an off-by-default warning about failure to specify a language
> edition (maybe in -Wall or -Wcompat). Unclear this benefits many people
> because if they aren't specifying a language edition or reading the
> release notes, they may well not be enabling non-default warnings either.
>
>   * Enable the warning about failure to specify a language edition by
> default. A bit noisy for ad hoc use.
>
>   * Add a warning where NoMonoLocalBinds is used and changing to
> MonoLocalBinds would break the program (since this is the most likely
> source of breakage in practice). This warning could be enabled by
> default if no language edition is specified. Nice for users, but
> probably quite a bit of implementation overhead, so unclear if it would
> be implemented.
>
>   * Wait for a super-major release (e.g. the 10.x series) before
> changing the default language. Not clear when this will be.
>
> Any other options? Opinions?
>
> Adam
>
>
> On 19/02/2024 21:34, Eric Seidel wrote:
> > It seems to me that this particular proposal could make sense
> > tactically, but I agree with Chris and Arnaud that it feels
> > like the wrong thing strategically.
> >
> > I don't see us getting away from a notion of a "default language".
> > GCC/Clang similarly implement many C/C++ standards and let users
> > choose, but still define a default standard per compiler version.
> > And this default changes across compiler releases. Forcing even
> > adhoc ghc[i] sessions to specify a language standard feels
> > excessive.
> >
> > Thus, we need *some* cadence for updating the default language.
> > It could be that GHC 9.10 is too soon to make that change, but
> > we should commit to making the change at some point, with proper
> > messaging.
> >
> > Eric
> >
> > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:
> >> Thanks everyone for sharing your thoughts.
> >>
> >> I would point out that this is not just about "the handful of people
> >> that have ghci scripts" but rather anyone compiling modules with ghc
> >> directly (not using Cabal). Were it about ghci alone, I agree that the
> >> latest language edition would be preferable. But it seems likely to be a
> >> larger class, e.g. including educators teaching Haskell, and users with
> >> small programs where they have not created a Cabal package.
> >>
> >> Adam
> >>
> >>
> >> On 16/02/2024 08:36, Arnaud Spiwack wrote:
> >>> (I won't be able to follow this conversation as I'll be on holiday for
> >>> the next week so dropping my thoughts a little unstructured)
> >>>
> >>> I'm not keen on giving people gratuitous work. I think staging making
> >>> GHC2024 the default borders on gratuitous work (because I'm not
> >>> convinced that the transition period will achieve anything, but on the
> >>> other hand, it gives us a little bit of time to warn people). The idea
> >>> that we will want to make a decision for each edition in the future
> >>> regarding whether it's to be the default is definitely gratuitous work
> >>> (I can be convinced otherwise, of course: this is my current train of
> >>> thoughts).
> >>> Generally speaking, all cabal projects have a fixed `default-language`
> >>> (which, we learnt, is Haskell98 if omitted). So really we're doing this
> >>> for the handful of people that have ghci scripts. And we're making
> >>> everybody else's life worse (because ghci is worse). I'm, obviously, a
> >>> strong believer in the power of defaults.
> >>>
> >>> So, anyway, without having had much time to think about this: maybe ok
> >>> for staging GHC2024 in particular, just this once. I think it's a bad
> >>> idea, but not a hill I'll die on. The rest of the proposal I'm rather
> >>> opposed to.
> >>>
> >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan <chris at chrisdornan.com
> >>> <mailto:chris at chrisdornan.com>> wrote:
> >>>
> >>>      Sorry, I misunderstood the proposal — for some reason I thought we
> >>>      were going to delay the default for ghci.
> >>>
> >>>      If we think the new language is going to be particularly
> disruptive
> >>>      then we might want a transition period where it is available
> before
> >>>      making it the default — I really have no objection to this at all
> in
> >>>      general.
> >>>
> >>>      I will just suggest that we might want to enable these defaults
> >>>      quite aggressively — and I say this having been bitten by GHC2021
> >>>      myself. We are committed to breaking stuff — is there much to be
> >>>      gained by delaying. Is it not going to delay take-up? It makes the
> >>>      whole process more complicated.
> >>>
> >>>      Chris
> >>>
> >>>
> >>>>      On 15 Feb 2024, at 16:08, Simon Peyton Jones
> >>>>      <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com
> >>
> >>>>      wrote:
> >>>>
> >>>>      I'm not understanding  your point, Chris.
> >>>>
> >>>>      I think we are planning to increasingly encourage people to
> >>>>      specify an explicit language edition for everything.  (Indeed
> >>>>      there is discussion of an on-by-default warning that complains if
> >>>>      you don't.)  For these users, the "default language edition" is
> >>>>      irrelevant.
> >>>>
> >>>>      So the only issue is people who don't specify a language edition
> >>>>      at all.   Changing the default language edition risks breaking
> >>>>      their code.  Why would we do that? What compelling reason is
> there
> >>>>      for breaking code that we don't have to break?
> >>>>
> >>>>      For the short term,
> >>>>
> >>>>        * GHC2024 is particularly likely to break code
> >>>>        * We have not yet educated our users to use explicit language
> >>>>          editions
> >>>>
> >>>>      So making GHC2024 be the default language for GHC 9.10 seems (to
> >>>>      me) to lead to entirely-unnecessary breakage, with no compelling
> >>>>      reason to do so.
> >>>>
> >>>>      Simon
> >>>>
> >>>>      On Thu, 15 Feb 2024 at 13:21, Chris Dornan <
> chris at chrisdornan.com
> >>>>      <mailto:chris at chrisdornan.com>> wrote:
> >>>>
> >>>>          I have been a strongly in favour of minimising surprises but
> I
> >>>>          mildly resistant to this proposal.
> >>>>
> >>>>          After GHC2021 broke my code quite severly (though PolyKinds)
> >>>>          there was an initial adjustment phase but I quickly got used
> >>>>          to specifying the exact language I want to use everywhere.
> >>>>          Indeed the propensity for GHCi to pick up the new breakage
> >>>>          caused some surprises but I quickly adjusted when I realised
> >>>>          what was going on.
> >>>>
> >>>>          The point is not that change is bad but change that is
> >>>>          difficult to anticipate and control is bad.
> >>>>
> >>>>          I now see the GHC adoption of the new default languages, that
> >>>>          can very selectively break things when needed, as a fantastic
> >>>>          development. It allows us to roll out changes in a very
> >>>>          controlled way where at synchronisation points that are easy
> >>>>          to understand and where developers retain control. This
> >>>>          strikes me as a really great sweet spot for Haskell.
> >>>>
> >>>>          If we make this scheme more complicated by making some the
> >>>>          tools adopt languages on different schedules then it risks
> >>>>          creating confusion. Folks that want to tie down advanced
> >>>>          features strike me as just the kind that should find it easy
> >>>>          to fill out the appropriate settings in configuration files.
> >>>>
> >>>>          So I say lets get this rolled out ASAP (as Adam says) but
> roll
> >>>>          it out consistently everywhere.
> >>>>
> >>>>          Chris
> >>>>
> >>>>
> >>>>>          On 15 Feb 2024, at 09:15, Simon Peyton Jones
> >>>>>          <simon.peytonjones at gmail.com
> >>>>>          <mailto:simon.peytonjones at gmail.com>> wrote:
> >>>>>
> >>>>>          I'm ok with this proposal.  The whole concept of a default
> >>>>>          language seems a bit flaky to me, if we are going to start
> >>>>>          warning any time someone doesn't explicitly specify an
> >>>>>          explicit addition.  While this is settling down, causing
> >>>>>          minimum disruption is good.
> >>>>>
> >>>>>          Simon
> >>>>>
> >>>>>          On Thu, 15 Feb 2024 at 08:50, Adam Gundry
> >>>>>          <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> >>>>>
> >>>>>              Dear committee,
> >>>>>
> >>>>>              In #632, I propose amending the GHC2024 proposal to
> >>>>>              specify that the
> >>>>>              default language used by ghc/ghci when run directly will
> >>>>>              remain GHC2021
> >>>>>              for now, since changing to GHC2024 is not backwards
> >>>>>              compatible. (This
> >>>>>              does not affect Cabal packages either way, since Cabal
> >>>>>              specifies its own
> >>>>>              default.)
> >>>>>
> >>>>>              https://github.com/ghc-proposals/ghc-proposals/pull/632
> >>>>>              <
> https://github.com/ghc-proposals/ghc-proposals/pull/632>
> >>>>>
> >>>>>
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> <
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> >
> >>>>>
> >>>>>              On the discussion thread, some people expressed a
> >>>>>              preference that GHC
> >>>>>              should default to the latest language edition anyway.
> >>>>>              There is also
> >>>>>              Richard's suggestion of wider changes of approach in
> >>>>>              #636. However,
> >>>>>              given that the GHC 9.10 fork date is fast approaching,
> >>>>>              introducing
> >>>>>              GHC2024 but not making it the default seems like the
> best
> >>>>>              short-term
> >>>>>              solution to me. We can always reassess our approach to
> >>>>>              this for future
> >>>>>              releases as part of the wider discussion.
> >>>>>
> >>>>>              If you object to the proposed approach, please speak up
> >>>>>              ASAP. Otherwise
> >>>>>              I plan to merge in a week or so.
> >>>>>
> >>>>>              Cheers,
> >>>>>
> >>>>>              Adam
> >>
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20240321/09ad4059/attachment-0001.html>

From simon.peytonjones at gmail.com  Thu Mar 21 10:11:25 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 21 Mar 2024 10:11:25 +0000
Subject: [ghc-steering-committee] Fwd: Please review #640: Fix
 quantification order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <2ocr3mtaqcolqnii63pyru2tio5nzbuc7y4h4ua5rpxfp5hw6e@hera.m-0.eu>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
 <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
 <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>
 <CAGwnsnkEO4no6HdNMXXCvXW=TxM2m4yfJNEj638Cj-n=YyA0xw@mail.gmail.com>
 <2ocr3mtaqcolqnii63pyru2tio5nzbuc7y4h4ua5rpxfp5hw6e@hera.m-0.eu>
Message-ID: <CAJKmMz8SU4aW6W-AYn3ZiiZftG380mU9v1bZG7gcRkDcHKSwdQ@mail.gmail.com>

Great summary.

I am generally not a fan of enshrining historic coincidence in the language
when
the cost of fixing it is bareable. On the other hand this is such a minor
detail
that I don’t think it will matter much in either direction.


That's exactly why I am on the fence!

Chris, Simon M, Matthias, any opinions?

We may just have to vote, as Malte says

Simon


On Wed, 20 Mar 2024 at 23:42, Malte Ott <malte.ott at maralorn.de> wrote:

> Okay, let me summarize the voiced opinions:
>
> We have agreement on the change to multiplicities.
>
> On the infix type operator we are a bit stuck:
>
> * Richard, Eric and I are in favor of fixing the bug.
> * Adam and Arnaud are in favor of staying stable, living with the exception
> * Simon was on the fix side but switched to undecided, waiting for more
> opinions
> * Moritz preferred staying stable, but deferred to Simon before his switch
>
> Overall slightly more votes for the change but subjectively hold less
> strongly
> than the opinions against it.
>
> Since I am unclear on how to proceed I’d love to hear more opinions
> (especially
> of committee members who haven’t voiced theirs about this proposal).
>
> I am generally not a fan of enshrining historic coincidence in the
> language when
> the cost of fixing it is bareable. On the other hand this is such a minor
> detail
> that I don’t think it will matter much in either direction.
>
> If we cannot come to a consensus soon I will put it a to a vote. We
> shouldn’t spend too much time on this.
>
> Best
> Malte
>
> On 2024-03-19 15:12, Arnaud Spiwack wrote:
> > On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <
> > simon.peytonjones at gmail.com> wrote:
> >
> > > But I think you are now saying that *even if a left-to-right order was
> > > "best", *there is a long-standing bug in GHC that puts `b` first in (a
> > > `b` c`), and it's not worth the risk of change.   So instead we should
> > > institutionalise the bug into the spec.
> > >
> >
> > This is, at least, my position. This is a bug fix, but the bug is so
> tiny,
> > that even if the breakage is rare, it's not necessarily worth it, and it
> > may be better to bake the exception into the spec. I'm weakly on the side
> > that baking the exception is better.
>
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> 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/20240321/eea7881c/attachment.html>

From chris at chrisdornan.com  Thu Mar 21 11:46:20 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 21 Mar 2024 11:46:20 +0000
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAJKmMz8SU4aW6W-AYn3ZiiZftG380mU9v1bZG7gcRkDcHKSwdQ@mail.gmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
 <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
 <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>
 <CAGwnsnkEO4no6HdNMXXCvXW=TxM2m4yfJNEj638Cj-n=YyA0xw@mail.gmail.com>
 <2ocr3mtaqcolqnii63pyru2tio5nzbuc7y4h4ua5rpxfp5hw6e@hera.m-0.eu>
 <CAJKmMz8SU4aW6W-AYn3ZiiZftG380mU9v1bZG7gcRkDcHKSwdQ@mail.gmail.com>
Message-ID: <AA528EC2-2CA3-4AFA-827E-C5BC57A7C103@chrisdornan.com>

I can go either way. We should make the linear change of course. Both Simon and Adam make good arguments for accepting and rejecting the infix operator aspect.

I would probably be tempted to stick with the status quo but am happy	to accept the whole proposal — as that requires no further change I am coming down on that side — to accept the whole proposal unless someone objects.

Chris

> On 21 Mar 2024, at 10:11, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Great summary.
> 
> I am generally not a fan of enshrining historic coincidence in the language when
> the cost of fixing it is bareable. On the other hand this is such a minor detail
> that I don’t think it will matter much in either direction.
> 
> That's exactly why I am on the fence!
> 
> Chris, Simon M, Matthias, any opinions?
> 
> We may just have to vote, as Malte says
> 
> Simon
> 
> 
> On Wed, 20 Mar 2024 at 23:42, Malte Ott <malte.ott at maralorn.de <mailto:malte.ott at maralorn.de>> wrote:
>> Okay, let me summarize the voiced opinions:
>> 
>> We have agreement on the change to multiplicities.
>> 
>> On the infix type operator we are a bit stuck:
>> 
>> * Richard, Eric and I are in favor of fixing the bug.
>> * Adam and Arnaud are in favor of staying stable, living with the exception
>> * Simon was on the fix side but switched to undecided, waiting for more opinions
>> * Moritz preferred staying stable, but deferred to Simon before his switch
>> 
>> Overall slightly more votes for the change but subjectively hold less strongly
>> than the opinions against it.
>> 
>> Since I am unclear on how to proceed I’d love to hear more opinions (especially
>> of committee members who haven’t voiced theirs about this proposal).
>> 
>> I am generally not a fan of enshrining historic coincidence in the language when
>> the cost of fixing it is bareable. On the other hand this is such a minor detail
>> that I don’t think it will matter much in either direction.
>> 
>> If we cannot come to a consensus soon I will put it a to a vote. We
>> shouldn’t spend too much time on this.
>> 
>> Best
>> Malte
>> 
>> On 2024-03-19 15:12, Arnaud Spiwack wrote:
>> > On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <
>> > simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> > 
>> > > But I think you are now saying that *even if a left-to-right order was
>> > > "best", *there is a long-standing bug in GHC that puts `b` first in (a
>> > > `b` c`), and it's not worth the risk of change.   So instead we should
>> > > institutionalise the bug into the spec.
>> > >
>> > 
>> > This is, at least, my position. This is a bug fix, but the bug is so tiny,
>> > that even if the breakage is rare, it's not necessarily worth it, and it
>> > may be better to bake the exception into the spec. I'm weakly on the side
>> > that baking the exception is better.
>> 
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/20240321/2cdca345/attachment.html>

From chris at chrisdornan.com  Thu Mar 21 11:46:20 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 21 Mar 2024 11:46:20 +0000
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAJKmMz8SU4aW6W-AYn3ZiiZftG380mU9v1bZG7gcRkDcHKSwdQ@mail.gmail.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
 <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
 <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>
 <CAGwnsnkEO4no6HdNMXXCvXW=TxM2m4yfJNEj638Cj-n=YyA0xw@mail.gmail.com>
 <2ocr3mtaqcolqnii63pyru2tio5nzbuc7y4h4ua5rpxfp5hw6e@hera.m-0.eu>
 <CAJKmMz8SU4aW6W-AYn3ZiiZftG380mU9v1bZG7gcRkDcHKSwdQ@mail.gmail.com>
Message-ID: <AA528EC2-2CA3-4AFA-827E-C5BC57A7C103@chrisdornan.com>

I can go either way. We should make the linear change of course. Both Simon and Adam make good arguments for accepting and rejecting the infix operator aspect.

I would probably be tempted to stick with the status quo but am happy	to accept the whole proposal — as that requires no further change I am coming down on that side — to accept the whole proposal unless someone objects.

Chris

> On 21 Mar 2024, at 10:11, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Great summary.
> 
> I am generally not a fan of enshrining historic coincidence in the language when
> the cost of fixing it is bareable. On the other hand this is such a minor detail
> that I don’t think it will matter much in either direction.
> 
> That's exactly why I am on the fence!
> 
> Chris, Simon M, Matthias, any opinions?
> 
> We may just have to vote, as Malte says
> 
> Simon
> 
> 
> On Wed, 20 Mar 2024 at 23:42, Malte Ott <malte.ott at maralorn.de <mailto:malte.ott at maralorn.de>> wrote:
>> Okay, let me summarize the voiced opinions:
>> 
>> We have agreement on the change to multiplicities.
>> 
>> On the infix type operator we are a bit stuck:
>> 
>> * Richard, Eric and I are in favor of fixing the bug.
>> * Adam and Arnaud are in favor of staying stable, living with the exception
>> * Simon was on the fix side but switched to undecided, waiting for more opinions
>> * Moritz preferred staying stable, but deferred to Simon before his switch
>> 
>> Overall slightly more votes for the change but subjectively hold less strongly
>> than the opinions against it.
>> 
>> Since I am unclear on how to proceed I’d love to hear more opinions (especially
>> of committee members who haven’t voiced theirs about this proposal).
>> 
>> I am generally not a fan of enshrining historic coincidence in the language when
>> the cost of fixing it is bareable. On the other hand this is such a minor detail
>> that I don’t think it will matter much in either direction.
>> 
>> If we cannot come to a consensus soon I will put it a to a vote. We
>> shouldn’t spend too much time on this.
>> 
>> Best
>> Malte
>> 
>> On 2024-03-19 15:12, Arnaud Spiwack wrote:
>> > On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <
>> > simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> > 
>> > > But I think you are now saying that *even if a left-to-right order was
>> > > "best", *there is a long-standing bug in GHC that puts `b` first in (a
>> > > `b` c`), and it's not worth the risk of change.   So instead we should
>> > > institutionalise the bug into the spec.
>> > >
>> > 
>> > This is, at least, my position. This is a bug fix, but the bug is so tiny,
>> > that even if the breakage is rare, it's not necessarily worth it, and it
>> > may be better to bake the exception into the spec. I'm weakly on the side
>> > that baking the exception is better.
>> 
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/20240321/2cdca345/attachment-0003.html>

From mpg at mpg.is  Thu Mar 21 17:46:57 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Thu, 21 Mar 2024 17:46:57 +0000
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <AA528EC2-2CA3-4AFA-827E-C5BC57A7C103@chrisdornan.com>
References: <25b7fa38-900f-43df-b89e-c10c56c2cf35@well-typed.com>
 <e3ztfd57ytbkqupulbm7xkpdhs5naidrzfxegqqgumpfm5i4io@hera.m-0.eu>
 <CAGwnsnmCfS=vAP08FKBe0ij6ZWmn6hGHh1CmTcgQBO9dpj1yoQ@mail.gmail.com>
 <CAJKmMz9Mg8d0BEJ7D4CVJ6cdJVzA2+x=w8ay7BDhdR7bvPUYLQ@mail.gmail.com>
 <CAKfdd-yLkbZ++7ejv8Lc-M=+kUuSPeWL4B+HkOvHvhf5GXxyaA@mail.gmail.com>
 <ff2d5a9a-caa8-46dc-b483-a82d6eecd995@app.fastmail.com>
 <d6949eea-d8f7-4736-a04b-e7f924f853ad@well-typed.com>
 <CAJKmMz_Nu6zBDaJPZtaQobBTpfXzhL+DMTop31bLdNi=oVO3Bg@mail.gmail.com>
 <CAGwnsnkEO4no6HdNMXXCvXW=TxM2m4yfJNEj638Cj-n=YyA0xw@mail.gmail.com>
 <2ocr3mtaqcolqnii63pyru2tio5nzbuc7y4h4ua5rpxfp5hw6e@hera.m-0.eu>
 <CAJKmMz8SU4aW6W-AYn3ZiiZftG380mU9v1bZG7gcRkDcHKSwdQ@mail.gmail.com>
 <AA528EC2-2CA3-4AFA-827E-C5BC57A7C103@chrisdornan.com>
Message-ID: <CAPxmXQxwS9a1dnuaw9GudwL425mxrrbpS31eE9-vhKC__YpHtg@mail.gmail.com>

I’m in favor of the proposal:

For

a `m` b -> (a,b)

I think it’s debatable, “forall a m b” vs “forall m a b”

But what about more nested expressions? If we had

(a `m` b) `n` (c `o` d) -> (a,b,c,d),

The current order would give “forall n m a b o c d”, whereas the change
would give “forall a m b n c o d”. The latter is “less surprising”, and I’m
in favor of the element of least surprise. Same with linear multiplicities,
I was surprised to see the m being last in “a %m -> b”.

As mentioned before, this seems unlikely to cause breakage in the wild, and
the fix is a simple explicit forall. So I’m in favor of the bug fix.

/Matti Palli


On Thu, Mar 21, 2024 at 11:46 Chris Dornan <chris at chrisdornan.com> wrote:

> I can go either way. We should make the linear change of course. Both
> Simon and Adam make good arguments for accepting and rejecting the infix
> operator aspect.
>
> I would probably be tempted to stick with the status quo but am happy to
> accept the whole proposal — as that requires no further change I am coming
> down on that side — to accept the whole proposal unless someone objects.
>
>
> Chris
>
> On 21 Mar 2024, at 10:11, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> Great summary.
>
> I am generally not a fan of enshrining historic coincidence in the
> language when
> the cost of fixing it is bareable. On the other hand this is such a minor
> detail
> that I don’t think it will matter much in either direction.
>
>
> That's exactly why I am on the fence!
>
> Chris, Simon M, Matthias, any opinions?
>
> We may just have to vote, as Malte says
>
> Simon
>
>
> On Wed, 20 Mar 2024 at 23:42, Malte Ott <malte.ott at maralorn.de> wrote:
>
>> Okay, let me summarize the voiced opinions:
>>
>> We have agreement on the change to multiplicities.
>>
>> On the infix type operator we are a bit stuck:
>>
>> * Richard, Eric and I are in favor of fixing the bug.
>> * Adam and Arnaud are in favor of staying stable, living with the
>> exception
>> * Simon was on the fix side but switched to undecided, waiting for more
>> opinions
>> * Moritz preferred staying stable, but deferred to Simon before his switch
>>
>> Overall slightly more votes for the change but subjectively hold less
>> strongly
>> than the opinions against it.
>>
>> Since I am unclear on how to proceed I’d love to hear more opinions
>> (especially
>> of committee members who haven’t voiced theirs about this proposal).
>>
>> I am generally not a fan of enshrining historic coincidence in the
>> language when
>> the cost of fixing it is bareable. On the other hand this is such a minor
>> detail
>> that I don’t think it will matter much in either direction.
>>
>> If we cannot come to a consensus soon I will put it a to a vote. We
>> shouldn’t spend too much time on this.
>>
>> Best
>> Malte
>>
>> On 2024-03-19 15:12, Arnaud Spiwack wrote:
>> > On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <
>> > simon.peytonjones at gmail.com> wrote:
>> >
>> > > But I think you are now saying that *even if a left-to-right order was
>> > > "best", *there is a long-standing bug in GHC that puts `b` first in (a
>> > > `b` c`), and it's not worth the risk of change.   So instead we should
>> > > institutionalise the bug into the spec.
>> > >
>> >
>> > This is, at least, my position. This is a bug fix, but the bug is so
>> tiny,
>> > that even if the breakage is rare, it's not necessarily worth it, and it
>> > may be better to bake the exception into the spec. I'm weakly on the
>> side
>> > that baking the exception is better.
>>
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> 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/20240321/967fe428/attachment.html>

From arnaud.spiwack at tweag.io  Fri Mar 22 07:58:47 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 22 Mar 2024 08:58:47 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
References: <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
Message-ID: <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>

@Malte, in my opinion, with the extension on, types which are not covered
by the type class should error out.

I'd like to have some more understanding of what's feasible to implement.
Adam, Simon PJ, could you share some insight there?

On Thu, 21 Mar 2024 at 00:19, Malte Ott <malte.ott at maralorn.de> wrote:

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

From arnaud.spiwack at tweag.io  Fri Mar 22 08:08:55 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 22 Mar 2024 09:08:55 +0100
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
Message-ID: <CAGwnsnk0R3-p3syH9wT7SRpSsmhPqfmKZ0ViMiGAYK0iAC1tcA@mail.gmail.com>

> I think we should thus encourage them.  Because that greatly increases
the chances that if the module compiles with GHC(X) then it'll compile with
GHC(X+k).

Very much so, in my opinion. In libraries, and other code that must remain
stable.

> If they do this, then the "default language edition" barely matters.

I'd say defaults always matter a lot. They communicate what we consider to
be normal. I've expressed before that I believe it's crucially important
that “normal Haskell” be equated with the latest edition (this is a hill
I'm willing to die on). If the default is anything else, we're
communicating the wrong thing, creating confusion.

Now there are several levels of defaults: what Cabal and Stack chooses as
default for `cabal init`/`stack new`. This we don't have control over
(except maybe frowning and looking very cross at the authors). I still
believe it should point to the latest edition.

Then there's the default when running GHC. This mostly only matter when not
building via Cabal. Which, in my experience, is only for throwaway script
(tiny experiment, very often with ghci). There I also want to use normal
Haskell. And, just as importantly, I want the bells and the whistles of
recent developments. Stability isn't a concern, I just want to  get started
efficiently.

On Thu, 21 Mar 2024 at 11:08, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> It's hard to answer this without addressing the following question
>
>    - Do we want to actively encourage Haskell users to specify a language
>    edition for every module (via a LANGUAGE pragma, cabal file, or command
>    line option)?
>
> I think we should thus encourage them.  Because that greatly increases the
> chances that if the module compiles with GHC(X) then it'll compile with
> GHC(X+k).
>
> If they do this, then the "default language edition" barely matters.
>
> Indeed, I want to question the merit of having a "default language
> edition" at all.  Suppose the default language edition was GHC2021
> forever.  All by itself that would encourage the use of an explicit
> language edition, to get hold a coherent bundle of extensions beyond
> GHC2021.  We might not need to do any more than that.
>
> Simon
>
>
>
> On Thu, 21 Mar 2024 at 09:08, Adam Gundry <adam at well-typed.com> wrote:
>
>> Apologies for letting this thread linger.
>>
>> The current de facto situation is that GHC 9.10 will ship with GHC2024
>> available but not enabled by default. (Given the timing, it did not seem
>> feasible to change the default, and but leaving GHC2024 out of the
>> release entirely would seem unnecessary.)
>>
>> Several people have expressed the opinion that we should actively plan
>> to switch the default, to benefit one-off use (especially in ghci),
>> rather than simply leaving GHC2021 as the default indefinitely. So the
>> question is what level of messaging is appropriate before that happens.
>> I can see a few options, none of which are entirely satisfying:
>>
>>   * Mention in the release notes (done for 9.10, and easily done in the
>> next release).
>>
>>   * Add an off-by-default warning about failure to specify a language
>> edition (maybe in -Wall or -Wcompat). Unclear this benefits many people
>> because if they aren't specifying a language edition or reading the
>> release notes, they may well not be enabling non-default warnings either.
>>
>>   * Enable the warning about failure to specify a language edition by
>> default. A bit noisy for ad hoc use.
>>
>>   * Add a warning where NoMonoLocalBinds is used and changing to
>> MonoLocalBinds would break the program (since this is the most likely
>> source of breakage in practice). This warning could be enabled by
>> default if no language edition is specified. Nice for users, but
>> probably quite a bit of implementation overhead, so unclear if it would
>> be implemented.
>>
>>   * Wait for a super-major release (e.g. the 10.x series) before
>> changing the default language. Not clear when this will be.
>>
>> Any other options? Opinions?
>>
>> Adam
>>
>>
>> On 19/02/2024 21:34, Eric Seidel wrote:
>> > It seems to me that this particular proposal could make sense
>> > tactically, but I agree with Chris and Arnaud that it feels
>> > like the wrong thing strategically.
>> >
>> > I don't see us getting away from a notion of a "default language".
>> > GCC/Clang similarly implement many C/C++ standards and let users
>> > choose, but still define a default standard per compiler version.
>> > And this default changes across compiler releases. Forcing even
>> > adhoc ghc[i] sessions to specify a language standard feels
>> > excessive.
>> >
>> > Thus, we need *some* cadence for updating the default language.
>> > It could be that GHC 9.10 is too soon to make that change, but
>> > we should commit to making the change at some point, with proper
>> > messaging.
>> >
>> > Eric
>> >
>> > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:
>> >> Thanks everyone for sharing your thoughts.
>> >>
>> >> I would point out that this is not just about "the handful of people
>> >> that have ghci scripts" but rather anyone compiling modules with ghc
>> >> directly (not using Cabal). Were it about ghci alone, I agree that the
>> >> latest language edition would be preferable. But it seems likely to be
>> a
>> >> larger class, e.g. including educators teaching Haskell, and users with
>> >> small programs where they have not created a Cabal package.
>> >>
>> >> Adam
>> >>
>> >>
>> >> On 16/02/2024 08:36, Arnaud Spiwack wrote:
>> >>> (I won't be able to follow this conversation as I'll be on holiday for
>> >>> the next week so dropping my thoughts a little unstructured)
>> >>>
>> >>> I'm not keen on giving people gratuitous work. I think staging making
>> >>> GHC2024 the default borders on gratuitous work (because I'm not
>> >>> convinced that the transition period will achieve anything, but on the
>> >>> other hand, it gives us a little bit of time to warn people). The idea
>> >>> that we will want to make a decision for each edition in the future
>> >>> regarding whether it's to be the default is definitely gratuitous work
>> >>> (I can be convinced otherwise, of course: this is my current train of
>> >>> thoughts).
>> >>> Generally speaking, all cabal projects have a fixed `default-language`
>> >>> (which, we learnt, is Haskell98 if omitted). So really we're doing
>> this
>> >>> for the handful of people that have ghci scripts. And we're making
>> >>> everybody else's life worse (because ghci is worse). I'm, obviously, a
>> >>> strong believer in the power of defaults.
>> >>>
>> >>> So, anyway, without having had much time to think about this: maybe ok
>> >>> for staging GHC2024 in particular, just this once. I think it's a bad
>> >>> idea, but not a hill I'll die on. The rest of the proposal I'm rather
>> >>> opposed to.
>> >>>
>> >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan <chris at chrisdornan.com
>> >>> <mailto:chris at chrisdornan.com>> wrote:
>> >>>
>> >>>      Sorry, I misunderstood the proposal — for some reason I thought
>> we
>> >>>      were going to delay the default for ghci.
>> >>>
>> >>>      If we think the new language is going to be particularly
>> disruptive
>> >>>      then we might want a transition period where it is available
>> before
>> >>>      making it the default — I really have no objection to this at
>> all in
>> >>>      general.
>> >>>
>> >>>      I will just suggest that we might want to enable these defaults
>> >>>      quite aggressively — and I say this having been bitten by GHC2021
>> >>>      myself. We are committed to breaking stuff — is there much to be
>> >>>      gained by delaying. Is it not going to delay take-up? It makes
>> the
>> >>>      whole process more complicated.
>> >>>
>> >>>      Chris
>> >>>
>> >>>
>> >>>>      On 15 Feb 2024, at 16:08, Simon Peyton Jones
>> >>>>      <simon.peytonjones at gmail.com <mailto:
>> simon.peytonjones at gmail.com>>
>> >>>>      wrote:
>> >>>>
>> >>>>      I'm not understanding  your point, Chris.
>> >>>>
>> >>>>      I think we are planning to increasingly encourage people to
>> >>>>      specify an explicit language edition for everything.  (Indeed
>> >>>>      there is discussion of an on-by-default warning that complains
>> if
>> >>>>      you don't.)  For these users, the "default language edition" is
>> >>>>      irrelevant.
>> >>>>
>> >>>>      So the only issue is people who don't specify a language edition
>> >>>>      at all.   Changing the default language edition risks breaking
>> >>>>      their code.  Why would we do that? What compelling reason is
>> there
>> >>>>      for breaking code that we don't have to break?
>> >>>>
>> >>>>      For the short term,
>> >>>>
>> >>>>        * GHC2024 is particularly likely to break code
>> >>>>        * We have not yet educated our users to use explicit language
>> >>>>          editions
>> >>>>
>> >>>>      So making GHC2024 be the default language for GHC 9.10 seems (to
>> >>>>      me) to lead to entirely-unnecessary breakage, with no compelling
>> >>>>      reason to do so.
>> >>>>
>> >>>>      Simon
>> >>>>
>> >>>>      On Thu, 15 Feb 2024 at 13:21, Chris Dornan <
>> chris at chrisdornan.com
>> >>>>      <mailto:chris at chrisdornan.com>> wrote:
>> >>>>
>> >>>>          I have been a strongly in favour of minimising surprises
>> but I
>> >>>>          mildly resistant to this proposal.
>> >>>>
>> >>>>          After GHC2021 broke my code quite severly (though PolyKinds)
>> >>>>          there was an initial adjustment phase but I quickly got used
>> >>>>          to specifying the exact language I want to use everywhere.
>> >>>>          Indeed the propensity for GHCi to pick up the new breakage
>> >>>>          caused some surprises but I quickly adjusted when I realised
>> >>>>          what was going on.
>> >>>>
>> >>>>          The point is not that change is bad but change that is
>> >>>>          difficult to anticipate and control is bad.
>> >>>>
>> >>>>          I now see the GHC adoption of the new default languages,
>> that
>> >>>>          can very selectively break things when needed, as a
>> fantastic
>> >>>>          development. It allows us to roll out changes in a very
>> >>>>          controlled way where at synchronisation points that are easy
>> >>>>          to understand and where developers retain control. This
>> >>>>          strikes me as a really great sweet spot for Haskell.
>> >>>>
>> >>>>          If we make this scheme more complicated by making some the
>> >>>>          tools adopt languages on different schedules then it risks
>> >>>>          creating confusion. Folks that want to tie down advanced
>> >>>>          features strike me as just the kind that should find it easy
>> >>>>          to fill out the appropriate settings in configuration files.
>> >>>>
>> >>>>          So I say lets get this rolled out ASAP (as Adam says) but
>> roll
>> >>>>          it out consistently everywhere.
>> >>>>
>> >>>>          Chris
>> >>>>
>> >>>>
>> >>>>>          On 15 Feb 2024, at 09:15, Simon Peyton Jones
>> >>>>>          <simon.peytonjones at gmail.com
>> >>>>>          <mailto:simon.peytonjones at gmail.com>> wrote:
>> >>>>>
>> >>>>>          I'm ok with this proposal.  The whole concept of a default
>> >>>>>          language seems a bit flaky to me, if we are going to start
>> >>>>>          warning any time someone doesn't explicitly specify an
>> >>>>>          explicit addition.  While this is settling down, causing
>> >>>>>          minimum disruption is good.
>> >>>>>
>> >>>>>          Simon
>> >>>>>
>> >>>>>          On Thu, 15 Feb 2024 at 08:50, Adam Gundry
>> >>>>>          <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>> >>>>>
>> >>>>>              Dear committee,
>> >>>>>
>> >>>>>              In #632, I propose amending the GHC2024 proposal to
>> >>>>>              specify that the
>> >>>>>              default language used by ghc/ghci when run directly
>> will
>> >>>>>              remain GHC2021
>> >>>>>              for now, since changing to GHC2024 is not backwards
>> >>>>>              compatible. (This
>> >>>>>              does not affect Cabal packages either way, since Cabal
>> >>>>>              specifies its own
>> >>>>>              default.)
>> >>>>>
>> >>>>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/632
>> >>>>>              <
>> https://github.com/ghc-proposals/ghc-proposals/pull/632>
>> >>>>>
>> >>>>>
>> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>> <
>> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>> >
>> >>>>>
>> >>>>>              On the discussion thread, some people expressed a
>> >>>>>              preference that GHC
>> >>>>>              should default to the latest language edition anyway.
>> >>>>>              There is also
>> >>>>>              Richard's suggestion of wider changes of approach in
>> >>>>>              #636. However,
>> >>>>>              given that the GHC 9.10 fork date is fast approaching,
>> >>>>>              introducing
>> >>>>>              GHC2024 but not making it the default seems like the
>> best
>> >>>>>              short-term
>> >>>>>              solution to me. We can always reassess our approach to
>> >>>>>              this for future
>> >>>>>              releases as part of the wider discussion.
>> >>>>>
>> >>>>>              If you object to the proposed approach, please speak up
>> >>>>>              ASAP. Otherwise
>> >>>>>              I plan to merge in a week or so.
>> >>>>>
>> >>>>>              Cheers,
>> >>>>>
>> >>>>>              Adam
>> >>
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240322/c6fb286f/attachment-0001.html>

From adam at well-typed.com  Fri Mar 22 08:20:42 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 22 Mar 2024 08:20:42 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
Message-ID: <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>

On 21/03/2024 10:08, Simon Peyton Jones wrote:
> It's hard to answer this without addressing the following question
> 
>   * Do we want to actively encourage Haskell users to specify a language
>     edition for every module (via a LANGUAGE pragma, cabal file, or
>     command line option)?
> 
> I think we should thus encourage them. Because that greatly increases 
> the chances that if the module compiles with GHC(X) then it'll compile 
> with GHC(X+k).

We certainly should encourage them to specify a language edition for 
every module that will last for any length of time. But that still 
leaves quick one-off uses, either just firing up ghci, or writing a 
throwaway module. And there it's less obvious how active our 
encouragement should be.


> If they do this, then the "default language edition" barely matters.
> 
> Indeed, I want to question the merit of having a "default language 
> edition" at all.  Suppose the default language edition was GHC2021 
> forever.  All by itself that would encourage the use of an explicit 
> language edition, to get hold a coherent bundle of extensions beyond 
> GHC2021.  We might not need to do any more than that.

The downside of this is that simply typing "ghci" will give the user a 
suboptimal experience (at least if we assume that future GHC20xx 
revisions will be better than GHC2021). So we potentially end up in a 
situation where expert users have learned to use "ghci -XGHC2035" but 
beginners use "ghci" and encounter unexpected papercuts.

In the extremely long term, perhaps we won't want to support GHC2021 
forever, but if we don't have a story about evolving the default 
language, we are stuck. I think we are better off having a clearly 
identified default language per compiler version, but making users aware 
of when they are relying on that default.

Side thought: maybe "ghci" should print the language edition in use as 
part of the initial prompt, at least where the default was not overridden?

Adam


> On Thu, 21 Mar 2024 at 09:08, Adam Gundry <adam at well-typed.com 
> <mailto:adam at well-typed.com>> wrote:
> 
>     Apologies for letting this thread linger.
> 
>     The current de facto situation is that GHC 9.10 will ship with GHC2024
>     available but not enabled by default. (Given the timing, it did not
>     seem
>     feasible to change the default, and but leaving GHC2024 out of the
>     release entirely would seem unnecessary.)
> 
>     Several people have expressed the opinion that we should actively plan
>     to switch the default, to benefit one-off use (especially in ghci),
>     rather than simply leaving GHC2021 as the default indefinitely. So the
>     question is what level of messaging is appropriate before that happens.
>     I can see a few options, none of which are entirely satisfying:
> 
>        * Mention in the release notes (done for 9.10, and easily done in
>     the
>     next release).
> 
>        * Add an off-by-default warning about failure to specify a language
>     edition (maybe in -Wall or -Wcompat). Unclear this benefits many people
>     because if they aren't specifying a language edition or reading the
>     release notes, they may well not be enabling non-default warnings
>     either.
> 
>        * Enable the warning about failure to specify a language edition by
>     default. A bit noisy for ad hoc use.
> 
>        * Add a warning where NoMonoLocalBinds is used and changing to
>     MonoLocalBinds would break the program (since this is the most likely
>     source of breakage in practice). This warning could be enabled by
>     default if no language edition is specified. Nice for users, but
>     probably quite a bit of implementation overhead, so unclear if it would
>     be implemented.
> 
>        * Wait for a super-major release (e.g. the 10.x series) before
>     changing the default language. Not clear when this will be.
> 
>     Any other options? Opinions?
> 
>     Adam
> 
> 
>     On 19/02/2024 21:34, Eric Seidel wrote:
>      > It seems to me that this particular proposal could make sense
>      > tactically, but I agree with Chris and Arnaud that it feels
>      > like the wrong thing strategically.
>      >
>      > I don't see us getting away from a notion of a "default language".
>      > GCC/Clang similarly implement many C/C++ standards and let users
>      > choose, but still define a default standard per compiler version.
>      > And this default changes across compiler releases. Forcing even
>      > adhoc ghc[i] sessions to specify a language standard feels
>      > excessive.
>      >
>      > Thus, we need *some* cadence for updating the default language.
>      > It could be that GHC 9.10 is too soon to make that change, but
>      > we should commit to making the change at some point, with proper
>      > messaging.
>      >
>      > Eric
>      >
>      > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:
>      >> Thanks everyone for sharing your thoughts.
>      >>
>      >> I would point out that this is not just about "the handful of people
>      >> that have ghci scripts" but rather anyone compiling modules with ghc
>      >> directly (not using Cabal). Were it about ghci alone, I agree
>     that the
>      >> latest language edition would be preferable. But it seems likely
>     to be a
>      >> larger class, e.g. including educators teaching Haskell, and
>     users with
>      >> small programs where they have not created a Cabal package.
>      >>
>      >> Adam
>      >>
>      >>
>      >> On 16/02/2024 08:36, Arnaud Spiwack wrote:
>      >>> (I won't be able to follow this conversation as I'll be on
>     holiday for
>      >>> the next week so dropping my thoughts a little unstructured)
>      >>>
>      >>> I'm not keen on giving people gratuitous work. I think staging
>     making
>      >>> GHC2024 the default borders on gratuitous work (because I'm not
>      >>> convinced that the transition period will achieve anything, but
>     on the
>      >>> other hand, it gives us a little bit of time to warn people).
>     The idea
>      >>> that we will want to make a decision for each edition in the future
>      >>> regarding whether it's to be the default is definitely
>     gratuitous work
>      >>> (I can be convinced otherwise, of course: this is my current
>     train of
>      >>> thoughts).
>      >>> Generally speaking, all cabal projects have a fixed
>     `default-language`
>      >>> (which, we learnt, is Haskell98 if omitted). So really we're
>     doing this
>      >>> for the handful of people that have ghci scripts. And we're making
>      >>> everybody else's life worse (because ghci is worse). I'm,
>     obviously, a
>      >>> strong believer in the power of defaults.
>      >>>
>      >>> So, anyway, without having had much time to think about this:
>     maybe ok
>      >>> for staging GHC2024 in particular, just this once. I think it's
>     a bad
>      >>> idea, but not a hill I'll die on. The rest of the proposal I'm
>     rather
>      >>> opposed to.
>      >>>
>      >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan
>     <chris at chrisdornan.com <mailto:chris at chrisdornan.com>
>      >>> <mailto:chris at chrisdornan.com <mailto:chris at chrisdornan.com>>>
>     wrote:
>      >>>
>      >>>      Sorry, I misunderstood the proposal — for some reason I
>     thought we
>      >>>      were going to delay the default for ghci.
>      >>>
>      >>>      If we think the new language is going to be particularly
>     disruptive
>      >>>      then we might want a transition period where it is
>     available before
>      >>>      making it the default — I really have no objection to this
>     at all in
>      >>>      general.
>      >>>
>      >>>      I will just suggest that we might want to enable these
>     defaults
>      >>>      quite aggressively — and I say this having been bitten by
>     GHC2021
>      >>>      myself. We are committed to breaking stuff — is there much
>     to be
>      >>>      gained by delaying. Is it not going to delay take-up? It
>     makes the
>      >>>      whole process more complicated.
>      >>>
>      >>>      Chris
>      >>>
>      >>>
>      >>>>      On 15 Feb 2024, at 16:08, Simon Peyton Jones
>      >>>>      <simon.peytonjones at gmail.com
>     <mailto:simon.peytonjones at gmail.com>
>     <mailto:simon.peytonjones at gmail.com
>     <mailto:simon.peytonjones at gmail.com>>>
>      >>>>      wrote:
>      >>>>
>      >>>>      I'm not understanding  your point, Chris.
>      >>>>
>      >>>>      I think we are planning to increasingly encourage people to
>      >>>>      specify an explicit language edition for everything.  (Indeed
>      >>>>      there is discussion of an on-by-default warning that
>     complains if
>      >>>>      you don't.)  For these users, the "default language
>     edition" is
>      >>>>      irrelevant.
>      >>>>
>      >>>>      So the only issue is people who don't specify a language
>     edition
>      >>>>      at all.   Changing the default language edition risks
>     breaking
>      >>>>      their code.  Why would we do that? What compelling reason
>     is there
>      >>>>      for breaking code that we don't have to break?
>      >>>>
>      >>>>      For the short term,
>      >>>>
>      >>>>        * GHC2024 is particularly likely to break code
>      >>>>        * We have not yet educated our users to use explicit
>     language
>      >>>>          editions
>      >>>>
>      >>>>      So making GHC2024 be the default language for GHC 9.10
>     seems (to
>      >>>>      me) to lead to entirely-unnecessary breakage, with no
>     compelling
>      >>>>      reason to do so.
>      >>>>
>      >>>>      Simon
>      >>>>
>      >>>>      On Thu, 15 Feb 2024 at 13:21, Chris Dornan
>     <chris at chrisdornan.com <mailto:chris at chrisdornan.com>
>      >>>>      <mailto:chris at chrisdornan.com
>     <mailto:chris at chrisdornan.com>>> wrote:
>      >>>>
>      >>>>          I have been a strongly in favour of minimising
>     surprises but I
>      >>>>          mildly resistant to this proposal.
>      >>>>
>      >>>>          After GHC2021 broke my code quite severly (though
>     PolyKinds)
>      >>>>          there was an initial adjustment phase but I quickly
>     got used
>      >>>>          to specifying the exact language I want to use
>     everywhere.
>      >>>>          Indeed the propensity for GHCi to pick up the new
>     breakage
>      >>>>          caused some surprises but I quickly adjusted when I
>     realised
>      >>>>          what was going on.
>      >>>>
>      >>>>          The point is not that change is bad but change that is
>      >>>>          difficult to anticipate and control is bad.
>      >>>>
>      >>>>          I now see the GHC adoption of the new default
>     languages, that
>      >>>>          can very selectively break things when needed, as a
>     fantastic
>      >>>>          development. It allows us to roll out changes in a very
>      >>>>          controlled way where at synchronisation points that
>     are easy
>      >>>>          to understand and where developers retain control. This
>      >>>>          strikes me as a really great sweet spot for Haskell.
>      >>>>
>      >>>>          If we make this scheme more complicated by making
>     some the
>      >>>>          tools adopt languages on different schedules then it
>     risks
>      >>>>          creating confusion. Folks that want to tie down advanced
>      >>>>          features strike me as just the kind that should find
>     it easy
>      >>>>          to fill out the appropriate settings in configuration
>     files.
>      >>>>
>      >>>>          So I say lets get this rolled out ASAP (as Adam says)
>     but roll
>      >>>>          it out consistently everywhere.
>      >>>>
>      >>>>          Chris
>      >>>>
>      >>>>
>      >>>>>          On 15 Feb 2024, at 09:15, Simon Peyton Jones
>      >>>>>          <simon.peytonjones at gmail.com
>     <mailto:simon.peytonjones at gmail.com>
>      >>>>>          <mailto:simon.peytonjones at gmail.com
>     <mailto:simon.peytonjones at gmail.com>>> wrote:
>      >>>>>
>      >>>>>          I'm ok with this proposal.  The whole concept of a
>     default
>      >>>>>          language seems a bit flaky to me, if we are going to
>     start
>      >>>>>          warning any time someone doesn't explicitly specify an
>      >>>>>          explicit addition.  While this is settling down, causing
>      >>>>>          minimum disruption is good.
>      >>>>>
>      >>>>>          Simon
>      >>>>>
>      >>>>>          On Thu, 15 Feb 2024 at 08:50, Adam Gundry
>      >>>>>          <adam at well-typed.com <mailto:adam at well-typed.com>
>     <mailto:adam at well-typed.com <mailto:adam at well-typed.com>>> wrote:
>      >>>>>
>      >>>>>              Dear committee,
>      >>>>>
>      >>>>>              In #632, I propose amending the GHC2024 proposal to
>      >>>>>              specify that the
>      >>>>>              default language used by ghc/ghci when run
>     directly will
>      >>>>>              remain GHC2021
>      >>>>>              for now, since changing to GHC2024 is not backwards
>      >>>>>              compatible. (This
>      >>>>>              does not affect Cabal packages either way, since
>     Cabal
>      >>>>>              specifies its own
>      >>>>>              default.)
>      >>>>>
>      >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/632
>     <https://github.com/ghc-proposals/ghc-proposals/pull/632>
>      >>>>>             
>     <https://github.com/ghc-proposals/ghc-proposals/pull/632
>     <https://github.com/ghc-proposals/ghc-proposals/pull/632>>
>      >>>>>
>      >>>>>
>     https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024 <https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024> <https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024 <https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024>>
>      >>>>>
>      >>>>>              On the discussion thread, some people expressed a
>      >>>>>              preference that GHC
>      >>>>>              should default to the latest language edition
>     anyway.
>      >>>>>              There is also
>      >>>>>              Richard's suggestion of wider changes of approach in
>      >>>>>              #636. However,
>      >>>>>              given that the GHC 9.10 fork date is fast
>     approaching,
>      >>>>>              introducing
>      >>>>>              GHC2024 but not making it the default seems like
>     the best
>      >>>>>              short-term
>      >>>>>              solution to me. We can always reassess our
>     approach to
>      >>>>>              this for future
>      >>>>>              releases as part of the wider discussion.
>      >>>>>
>      >>>>>              If you object to the proposed approach, please
>     speak up
>      >>>>>              ASAP. Otherwise
>      >>>>>              I plan to merge in a week or so.
>      >>>>>
>      >>>>>              Cheers,
>      >>>>>
>      >>>>>              Adam
>      >>
> 

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From arnaud.spiwack at tweag.io  Fri Mar 22 08:12:49 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 22 Mar 2024 09:12:49 +0100
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
Message-ID: <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>

Simon,

Do you worry about the implementation because of future maintenance costs?
Or because of the immediate cost of developing the feature?

As far as I can see, there aren't other objections to this design besides
the cost, right? There's no real possibility of an alternate, conflicting
design for data type arguments, is there?

On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear Steering Committee
>
> Vlad proposes to amend proposal #425
> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
> permit more wildcard binder forms in type declarations:
>   https://github.com/ghc-proposals/ghc-proposals/pull/641
>
> You may find it easiest to look at the rich diff
> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
> .
>
> This is a pretty small generalisation which would allow
>
> data T (( (a :: k1) :: k2)) = ...
>
> in which the binder has multiple kind signatures and redundant parens.
> The change is *not driven by user need*, but rather solely by *uniformity*:
> these same forms are permitted in function definitions:
>
> f :: forall (a :: k). blah
> f @(((a::k1)::k2))) = ...
>
> is permitted.
>
> It imposes a change on Template Haskell syntax too.
>
> The implementation becomes a bit more complicated; more recursive data
> types, etc.  Nothing hard, but more.
>
> It's not a big deal either way.  Very few people expressed a view on
> GitHub.  My personal view is that the modest (albeit non-zero) gain does
> not justify the definite (albeit modest) pain. I would leave this until
> someone actually wants it.
>
> Vlad argues for future-proofing, but my experience is that an eye to the
> future is sensible when you are making changes anyway; but making unforced
> changes solely for the future risks incurring pain now that, when the
> future comes, turns out to have been a poor investment.  We may have
> correctly anticipated, or we may not.
>
> So my recommendation is to park this until we get a real user demand.
>
> It's a perfectly sensible proposal, but adopting it is a judgement call.
> I'll leave a week for committee responses, and then we can just vote.
>
> Simon
>
> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear Committee,
>>
>> Vlad proposes to amend proposal #425 to permit more wildcard binder
>> forms in type declarations:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>>
>> I'd like to nominate Simon PJ as the shepherd.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Cheers,
>>
>> Adam
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240322/d2f763d4/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Mar 22 08:53:14 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Mar 2024 08:53:14 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
Message-ID: <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>

>
> Do you worry about the implementation because of future maintenance costs?
> Or because of the immediate cost of developing the feature?


Mostly the former.  It's just a bit more un-forced complexity.

As far as I can see, there aren't other objections to this design besides
> the cost, right? There's no real possibility of an alternate, conflicting
> design for data type arguments, is there?
>

It's just Occam's razor.   No one is asking for this.  And I'm unconvinced
by "future proofiing" because it's hard to correctly anticipate the future.

Simon

On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Simon,
>
> Do you worry about the implementation because of future maintenance costs?
> Or because of the immediate cost of developing the feature?
>
> As far as I can see, there aren't other objections to this design besides
> the cost, right? There's no real possibility of an alternate, conflicting
> design for data type arguments, is there?
>
> On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear Steering Committee
>>
>> Vlad proposes to amend proposal #425
>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
>> permit more wildcard binder forms in type declarations:
>>   https://github.com/ghc-proposals/ghc-proposals/pull/641
>>
>> You may find it easiest to look at the rich diff
>> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
>> .
>>
>> This is a pretty small generalisation which would allow
>>
>> data T (( (a :: k1) :: k2)) = ...
>>
>> in which the binder has multiple kind signatures and redundant parens.
>> The change is *not driven by user need*, but rather solely by
>> *uniformity*: these same forms are permitted in function definitions:
>>
>> f :: forall (a :: k). blah
>> f @(((a::k1)::k2))) = ...
>>
>> is permitted.
>>
>> It imposes a change on Template Haskell syntax too.
>>
>> The implementation becomes a bit more complicated; more recursive data
>> types, etc.  Nothing hard, but more.
>>
>> It's not a big deal either way.  Very few people expressed a view on
>> GitHub.  My personal view is that the modest (albeit non-zero) gain does
>> not justify the definite (albeit modest) pain. I would leave this until
>> someone actually wants it.
>>
>> Vlad argues for future-proofing, but my experience is that an eye to the
>> future is sensible when you are making changes anyway; but making unforced
>> changes solely for the future risks incurring pain now that, when the
>> future comes, turns out to have been a poor investment.  We may have
>> correctly anticipated, or we may not.
>>
>> So my recommendation is to park this until we get a real user demand.
>>
>> It's a perfectly sensible proposal, but adopting it is a judgement call.
>> I'll leave a week for committee responses, and then we can just vote.
>>
>> Simon
>>
>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> Dear Committee,
>>>
>>> Vlad proposes to amend proposal #425 to permit more wildcard binder
>>> forms in type declarations:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>>>
>>> I'd like to nominate Simon PJ as the shepherd.
>>>
>>> Please guide us to a conclusion as outlined in
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>
>>> Cheers,
>>>
>>> Adam
>>>
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> 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/20240322/28a221ea/attachment.html>

From simon.peytonjones at gmail.com  Fri Mar 22 09:02:49 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Mar 2024 09:02:49 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
 <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
Message-ID: <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>

OK, well it clarifies the conversation if the question of a "default
language edition" is basically just "what you get if you type 'ghci'".
(The expectation being that every Foo.hs file will, one way or another,
have an explicitly-specified language edition, so that it continues to work
into the future.)

Very well: perhaps

   - The GHCi REPL does the latest stable language edition (and could as
   you say even put that in the prompt)
   - All other uses of GHC (compiling a Foo.hs module) expect an
   explicitly-specified language edition, but use GHC2021 (or even Haskell
   98!), and emit a warning to say so, if there none.  Essentially we'd be
   encouraging users to start every Foo.hs with {-# LANGUAGE GHC2024 #-},
   which makes the file admirably self-describing.


I'm playing devil's advocate a bit here.  But I used to think that having a
default language edition was obvious, but I have come to realize that it
isn't.

Simon


On Fri, 22 Mar 2024 at 08:20, Adam Gundry <adam at well-typed.com> wrote:

> On 21/03/2024 10:08, Simon Peyton Jones wrote:
> > It's hard to answer this without addressing the following question
> >
> >   * Do we want to actively encourage Haskell users to specify a language
> >     edition for every module (via a LANGUAGE pragma, cabal file, or
> >     command line option)?
> >
> > I think we should thus encourage them. Because that greatly increases
> > the chances that if the module compiles with GHC(X) then it'll compile
> > with GHC(X+k).
>
> We certainly should encourage them to specify a language edition for
> every module that will last for any length of time. But that still
> leaves quick one-off uses, either just firing up ghci, or writing a
> throwaway module. And there it's less obvious how active our
> encouragement should be.
>
>
> > If they do this, then the "default language edition" barely matters.
> >
> > Indeed, I want to question the merit of having a "default language
> > edition" at all.  Suppose the default language edition was GHC2021
> > forever.  All by itself that would encourage the use of an explicit
> > language edition, to get hold a coherent bundle of extensions beyond
> > GHC2021.  We might not need to do any more than that.
>
> The downside of this is that simply typing "ghci" will give the user a
> suboptimal experience (at least if we assume that future GHC20xx
> revisions will be better than GHC2021). So we potentially end up in a
> situation where expert users have learned to use "ghci -XGHC2035" but
> beginners use "ghci" and encounter unexpected papercuts.
>
> In the extremely long term, perhaps we won't want to support GHC2021
> forever, but if we don't have a story about evolving the default
> language, we are stuck. I think we are better off having a clearly
> identified default language per compiler version, but making users aware
> of when they are relying on that default.
>
> Side thought: maybe "ghci" should print the language edition in use as
> part of the initial prompt, at least where the default was not overridden?
>
> Adam
>
>
> > On Thu, 21 Mar 2024 at 09:08, Adam Gundry <adam at well-typed.com
> > <mailto:adam at well-typed.com>> wrote:
> >
> >     Apologies for letting this thread linger.
> >
> >     The current de facto situation is that GHC 9.10 will ship with
> GHC2024
> >     available but not enabled by default. (Given the timing, it did not
> >     seem
> >     feasible to change the default, and but leaving GHC2024 out of the
> >     release entirely would seem unnecessary.)
> >
> >     Several people have expressed the opinion that we should actively
> plan
> >     to switch the default, to benefit one-off use (especially in ghci),
> >     rather than simply leaving GHC2021 as the default indefinitely. So
> the
> >     question is what level of messaging is appropriate before that
> happens.
> >     I can see a few options, none of which are entirely satisfying:
> >
> >        * Mention in the release notes (done for 9.10, and easily done in
> >     the
> >     next release).
> >
> >        * Add an off-by-default warning about failure to specify a
> language
> >     edition (maybe in -Wall or -Wcompat). Unclear this benefits many
> people
> >     because if they aren't specifying a language edition or reading the
> >     release notes, they may well not be enabling non-default warnings
> >     either.
> >
> >        * Enable the warning about failure to specify a language edition
> by
> >     default. A bit noisy for ad hoc use.
> >
> >        * Add a warning where NoMonoLocalBinds is used and changing to
> >     MonoLocalBinds would break the program (since this is the most likely
> >     source of breakage in practice). This warning could be enabled by
> >     default if no language edition is specified. Nice for users, but
> >     probably quite a bit of implementation overhead, so unclear if it
> would
> >     be implemented.
> >
> >        * Wait for a super-major release (e.g. the 10.x series) before
> >     changing the default language. Not clear when this will be.
> >
> >     Any other options? Opinions?
> >
> >     Adam
> >
> >
> >     On 19/02/2024 21:34, Eric Seidel wrote:
> >      > It seems to me that this particular proposal could make sense
> >      > tactically, but I agree with Chris and Arnaud that it feels
> >      > like the wrong thing strategically.
> >      >
> >      > I don't see us getting away from a notion of a "default language".
> >      > GCC/Clang similarly implement many C/C++ standards and let users
> >      > choose, but still define a default standard per compiler version.
> >      > And this default changes across compiler releases. Forcing even
> >      > adhoc ghc[i] sessions to specify a language standard feels
> >      > excessive.
> >      >
> >      > Thus, we need *some* cadence for updating the default language.
> >      > It could be that GHC 9.10 is too soon to make that change, but
> >      > we should commit to making the change at some point, with proper
> >      > messaging.
> >      >
> >      > Eric
> >      >
> >      > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:
> >      >> Thanks everyone for sharing your thoughts.
> >      >>
> >      >> I would point out that this is not just about "the handful of
> people
> >      >> that have ghci scripts" but rather anyone compiling modules with
> ghc
> >      >> directly (not using Cabal). Were it about ghci alone, I agree
> >     that the
> >      >> latest language edition would be preferable. But it seems likely
> >     to be a
> >      >> larger class, e.g. including educators teaching Haskell, and
> >     users with
> >      >> small programs where they have not created a Cabal package.
> >      >>
> >      >> Adam
> >      >>
> >      >>
> >      >> On 16/02/2024 08:36, Arnaud Spiwack wrote:
> >      >>> (I won't be able to follow this conversation as I'll be on
> >     holiday for
> >      >>> the next week so dropping my thoughts a little unstructured)
> >      >>>
> >      >>> I'm not keen on giving people gratuitous work. I think staging
> >     making
> >      >>> GHC2024 the default borders on gratuitous work (because I'm not
> >      >>> convinced that the transition period will achieve anything, but
> >     on the
> >      >>> other hand, it gives us a little bit of time to warn people).
> >     The idea
> >      >>> that we will want to make a decision for each edition in the
> future
> >      >>> regarding whether it's to be the default is definitely
> >     gratuitous work
> >      >>> (I can be convinced otherwise, of course: this is my current
> >     train of
> >      >>> thoughts).
> >      >>> Generally speaking, all cabal projects have a fixed
> >     `default-language`
> >      >>> (which, we learnt, is Haskell98 if omitted). So really we're
> >     doing this
> >      >>> for the handful of people that have ghci scripts. And we're
> making
> >      >>> everybody else's life worse (because ghci is worse). I'm,
> >     obviously, a
> >      >>> strong believer in the power of defaults.
> >      >>>
> >      >>> So, anyway, without having had much time to think about this:
> >     maybe ok
> >      >>> for staging GHC2024 in particular, just this once. I think it's
> >     a bad
> >      >>> idea, but not a hill I'll die on. The rest of the proposal I'm
> >     rather
> >      >>> opposed to.
> >      >>>
> >      >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan
> >     <chris at chrisdornan.com <mailto:chris at chrisdornan.com>
> >      >>> <mailto:chris at chrisdornan.com <mailto:chris at chrisdornan.com>>>
> >     wrote:
> >      >>>
> >      >>>      Sorry, I misunderstood the proposal — for some reason I
> >     thought we
> >      >>>      were going to delay the default for ghci.
> >      >>>
> >      >>>      If we think the new language is going to be particularly
> >     disruptive
> >      >>>      then we might want a transition period where it is
> >     available before
> >      >>>      making it the default — I really have no objection to this
> >     at all in
> >      >>>      general.
> >      >>>
> >      >>>      I will just suggest that we might want to enable these
> >     defaults
> >      >>>      quite aggressively — and I say this having been bitten by
> >     GHC2021
> >      >>>      myself. We are committed to breaking stuff — is there much
> >     to be
> >      >>>      gained by delaying. Is it not going to delay take-up? It
> >     makes the
> >      >>>      whole process more complicated.
> >      >>>
> >      >>>      Chris
> >      >>>
> >      >>>
> >      >>>>      On 15 Feb 2024, at 16:08, Simon Peyton Jones
> >      >>>>      <simon.peytonjones at gmail.com
> >     <mailto:simon.peytonjones at gmail.com>
> >     <mailto:simon.peytonjones at gmail.com
> >     <mailto:simon.peytonjones at gmail.com>>>
> >      >>>>      wrote:
> >      >>>>
> >      >>>>      I'm not understanding  your point, Chris.
> >      >>>>
> >      >>>>      I think we are planning to increasingly encourage people
> to
> >      >>>>      specify an explicit language edition for everything.
> (Indeed
> >      >>>>      there is discussion of an on-by-default warning that
> >     complains if
> >      >>>>      you don't.)  For these users, the "default language
> >     edition" is
> >      >>>>      irrelevant.
> >      >>>>
> >      >>>>      So the only issue is people who don't specify a language
> >     edition
> >      >>>>      at all.   Changing the default language edition risks
> >     breaking
> >      >>>>      their code.  Why would we do that? What compelling reason
> >     is there
> >      >>>>      for breaking code that we don't have to break?
> >      >>>>
> >      >>>>      For the short term,
> >      >>>>
> >      >>>>        * GHC2024 is particularly likely to break code
> >      >>>>        * We have not yet educated our users to use explicit
> >     language
> >      >>>>          editions
> >      >>>>
> >      >>>>      So making GHC2024 be the default language for GHC 9.10
> >     seems (to
> >      >>>>      me) to lead to entirely-unnecessary breakage, with no
> >     compelling
> >      >>>>      reason to do so.
> >      >>>>
> >      >>>>      Simon
> >      >>>>
> >      >>>>      On Thu, 15 Feb 2024 at 13:21, Chris Dornan
> >     <chris at chrisdornan.com <mailto:chris at chrisdornan.com>
> >      >>>>      <mailto:chris at chrisdornan.com
> >     <mailto:chris at chrisdornan.com>>> wrote:
> >      >>>>
> >      >>>>          I have been a strongly in favour of minimising
> >     surprises but I
> >      >>>>          mildly resistant to this proposal.
> >      >>>>
> >      >>>>          After GHC2021 broke my code quite severly (though
> >     PolyKinds)
> >      >>>>          there was an initial adjustment phase but I quickly
> >     got used
> >      >>>>          to specifying the exact language I want to use
> >     everywhere.
> >      >>>>          Indeed the propensity for GHCi to pick up the new
> >     breakage
> >      >>>>          caused some surprises but I quickly adjusted when I
> >     realised
> >      >>>>          what was going on.
> >      >>>>
> >      >>>>          The point is not that change is bad but change that is
> >      >>>>          difficult to anticipate and control is bad.
> >      >>>>
> >      >>>>          I now see the GHC adoption of the new default
> >     languages, that
> >      >>>>          can very selectively break things when needed, as a
> >     fantastic
> >      >>>>          development. It allows us to roll out changes in a
> very
> >      >>>>          controlled way where at synchronisation points that
> >     are easy
> >      >>>>          to understand and where developers retain control.
> This
> >      >>>>          strikes me as a really great sweet spot for Haskell.
> >      >>>>
> >      >>>>          If we make this scheme more complicated by making
> >     some the
> >      >>>>          tools adopt languages on different schedules then it
> >     risks
> >      >>>>          creating confusion. Folks that want to tie down
> advanced
> >      >>>>          features strike me as just the kind that should find
> >     it easy
> >      >>>>          to fill out the appropriate settings in configuration
> >     files.
> >      >>>>
> >      >>>>          So I say lets get this rolled out ASAP (as Adam says)
> >     but roll
> >      >>>>          it out consistently everywhere.
> >      >>>>
> >      >>>>          Chris
> >      >>>>
> >      >>>>
> >      >>>>>          On 15 Feb 2024, at 09:15, Simon Peyton Jones
> >      >>>>>          <simon.peytonjones at gmail.com
> >     <mailto:simon.peytonjones at gmail.com>
> >      >>>>>          <mailto:simon.peytonjones at gmail.com
> >     <mailto:simon.peytonjones at gmail.com>>> wrote:
> >      >>>>>
> >      >>>>>          I'm ok with this proposal.  The whole concept of a
> >     default
> >      >>>>>          language seems a bit flaky to me, if we are going to
> >     start
> >      >>>>>          warning any time someone doesn't explicitly specify
> an
> >      >>>>>          explicit addition.  While this is settling down,
> causing
> >      >>>>>          minimum disruption is good.
> >      >>>>>
> >      >>>>>          Simon
> >      >>>>>
> >      >>>>>          On Thu, 15 Feb 2024 at 08:50, Adam Gundry
> >      >>>>>          <adam at well-typed.com <mailto:adam at well-typed.com>
> >     <mailto:adam at well-typed.com <mailto:adam at well-typed.com>>> wrote:
> >      >>>>>
> >      >>>>>              Dear committee,
> >      >>>>>
> >      >>>>>              In #632, I propose amending the GHC2024 proposal
> to
> >      >>>>>              specify that the
> >      >>>>>              default language used by ghc/ghci when run
> >     directly will
> >      >>>>>              remain GHC2021
> >      >>>>>              for now, since changing to GHC2024 is not
> backwards
> >      >>>>>              compatible. (This
> >      >>>>>              does not affect Cabal packages either way, since
> >     Cabal
> >      >>>>>              specifies its own
> >      >>>>>              default.)
> >      >>>>>
> >      >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/632
> >     <https://github.com/ghc-proposals/ghc-proposals/pull/632>
> >      >>>>>
> >     <https://github.com/ghc-proposals/ghc-proposals/pull/632
> >     <https://github.com/ghc-proposals/ghc-proposals/pull/632>>
> >      >>>>>
> >      >>>>>
> >
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> <
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024>
> <
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> <
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> >>
> >      >>>>>
> >      >>>>>              On the discussion thread, some people expressed a
> >      >>>>>              preference that GHC
> >      >>>>>              should default to the latest language edition
> >     anyway.
> >      >>>>>              There is also
> >      >>>>>              Richard's suggestion of wider changes of
> approach in
> >      >>>>>              #636. However,
> >      >>>>>              given that the GHC 9.10 fork date is fast
> >     approaching,
> >      >>>>>              introducing
> >      >>>>>              GHC2024 but not making it the default seems like
> >     the best
> >      >>>>>              short-term
> >      >>>>>              solution to me. We can always reassess our
> >     approach to
> >      >>>>>              this for future
> >      >>>>>              releases as part of the wider discussion.
> >      >>>>>
> >      >>>>>              If you object to the proposed approach, please
> >     speak up
> >      >>>>>              ASAP. Otherwise
> >      >>>>>              I plan to merge in a week or so.
> >      >>>>>
> >      >>>>>              Cheers,
> >      >>>>>
> >      >>>>>              Adam
> >      >>
> >
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240322/4abb51e8/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Mar 22 09:03:43 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Mar 2024 09:03:43 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
References: <CALkkMoRXOT=vpH4jN8nN4ra8VA=6sZ-doXLTeuPDaqYZ5L=K-g@mail.gmail.com>
 <CAJKmMz_geRL+=XqriPoQtXBg0p-156HTba=8aq1t0WL8bz=vRQ@mail.gmail.com>
 <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
Message-ID: <CAJKmMz-6CbGera5iWBfbonctvKxDLT_Q0cMEtsd6U_zb9_EOBw@mail.gmail.com>

I'd like to have some more understanding of what's feasible to implement.
Adam, Simon PJ, could you share some insight there?


I don't think any of the alternatives discussed here are hard to implement.

Simon

On Fri, 22 Mar 2024 at 07:59, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

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

From mail at joachim-breitner.de  Fri Mar 22 09:43:13 2024
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 22 Mar 2024 10:43:13 +0100
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
 <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
 <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>
Message-ID: <542dd7b3f5c076ddce5de321e475eb8f0e71a8e7.camel@joachim-breitner.de>

Hello from the sidelines,

Am Freitag, dem 22.03.2024 um 09:02 +0000 schrieb Simon Peyton Jones:
> Very well: perhaps
>  * The GHCi REPL does the latest stable language edition (and could as you say even put that in the prompt)
>  * All other uses of GHC (compiling a Foo.hs module) expect an explicitly-specified language edition, but use GHC2021 (or even Haskell 98!), and emit a warning to say so, if there none.  Essentially we'd be encouraging users to start every Foo.hs with {-# LANGUAGE GHC2024 #-}, which makes the file admirably self-describing.

That very precisely describes at least my vision ever since we started
introducing GHC20xx. Maybe with the small amendment to the second
bullet that for cabalized code, putting the edition into the .cabal
files is no less encouraged.

So if you are playing devil’s advocate by stating this, it seems this
makes me the … 😈 :-)

Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From arnaud.spiwack at tweag.io  Fri Mar 22 13:23:24 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 22 Mar 2024 14:23:24 +0100
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
 <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>
Message-ID: <CAGwnsnngDuAxqVY__i8ifL3sEdZhdA6Hq9KhC2ZFSb_kq0P4oQ@mail.gmail.com>

I'm happy to follow you on this. Especially since in the future that Vlad
hopes, where there'd be less difference between terms and types, this
particular feature may fall naturally, so it may be worth revisiting then
rather than paying the cost now.

On Fri, 22 Mar 2024 at 09:53, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Do you worry about the implementation because of future maintenance costs?
>> Or because of the immediate cost of developing the feature?
>
>
> Mostly the former.  It's just a bit more un-forced complexity.
>
> As far as I can see, there aren't other objections to this design besides
>> the cost, right? There's no real possibility of an alternate, conflicting
>> design for data type arguments, is there?
>>
>
> It's just Occam's razor.   No one is asking for this.  And I'm unconvinced
> by "future proofiing" because it's hard to correctly anticipate the future.
>
> Simon
>
> On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Simon,
>>
>> Do you worry about the implementation because of future maintenance
>> costs? Or because of the immediate cost of developing the feature?
>>
>> As far as I can see, there aren't other objections to this design besides
>> the cost, right? There's no real possibility of an alternate, conflicting
>> design for data type arguments, is there?
>>
>> On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear Steering Committee
>>>
>>> Vlad proposes to amend proposal #425
>>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
>>> permit more wildcard binder forms in type declarations:
>>>   https://github.com/ghc-proposals/ghc-proposals/pull/641
>>>
>>> You may find it easiest to look at the rich diff
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
>>> .
>>>
>>> This is a pretty small generalisation which would allow
>>>
>>> data T (( (a :: k1) :: k2)) = ...
>>>
>>> in which the binder has multiple kind signatures and redundant parens.
>>> The change is *not driven by user need*, but rather solely by
>>> *uniformity*: these same forms are permitted in function definitions:
>>>
>>> f :: forall (a :: k). blah
>>> f @(((a::k1)::k2))) = ...
>>>
>>> is permitted.
>>>
>>> It imposes a change on Template Haskell syntax too.
>>>
>>> The implementation becomes a bit more complicated; more recursive data
>>> types, etc.  Nothing hard, but more.
>>>
>>> It's not a big deal either way.  Very few people expressed a view on
>>> GitHub.  My personal view is that the modest (albeit non-zero) gain does
>>> not justify the definite (albeit modest) pain. I would leave this until
>>> someone actually wants it.
>>>
>>> Vlad argues for future-proofing, but my experience is that an eye to the
>>> future is sensible when you are making changes anyway; but making unforced
>>> changes solely for the future risks incurring pain now that, when the
>>> future comes, turns out to have been a poor investment.  We may have
>>> correctly anticipated, or we may not.
>>>
>>> So my recommendation is to park this until we get a real user demand.
>>>
>>> It's a perfectly sensible proposal, but adopting it is a judgement call.
>>> I'll leave a week for committee responses, and then we can just vote.
>>>
>>> Simon
>>>
>>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> Vlad proposes to amend proposal #425 to permit more wildcard binder
>>>> forms in type declarations:
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>>>>
>>>> I'd like to nominate Simon PJ as the shepherd.
>>>>
>>>> Please guide us to a conclusion as outlined in
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>
>>>> Cheers,
>>>>
>>>> Adam
>>>>
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240322/1f90e603/attachment.html>

From malte.ott at maralorn.de  Fri Mar 22 14:29:51 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Fri, 22 Mar 2024 15:29:51 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
Message-ID: <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>

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

From malte.ott at maralorn.de  Fri Mar 22 14:42:02 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Fri, 22 Mar 2024 15:42:02 +0100
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <542dd7b3f5c076ddce5de321e475eb8f0e71a8e7.camel@joachim-breitner.de>
References: <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
 <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
 <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>
 <542dd7b3f5c076ddce5de321e475eb8f0e71a8e7.camel@joachim-breitner.de>
Message-ID: <qjq2cfabyd4v6m47a2srivl6ovhpmd6jpb6kq5xqoyht3bcwqu@hera.m-0.eu>

I also think that the notion of default-language matters. For some reason people
care greatly about which is the "real" Haskell.

I really want ghci to use the latest and greatest language edition.
I also would prefer it to be used when calling ghc on a quick test file.
If deemed necessary we can throw a warning when we fallback to a default in
that case.

I think it is very important that we care about breakage for the sake of the
ecosystem. But the ecosystem relies on Cabal to build packages so outside of
that changes have another quality.

Best
Malte

From malte.ott at maralorn.de  Fri Mar 22 14:47:37 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Fri, 22 Mar 2024 15:47:37 +0100
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAGwnsnngDuAxqVY__i8ifL3sEdZhdA6Hq9KhC2ZFSb_kq0P4oQ@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
 <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>
 <CAGwnsnngDuAxqVY__i8ifL3sEdZhdA6Hq9KhC2ZFSb_kq0P4oQ@mail.gmail.com>
Message-ID: <kcg5tp5qxa5zfi2xlyzebwn5ebnmp4vxd6hv33s4ckjlvffeo2@hera.m-0.eu>

>From my understanding the biggest argument against this is the change in
template-haskell?
I am wondering how many users will actually be affected by that.
TypeAbstractions are quite recent so I wouldn’t be surprised if not much
template-haskell code is using the corresponding constructors.
That might also be an argument to do this change now before the ecosystem has
more time to settle on this.

Simon, I am also curious. Why are you not convinced by the goal to make types
and terms as similar as possible?

Best
Malte

On 2024-03-22 14:23, Arnaud Spiwack wrote:
> I'm happy to follow you on this. Especially since in the future that Vlad
> hopes, where there'd be less difference between terms and types, this
> particular feature may fall naturally, so it may be worth revisiting then
> rather than paying the cost now.
> 
> On Fri, 22 Mar 2024 at 09:53, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> 
> > Do you worry about the implementation because of future maintenance costs?
> >> Or because of the immediate cost of developing the feature?
> >
> >
> > Mostly the former.  It's just a bit more un-forced complexity.
> >
> > As far as I can see, there aren't other objections to this design besides
> >> the cost, right? There's no real possibility of an alternate, conflicting
> >> design for data type arguments, is there?
> >>
> >
> > It's just Occam's razor.   No one is asking for this.  And I'm unconvinced
> > by "future proofiing" because it's hard to correctly anticipate the future.
> >
> > Simon
> >
> > On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> > wrote:
> >
> >> Simon,
> >>
> >> Do you worry about the implementation because of future maintenance
> >> costs? Or because of the immediate cost of developing the feature?
> >>
> >> As far as I can see, there aren't other objections to this design besides
> >> the cost, right? There's no real possibility of an alternate, conflicting
> >> design for data type arguments, is there?
> >>
> >> On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones <
> >> simon.peytonjones at gmail.com> wrote:
> >>
> >>> Dear Steering Committee
> >>>
> >>> Vlad proposes to amend proposal #425
> >>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
> >>> permit more wildcard binder forms in type declarations:
> >>>   https://github.com/ghc-proposals/ghc-proposals/pull/641
> >>>
> >>> You may find it easiest to look at the rich diff
> >>> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
> >>> .
> >>>
> >>> This is a pretty small generalisation which would allow
> >>>
> >>> data T (( (a :: k1) :: k2)) = ...
> >>>
> >>> in which the binder has multiple kind signatures and redundant parens.
> >>> The change is *not driven by user need*, but rather solely by
> >>> *uniformity*: these same forms are permitted in function definitions:
> >>>
> >>> f :: forall (a :: k). blah
> >>> f @(((a::k1)::k2))) = ...
> >>>
> >>> is permitted.
> >>>
> >>> It imposes a change on Template Haskell syntax too.
> >>>
> >>> The implementation becomes a bit more complicated; more recursive data
> >>> types, etc.  Nothing hard, but more.
> >>>
> >>> It's not a big deal either way.  Very few people expressed a view on
> >>> GitHub.  My personal view is that the modest (albeit non-zero) gain does
> >>> not justify the definite (albeit modest) pain. I would leave this until
> >>> someone actually wants it.
> >>>
> >>> Vlad argues for future-proofing, but my experience is that an eye to the
> >>> future is sensible when you are making changes anyway; but making unforced
> >>> changes solely for the future risks incurring pain now that, when the
> >>> future comes, turns out to have been a poor investment.  We may have
> >>> correctly anticipated, or we may not.
> >>>
> >>> So my recommendation is to park this until we get a real user demand.
> >>>
> >>> It's a perfectly sensible proposal, but adopting it is a judgement call.
> >>> I'll leave a week for committee responses, and then we can just vote.
> >>>
> >>> Simon
> >>>
> >>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:
> >>>
> >>>> Dear Committee,
> >>>>
> >>>> Vlad proposes to amend proposal #425 to permit more wildcard binder
> >>>> forms in type declarations:
> >>>>
> >>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
> >>>>
> >>>> I'd like to nominate Simon PJ as the shepherd.
> >>>>
> >>>> Please guide us to a conclusion as outlined in
> >>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Adam
> >>>>
> >>>>
> >>>> --
> >>>> Adam Gundry, Haskell Consultant
> >>>> Well-Typed LLP, https://www.well-typed.com/
> >>>>
> >>>> Registered in England & Wales, OC335890
> >>>> 27 Old Gloucester Street, London WC1N 3AX, England
> >>>> _______________________________________________
> >>>> ghc-steering-committee mailing list
> >>>> ghc-steering-committee at haskell.org
> >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>>>
> >>> _______________________________________________
> >>> 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


From marlowsd at gmail.com  Fri Mar 22 15:05:09 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 22 Mar 2024 15:05:09 +0000
Subject: [ghc-steering-committee] Please review #617: Add -experimental
 flag, Shepherd: Simon M
In-Reply-To: <7a9c8bb6-deec-49c5-9898-3701917ff2d9@well-typed.com>
References: <7a9c8bb6-deec-49c5-9898-3701917ff2d9@well-typed.com>
Message-ID: <CANsrgPJJa6rEjk1hNSrWfwgjZZ9yRwAwVpEkp5eKL9RAHb42+g@mail.gmail.com>

I was asked to shepherd this proposal, but reading through it doesn't look
like we're in a state to make a decision yet.

   - The proposal itself still has some outstanding issues raised in the
   comment thread
   - It interacts and overlaps with "Fortified Language Editions", and it
   doesn't make a lot of sense (to me at least) to consider these proposals
   separately.

So for now I'm going to put this back in needs-revision

Cheers
Simon

On Thu, 25 Jan 2024 at 09:13, Adam Gundry <adam at well-typed.com> wrote:

> Dear Committee,
>
> Moritz proposes to add a new flag, -experimental, to guard experimental
> features:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/617
>
>
> https://github.com/angerman/ghc-proposals/blob/std-experimental/proposals/0000-std-experimental.rst
>
> I’d like to nominate Simon Marlow as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Cheers,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> 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/20240322/088dc361/attachment.html>

From marlowsd at gmail.com  Fri Mar 22 15:42:42 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 22 Mar 2024 15:42:42 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
Message-ID: <CANsrgPJAqE2bS=yK+ZFhGgR+AyQMk=X1=0AkvLdQzDmo5r_8Pw@mail.gmail.com>

I'm totally fine with bumping the default to GHC2024. Indeed that seems the
least surprising behaviour, because "the latest supported by the compiler"
is predictable and you don't have to look in the user guide to find out
whether the default was bumped or not.

Adding a warning for ad-hoc use would be too annoying IMO.

Cheers
Simon

On Thu, 21 Mar 2024 at 09:08, Adam Gundry <adam at well-typed.com> wrote:

> Apologies for letting this thread linger.
>
> The current de facto situation is that GHC 9.10 will ship with GHC2024
> available but not enabled by default. (Given the timing, it did not seem
> feasible to change the default, and but leaving GHC2024 out of the
> release entirely would seem unnecessary.)
>
> Several people have expressed the opinion that we should actively plan
> to switch the default, to benefit one-off use (especially in ghci),
> rather than simply leaving GHC2021 as the default indefinitely. So the
> question is what level of messaging is appropriate before that happens.
> I can see a few options, none of which are entirely satisfying:
>
>   * Mention in the release notes (done for 9.10, and easily done in the
> next release).
>
>   * Add an off-by-default warning about failure to specify a language
> edition (maybe in -Wall or -Wcompat). Unclear this benefits many people
> because if they aren't specifying a language edition or reading the
> release notes, they may well not be enabling non-default warnings either.
>
>   * Enable the warning about failure to specify a language edition by
> default. A bit noisy for ad hoc use.
>
>   * Add a warning where NoMonoLocalBinds is used and changing to
> MonoLocalBinds would break the program (since this is the most likely
> source of breakage in practice). This warning could be enabled by
> default if no language edition is specified. Nice for users, but
> probably quite a bit of implementation overhead, so unclear if it would
> be implemented.
>
>   * Wait for a super-major release (e.g. the 10.x series) before
> changing the default language. Not clear when this will be.
>
> Any other options? Opinions?
>
> Adam
>
>
> On 19/02/2024 21:34, Eric Seidel wrote:
> > It seems to me that this particular proposal could make sense
> > tactically, but I agree with Chris and Arnaud that it feels
> > like the wrong thing strategically.
> >
> > I don't see us getting away from a notion of a "default language".
> > GCC/Clang similarly implement many C/C++ standards and let users
> > choose, but still define a default standard per compiler version.
> > And this default changes across compiler releases. Forcing even
> > adhoc ghc[i] sessions to specify a language standard feels
> > excessive.
> >
> > Thus, we need *some* cadence for updating the default language.
> > It could be that GHC 9.10 is too soon to make that change, but
> > we should commit to making the change at some point, with proper
> > messaging.
> >
> > Eric
> >
> > On Fri, Feb 16, 2024, at 03:08, Adam Gundry wrote:
> >> Thanks everyone for sharing your thoughts.
> >>
> >> I would point out that this is not just about "the handful of people
> >> that have ghci scripts" but rather anyone compiling modules with ghc
> >> directly (not using Cabal). Were it about ghci alone, I agree that the
> >> latest language edition would be preferable. But it seems likely to be a
> >> larger class, e.g. including educators teaching Haskell, and users with
> >> small programs where they have not created a Cabal package.
> >>
> >> Adam
> >>
> >>
> >> On 16/02/2024 08:36, Arnaud Spiwack wrote:
> >>> (I won't be able to follow this conversation as I'll be on holiday for
> >>> the next week so dropping my thoughts a little unstructured)
> >>>
> >>> I'm not keen on giving people gratuitous work. I think staging making
> >>> GHC2024 the default borders on gratuitous work (because I'm not
> >>> convinced that the transition period will achieve anything, but on the
> >>> other hand, it gives us a little bit of time to warn people). The idea
> >>> that we will want to make a decision for each edition in the future
> >>> regarding whether it's to be the default is definitely gratuitous work
> >>> (I can be convinced otherwise, of course: this is my current train of
> >>> thoughts).
> >>> Generally speaking, all cabal projects have a fixed `default-language`
> >>> (which, we learnt, is Haskell98 if omitted). So really we're doing this
> >>> for the handful of people that have ghci scripts. And we're making
> >>> everybody else's life worse (because ghci is worse). I'm, obviously, a
> >>> strong believer in the power of defaults.
> >>>
> >>> So, anyway, without having had much time to think about this: maybe ok
> >>> for staging GHC2024 in particular, just this once. I think it's a bad
> >>> idea, but not a hill I'll die on. The rest of the proposal I'm rather
> >>> opposed to.
> >>>
> >>> On Thu, 15 Feb 2024 at 20:51, Chris Dornan <chris at chrisdornan.com
> >>> <mailto:chris at chrisdornan.com>> wrote:
> >>>
> >>>      Sorry, I misunderstood the proposal — for some reason I thought we
> >>>      were going to delay the default for ghci.
> >>>
> >>>      If we think the new language is going to be particularly
> disruptive
> >>>      then we might want a transition period where it is available
> before
> >>>      making it the default — I really have no objection to this at all
> in
> >>>      general.
> >>>
> >>>      I will just suggest that we might want to enable these defaults
> >>>      quite aggressively — and I say this having been bitten by GHC2021
> >>>      myself. We are committed to breaking stuff — is there much to be
> >>>      gained by delaying. Is it not going to delay take-up? It makes the
> >>>      whole process more complicated.
> >>>
> >>>      Chris
> >>>
> >>>
> >>>>      On 15 Feb 2024, at 16:08, Simon Peyton Jones
> >>>>      <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com
> >>
> >>>>      wrote:
> >>>>
> >>>>      I'm not understanding  your point, Chris.
> >>>>
> >>>>      I think we are planning to increasingly encourage people to
> >>>>      specify an explicit language edition for everything.  (Indeed
> >>>>      there is discussion of an on-by-default warning that complains if
> >>>>      you don't.)  For these users, the "default language edition" is
> >>>>      irrelevant.
> >>>>
> >>>>      So the only issue is people who don't specify a language edition
> >>>>      at all.   Changing the default language edition risks breaking
> >>>>      their code.  Why would we do that? What compelling reason is
> there
> >>>>      for breaking code that we don't have to break?
> >>>>
> >>>>      For the short term,
> >>>>
> >>>>        * GHC2024 is particularly likely to break code
> >>>>        * We have not yet educated our users to use explicit language
> >>>>          editions
> >>>>
> >>>>      So making GHC2024 be the default language for GHC 9.10 seems (to
> >>>>      me) to lead to entirely-unnecessary breakage, with no compelling
> >>>>      reason to do so.
> >>>>
> >>>>      Simon
> >>>>
> >>>>      On Thu, 15 Feb 2024 at 13:21, Chris Dornan <
> chris at chrisdornan.com
> >>>>      <mailto:chris at chrisdornan.com>> wrote:
> >>>>
> >>>>          I have been a strongly in favour of minimising surprises but
> I
> >>>>          mildly resistant to this proposal.
> >>>>
> >>>>          After GHC2021 broke my code quite severly (though PolyKinds)
> >>>>          there was an initial adjustment phase but I quickly got used
> >>>>          to specifying the exact language I want to use everywhere.
> >>>>          Indeed the propensity for GHCi to pick up the new breakage
> >>>>          caused some surprises but I quickly adjusted when I realised
> >>>>          what was going on.
> >>>>
> >>>>          The point is not that change is bad but change that is
> >>>>          difficult to anticipate and control is bad.
> >>>>
> >>>>          I now see the GHC adoption of the new default languages, that
> >>>>          can very selectively break things when needed, as a fantastic
> >>>>          development. It allows us to roll out changes in a very
> >>>>          controlled way where at synchronisation points that are easy
> >>>>          to understand and where developers retain control. This
> >>>>          strikes me as a really great sweet spot for Haskell.
> >>>>
> >>>>          If we make this scheme more complicated by making some the
> >>>>          tools adopt languages on different schedules then it risks
> >>>>          creating confusion. Folks that want to tie down advanced
> >>>>          features strike me as just the kind that should find it easy
> >>>>          to fill out the appropriate settings in configuration files.
> >>>>
> >>>>          So I say lets get this rolled out ASAP (as Adam says) but
> roll
> >>>>          it out consistently everywhere.
> >>>>
> >>>>          Chris
> >>>>
> >>>>
> >>>>>          On 15 Feb 2024, at 09:15, Simon Peyton Jones
> >>>>>          <simon.peytonjones at gmail.com
> >>>>>          <mailto:simon.peytonjones at gmail.com>> wrote:
> >>>>>
> >>>>>          I'm ok with this proposal.  The whole concept of a default
> >>>>>          language seems a bit flaky to me, if we are going to start
> >>>>>          warning any time someone doesn't explicitly specify an
> >>>>>          explicit addition.  While this is settling down, causing
> >>>>>          minimum disruption is good.
> >>>>>
> >>>>>          Simon
> >>>>>
> >>>>>          On Thu, 15 Feb 2024 at 08:50, Adam Gundry
> >>>>>          <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> >>>>>
> >>>>>              Dear committee,
> >>>>>
> >>>>>              In #632, I propose amending the GHC2024 proposal to
> >>>>>              specify that the
> >>>>>              default language used by ghc/ghci when run directly will
> >>>>>              remain GHC2021
> >>>>>              for now, since changing to GHC2024 is not backwards
> >>>>>              compatible. (This
> >>>>>              does not affect Cabal packages either way, since Cabal
> >>>>>              specifies its own
> >>>>>              default.)
> >>>>>
> >>>>>              https://github.com/ghc-proposals/ghc-proposals/pull/632
> >>>>>              <
> https://github.com/ghc-proposals/ghc-proposals/pull/632>
> >>>>>
> >>>>>
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> <
> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
> >
> >>>>>
> >>>>>              On the discussion thread, some people expressed a
> >>>>>              preference that GHC
> >>>>>              should default to the latest language edition anyway.
> >>>>>              There is also
> >>>>>              Richard's suggestion of wider changes of approach in
> >>>>>              #636. However,
> >>>>>              given that the GHC 9.10 fork date is fast approaching,
> >>>>>              introducing
> >>>>>              GHC2024 but not making it the default seems like the
> best
> >>>>>              short-term
> >>>>>              solution to me. We can always reassess our approach to
> >>>>>              this for future
> >>>>>              releases as part of the wider discussion.
> >>>>>
> >>>>>              If you object to the proposed approach, please speak up
> >>>>>              ASAP. Otherwise
> >>>>>              I plan to merge in a week or so.
> >>>>>
> >>>>>              Cheers,
> >>>>>
> >>>>>              Adam
> >>
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20240322/bdd3036b/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Mar 22 18:19:29 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Mar 2024 18:19:29 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <kcg5tp5qxa5zfi2xlyzebwn5ebnmp4vxd6hv33s4ckjlvffeo2@hera.m-0.eu>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
 <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>
 <CAGwnsnngDuAxqVY__i8ifL3sEdZhdA6Hq9KhC2ZFSb_kq0P4oQ@mail.gmail.com>
 <kcg5tp5qxa5zfi2xlyzebwn5ebnmp4vxd6hv33s4ckjlvffeo2@hera.m-0.eu>
Message-ID: <CAJKmMz-atEf_rh2iztWA1NFG0xxq2pZaHTN8SY8e3_1Lb_2XHA@mail.gmail.com>

>From my understanding the biggest argument against this is the change in
template-haskell?


Not specifically.  My reservation is that

   - it's an unforced change,
   - with no user demand
   - but some real user impact (you mention TH)
   - and some implementation cost (modest but very non-zero)
   - aiming to anticipate as-yet-unknown future requirements

That's not a combination I like.  Pain now for possible (but uncertain)
gain in the future.

I don't object to making types and terms behave similarly -- indeed I have
invested lots of time working with Richard, Vlad, Andrei and others on
proposals and MRs that move in this direction.  I'm just very unconvinced
about *this *proposal.

One minor point.  In patterns we allow this:
f ((,) @Int @[a] x y) = ...
Here the type arguments are not type variables but full-blown types, and of
course nested parens etc come "for free".  But this proposal concerns data
type declarations in which we definitely don't want fulll-blown types. So
it's more than a "terms and types should be the same" discussion.

Simon



On Fri, 22 Mar 2024 at 14:47, Malte Ott <malte.ott at maralorn.de> wrote:

> From my understanding the biggest argument against this is the change in
> template-haskell?
> I am wondering how many users will actually be affected by that.
> TypeAbstractions are quite recent so I wouldn’t be surprised if not much
> template-haskell code is using the corresponding constructors.
> That might also be an argument to do this change now before the ecosystem
> has
> more time to settle on this.
>
> Simon, I am also curious. Why are you not convinced by the goal to make
> types
> and terms as similar as possible?
>
> Best
> Malte
>
> On 2024-03-22 14:23, Arnaud Spiwack wrote:
> > I'm happy to follow you on this. Especially since in the future that Vlad
> > hopes, where there'd be less difference between terms and types, this
> > particular feature may fall naturally, so it may be worth revisiting then
> > rather than paying the cost now.
> >
> > On Fri, 22 Mar 2024 at 09:53, Simon Peyton Jones <
> > simon.peytonjones at gmail.com> wrote:
> >
> > > Do you worry about the implementation because of future maintenance
> costs?
> > >> Or because of the immediate cost of developing the feature?
> > >
> > >
> > > Mostly the former.  It's just a bit more un-forced complexity.
> > >
> > > As far as I can see, there aren't other objections to this design
> besides
> > >> the cost, right? There's no real possibility of an alternate,
> conflicting
> > >> design for data type arguments, is there?
> > >>
> > >
> > > It's just Occam's razor.   No one is asking for this.  And I'm
> unconvinced
> > > by "future proofiing" because it's hard to correctly anticipate the
> future.
> > >
> > > Simon
> > >
> > > On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> > > wrote:
> > >
> > >> Simon,
> > >>
> > >> Do you worry about the implementation because of future maintenance
> > >> costs? Or because of the immediate cost of developing the feature?
> > >>
> > >> As far as I can see, there aren't other objections to this design
> besides
> > >> the cost, right? There's no real possibility of an alternate,
> conflicting
> > >> design for data type arguments, is there?
> > >>
> > >> On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones <
> > >> simon.peytonjones at gmail.com> wrote:
> > >>
> > >>> Dear Steering Committee
> > >>>
> > >>> Vlad proposes to amend proposal #425
> > >>> <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst
> >to
> > >>> permit more wildcard binder forms in type declarations:
> > >>>   https://github.com/ghc-proposals/ghc-proposals/pull/641
> > >>>
> > >>> You may find it easiest to look at the rich diff
> > >>> <
> https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5
> >
> > >>> .
> > >>>
> > >>> This is a pretty small generalisation which would allow
> > >>>
> > >>> data T (( (a :: k1) :: k2)) = ...
> > >>>
> > >>> in which the binder has multiple kind signatures and redundant
> parens.
> > >>> The change is *not driven by user need*, but rather solely by
> > >>> *uniformity*: these same forms are permitted in function definitions:
> > >>>
> > >>> f :: forall (a :: k). blah
> > >>> f @(((a::k1)::k2))) = ...
> > >>>
> > >>> is permitted.
> > >>>
> > >>> It imposes a change on Template Haskell syntax too.
> > >>>
> > >>> The implementation becomes a bit more complicated; more recursive
> data
> > >>> types, etc.  Nothing hard, but more.
> > >>>
> > >>> It's not a big deal either way.  Very few people expressed a view on
> > >>> GitHub.  My personal view is that the modest (albeit non-zero) gain
> does
> > >>> not justify the definite (albeit modest) pain. I would leave this
> until
> > >>> someone actually wants it.
> > >>>
> > >>> Vlad argues for future-proofing, but my experience is that an eye to
> the
> > >>> future is sensible when you are making changes anyway; but making
> unforced
> > >>> changes solely for the future risks incurring pain now that, when the
> > >>> future comes, turns out to have been a poor investment.  We may have
> > >>> correctly anticipated, or we may not.
> > >>>
> > >>> So my recommendation is to park this until we get a real user demand.
> > >>>
> > >>> It's a perfectly sensible proposal, but adopting it is a judgement
> call.
> > >>> I'll leave a week for committee responses, and then we can just vote.
> > >>>
> > >>> Simon
> > >>>
> > >>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com>
> wrote:
> > >>>
> > >>>> Dear Committee,
> > >>>>
> > >>>> Vlad proposes to amend proposal #425 to permit more wildcard binder
> > >>>> forms in type declarations:
> > >>>>
> > >>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
> > >>>>
> > >>>> I'd like to nominate Simon PJ as the shepherd.
> > >>>>
> > >>>> Please guide us to a conclusion as outlined in
> > >>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> Adam
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Adam Gundry, Haskell Consultant
> > >>>> Well-Typed LLP, https://www.well-typed.com/
> > >>>>
> > >>>> Registered in England & Wales, OC335890
> > >>>> 27 Old Gloucester Street, London WC1N 3AX, England
> > >>>> _______________________________________________
> > >>>> ghc-steering-committee mailing list
> > >>>> ghc-steering-committee at haskell.org
> > >>>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >>>>
> > >>> _______________________________________________
> > >>> 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
>
> _______________________________________________
> 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/20240322/b7bcfdf6/attachment.html>

From simon.peytonjones at gmail.com  Fri Mar 22 18:26:40 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Mar 2024 18:26:40 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <qjq2cfabyd4v6m47a2srivl6ovhpmd6jpb6kq5xqoyht3bcwqu@hera.m-0.eu>
References: <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
 <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
 <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>
 <542dd7b3f5c076ddce5de321e475eb8f0e71a8e7.camel@joachim-breitner.de>
 <qjq2cfabyd4v6m47a2srivl6ovhpmd6jpb6kq5xqoyht3bcwqu@hera.m-0.eu>
Message-ID: <CAJKmMz-gp-OzcCFaJ9a+A_8Dwn0gDuBUeSu7uSBX_b+8rk7-ZQ@mail.gmail.com>

I really want ghci to use the latest and greatest language edition.


I think we agree about this

I also would prefer it to be used when calling ghc on a quick test file.
If deemed necessary we can throw a warning when we fallback to a default in
that case.


Ah, but now we are on the slippery slope.  Your "quick test file" may well
become a little script you use every day... and it may then suddenly stop
working when you install a new GHC with a new default language edition.  We
don't want that!  And it is completely solved by saying that we never
change the default language edition for .hs modules -- if it works now
it'll work in the future because we always fall back to the same language
edition. (e.g Hsakell98 or GHC2021 or whatever).

In some ways Hakell98 is better: it's very stable; and it is so old that
it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-} at the top
of your module to make it self-describing.   I love self-describing files
:-)

I wonder if this debate would be better on the GitHub discussion thread?
I'd love to hear from more people.

Simon

On Fri, 22 Mar 2024 at 14:42, Malte Ott <malte.ott at maralorn.de> wrote:

> I also think that the notion of default-language matters. For some reason
> people
> care greatly about which is the "real" Haskell.
>
> I really want ghci to use the latest and greatest language edition.
> I also would prefer it to be used when calling ghc on a quick test file.
> If deemed necessary we can throw a warning when we fallback to a default in
> that case.
>
> I think it is very important that we care about breakage for the sake of
> the
> ecosystem. But the ecosystem relies on Cabal to build packages so outside
> of
> that changes have another quality.
>
> Best
> Malte
> _______________________________________________
> 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/20240322/cd14e7af/attachment-0001.html>

From moritz.angermann at gmail.com  Sat Mar 23 01:15:24 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 23 Mar 2024 09:15:24 +0800
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAJKmMz-gp-OzcCFaJ9a+A_8Dwn0gDuBUeSu7uSBX_b+8rk7-ZQ@mail.gmail.com>
References: <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
 <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
 <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>
 <542dd7b3f5c076ddce5de321e475eb8f0e71a8e7.camel@joachim-breitner.de>
 <qjq2cfabyd4v6m47a2srivl6ovhpmd6jpb6kq5xqoyht3bcwqu@hera.m-0.eu>
 <CAJKmMz-gp-OzcCFaJ9a+A_8Dwn0gDuBUeSu7uSBX_b+8rk7-ZQ@mail.gmail.com>
Message-ID: <CAKfdd-wcf9itVbzD1ej7LQ6ekAWAqcNKvUGrohAz8UDRud2tTg@mail.gmail.com>

I'm all for people specifying the language they want at the module (or
cabal level).

I would expect ghci to give me the default variant for the compiler I'm
using, unless I explicitly set a specific default language
(e.g. if I launch ghci through cabal, then I expect it to adhere to the
language set in the cabal file).


On Sat, 23 Mar 2024 at 02:27, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I really want ghci to use the latest and greatest language edition.
>
>
> I think we agree about this
>
> I also would prefer it to be used when calling ghc on a quick test file.
> If deemed necessary we can throw a warning when we fallback to a default in
> that case.
>
>
> Ah, but now we are on the slippery slope.  Your "quick test file" may well
> become a little script you use every day... and it may then suddenly stop
> working when you install a new GHC with a new default language edition.  We
> don't want that!  And it is completely solved by saying that we never
> change the default language edition for .hs modules -- if it works now
> it'll work in the future because we always fall back to the same language
> edition. (e.g Hsakell98 or GHC2021 or whatever).
>
> In some ways Hakell98 is better: it's very stable; and it is so old that
> it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-} at the top
> of your module to make it self-describing.   I love self-describing files
> :-)
>
> I wonder if this debate would be better on the GitHub discussion thread?
> I'd love to hear from more people.
>
> Simon
>
> On Fri, 22 Mar 2024 at 14:42, Malte Ott <malte.ott at maralorn.de> wrote:
>
>> I also think that the notion of default-language matters. For some reason
>> people
>> care greatly about which is the "real" Haskell.
>>
>> I really want ghci to use the latest and greatest language edition.
>> I also would prefer it to be used when calling ghc on a quick test file.
>> If deemed necessary we can throw a warning when we fallback to a default
>> in
>> that case.
>>
>> I think it is very important that we care about breakage for the sake of
>> the
>> ecosystem. But the ecosystem relies on Cabal to build packages so outside
>> of
>> that changes have another quality.
>>
>> Best
>> Malte
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240323/6095b49b/attachment.html>

From moritz.angermann at gmail.com  Sat Mar 23 01:17:28 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 23 Mar 2024 09:17:28 +0800
Subject: [ghc-steering-committee] Please review #617: Add -experimental
 flag, Shepherd: Simon M
In-Reply-To: <CANsrgPJJa6rEjk1hNSrWfwgjZZ9yRwAwVpEkp5eKL9RAHb42+g@mail.gmail.com>
References: <7a9c8bb6-deec-49c5-9898-3701917ff2d9@well-typed.com>
 <CANsrgPJJa6rEjk1hNSrWfwgjZZ9yRwAwVpEkp5eKL9RAHb42+g@mail.gmail.com>
Message-ID: <CAKfdd-widuATBDGrmNFrKM0EGaKkaVhUVQcycxNoOBt9ta__0w@mail.gmail.com>

@Simon Marlow <marlowsd at gmail.com> agreed. The choice of -experimental is
too contentious in meaning. The proposal needs to be rewritten using a
different flag name.
The whole confusion seems to stem from the fact that "experimental" means
vastly different things to different people.

On Fri, 22 Mar 2024 at 23:05, Simon Marlow <marlowsd at gmail.com> wrote:

> I was asked to shepherd this proposal, but reading through it doesn't look
> like we're in a state to make a decision yet.
>
>    - The proposal itself still has some outstanding issues raised in the
>    comment thread
>    - It interacts and overlaps with "Fortified Language Editions", and it
>    doesn't make a lot of sense (to me at least) to consider these proposals
>    separately.
>
> So for now I'm going to put this back in needs-revision
>
> Cheers
> Simon
>
> On Thu, 25 Jan 2024 at 09:13, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear Committee,
>>
>> Moritz proposes to add a new flag, -experimental, to guard experimental
>> features:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/617
>>
>>
>> https://github.com/angerman/ghc-proposals/blob/std-experimental/proposals/0000-std-experimental.rst
>>
>> I’d like to nominate Simon Marlow as the shepherd.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Cheers,
>>
>> Adam
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240323/6e0f4efb/attachment.html>

From marlowsd at gmail.com  Mon Mar 25 09:30:48 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 25 Mar 2024 09:30:48 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAJKmMz-gp-OzcCFaJ9a+A_8Dwn0gDuBUeSu7uSBX_b+8rk7-ZQ@mail.gmail.com>
References: <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
 <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
 <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>
 <542dd7b3f5c076ddce5de321e475eb8f0e71a8e7.camel@joachim-breitner.de>
 <qjq2cfabyd4v6m47a2srivl6ovhpmd6jpb6kq5xqoyht3bcwqu@hera.m-0.eu>
 <CAJKmMz-gp-OzcCFaJ9a+A_8Dwn0gDuBUeSu7uSBX_b+8rk7-ZQ@mail.gmail.com>
Message-ID: <CANsrgPJL-TPRXp-DEWRFG3ropM4-rDHQAkV1K1SD1EVGGfLRzg@mail.gmail.com>

On Fri, 22 Mar 2024 at 18:27, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I really want ghci to use the latest and greatest language edition.
>
>
> I think we agree about this
>
> I also would prefer it to be used when calling ghc on a quick test file.
> If deemed necessary we can throw a warning when we fallback to a default in
> that case.
>
>
> Ah, but now we are on the slippery slope.  Your "quick test file" may well
> become a little script you use every day... and it may then suddenly stop
> working when you install a new GHC with a new default language edition.  We
> don't want that!  And it is completely solved by saying that we never
> change the default language edition for .hs modules -- if it works now
> it'll work in the future because we always fall back to the same language
> edition. (e.g Hsakell98 or GHC2021 or whatever).
>
> In some ways Hakell98 is better: it's very stable; and it is so old that
> it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-} at the top
> of your module to make it self-describing.   I love self-describing files
> :-)
>

I can think of a couple of reasons not to fix the default language
permanently:

   - Eventually we'll want to remove support for Haskell98, GHC2021 etc.
   because supporting old versions of the language gets harder over time. The
   Fortified Language Editions proposal requires 3 years of support only.
   (indeed Haskell98 is already not really Haskell98, because the definition
   of Monad has changed for example)
   - Other languages don't do it this way, e.g. with gcc/g++ you get some
   recent version of C/C++ by default.

Cheers
Simon


>
> I wonder if this debate would be better on the GitHub discussion thread?
> I'd love to hear from more people.
>
> Simon
>
> On Fri, 22 Mar 2024 at 14:42, Malte Ott <malte.ott at maralorn.de> wrote:
>
>> I also think that the notion of default-language matters. For some reason
>> people
>> care greatly about which is the "real" Haskell.
>>
>> I really want ghci to use the latest and greatest language edition.
>> I also would prefer it to be used when calling ghc on a quick test file.
>> If deemed necessary we can throw a warning when we fallback to a default
>> in
>> that case.
>>
>> I think it is very important that we care about breakage for the sake of
>> the
>> ecosystem. But the ecosystem relies on Cabal to build packages so outside
>> of
>> that changes have another quality.
>>
>> Best
>> Malte
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240325/f4ae3b1d/attachment.html>

From arnaud.spiwack at tweag.io  Tue Mar 26 09:34:00 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 26 Mar 2024 10:34:00 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
 <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>
Message-ID: <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>

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

From simon.peytonjones at gmail.com  Tue Mar 26 11:57:09 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 26 Mar 2024 11:57:09 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
 <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>
 <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>
Message-ID: <CAJKmMz83_BBeTXCWLMWVGeC5YE2uU=ZBrjshuG9+ippUE9G_AA@mail.gmail.com>

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>

From arnaud.spiwack at tweag.io  Tue Mar 26 15:23:53 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 26 Mar 2024 16:23:53 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAJKmMz83_BBeTXCWLMWVGeC5YE2uU=ZBrjshuG9+ippUE9G_AA@mail.gmail.com>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
 <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>
 <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>
 <CAJKmMz83_BBeTXCWLMWVGeC5YE2uU=ZBrjshuG9+ippUE9G_AA@mail.gmail.com>
Message-ID: <CAGwnsnkE-RBLiVp1bLhG5UPd7T6g99aVNE8N6M0HfgdkqdoT=A@mail.gmail.com>

Of course I'll ask Shea, but I want to gather thoughts first. Hence my call
for a vote. If I may make a final attempt at defining the options I layed
out. If it doesn't work, I'll change my strategy.

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. (On Void
and (), T and 0 are the same thing)
- N: not available under this alternative

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

Alternatives:
1a. TT0T0T (this is Shea's preferred proposal)
1b. -XNoWombat: 000000 / -XWombat TTETET
2. 00WWWN
3a. -XNoWombat: 00WWWW / -XWombat: TTETET
3b. -XNoWombat: 00WWWW / -XWombat: TTWTWT

On Tue, 26 Mar 2024 at 12:57, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

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

-- 
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/20240326/550bfb19/attachment.html>

From adam at well-typed.com  Tue Mar 26 19:38:31 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 26 Mar 2024 19:38:31 +0000
Subject: [ghc-steering-committee] Update on nomination round
Message-ID: <2796059f-c995-485d-97cc-0f93f8a99192@well-typed.com>

Hi everyone,

Just a quick update on the current nomination round, which we started 
earlier this month following Malte and Matthías joining: so far I've 
received 4 nominations. We were originally planning to accept up to 3 
new members depending on the applications we receive, though we can of 
course reconsider this.

I intend to allow another week or so for nominations, then distribute 
the nominations privately for consideration by the committee. So if you 
are still planning to encourage someone to apply, please do so ASAP.

Cheers,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

From adam at well-typed.com  Tue Mar 26 20:44:42 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 26 Mar 2024 20:44:42 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CANsrgPJL-TPRXp-DEWRFG3ropM4-rDHQAkV1K1SD1EVGGfLRzg@mail.gmail.com>
References: <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
 <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>
 <9e58ff2f-734e-401f-a4cb-1a0f9e79a9d3@well-typed.com>
 <CAJKmMz-kstQx-DRAn6pbQTSv1KWDeVUyv+VRb1L3XUQT-Q9L3Q@mail.gmail.com>
 <1235d2cd-b971-4a66-85d7-625b3940c475@well-typed.com>
 <CAJKmMz_EazxsHU74-r6_KHGDGOVjqia7cbkPtRFyxyrASCXROQ@mail.gmail.com>
 <542dd7b3f5c076ddce5de321e475eb8f0e71a8e7.camel@joachim-breitner.de>
 <qjq2cfabyd4v6m47a2srivl6ovhpmd6jpb6kq5xqoyht3bcwqu@hera.m-0.eu>
 <CAJKmMz-gp-OzcCFaJ9a+A_8Dwn0gDuBUeSu7uSBX_b+8rk7-ZQ@mail.gmail.com>
 <CANsrgPJL-TPRXp-DEWRFG3ropM4-rDHQAkV1K1SD1EVGGfLRzg@mail.gmail.com>
Message-ID: <a89a6ab3-a13d-4428-9652-aa97c922e1d2@well-typed.com>

I posted a summary of options to the GitHub thread to try to solicit 
further feedback 
(https://github.com/ghc-proposals/ghc-proposals/pull/632#issuecomment-2021426391).

One idea I noticed rereading the thread was Gershom's suggestion 
(https://github.com/ghc-proposals/ghc-proposals/pull/632#issuecomment-1924318071) 
that we could change the default language when the compiler gets a 
supermajor version bump. We missed that by a release last time, as GHC 
9.0 used Haskell2010 but 9.2 used GHC2021. But we could plan for the 
next release after GHC 9.10 to be 10.0 and use GHC2024 by default, then 
in three years release GHC 11.0 with GHC2027...

Adam



On 25/03/2024 09:30, Simon Marlow wrote:
> On Fri, 22 Mar 2024 at 18:27, Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>         I really want ghci to use the latest and greatest language edition.
> 
> 
>     I think we agree about this
> 
>         I also would prefer it to be used when calling ghc on a quick
>         test file.
>         If deemed necessary we can throw a warning when we fallback to a
>         default in
>         that case. 
> 
> 
>     Ah, but now we are on the slippery slope.  Your "quick test file"
>     may well become a little script you use every day... and it may then
>     suddenly stop working when you install a new GHC with a new default
>     language edition.  We don't want that!  And it is completely solved
>     by saying that we never change the default language edition for .hs
>     modules -- if it works now it'll work in the future because we
>     always fall back to the same language edition. (e.g Hsakell98 or
>     GHC2021 or whatever).
> 
>     In some ways Hakell98 is better: it's very stable; and it is so old
>     that it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-}
>     at the top of your module to make it self-describing.   I love
>     self-describing files :-)
> 
> 
> I can think of a couple of reasons not to fix the default language 
> permanently:
> 
>   * Eventually we'll want to remove support for Haskell98, GHC2021 etc.
>     because supporting old versions of the language gets harder over
>     time. The Fortified Language Editions proposal requires 3 years of
>     support only. (indeed Haskell98 is already not really Haskell98,
>     because the definition of Monad has changed for example)
>   * Other languages don't do it this way, e.g. with gcc/g++ you get some
>     recent version of C/C++ by default.
> 
> Cheers
> Simon
> 
> 
>     I wonder if this debate would be better on the GitHub discussion
>     thread?  I'd love to hear from more people.
> 
>     Simon
> 
>     On Fri, 22 Mar 2024 at 14:42, Malte Ott <malte.ott at maralorn.de
>     <mailto:malte.ott at maralorn.de>> wrote:
> 
>         I also think that the notion of default-language matters. For
>         some reason people
>         care greatly about which is the "real" Haskell.
> 
>         I really want ghci to use the latest and greatest language edition.
>         I also would prefer it to be used when calling ghc on a quick
>         test file.
>         If deemed necessary we can throw a warning when we fallback to a
>         default in
>         that case.
> 
>         I think it is very important that we care about breakage for the
>         sake of the
>         ecosystem. But the ecosystem relies on Cabal to build packages
>         so outside of
>         that changes have another quality.
> 
>         Best
>         Malte
>         _______________________________________________

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From adam at well-typed.com  Tue Mar 26 21:12:29 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 26 Mar 2024 21:12:29 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz-atEf_rh2iztWA1NFG0xxq2pZaHTN8SY8e3_1Lb_2XHA@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
 <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>
 <CAGwnsnngDuAxqVY__i8ifL3sEdZhdA6Hq9KhC2ZFSb_kq0P4oQ@mail.gmail.com>
 <kcg5tp5qxa5zfi2xlyzebwn5ebnmp4vxd6hv33s4ckjlvffeo2@hera.m-0.eu>
 <CAJKmMz-atEf_rh2iztWA1NFG0xxq2pZaHTN8SY8e3_1Lb_2XHA@mail.gmail.com>
Message-ID: <9807ed75-a11b-40ee-aed8-cb3d024dd94a@well-typed.com>

The examples with redundant parentheses or duplicate kind signatures are 
not very compelling, indeed. But if I understand correctly, this 
proposal also permits using a wildcard binder for a visibly-quantified 
variable, like this:

type T :: forall k (a :: k) -> Type
data T _ _ where
   MkT :: T _ _

While this is not exactly an essential feature (one can work around it 
by giving unused names), it seems a more reasonable thing to want.

I doubt the impact on TH will be very significant if we use pattern 
synonyms to support the old constructors.

Adam


On 22/03/2024 18:19, Simon Peyton Jones wrote:
>      >From my understanding the biggest argument against this is the
>     change in
>     template-haskell? 
> 
> 
> Not specifically.  My reservation is that
> 
>   * it's an unforced change,
>   * with no user demand
>   * but some real user impact (you mention TH)
>   * and some implementation cost (modest but very non-zero)
>   * aiming to anticipate as-yet-unknown future requirements
> 
> That's not a combination I like.  Pain now for possible (but uncertain) 
> gain in the future.
> 
> I don't object to making types and terms behave similarly -- indeed I 
> have invested lots of time working with Richard, Vlad, Andrei and others 
> on proposals and MRs that move in this direction.  I'm just very 
> unconvinced about *this *proposal.
> 
> One minor point.  In patterns we allow this:
> f ((,) @Int @[a] x y) = ...
> Here the type arguments are not type variables but full-blown types, and 
> of course nested parens etc come "for free".  But this proposal concerns 
> data type declarations in which we definitely don't want fulll-blown 
> types. So it's more than a "terms and types should be the same" discussion.
> 
> Simon
> 
> 
> 
> On Fri, 22 Mar 2024 at 14:47, Malte Ott <malte.ott at maralorn.de 
> <mailto:malte.ott at maralorn.de>> wrote:
> 
>      From my understanding the biggest argument against this is the
>     change in
>     template-haskell?
>     I am wondering how many users will actually be affected by that.
>     TypeAbstractions are quite recent so I wouldn’t be surprised if not much
>     template-haskell code is using the corresponding constructors.
>     That might also be an argument to do this change now before the
>     ecosystem has
>     more time to settle on this.
> 
>     Simon, I am also curious. Why are you not convinced by the goal to
>     make types
>     and terms as similar as possible?
> 
>     Best
>     Malte
> 
>     On 2024-03-22 14:23, Arnaud Spiwack wrote:
>      > I'm happy to follow you on this. Especially since in the future
>     that Vlad
>      > hopes, where there'd be less difference between terms and types, this
>      > particular feature may fall naturally, so it may be worth
>     revisiting then
>      > rather than paying the cost now.
>      >
>      > On Fri, 22 Mar 2024 at 09:53, Simon Peyton Jones <
>      > simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>     wrote:
>      >
>      > > Do you worry about the implementation because of future
>     maintenance costs?
>      > >> Or because of the immediate cost of developing the feature?
>      > >
>      > >
>      > > Mostly the former.  It's just a bit more un-forced complexity.
>      > >
>      > > As far as I can see, there aren't other objections to this
>     design besides
>      > >> the cost, right? There's no real possibility of an alternate,
>     conflicting
>      > >> design for data type arguments, is there?
>      > >>
>      > >
>      > > It's just Occam's razor.   No one is asking for this.  And I'm
>     unconvinced
>      > > by "future proofiing" because it's hard to correctly anticipate
>     the future.
>      > >
>      > > Simon
>      > >
>      > > On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack
>     <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>      > > wrote:
>      > >
>      > >> Simon,
>      > >>
>      > >> Do you worry about the implementation because of future
>     maintenance
>      > >> costs? Or because of the immediate cost of developing the feature?
>      > >>
>      > >> As far as I can see, there aren't other objections to this
>     design besides
>      > >> the cost, right? There's no real possibility of an alternate,
>     conflicting
>      > >> design for data type arguments, is there?
>      > >>
>      > >> On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones <
>      > >> simon.peytonjones at gmail.com
>     <mailto:simon.peytonjones at gmail.com>> wrote:
>      > >>
>      > >>> Dear Steering Committee
>      > >>>
>      > >>> Vlad proposes to amend proposal #425
>      > >>>
>     <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>>to
>      > >>> permit more wildcard binder forms in type declarations:
>      > >>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>     <https://github.com/ghc-proposals/ghc-proposals/pull/641>
>      > >>>
>      > >>> You may find it easiest to look at the rich diff
>      > >>>
>     <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5 <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>>
>      > >>> .
>      > >>>
>      > >>> This is a pretty small generalisation which would allow
>      > >>>
>      > >>> data T (( (a :: k1) :: k2)) = ...
>      > >>>
>      > >>> in which the binder has multiple kind signatures and
>     redundant parens.
>      > >>> The change is *not driven by user need*, but rather solely by
>      > >>> *uniformity*: these same forms are permitted in function
>     definitions:
>      > >>>
>      > >>> f :: forall (a :: k). blah
>      > >>> f @(((a::k1)::k2))) = ...
>      > >>>
>      > >>> is permitted.
>      > >>>
>      > >>> It imposes a change on Template Haskell syntax too.
>      > >>>
>      > >>> The implementation becomes a bit more complicated; more
>     recursive data
>      > >>> types, etc.  Nothing hard, but more.
>      > >>>
>      > >>> It's not a big deal either way.  Very few people expressed a
>     view on
>      > >>> GitHub.  My personal view is that the modest (albeit
>     non-zero) gain does
>      > >>> not justify the definite (albeit modest) pain. I would leave
>     this until
>      > >>> someone actually wants it.
>      > >>>
>      > >>> Vlad argues for future-proofing, but my experience is that an
>     eye to the
>      > >>> future is sensible when you are making changes anyway; but
>     making unforced
>      > >>> changes solely for the future risks incurring pain now that,
>     when the
>      > >>> future comes, turns out to have been a poor investment.  We
>     may have
>      > >>> correctly anticipated, or we may not.
>      > >>>
>      > >>> So my recommendation is to park this until we get a real user
>     demand.
>      > >>>
>      > >>> It's a perfectly sensible proposal, but adopting it is a
>     judgement call.
>      > >>> I'll leave a week for committee responses, and then we can
>     just vote.
>      > >>>
>      > >>> Simon
>      > >>>
>      > >>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry
>     <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>      > >>>
>      > >>>> Dear Committee,
>      > >>>>
>      > >>>> Vlad proposes to amend proposal #425 to permit more wildcard
>     binder
>      > >>>> forms in type declarations:
>      > >>>>
>      > >>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>     <https://github.com/ghc-proposals/ghc-proposals/pull/641>
>      > >>>>
>      > >>>> I'd like to nominate Simon PJ as the shepherd.
>      > >>>>
>      > >>>> Please guide us to a conclusion as outlined in
>      > >>>>
>     https://github.com/ghc-proposals/ghc-proposals#committee-process
>     <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>      > >>>>
>      > >>>> Cheers,
>      > >>>>
>      > >>>> Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Wed Mar 27 09:14:44 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 27 Mar 2024 09:14:44 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
Message-ID: <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>

Dear Simon, Chris, Eric, Moritz, Matthias

You have not responded to my email below.

I'll call a vote tomorrow, but I would love to hear your opinions as a
member of the GHC SC.

Thanks

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear Steering Committee
>
> Vlad proposes to amend proposal #425
> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
> permit more wildcard binder forms in type declarations:
>   https://github.com/ghc-proposals/ghc-proposals/pull/641
>
> You may find it easiest to look at the rich diff
> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
> .
>
> This is a pretty small generalisation which would allow
>
> data T (( (a :: k1) :: k2)) = ...
>
> in which the binder has multiple kind signatures and redundant parens.
> The change is *not driven by user need*, but rather solely by *uniformity*:
> these same forms are permitted in function definitions:
>
> f :: forall (a :: k). blah
> f @(((a::k1)::k2))) = ...
>
> is permitted.
>
> It imposes a change on Template Haskell syntax too.
>
> The implementation becomes a bit more complicated; more recursive data
> types, etc.  Nothing hard, but more.
>
> It's not a big deal either way.  Very few people expressed a view on
> GitHub.  My personal view is that the modest (albeit non-zero) gain does
> not justify the definite (albeit modest) pain. I would leave this until
> someone actually wants it.
>
> Vlad argues for future-proofing, but my experience is that an eye to the
> future is sensible when you are making changes anyway; but making unforced
> changes solely for the future risks incurring pain now that, when the
> future comes, turns out to have been a poor investment.  We may have
> correctly anticipated, or we may not.
>
> So my recommendation is to park this until we get a real user demand.
>
> It's a perfectly sensible proposal, but adopting it is a judgement call.
> I'll leave a week for committee responses, and then we can just vote.
>
> Simon
>
> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear Committee,
>>
>> Vlad proposes to amend proposal #425 to permit more wildcard binder
>> forms in type declarations:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>>
>> I'd like to nominate Simon PJ as the shepherd.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Cheers,
>>
>> Adam
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>> _______________________________________________
>> 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/20240327/cb3c7c92/attachment.html>

From simon.peytonjones at gmail.com  Wed Mar 27 09:53:06 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 27 Mar 2024 09:53:06 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsnkE-RBLiVp1bLhG5UPd7T6g99aVNE8N6M0HfgdkqdoT=A@mail.gmail.com>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
 <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>
 <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>
 <CAJKmMz83_BBeTXCWLMWVGeC5YE2uU=ZBrjshuG9+ippUE9G_AA@mail.gmail.com>
 <CAGwnsnkE-RBLiVp1bLhG5UPd7T6g99aVNE8N6M0HfgdkqdoT=A@mail.gmail.com>
Message-ID: <CAJKmMz9f1rJ5CzL-4Yxi4QPvNbtma2CDqUitjCybTEHjcrqA_w@mail.gmail.com>

I think of it like this:

   - The core of the proposal is a way to map the value returned by `main`
   to an exit code.
   - The status quo is that it is always mapped to zero.
   - Your (2) continues with the status quo but adds a warning for return
   types other than () and Void.  Not worth doing in my view.
   - The type-class idea provides a general way to map the return value to
   an exit code.  Good plan.
   - I think we have to gate the extension, because currently a program
   with `main :: IO ExitCode` will always return exit code 0; but with the
   type-class thing it'll return the specified exit code.  A change in
   behaviour.
   - With no extension, but warning (*not *erroring), old programs (with
   say `main :: IO Bool`) may start to warn; that's OK.  It's easy to fix in a
   backward compatible way.  It's a bit like any other new warning.

Another possible plan, call it (4) in your list is: *if `main :: IO
ExitCode` then use that exit code. For all other types, return exit code 0*.
That is simpler than the type class story, but you don't list it as a
possibility.

My top picks are:

   - (4) just make main :: IO ExitCode special
   - (1c) Type class form, gated by an extension, with warning for
   non-instance types
   - Without the extension, today's behaviour (000000);
      - with the extension, warn if the return type is no an instance
      (TTWTWT).

Sadly, neither of these is in your list,, but those are the two that seem
plausible to me.

I feel we should be involving Shea, and indeed the wider community.  If a
bunch of actual users had strong opinions, I would immediately withdraw
mine. I don't feel strongly.

Simon

On Tue, 26 Mar 2024 at 15:24, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Of course I'll ask Shea, but I want to gather thoughts first. Hence my
> call for a vote. If I may make a final attempt at defining the options I
> layed out. If it doesn't work, I'll change my strategy.
>
> 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. (On Void
> and (), T and 0 are the same thing)
> - N: not available under this alternative
>
> Your 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 ... }
>
> Alternatives:
> 1a. TT0T0T (this is Shea's preferred proposal)
> 1b. -XNoWombat: 000000 / -XWombat TTETET
> 2. 00WWWN
> 3a. -XNoWombat: 00WWWW / -XWombat: TTETET
> 3b. -XNoWombat: 00WWWW / -XWombat: TTWTWT
>
> On Tue, 26 Mar 2024 at 12:57, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> 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
>>>
>>
>
> --
> 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/20240327/c9854948/attachment-0001.html>

From chris at chrisdornan.com  Wed Mar 27 16:28:13 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Wed, 27 Mar 2024 16:28:13 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>
Message-ID: <CE0D2F55-A25F-4E0C-8E9F-FE994DEFFD9F@chrisdornan.com>

I don’t have a strong opinion as I don’t do a whole lot of TLP, but consistency and uniformity are generally good, as long as we aren’t disruptive. Simon identifies some implementation complexity but I am not sure that implementation effort is so fungible as people tend to do the things they want to do anyway so we might as we’ll approve the proposal while being clear that it is not a priority — at least until some compelling use cases are brought to our attention.

I am marginally in favour but could be talked out of it if I have misjudged the externalities of approval.

Chris

> On 27 Mar 2024, at 09:14, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Dear Simon, Chris, Eric, Moritz, Matthias
> 
> You have not responded to my email below.
> 
> I'll call a vote tomorrow, but I would love to hear your opinions as a member of the GHC SC.
> 
> Thanks
> 
> Simon
> 
> On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> Dear Steering Committee
>> 
>> Vlad proposes to amend proposal #425  <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to permit more wildcard binder forms in type declarations:
>>   https://github.com/ghc-proposals/ghc-proposals/pull/641
>> 
>> You may find it easiest to look at the rich diff <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>.
>> 
>> This is a pretty small generalisation which would allow
>> 
>> data T (( (a :: k1) :: k2)) = ...
>> 
>> in which the binder has multiple kind signatures and redundant parens.  The change is not driven by user need, but rather solely by uniformity: these same forms are permitted in function definitions:
>> 
>> f :: forall (a :: k). blah
>> f @(((a::k1)::k2))) = ...
>> 
>> is permitted.
>> 
>> It imposes a change on Template Haskell syntax too.
>> 
>> The implementation becomes a bit more complicated; more recursive data types, etc.  Nothing hard, but more.
>> 
>> It's not a big deal either way.  Very few people expressed a view on GitHub.  My personal view is that the modest (albeit non-zero) gain does not justify the definite (albeit modest) pain. I would leave this until someone actually wants it.
>> 
>> Vlad argues for future-proofing, but my experience is that an eye to the future is sensible when you are making changes anyway; but making unforced changes solely for the future risks incurring pain now that, when the future comes, turns out to have been a poor investment.  We may have correctly anticipated, or we may not.
>> 
>> So my recommendation is to park this until we get a real user demand.
>> 
>> It's a perfectly sensible proposal, but adopting it is a judgement call. I'll leave a week for committee responses, and then we can just vote.
>> 
>> Simon
>> 
>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>> Dear Committee,
>>> 
>>> Vlad proposes to amend proposal #425 to permit more wildcard binder 
>>> forms in type declarations:
>>> 
>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>>> 
>>> I'd like to nominate Simon PJ as the shepherd.
>>> 
>>> Please guide us to a conclusion as outlined in
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> 
>>> Cheers,
>>> 
>>> Adam
>>> 
>>> 
>>> -- 
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>> 
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/20240327/bde0cbaf/attachment.html>

From marlowsd at gmail.com  Thu Mar 28 08:03:31 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Mar 2024 08:03:31 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>
Message-ID: <CANsrgPK9-COFQDgFL8H4m4zfy52JQp7u64gXUFEbfCxW3VqByA@mail.gmail.com>

What is the impact on Template Haskell? Is it a breaking API change?

On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear Simon, Chris, Eric, Moritz, Matthias
>
> You have not responded to my email below.
>
> I'll call a vote tomorrow, but I would love to hear your opinions as a
> member of the GHC SC.
>
> Thanks
>
> Simon
>
> On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear Steering Committee
>>
>> Vlad proposes to amend proposal #425
>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
>> permit more wildcard binder forms in type declarations:
>>   https://github.com/ghc-proposals/ghc-proposals/pull/641
>>
>> You may find it easiest to look at the rich diff
>> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
>> .
>>
>> This is a pretty small generalisation which would allow
>>
>> data T (( (a :: k1) :: k2)) = ...
>>
>> in which the binder has multiple kind signatures and redundant parens.
>> The change is *not driven by user need*, but rather solely by
>> *uniformity*: these same forms are permitted in function definitions:
>>
>> f :: forall (a :: k). blah
>> f @(((a::k1)::k2))) = ...
>>
>> is permitted.
>>
>> It imposes a change on Template Haskell syntax too.
>>
>> The implementation becomes a bit more complicated; more recursive data
>> types, etc.  Nothing hard, but more.
>>
>> It's not a big deal either way.  Very few people expressed a view on
>> GitHub.  My personal view is that the modest (albeit non-zero) gain does
>> not justify the definite (albeit modest) pain. I would leave this until
>> someone actually wants it.
>>
>> Vlad argues for future-proofing, but my experience is that an eye to the
>> future is sensible when you are making changes anyway; but making unforced
>> changes solely for the future risks incurring pain now that, when the
>> future comes, turns out to have been a poor investment.  We may have
>> correctly anticipated, or we may not.
>>
>> So my recommendation is to park this until we get a real user demand.
>>
>> It's a perfectly sensible proposal, but adopting it is a judgement call.
>> I'll leave a week for committee responses, and then we can just vote.
>>
>> Simon
>>
>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> Dear Committee,
>>>
>>> Vlad proposes to amend proposal #425 to permit more wildcard binder
>>> forms in type declarations:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>>>
>>> I'd like to nominate Simon PJ as the shepherd.
>>>
>>> Please guide us to a conclusion as outlined in
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>
>>> Cheers,
>>>
>>> Adam
>>>
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
> 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/20240328/6a0cf534/attachment-0001.html>

From marlowsd at gmail.com  Thu Mar 28 08:18:33 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Mar 2024 08:18:33 +0000
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
 <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>
 <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>
Message-ID: <CANsrgPLmpQtv5--zdcZU8dyK0ph-wK+nCgH_e+yP7bx8t=dFEw@mail.gmail.com>

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

From simon.peytonjones at gmail.com  Thu Mar 28 08:40:32 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 28 Mar 2024 08:40:32 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CANsrgPK9-COFQDgFL8H4m4zfy52JQp7u64gXUFEbfCxW3VqByA@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>
 <CANsrgPK9-COFQDgFL8H4m4zfy52JQp7u64gXUFEbfCxW3VqByA@mail.gmail.com>
Message-ID: <CAJKmMz9mcvTEariLVJPCO_ghz8YNL9Tb9+pBNYzRWbNhy+1xig@mail.gmail.com>

> What is the impact on Template Haskell? Is it a breaking API change?

yes I think so -- we'd need to elaborate the TH data types.

I don't like unforced breaking changes. That's why I advocate parking this.

Simon

On Thu, 28 Mar 2024 at 08:03, Simon Marlow <marlowsd at gmail.com> wrote:

> What is the impact on Template Haskell? Is it a breaking API change?
>
> On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear Simon, Chris, Eric, Moritz, Matthias
>>
>> You have not responded to my email below.
>>
>> I'll call a vote tomorrow, but I would love to hear your opinions as a
>> member of the GHC SC.
>>
>> Thanks
>>
>> Simon
>>
>> On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear Steering Committee
>>>
>>> Vlad proposes to amend proposal #425
>>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
>>> permit more wildcard binder forms in type declarations:
>>>   https://github.com/ghc-proposals/ghc-proposals/pull/641
>>>
>>> You may find it easiest to look at the rich diff
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
>>> .
>>>
>>> This is a pretty small generalisation which would allow
>>>
>>> data T (( (a :: k1) :: k2)) = ...
>>>
>>> in which the binder has multiple kind signatures and redundant parens.
>>> The change is *not driven by user need*, but rather solely by
>>> *uniformity*: these same forms are permitted in function definitions:
>>>
>>> f :: forall (a :: k). blah
>>> f @(((a::k1)::k2))) = ...
>>>
>>> is permitted.
>>>
>>> It imposes a change on Template Haskell syntax too.
>>>
>>> The implementation becomes a bit more complicated; more recursive data
>>> types, etc.  Nothing hard, but more.
>>>
>>> It's not a big deal either way.  Very few people expressed a view on
>>> GitHub.  My personal view is that the modest (albeit non-zero) gain does
>>> not justify the definite (albeit modest) pain. I would leave this until
>>> someone actually wants it.
>>>
>>> Vlad argues for future-proofing, but my experience is that an eye to the
>>> future is sensible when you are making changes anyway; but making unforced
>>> changes solely for the future risks incurring pain now that, when the
>>> future comes, turns out to have been a poor investment.  We may have
>>> correctly anticipated, or we may not.
>>>
>>> So my recommendation is to park this until we get a real user demand.
>>>
>>> It's a perfectly sensible proposal, but adopting it is a judgement call.
>>> I'll leave a week for committee responses, and then we can just vote.
>>>
>>> Simon
>>>
>>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> Vlad proposes to amend proposal #425 to permit more wildcard binder
>>>> forms in type declarations:
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/641
>>>>
>>>> I'd like to nominate Simon PJ as the shepherd.
>>>>
>>>> Please guide us to a conclusion as outlined in
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>
>>>> Cheers,
>>>>
>>>> Adam
>>>>
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>> 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/20240328/5a975df2/attachment.html>

From adam at well-typed.com  Thu Mar 28 09:19:00 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 28 Mar 2024 09:19:00 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz9mcvTEariLVJPCO_ghz8YNL9Tb9+pBNYzRWbNhy+1xig@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>
 <CANsrgPK9-COFQDgFL8H4m4zfy52JQp7u64gXUFEbfCxW3VqByA@mail.gmail.com>
 <CAJKmMz9mcvTEariLVJPCO_ghz8YNL9Tb9+pBNYzRWbNhy+1xig@mail.gmail.com>
Message-ID: <20308915-7563-4341-9c0c-8390e240bffd@well-typed.com>

On 28/03/2024 08:40, Simon Peyton Jones wrote:
>  > What is the impact on Template Haskell? Is it a breaking API change?
> 
> yes I think so -- we'd need to elaborate the TH data types.

Can't we fairly easily use pattern synonyms to support the old 
constructors? That would avoid breaking any existing programs. (It would 
necessarily introduce some partial matches, so a library matching on the 
old constructors could fail if exposed to the new syntax, but by 
definition existing code won't be using the new syntax.)

Adam


> I don't like unforced breaking changes. That's why I advocate parking this.
> 
> Simon
> 
> On Thu, 28 Mar 2024 at 08:03, Simon Marlow <marlowsd at gmail.com 
> <mailto:marlowsd at gmail.com>> wrote:
> 
>     What is the impact on Template Haskell? Is it a breaking API change?
> 
>     On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones
>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>     wrote:
> 
>         Dear Simon, Chris, Eric, Moritz, Matthias
> 
>         You have not responded to my email below.
> 
>         I'll call a vote tomorrow, but I would love to hear your
>         opinions as a member of the GHC SC.
> 
>         Thanks
> 
>         Simon
> 
>         On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones
>         <simon.peytonjones at gmail.com
>         <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>             Dear Steering Committee
> 
>             Vlad proposes to amend proposal #425
>             <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to permit more wildcard binder forms in type declarations:
>             https://github.com/ghc-proposals/ghc-proposals/pull/641
>             <https://github.com/ghc-proposals/ghc-proposals/pull/641>
> 
>             You may find it easiest to look at the rich diff
>             <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>.
> 
>             This is a pretty small generalisation which would allow
> 
>             data T (( (a :: k1) :: k2)) = ...
> 
>             in which the binder has multiple kind signatures and
>             redundant parens.  The change is *not driven by user need*,
>             but rather solely by *uniformity*: these same forms are
>             permitted in function definitions:
> 
>             f :: forall (a :: k). blah
>             f @(((a::k1)::k2))) = ...
> 
>             is permitted.
> 
>             It imposes a change on Template Haskell syntax too.
> 
>             The implementation becomes a bit more complicated; more
>             recursive data types, etc.  Nothing hard, but more.
> 
>             It's not a big deal either way.  Very few people expressed a
>             view on GitHub.  My personal view is that the modest (albeit
>             non-zero) gain does not justify the definite (albeit modest)
>             pain. I would leave this until someone actually wants it.
> 
>             Vlad argues for future-proofing, but my experience is that
>             an eye to the future is sensible when you are making changes
>             anyway; but making unforced changes solely for the future
>             risks incurring pain now that, when the future comes, turns
>             out to have been a poor investment.  We may have correctly
>             anticipated, or we may not.
> 
>             So my recommendation is to park this until we get a real
>             user demand.
> 
>             It's a perfectly sensible proposal, but adopting it is a
>             judgement call. I'll leave a week for committee responses,
>             and then we can just vote.
> 
>             Simon
> 
>             On Thu, 21 Mar 2024 at 08:07, Adam Gundry
>             <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> 
>                 Dear Committee,
> 
>                 Vlad proposes to amend proposal #425 to permit more
>                 wildcard binder
>                 forms in type declarations:
> 
>                 https://github.com/ghc-proposals/ghc-proposals/pull/641
>                 <https://github.com/ghc-proposals/ghc-proposals/pull/641>
> 
>                 I'd like to nominate Simon PJ as the shepherd.
> 
>                 Please guide us to a conclusion as outlined in
>                 https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> 
>                 Cheers,
> 
>                 Adam
> 


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Thu Mar 28 09:29:49 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 28 Mar 2024 09:29:49 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <20308915-7563-4341-9c0c-8390e240bffd@well-typed.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz8hU3+R=w34gr4zB0RQh95ZEAJMDGHMULu2pptiL_H_Jg@mail.gmail.com>
 <CANsrgPK9-COFQDgFL8H4m4zfy52JQp7u64gXUFEbfCxW3VqByA@mail.gmail.com>
 <CAJKmMz9mcvTEariLVJPCO_ghz8YNL9Tb9+pBNYzRWbNhy+1xig@mail.gmail.com>
 <20308915-7563-4341-9c0c-8390e240bffd@well-typed.com>
Message-ID: <CAJKmMz-TGQ6GYzPSs+J3oy9=fVRMZY0x24Ey7NH+V10w5gmphg@mail.gmail.com>

Can't we fairly easily use pattern synonyms to support the old
constructors? That would avoid breaking any existing programs. (It would
necessarily introduce some partial matches, so a library matching on the
old constructors could fail if exposed to the new syntax, but by
definition existing code won't be using the new syntax.)


Old code would get incomplete pattern match warnings; and would fail
outright if it analysed quoted code that used the new syntax.

It's all just extra complexity!   We have so many mission-critical things
to do.  I'm arguing against taking out precious time and attention to deal
with a problem that no  one is asking us to solve.

Sebastian Graf (in another context) pointed me to YAGNI:
https://martinfowler.com/bliki/Yagni.html  The author puts it well.

Simon

On Thu, 28 Mar 2024 at 09:19, Adam Gundry <adam at well-typed.com> wrote:

> On 28/03/2024 08:40, Simon Peyton Jones wrote:
> >  > What is the impact on Template Haskell? Is it a breaking API change?
> >
> > yes I think so -- we'd need to elaborate the TH data types.
>
> Can't we fairly easily use pattern synonyms to support the old
> constructors? That would avoid breaking any existing programs. (It would
> necessarily introduce some partial matches, so a library matching on the
> old constructors could fail if exposed to the new syntax, but by
> definition existing code won't be using the new syntax.)
>
> Adam
>
>
> > I don't like unforced breaking changes. That's why I advocate parking
> this.
> >
> > Simon
> >
> > On Thu, 28 Mar 2024 at 08:03, Simon Marlow <marlowsd at gmail.com
> > <mailto:marlowsd at gmail.com>> wrote:
> >
> >     What is the impact on Template Haskell? Is it a breaking API change?
> >
> >     On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones
> >     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> >     wrote:
> >
> >         Dear Simon, Chris, Eric, Moritz, Matthias
> >
> >         You have not responded to my email below.
> >
> >         I'll call a vote tomorrow, but I would love to hear your
> >         opinions as a member of the GHC SC.
> >
> >         Thanks
> >
> >         Simon
> >
> >         On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones
> >         <simon.peytonjones at gmail.com
> >         <mailto:simon.peytonjones at gmail.com>> wrote:
> >
> >             Dear Steering Committee
> >
> >             Vlad proposes to amend proposal #425
> >             <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
> permit more wildcard binder forms in type declarations:
> >             https://github.com/ghc-proposals/ghc-proposals/pull/641
> >             <https://github.com/ghc-proposals/ghc-proposals/pull/641>
> >
> >             You may find it easiest to look at the rich diff
> >             <
> https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5
> >.
> >
> >             This is a pretty small generalisation which would allow
> >
> >             data T (( (a :: k1) :: k2)) = ...
> >
> >             in which the binder has multiple kind signatures and
> >             redundant parens.  The change is *not driven by user need*,
> >             but rather solely by *uniformity*: these same forms are
> >             permitted in function definitions:
> >
> >             f :: forall (a :: k). blah
> >             f @(((a::k1)::k2))) = ...
> >
> >             is permitted.
> >
> >             It imposes a change on Template Haskell syntax too.
> >
> >             The implementation becomes a bit more complicated; more
> >             recursive data types, etc.  Nothing hard, but more.
> >
> >             It's not a big deal either way.  Very few people expressed a
> >             view on GitHub.  My personal view is that the modest (albeit
> >             non-zero) gain does not justify the definite (albeit modest)
> >             pain. I would leave this until someone actually wants it.
> >
> >             Vlad argues for future-proofing, but my experience is that
> >             an eye to the future is sensible when you are making changes
> >             anyway; but making unforced changes solely for the future
> >             risks incurring pain now that, when the future comes, turns
> >             out to have been a poor investment.  We may have correctly
> >             anticipated, or we may not.
> >
> >             So my recommendation is to park this until we get a real
> >             user demand.
> >
> >             It's a perfectly sensible proposal, but adopting it is a
> >             judgement call. I'll leave a week for committee responses,
> >             and then we can just vote.
> >
> >             Simon
> >
> >             On Thu, 21 Mar 2024 at 08:07, Adam Gundry
> >             <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> >
> >                 Dear Committee,
> >
> >                 Vlad proposes to amend proposal #425 to permit more
> >                 wildcard binder
> >                 forms in type declarations:
> >
> >                 https://github.com/ghc-proposals/ghc-proposals/pull/641
> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/641
> >
> >
> >                 I'd like to nominate Simon PJ as the shepherd.
> >
> >                 Please guide us to a conclusion as outlined in
> >
> https://github.com/ghc-proposals/ghc-proposals#committee-process <
> https://github.com/ghc-proposals/ghc-proposals#committee-process>
> >
> >                 Cheers,
> >
> >                 Adam
> >
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20240328/cec30cb4/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar 28 15:18:23 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 28 Mar 2024 16:18:23 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CANsrgPLmpQtv5--zdcZU8dyK0ph-wK+nCgH_e+yP7bx8t=dFEw@mail.gmail.com>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.com>
 <b6d5a0a2-96c2-4a5f-86f0-8f6d74049761@well-typed.com>
 <CAGwnsn=RiywMWJwR0siR+NzSsBe8N7JggPx4mRc85Ch7N_q4VQ@mail.gmail.com>
 <wqxsvu3jw33vnikyu7o2iqjo2bftplske63irwteu2qxvycy43@hera.m-0.eu>
 <CAJKmMz9vEBjh0U88+DjSWxcKwMv7qq=4fAw5BcfH+Y7nAoyUCQ@mail.gmail.com>
 <CANsrgPJofwGi4-7fp0Zvm274gAxd-otKZXLMBrwgnvBV3Z1+tw@mail.gmail.com>
 <CAPxmXQznApR2N+EnwA9v6=HchVE1sCmdP0Xz7pC_ZJ-uVzDx_A@mail.gmail.com>
 <CAGwnsnk=fkOoyAxQSiMqxec9ML1ph8uqjod6VgmWOsFvM4QozQ@mail.gmail.com>
 <dkzxfuc3z3vnoq7logibg2qbgis7uwtrwptdzvw2sacrkjiz2z@hera.m-0.eu>
 <CAGwnsn=4VGb9az5HPzWzXu=Ngj=jvd0K9KKxZwFCJCLfy6DKKA@mail.gmail.com>
 <ecg5hqmsbaivhpkr4if7ta2wdwafh45mzqwp6mzicyveor4ygy@hera.m-0.eu>
 <CAGwnsn=zjOx3CRVZGaUfV_sP_FTDwkNFtXz4zXvnQHAD2bYRcA@mail.gmail.com>
 <CANsrgPLmpQtv5--zdcZU8dyK0ph-wK+nCgH_e+yP7bx8t=dFEw@mail.gmail.com>
Message-ID: <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>

@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>

From malte.ott at maralorn.de  Sat Mar 30 21:39:26 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Sat, 30 Mar 2024 22:39:26 +0100
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <9807ed75-a11b-40ee-aed8-cb3d024dd94a@well-typed.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
 <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>
 <CAGwnsnngDuAxqVY__i8ifL3sEdZhdA6Hq9KhC2ZFSb_kq0P4oQ@mail.gmail.com>
 <kcg5tp5qxa5zfi2xlyzebwn5ebnmp4vxd6hv33s4ckjlvffeo2@hera.m-0.eu>
 <CAJKmMz-atEf_rh2iztWA1NFG0xxq2pZaHTN8SY8e3_1Lb_2XHA@mail.gmail.com>
 <9807ed75-a11b-40ee-aed8-cb3d024dd94a@well-typed.com>
Message-ID: <inhnnvat6p5hjklq7tgwdh47u5z6lekdcewisonqa5jxyz6umm@hera.m-0.eu>


On 22/03/2024 18:19, Simon Peyton Jones wrote:
>      >From my understanding the biggest argument against this is the
>     change in
>     template-haskell?
> 
> 
> Not specifically.  My reservation is that
> 
>   * it's an unforced change,
>   * with no user demand
>   * but some real user impact (you mention TH)
>   * and some implementation cost (modest but very non-zero)
>   * aiming to anticipate as-yet-unknown future requirements
> 
> That's not a combination I like.  Pain now for possible (but uncertain)
> gain in the future.
> 
> I don't object to making types and terms behave similarly -- indeed I
> have invested lots of time working with Richard, Vlad, Andrei and others
> on proposals and MRs that move in this direction.  I'm just very
> unconvinced about *this *proposal.
> 
> One minor point.  In patterns we allow this:
> f ((,) @Int @[a] x y) = ...
> Here the type arguments are not type variables but full-blown types, and
> of course nested parens etc come "for free".  But this proposal concerns
> data type declarations in which we definitely don't want fulll-blown
> types. So it's more than a "terms and types should be the same"
> discussion.
> 
> Simon

I see. I admit that I don’t feel expert enough to know if this design will turn
out to be optimal.

If forced to voice an opinion I am still slightly in favor of the proposal.
Mainly because we have an implementor here who is motivated to implement this,
thus the implementation cost seems less problematic.

Best,
Malte

From simon.peytonjones at gmail.com  Sat Mar 30 21:54:57 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 30 Mar 2024 21:54:57 +0000
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <inhnnvat6p5hjklq7tgwdh47u5z6lekdcewisonqa5jxyz6umm@hera.m-0.eu>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAGwnsnmn-Xa7PCev_hz7J+XBNgEcynkVaeZZYMWKhZK-AEzbNA@mail.gmail.com>
 <CAJKmMz_HDUi+5fKmVFdx0NNFYHX1T_NVMGgOyNJ0Cq4kV0WvMA@mail.gmail.com>
 <CAGwnsnngDuAxqVY__i8ifL3sEdZhdA6Hq9KhC2ZFSb_kq0P4oQ@mail.gmail.com>
 <kcg5tp5qxa5zfi2xlyzebwn5ebnmp4vxd6hv33s4ckjlvffeo2@hera.m-0.eu>
 <CAJKmMz-atEf_rh2iztWA1NFG0xxq2pZaHTN8SY8e3_1Lb_2XHA@mail.gmail.com>
 <9807ed75-a11b-40ee-aed8-cb3d024dd94a@well-typed.com>
 <inhnnvat6p5hjklq7tgwdh47u5z6lekdcewisonqa5jxyz6umm@hera.m-0.eu>
Message-ID: <CAJKmMz9q=ooFEQMz5dn=SM7o6hqgVGDbkYW_WN=KqM86VS9h_w@mail.gmail.com>

If forced to voice an opinion I am still slightly in favor of the proposal.
Mainly because we have an implementor here who is motivated to implement
this,
thus the implementation cost seems less problematic.


It's best to imagine that implementation is free.  (If the implementation
is too costly, no one will do it, and the entire proposal becomes moot.)
What matters is the *maintenance *cost.  In ten years time when all the
current enthusiasts have moved on, our future selves will be working on the
implementation.

Here the additional complexity is not great.  But neither is the benefit.

Also let us remember the TH breakage.  That is a real cost, imposed on our
users.

I was originally pretty much on the fence, leaning to reject.  But the more
we discuss it, the more convinced I become that we should park this until
someone actually wants it.

Simon

On Sat, 30 Mar 2024 at 21:39, Malte Ott <malte.ott at maralorn.de> wrote:

>
> On 22/03/2024 18:19, Simon Peyton Jones wrote:
> >      >From my understanding the biggest argument against this is the
> >     change in
> >     template-haskell?
> >
> >
> > Not specifically.  My reservation is that
> >
> >   * it's an unforced change,
> >   * with no user demand
> >   * but some real user impact (you mention TH)
> >   * and some implementation cost (modest but very non-zero)
> >   * aiming to anticipate as-yet-unknown future requirements
> >
> > That's not a combination I like.  Pain now for possible (but uncertain)
> > gain in the future.
> >
> > I don't object to making types and terms behave similarly -- indeed I
> > have invested lots of time working with Richard, Vlad, Andrei and others
> > on proposals and MRs that move in this direction.  I'm just very
> > unconvinced about *this *proposal.
> >
> > One minor point.  In patterns we allow this:
> > f ((,) @Int @[a] x y) = ...
> > Here the type arguments are not type variables but full-blown types, and
> > of course nested parens etc come "for free".  But this proposal concerns
> > data type declarations in which we definitely don't want fulll-blown
> > types. So it's more than a "terms and types should be the same"
> > discussion.
> >
> > Simon
>
> I see. I admit that I don’t feel expert enough to know if this design will
> turn
> out to be optimal.
>
> If forced to voice an opinion I am still slightly in favor of the proposal.
> Mainly because we have an implementor here who is motivated to implement
> this,
> thus the implementation cost seems less problematic.
>
> Best,
> Malte
> _______________________________________________
> 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/20240330/b818cadc/attachment.html>