From sgraf1337 at gmail.com Tue Aug 5 12:23:35 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 5 Aug 2025 14:23:35 +0200 Subject: [ghc-steering-committee] #705: Explicit Level Imports: refine specification for exports, recommendation: accept In-Reply-To: References: Message-ID: I vote to accept the proposal as is or with the wording improvements that Simon suggested. Sebastian Am Fr., 25. Juli 2025 um 01:48 Uhr schrieb Arnaud Spiwack via ghc-steering-committee : > Dear all, > > Matthew and team propose a very short revision of their accepted proposal > for explicit level imports (this proposal, if you don't remember, is about > being more precise, when importing modules, whether they need to be > available to emit code, or also for Template Haskell, for better > recompilation avoidance and cross-compilation support). > > I say revision, but really, this simply specifies some corner cases which, > admittedly, were ambiguous with the original wording of the proposal. > There's nothing controversial about it. We should accept very quickly. > > I'll be on holiday the next couple of weeks, so I won't be able to act on > this for a while. I don't think it's worth waiting two weeks though. So > Adam, unless someone complains, probably accept it at the end of next week. > > Best, > Arnaud > > -- > 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: From adam at well-typed.com Thu Aug 7 19:56:14 2025 From: adam at well-typed.com (Adam Gundry) Date: Thu, 7 Aug 2025 20:56:14 +0100 Subject: [ghc-steering-committee] #705: Explicit Level Imports: refine specification for exports, recommendation: accept In-Reply-To: References: Message-ID: Given the support from Arnaud, Sebastian and Simon, and lack of dissent, I'm happy to declare this proposal accepted in Arnaud's absence. Adam On 05/08/2025 13:23, Sebastian Graf via ghc-steering-committee wrote: > I vote to accept the proposal as is or with the wording improvements > that Simon suggested. > > Sebastian > > Am Fr., 25. Juli 2025 um 01:48 Uhr schrieb Arnaud Spiwack via ghc- > steering-committee steering-committee at haskell.org>>: > > Dear all, > > Matthew and team propose a very short revision of their accepted > proposal for explicit level imports (this proposal, if you don't > remember, is about being more precise, when importing modules, > whether they need to be available to emit code, or also for Template > Haskell, for better recompilation avoidance and cross-compilation > support). > > I say revision, but really, this simply specifies some corner cases > which, admittedly, were ambiguous with the original wording of the > proposal. There's nothing controversial about it. We should accept > very quickly. > > I'll be on holiday the next couple of weeks, so I won't be able to > act on this for a while. I don't think it's worth waiting two weeks > though. So Adam, unless someone complains, probably accept it at the > end of next week. > > Best, > Arnaud > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com moduscreate.com> and https://tweag.io . -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From adam at well-typed.com Thu Aug 7 20:10:19 2025 From: adam at well-typed.com (Adam Gundry) Date: Thu, 7 Aug 2025 21:10:19 +0100 Subject: [ghc-steering-committee] Please review #669: Initial categorization of language extensions In-Reply-To: References: <6581139a-1784-4ecd-81e4-13a7848d9d27@well-typed.com> Message-ID: Hi Malte, This proposal looks like it could be accepted, but I'm not sure if any final polishing is needed? Let's please try not to let proposals linger in the committee review state for too long! Thanks, Adam On 07/07/2025 14:51, Matthías Páll Gissurarson via ghc-steering-committee wrote: > The list seems reasonable. I vote accept. > > On Mon, 7 Jul 2025 at 06:24, Sebastian Graf via ghc-steering-committee > committee at haskell.org>> wrote: > > I vote accept as well. > > Am Sa., 5. Juli 2025 um 17:11 Uhr schrieb Jakob Brünker via ghc- > steering-committee steering-committee at haskell.org>>: > > This all seems very reasonable to me. I vote to accept. > > Jakob > > On Wed, Jul 2, 2025 at 4:59 PM Simon Peyton Jones via ghc- > steering-committee > wrote: > > I'm in support of this proposal. > > There is some discussion around the corners but lets get it > done! > > Simon > > On Mon, 23 Jun 2025 at 14:12, Malte Ott via ghc-steering- > committee steering-committee at haskell.org>> wrote: > > Dear Committee, > > On 2024-10-29 19:45, Adam Gundry wrote: > > Trevis Elser proposes a classification of (some) > language extensions based > > on previous work in proposal #601 establishing > categories: > > > > https://github.com/ghc-proposals/ghc-proposals/ > pull/669 proposals/pull/669> > > > > https://github.com/telser/ghc-proposals/blob/initial- > extension-categorization/proposals/0000-extension- > categorization.md proposals/blob/initial-extension-categorization/ > proposals/0000-extension-categorization.md> > > (Note that additionally to adding the new proposal the > PR also contains a small diff to the previous proposal > #601.) > > This proposal rested for a while, but after some > revisions at Zurihac I am > recommending to accept this proposal. The proposal is > the logical next step after > the acceptance of #601. It’s not pretty to have a > categorization but not use it > and I think the classification is very helpful to guide > users and us. > > In the proposal Trevis nominates > > 72 extensions as stable, > 10 extensions as deprecated, >  5 extensions as legacy, >  8 extensions as experimental > > and > > 42 remain unclassified. > > This only affects documentation and our future > decisions. Only observable > change in GHC will be that deprecated extensions > consistently get a warning > via -Wdeprecated-flags. > > The intention is to basically just describe the status > quo with the > classification and defer all contentious extensions to > be classified later. > > My general tendency is that we should err in the > direction of marking > extensions stable because at least for widely used > extensions, even those where > we are not very happy with the design, marking them > experimental is like giving > us a free pass to break our stability principle. Also > marking an extension > stable is not the same as "recommended" as it is > perfectly fine for an extension > to be stable but not part of a GHCXXXX language edition. > > Note that "For an extension to be classified as Stable > it must be considered > Stable when used in combination of all possible, non- > mutually exclusive, > extensions that are already Stable." I admit that I > cannot judge this with > certainty for all listed extensions. To be honest I > learned e.g. of the > existence of NoTraditionalRecordSyntax from reading the > list. While I have been > told that the categorization has been produced in close > collaboration with GHC > devs I ask everyone to keep this in mind when reviewing > the list. > > Please review the overall proposal and the proposed > categories. You can give > your approval conditional on moving some extensions to > "unclassified". Others > and I have already done so, so from my point of view the > list is good as is. > > Best, > Malte -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From malte.ott at maralorn.de Thu Aug 7 21:23:12 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Thu, 7 Aug 2025 23:23:12 +0200 Subject: [ghc-steering-committee] Please review #669: Initial categorization of language extensions In-Reply-To: References: <6581139a-1784-4ecd-81e4-13a7848d9d27@well-typed.com> Message-ID: Ah, I wholeheartedly agree. Sorry, for the delay. There were no polishing requirements that I know of, so I accepted the proposal. Thanks everyone. Best, Malte On 2025-08-07 21:10, Adam Gundry wrote: > Hi Malte, > > This proposal looks like it could be accepted, but I'm not sure if any final > polishing is needed? > > Let's please try not to let proposals linger in the committee review state > for too long! > > Thanks, > > Adam > > > > On 07/07/2025 14:51, Matthías Páll Gissurarson via ghc-steering-committee > wrote: > > The list seems reasonable. I vote accept. > > > > On Mon, 7 Jul 2025 at 06:24, Sebastian Graf via ghc-steering-committee > > > committee at haskell.org>> wrote: > > > > I vote accept as well. > > > > Am Sa., 5. Juli 2025 um 17:11 Uhr schrieb Jakob Brünker via ghc- > > steering-committee > steering-committee at haskell.org>>: > > > > This all seems very reasonable to me. I vote to accept. > > > > Jakob > > > > On Wed, Jul 2, 2025 at 4:59 PM Simon Peyton Jones via ghc- > > steering-committee > > wrote: > > > > I'm in support of this proposal. > > > > There is some discussion around the corners but lets get it > > done! > > > > Simon > > > > On Mon, 23 Jun 2025 at 14:12, Malte Ott via ghc-steering- > > committee > steering-committee at haskell.org>> wrote: > > > > Dear Committee, > > > > On 2024-10-29 19:45, Adam Gundry wrote: > > > Trevis Elser proposes a classification of (some) > > language extensions based > > > on previous work in proposal #601 establishing > > categories: > > > > > > https://github.com/ghc-proposals/ghc-proposals/ > > pull/669 > proposals/pull/669> > > > > > > https://github.com/telser/ghc-proposals/blob/initial- > > extension-categorization/proposals/0000-extension- > > categorization.md > proposals/blob/initial-extension-categorization/ > > proposals/0000-extension-categorization.md> > > > > (Note that additionally to adding the new proposal the > > PR also contains a small diff to the previous proposal > > #601.) > > > > This proposal rested for a while, but after some > > revisions at Zurihac I am > > recommending to accept this proposal. The proposal is > > the logical next step after > > the acceptance of #601. It’s not pretty to have a > > categorization but not use it > > and I think the classification is very helpful to guide > > users and us. > > > > In the proposal Trevis nominates > > > > 72 extensions as stable, > > 10 extensions as deprecated, > >  5 extensions as legacy, > >  8 extensions as experimental > > > > and > > > > 42 remain unclassified. > > > > This only affects documentation and our future > > decisions. Only observable > > change in GHC will be that deprecated extensions > > consistently get a warning > > via -Wdeprecated-flags. > > > > The intention is to basically just describe the status > > quo with the > > classification and defer all contentious extensions to > > be classified later. > > > > My general tendency is that we should err in the > > direction of marking > > extensions stable because at least for widely used > > extensions, even those where > > we are not very happy with the design, marking them > > experimental is like giving > > us a free pass to break our stability principle. Also > > marking an extension > > stable is not the same as "recommended" as it is > > perfectly fine for an extension > > to be stable but not part of a GHCXXXX language edition. > > > > Note that "For an extension to be classified as Stable > > it must be considered > > Stable when used in combination of all possible, non- > > mutually exclusive, > > extensions that are already Stable." I admit that I > > cannot judge this with > > certainty for all listed extensions. To be honest I > > learned e.g. of the > > existence of NoTraditionalRecordSyntax from reading the > > list. While I have been > > told that the categorization has been produced in close > > collaboration with GHC > > devs I ask everyone to keep this in mind when reviewing > > the list. > > > > Please review the overall proposal and the proposed > > categories. You can give > > your approval conditional on moving some extensions to > > "unclassified". Others > > and I have already done so, so from my point of view the > > list is good as is. > > > > Best, > > Malte > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > From arnaud.spiwack at tweag.io Wed Aug 13 12:13:19 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 13 Aug 2025 14:13:19 +0200 Subject: [ghc-steering-committee] #705: Explicit Level Imports: refine specification for exports, recommendation: accept In-Reply-To: References: Message-ID: Thanks Adam for handling this. Also, sorry everybody: I've just realised I forgot to include the link to the PR in my email (it's here for the record https://github.com/ghc-proposals/ghc-proposals/pull/705 ). /Arnaud On Thu, 7 Aug 2025 at 21:56, Adam Gundry via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Given the support from Arnaud, Sebastian and Simon, and lack of dissent, > I'm happy to declare this proposal accepted in Arnaud's absence. > > Adam > > > On 05/08/2025 13:23, Sebastian Graf via ghc-steering-committee wrote: > > I vote to accept the proposal as is or with the wording improvements > > that Simon suggested. > > > > Sebastian > > > > Am Fr., 25. Juli 2025 um 01:48 Uhr schrieb Arnaud Spiwack via ghc- > > steering-committee > steering-committee at haskell.org>>: > > > > Dear all, > > > > Matthew and team propose a very short revision of their accepted > > proposal for explicit level imports (this proposal, if you don't > > remember, is about being more precise, when importing modules, > > whether they need to be available to emit code, or also for Template > > Haskell, for better recompilation avoidance and cross-compilation > > support). > > > > I say revision, but really, this simply specifies some corner cases > > which, admittedly, were ambiguous with the original wording of the > > proposal. There's nothing controversial about it. We should accept > > very quickly. > > > > I'll be on holiday the next couple of weeks, so I won't be able to > > act on this for a while. I don't think it's worth waiting two weeks > > though. So Adam, unless someone complains, probably accept it at the > > end of next week. > > > > Best, > > Arnaud > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com > moduscreate.com> and https://tweag.io . > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri Aug 15 12:07:58 2025 From: adam at well-typed.com (Adam Gundry) Date: Fri, 15 Aug 2025 13:07:58 +0100 Subject: [ghc-steering-committee] Proposal process refinements, removal of Markdown option Message-ID: <56c8550a-3543-4da4-ac1d-eedab8816797@well-typed.com> Hi everyone, There is some discussion going on around refining the proposal process documentation in this PR from VitWW: https://github.com/ghc-proposals/ghc-proposals/pull/712 https://github.com/VitWW/ghc-proposals/blob/update-readme/README.rst I'm not planning to send this PR through the full review process itself, but I wanted to flag it up in case anyone from the committee wishes to comment. One point in particular to note is the removal of Markdown format as an option for authors, so that all proposals will be ReStructuredText. It seems this was agreed in principle several years ago, but not subsequently implemented, per this discussion: https://github.com/ghc-proposals/ghc-proposals/issues/560 If anyone objects to this change, please do speak up. 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