- ghc-steering-committee

Please review #681: Updates to modifiers proposal
by Adam Gundry 09 Sep '25

09 Sep '25

Dear Committee, Phil Hazelden proposes to amend the Modifiers proposal based on experience with the implementation: https://github.com/ghc-proposals/ghc-proposals/pull/681 I'd like to nominate Matthías as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commi…. If possible, please aim to make a recommendation by 23rd September 2025. 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

1 0

Please review #698: Qualified Literals
by Adam Gundry 08 Sep '25

08 Sep '25

Dear Committee, Brandon Chinn proposes to introduce new extensions for qualified number, string and list literals: https://github.com/ghc-proposals/ghc-proposals/pull/698 https://github.com/brandonchinn178/ghc-proposals/blob/qualified-literals/pr… I'd like to nominate Erik as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commi… (thanks Sebastian for pointing out the previously broken link) 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

6 12

Proposal process refinements, removal of Markdown option
by Adam Gundry 15 Aug '25

15 Aug '25

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

1 0

#705: Explicit Level Imports: refine specification for exports, recommendation: accept
by Arnaud Spiwack 13 Aug '25

13 Aug '25

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.

3 3

Please review #669: Initial categorization of language extensions
by Adam Gundry 07 Aug '25

07 Aug '25

Dear Committee, 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-categorizati… I'd like to nominate Malte Ott 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

7 8

Please review #705: Refine Explicit Level Imports specification for exports
by Adam Gundry 24 Jul '25

24 Jul '25

Dear Committee, Matthew Pickering proposes to refine the specification for Explicit Level Imports (#682) to clarify the behaviour of module exports: https://github.com/ghc-proposals/ghc-proposals/pull/705 I'd like to nominate Arnaud as the shepherd, since he shepherded the original proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commi… If possible it would be good to get a quick decision on this so the implementation can be sorted for 9.14. 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

1 0

Please review #696: Splitting out stable interfaces from template-haskell
by Adam Gundry 14 Jul '25

14 Jul '25

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/pr… 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

9 11

Stepping down from the Steering Committee
by Eric Seidel 19 May '25

19 May '25

Hi folks, I have not had time to participate in Committee activities for a few months now. And upon reflection, I don't think that will change in the near future. So I think it's time for me to step down from the Committee and make room for someone else with more capacity to devote to improving Haskell. It makes me sad because I still care deeply about Haskell and its community. But I think it's the right decision for me and for the community. Thank you all, it's been an honor to serve. Eric

3 2

Please review #632: introduction of new language editions (inc. GHC2024)
by Adam Gundry 06 May '25

06 May '25

Dear Committee, I propose to amend the process for introducing new language editions, such that GHC always uses the latest language edition by default. In particular this would change the default language edition to GHC2024 (it currently remains GHC2021): https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposal… https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposal… I'd like to invite Simon Marlow to be the shepherd. (Originally I was shepherding this amendment myself, in the hope that it would be a quick amendment in time for GHC 9.10, but that was clearly a forlorn hope!) 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

9 10

#668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Adam Gundry 06 May '25

06 May '25

Dear Committee, In the interests of getting things moving on proposal #668 from Matt Parsons, I'll shepherd it myself, and recommend we accept it. https://github.com/ghc-proposals/ghc-proposals/pull/668 This is a small amendment to the OverloadedRecordDot extension to allow reserved identifiers as field names. For example, this program is currently rejected with a parse error, but would be accepted: import GHC.Records x = foo.type -- parse error, "type" is a reserved identifier data T = MkT Int foo = MkT 42 instance HasField "type" T Int where getField (MkT x) = x While "type" is not a valid field name in a traditional Haskell record data type, there is nothing stopping a user defining their own instance for `HasField "type" r a`, and some users would like to do so (e.g. when using HasField to interface with a database). Attempting to use such an instance with OverloadedRecordDot runs into this parse error. However the presence of the dot syntax means there is no ambiguity in what the user means. Even if a user wrote `x.type` by accident, they are likely to get better diagnostic information if the parser accepts the program. The only issue I see is that some syntax highlighters unaware of this change may incorrectly highlight such record projections as keywords. Please indicate whether you are happy to accept this proposal. 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

10 18