From simon.peytonjones at gmail.com  Thu Feb  1 12:37:29 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 1 Feb 2024 12:37:29 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <ed0b6af5-58d7-44c8-b4fa-8e7004c6c2b3@well-typed.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
 <7ee154a4cc3b782b8f40cbe57b2af0f46deea85d.camel@joachim-breitner.de>
 <CANsrgPLZ8_eDPk7dHDuWNjVKiONAphJo4r0HjR9WDmOCoB9Jrw@mail.gmail.com>
 <14dbafad95a577f2f4905a6ee793b23c67bda4d2.camel@joachim-breitner.de>
 <CANsrgP+nvhWn4KPoLewWKbShiUnaUKF_2cUUDDVdwuN-ZEs-uA@mail.gmail.com>
 <CALkkMoR=aALOYAmit8t42t_duj--mW-se-qGkNb5K5zXVtRUVA@mail.gmail.com>
 <CANsrgPKfVyzH0JyuaWwd77RKUes5p=qevGpzkUeXP7EzrPeJmQ@mail.gmail.com>
 <ed0b6af5-58d7-44c8-b4fa-8e7004c6c2b3@well-typed.com>
Message-ID: <CAJKmMz-oBwYF5ZPgq7wx-QGLm4=21E=M9ZaY_wGaUWRq9_3qhw@mail.gmail.com>

I see. So you are proposing

   - PatternSignatures = SimplePatternSignatures + PatternSignatureBinds

That's fine with me.

Simon

On Wed, 31 Jan 2024 at 21:30, Adam Gundry <adam at well-typed.com> wrote:

> John responded to some of this discussion on the proposal:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/608#issuecomment-1919413031
> .
>
> I think we should try to resolve this thread rather than leave it
> hanging. Given Simon's opposition to the idea of changing
> PatternSignatures, it seems to me the next best thing would be Joachim's
> observation that we could define a new extension SimplePatternSignatures
> (or however we call it) and modify #448 to use that instead. Perhaps
> that's a compromise we can live with? John indicates that he'd be happy
> with that outcome.
>
> Cheers,
>
> Adam
>
>
>
> On 29/01/2024 15:30, Simon Marlow wrote:
> > On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg
> > <reisenberg at janestreet.com <mailto:reisenberg at janestreet.com>> wrote:
> >
> >     Simon M:
> >
> >         deciding that the stability principles don't apply to
> >         pre-existing deprecations would not be in the right spirit, if
> >         you ask me
> >
> >
> >     To me, it's in the spirit of "deprecation", if not stability. That
> >     is, what does it mean to deprecate a feature? I think it means that
> >     users should expect the feature to disappear at some point in the
> >     future; in other words, it explicitly labels a feature as
> >     non-stable. Up until now, we hadn't settled on a meaning of
> >     stability, and so by extension we hadn't settled on a meaning for
> >     deprecation. So maybe we say "the feature wasn't actually deprecated
> >     because we didn't know what /deprecated/ meant", but I think this
> >     one has been labeled deprecated for long enough that we should feel
> >     comfortable removing it / changing it.
> >
> >
> > This raises an interesting distinction that I hadn't realised before
> > (and sorry about the tangent but it seemed important to highlight). We
> > may actually want two different kinds of deprecation:
> >
> > 1. Deprecated and may change in a future GHC release (GR3-style
> > deprecation; we expect these to be rare)
> > 2. Deprecated and may change in a future language edition (no impact on
> > stability; doesn't require GR2 justification; more common)
> >
> > I kind of expected most existing deprecations would turn into (2) given
> > the new stability requirements.
> >
> > Cheers
> > Simon
> >
> >
> >     ---------------
> >
> >     My initial support for this proposal was based on the fact that it
> >     made a few people happy. Now it's become clear that it also makes a
> >     few people unhappy. I'm still hoping for a language-edition-based
> >     future <https://github.com/ghc-proposals/ghc-proposals/pull/628>
> >     where this proposal doesn't matter, so I'm pretty agnostic. Maybe on
> >     balance it's a better use of time debating that potential future
> >     (I'll prepare a proper proposal this week) than to debate this finer
> >     point?
> >
> >     Richard
> >
> >     On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow <marlowsd at gmail.com
> >     <mailto:marlowsd at gmail.com>> wrote:
> >
> >         Hmm, deciding that the stability principles don't apply to
> >         pre-existing deprecations would not be in the right spirit, if
> >         you ask me. I think we should apply the rules consistently to
> >         every proposal going forward, being already deprecated doesn't
> >         get you a pass. In this case we really don't have to break
> >         existing code, so let's not do it.
> >
> >         It's not that hard to make a new extension or to change the
> >         behaviour in GHC2024 is it?
> >
> >         Cheers
> >         Simon
> >
> >
> >
> >         On Mon, 29 Jan 2024 at 11:42, Joachim Breitner
> >         <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
> wrote:
> >
> >             Hi,
> >
> >             well, we were more liberal at deprecating things in the past
> >             than we
> >             will be under the new regime, and we might not have invoked
> >             GR2 here.
> >
> >             But the extension already _is_ deprecated. If deprecating
> >             (even for the
> >             wrong reasons) and waiting multiple releases does not allow
> >             us to break
> >             the deprecated thing, then what is the point of GR3?
> >
> >             I am quite fond of the new stability regime, it sets out
> >             clear requirements on code (set a language flag, heed
> >             deprecation
> >             warnings, although the latter could be spelled out more
> >             explicitly), in
> >             return for clear promises. Let’s not water this down by not
> >             taking the
> >             set of requirements of requirements seriously ourselves.
> >
> >             Cheers,
> >             Joachim
> >
> >             Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon
> Marlow:
> >              > "Only exceptionally would we fix a design flaw in a way
> >             that breaks programs compiled with existing language
> >             editions."
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#34exceptions-gr2
> >
> >              >
> >              > This is not exceptional is it? It's just a regular design
> >             flaw :) If we must fix it, let's do it in a way that
> >             complies with the stability principle.
> >              >
> >              > Cheers
> >              > Simon
> >              >
> >              >
> >              > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner
> >             <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
> >             wrote:
> >              > > Hi,
> >              > >
> >              > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon
> >             Marlow:
> >              > > > I might be a bit confused, but doesn't this proposal
> >             change the meaning of an existing
> >              > > > extension (PatternSignatures)?
> >              > >
> >              > > a long-ago deprecated one:
> >              > >
> >              > > ~ $ ghci
> >              > > GHCi, version 9.4.8: https://www.haskell.org/ghc/
> >             <https://www.haskell.org/ghc/>  :? for help
> >              > > ghci> :set -XPatternSignatures
> >              > >
> >              > > <no location info>: warning: [-Wdeprecated-flags]
> >              > >     -XPatternSignatures is deprecated: use
> >             -XScopedTypeVariables or pragma {-# LANGUAGE
> >             ScopedTypeVariables #-} instead
> >              > >
> >              > > Hopefully our stability principles does not require us
> >             to heed programs
> >              > > that ignored deprecation flags for a while?
> >              > >
> >              > > My understanding of
> >              > >
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/principles.rst#3ghc-stability-principles
> >
> >              > > is that, despite “stable package” not saying “does not
> >             use features
> >              > > deprecated long ago”, it’s still ok to break such
> >             programs, as this is
> >              > > our mechanism GR3?
> >              > >
> >              > >
> >              > > Of course we could side-step this procedural question
> >             about repurposing
> >              > > an old extension and introduce
> >             `SimplePatternSignatures` instead. Not
> >              > > in favor, simply because as a user I more than once
> >             intuitively reached
> >              > > for `PatternSignatures` to get the proposed behavior.
> >              > >
> >              > > Cheers,
> >              > > Joachim
>
>
> --
> 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/20240201/f19d1eb0/attachment.html>

From simon.peytonjones at gmail.com  Sat Feb  3 21:14:52 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 3 Feb 2024 21:14:52 +0000
Subject: [ghc-steering-committee] #625 stability criteria
Message-ID: <CAJKmMz-REAdkqbbSOcqvVgASN4Vz02GeAcrBiWcGNuGQyJsxJg@mail.gmail.com>

Moritz

You are the shepherd on #625 GHC Stability Goals.  I submitted it to the
committee on 18 December.  Could you shepherd the discussion to a close?

Personally think we can just land it now, but as the shepherd that is your
role.

Thanks

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240203/662fa4fc/attachment.html>

From moritz.angermann at gmail.com  Sun Feb  4 09:09:35 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 4 Feb 2024 17:09:35 +0800
Subject: [ghc-steering-committee] Proposal #625 Articulate stability goals,
	recommendation: strong accept
Message-ID: <CAKfdd-zTk00ftEge9RvNv8x2O7a84QLHp2Mvxtbs0nbAqtR_Ng@mail.gmail.com>

Hi All,

Pull request 625 (https://github.com/ghc-proposals/ghc-proposals/pull/625),
is not
a proposal as usual, but primarily amending the readme and principles.
Simon has
taken the Stability discussion we have had last year, and integrated the
crystalized
General Rules into the readme and principles.

In my opinion, we have now debated this topic sufficiently, and found a
formulation
that captures the intent we want to set forward for the evolution of GHC. I
think this
spells out clear guardrails for GHCs evolution, as well as providing
reassurance to
commercial users of GHC regarding backwards compatibility and migration
support
though deprecation cycles when breakage is needed. As such, I
strongly recommend
acceptance of the proposal.

While there has been a recent spark in discussion of warning flags, I do
not believe
that discussion to be productive towards the change this proposal tries to
bring.

I'd like to ask the committee to cast their final votes on this amendment
to the
readme and principles, by the end of the coming week. Unless someone
objects,
I'll merge this as it is now on the 10th of February.

Best,
  Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240204/8db2d118/attachment.html>

From eric at seidel.io  Sun Feb  4 19:06:13 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 04 Feb 2024 13:06:13 -0600
Subject: [ghc-steering-committee] Proposal #625 Articulate stability
 goals, recommendation: strong accept
In-Reply-To: <CAKfdd-zTk00ftEge9RvNv8x2O7a84QLHp2Mvxtbs0nbAqtR_Ng@mail.gmail.com>
References: <CAKfdd-zTk00ftEge9RvNv8x2O7a84QLHp2Mvxtbs0nbAqtR_Ng@mail.gmail.com>
Message-ID: <3e44e36f-509d-4052-acc5-0f94dfe915dc@app.fastmail.com>

I support acceptance, thank you Simon for writing this up!

On Sun, Feb 4, 2024, at 03:09, Moritz Angermann wrote:
> Hi All,
>
> Pull request 625 
> (https://github.com/ghc-proposals/ghc-proposals/pull/625), is not
> a proposal as usual, but primarily amending the readme and principles.  
> Simon has
> taken the Stability discussion we have had last year, and integrated 
> the crystalized
> General Rules into the readme and principles.
>
> In my opinion, we have now debated this topic sufficiently, and found a 
> formulation
> that captures the intent we want to set forward for the evolution of 
> GHC. I think this
> spells out clear guardrails for GHCs evolution, as well as providing 
> reassurance to
> commercial users of GHC regarding backwards compatibility and migration 
> support
> though deprecation cycles when breakage is needed. As such, I strongly 
> recommend
> acceptance of the proposal.
>
> While there has been a recent spark in discussion of warning flags, I 
> do not believe
> that discussion to be productive towards the change this proposal tries 
> to bring.
>
> I'd like to ask the committee to cast their final votes on this amendment to the
> readme and principles, by the end of the coming week. Unless someone objects,
> I'll merge this as it is now on the 10th of February. 
>
> Best, 
>   Moritz
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From marlowsd at gmail.com  Mon Feb  5 08:02:45 2024
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 5 Feb 2024 08:02:45 +0000
Subject: [ghc-steering-committee] Proposal #625 Articulate stability
 goals, recommendation: strong accept
In-Reply-To: <CAKfdd-zTk00ftEge9RvNv8x2O7a84QLHp2Mvxtbs0nbAqtR_Ng@mail.gmail.com>
References: <CAKfdd-zTk00ftEge9RvNv8x2O7a84QLHp2Mvxtbs0nbAqtR_Ng@mail.gmail.com>
Message-ID: <CANsrgP+K1puqRqhoz4ZPKxUiHAto77ccpcZW0Rh4_e6KbPVc3g@mail.gmail.com>

Agreed, let's do it!

On Sun, 4 Feb 2024, 09:10 Moritz Angermann, <moritz.angermann at gmail.com>
wrote:

> Hi All,
>
> Pull request 625 (https://github.com/ghc-proposals/ghc-proposals/pull/625),
> is not
> a proposal as usual, but primarily amending the readme and principles.
> Simon has
> taken the Stability discussion we have had last year, and integrated the
> crystalized
> General Rules into the readme and principles.
>
> In my opinion, we have now debated this topic sufficiently, and found a
> formulation
> that captures the intent we want to set forward for the evolution of GHC.
> I think this
> spells out clear guardrails for GHCs evolution, as well as providing
> reassurance to
> commercial users of GHC regarding backwards compatibility and migration
> support
> though deprecation cycles when breakage is needed. As such, I
> strongly recommend
> acceptance of the proposal.
>
> While there has been a recent spark in discussion of warning flags, I do
> not believe
> that discussion to be productive towards the change this proposal tries to
> bring.
>
> I'd like to ask the committee to cast their final votes on this amendment
> to the
> readme and principles, by the end of the coming week. Unless someone
> objects,
> I'll merge this as it is now on the 10th of February.
>
> Best,
>   Moritz
> _______________________________________________
> 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/20240205/d308b274/attachment.html>

From arnaud.spiwack at tweag.io  Mon Feb  5 08:45:07 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 5 Feb 2024 09:45:07 +0100
Subject: [ghc-steering-committee] Proposal #625 Articulate stability
 goals, recommendation: strong accept
In-Reply-To: <CANsrgP+K1puqRqhoz4ZPKxUiHAto77ccpcZW0Rh4_e6KbPVc3g@mail.gmail.com>
References: <CAKfdd-zTk00ftEge9RvNv8x2O7a84QLHp2Mvxtbs0nbAqtR_Ng@mail.gmail.com>
 <CANsrgP+K1puqRqhoz4ZPKxUiHAto77ccpcZW0Rh4_e6KbPVc3g@mail.gmail.com>
Message-ID: <CAGwnsnm6hcb-37Ka0pV7ASyUqDL49WGrLPptDOLKNTo-1cHdew@mail.gmail.com>

I made a couple of (unessential) wording suggestions on the PR.

At any rate, I think that we bikeshed this one long enough :-) . Let's
adopt it.

On Mon, 5 Feb 2024 at 09:03, Simon Marlow <marlowsd at gmail.com> wrote:

> Agreed, let's do it!
>
> On Sun, 4 Feb 2024, 09:10 Moritz Angermann, <moritz.angermann at gmail.com>
> wrote:
>
>> Hi All,
>>
>> Pull request 625 (https://github.com/ghc-proposals/ghc-proposals/pull/625),
>> is not
>> a proposal as usual, but primarily amending the readme and principles.
>> Simon has
>> taken the Stability discussion we have had last year, and integrated the
>> crystalized
>> General Rules into the readme and principles.
>>
>> In my opinion, we have now debated this topic sufficiently, and found a
>> formulation
>> that captures the intent we want to set forward for the evolution of GHC.
>> I think this
>> spells out clear guardrails for GHCs evolution, as well as providing
>> reassurance to
>> commercial users of GHC regarding backwards compatibility and migration
>> support
>> though deprecation cycles when breakage is needed. As such, I
>> strongly recommend
>> acceptance of the proposal.
>>
>> While there has been a recent spark in discussion of warning flags, I do
>> not believe
>> that discussion to be productive towards the change this proposal tries
>> to bring.
>>
>> I'd like to ask the committee to cast their final votes on this amendment
>> to the
>> readme and principles, by the end of the coming week. Unless someone
>> objects,
>> I'll merge this as it is now on the 10th of February.
>>
>> Best,
>>   Moritz
>> _______________________________________________
>> 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/20240205/b788b963/attachment.html>

From reisenberg at janestreet.com  Mon Feb  5 14:25:03 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Mon, 5 Feb 2024 09:25:03 -0500
Subject: [ghc-steering-committee] Proposal #625 Articulate stability
 goals, recommendation: strong accept
In-Reply-To: <CAGwnsnm6hcb-37Ka0pV7ASyUqDL49WGrLPptDOLKNTo-1cHdew@mail.gmail.com>
References: <CAKfdd-zTk00ftEge9RvNv8x2O7a84QLHp2Mvxtbs0nbAqtR_Ng@mail.gmail.com>
 <CANsrgP+K1puqRqhoz4ZPKxUiHAto77ccpcZW0Rh4_e6KbPVc3g@mail.gmail.com>
 <CAGwnsnm6hcb-37Ka0pV7ASyUqDL49WGrLPptDOLKNTo-1cHdew@mail.gmail.com>
Message-ID: <CALkkMoQgwwU0JSPxYzj5L3Tyg-QO3NrVi2oNzz=8D93FVD=Lvw@mail.gmail.com>

Yes, let's accept. I agree that there may be further amendments as regards
warnings, but this writeup is still a clear step forward (to me).

On Mon, Feb 5, 2024 at 3:45 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I made a couple of (unessential) wording suggestions on the PR.
>
> At any rate, I think that we bikeshed this one long enough :-) . Let's
> adopt it.
>
> On Mon, 5 Feb 2024 at 09:03, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> Agreed, let's do it!
>>
>> On Sun, 4 Feb 2024, 09:10 Moritz Angermann, <moritz.angermann at gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> Pull request 625 (
>>> https://github.com/ghc-proposals/ghc-proposals/pull/625), is not
>>> a proposal as usual, but primarily amending the readme and principles.
>>> Simon has
>>> taken the Stability discussion we have had last year, and integrated the
>>> crystalized
>>> General Rules into the readme and principles.
>>>
>>> In my opinion, we have now debated this topic sufficiently, and found a
>>> formulation
>>> that captures the intent we want to set forward for the evolution of
>>> GHC. I think this
>>> spells out clear guardrails for GHCs evolution, as well as providing
>>> reassurance to
>>> commercial users of GHC regarding backwards compatibility and migration
>>> support
>>> though deprecation cycles when breakage is needed. As such, I
>>> strongly recommend
>>> acceptance of the proposal.
>>>
>>> While there has been a recent spark in discussion of warning flags, I do
>>> not believe
>>> that discussion to be productive towards the change this proposal tries
>>> to bring.
>>>
>>> I'd like to ask the committee to cast their final votes on this
>>> amendment to the
>>> readme and principles, by the end of the coming week. Unless someone
>>> objects,
>>> I'll merge this as it is now on the 10th of February.
>>>
>>> Best,
>>>   Moritz
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240205/3569256e/attachment.html>

From adam at well-typed.com  Thu Feb  8 21:15:41 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 8 Feb 2024 21:15:41 +0000
Subject: [ghc-steering-committee] Please review #592: Scoped kind variables
 in standalone kind signatures
Message-ID: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>

Dear Committee,

Vlad proposes to amend StandaloneKindSignatures to support scoped kind 
variables:

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

https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification

I'd like to nominate Eric as the shepherd.

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

Cheers,

Adam

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

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

From eric at seidel.io  Sat Feb 10 03:09:59 2024
From: eric at seidel.io (Eric Seidel)
Date: Fri, 09 Feb 2024 21:09:59 -0600
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables in
 standalone kind signatures (recommend accept)
In-Reply-To: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
Message-ID: <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>

Dear Committee,

Vlad has found what looks like a clear gap in the interaction between
two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.

I think it's quite obvious that under -XExtendedForAllScope the forall
in a standalone kind signature should behave like the forall in a
standalone type signature, i.e. it should scope over the definition
as well.

I recommend accepting this amendment to StandaloneKindSignatures.

Eric

https://github.com/ghc-proposals/ghc-proposals/pull/592
https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification

From rae at richarde.dev  Mon Feb 12 15:02:01 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 12 Feb 2024 15:02:01 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAKfdd-zzjYTKbqdCy7OnZ1+qpag1wdZQghesWL59SEwYTrJ8Zw@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
 <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
 <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>
 <CAKfdd-y+sYPf0DuJpDMp89uqSSrF+1QX_i68PdgOSOH-uS+RTg@mail.gmail.com>
 <CAGwnsn=pYEOxgc0=cBQ2gTFS+JjVJymhJVCq_NsvnAZ6-2=_hw@mail.gmail.com>
 <CAKfdd-zzjYTKbqdCy7OnZ1+qpag1wdZQghesWL59SEwYTrJ8Zw@mail.gmail.com>
Message-ID: <010f018d9dd6e065-959668a4-6ba2-49dc-aa88-b775e336172b-000000@us-east-2.amazonses.com>

Summarizing the discussion:

- Only a few have us have joined in. I'll take that as a signal that most don't have an opinion.
- There is some design wiggle-room. But there seem to be few strong opinions about how to set the knobs.
- Moritz is concerned about backward compatibility, given that there may not be wide knowledge in the community that -XLinearTypes is experimental.

While I agree it is regrettable that GHC itself has no built-in notion of "experimental", I'm not particularly moved by Moritz's concern here (sorry, Moritz!) -- I wager that LinearTypes is known to be pretty new and with sharp edges, and I'm pretty relaxed about changing it. We should prioritize cleaning this up so that we can be clearer in the future about what's experimental and what's not. To be clear, I think backward compatibility / stability is essential for GHC/Haskell, but I also think that until we have these notions baked into GHC (which we should do post-haste), we can use our judgement to determine that this change would not violate most users' assumptions of stability.

I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd like to say that we'll accept this proposal, with the understanding that Arnaud and I will work out any remaining design details (as discussed in this thread), including a clear, unambiguous bit of documentation in the user manual and an update proposal. The patch implementing this change (already merged!) has some documentation, but it doesn't accurately reflect the implementation, and so a further patch will be necessary. I can review that further patch, focusing on the documentation piece.

Any objections to this plan?

Thanks,
Richard

> On Jan 25, 2024, at 3:07 AM, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> Arnaud, I agree that _we_ consider LinearTypes experimental. I hope we can get https://github.com/ghc-proposals/ghc-proposals/pull/617 <https://github.com/ghc-proposals/ghc-proposals/pull/617> agreed on soon, so that the compiler has
> this knowledge as well. I am however not able to fully comprehend the technical details of this proposal right and therefore will defer to others on this!
> 
> On Thu, 25 Jan 2024 at 16:01, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> Moritz: there's one breakage introduced (but only for users of LinearTypes, which is considered experimental), namely that LinearTypes is proposed to now imply MonoLocalBinds.
> 
> On Thu, 25 Jan 2024 at 07:18, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
> I'll have to recuse myself from this, as much of this is currently going above my head. My overall understanding is that
> this mostly relaxes what we accept, and therefore won't break existing code?
> 
> Best,
>  Moritz
> 
> On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> Do newtypes make a difference?  E.g      let N x = e in ...
> where N is the data contructor of a newtype?
> 
> I don't think it has too. So for the moment, I vote to stick to the current proposal and consider this like all lazy non-variable patterns: must be unrestricted.
> 
> I suspect that there's a possible refinement where we say that a happy pattern is either:
> - A variable
> - Strict
> - A newtype constructor where the inner pattern is happy.
> 
> (then if pat is an unhappy pattern, `let pat` must be unrestricted).
> 
> But I don't think I'm quite ready to go there for the time being, and that'll be a backward compatible change if we change our mind.
> _______________________________________________
> 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 <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/20240212/7c217fed/attachment.html>

From simon.peytonjones at gmail.com  Mon Feb 12 22:29:59 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 12 Feb 2024 22:29:59 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <010f018d9dd6e065-959668a4-6ba2-49dc-aa88-b775e336172b-000000@us-east-2.amazonses.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
 <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
 <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>
 <CAKfdd-y+sYPf0DuJpDMp89uqSSrF+1QX_i68PdgOSOH-uS+RTg@mail.gmail.com>
 <CAGwnsn=pYEOxgc0=cBQ2gTFS+JjVJymhJVCq_NsvnAZ6-2=_hw@mail.gmail.com>
 <CAKfdd-zzjYTKbqdCy7OnZ1+qpag1wdZQghesWL59SEwYTrJ8Zw@mail.gmail.com>
 <010f018d9dd6e065-959668a4-6ba2-49dc-aa88-b775e336172b-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz_vCQg4t--4M2f2RZO0XBgnFSte++OKmmUqXWYgeakxxQ@mail.gmail.com>

>
> I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd
> like to say that we'll accept this proposal, with the understanding that
> Arnaud and I will work out any remaining design details (as discussed in
> this thread), including a clear, unambiguous bit of documentation in the
> user manual and an update proposal. The patch implementing this change
> (already merged!) has some documentation, but it doesn't accurately reflect
> the implementation, and so a further patch will be necessary. I can review
> that further patch, focusing on the documentation piece.


I support this.

Simon

On Mon, 12 Feb 2024 at 15:02, Richard Eisenberg <rae at richarde.dev> wrote:

> Summarizing the discussion:
>
> - Only a few have us have joined in. I'll take that as a signal that most
> don't have an opinion.
> - There is some design wiggle-room. But there seem to be few strong
> opinions about how to set the knobs.
> - Moritz is concerned about backward compatibility, given that there may
> not be wide knowledge in the community that -XLinearTypes is experimental.
>
> While I agree it is regrettable that GHC itself has no built-in notion of
> "experimental", I'm not particularly moved by Moritz's concern here (sorry,
> Moritz!) -- I wager that LinearTypes is known to be pretty new and with
> sharp edges, and I'm pretty relaxed about changing it. We should prioritize
> cleaning this up so that we can be clearer in the future about what's
> experimental and what's not. To be clear, I think backward compatibility /
> stability is essential for GHC/Haskell, but I also think that until we have
> these notions baked into GHC (which we should do post-haste), we can use
> our judgement to determine that this change would not violate most users'
> assumptions of stability.
>
> I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd
> like to say that we'll accept this proposal, with the understanding that
> Arnaud and I will work out any remaining design details (as discussed in
> this thread), including a clear, unambiguous bit of documentation in the
> user manual and an update proposal. The patch implementing this change
> (already merged!) has some documentation, but it doesn't accurately reflect
> the implementation, and so a further patch will be necessary. I can review
> that further patch, focusing on the documentation piece.
>
> Any objections to this plan?
>
> Thanks,
> Richard
>
> On Jan 25, 2024, at 3:07 AM, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
> Arnaud, I agree that _we_ consider LinearTypes experimental. I hope we can
> get https://github.com/ghc-proposals/ghc-proposals/pull/617 agreed on
> soon, so that the compiler has
> this knowledge as well. I am however not able to fully comprehend the
> technical details of this proposal right and therefore will defer to others
> on this!
>
> On Thu, 25 Jan 2024 at 16:01, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Moritz: there's one breakage introduced (but only for users of
>> LinearTypes, which is considered experimental), namely that LinearTypes is
>> proposed to now imply MonoLocalBinds.
>>
>> On Thu, 25 Jan 2024 at 07:18, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> I'll have to recuse myself from this, as much of this is currently going
>>> above my head. My overall understanding is that
>>> this mostly relaxes what we accept, and therefore won't break existing
>>> code?
>>>
>>> Best,
>>>  Moritz
>>>
>>> On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>>> Do newtypes make a difference?  E.g      let N x = e in ...
>>>>> where N is the data contructor of a newtype?
>>>>>
>>>>
>>>> I don't think it has too. So for the moment, I vote to stick to the
>>>> current proposal and consider this like all lazy non-variable patterns:
>>>> must be unrestricted.
>>>>
>>>> I suspect that there's a possible refinement where we say that a happy
>>>> pattern is either:
>>>> - A variable
>>>> - Strict
>>>> - A newtype constructor where the inner pattern is happy.
>>>>
>>>> (then if pat is an unhappy pattern, `let pat` must be unrestricted).
>>>>
>>>> But I don't think I'm quite ready to go there for the time being, and
>>>> that'll be a backward compatible change if we change our mind.
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240212/2685f59a/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Feb 12 22:38:34 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 12 Feb 2024 22:38:34 +0000
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
Message-ID: <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>

I support this too.

Simon

On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:

> Dear Committee,
>
> Vlad has found what looks like a clear gap in the interaction between
> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
>
> I think it's quite obvious that under -XExtendedForAllScope the forall
> in a standalone kind signature should behave like the forall in a
> standalone type signature, i.e. it should scope over the definition
> as well.
>
> I recommend accepting this amendment to StandaloneKindSignatures.
>
> Eric
>
> https://github.com/ghc-proposals/ghc-proposals/pull/592
>
> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
> _______________________________________________
> 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/20240212/b614884e/attachment.html>

From chris at chrisdornan.com  Tue Feb 13 10:59:28 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 13 Feb 2024 10:59:28 +0000
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
Message-ID: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>

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 suppresses the latter unless the -freport-indirectly-unused-bindings flag is specified.

The proposal is concise with some well-chosen examples and I recommend everyone at least skim it.

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

Chris

From chris at chrisdornan.com  Tue Feb 13 11:01:42 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 13 Feb 2024 11:01:42 +0000
Subject: [ghc-steering-committee] Proposal #624 on linear let-bindings;
 recommendation: accept
In-Reply-To: <CAJKmMz_vCQg4t--4M2f2RZO0XBgnFSte++OKmmUqXWYgeakxxQ@mail.gmail.com>
References: <010f018cdd16f88c-a1c3aa2d-6288-4d53-b55d-f489de51adb3-000000@us-east-2.amazonses.com>
 <CAJKmMz833TrAWuLoPAvx+qYOxgERXQTFWnir0RpF8_zYBJ5eKA@mail.gmail.com>
 <CAGwnsnnTN4h7kXHUodw9zqJR-f7zgZoTF1w5fFzNcCkUrt0E2g@mail.gmail.com>
 <010f018d139e1c95-917bef61-197e-4021-841a-ceee5e82d201-000000@us-east-2.amazonses.com>
 <CAJKmMz-Fx45qdEM7AojD2HGQmR-NTD6UsEJb-AkMjtrfE0pnpA@mail.gmail.com>
 <010f018d1954caeb-21f2195d-ba10-4208-b2c3-f5e2a7636f94-000000@us-east-2.amazonses.com>
 <CAGwnsnkedn5rGDN31aOo-wz24rVFG384Jswsh3Jpuz6JJ+1zdQ@mail.gmail.com>
 <CAJKmMz-VOqfRkOOE17r2DXpjbMsw6jKBhDqPJG=vF46HXN8w_Q@mail.gmail.com>
 <CAGwnsnnTKx_Ts19PPKYLQkc8AMrrErTKxoVy+utVjjRUX2QTHw@mail.gmail.com>
 <CAJKmMz8=DGDcu9WeXe=vQtPGqjk+DnedB1KtiWARzeQrQPTang@mail.gmail.com>
 <010f018d3bcc309a-a9101718-cd2b-4554-a4a3-e1ef8bd91794-000000@us-east-2.amazonses.com>
 <CAJKmMz-OVmHSSYcR1gu-68-E2iPBEvKE1SornN1O6NAxwKgDEA@mail.gmail.com>
 <CAGwnsnmz21QTwKFc_9ANL8=BvFXer9ZPD9g_oaupWUo8NyJUiw@mail.gmail.com>
 <CAKfdd-y+sYPf0DuJpDMp89uqSSrF+1QX_i68PdgOSOH-uS+RTg@mail.gmail.com>
 <CAGwnsn=pYEOxgc0=cBQ2gTFS+JjVJymhJVCq_NsvnAZ6-2=_hw@mail.gmail.com>
 <CAKfdd-zzjYTKbqdCy7OnZ1+qpag1wdZQghesWL59SEwYTrJ8Zw@mail.gmail.com>
 <010f018d9dd6e065-959668a4-6ba2-49dc-aa88-b775e336172b-000000@us-east-2.amazonses.com>
 <CAJKmMz_vCQg4t--4M2f2RZO0XBgnFSte++OKmmUqXWYgeakxxQ@mail.gmail.com>
Message-ID: <9A1CC2E2-4EC3-431B-837F-C36C093DE66B@chrisdornan.com>

+1 from me also

> On 12 Feb 2024, at 22:29, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd like to say that we'll accept this proposal, with the understanding that Arnaud and I will work out any remaining design details (as discussed in this thread), including a clear, unambiguous bit of documentation in the user manual and an update proposal. The patch implementing this change (already merged!) has some documentation, but it doesn't accurately reflect the implementation, and so a further patch will be necessary. I can review that further patch, focusing on the documentation piece.
> 
> I support this.
> 
> Simon
> 
> On Mon, 12 Feb 2024 at 15:02, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> Summarizing the discussion:
>> 
>> - Only a few have us have joined in. I'll take that as a signal that most don't have an opinion.
>> - There is some design wiggle-room. But there seem to be few strong opinions about how to set the knobs.
>> - Moritz is concerned about backward compatibility, given that there may not be wide knowledge in the community that -XLinearTypes is experimental.
>> 
>> While I agree it is regrettable that GHC itself has no built-in notion of "experimental", I'm not particularly moved by Moritz's concern here (sorry, Moritz!) -- I wager that LinearTypes is known to be pretty new and with sharp edges, and I'm pretty relaxed about changing it. We should prioritize cleaning this up so that we can be clearer in the future about what's experimental and what's not. To be clear, I think backward compatibility / stability is essential for GHC/Haskell, but I also think that until we have these notions baked into GHC (which we should do post-haste), we can use our judgement to determine that this change would not violate most users' assumptions of stability.
>> 
>> I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd like to say that we'll accept this proposal, with the understanding that Arnaud and I will work out any remaining design details (as discussed in this thread), including a clear, unambiguous bit of documentation in the user manual and an update proposal. The patch implementing this change (already merged!) has some documentation, but it doesn't accurately reflect the implementation, and so a further patch will be necessary. I can review that further patch, focusing on the documentation piece.
>> 
>> Any objections to this plan?
>> 
>> Thanks,
>> Richard
>> 
>>> On Jan 25, 2024, at 3:07 AM, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>> 
>>> Arnaud, I agree that _we_ consider LinearTypes experimental. I hope we can get https://github.com/ghc-proposals/ghc-proposals/pull/617 agreed on soon, so that the compiler has
>>> this knowledge as well. I am however not able to fully comprehend the technical details of this proposal right and therefore will defer to others on this!
>>> 
>>> On Thu, 25 Jan 2024 at 16:01, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>> Moritz: there's one breakage introduced (but only for users of LinearTypes, which is considered experimental), namely that LinearTypes is proposed to now imply MonoLocalBinds.
>>>> 
>>>> On Thu, 25 Jan 2024 at 07:18, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>>>> I'll have to recuse myself from this, as much of this is currently going above my head. My overall understanding is that
>>>>> this mostly relaxes what we accept, and therefore won't break existing code?
>>>>> 
>>>>> Best,
>>>>>  Moritz
>>>>> 
>>>>> On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>>>> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>>> Do newtypes make a difference?  E.g      let N x = e in ...
>>>>>>> where N is the data contructor of a newtype?
>>>>>> 
>>>>>> I don't think it has too. So for the moment, I vote to stick to the current proposal and consider this like all lazy non-variable patterns: must be unrestricted.
>>>>>> 
>>>>>> I suspect that there's a possible refinement where we say that a happy pattern is either:
>>>>>> - A variable
>>>>>> - Strict
>>>>>> - A newtype constructor where the inner pattern is happy.
>>>>>> 
>>>>>> (then if pat is an unhappy pattern, `let pat` must be unrestricted).
>>>>>> 
>>>>>> But I don't think I'm quite ready to go there for the time being, and that'll be a backward compatible change if we change our mind.
>>>>>> _______________________________________________
>>>>>> 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
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240213/e8587a34/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Feb 13 16:38:48 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 13 Feb 2024 17:38:48 +0100
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
 <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
Message-ID: <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>

I haven't taken time to check that the specification that Vlad wrote is the
same as that of -XExtendedForAllScope for type signatures and function
definitions. But I trust that Vlad did his homework.

This makes perfect sense to me, though I'm not sure this is worth spending
time on, considering that we seem to be going in the direction to deprecate
-XExtendedForAllScope.

On Mon, 12 Feb 2024 at 23:39, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I support this too.
>
> Simon
>
> On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:
>
>> Dear Committee,
>>
>> Vlad has found what looks like a clear gap in the interaction between
>> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
>>
>> I think it's quite obvious that under -XExtendedForAllScope the forall
>> in a standalone kind signature should behave like the forall in a
>> standalone type signature, i.e. it should scope over the definition
>> as well.
>>
>> I recommend accepting this amendment to StandaloneKindSignatures.
>>
>> Eric
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/592
>>
>> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
>> _______________________________________________
>> 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/20240213/f433eb60/attachment.html>

From arnaud.spiwack at tweag.io  Tue Feb 13 16:57:21 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 13 Feb 2024 17:57:21 +0100
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
Message-ID: <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>

I noticed that the default value of the flag is unspecified (I believe that
the flag should be on by default, as deactivating transitively unused
bindings is pretty situational in my opinion; we may even decide to accept
the proposal but without the flag, though I have a feeling that the author
wouldn't be willing to implement the flagless version). I made a comment to
that effect on Github.

The rest of the proposal looks good to me.

On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com> wrote:

> 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 suppresses the latter unless the -freport-indirectly-unused-bindings
> flag is specified.
>
> The proposal is concise with some well-chosen examples and I recommend
> everyone at least skim it.
>
> I propose        that we accept this proposal if nobody objects by the
> start of next week (Monday, 2024-02-19).
>
> Chris
> _______________________________________________
> 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/20240213/47b2a511/attachment.html>

From chris at chrisdornan.com  Wed Feb 14 13:22:11 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Wed, 14 Feb 2024 13:22:11 +0000
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
Message-ID: <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>

Thanks Arnaud — I agree with you and have said as much in the thread and asked Jakob to clarify.

> On 13 Feb 2024, at 16:57, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I noticed that the default value of the flag is unspecified (I believe that the flag should be on by default, as deactivating transitively unused bindings is pretty situational in my opinion; we may even decide to accept the proposal but without the flag, though I have a feeling that the author wouldn't be willing to implement the flagless version). I made a comment to that effect on Github.
> 
> The rest of the proposal looks good to me.
> 
> On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> 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 suppresses the latter unless the -freport-indirectly-unused-bindings flag is specified.
>> 
>> The proposal is concise with some well-chosen examples and I recommend everyone at least skim it.
>> 
>> I propose        that we accept this proposal if nobody objects by the start of next week (Monday, 2024-02-19).
>> 
>> 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
> 
> 
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240214/8a988bf0/attachment.html>

From reisenberg at janestreet.com  Wed Feb 14 21:33:39 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Wed, 14 Feb 2024 16:33:39 -0500
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
 <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
 <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>
Message-ID: <CALkkMoREVHvNo-=kW9naqsOFy5MaU9FBp1Q_8Cp8zKZ9E3jFGA@mail.gmail.com>

Yes, looks good to me. This is a natural part of -XExtendedForAllScope.
Which, though I dislike, seems to be around for good (and admittedly is
quite convenient).

On Tue, Feb 13, 2024 at 11:39 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I haven't taken time to check that the specification that Vlad wrote is
> the same as that of -XExtendedForAllScope for type signatures and function
> definitions. But I trust that Vlad did his homework.
>
> This makes perfect sense to me, though I'm not sure this is worth spending
> time on, considering that we seem to be going in the direction to deprecate
> -XExtendedForAllScope.
>
> On Mon, 12 Feb 2024 at 23:39, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I support this too.
>>
>> Simon
>>
>> On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:
>>
>>> Dear Committee,
>>>
>>> Vlad has found what looks like a clear gap in the interaction between
>>> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
>>>
>>> I think it's quite obvious that under -XExtendedForAllScope the forall
>>> in a standalone kind signature should behave like the forall in a
>>> standalone type signature, i.e. it should scope over the definition
>>> as well.
>>>
>>> I recommend accepting this amendment to StandaloneKindSignatures.
>>>
>>> Eric
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/592
>>>
>>> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240214/154600aa/attachment.html>

From arnaud.spiwack at tweag.io  Thu Feb 15 07:58:20 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 15 Feb 2024 08:58:20 +0100
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
 <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
Message-ID: <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@mail.gmail.com>

For the record, Jakob has amended the proposal with the flag on by default.
I'm now fully good with the proposal.

On Wed, 14 Feb 2024 at 14:22, Chris Dornan <chris at chrisdornan.com> wrote:

> Thanks Arnaud — I agree with you and have said as much in the thread and
> asked Jakob to clarify.
>
> On 13 Feb 2024, at 16:57, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>
> I noticed that the default value of the flag is unspecified (I believe
> that the flag should be on by default, as deactivating transitively unused
> bindings is pretty situational in my opinion; we may even decide to accept
> the proposal but without the flag, though I have a feeling that the author
> wouldn't be willing to implement the flagless version). I made a comment to
> that effect on Github.
>
> The rest of the proposal looks good to me.
>
> On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> 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 suppresses the latter unless the -freport-indirectly-unused-bindings
>> flag is specified.
>>
>> The proposal is concise with some well-chosen examples and I recommend
>> everyone at least skim it.
>>
>> I propose        that we accept this proposal if nobody objects by the
>> start of next week (Monday, 2024-02-19).
>>
>> Chris
>> _______________________________________________
>> 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/20240215/8e854f95/attachment-0001.html>

From chris at chrisdornan.com  Thu Feb 15 08:23:22 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 15 Feb 2024 08:23:22 +0000
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@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>
Message-ID: <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>

Indeed — just a gentle reminder that the deadline for amending or objecting to this proposal is this coming Monday 19th.

Chris

> On 15 Feb 2024, at 07:58, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> For the record, Jakob has amended the proposal with the flag on by default. I'm now fully good with the proposal.
> 
> On Wed, 14 Feb 2024 at 14:22, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> Thanks Arnaud — I agree with you and have said as much in the thread and asked Jakob to clarify.
>> 
>>> On 13 Feb 2024, at 16:57, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>> 
>>> I noticed that the default value of the flag is unspecified (I believe that the flag should be on by default, as deactivating transitively unused bindings is pretty situational in my opinion; we may even decide to accept the proposal but without the flag, though I have a feeling that the author wouldn't be willing to implement the flagless version). I made a comment to that effect on Github.
>>> 
>>> The rest of the proposal looks good to me.
>>> 
>>> On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>>> 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 suppresses the latter unless the -freport-indirectly-unused-bindings flag is specified.
>>>> 
>>>> The proposal is concise with some well-chosen examples and I recommend everyone at least skim it.
>>>> 
>>>> I propose        that we accept this proposal if nobody objects by the start of next week (Monday, 2024-02-19).
>>>> 
>>>> 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
>>> 
>>> 
>>> --
>>> 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/>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240215/7688b381/attachment.html>

From adam at well-typed.com  Thu Feb 15 08:50:29 2024
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 15 Feb 2024 08:50:29 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
Message-ID: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>

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/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024

On the discussion thread, some people expressed a preference that GHC 
should default to the latest language edition anyway. There is also 
Richard's suggestion of wider changes of approach in #636. However, 
given that the GHC 9.10 fork date is fast approaching, introducing 
GHC2024 but not making it the default seems like the best short-term 
solution to me. We can always reassess our approach to this for future 
releases as part of the wider discussion.

If you object to the proposed approach, please speak up ASAP. Otherwise 
I plan to merge in a week or so.

Cheers,

Adam


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

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

From simon.peytonjones at gmail.com  Thu Feb 15 09:15:37 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 15 Feb 2024 09:15:37 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
Message-ID: <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>

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> 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/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>
> On the discussion thread, some people expressed a preference that GHC
> should default to the latest language edition anyway. There is also
> Richard's suggestion of wider changes of approach in #636. However,
> given that the GHC 9.10 fork date is fast approaching, introducing
> GHC2024 but not making it the default seems like the best short-term
> solution to me. We can always reassess our approach to this for future
> releases as part of the wider discussion.
>
> If you object to the proposed approach, please speak up ASAP. Otherwise
> I plan to merge in a week or so.
>
> Cheers,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240215/82736b7b/attachment.html>

From chris at chrisdornan.com  Thu Feb 15 13:21:11 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 15 Feb 2024 13:21:11 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
Message-ID: <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>

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> wrote:
> 
> I'm ok with this proposal.  The whole concept of a default language seems a bit flaky to me, if we are going to start warning any time someone doesn't explicitly specify an explicit addition.  While this is settling down, causing minimum disruption is good.
> 
> Simon
> 
> On Thu, 15 Feb 2024 at 08:50, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>> Dear committee,
>> 
>> In #632, I propose amending the GHC2024 proposal to specify that the 
>> default language used by ghc/ghci when run directly will remain GHC2021 
>> for now, since changing to GHC2024 is not backwards compatible. (This 
>> does not affect Cabal packages either way, since Cabal specifies its own 
>> default.)
>> 
>> https://github.com/ghc-proposals/ghc-proposals/pull/632
>> 
>> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>> 
>> On the discussion thread, some people expressed a preference that GHC 
>> should default to the latest language edition anyway. There is also 
>> Richard's suggestion of wider changes of approach in #636. However, 
>> given that the GHC 9.10 fork date is fast approaching, introducing 
>> GHC2024 but not making it the default seems like the best short-term 
>> solution to me. We can always reassess our approach to this for future 
>> releases as part of the wider discussion.
>> 
>> If you object to the proposed approach, please speak up ASAP. Otherwise 
>> I plan to merge in a week or so.
>> 
>> Cheers,
>> 
>> Adam
>> 
>> 
>> -- 
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>> 
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From simon.peytonjones at gmail.com  Thu Feb 15 16:08:28 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 15 Feb 2024 16:08:28 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
Message-ID: <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>

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> 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>
> 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> 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/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>>
>> On the discussion thread, some people expressed a preference that GHC
>> should default to the latest language edition anyway. There is also
>> Richard's suggestion of wider changes of approach in #636. However,
>> given that the GHC 9.10 fork date is fast approaching, introducing
>> GHC2024 but not making it the default seems like the best short-term
>> solution to me. We can always reassess our approach to this for future
>> releases as part of the wider discussion.
>>
>> If you object to the proposed approach, please speak up ASAP. Otherwise
>> I plan to merge in a week or so.
>>
>> Cheers,
>>
>> Adam
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240215/9519e3d7/attachment.html>

From chris at chrisdornan.com  Thu Feb 15 19:50:41 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 15 Feb 2024 19:50:41 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@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>
Message-ID: <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>

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> wrote:
> 
> I'm not understanding  your point, Chris.
> 
> I think we are planning to increasingly encourage people to specify an explicit language edition for everything.  (Indeed there is discussion of an on-by-default warning that complains if you don't.)  For these users, the "default language edition" is irrelevant.
> 
> So the only issue is people who don't specify a language edition at all.   Changing the default language edition risks breaking their code.  Why would we do that? What compelling reason is there for breaking code that we don't have to break?
> 
> For the short term,
> GHC2024 is particularly likely to break code
> We have not yet educated our users to use explicit language editions
> So making GHC2024 be the default language for GHC 9.10 seems (to me) to lead to entirely-unnecessary breakage, with no compelling reason to do so.
> 
> Simon
> 
> On Thu, 15 Feb 2024 at 13:21, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> I have been a strongly in favour of minimising surprises but I mildly resistant to this proposal.
>> 
>> After GHC2021 broke my code quite severly (though PolyKinds) there was an initial adjustment phase but I quickly got used to specifying the exact language I want to use everywhere. Indeed the propensity for GHCi to pick up the new breakage caused some surprises but I quickly adjusted when I realised what was going on.
>> 
>> The point is not that change is bad but change that is difficult to anticipate and control is bad. 
>> 
>> I now see the GHC adoption of the new default languages, that can very selectively break things when needed, as a fantastic development. It allows us to roll out changes in a very controlled way where at synchronisation points that are easy to understand and where developers retain control. This strikes me as a really great sweet spot for Haskell.
>> 
>> If we make this scheme more complicated by making some the tools adopt languages on different schedules then it risks creating confusion. Folks that want to tie down advanced features strike me as just the kind that should find it easy to fill out the appropriate settings in configuration files.
>> 
>> So I say lets get this rolled out ASAP (as Adam says) but roll it out consistently everywhere.
>> 
>> Chris
>> 
>> 
>>> On 15 Feb 2024, at 09:15, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> 
>>> I'm ok with this proposal.  The whole concept of a default language seems a bit flaky to me, if we are going to start warning any time someone doesn't explicitly specify an explicit addition.  While this is settling down, causing minimum disruption is good.
>>> 
>>> Simon
>>> 
>>> On Thu, 15 Feb 2024 at 08:50, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>> Dear committee,
>>>> 
>>>> In #632, I propose amending the GHC2024 proposal to specify that the 
>>>> default language used by ghc/ghci when run directly will remain GHC2021 
>>>> for now, since changing to GHC2024 is not backwards compatible. (This 
>>>> does not affect Cabal packages either way, since Cabal specifies its own 
>>>> default.)
>>>> 
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/632
>>>> 
>>>> https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>>>> 
>>>> On the discussion thread, some people expressed a preference that GHC 
>>>> should default to the latest language edition anyway. There is also 
>>>> Richard's suggestion of wider changes of approach in #636. However, 
>>>> given that the GHC 9.10 fork date is fast approaching, introducing 
>>>> GHC2024 but not making it the default seems like the best short-term 
>>>> solution to me. We can always reassess our approach to this for future 
>>>> releases as part of the wider discussion.
>>>> 
>>>> If you object to the proposed approach, please speak up ASAP. Otherwise 
>>>> I plan to merge in a week or so.
>>>> 
>>>> Cheers,
>>>> 
>>>> Adam
>>>> 
>>>> 
>>>> -- 
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>> 
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org <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
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240215/080f9b66/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Feb 16 08:36:46 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 16 Feb 2024 09:36:46 +0100
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.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>
Message-ID: <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>

(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> 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>
> 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> 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>
>> 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> 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/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#introduction-of-ghc2024
>>>
>>> On the discussion thread, some people expressed a preference that GHC
>>> should default to the latest language edition anyway. There is also
>>> Richard's suggestion of wider changes of approach in #636. However,
>>> given that the GHC 9.10 fork date is fast approaching, introducing
>>> GHC2024 but not making it the default seems like the best short-term
>>> solution to me. We can always reassess our approach to this for future
>>> releases as part of the wider discussion.
>>>
>>> If you object to the proposed approach, please speak up ASAP. Otherwise
>>> I plan to merge in a week or so.
>>>
>>> Cheers,
>>>
>>> Adam
>>>
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>>
> _______________________________________________
> 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/20240216/2f881ec6/attachment.html>

From adam at well-typed.com  Fri Feb 16 09:08:27 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 16 Feb 2024 09:08:27 +0000
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@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>
Message-ID: <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>

Thanks everyone for sharing your thoughts.

I would point out that this is not just about "the handful of people 
that have ghci scripts" but rather anyone compiling modules with ghc 
directly (not using Cabal). Were it about ghci alone, I agree that the 
latest language edition would be preferable. But it seems likely to be a 
larger class, e.g. including educators teaching Haskell, and users with 
small programs where they have not created a Cabal package.

Adam


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


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

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


From eric at seidel.io  Mon Feb 19 21:20:45 2024
From: eric at seidel.io (Eric Seidel)
Date: Mon, 19 Feb 2024 15:20:45 -0600
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>
References: <C20F7521-0342-4C90-875B-18088C37E6D2@chrisdornan.com>
 <CAGwnsn=v00rwrwegNSa_Wcjdo7FvYFbs6UVE+tBSehGNqGc6LA@mail.gmail.com>
 <A5577FF9-AD66-4921-A2D6-CBB981941AC3@chrisdornan.com>
 <CAGwnsnnE5De8ZX000CqGrN-B-JhK5S-m71dRGAuCy1boypPSxQ@mail.gmail.com>
 <139479DA-91FB-4960-9A04-BE453264F0C5@chrisdornan.com>
Message-ID: <7cce68ec-f48c-45cd-9c2e-c0180ac3b3cc@app.fastmail.com>

I'm generally fine with this proposal, but does it seem strange to anyone else that this is a -f flag rather than a new set of -W flags?

On Thu, Feb 15, 2024, at 02:23, Chris Dornan wrote:
> Indeed — just a gentle reminder that the deadline for amending or 
> objecting to this proposal is this coming Monday 19th.
>
> Chris
>
>> On 15 Feb 2024, at 07:58, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>> 
>> For the record, Jakob has amended the proposal with the flag on by default. I'm now fully good with the proposal.
>> 
>> On Wed, 14 Feb 2024 at 14:22, Chris Dornan <chris at chrisdornan.com> wrote:
>>> Thanks Arnaud — I agree with you and have said as much in the thread and asked Jakob to clarify.
>>> 
>>>> On 13 Feb 2024, at 16:57, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>>> 
>>>> I noticed that the default value of the flag is unspecified (I believe that the flag should be on by default, as deactivating transitively unused bindings is pretty situational in my opinion; we may even decide to accept the proposal but without the flag, though I have a feeling that the author wouldn't be willing to implement the flagless version). I made a comment to that effect on Github.
>>>> 
>>>> The rest of the proposal looks good to me.
>>>> 
>>>> On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com> wrote:
>>>>> 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 suppresses the latter unless the -freport-indirectly-unused-bindings flag is specified.
>>>>> 
>>>>> The proposal is concise with some well-chosen examples and I recommend everyone at least skim it.
>>>>> 
>>>>> I propose        that we accept this proposal if nobody objects by the start of next week (Monday, 2024-02-19).
>>>>> 
>>>>> Chris
>>>>> _______________________________________________
>>>>> 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 eric at seidel.io  Mon Feb 19 21:34:24 2024
From: eric at seidel.io (Eric Seidel)
Date: Mon, 19 Feb 2024 15:34:24 -0600
Subject: [ghc-steering-committee] #632: Phased introduction of GHC2024
In-Reply-To: <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
References: <5e6c9e1f-3a4c-49a7-9f5e-6f25f8a574f0@well-typed.com>
 <CAJKmMz8NAX-zK6zDppcApmVde6L9Ln0ku_wAq3TKZxyoX378bA@mail.gmail.com>
 <D32300BB-AF17-4814-8AC2-E1CD05ADAF90@chrisdornan.com>
 <CAJKmMz-85zqF7N4j-jXrNoOci4QJgExvU3uWrO0zPuq+8koV9A@mail.gmail.com>
 <2113AF54-F28A-491C-9389-761053942E97@chrisdornan.com>
 <CAGwnsnnvi=eOysLs0mM0tn6s-FXAXi6JwWQMrO7geHn37ikUFw@mail.gmail.com>
 <c6a850bc-7f9b-4a4c-9d39-24a48d38ecc7@well-typed.com>
Message-ID: <80d0f0aa-12d6-4bff-8900-3ea02c036a42@app.fastmail.com>

It seems to me that this particular proposal could make sense
tactically, but I agree with Chris and Arnaud that it feels
like the wrong thing strategically.

I don't see us getting away from a notion of a "default language".
GCC/Clang similarly implement many C/C++ standards and let users
choose, but still define a default standard per compiler version.
And this default changes across compiler releases. Forcing even
adhoc ghc[i] sessions to specify a language standard feels
excessive.

Thus, we need *some* cadence for updating the default language.
It could be that GHC 9.10 is too soon to make that change, but
we should commit to making the change at some point, with proper
messaging.

Eric

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

From eric at seidel.io  Mon Feb 19 21:36:52 2024
From: eric at seidel.io (Eric Seidel)
Date: Mon, 19 Feb 2024 15:36:52 -0600
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <CALkkMoREVHvNo-=kW9naqsOFy5MaU9FBp1Q_8Cp8zKZ9E3jFGA@mail.gmail.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
 <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
 <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>
 <CALkkMoREVHvNo-=kW9naqsOFy5MaU9FBp1Q_8Cp8zKZ9E3jFGA@mail.gmail.com>
Message-ID: <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>

All, I've only heard from SimonPJ, Arnaud, and Richard. Please voice your assent or dissent. Otherwise I will take silence as assent and accept the proposal this weekend.

On Wed, Feb 14, 2024, at 15:33, Richard Eisenberg wrote:
> Yes, looks good to me. This is a natural part of -XExtendedForAllScope. 
> Which, though I dislike, seems to be around for good (and admittedly is 
> quite convenient).
>
> On Tue, Feb 13, 2024 at 11:39 AM Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>> I haven't taken time to check that the specification that Vlad wrote is the same as that of -XExtendedForAllScope for type signatures and function definitions. But I trust that Vlad did his homework.
>> 
>> This makes perfect sense to me, though I'm not sure this is worth spending time on, considering that we seem to be going in the direction to deprecate -XExtendedForAllScope.
>> 
>> On Mon, 12 Feb 2024 at 23:39, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>> I support this too.
>>> 
>>> Simon
>>> 
>>> On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:
>>>> Dear Committee,
>>>> 
>>>> Vlad has found what looks like a clear gap in the interaction between
>>>> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
>>>> 
>>>> I think it's quite obvious that under -XExtendedForAllScope the forall
>>>> in a standalone kind signature should behave like the forall in a
>>>> standalone type signature, i.e. it should scope over the definition
>>>> as well.
>>>> 
>>>> I recommend accepting this amendment to StandaloneKindSignatures.
>>>> 
>>>> Eric
>>>> 
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/592
>>>> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> 
>> -- 
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From moritz.angermann at gmail.com  Wed Feb 21 09:41:30 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 21 Feb 2024 17:41:30 +0800
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <7cce68ec-f48c-45cd-9c2e-c0180ac3b3cc@app.fastmail.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>
Message-ID: <CAKfdd-wTAwa2LHivLP1U6XhKu3nNRzg8GJCz4qyA9rALrru81g@mail.gmail.com>

Sorry for the late reply. Last week was LNY week 😓 Just catching up on all
the work and other stuff.

I'm with Eric, that this seems fine. And while the -f / -W part is
discussed in the alternatives section, I can see reasons for both.

Guess we'll have to see how this plays out. I'm fine with -f or -W and as
such +1 from me.

On Tue, 20 Feb 2024 at 05:21, Eric Seidel <eric at seidel.io> wrote:

> I'm generally fine with this proposal, but does it seem strange to anyone
> else that this is a -f flag rather than a new set of -W flags?
>
> On Thu, Feb 15, 2024, at 02:23, Chris Dornan wrote:
> > Indeed — just a gentle reminder that the deadline for amending or
> > objecting to this proposal is this coming Monday 19th.
> >
> > Chris
> >
> >> On 15 Feb 2024, at 07:58, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> >>
> >> For the record, Jakob has amended the proposal with the flag on by
> default. I'm now fully good with the proposal.
> >>
> >> On Wed, 14 Feb 2024 at 14:22, Chris Dornan <chris at chrisdornan.com>
> wrote:
> >>> Thanks Arnaud — I agree with you and have said as much in the thread
> and asked Jakob to clarify.
> >>>
> >>>> On 13 Feb 2024, at 16:57, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> >>>>
> >>>> I noticed that the default value of the flag is unspecified (I
> believe that the flag should be on by default, as deactivating transitively
> unused bindings is pretty situational in my opinion; we may even decide to
> accept the proposal but without the flag, though I have a feeling that the
> author wouldn't be willing to implement the flagless version). I made a
> comment to that effect on Github.
> >>>>
> >>>> The rest of the proposal looks good to me.
> >>>>
> >>>> On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com>
> wrote:
> >>>>> 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 suppresses the latter unless the
> -freport-indirectly-unused-bindings flag is specified.
> >>>>>
> >>>>> The proposal is concise with some well-chosen examples and I
> recommend everyone at least skim it.
> >>>>>
> >>>>> I propose        that we accept this proposal if nobody objects by
> the start of next week (Monday, 2024-02-19).
> >>>>>
> >>>>> Chris
> >>>>> _______________________________________________
> >>>>> ghc-steering-committee mailing list
> >>>>> ghc-steering-committee at haskell.org
> >>>>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>>>
> >>>>
> >>>> --
> >>>> Arnaud Spiwack
> >>>> Director, Research at https://moduscreate.com and https://tweag.io.
> >>>
> >>
> >>
> >> --
> >> Arnaud Spiwack
> >> Director, Research at https://moduscreate.com and https://tweag.io.
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240221/8b46c91a/attachment.html>

From moritz.angermann at gmail.com  Wed Feb 21 09:44:56 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 21 Feb 2024 17:44:56 +0800
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
 <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
 <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>
 <CALkkMoREVHvNo-=kW9naqsOFy5MaU9FBp1Q_8Cp8zKZ9E3jFGA@mail.gmail.com>
 <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>
Message-ID: <CAKfdd-wGX_=LZicm8_anhh9mLb5XcnmQR-cCRYnKO2++xc3+KA@mail.gmail.com>

I must admit this is a bit outside of my usual realm of Haskell. I trust
the more knowledgeable members of this group to have a more informed view
on this than I do.
>From the associated discussion on the ticket, I'm pleased to see that
breakage has been taken into consideration.

+1 from me.

On Tue, 20 Feb 2024 at 05:37, Eric Seidel <eric at seidel.io> wrote:

> All, I've only heard from SimonPJ, Arnaud, and Richard. Please voice your
> assent or dissent. Otherwise I will take silence as assent and accept the
> proposal this weekend.
>
> On Wed, Feb 14, 2024, at 15:33, Richard Eisenberg wrote:
> > Yes, looks good to me. This is a natural part of -XExtendedForAllScope.
> > Which, though I dislike, seems to be around for good (and admittedly is
> > quite convenient).
> >
> > On Tue, Feb 13, 2024 at 11:39 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> >> I haven't taken time to check that the specification that Vlad wrote is
> the same as that of -XExtendedForAllScope for type signatures and function
> definitions. But I trust that Vlad did his homework.
> >>
> >> This makes perfect sense to me, though I'm not sure this is worth
> spending time on, considering that we seem to be going in the direction to
> deprecate -XExtendedForAllScope.
> >>
> >> On Mon, 12 Feb 2024 at 23:39, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> >>> I support this too.
> >>>
> >>> Simon
> >>>
> >>> On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:
> >>>> Dear Committee,
> >>>>
> >>>> Vlad has found what looks like a clear gap in the interaction between
> >>>> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
> >>>>
> >>>> I think it's quite obvious that under -XExtendedForAllScope the forall
> >>>> in a standalone kind signature should behave like the forall in a
> >>>> standalone type signature, i.e. it should scope over the definition
> >>>> as well.
> >>>>
> >>>> I recommend accepting this amendment to StandaloneKindSignatures.
> >>>>
> >>>> Eric
> >>>>
> >>>> https://github.com/ghc-proposals/ghc-proposals/pull/592
> >>>>
> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
> >>>> _______________________________________________
> >>>> ghc-steering-committee mailing list
> >>>> ghc-steering-committee at haskell.org
> >>>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
> >>
> >> --
> >> Arnaud Spiwack
> >> Director, Research at https://moduscreate.com and https://tweag.io.
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > 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/20240221/f2e648f3/attachment.html>

From simon.peytonjones at gmail.com  Thu Feb 22 13:37:32 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 22 Feb 2024 13:37:32 +0000
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CAKfdd-wTAwa2LHivLP1U6XhKu3nNRzg8GJCz4qyA9rALrru81g@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>
Message-ID: <CAJKmMz_WHTLHWfDb-ALtZaeiJ3rQJv6v3kUrbdNApELnFTz5Sg@mail.gmail.com>

I have suggested further precision in the spec.  And I strongly urge that
we use a -W flag not -f flag to control these warnings.  I have suggested a
design in
<https://github.com/ghc-proposals/ghc-proposals/pull/434#issuecomment-1959465348>my
comment

With that done, I approve

Simon

On Wed, 21 Feb 2024 at 10:41, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Sorry for the late reply. Last week was LNY week 😓 Just catching up on
> all the work and other stuff.
>
> I'm with Eric, that this seems fine. And while the -f / -W part is
> discussed in the alternatives section, I can see reasons for both.
>
> Guess we'll have to see how this plays out. I'm fine with -f or -W and as
> such +1 from me.
>
> On Tue, 20 Feb 2024 at 05:21, Eric Seidel <eric at seidel.io> wrote:
>
>> I'm generally fine with this proposal, but does it seem strange to anyone
>> else that this is a -f flag rather than a new set of -W flags?
>>
>> On Thu, Feb 15, 2024, at 02:23, Chris Dornan wrote:
>> > Indeed — just a gentle reminder that the deadline for amending or
>> > objecting to this proposal is this coming Monday 19th.
>> >
>> > Chris
>> >
>> >> On 15 Feb 2024, at 07:58, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>> >>
>> >> For the record, Jakob has amended the proposal with the flag on by
>> default. I'm now fully good with the proposal.
>> >>
>> >> On Wed, 14 Feb 2024 at 14:22, Chris Dornan <chris at chrisdornan.com>
>> wrote:
>> >>> Thanks Arnaud — I agree with you and have said as much in the thread
>> and asked Jakob to clarify.
>> >>>
>> >>>> On 13 Feb 2024, at 16:57, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>> >>>>
>> >>>> I noticed that the default value of the flag is unspecified (I
>> believe that the flag should be on by default, as deactivating transitively
>> unused bindings is pretty situational in my opinion; we may even decide to
>> accept the proposal but without the flag, though I have a feeling that the
>> author wouldn't be willing to implement the flagless version). I made a
>> comment to that effect on Github.
>> >>>>
>> >>>> The rest of the proposal looks good to me.
>> >>>>
>> >>>> On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com>
>> wrote:
>> >>>>> 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 suppresses the latter unless the
>> -freport-indirectly-unused-bindings flag is specified.
>> >>>>>
>> >>>>> The proposal is concise with some well-chosen examples and I
>> recommend everyone at least skim it.
>> >>>>>
>> >>>>> I propose        that we accept this proposal if nobody objects by
>> the start of next week (Monday, 2024-02-19).
>> >>>>>
>> >>>>> Chris
>> >>>>> _______________________________________________
>> >>>>> ghc-steering-committee mailing list
>> >>>>> ghc-steering-committee at haskell.org
>> >>>>>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Arnaud Spiwack
>> >>>> Director, Research at https://moduscreate.com and https://tweag.io.
>> >>>
>> >>
>> >>
>> >> --
>> >> Arnaud Spiwack
>> >> Director, Research at https://moduscreate.com and https://tweag.io.
>> >
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20240222/06483066/attachment.html>

From simon.peytonjones at gmail.com  Thu Feb 22 14:19:29 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 22 Feb 2024 14:19:29 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz_k3GsSeC-XQ0sv=FfJkrYewoDZ=HdjFq+4hrhucQE=2A@mail.gmail.com>

Richard,

A month after your recommendation this one is still unresolved.  Might you
find the time to drive it to a conclusion?  Thanks!

Simon

On Wed, 24 Jan 2024 at 18:33, Richard Eisenberg <rae at richarde.dev> wrote:

> John Ericson has submitted proposal #608
> <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding
> -XPatternSignatureBinds. The proposal is an amendment and is thus a little
> harder to consume. I recommend reading the summary here.
>
> Proposed change:
>
> The proposed -XPatternSignatureBinds takes a piece out from
> -XPatternSignatures: with only -XPatternSignatures and not
> -XPatternSignatureBinds, a pattern signature  can mention in-scope type
> variables but can never bind fresh ones. With -XPatternSignatureBinds, an
> appearance of an out-of-scope type variable in a pattern signature will
> cause the variable to be bound to the type it unifies with.
>
> -XScopedTypeVariables will imply -XPatternSignatures
> -XPatternSignatureBinds (and a few more), so the behavior of
> -XScopedTypeVariables is completely unchanged. Note that
> -XPatternSignatures is currently deprecated (and has been so for a long
> time), so a change in behavior there is not so bad.
>
> Motivation for the change:
>
> - It is awkward to have a rule in a language where scoping behavior
> depends on what else is in scope. This can confound e.g. tools meant to
> find the bindings sites of a variable occurrence.
> - The implicit binding we have today plays poorly with the plan to allow
> users to pretend GHC has a unified namespace. That is, suppose x is in
> scope as a term variable, and then we have f (... :: ... x ...) = ... .
> Should that x be bound implicitly there or not? It's pretty unclear. By
> separating out -XPatternSignatureBinds from -XPatternSignatures, users of
> the latter are insulated from worrying about this potential future change.
>
> My opinion:
>
> - John has argued that this will make future namespace changes easier. I
> disagree with this assessment, because -XScopedTypeVariables is utterly
> pervasive. So the problem that this change is supposed to solve becomes
> only a tiny bit smaller, benefiting only those users who carefully enable
> -XPatternSignatures but not, say, -XScopedTypeVariables.
> - But in the end, I don't care all that much. I've come to the opinion
> that we shouldn't worry about the distinction between warnings and
> extensions. The net effect of this proposal is to promote a warning into an
> extension (because we previously had -Wpattern-signature-binds). So if we
> shouldn't worry about this distinction, then this proposal is a no-op on
> the aspects of the language we should care about, and thus accepting and
> rejecting have the same effect. (This little analysis only makes sense
> because the features are so new -- there's no broad re-education to do or
> back-compat issues.)
> - Accepting will make at least one person (John) happy. And I don't note
> anyone who would become unhappy. More happy people is more better. So I
> recommend acceptance. :)
>
> Please let us know your thoughts!
> Richard
> _______________________________________________
> 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/20240222/9209ec6d/attachment.html>

From simon.peytonjones at gmail.com  Thu Feb 22 14:36:38 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 22 Feb 2024 14:36:38 +0000
Subject: [ghc-steering-committee] Shepherding
Message-ID: <CAJKmMz_2YckBv82s2+ZAdAFXWJCzO263d28Teof75gTT-7Yvuw@mail.gmail.com>

Dear shepherds

We still have eight GHC proposals in our inbox, some dating back quite a
long way.  I know that progress is being made on some (thank you), but
others seem to have stalled.

Please could you make time to push our debate forward?  It need not take
long.  But if the shepherd does not push onward, no one else does, and we
really owe our authors a timely response.

I would much prefer not to have to nag you.  I feel bad doing so; but I
also feel bad not doing so.

Thanks!

Spreadsheet here
<https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
Do keep it up to date.

Simon


#434 Unused warnings Chris 2 Jul 2023
#608 -XPatternSignatures without implicit binds Richard 17 Aug 2023
#612 -fhpc tix file changes Moritz 27 Sep 2023
#606 Amendment to #281: atype not ktype Richard 29 Nov 2023
#617 Add -experimental flag Simon M 25 Jan 2024
#631 Type of main fixes return code Arnaud 27 Jan 2024
#592 Scoped kind variables in SAKS Eric 8 Feb 2024
#632 Phased introduction of GHC2024 Adam 15 Feb 2024
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240222/edfd39ca/attachment-0001.html>

From chris at chrisdornan.com  Thu Feb 22 15:23:59 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 22 Feb 2024 15:23:59 +0000
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CAJKmMz_WHTLHWfDb-ALtZaeiJ3rQJv6v3kUrbdNApELnFTz5Sg@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>
Message-ID: <B839D8A8-DC07-408D-A140-9A4A877AB35F@chrisdornan.com>

Thanks Simon.

We clearly need to adopt the -W design and I have asked Jakob to make the switch in the thread.

Chris

> On 22 Feb 2024, at 13:37, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I have suggested further precision in the spec.  And I strongly urge that we use a -W flag not -f flag to control these warnings.  I have suggested a design in  <https://github.com/ghc-proposals/ghc-proposals/pull/434#issuecomment-1959465348>my comment
> 
> With that done, I approve
> 
> Simon
> 
> On Wed, 21 Feb 2024 at 10:41, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> Sorry for the late reply. Last week was LNY week 😓 Just catching up on all the work and other stuff.
>> 
>> I'm with Eric, that this seems fine. And while the -f / -W part is discussed in the alternatives section, I can see reasons for both.
>> 
>> Guess we'll have to see how this plays out. I'm fine with -f or -W and as such +1 from me.
>> 
>> On Tue, 20 Feb 2024 at 05:21, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>>> I'm generally fine with this proposal, but does it seem strange to anyone else that this is a -f flag rather than a new set of -W flags?
>>> 
>>> On Thu, Feb 15, 2024, at 02:23, Chris Dornan wrote:
>>> > Indeed — just a gentle reminder that the deadline for amending or 
>>> > objecting to this proposal is this coming Monday 19th.
>>> >
>>> > Chris
>>> >
>>> >> On 15 Feb 2024, at 07:58, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>> >> 
>>> >> For the record, Jakob has amended the proposal with the flag on by default. I'm now fully good with the proposal.
>>> >> 
>>> >> On Wed, 14 Feb 2024 at 14:22, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>> >>> Thanks Arnaud — I agree with you and have said as much in the thread and asked Jakob to clarify.
>>> >>> 
>>> >>>> On 13 Feb 2024, at 16:57, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>> >>>> 
>>> >>>> I noticed that the default value of the flag is unspecified (I believe that the flag should be on by default, as deactivating transitively unused bindings is pretty situational in my opinion; we may even decide to accept the proposal but without the flag, though I have a feeling that the author wouldn't be willing to implement the flagless version). I made a comment to that effect on Github.
>>> >>>> 
>>> >>>> The rest of the proposal looks good to me.
>>> >>>> 
>>> >>>> On Tue, 13 Feb 2024 at 11:59, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>> >>>>> 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 suppresses the latter unless the -freport-indirectly-unused-bindings flag is specified.
>>> >>>>> 
>>> >>>>> The proposal is concise with some well-chosen examples and I recommend everyone at least skim it.
>>> >>>>> 
>>> >>>>> I propose        that we accept this proposal if nobody objects by the start of next week (Monday, 2024-02-19).
>>> >>>>> 
>>> >>>>> 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
>>> >>>> 
>>> >>>> 
>>> >>>> -- 
>>> >>>> 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
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From moritz.angermann at gmail.com  Fri Feb 23 00:41:20 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 23 Feb 2024 08:41:20 +0800
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CANsrgPJRNyz_u=ehm40aUzVLaUnv6H-t8Qvk_Zm3HfZoGMts7Q@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
 <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
 <CANsrgPJRNyz_u=ehm40aUzVLaUnv6H-t8Qvk_Zm3HfZoGMts7Q@mail.gmail.com>
Message-ID: <CAKfdd-xVviTJfUQDgxcb-P7zjADaAjFaGHyfBLrdUuFsiDaqXg@mail.gmail.com>

Simon,

I see where you are coming from. So let me try to outline how I usually
handle this: this silent change (even with deprecation) likely alters one
of the build products, and hopefully(!) someone will get suspicious
(because the build products are used (otherwise why bother building them
in the first place). Thus someone flags that something with hpc is off. At
which point I'd go and manually investigate what is going on, at _that_
point, I will see this, either because I'm reading the logs, or because the
compiler reports it to me while manually running it.

1. I upgrade the compiler.
2. I observe a change.
3. I try to figure out where the change comes from.

If in (3) or maybe (2), I am told pretty directly what the change is, it's
much easier for me to adjust. Even better if the change message includes
instructions on how to adjust. Even better if someone else can observe the
change, _and_ know as well as having been given actionable advice
on how to proceed. If I can cut myself out of the whole "Something broke, I
looked at it, but can't figure out what's going on, and got way too much
on my hands, please someone else dig into it" situation, it's a win. Not
only for the person experiencing the change (they don't feel helpless, nor
do they
need to ask for assistance), but also for the people supporting these kinds
of issues as they don't come up in the first place.

The difference is between it taking 10min to figure, and providing the
agency to understand and solve it alone, or needing to reach for support it
taking 60+min to figure out and correct, because one has to dig into all
the changes and details. Maybe LLM will cut this a bit because one could
ask "I'm seeing some strange behaviour regarding -fhpc, please provide a
summary of the relevant changes between X and Y".

I like SPJ's suggestion in this thread quite a bit and will ask the Author
about their opinion.

In general we seem to be in agreement around the current default not being
ideal, and somewhat hung on the deprecation notice part. With an
eye on our stability goals, I'd like to see us try light deprecation
warnings. I see that Adams' solution is much more thorough, I also agree
that it's
a lot more involved.

If anyone has qualms around accepting this with a light deprecation notice,
please speak up, otherwise I'll mark this proposal as accepted, and
merge it in a few days after David responded.

Cheers,
 Moritz

On Sat, 27 Jan 2024 at 00:46, Simon Marlow <marlowsd at gmail.com> wrote:

> Moritz - I agree with everything you say about how users will typically
> experience the change, but I don't think a deprecation warning resolves the
> concern. As you say, people might be using HPC via automated tooling and
> will likely not even see the warning, and even if they do see it will
> likely ignore it (I don't know about you, but I don't usually want to be
> distracted by some different yak that needs shaving while I'm coding).
>
> IMO we either have to break it completely - i.e. make the existing usage
> just fail, after a warning cycle - or don't change it at all. We can't
> silently change the behaviour even with a deprecation cycle.
>
> Cheers
> Simon
>
> On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Here's my rationale for a deprecation period.
>>
>> Someone who uses hpc, might rely on the accumulating behaviour.  They
>> need a way to be informed about the upcoming change, otherwise they won't
>> know that they need to pass a new flag going forward (and they can
>> even start doing that at that point to be defensive). I also hope the
>> deprecation note would show up in automated tooling, which can then be
>> proactively adjusted.
>>
>> To me the compiler is _the_ interface to the end user.  Chances that
>> someone reads the proposals, GHC changelog are very low. Chances someone
>> reads the user guide in detail for each GHC release are low as well,
>> only after the fact, if someone broke will someone start trying to figure
>> out why something broke. At that point, I think we've lost. They are
>> frustrated already that something they knew worked just broke.
>>
>> So to me the deprecation note is basically the signage towards the end
>> user that uses hpc, that they will need to adjust their ghc invocation if
>> they rely on the current behaviour, and also a courtesy heads up that the
>> behaviour
>> they might rely on changes, _and_ how to adjust and get their old
>> behaviour (they may need/rely on) back.
>>
>> To address your two points in detail:
>> > Is a deprecation period necessary? Or even useful (how do we signal the
>> upcoming change in default, and how do we expect people would act on it)?
>> - As the flag currently does not exist, call GHC with hpc without the new
>> flag will issue a warning. (e.g. current users will be informed).
>> - The warning message will let the user know what to pass to ghc to
>> retain the old (current) behaviour, or opt in to the new (future current)
>> behaviour, depending on their needs.
>>
>> If we did neither, the user would at some point just notice an existing
>> workflow magically stopped or in this case even worse, the silent
>> aggregation of .tix data would stop, and they
>> might _assume_ the data was the aggregate but it wasn't. A silent change
>> in default behaviour would be rather painful to notice, debug, and rectify
>> for users. At least that's my expectation.
>> (And I know I personally would be furious if a compiler pulled that on
>> me).
>>
>> Best,
>>  Moritz
>>
>> On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> The proposed change seems sensible. At least the argument is convincing.
>>> I don't use hpc myself, so I don't have an actual design opinion besides
>>> that. So I vote (weakly) for the proposed new default.
>>>
>>> Is a deprecation period necessary? Or even useful (how do we signal the
>>> upcoming change in default, and how do we expect people would act on it)?
>>>
>>> On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> Dear Committee members,
>>>>
>>>> In Proposal #612
>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David
>>>> Binder suggests changing the semantics from `-fhpc` to auto-ingest
>>>> existing .tix files for accumulation, towards _not_ auto-ingesting them
>>>> and instead overwriting
>>>> the .tix file with the coverage of the latest run.
>>>>
>>>> I agree with his assessment that the current behaviour easily leads to
>>>> unexpected surprises. He suggests adding a flag --read-tix-file= to control
>>>> this behaviour and defaulting that to _no_, with a grace and
>>>> deprecation period prior informing the user that the currently accumulating
>>>> feature will change in a future GHC release.
>>>>
>>>> Adding the flag to control this behaviour is fairly uncontroversial I
>>>> hope, however I'd like you to. Weight in on the default. Should we change
>>>> the default behaviour, or only add the flag?
>>>>
>>>> I'd recommend changing the default to --read-tix-file=no after a
>>>> deprecation period.
>>>>
>>>> Best,
>>>>  Moritz
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240223/0ad383bc/attachment-0001.html>

From adam at well-typed.com  Fri Feb 23 21:25:32 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 23 Feb 2024 21:25:32 +0000
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
 <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
 <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>
 <CALkkMoREVHvNo-=kW9naqsOFy5MaU9FBp1Q_8Cp8zKZ9E3jFGA@mail.gmail.com>
 <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>
Message-ID: <05447618-2776-4140-bc84-9b0b594d9dc4@well-typed.com>

I'm happy with acceptance.

Adam


On 19/02/2024 21:36, Eric Seidel wrote:
> All, I've only heard from SimonPJ, Arnaud, and Richard. Please voice your assent or dissent. Otherwise I will take silence as assent and accept the proposal this weekend.
> 
> On Wed, Feb 14, 2024, at 15:33, Richard Eisenberg wrote:
>> Yes, looks good to me. This is a natural part of -XExtendedForAllScope.
>> Which, though I dislike, seems to be around for good (and admittedly is
>> quite convenient).
>>
>> On Tue, Feb 13, 2024 at 11:39 AM Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>> I haven't taken time to check that the specification that Vlad wrote is the same as that of -XExtendedForAllScope for type signatures and function definitions. But I trust that Vlad did his homework.
>>>
>>> This makes perfect sense to me, though I'm not sure this is worth spending time on, considering that we seem to be going in the direction to deprecate -XExtendedForAllScope.
>>>
>>> On Mon, 12 Feb 2024 at 23:39, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>>> I support this too.
>>>>
>>>> Simon
>>>>
>>>> On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:
>>>>> Dear Committee,
>>>>>
>>>>> Vlad has found what looks like a clear gap in the interaction between
>>>>> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
>>>>>
>>>>> I think it's quite obvious that under -XExtendedForAllScope the forall
>>>>> in a standalone kind signature should behave like the forall in a
>>>>> standalone type signature, i.e. it should scope over the definition
>>>>> as well.
>>>>>
>>>>> I recommend accepting this amendment to StandaloneKindSignatures.
>>>>>
>>>>> Eric
>>>>>
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/592
>>>>> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
>>>>> _______________________________________________

-- 
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 chris at chrisdornan.com  Sun Feb 25 10:50:03 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 25 Feb 2024 10:50:03 +0000
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
 <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
 <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>
 <CALkkMoREVHvNo-=kW9naqsOFy5MaU9FBp1Q_8Cp8zKZ9E3jFGA@mail.gmail.com>
 <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>
Message-ID: <B080C29A-C27E-4FBA-9E73-9BC7807A78FB@chrisdornan.com>

+1 from me

> On 19 Feb 2024, at 21:36, Eric Seidel <eric at seidel.io> wrote:
> 
> All, I've only heard from SimonPJ, Arnaud, and Richard. Please voice your assent or dissent. Otherwise I will take silence as assent and accept the proposal this weekend.
> 
> On Wed, Feb 14, 2024, at 15:33, Richard Eisenberg wrote:
>> Yes, looks good to me. This is a natural part of -XExtendedForAllScope. 
>> Which, though I dislike, seems to be around for good (and admittedly is 
>> quite convenient).
>> 
>> On Tue, Feb 13, 2024 at 11:39 AM Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>> I haven't taken time to check that the specification that Vlad wrote is the same as that of -XExtendedForAllScope for type signatures and function definitions. But I trust that Vlad did his homework.
>>> 
>>> This makes perfect sense to me, though I'm not sure this is worth spending time on, considering that we seem to be going in the direction to deprecate -XExtendedForAllScope.
>>> 
>>> On Mon, 12 Feb 2024 at 23:39, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>>> I support this too.
>>>> 
>>>> Simon
>>>> 
>>>> On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:
>>>>> Dear Committee,
>>>>> 
>>>>> Vlad has found what looks like a clear gap in the interaction between
>>>>> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
>>>>> 
>>>>> I think it's quite obvious that under -XExtendedForAllScope the forall
>>>>> in a standalone kind signature should behave like the forall in a
>>>>> standalone type signature, i.e. it should scope over the definition
>>>>> as well.
>>>>> 
>>>>> I recommend accepting this amendment to StandaloneKindSignatures.
>>>>> 
>>>>> Eric
>>>>> 
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/592
>>>>> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> 
>>> 
>>> -- 
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> 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 chris at chrisdornan.com  Sun Feb 25 10:53:27 2024
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 25 Feb 2024 10:53:27 +0000
Subject: [ghc-steering-committee] Proposal #612: Change semantics of
 -fhpc to not accumulate data over multiple runs, rec: accept
In-Reply-To: <CAKfdd-xVviTJfUQDgxcb-P7zjADaAjFaGHyfBLrdUuFsiDaqXg@mail.gmail.com>
References: <CAKfdd-y9z3V1qyN-nEkjKK2bbpdXJ_KWx2yP9nj3OWr9Vb_WdQ@mail.gmail.com>
 <CAGwnsn=YkEtx3xSPbjvm9bde2hd7kfzwptKnoxqUBhVRuAC3FA@mail.gmail.com>
 <CAKfdd-zTz0Ko8pm+PpW4uH+GoOBxdy2svt2A53yFCmhQzhxXXw@mail.gmail.com>
 <CANsrgPJRNyz_u=ehm40aUzVLaUnv6H-t8Qvk_Zm3HfZoGMts7Q@mail.gmail.com>
 <CAKfdd-xVviTJfUQDgxcb-P7zjADaAjFaGHyfBLrdUuFsiDaqXg@mail.gmail.com>
Message-ID: <00A415C3-13C5-4984-B27A-5315E16D3EC3@chrisdornan.com>

I am fine with a light depracation notice : +1 from me.

> On 23 Feb 2024, at 00:41, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> Simon,
> 
> I see where you are coming from. So let me try to outline how I usually handle this: this silent change (even with deprecation) likely alters one
> of the build products, and hopefully(!) someone will get suspicious (because the build products are used (otherwise why bother building them
> in the first place). Thus someone flags that something with hpc is off. At which point I'd go and manually investigate what is going on, at _that_
> point, I will see this, either because I'm reading the logs, or because the compiler reports it to me while manually running it.
> 
> 1. I upgrade the compiler.
> 2. I observe a change.
> 3. I try to figure out where the change comes from.
> 
> If in (3) or maybe (2), I am told pretty directly what the change is, it's much easier for me to adjust. Even better if the change message includes
> instructions on how to adjust. Even better if someone else can observe the change, _and_ know as well as having been given actionable advice
> on how to proceed. If I can cut myself out of the whole "Something broke, I looked at it, but can't figure out what's going on, and got way too much
> on my hands, please someone else dig into it" situation, it's a win. Not only for the person experiencing the change (they don't feel helpless, nor do they
> need to ask for assistance), but also for the people supporting these kinds of issues as they don't come up in the first place.
> 
> The difference is between it taking 10min to figure, and providing the agency to understand and solve it alone, or needing to reach for support it
> taking 60+min to figure out and correct, because one has to dig into all the changes and details. Maybe LLM will cut this a bit because one could
> ask "I'm seeing some strange behaviour regarding -fhpc, please provide a summary of the relevant changes between X and Y".
> 
> I like SPJ's suggestion in this thread quite a bit and will ask the Author about their opinion.
> 
> In general we seem to be in agreement around the current default not being ideal, and somewhat hung on the deprecation notice part. With an
> eye on our stability goals, I'd like to see us try light deprecation warnings. I see that Adams' solution is much more thorough, I also agree that it's
> a lot more involved. 
> 
> If anyone has qualms around accepting this with a light deprecation notice, please speak up, otherwise I'll mark this proposal as accepted, and
> merge it in a few days after David responded.
> 
> Cheers,
>  Moritz
> 
> On Sat, 27 Jan 2024 at 00:46, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
>> Moritz - I agree with everything you say about how users will typically experience the change, but I don't think a deprecation warning resolves the concern. As you say, people might be using HPC via automated tooling and will likely not even see the warning, and even if they do see it will likely ignore it (I don't know about you, but I don't usually want to be distracted by some different yak that needs shaving while I'm coding).
>> 
>> IMO we either have to break it completely - i.e. make the existing usage just fail, after a warning cycle - or don't change it at all. We can't silently change the behaviour even with a deprecation cycle.
>> 
>> Cheers
>> Simon
>> 
>> On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>> Here's my rationale for a deprecation period.
>>> 
>>> Someone who uses hpc, might rely on the accumulating behaviour.  They need a way to be informed about the upcoming change, otherwise they won't know that they need to pass a new flag going forward (and they can
>>> even start doing that at that point to be defensive). I also hope the deprecation note would show up in automated tooling, which can then be proactively adjusted.
>>> 
>>> To me the compiler is _the_ interface to the end user.  Chances that someone reads the proposals, GHC changelog are very low. Chances someone reads the user guide in detail for each GHC release are low as well,
>>> only after the fact, if someone broke will someone start trying to figure out why something broke. At that point, I think we've lost. They are frustrated already that something they knew worked just broke. 
>>> 
>>> So to me the deprecation note is basically the signage towards the end user that uses hpc, that they will need to adjust their ghc invocation if they rely on the current behaviour, and also a courtesy heads up that the behaviour
>>> they might rely on changes, _and_ how to adjust and get their old behaviour (they may need/rely on) back.
>>> 
>>> To address your two points in detail:
>>> > Is a deprecation period necessary? Or even useful (how do we signal the upcoming change in default, and how do we expect people would act on it)?
>>> - As the flag currently does not exist, call GHC with hpc without the new flag will issue a warning. (e.g. current users will be informed).
>>> - The warning message will let the user know what to pass to ghc to retain the old (current) behaviour, or opt in to the new (future current) behaviour, depending on their needs.
>>> 
>>> If we did neither, the user would at some point just notice an existing workflow magically stopped or in this case even worse, the silent aggregation of .tix data would stop, and they
>>> might _assume_ the data was the aggregate but it wasn't. A silent change in default behaviour would be rather painful to notice, debug, and rectify for users. At least that's my expectation.
>>> (And I know I personally would be furious if a compiler pulled that on me).
>>> 
>>> Best,
>>>  Moritz
>>> 
>>> On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>> The proposed change seems sensible. At least the argument is convincing. I don't use hpc myself, so I don't have an actual design opinion besides that. So I vote (weakly) for the proposed new default.
>>>> 
>>>> Is a deprecation period necessary? Or even useful (how do we signal the upcoming change in default, and how do we expect people would act on it)?
>>>> 
>>>> On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>>>> Dear Committee members,
>>>>> 
>>>>> In Proposal #612 <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder suggests changing the semantics from `-fhpc` to auto-ingest
>>>>> existing .tix files for accumulation, towards _not_ auto-ingesting them and instead overwriting
>>>>> the .tix file with the coverage of the latest run.
>>>>> 
>>>>> I agree with his assessment that the current behaviour easily leads to unexpected surprises. He suggests adding a flag --read-tix-file= to control this behaviour and defaulting that to _no_, with a grace and deprecation period prior informing the user that the currently accumulating feature will change in a future GHC release.
>>>>> 
>>>>> Adding the flag to control this behaviour is fairly uncontroversial I hope, however I'd like you to. Weight in on the default. Should we change the default behaviour, or only add the flag?
>>>>> 
>>>>> I'd recommend changing the default to --read-tix-file=no after a deprecation period.
>>>>> 
>>>>> Best,
>>>>>  Moritz
>>>>> _______________________________________________
>>>>> 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
> _______________________________________________
> 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/20240225/e9bfe677/attachment-0001.html>

From eric at seidel.io  Sun Feb 25 21:41:48 2024
From: eric at seidel.io (Eric Seidel)
Date: Sun, 25 Feb 2024 14:41:48 -0700
Subject: [ghc-steering-committee] Proposal #592: Scoped kind variables
 in standalone kind signatures (recommend accept)
In-Reply-To: <B080C29A-C27E-4FBA-9E73-9BC7807A78FB@chrisdornan.com>
References: <ff70a065-f325-4644-abd1-3a75583868c9@well-typed.com>
 <978f7e2a-393f-4c1c-bf6a-c6658a2ba5ab@app.fastmail.com>
 <CAJKmMz8_eOhZJcxn4NtChZ+M4-U+Osw18vChqcA_eo8scbk_ew@mail.gmail.com>
 <CAGwnsnkoJKkFtGc+K74JGzcGV8Ot5jt5SX7TFEC=C3CGKHMe=w@mail.gmail.com>
 <CALkkMoREVHvNo-=kW9naqsOFy5MaU9FBp1Q_8Cp8zKZ9E3jFGA@mail.gmail.com>
 <de45931e-e4f4-45f2-a8ec-5a1e2caecf60@app.fastmail.com>
 <B080C29A-C27E-4FBA-9E73-9BC7807A78FB@chrisdornan.com>
Message-ID: <13cc6d41-1818-4b30-af75-529145dfb4d9@app.fastmail.com>

Thanks all for your comments, I have accepted the proposal.

On Sun, Feb 25, 2024, at 03:50, Chris Dornan wrote:
> +1 from me
>
>> On 19 Feb 2024, at 21:36, Eric Seidel <eric at seidel.io> wrote:
>> 
>> All, I've only heard from SimonPJ, Arnaud, and Richard. Please voice your assent or dissent. Otherwise I will take silence as assent and accept the proposal this weekend.
>> 
>> On Wed, Feb 14, 2024, at 15:33, Richard Eisenberg wrote:
>>> Yes, looks good to me. This is a natural part of -XExtendedForAllScope. 
>>> Which, though I dislike, seems to be around for good (and admittedly is 
>>> quite convenient).
>>> 
>>> On Tue, Feb 13, 2024 at 11:39 AM Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>>> I haven't taken time to check that the specification that Vlad wrote is the same as that of -XExtendedForAllScope for type signatures and function definitions. But I trust that Vlad did his homework.
>>>> 
>>>> This makes perfect sense to me, though I'm not sure this is worth spending time on, considering that we seem to be going in the direction to deprecate -XExtendedForAllScope.
>>>> 
>>>> On Mon, 12 Feb 2024 at 23:39, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>>>> I support this too.
>>>>> 
>>>>> Simon
>>>>> 
>>>>> On Sat, 10 Feb 2024 at 03:10, Eric Seidel <eric at seidel.io> wrote:
>>>>>> Dear Committee,
>>>>>> 
>>>>>> Vlad has found what looks like a clear gap in the interaction between
>>>>>> two extensions: -XStandaloneKindSignatures and -XExtendedForAllScope.
>>>>>> 
>>>>>> I think it's quite obvious that under -XExtendedForAllScope the forall
>>>>>> in a standalone kind signature should behave like the forall in a
>>>>>> standalone type signature, i.e. it should scope over the definition
>>>>>> as well.
>>>>>> 
>>>>>> I recommend accepting this amendment to StandaloneKindSignatures.
>>>>>> 
>>>>>> Eric
>>>>>> 
>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/592
>>>>>> https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-kind-signatures.rst#proposed-change-specification
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> 
>>>> 
>>>> -- 
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> 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 rae at richarde.dev  Mon Feb 26 13:29:50 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 26 Feb 2024 13:29:50 +0000
Subject: [ghc-steering-committee] Proposal #608,
 -XPatternSignatureBinds. Rec: accept
In-Reply-To: <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
References: <010f018d3c87f5e9-946e87dc-932b-4cf4-aea3-f65c9d09f4a0-000000@us-east-2.amazonses.com>
 <CANsrgPK1H_NmKqY8-xX+B76jiW4Pxbp19RaH+ExX33e6zz47gw@mail.gmail.com>
Message-ID: <010f018de59b8405-79d2db1b-2f36-4d43-b1a4-60798788e7d2-000000@us-east-2.amazonses.com>



> On Jan 29, 2024, at 6:03 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> I might be a bit confused, but doesn't this proposal change the meaning of an existing extension (PatternSignatures)? In which case shouldn't we do it properly according to our stability principles and either introduce the new behaviour as a new extension, or restrict the change to GHC2024 and later only?
> 

Picking up this thread again (sorry for the delay).

As a reminder to all, about where we stand: This is about a small change to the deprecated extension -XPatternSignatures (which has been deprecated for at least as long as I've been doing Haskell). I personally don't see much merit in the change (it seems to achieve its goal only in a world where -XScopedTypeVariables is somehow deprecated, and that world seems unlikely to me), but neither do I see much downside. John Ericson, the proposer, sees an upside to the change, as does Joachim. We had basically settled leaning toward acceptance. Simon M wonders above about how this interacts with our stability principles.

In response to Simon: I think this is fine w.r.t. our stability principles, which include (GR3), saying that any change should come with a deprecation period. -XPatternSignatures has been deprecated for over a decade, which I think is sufficiently long. On the other hand, the deprecation doesn't describe the upcoming change, but I still think it's OK.

Richard

From rae at richarde.dev  Mon Feb 26 13:42:50 2024
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 26 Feb 2024 13:42:50 +0000
Subject: [ghc-steering-committee] Proposal #606: small syntax change
 around types in terms; recommendation: vote
In-Reply-To: <CAJKmMz9MVHJWyipdWo1HxGcDG+fSXOA-iVkTQVfUf-br7y19qA@mail.gmail.com>
References: <010f018d3ccbfd87-f2b70ca6-0be3-4727-b10f-558dbdbcde60-000000@us-east-2.amazonses.com>
 <CAJKmMz9MVHJWyipdWo1HxGcDG+fSXOA-iVkTQVfUf-br7y19qA@mail.gmail.com>
Message-ID: <010f018de5a76910-abe1aa85-eb6d-4b96-9f26-fb00641457e2-000000@us-east-2.amazonses.com>

I've been on the fence, as have others here. Simon PJ describes himself as being far from the fence -- and in the same place as Vlad, our proposer and intrepid implementer. So while I'm not deeply convinced in my soul about this, I think the right choice as a committee is to go with option (2) in this thread (which is what the proposer is asking for).

I don't see much of a reason to keep extending this debate (everyone who is saying they care strongly is getting their way), but out of courtesy let's extend this to the end of the month (one extra day this year!). If I don't hear further comments, I'll accept this on Thursday.

Thanks!
Richard

> On Jan 25, 2024, at 7:07 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I vote (2), fairly strongly
> 
> Remember this comment from Vlad:
> 
> @phadej <https://github.com/phadej> For what it's worth, this was my initial thinking when I put ktype there, so past me agrees with you. What changed my opinion is that two years later (i.e. now) I looked at the examples like fn (type Int -> [a]) and had to double check the specification if it was supposed to be fn ((type Int) -> [a]) or fn (type (Int -> [a])).
> 
> The point is that the `type` namespace changer can appear deep within a type.  It's not like "@"!    For exmaple
> fn ((type K) -> [a])
> makes perfect sense.  fn has a required type argument, but in the (type K) sub-part of the type do we switch to the type namespace.  (Maybe K is in scope also as a data constructor.)  Without the parens, do you really want to wonder about how this parses?
> fn (type K -> [a])
> 
> I prefer code that is slightly longer, but much clearer, than saving two characters but requiring reference to the user manual to parse.
> 
> Let's make it simple and unambiguous for now.  If it seems painful in practice we can debate liberalising it.
> 
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20240226/659b23cf/attachment.html>

From arnaud.spiwack at tweag.io  Thu Feb 29 10:28:37 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 29 Feb 2024 11:28:37 +0100
Subject: [ghc-steering-committee] Proposal #631: Set program exit code by
 main return type, recommendation: accept something
Message-ID: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>

Dear all,

Shea Levy proposes to do something with the values returned by `main`
https://github.com/ghc-proposals/ghc-proposals/pull/631 .

The problem is that `main` is allowed to be of type `IO A` for any `A`. And
GHC will simply drop the value returned by `main`. Shea contends that it's
surprising. I agree that dropping a value without the compiler being
explicitly instructed to is surprising. But Shea says that when `A` is
`ExitCode` this is even more surprising. Namely `main :: IO ExitCode; main
= return $ Failure 1` actually terminates with exit code 0. And I doubt
that it's what anybody expects when reading the code.

The proposal is simple, but I have a lot of comments on it. Sorry about
that…

Now, this sort of proposal is tricky. When the current behaviour is
confusing, we want to change the default. But putting the new default
behind an extension doesn't really solve the fact that there's a trap. The
extension is, therefore, unlikely to be well tested before it becomes part
of the next language edition.

Shea's main proposition doesn't actually use an extension though. He adds a
type class `ExitStatus`, and if `ExistStatus A`, then `main :: IO A` uses
the instance to determine the exit code based on the return value.

The only change to the current behaviour is that `main :: IO ExitCode`
instead of always terminating with exit code 0 when returning now
terminates with the expected error code. The argument for not putting this
behind an extension is that virtually anybody affected by the change will
actually have the behaviour they were expecting. But maybe the argument
isn't strong enough (the changes may be more “interesting” if some library
exports some `ExistStatus` instance).

This design of this proposal is inspired by Rust's design. I've asked our
Rust team, and they certainly seem to have internalised the idea of
returning an exit code. It really seems a pretty natural feature to have.
So I'm rather in favour of some flavour of the type class implementation.
Though have a look at the alternatives, where you'll find other approaches
such as restricting the type of `main` to unsurprising types.

One caveat with respect to the main proposal: it is proposed that when no
`ExistStatus A` is found, then we drop the returned value like today. I
don't know that it's quite easy to implement this behaviour. But it can be
recovered by a catch-all overlapping instance, so maybe it's a better way
to specify the desired behaviour.

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240229/a3c7702c/attachment.html>

From reisenberg at janestreet.com  Thu Feb 29 12:38:23 2024
From: reisenberg at janestreet.com (Richard Eisenberg)
Date: Thu, 29 Feb 2024 07:38:23 -0500
Subject: [ghc-steering-committee] Proposal #631: Set program exit code
 by main return type, recommendation: accept something
In-Reply-To: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
References: <CAGwnsnnfby3cnOaNvjk=U=zZDxez324aBTt5WLrwSQoFBHPMTQ@mail.gmail.com>
Message-ID: <CALkkMoRU=GQBaBezJECe9HDuuHe6PQY6-y_OjixWqw_s05Uscg@mail.gmail.com>

I haven't followed this proposal closely. But couldn't we have a transition
period toward this eventual goal? That is, introduce a new warning, on by
default, if `main` returns anything other than `()`. That goes for a few
releases. Then we require that the return type of main has an instance of
ExitStatus.

I'm not worried about changing the behavior of programs that have type IO
ExitCode but expect the program to return 0 unconditionally; that's just
begging for confusion. I am a little worried about breaking programs that
end in an innocent-looking `return 0`, just because some other languages
like to end programs with that phrase. So I'm not sure if we should have an
instance ExitStatus Int (or instance ExitStatus Integer) -- but we probably
should. If a program ends with `return 1`, the programmer probably wants
the OS to return 1 as well.

Richard

On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> Shea Levy proposes to do something with the values returned by `main`
> https://github.com/ghc-proposals/ghc-proposals/pull/631 .
>
> The problem is that `main` is allowed to be of type `IO A` for any `A`.
> And GHC will simply drop the value returned by `main`. Shea contends that
> it's surprising. I agree that dropping a value without the compiler being
> explicitly instructed to is surprising. But Shea says that when `A` is
> `ExitCode` this is even more surprising. Namely `main :: IO ExitCode; main
> = return $ Failure 1` actually terminates with exit code 0. And I doubt
> that it's what anybody expects when reading the code.
>
> The proposal is simple, but I have a lot of comments on it. Sorry about
> that…
>
> Now, this sort of proposal is tricky. When the current behaviour is
> confusing, we want to change the default. But putting the new default
> behind an extension doesn't really solve the fact that there's a trap. The
> extension is, therefore, unlikely to be well tested before it becomes part
> of the next language edition.
>
> Shea's main proposition doesn't actually use an extension though. He adds
> a type class `ExitStatus`, and if `ExistStatus A`, then `main :: IO A` uses
> the instance to determine the exit code based on the return value.
>
> The only change to the current behaviour is that `main :: IO ExitCode`
> instead of always terminating with exit code 0 when returning now
> terminates with the expected error code. The argument for not putting this
> behind an extension is that virtually anybody affected by the change will
> actually have the behaviour they were expecting. But maybe the argument
> isn't strong enough (the changes may be more “interesting” if some library
> exports some `ExistStatus` instance).
>
> This design of this proposal is inspired by Rust's design. I've asked our
> Rust team, and they certainly seem to have internalised the idea of
> returning an exit code. It really seems a pretty natural feature to have.
> So I'm rather in favour of some flavour of the type class implementation.
> Though have a look at the alternatives, where you'll find other approaches
> such as restricting the type of `main` to unsurprising types.
>
> One caveat with respect to the main proposal: it is proposed that when no
> `ExistStatus A` is found, then we drop the returned value like today. I
> don't know that it's quite easy to implement this behaviour. But it can be
> recovered by a catch-all overlapping instance, so maybe it's a better way
> to specify the desired behaviour.
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240229/cb45afbc/attachment.html>