From simon.peytonjones at gmail.com  Tue Apr  2 16:25:12 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 2 Apr 2024 16:25:12 +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: <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>

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

See my mail below.   I recommend, fairly strongly, to park this until there
is evidence of need.

   - it's an unforced change,
   - with no user demand
   - but some real user impact (notably: it will break some TH users)
   - and some implementation cost (modest but very non-zero)
   - aiming to anticipate as-yet-unknown future requirements -- but YAGNI
   <https://martinfowler.com/bliki/Yagni.html>

I think it's time to vote.   Please so before Monday morning.  Thank you!

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/20240402/9a1b2425/attachment.html>

From malte.ott at maralorn.de  Tue Apr  2 18:47:48 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Tue, 2 Apr 2024 20:47:48 +0200
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
Message-ID: <p6axyx2hovalcwpvspqm2w74tpkoiz627zbdpiww7d5ma7thmy@hera.m-0.eu>

On 2024-04-02 16:25, Simon Peyton Jones wrote:
> Dear GHC 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
> 
> See my mail below.   I recommend, fairly strongly, to park this until there
> is evidence of need.
> 
>    - it's an unforced change,
>    - with no user demand
>    - but some real user impact (notably: it will break some TH users)
>    - and some implementation cost (modest but very non-zero)
>    - aiming to anticipate as-yet-unknown future requirements -- but YAGNI
>    <https://martinfowler.com/bliki/Yagni.html>
> 
> I think it's time to vote.   Please so before Monday morning.  Thank you!

Since my arguments in favor of the proposal convinced you of this position I am
fine with your recommendation, though mainly undecided.

Best
Malte

From adam at well-typed.com  Wed Apr  3 20:08:25 2024
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 3 Apr 2024 21:08:25 +0100
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAPxmXQxD3U2WJCTvOASFoxYK_oixNSvHn32K1swhHw_+4dUKFw@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>
 <CAPxmXQxD3U2WJCTvOASFoxYK_oixNSvHn32K1swhHw_+4dUKFw@mail.gmail.com>
Message-ID: <0f0a370b-135b-4921-a05f-9e4e5edeede3@well-typed.com>

I also agree that we should accept. We need some name for the unit 
unboxed tuple data constructor, and MkSolo# seems to fit with what we 
currently have.

Simon's suggestion that we rethink the naming of the tuple type 
constructors seems to be a separate question. I think it warrants a new 
proposal/amendment if anyone feels strongly enough, rather than blocking 
this proposal, especially given that the original proposal's type names 
are already implemented.

Adam


On 14/03/2024 10:33, Matthías Páll Gissurarson wrote:
> 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 <mailto: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 <mailto: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
>         <mailto: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 <mailto: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
>                 <mailto: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 <mailto:mpg at mpg.is>> wrote:
> 
>                         Greetings committee!
> 
>                         In
>                         [proposal #638](https://github.com/ghc-proposals/ghc-proposals/pull/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 <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/>


-- 
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  Sun Apr  7 21:18:19 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Sun, 7 Apr 2024 23:18:19 +0200
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <0f0a370b-135b-4921-a05f-9e4e5edeede3@well-typed.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>
 <CAPxmXQxD3U2WJCTvOASFoxYK_oixNSvHn32K1swhHw_+4dUKFw@mail.gmail.com>
 <0f0a370b-135b-4921-a05f-9e4e5edeede3@well-typed.com>
Message-ID: <CAPxmXQzDUX=XVtmrijm_QjVfFaob4OJdUJD1oaQJPK+DcHxBTg@mail.gmail.com>

There seems to be general consensus to accept the amendment, apart from
Simon's comment on a minor alternative.

Simon, are you OK with accepting the amendment, and leaving the minor
alternative to a future proposal?

On Wed, 3 Apr 2024 at 22:08, Adam Gundry <adam at well-typed.com> wrote:

> I also agree that we should accept. We need some name for the unit
> unboxed tuple data constructor, and MkSolo# seems to fit with what we
> currently have.
>
> Simon's suggestion that we rethink the naming of the tuple type
> constructors seems to be a separate question. I think it warrants a new
> proposal/amendment if anyone feels strongly enough, rather than blocking
> this proposal, especially given that the original proposal's type names
> are already implemented.
>
> Adam
>
>
> On 14/03/2024 10:33, Matthías Páll Gissurarson wrote:
> > 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 <mailto: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 <mailto: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
> >         <mailto: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 <mailto: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
> >                 <mailto: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 <mailto:mpg at mpg.is>> wrote:
> >
> >                         Greetings committee!
> >
> >                         In
> >                         [proposal #638](
> https://github.com/ghc-proposals/ghc-proposals/pull/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 <
> 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/>
>
>
> --
> 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
>


-- 
--  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/20240407/37acd2db/attachment.html>

From malte.ott at maralorn.de  Sun Apr  7 21:37:22 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Sun, 7 Apr 2024 23:37:22 +0200
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAPxmXQxwS9a1dnuaw9GudwL425mxrrbpS31eE9-vhKC__YpHtg@mail.gmail.com>
References: <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>
 <CAPxmXQxwS9a1dnuaw9GudwL425mxrrbpS31eE9-vhKC__YpHtg@mail.gmail.com>
Message-ID: <7xsam7fx5b6ozibkfbavww4wfqizdz2yuvt2oclpejkeuvhgkh@hera.m-0.eu>

Dear all,

I left this lingering for a bit in the hope a consensus might magically appear,
alas it didn’t.

We have consensus on accepting the proposal for the multiplicity annotations. 

For infix type operators I am now trying to convert previously voiced opinions
as faithfully as possible into votes:

Pro:

Eric, Malte, Chris, Matti

Con:

Adam, Arnaud

Undecided:

Simon PJ, Moritz, Simon M

Thus, as it stands we will accept the proposal as is, but it is close.
Please voice your opinion if you want to change your vote until Friday, I will
call the vote on the weekend.

Best
Malte

On 2024-03-21 17:46, Matthías Páll Gissurarson wrote:
> 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
> >

> _______________________________________________
> 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  Mon Apr  8 16:22:16 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 8 Apr 2024 17:22:16 +0100
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAPxmXQzDUX=XVtmrijm_QjVfFaob4OJdUJD1oaQJPK+DcHxBTg@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>
 <CAPxmXQxD3U2WJCTvOASFoxYK_oixNSvHn32K1swhHw_+4dUKFw@mail.gmail.com>
 <0f0a370b-135b-4921-a05f-9e4e5edeede3@well-typed.com>
 <CAPxmXQzDUX=XVtmrijm_QjVfFaob4OJdUJD1oaQJPK+DcHxBTg@mail.gmail.com>
Message-ID: <CAJKmMz_i5sXAUcAjRNXwn2MjKv5jcQvyTh8ex_HM==rg77JTCw@mail.gmail.com>

Simon, are you OK with accepting the amendment, and leaving the minor
alternative to a future proposal?


yes

Simon

On Sun, 7 Apr 2024 at 22:19, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

> There seems to be general consensus to accept the amendment, apart from
> Simon's comment on a minor alternative.
>
> Simon, are you OK with accepting the amendment, and leaving the minor
> alternative to a future proposal?
>
> On Wed, 3 Apr 2024 at 22:08, Adam Gundry <adam at well-typed.com> wrote:
>
>> I also agree that we should accept. We need some name for the unit
>> unboxed tuple data constructor, and MkSolo# seems to fit with what we
>> currently have.
>>
>> Simon's suggestion that we rethink the naming of the tuple type
>> constructors seems to be a separate question. I think it warrants a new
>> proposal/amendment if anyone feels strongly enough, rather than blocking
>> this proposal, especially given that the original proposal's type names
>> are already implemented.
>>
>> Adam
>>
>>
>> On 14/03/2024 10:33, Matthías Páll Gissurarson wrote:
>> > 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 <mailto: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 <mailto: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
>> >         <mailto: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 <mailto: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
>> >                 <mailto: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 <mailto:mpg at mpg.is>> wrote:
>> >
>> >                         Greetings committee!
>> >
>> >                         In
>> >                         [proposal #638](
>> https://github.com/ghc-proposals/ghc-proposals/pull/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 <
>> 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/>
>>
>>
>> --
>> 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
>>
>
>
> --
> --  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/20240408/7c9125ad/attachment.html>

From simon.peytonjones at gmail.com  Mon Apr  8 16:31:04 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 8 Apr 2024 17:31:04 +0100
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <7xsam7fx5b6ozibkfbavww4wfqizdz2yuvt2oclpejkeuvhgkh@hera.m-0.eu>
References: <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>
 <CAPxmXQxwS9a1dnuaw9GudwL425mxrrbpS31eE9-vhKC__YpHtg@mail.gmail.com>
 <7xsam7fx5b6ozibkfbavww4wfqizdz2yuvt2oclpejkeuvhgkh@hera.m-0.eu>
Message-ID: <CAJKmMz9uOa4Vxa-_O28fkJ-agA0PhDUgsatR5RW8qWR-c2qf3Q@mail.gmail.com>

I'm in favour of accepting as-is  -- that is, use left to right always.

It's encouraging that there was no breakage when compiling 3,337 packages.

Simon

On Sun, 7 Apr 2024 at 22:37, Malte Ott <malte.ott at maralorn.de> wrote:

> Dear all,
>
> I left this lingering for a bit in the hope a consensus might magically
> appear,
> alas it didn’t.
>
> We have consensus on accepting the proposal for the multiplicity
> annotations.
>
> For infix type operators I am now trying to convert previously voiced
> opinions
> as faithfully as possible into votes:
>
> Pro:
>
> Eric, Malte, Chris, Matti
>
> Con:
>
> Adam, Arnaud
>
> Undecided:
>
> Simon PJ, Moritz, Simon M
>
> Thus, as it stands we will accept the proposal as is, but it is close.
> Please voice your opinion if you want to change your vote until Friday, I
> will
> call the vote on the weekend.
>
> Best
> Malte
>
> On 2024-03-21 17:46, Matthías Páll Gissurarson wrote:
> > 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
> > >
>
> > _______________________________________________
> > 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/20240408/f0b11216/attachment-0001.html>

From mpg at mpg.is  Sun Apr 14 18:27:03 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Sun, 14 Apr 2024 20:27:03 +0200
Subject: [ghc-steering-committee] Proposal #638: Prefix form for MkSolo#
 (Recommend Accept)
In-Reply-To: <CAJKmMz_i5sXAUcAjRNXwn2MjKv5jcQvyTh8ex_HM==rg77JTCw@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>
 <CAPxmXQxD3U2WJCTvOASFoxYK_oixNSvHn32K1swhHw_+4dUKFw@mail.gmail.com>
 <0f0a370b-135b-4921-a05f-9e4e5edeede3@well-typed.com>
 <CAPxmXQzDUX=XVtmrijm_QjVfFaob4OJdUJD1oaQJPK+DcHxBTg@mail.gmail.com>
 <CAJKmMz_i5sXAUcAjRNXwn2MjKv5jcQvyTh8ex_HM==rg77JTCw@mail.gmail.com>
Message-ID: <CAPxmXQzsQuqU=RdkiuPbNkoYq+GRypm4TnbdOKH=Aop9ZehdWw@mail.gmail.com>

The amendment has been accepted, with the minor alternative left for a
future amendment.

On Mon, 8 Apr 2024 at 18:22, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Simon, are you OK with accepting the amendment, and leaving the minor
> alternative to a future proposal?
>
>
> yes
>
> Simon
>
> On Sun, 7 Apr 2024 at 22:19, Matthías Páll Gissurarson <mpg at mpg.is> wrote:
>
>> There seems to be general consensus to accept the amendment, apart from
>> Simon's comment on a minor alternative.
>>
>> Simon, are you OK with accepting the amendment, and leaving the minor
>> alternative to a future proposal?
>>
>> On Wed, 3 Apr 2024 at 22:08, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> I also agree that we should accept. We need some name for the unit
>>> unboxed tuple data constructor, and MkSolo# seems to fit with what we
>>> currently have.
>>>
>>> Simon's suggestion that we rethink the naming of the tuple type
>>> constructors seems to be a separate question. I think it warrants a new
>>> proposal/amendment if anyone feels strongly enough, rather than blocking
>>> this proposal, especially given that the original proposal's type names
>>> are already implemented.
>>>
>>> Adam
>>>
>>>
>>> On 14/03/2024 10:33, Matthías Páll Gissurarson wrote:
>>> > 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 <mailto: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 <mailto: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
>>> >         <mailto: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 <mailto: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
>>> >                 <mailto: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 <mailto:mpg at mpg.is>>
>>> wrote:
>>> >
>>> >                         Greetings committee!
>>> >
>>> >                         In
>>> >                         [proposal #638](
>>> https://github.com/ghc-proposals/ghc-proposals/pull/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 <
>>> 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/>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>> --
>> --  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
>>
>

-- 
--  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/20240414/6695831e/attachment.html>

From malte.ott at maralorn.de  Tue Apr 16 22:04:55 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Wed, 17 Apr 2024 00:04:55 +0200
Subject: [ghc-steering-committee] Please review #640: Fix quantification
 order for a `op` b and a %m -> b (Recommendation: Accept)
In-Reply-To: <CAJKmMz9uOa4Vxa-_O28fkJ-agA0PhDUgsatR5RW8qWR-c2qf3Q@mail.gmail.com>
References: <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>
 <CAPxmXQxwS9a1dnuaw9GudwL425mxrrbpS31eE9-vhKC__YpHtg@mail.gmail.com>
 <7xsam7fx5b6ozibkfbavww4wfqizdz2yuvt2oclpejkeuvhgkh@hera.m-0.eu>
 <CAJKmMz9uOa4Vxa-_O28fkJ-agA0PhDUgsatR5RW8qWR-c2qf3Q@mail.gmail.com>
Message-ID: <nnszl2dgwzjtpjib2ezwgatjdgu6jb4vnj5xa24l3uss66rxmn@hera.m-0.eu>

The vote is clear enough then and I have accepted the proposal. Thanks for the
discussion!

Best
Malte

On 2024-04-08 17:31, Simon Peyton Jones wrote:
> I'm in favour of accepting as-is  -- that is, use left to right always.
> 
> It's encouraging that there was no breakage when compiling 3,337 packages.
> 
> Simon
> 
> On Sun, 7 Apr 2024 at 22:37, Malte Ott <malte.ott at maralorn.de> wrote:
> 
> > Dear all,
> >
> > I left this lingering for a bit in the hope a consensus might magically
> > appear,
> > alas it didn’t.
> >
> > We have consensus on accepting the proposal for the multiplicity
> > annotations.
> >
> > For infix type operators I am now trying to convert previously voiced
> > opinions
> > as faithfully as possible into votes:
> >
> > Pro:
> >
> > Eric, Malte, Chris, Matti
> >
> > Con:
> >
> > Adam, Arnaud
> >
> > Undecided:
> >
> > Simon PJ, Moritz, Simon M
> >
> > Thus, as it stands we will accept the proposal as is, but it is close.
> > Please voice your opinion if you want to change your vote until Friday, I
> > will
> > call the vote on the weekend.
> >
> > Best
> > Malte
> >
> > On 2024-03-21 17:46, Matthías Páll Gissurarson wrote:
> > > 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
> > > >
> >
> > > _______________________________________________
> > > 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  Fri Apr 19 10:15:20 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 19 Apr 2024 11:15:20 +0100
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
Message-ID: <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>

 Dear GHC Steering Committee

On 2 April I asked:

I think it's time to vote.   Please so before Monday morning *[8 April]*.
> Thank you!



*It is now 19 April, of the eight members of the committee only Malte has
voted. *

Please please vote.  Today!   Use email and record your vote on the
spreadsheet
<https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
Vlad you have a vote; since you are the proposer you may choose to abstain
but I think it's up to you.

The proposal isn't a huge deal either way, but we owe it to the proposer
and to ourselves to deal with our business in a timely way.

Simon

On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Dear GHC 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
>
> See my mail below.   I recommend, fairly strongly, to park this until
> there is evidence of need.
>
>    - it's an unforced change,
>    - with no user demand
>    - but some real user impact (notably: it will break some TH users)
>    - and some implementation cost (modest but very non-zero)
>    - aiming to anticipate as-yet-unknown future requirements -- but YAGNI
>    <https://martinfowler.com/bliki/Yagni.html>
>
> I think it's time to vote.   Please so before Monday morning.  Thank you!
>
> 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/20240419/e897e331/attachment.html>

From vlad.z.4096 at gmail.com  Fri Apr 19 10:45:48 2024
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Fri, 19 Apr 2024 12:45:48 +0200
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
 <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
Message-ID: <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>

I don't think I have a vote, as my term has ended. Even if I had one, I'd
abstain because it is my amendment.

However, I'd like to point out two things.

1. If the proposed amendment is rejected, we /still/ have to change
template-haskell to implement 425 in its current form. The specification
allows invisible wildcards `@_`, which can't be represented in
template-haskell at the moment. So I'd like to ask voting members to take
that into consideration: this is not an "unforced change" because there is
a change coming either way.

2. Simon argues against a new recursive data type in the AST. OK, I can see
the problem, but please don't forget about non-recursive forms `type T _ =
rhs` and `type T (_ :: k) = rhs`. Even if there is no user demand for
nested forms like `type T ((_ :: k1) :: k2) = rhs`, flat wildcard binders
are a less intrusive addition and I've personally wanted them several
times. So if the problem is recursion, please consider sending the
amendment for revision instead of rejecting it.

Thus the voting options should probably be:

a) accept the amendment
b) revise the amendment to avoid recursive/nested forms
c) reject the amendment

Vlad

On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC Steering Committee
>
> On 2 April I asked:
>
> I think it's time to vote.   Please so before Monday morning *[8 April]*.
>> Thank you!
>
>
>
> *It is now 19 April, of the eight members of the committee only Malte has
> voted. *
>
> Please please vote.  Today!   Use email and record your vote on the
> spreadsheet
> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
> Vlad you have a vote; since you are the proposer you may choose to abstain
> but I think it's up to you.
>
> The proposal isn't a huge deal either way, but we owe it to the proposer
> and to ourselves to deal with our business in a timely way.
>
> Simon
>
> On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC 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
>>
>> See my mail below.   I recommend, fairly strongly, to park this until
>> there is evidence of need.
>>
>>    - it's an unforced change,
>>    - with no user demand
>>    - but some real user impact (notably: it will break some TH users)
>>    - and some implementation cost (modest but very non-zero)
>>    - aiming to anticipate as-yet-unknown future requirements -- but YAGNI
>>    <https://martinfowler.com/bliki/Yagni.html>
>>
>> I think it's time to vote.   Please so before Monday morning.  Thank you!
>>
>> 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/20240419/64adcd70/attachment-0001.html>

From mpg at mpg.is  Fri Apr 19 11:28:27 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Fri, 19 Apr 2024 13:28:27 +0200
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
 <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
 <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>
Message-ID: <CAPxmXQzMrp3jZQy6tO2m5ykcRn-rMU1=bZ3grXq2tVzYThPZcg@mail.gmail.com>

I don’t seem to have write access to that sheet, but I’ve requested it now.

I was on the fence here, and would have voted to park it until it was
requested. But as int-index points out, a breaking change to TH is on the
way anyway, and it would be good to improve the completeness at the same
time.

So I vote accept (mildly)

/Matti Palli


On Fri, Apr 19, 2024 at 12:45 Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> I don't think I have a vote, as my term has ended. Even if I had one, I'd
> abstain because it is my amendment.
>
> However, I'd like to point out two things.
>
> 1. If the proposed amendment is rejected, we /still/ have to change
> template-haskell to implement 425 in its current form. The specification
> allows invisible wildcards `@_`, which can't be represented in
> template-haskell at the moment. So I'd like to ask voting members to take
> that into consideration: this is not an "unforced change" because there is
> a change coming either way.
>
> 2. Simon argues against a new recursive data type in the AST. OK, I can
> see the problem, but please don't forget about non-recursive forms `type T
> _ = rhs` and `type T (_ :: k) = rhs`. Even if there is no user demand for
> nested forms like `type T ((_ :: k1) :: k2) = rhs`, flat wildcard binders
> are a less intrusive addition and I've personally wanted them several
> times. So if the problem is recursion, please consider sending the
> amendment for revision instead of rejecting it.
>
> Thus the voting options should probably be:
>
> a) accept the amendment
> b) revise the amendment to avoid recursive/nested forms
> c) reject the amendment
>
> Vlad
>
> On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC Steering Committee
>>
>> On 2 April I asked:
>>
>> I think it's time to vote.   Please so before Monday morning *[8 April]*.
>>> Thank you!
>>
>>
>>
>> *It is now 19 April, of the eight members of the committee only Malte has
>> voted. *
>>
>> Please please vote.  Today!   Use email and record your vote on the
>> spreadsheet
>> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
>> Vlad you have a vote; since you are the proposer you may choose to abstain
>> but I think it's up to you.
>>
>> The proposal isn't a huge deal either way, but we owe it to the proposer
>> and to ourselves to deal with our business in a timely way.
>>
>> Simon
>>
>> On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear GHC 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
>>>
>>> See my mail below.   I recommend, fairly strongly, to park this until
>>> there is evidence of need.
>>>
>>>    - it's an unforced change,
>>>    - with no user demand
>>>    - but some real user impact (notably: it will break some TH users)
>>>    - and some implementation cost (modest but very non-zero)
>>>    - aiming to anticipate as-yet-unknown future requirements -- but
>>>    YAGNI <https://martinfowler.com/bliki/Yagni.html>
>>>
>>> I think it's time to vote.   Please so before Monday morning.  Thank you!
>>>
>>> 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
>>>>> <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
>>
> _______________________________________________
> 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/20240419/4d6559e5/attachment.html>

From arnaud.spiwack at tweag.io  Fri Apr 19 12:40:13 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 19 Apr 2024 14:40:13 +0200
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAPxmXQzMrp3jZQy6tO2m5ykcRn-rMU1=bZ3grXq2tVzYThPZcg@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
 <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
 <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>
 <CAPxmXQzMrp3jZQy6tO2m5ykcRn-rMU1=bZ3grXq2tVzYThPZcg@mail.gmail.com>
Message-ID: <CAGwnsnnGYKCds-Fu_H0Ax_LR9vT-HgZsUYnMhnWJWYydeE+F1A@mail.gmail.com>

As per my earlier email, I have very little opinion about that, and I'm
happy to follow Simon's recommendation.

On Fri, 19 Apr 2024 at 13:28, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

> I don’t seem to have write access to that sheet, but I’ve requested it now.
>
> I was on the fence here, and would have voted to park it until it was
> requested. But as int-index points out, a breaking change to TH is on the
> way anyway, and it would be good to improve the completeness at the same
> time.
>
> So I vote accept (mildly)
>
> /Matti Palli
>
>
> On Fri, Apr 19, 2024 at 12:45 Vladislav Zavialov <vlad.z.4096 at gmail.com>
> wrote:
>
>> I don't think I have a vote, as my term has ended. Even if I had one, I'd
>> abstain because it is my amendment.
>>
>> However, I'd like to point out two things.
>>
>> 1. If the proposed amendment is rejected, we /still/ have to change
>> template-haskell to implement 425 in its current form. The specification
>> allows invisible wildcards `@_`, which can't be represented in
>> template-haskell at the moment. So I'd like to ask voting members to take
>> that into consideration: this is not an "unforced change" because there is
>> a change coming either way.
>>
>> 2. Simon argues against a new recursive data type in the AST. OK, I can
>> see the problem, but please don't forget about non-recursive forms `type T
>> _ = rhs` and `type T (_ :: k) = rhs`. Even if there is no user demand for
>> nested forms like `type T ((_ :: k1) :: k2) = rhs`, flat wildcard binders
>> are a less intrusive addition and I've personally wanted them several
>> times. So if the problem is recursion, please consider sending the
>> amendment for revision instead of rejecting it.
>>
>> Thus the voting options should probably be:
>>
>> a) accept the amendment
>> b) revise the amendment to avoid recursive/nested forms
>> c) reject the amendment
>>
>> Vlad
>>
>> On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear GHC Steering Committee
>>>
>>> On 2 April I asked:
>>>
>>> I think it's time to vote.   Please so before Monday morning *[8 April]*.
>>>> Thank you!
>>>
>>>
>>>
>>> *It is now 19 April, of the eight members of the committee only Malte
>>> has voted. *
>>>
>>> Please please vote.  Today!   Use email and record your vote on the
>>> spreadsheet
>>> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
>>> Vlad you have a vote; since you are the proposer you may choose to abstain
>>> but I think it's up to you.
>>>
>>> The proposal isn't a huge deal either way, but we owe it to the proposer
>>> and to ourselves to deal with our business in a timely way.
>>>
>>> Simon
>>>
>>> On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Dear GHC 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
>>>>
>>>> See my mail below.   I recommend, fairly strongly, to park this until
>>>> there is evidence of need.
>>>>
>>>>    - it's an unforced change,
>>>>    - with no user demand
>>>>    - but some real user impact (notably: it will break some TH users)
>>>>    - and some implementation cost (modest but very non-zero)
>>>>    - aiming to anticipate as-yet-unknown future requirements -- but
>>>>    YAGNI <https://martinfowler.com/bliki/Yagni.html>
>>>>
>>>> I think it's time to vote.   Please so before Monday morning.  Thank
>>>> you!
>>>>
>>>> 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
>>>>>> <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
>>>
>> _______________________________________________
>> 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/20240419/73f09d17/attachment.html>

From chris at chrisdornan.com  Fri Apr 19 13:51:05 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 19 Apr 2024 14:51:05 +0100
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#343)
In-Reply-To: <CAGwnsn=YLY4ynSBmC=5b39kL_2aMiqRP4cRmrHfQUmtVFNz=8w@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>
 <CAGwnsn=YLY4ynSBmC=5b39kL_2aMiqRP4cRmrHfQUmtVFNz=8w@mail.gmail.com>
Message-ID: <C698E21E-6DB1-43DA-B55F-820517891E7E@chrisdornan.com>

There have been no objections to this (fine-grained warnings) proposal which has been broadly supported through a couple of rounds of voting so I have marked it and marked it as accepted.

Thanks everyone.

Chris

> On 14 Mar 2024, at 07:58, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I'm in favour.
> 
> On Wed, 13 Mar 2024 at 08:50, Moritz Angermann <moritz.angermann at gmail.com <mailto: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 <mailto: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 <mailto: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 <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 <mailto: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 <https://moduscreate.com/> and https://tweag.io <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/20240419/29fb4acd/attachment-0001.html>

From marlowsd at gmail.com  Fri Apr 19 15:46:02 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 19 Apr 2024 16:46:02 +0100
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
Message-ID: <CANsrgP+Bwn38VWF1Nb9yQbkF5YXgN2Xs4jizx3KqcX6+4gDHog@mail.gmail.com>

I voted to park, as per Simon's recommendation (although if it comes up
again I would be against unless it can be made a non-breaking change
perhaps by using Adam's suggestion of pattern synonyms).

Cheers
Simon

On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Dear GHC 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
>
> See my mail below.   I recommend, fairly strongly, to park this until
> there is evidence of need.
>
>    - it's an unforced change,
>    - with no user demand
>    - but some real user impact (notably: it will break some TH users)
>    - and some implementation cost (modest but very non-zero)
>    - aiming to anticipate as-yet-unknown future requirements -- but YAGNI
>    <https://martinfowler.com/bliki/Yagni.html>
>
> I think it's time to vote.   Please so before Monday morning.  Thank you!
>
> 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/20240419/5e23c960/attachment.html>

From malte.ott at maralorn.de  Fri Apr 19 15:59:39 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Fri, 19 Apr 2024 17:59:39 +0200
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
 <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
 <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>
Message-ID: <yq2tctyc4nqyeoctgem7zhhixqu5itith6lzy5p4crovmcbvwf@hera.m-0.eu>

Thanks for the input Vlad. Regarding the breaking change to TH:
Do I understand you correctly that the required changes from 425 have not landed
in 9.10 and therefor accepting this proposal will not create anymore breakage,
even between 9.10 and 9.12?

If that’s the case then I am in favor of this proposal precisely to prevent the
need to change this again in the future.

I have no opinion on the recursion and am fine either way.

On 2024-04-19 12:45, Vladislav Zavialov wrote:
> I don't think I have a vote, as my term has ended. Even if I had one, I'd
> abstain because it is my amendment.
> 
> However, I'd like to point out two things.
> 
> 1. If the proposed amendment is rejected, we /still/ have to change
> template-haskell to implement 425 in its current form. The specification
> allows invisible wildcards `@_`, which can't be represented in
> template-haskell at the moment. So I'd like to ask voting members to take
> that into consideration: this is not an "unforced change" because there is
> a change coming either way.
> 
> 2. Simon argues against a new recursive data type in the AST. OK, I can see
> the problem, but please don't forget about non-recursive forms `type T _ =
> rhs` and `type T (_ :: k) = rhs`. Even if there is no user demand for
> nested forms like `type T ((_ :: k1) :: k2) = rhs`, flat wildcard binders
> are a less intrusive addition and I've personally wanted them several
> times. So if the problem is recursion, please consider sending the
> amendment for revision instead of rejecting it.
> 
> Thus the voting options should probably be:
> 
> a) accept the amendment
> b) revise the amendment to avoid recursive/nested forms
> c) reject the amendment
> 
> Vlad
> 
> On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> 
> > Dear GHC Steering Committee
> >
> > On 2 April I asked:
> >
> > I think it's time to vote.   Please so before Monday morning *[8 April]*.
> >> Thank you!
> >
> >
> >
> > *It is now 19 April, of the eight members of the committee only Malte has
> > voted. *
> >
> > Please please vote.  Today!   Use email and record your vote on the
> > spreadsheet
> > <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
> > Vlad you have a vote; since you are the proposer you may choose to abstain
> > but I think it's up to you.
> >
> > The proposal isn't a huge deal either way, but we owe it to the proposer
> > and to ourselves to deal with our business in a timely way.
> >
> > Simon
> >
> > On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <
> > simon.peytonjones at gmail.com> wrote:
> >
> >> Dear GHC 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
> >>
> >> See my mail below.   I recommend, fairly strongly, to park this until
> >> there is evidence of need.
> >>
> >>    - it's an unforced change,
> >>    - with no user demand
> >>    - but some real user impact (notably: it will break some TH users)
> >>    - and some implementation cost (modest but very non-zero)
> >>    - aiming to anticipate as-yet-unknown future requirements -- but YAGNI
> >>    <https://martinfowler.com/bliki/Yagni.html>
> >>
> >> I think it's time to vote.   Please so before Monday morning.  Thank you!
> >>
> >> 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
> >

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


From vlad.z.4096 at gmail.com  Fri Apr 19 16:17:27 2024
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Fri, 19 Apr 2024 18:17:27 +0200
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <yq2tctyc4nqyeoctgem7zhhixqu5itith6lzy5p4crovmcbvwf@hera.m-0.eu>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
 <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
 <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>
 <yq2tctyc4nqyeoctgem7zhhixqu5itith6lzy5p4crovmcbvwf@hera.m-0.eu>
Message-ID: <CAHZ0NLo6ELnr=0H0qUGYVfdwfxs=B1zA48+11rt02WNiKGs_2A@mail.gmail.com>

That's exactly right. We are not choosing between change / no change, we
are choosing between three possible changes:

1. Current proposal: only add support for @_
2. Amendment sans recursion (if revised): add support for @_, @(_ :: k), _,
and (_ :: k)
3. Amendment with recursion: add support for arbitrary combinations of @,
_, ::, and ( ... )

It's going to be breaking in all three scenarios, unless we come up with a
compatibility layer using pattern synonyms as Adam suggests (I have not
investigated the feasibility of that).

Vlad

On Fri, Apr 19, 2024 at 5:59 PM Malte Ott <malte.ott at maralorn.de> wrote:

> Thanks for the input Vlad. Regarding the breaking change to TH:
> Do I understand you correctly that the required changes from 425 have not
> landed
> in 9.10 and therefor accepting this proposal will not create anymore
> breakage,
> even between 9.10 and 9.12?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240419/9c06fad6/attachment-0001.html>

From eric at seidel.io  Sun Apr 21 18:13:37 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 21 Apr 2024 13:13:37 -0500
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
 <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
Message-ID: <1c3c7bd4-0fcd-4335-b726-74fac0d16345@app.fastmail.com>

This feels like a reasonable generalization, assuming the it doesn't raise any
serious implementation concerns. I'll trust Simon PJ above that it doesn't.

I also agree that an unforced change like this should preferably be bundled
alongside some other motivated change.

I think that still means that *we should accept the proposal*, but the GHC
devs can make a reasoned decision about *when* to implement the change.

On Fri, Apr 19, 2024, at 05:15, Simon Peyton Jones wrote:
> Dear GHC Steering Committee
>
> On 2 April I asked:
>
>> I think it's time to vote.   Please so before Monday morning *[8 April]*.  Thank you!
>
> *It is now 19 April, of the eight members of the committee only Malte 
> has voted. 
> *
>
> Please please vote.  Today!   Use email and record your vote on the 
> spreadsheet 
> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>. 
>  Vlad you have a vote; since you are the proposer you may choose to 
> abstain but I think it's up to you.
>
> The proposal isn't a huge deal either way, but we owe it to the 
> proposer and to ourselves to deal with our business in a timely way.
>
> Simon 
>
> On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones 
> <simon.peytonjones at gmail.com> wrote:
>> Dear GHC 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
>> 
>> See my mail below.   I recommend, fairly strongly, to park this until there is evidence of need.
>>  • it's an unforced change, 
>>  • with no user demand
>>  • but some real user impact (notably: it will break some TH users)
>>  • and some implementation cost (modest but very non-zero)
>>  • aiming to anticipate as-yet-unknown future requirements -- but YAGNI <https://martinfowler.com/bliki/Yagni.html>
>> I think it's time to vote.   Please so before Monday morning.  Thank you!
>> 
>> 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

From arnaud.spiwack at tweag.io  Mon Apr 22 14:15:00 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 22 Apr 2024 16:15:00 +0200
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
Message-ID: <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>

Ok, so, after an extended period of time (which, obviously, is my fault),
we essentially have one option per opinion (well, I guess 3a and 4 have
two, but that's not really what consensus is like). Simon, the other day,
advised me to reduce the number of choices based on Shea's preferences. I
decided to not include Shea's original proposal of doing the backward
incompatible change without extension as I believe that it is contrary to
the spirit of the language editions and all that.

*I'm calling for a vote* on the three following options. As per our
customs, this is preference voting please order the following options. If
you want to vote against an option, rank it after “That's it” (or omit it
altogether). Explanation of the summary below

I'm leaving the vote open until *Wednesday 1st May*. After which, I'll
tally, and synthesise the committee's final position.

2. [Summary: 00WWWN] No change in behaviour, just add a warning when `main`
has a type that isn't `main :: IO ()` or `main :: IO Void`, very much
including `main :: IO ExitCode` (Shae's second favourite alternative)
3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added as
in 2, but, additionally, an extension is introduced. When the extension is
turned on, we always call the proposed `ExitStatus` type class on the
returned value to determine the program's exit code. (Shae's favourite
alternative)
4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
introduced, but an extension is. When the extension is turned on,
everything is as today, except when `main :: IO ExitCode`, in which case we
program's exit code is the exit code returned by `main` (Simon PJ's
favourite)
That's it

------

The summaries are based on the following examples. Each get a letter
representing the behaviour under the proposal, as described in the legend

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

The 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.
- I: The exit code is the returned value (only apply to `main :: IO
ExitCode`).
- N: not available under this alternative

On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

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


-- 
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/20240422/ddad7622/attachment.html>

From mpg at mpg.is  Mon Apr 22 14:30:25 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Mon, 22 Apr 2024 16:30:25 +0200
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
Message-ID: <CAPxmXQwgqQU+tQRhERfvBHKHeyycjBFsQQqoux8qerPXH9Wb2A@mail.gmail.com>

My ranking is

4
3a
2

That’s it.


/Matti Palli


On Mon, Apr 22, 2024 at 16:15 Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Ok, so, after an extended period of time (which, obviously, is my fault),
> we essentially have one option per opinion (well, I guess 3a and 4 have
> two, but that's not really what consensus is like). Simon, the other day,
> advised me to reduce the number of choices based on Shea's preferences. I
> decided to not include Shea's original proposal of doing the backward
> incompatible change without extension as I believe that it is contrary to
> the spirit of the language editions and all that.
>
> *I'm calling for a vote* on the three following options. As per our
> customs, this is preference voting please order the following options. If
> you want to vote against an option, rank it after “That's it” (or omit it
> altogether). Explanation of the summary below
>
> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll
> tally, and synthesise the committee's final position.
>
> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when
> `main` has a type that isn't `main :: IO ()` or `main :: IO Void`, very
> much including `main :: IO ExitCode` (Shae's second favourite alternative)
> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added as
> in 2, but, additionally, an extension is introduced. When the extension is
> turned on, we always call the proposed `ExitStatus` type class on the
> returned value to determine the program's exit code. (Shae's favourite
> alternative)
> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
> introduced, but an extension is. When the extension is turned on,
> everything is as today, except when `main :: IO ExitCode`, in which case we
> program's exit code is the exit code returned by `main` (Simon PJ's
> favourite)
> That's it
>
> ------
>
> The summaries are based on the following examples. Each get a letter
> representing the behaviour under the proposal, as described in the legend
>
> The 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 ... }
>
> The 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.
> - I: The exit code is the returned value (only apply to `main :: IO
> ExitCode`).
> - N: not available under this alternative
>
> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> @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.
>>
>
>
> --
> 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/20240422/71aad2a1/attachment-0001.html>

From arnaud.spiwack at tweag.io  Mon Apr 22 15:11:21 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 22 Apr 2024 17:11:21 +0200
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAPxmXQwgqQU+tQRhERfvBHKHeyycjBFsQQqoux8qerPXH9Wb2A@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
 <CAPxmXQwgqQU+tQRhERfvBHKHeyycjBFsQQqoux8qerPXH9Wb2A@mail.gmail.com>
Message-ID: <CAGwnsnnSaAecmZy7EHF2R-OZr58Oe9OpoFfTT8x9Z7iTiD0yfw@mail.gmail.com>

I forgot to vote. Great job me!

Here's my vote:

3a
2
That's it.

On Mon, 22 Apr 2024 at 16:30, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

> My ranking is
>
> 4
> 3a
> 2
>
> That’s it.
>
>
> /Matti Palli
>
>
> On Mon, Apr 22, 2024 at 16:15 Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Ok, so, after an extended period of time (which, obviously, is my fault),
>> we essentially have one option per opinion (well, I guess 3a and 4 have
>> two, but that's not really what consensus is like). Simon, the other day,
>> advised me to reduce the number of choices based on Shea's preferences. I
>> decided to not include Shea's original proposal of doing the backward
>> incompatible change without extension as I believe that it is contrary to
>> the spirit of the language editions and all that.
>>
>> *I'm calling for a vote* on the three following options. As per our
>> customs, this is preference voting please order the following options. If
>> you want to vote against an option, rank it after “That's it” (or omit it
>> altogether). Explanation of the summary below
>>
>> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll
>> tally, and synthesise the committee's final position.
>>
>> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when
>> `main` has a type that isn't `main :: IO ()` or `main :: IO Void`, very
>> much including `main :: IO ExitCode` (Shae's second favourite alternative)
>> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added
>> as in 2, but, additionally, an extension is introduced. When the extension
>> is turned on, we always call the proposed `ExitStatus` type class on the
>> returned value to determine the program's exit code. (Shae's favourite
>> alternative)
>> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
>> introduced, but an extension is. When the extension is turned on,
>> everything is as today, except when `main :: IO ExitCode`, in which case we
>> program's exit code is the exit code returned by `main` (Simon PJ's
>> favourite)
>> That's it
>>
>> ------
>>
>> The summaries are based on the following examples. Each get a letter
>> representing the behaviour under the proposal, as described in the legend
>>
>> The 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 ... }
>>
>> The 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.
>> - I: The exit code is the returned value (only apply to `main :: IO
>> ExitCode`).
>> - N: not available under this alternative
>>
>> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> @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.
>>>
>>
>>
>> --
>> 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/20240422/e5fe05d5/attachment.html>

From eric at seidel.io  Mon Apr 22 17:02:54 2024
From: eric at seidel.io (Eric Seidel)
Date: Mon, 22 Apr 2024 12:02:54 -0500
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
Message-ID: <97797dba-4cf6-4aa1-a76d-434c6167f9a0@app.fastmail.com>

I don't feel strongly about this, but here's my vote

3a
4
that's it

On Mon, Apr 22, 2024, at 09:15, Arnaud Spiwack wrote:
> Ok, so, after an extended period of time (which, obviously, is my 
> fault), we essentially have one option per opinion (well, I guess 3a 
> and 4 have two, but that's not really what consensus is like). Simon, 
> the other day, advised me to reduce the number of choices based on 
> Shea's preferences. I decided to not include Shea's original proposal 
> of doing the backward incompatible change without extension as I 
> believe that it is contrary to the spirit of the language editions and 
> all that.
>
> *I'm calling for a vote* on the three following options. As per our 
> customs, this is preference voting please order the following options. 
> If you want to vote against an option, rank it after “That's it” (or 
> omit it altogether). Explanation of the summary below
>
> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll 
> tally, and synthesise the committee's final position.
>
> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when 
> `main` has a type that isn't `main :: IO ()` or `main :: IO Void`, very 
> much including `main :: IO ExitCode` (Shae's second favourite 
> alternative)
> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added 
> as in 2, but, additionally, an extension is introduced. When the 
> extension is turned on, we always call the proposed `ExitStatus` type 
> class on the returned value to determine the program's exit code. 
> (Shae's favourite alternative)
> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is 
> introduced, but an extension is. When the extension is turned on, 
> everything is as today, except when `main :: IO ExitCode`, in which 
> case we program's exit code is the exit code returned by `main` (Simon 
> PJ's favourite)
> That's it
>
> ------
>
> The summaries are based on the following examples. Each get a letter 
> representing the behaviour under the proposal, as described in the 
> legend
>
> The 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 ... }
>
> The 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.
> - I: The exit code is the returned value (only apply to `main :: IO ExitCode`).
> - N: not available under this alternative
>
> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>> @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.
>
>
> -- 
> 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 adam at well-typed.com  Mon Apr 22 20:04:29 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 22 Apr 2024 21:04:29 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
References: <CAGwnsnmKgT6XLagydbM95g2Maq-pzRnF7tuym_hF96OUOLcXsA@mail.gmail.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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
Message-ID: <5415ff5a-c60d-4cfe-8ad3-196cb6530946@well-typed.com>

I vote:

2
3a
That's it

on the basis articulated in 
https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1985236743. 
Adding a warning solves the problem of GHC surprising users by ignoring 
`main :: IO ExitCode`. Adding an extension for a tiny bit of convenience 
seems undermotivated IMHO, and I agree that making the change without 
extension is unjustified.

I'm very sceptical of 4, because it introduces an extension that 
approximately nobody will think to use (and if it gets turned on by 
default at some point, we risk significant confusion with `main :: IO 
ExitCode` quietly doing different things on different language editions).

Adam


On 22/04/2024 15:15, Arnaud Spiwack wrote:
> Ok, so, after an extended period of time (which, obviously, is my 
> fault), we essentially have one option per opinion (well, I guess 3a and 
> 4 have two, but that's not really what consensus is like). Simon, the 
> other day, advised me to reduce the number of choices based on Shea's 
> preferences. I decided to not include Shea's original proposal of doing 
> the backward incompatible change without extension as I believe that it 
> is contrary to the spirit of the language editions and all that.
> 
> *I'm calling for a vote* on the three following options. As per our 
> customs, this is preference voting please order the following options. 
> If you want to vote against an option, rank it after “That's it” (or 
> omit it altogether). Explanation of the summary below
> 
> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll 
> tally, and synthesise the committee's final position.
> 
> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when 
> `main` has a type that isn't `main :: IO ()` or `main :: IO Void`, very 
> much including `main :: IO ExitCode` (Shae's second favourite alternative)
> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added 
> as in 2, but, additionally, an extension is introduced. When the 
> extension is turned on, we always call the proposed `ExitStatus` type 
> class on the returned value to determine the program's exit code. 
> (Shae's favourite alternative)
> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is 
> introduced, but an extension is. When the extension is turned on, 
> everything is as today, except when `main :: IO ExitCode`, in which case 
> we program's exit code is the exit code returned by `main` (Simon PJ's 
> favourite)
> That's it
> 
> ------
> 
> The summaries are based on the following examples. Each get a letter 
> representing the behaviour under the proposal, as described in the legend
> 
> The 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 ... }
> 
> The 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.
> - I: The exit code is the returned value (only apply to `main :: IO 
> ExitCode`).
> - N: not available under this alternative
> 
> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io 
> <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>     @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
>     <mailto: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 <mailto: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 <mailto: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
>                 _______________________________________________


-- 
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  Mon Apr 22 20:11:48 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 22 Apr 2024 21:11:48 +0100
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CANsrgPJAqE2bS=yK+ZFhGgR+AyQMk=X1=0AkvLdQzDmo5r_8Pw@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>
 <CANsrgPJAqE2bS=yK+ZFhGgR+AyQMk=X1=0AkvLdQzDmo5r_8Pw@mail.gmail.com>
Message-ID: <70b22f40-961e-40c9-bcb0-dc4374d927b7@well-typed.com>

Apologies for the delay in following up on this. It seems there is a 
general sentiment that we should bump the default to GHC2024 in a future 
release. I'm planning to revise the amendment to reflect this, but I've 
been lacking cycles to do so, thus I've moved the PR to "needs revision" 
status for now.

Adam


On 22/03/2024 15:42, Simon Marlow wrote:
> 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 
> <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 adam at well-typed.com  Mon Apr 22 20:26:48 2024
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 22 Apr 2024 21:26:48 +0100
Subject: [ghc-steering-committee] Please review #641: Wildcard binders
 in type declarations
In-Reply-To: <CAHZ0NLo6ELnr=0H0qUGYVfdwfxs=B1zA48+11rt02WNiKGs_2A@mail.gmail.com>
References: <18459608-c6d2-42d1-bdae-f14c973e4592@well-typed.com>
 <CAJKmMz89Ab+w+dMnjX2pfGrj-M1hLgC+w6vJhTucyG9OcOvH1Q@mail.gmail.com>
 <CAJKmMz_HauwSPomVNOcKNcFhgxXEbdXmHFxtgJ8z+PrsAa21ww@mail.gmail.com>
 <CAJKmMz8Mm3fovvoyQ5n=AR9Y18vfAusWyLzzvRcuKyK=QMMnFg@mail.gmail.com>
 <CAHZ0NLqijV93xG9o3fcpGRk5LZffUzLpSb6_kobrPupd6mwNgw@mail.gmail.com>
 <yq2tctyc4nqyeoctgem7zhhixqu5itith6lzy5p4crovmcbvwf@hera.m-0.eu>
 <CAHZ0NLo6ELnr=0H0qUGYVfdwfxs=B1zA48+11rt02WNiKGs_2A@mail.gmail.com>
Message-ID: <9833566f-e73a-40fd-9a13-0b2e645b59a9@well-typed.com>

I find Vlad's argument convincing: if we are already adding support for 
@_ then at the very least it's worth adding _ at the same time, and it 
seems to involve no more breakage or implementation cost than #425 
unamended. So I vote to accept.

I'm on the fence as to whether to prefer the recursive version (more 
general and consistent with term syntax) or the non-recursive version 
(since it is simpler, and in practice the more general forms seem 
unlikely to be useful).

Adam


On 19/04/2024 17:17, Vladislav Zavialov wrote:
> That's exactly right. We are not choosing between change / no change, we 
> are choosing between three possible changes:
> 
> 1. Current proposal: only add support for @_
> 2. Amendment sans recursion (if revised): add support for @_, @(_ :: k), 
> _, and (_ :: k)
> 3. Amendment with recursion: add support for arbitrary combinations 
> of @, _, ::, and ( ... )
> 
> It's going to be breaking in all three scenarios, unless we come up with 
> a compatibility layer using pattern synonyms as Adam suggests (I have 
> not investigated the feasibility of that).
> 
> Vlad
> 
> On Fri, Apr 19, 2024 at 5:59 PM Malte Ott <malte.ott at maralorn.de 
> <mailto:malte.ott at maralorn.de>> wrote:
> 
>     Thanks for the input Vlad. Regarding the breaking change to TH:
>     Do I understand you correctly that the required changes from 425
>     have not landed
>     in 9.10 and therefor accepting this proposal will not create anymore
>     breakage,
>     even between 9.10 and 9.12?


-- 
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 malte.ott at maralorn.de  Mon Apr 22 20:37:29 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Mon, 22 Apr 2024 22:37:29 +0200
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
References: <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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
Message-ID: <hzexiqg77ws7gzkcihpyvoxdnftq5hrv7wciqcbngz4e3qalvm@hera.m-0.eu>

I am not thrilled by having this three voting options. e.g. I think the
behaviour in 4. is fine and maybe even better than the type class approach, but
since this is coupled with not having a warning, its definitely worse.

3a
2
4

Also: If we implement 3a and then later people are against adding the
extension to a language edition because it might error on a few programs I will
be annoyed.

Best
Malte



On 2024-04-22 16:15, Arnaud Spiwack wrote:
> Ok, so, after an extended period of time (which, obviously, is my fault),
> we essentially have one option per opinion (well, I guess 3a and 4 have
> two, but that's not really what consensus is like). Simon, the other day,
> advised me to reduce the number of choices based on Shea's preferences. I
> decided to not include Shea's original proposal of doing the backward
> incompatible change without extension as I believe that it is contrary to
> the spirit of the language editions and all that.
> 
> *I'm calling for a vote* on the three following options. As per our
> customs, this is preference voting please order the following options. If
> you want to vote against an option, rank it after “That's it” (or omit it
> altogether). Explanation of the summary below
> 
> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll
> tally, and synthesise the committee's final position.
> 
> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when `main`
> has a type that isn't `main :: IO ()` or `main :: IO Void`, very much
> including `main :: IO ExitCode` (Shae's second favourite alternative)
> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added as
> in 2, but, additionally, an extension is introduced. When the extension is
> turned on, we always call the proposed `ExitStatus` type class on the
> returned value to determine the program's exit code. (Shae's favourite
> alternative)
> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
> introduced, but an extension is. When the extension is turned on,
> everything is as today, except when `main :: IO ExitCode`, in which case we
> program's exit code is the exit code returned by `main` (Simon PJ's
> favourite)
> That's it
> 
> ------
> 
> The summaries are based on the following examples. Each get a letter
> representing the behaviour under the proposal, as described in the legend
> 
> The 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 ... }
> 
> The 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.
> - I: The exit code is the returned value (only apply to `main :: IO
> ExitCode`).
> - N: not available under this alternative
> 
> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> 
> > @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.
> >
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.

From arnaud.spiwack at tweag.io  Mon Apr 29 07:26:54 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 29 Apr 2024 09:26:54 +0200
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
Message-ID: <CAGwnsnnyES2QgebKaJ9rFdoZe2H00gEwfn42pBMtnxmgtz4h2w@mail.gmail.com>

Let me remind everybody of this thread: votes close on Wednesday.

Simon M, Simon PJ, Chris, Moritz, I'd love to have your opinion.

PS: Malte, I agree and I don't love the reduced choice either. But many
choices seemed to prevent opinions from coalescing. I don't think there's
an easy solution here. Generally, my opinion is that bikeshedding issues
aren't very-well suited to being resolved by committees. So we have to
compromise to move forward.

/Arnaud


On Mon, 22 Apr 2024 at 16:15, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Ok, so, after an extended period of time (which, obviously, is my fault),
> we essentially have one option per opinion (well, I guess 3a and 4 have
> two, but that's not really what consensus is like). Simon, the other day,
> advised me to reduce the number of choices based on Shea's preferences. I
> decided to not include Shea's original proposal of doing the backward
> incompatible change without extension as I believe that it is contrary to
> the spirit of the language editions and all that.
>
> *I'm calling for a vote* on the three following options. As per our
> customs, this is preference voting please order the following options. If
> you want to vote against an option, rank it after “That's it” (or omit it
> altogether). Explanation of the summary below
>
> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll
> tally, and synthesise the committee's final position.
>
> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when
> `main` has a type that isn't `main :: IO ()` or `main :: IO Void`, very
> much including `main :: IO ExitCode` (Shae's second favourite alternative)
> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added as
> in 2, but, additionally, an extension is introduced. When the extension is
> turned on, we always call the proposed `ExitStatus` type class on the
> returned value to determine the program's exit code. (Shae's favourite
> alternative)
> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
> introduced, but an extension is. When the extension is turned on,
> everything is as today, except when `main :: IO ExitCode`, in which case we
> program's exit code is the exit code returned by `main` (Simon PJ's
> favourite)
> That's it
>
> ------
>
> The summaries are based on the following examples. Each get a letter
> representing the behaviour under the proposal, as described in the legend
>
> The 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 ... }
>
> The 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.
> - I: The exit code is the returned value (only apply to `main :: IO
> ExitCode`).
> - N: not available under this alternative
>
> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> @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.
>>
>
>
> --
> 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/20240429/613f9749/attachment.html>

From chris at chrisdornan.com  Mon Apr 29 15:25:47 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 29 Apr 2024 16:25:47 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsnnyES2QgebKaJ9rFdoZe2H00gEwfn42pBMtnxmgtz4h2w@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
 <CAGwnsnnyES2QgebKaJ9rFdoZe2H00gEwfn42pBMtnxmgtz4h2w@mail.gmail.com>
Message-ID: <2F9BF83C-AE4F-4BDD-88F0-658284969CCD@chrisdornan.com>

My preference is 

4
3a
2

> On 29 Apr 2024, at 08:26, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> Let me remind everybody of this thread: votes close on Wednesday.
> 
> Simon M, Simon PJ, Chris, Moritz, I'd love to have your opinion.
> 
> PS: Malte, I agree and I don't love the reduced choice either. But many choices seemed to prevent opinions from coalescing. I don't think there's an easy solution here. Generally, my opinion is that bikeshedding issues aren't very-well suited to being resolved by committees. So we have to compromise to move forward.
> 
> /Arnaud
> 
> 
> On Mon, 22 Apr 2024 at 16:15, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> Ok, so, after an extended period of time (which, obviously, is my fault), we essentially have one option per opinion (well, I guess 3a and 4 have two, but that's not really what consensus is like). Simon, the other day, advised me to reduce the number of choices based on Shea's preferences. I decided to not include Shea's original proposal of doing the backward incompatible change without extension as I believe that it is contrary to the spirit of the language editions and all that.
>> 
>> I'm calling for a vote on the three following options. As per our customs, this is preference voting please order the following options. If you want to vote against an option, rank it after “That's it” (or omit it altogether). Explanation of the summary below
>> 
>> I'm leaving the vote open until Wednesday 1st May. After which, I'll tally, and synthesise the committee's final position.
>> 
>> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when `main` has a type that isn't `main :: IO ()` or `main :: IO Void`, very much including `main :: IO ExitCode` (Shae's second favourite alternative)
>> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added as in 2, but, additionally, an extension is introduced. When the extension is turned on, we always call the proposed `ExitStatus` type class on the returned value to determine the program's exit code. (Shae's favourite alternative)
>> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is introduced, but an extension is. When the extension is turned on, everything is as today, except when `main :: IO ExitCode`, in which case we program's exit code is the exit code returned by `main` (Simon PJ's favourite)
>> That's it
>> 
>> ------
>> 
>> The summaries are based on the following examples. Each get a letter representing the behaviour under the proposal, as described in the legend
>> 
>> The 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 ... }
>> 
>> The 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.
>> - I: The exit code is the returned value (only apply to `main :: IO ExitCode`).
>> - N: not available under this alternative
>> 
>> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>> @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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> 
>>> -- 
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
>> 
>> 
>> -- 
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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/20240429/752a74a3/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Apr 29 15:58:12 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 29 Apr 2024 16:58:12 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
Message-ID: <CAJKmMz-zb-Y1MBc7SUcLsgJJHok028HnHUv4sMA=3c1ZTXa-XQ@mail.gmail.com>

Arnaud

4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
introduced, but an extension is. When the extension is turned on,
everything is as today, except when `main :: IO ExitCode`, in which case we
program's exit code is the exit code returned by `main` (Simon PJ's
favourite)


Actually I didn't say anything about warnings when suggesting (4).  If we
adopted (4) *we'd surely want a warning like (2) when main returns a type
other than (), Void, or ExitCode*.  So I'm going to vote on that basis

4 (with warning)
3a
2
that's it

Note that 4 (with warning) amounts to the same as (3a) with three built-in
instances for (), Void, and ExitCode.  The difference is that 3a allows you
to have new types that all map to ExitCode. I don't think we have (nearly)
enough evidence to justify that extra complexity.  If we get that evidence
we can smoothly move from (4-with-warning) to (3a); but not vice versa.
Because (4-with-warning) is effectively a special case of (3a).

Finally, with 3a there is a question of whether it is

   -  an error for main to return a type that is not an instance of
   ExitStatus
   - or a warning

The former is a breaking change; the latter is not.  The proposal specifies
the latter, only it's not clear from the proposal whether you get a
warning. I think you should.

Simon


On Mon, 22 Apr 2024 at 15:15, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Ok, so, after an extended period of time (which, obviously, is my fault),
> we essentially have one option per opinion (well, I guess 3a and 4 have
> two, but that's not really what consensus is like). Simon, the other day,
> advised me to reduce the number of choices based on Shea's preferences. I
> decided to not include Shea's original proposal of doing the backward
> incompatible change without extension as I believe that it is contrary to
> the spirit of the language editions and all that.
>
> *I'm calling for a vote* on the three following options. As per our
> customs, this is preference voting please order the following options. If
> you want to vote against an option, rank it after “That's it” (or omit it
> altogether). Explanation of the summary below
>
> I'm leaving the vote open until *Wednesday 1st May*. After which, I'll
> tally, and synthesise the committee's final position.
>
> 2. [Summary: 00WWWN] No change in behaviour, just add a warning when
> `main` has a type that isn't `main :: IO ()` or `main :: IO Void`, very
> much including `main :: IO ExitCode` (Shae's second favourite alternative)
> 3a. [Summary: -XNoWombat: 00WWWW / -XWombat: TTETET] A warning is added as
> in 2, but, additionally, an extension is introduced. When the extension is
> turned on, we always call the proposed `ExitStatus` type class on the
> returned value to determine the program's exit code. (Shae's favourite
> alternative)
> 4. [Summary: -XNoWombat: 00000N / -XWombat 00I00N] No warning is
> introduced, but an extension is. When the extension is turned on,
> everything is as today, except when `main :: IO ExitCode`, in which case we
> program's exit code is the exit code returned by `main` (Simon PJ's
> favourite)
> That's it
>
> ------
>
> The summaries are based on the following examples. Each get a letter
> representing the behaviour under the proposal, as described in the legend
>
> The 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 ... }
>
> The 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.
> - I: The exit code is the returned value (only apply to `main :: IO
> ExitCode`).
> - N: not available under this alternative
>
> On Thu, 28 Mar 2024 at 16:18, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> @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.
>>
>
>
> --
> 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/20240429/a58e9b85/attachment.html>

From arnaud.spiwack at tweag.io  Tue Apr 30 12:20:10 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 30 Apr 2024 14:20:10 +0200
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAJKmMz-zb-Y1MBc7SUcLsgJJHok028HnHUv4sMA=3c1ZTXa-XQ@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
 <CAJKmMz-zb-Y1MBc7SUcLsgJJHok028HnHUv4sMA=3c1ZTXa-XQ@mail.gmail.com>
Message-ID: <CAGwnsnkMFDAG+nEQ5T_AEcbmzYWeoxPTcM+YQEwhvDbVAn5YjA@mail.gmail.com>

On Mon, 29 Apr 2024 at 17:58, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Actually I didn't say anything about warnings when suggesting (4).  If we
> adopted (4) *we'd surely want a warning like (2) when main returns a type
> other than (), Void, or ExitCode*.  So I'm going to vote on that basis
>

Argl! My misunderstanding, sorry.

Would anyone change their vote if we change 4 to: -XNoWombat: 00WWWN /
-XWombat 00IWWN]? I believe Malte will. Anyone else?

(For 3a, I did specify that -XWombat gives errors on types which aren't
instances of ExitStatus)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240430/0eb3d5bc/attachment.html>

From moritz.angermann at gmail.com  Tue Apr 30 12:37:22 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 30 Apr 2024 20:37:22 +0800
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsnkMFDAG+nEQ5T_AEcbmzYWeoxPTcM+YQEwhvDbVAn5YjA@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
 <CAJKmMz-zb-Y1MBc7SUcLsgJJHok028HnHUv4sMA=3c1ZTXa-XQ@mail.gmail.com>
 <CAGwnsnkMFDAG+nEQ5T_AEcbmzYWeoxPTcM+YQEwhvDbVAn5YjA@mail.gmail.com>
Message-ID: <CAKfdd-wwMETbaUOTMp97Cv8YOVDV6fjAOwk3DQVqETFRrYg1eQ@mail.gmail.com>

Dear friends,

I ask to abstain from this vote, as I’m experiencing some medical issues,
which require my full attention right now.

Thank you!

Best,
  Moritz

On Tue, 30 Apr 2024 at 8:20 PM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> On Mon, 29 Apr 2024 at 17:58, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Actually I didn't say anything about warnings when suggesting (4).  If we
>> adopted (4) *we'd surely want a warning like (2) when main returns a
>> type other than (), Void, or ExitCode*.  So I'm going to vote on that
>> basis
>>
>
> Argl! My misunderstanding, sorry.
>
> Would anyone change their vote if we change 4 to: -XNoWombat: 00WWWN /
> -XWombat 00IWWN]? I believe Malte will. Anyone else?
>
> (For 3a, I did specify that -XWombat gives errors on types which aren't
> instances of ExitStatus)
> _______________________________________________
> 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/20240430/5a23f919/attachment.html>

From arnaud.spiwack at tweag.io  Tue Apr 30 12:38:21 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 30 Apr 2024 14:38:21 +0200
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAKfdd-wwMETbaUOTMp97Cv8YOVDV6fjAOwk3DQVqETFRrYg1eQ@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>
 <CAGwnsnn0ZoE0erqPdMkGFHEAG9kXc=6Er_y2nyFNzBkfuBoSPA@mail.gmail.com>
 <CAGwnsn=cd0WgZ731nuEEAg_19g6KE-f+9H_zmtNB8Yj3umMWGg@mail.gmail.com>
 <CAJKmMz-zb-Y1MBc7SUcLsgJJHok028HnHUv4sMA=3c1ZTXa-XQ@mail.gmail.com>
 <CAGwnsnkMFDAG+nEQ5T_AEcbmzYWeoxPTcM+YQEwhvDbVAn5YjA@mail.gmail.com>
 <CAKfdd-wwMETbaUOTMp97Cv8YOVDV6fjAOwk3DQVqETFRrYg1eQ@mail.gmail.com>
Message-ID: <CAGwnsnmDLrAkD76rRSezEdESsE3mdRT4CYz948FsagHnkNc8rQ@mail.gmail.com>

Moritz,

No worries. Take good care of yourself.

On Tue, 30 Apr 2024 at 14:37, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Dear friends,
>
> I ask to abstain from this vote, as I’m experiencing some medical issues,
> which require my full attention right now.
>
> Thank you!
>
> Best,
>   Moritz
>
> On Tue, 30 Apr 2024 at 8:20 PM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> On Mon, 29 Apr 2024 at 17:58, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Actually I didn't say anything about warnings when suggesting (4).  If
>>> we adopted (4) *we'd surely want a warning like (2) when main returns a
>>> type other than (), Void, or ExitCode*.  So I'm going to vote on that
>>> basis
>>>
>>
>> Argl! My misunderstanding, sorry.
>>
>> Would anyone change their vote if we change 4 to: -XNoWombat: 00WWWN /
>> -XWombat 00IWWN]? I believe Malte will. Anyone else?
>>
>> (For 3a, I did specify that -XWombat gives errors on types which aren't
>> instances of ExitStatus)
>> _______________________________________________
>> 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/20240430/37897208/attachment.html>