- ghc-steering-committee

GHC steering committee status 2026-10-21
by Simon Marlow 21 Oct '26

21 Oct '26

Proposals currently in 'Waiting for shepherd recommendation' state: ---------------------------------------------------------------------- PR #767 (shepherd: Matthias) New constraint separator for Pattern Synonyms (under review) 0 days PR #770 (shepherd: Malte) NOCOVER expression pragma (under review) 0 days Proposals currently in 'Committee discussion' state: ---------------------------------------------------------------------- PR #738 (shepherd: Adam) Amend #669 to categorize more language extensions (under review) 77 days Created by https://github.com/simonmar/ghc-proposals-stats/

1 0

Assigning Shepherd: NOCOVER expression pragma - #770
by Simon Marlow 21 Oct '26

21 Oct '26

rafl <https://github.com/rafl> submitted proposal #770: NOCOVER expression pragma - #770 <https://github.com/ghc-proposals/ghc-proposals/pull/770> for the committee to review. I’d like to nominate *Malte Ott* as the shepherd. Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#9comm…> . If possible, please aim to make a recommendation by *4 November 2026*.

1 0

Assigning Shepherd: #767: New constraint separator for Pattern Synonyms
by Simon Marlow 21 Oct '26

21 Oct '26

VitWW submitted proposal #767: New constraint separator for Pattern Synonyms - #767 <https://github.com/ghc-proposals/ghc-proposals/pull/767> for the committee to review. I'd like to nominate *Matthías Páll Gissurarson* as the shepherd. Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#9comm…> . If possible, please aim to make a recommendation by *4 November 2026*. Cheers Simon

1 0

Unordered extra commas
by code＠jaro.addy.io 13 Oct '26

13 Oct '26

Dear fellow committee members, We have a proposal in the pipeline about allowing extra commas <https://github.com/ghc-proposals/ghc-proposals/pull/748> in sequences where the order does not matter. These extra commas (before the first item and/or after the last item) make code layout more consistent and reduce clutter in diffs. This is a limited version of an earlier proposal which did not make it because it sparked too much controversy. The current only allows redundant commas in uncontroversial places, which roughly lines up with the intuition that for all these places the order of the sequence items does not matter. Since there hasn't been much discussion lately on this proposal, I'm asking you to provide your opinion. There are two main points of discussion: 1. Does this proposal make the right selection of places where to allow extra commas? This proposal for example does not include commas in contexts ((...here...) => ...), or in lists. I personally think we should choose carefully to avoid the situation where we do want to allow extra commas in more places in the future, because we then either need a new extension or we need to change the meaning of this extension. 2. Which extra commas do we allow? The current proposal is to allow an extra comma at the start AND at the end of a sequence. I personally think we should be more conservative and only allow one OR the other (exclusively). Another alternative is to allow extra commas anywhere in the list, even multiple in a row. I'm looking forward to your opinions, Jaro

11 36

Assigning Shepherd: #738: Amend #669 to categorize more language extensions
by Simon Marlow 13 Oct '26

13 Oct '26

Trevis Elser submitted proposal #738: Amend #669 to categorize more language extensions <https://github.com/ghc-proposals/ghc-proposals/pull/738> for the committee to review. I'd like to nominate *Adam Gundry* as the shepherd. Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#9comm…> . If possible, please aim to make a recommendation by *7 August 2026*. Cheers Simon

5 8

#765: Pun warnings, recommendation: accept
by Jakob Brünker 03 Sep '26

03 Sep '26

Hi all, Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace: https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/… These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378) by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle). They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal. I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it. I recommend we accept. Please indicate whether you wish to accept this proposal. Jakob

8 14

Fw: Re: Please review #678: Amendment to ImportShadowing
by Erik de Castro Lopo 02 Sep '26

02 Sep '26

Hi all, I realize that this is the time of year when the northern hemisphere takes holidays, but this email may also just have been flagged as spam in Simon's email. Would appreciate it if anyone might be able to provied a clue here. Thanks, Erik Begin forwarded message: Date: Mon, 24 Aug 2026 19:22:47 +1000 From: Erik de Castro Lopo <erikd(a)mega-nerd.com> To: Simon Marlow <marlowsd(a)gmail.com> Subject: Re: [ghc-steering-committee] Please review #678: Amendment to ImportShadowing Hi Simon, I understand that you are currently secretary. Does the Google spreadsheet where the acceptances were recorded still exist? If so please provide me with a link. Thanks, Erik Erik de Castro Lopo wrote: > Hi all, > > With regards to this I have seen acceptance recommendations from > > Malte Ott, Jaro Reinders, Adam Gundry, Sebastian Graf, Matthías Páll > Gissurarson and myself. > > Hope I have not missed anyone. Anybody else like to accept? > > There used to be a Google spreadsheet where the acceptances were recorded. > Does that still exist? Is there a new way acceptances are recorded? > > Thanks, > Erik > > Erik de Castro Lopo via ghc-steering-committee wrote: > > > Hi all, > > > > In regards to the "Amend Import Shadowing proposal to match Haskell 2010 > > section 5.2.5" proposal: > > > > https://github.com/ghc-proposals/ghc-proposals/pull/678 > > > > This went back into review because there was still a lot of chatter on it. > > This chatter has completely died out after Simon PJ's input was incorporated. > > > > I have recommended that we accept this minor modification of this proposal. > > I would appreciate it if everyone else on the committee would vote. > > > > Thanks, > > Erik > > -- > > ---------------------------------------------------------------------- > > Erik de Castro Lopo > > http://www.mega-nerd.com/ > > _______________________________________________ > > ghc-steering-committee mailing list -- ghc-steering-committee(a)haskell.org > > To unsubscribe send an email to ghc-steering-committee-leave(a)haskell.org > > > > > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4 5

Please review #678: Amendment to ImportShadowing
by Erik de Castro Lopo 31 Aug '26

31 Aug '26

Hi all, In regards to the "Amend Import Shadowing proposal to match Haskell 2010 section 5.2.5" proposal: https://github.com/ghc-proposals/ghc-proposals/pull/678 This went back into review because there was still a lot of chatter on it. This chatter has completely died out after Simon PJ's input was incorporated. I have recommended that we accept this minor modification of this proposal. I would appreciate it if everyone else on the committee would vote. Thanks, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

8 10

GHC steering committee status 2026-08-04
by Simon Marlow 04 Aug '26

04 Aug '26

Proposals currently in 'Waiting for shepherd recommendation' state: ---------------------------------------------------------------------- PR #738 (shepherd: Adam) Amend #669 to categorize more language extensions (under review) 11 days Proposals currently in 'Committee discussion' state: ---------------------------------------------------------------------- PR #678 (shepherd: Erik) Amend Import Shadowing proposal to match Haskell 2010 section 5.2.5 (under review) 40 days PR #765 (shepherd: Jakob) Pun warnings 21 days PR #748 (shepherd: Jaro) Extra NonTuple Commas (under review) 11 days Created by https://github.com/simonmar/ghc-proposals-stats/ With a little manual editing to add the shepherds.

1 0

Re: #570: Native string interpolation syntax (round two)
by Sebastian Graf 03 Aug '26

03 Aug '26

Hi everyone, Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes. We are now 3 weeks into the review period. That means we have about *1 week left* to come to a conclusion. I would be interested in the opinions of - Simon M - Adam - Malte - Matthías - Jakob Thank you! Sebastian Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code(a)jaro.addy.io>: > I support the proposal. > > I think string interpolation is rarely the most principled solution any > problem, but it is very convenient and Brandon and all contributors have > put enough thought into making sure the proposed string interpolation has > few sharp edges. > > Cheers, > Jaro > > On 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337(a)gmail.com> wrote: > > Dear committee, > > In #570 <https://github.com/ghc-proposals/ghc-proposals/pull/570>, > Brandon Chinn proposes adding native string interpolation syntax to GHC, > along the lines of s"a ${x + 1} b", catching up with and even exceeding > similar features in popular programming languages. > > I think this is an important proposal and I recommend that we accept it. > > Since the previous submission, Brandon settled on a coherent and simple > interaction with -XOverloadedStrings. Although the proposed interpolation > API seems more ad-hoc than necessary, I did not find a way to simplify it > any further. > > Cheers, > Sebastian > > >

5 6