From arnaud.spiwack at tweag.io Tue Jul 1 08:31:57 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 1 Jul 2025 17:31:57 +0900 Subject: [ghc-steering-committee] Please review #696: Splitting out stable interfaces from template-haskell In-Reply-To: References: <62a93f67-d413-4232-9b1e-deb64048dad0@well-typed.com> Message-ID: I did post a couple of reservations on the issue. But whatever we end up deciding, I'm in favour anyway. They're, I suppose, a bit on the bikeshedding side. Worth spending a little bit of time on, but not too much. On Mon, 30 Jun 2025 at 17:27, Sebastian Graf via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > I think the renaming proposed by Adam is uncontroversial and I will > include this revision when accepting the proposal. > > Am Do., 26. Juni 2025 um 10:25 Uhr schrieb Adam Gundry < > adam at well-typed.com>: > >> I'm also in favour. >> >> I am suggesting some small naming changes, and I would point out one >> detail on which the committee may have opinions as to bikeshed colour, >> namely the module namespace to be used by the new packages. Teo proposes >> >> template-haskell-lift with module TemplateHaskell.Lift >> template-haskell-quasiquote with module TemplateHaskell.Quasiquoter >> >> and I suggest slightly tweaking the latter to >> >> template-haskell-quasiquoter with module TemplateHaskell.QuasiQuoter >> >> for consistency with the QuasiQuoter type name. >> >> In both cases, the module name is in a new TemplateHaskell module >> hierarchy, whereas the existing template-haskell package uses the >> Language.Haskell.TH module hierarchy. I think a renaming is in order, >> because it gives a clear distinction between the historic API of the old >> template-haskell package and the cleaned up APIs of the new packages. >> Personally I like the new names, but I wanted to check others are also >> happy with them? >> >> Cheers, >> >> Adam >> >> >> >> On 23/06/2025 08:55, Sebastian Graf wrote: >> > Dear Committee, >> > >> > With their proposal, Teo wants to reduce the maintenance cost for >> > packages (such as `containers`) that depend on `template-haskell` only >> > for comparatively stable APIs (`Lift`, quasiquoting), by carving out >> > separate packages for these stable APIs. >> > These so-called "type (A) clients" constitute a considerable share of >> > all clients of `template-haskell`. It is a well-written proposal >> > outlining a simple solution with a great cost/benefit ratio. >> > I recommend we accept it. >> > >> > Cheers, >> > Sebastian >> > >> > Am Mo., 16. Juni 2025 um 09:17 Uhr schrieb Adam Gundry via >> > ghc-steering-committee > > >: >> > >> > Dear Committee, >> > >> > Teo Camarasu proposes to split out smaller, more coherent packages >> with >> > more stable interfaces from the template-haskell package: >> > >> > https://github.com/ghc-proposals/ghc-proposals/pull/696 >> > >> > >> https://github.com/TeofilC/ghc-proposals/blob/wip/th-lift-and-quasiquote/proposals/0000-splitting-out-stable-interfaces-from-th.rst >> < >> https://github.com/TeofilC/ghc-proposals/blob/wip/th-lift-and-quasiquote/proposals/0000-splitting-out-stable-interfaces-from-th.rst >> > >> > >> > I'd like to nominate Sebastian as the shepherd. >> > >> > Please guide us to a conclusion as outlined in >> > https://github.com/ghc-proposals/ghc-proposals#committee-process >> > >> > >> > Cheers, >> > >> > Adam >> > >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, https://www.well-typed.com/ >> >> Registered in England & Wales, OC335890 >> 27 Old Gloucester Street, London WC1N 3AX, England >> >> _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Jul 1 08:57:08 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 1 Jul 2025 17:57:08 +0900 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: I will not vote on this one because I don't feel that there's much value either way. I don't feel invested enough to juge of whether it's well designed or not, but *I don't want to block this initiative*. I did make a small comment in the proposal thread which hopefully will lead to simplification of the classification, though. On Mon, 23 Jun 2025 at 22:12, Malte Ott via ghc-steering-committee < ghc-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 > > > > > https://github.com/telser/ghc-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 > _______________________________________________ > 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 simon.peytonjones at gmail.com Wed Jul 2 14:59:13 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 2 Jul 2025 15:59:13 +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: 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 < ghc-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 > > > > > https://github.com/telser/ghc-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 > _______________________________________________ > 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: