May 2025 - ghc-steering-committee

Please review #678: Amendment to ImportShadowing
by Adam Gundry 15 Jun '26

15 Jun '26

Dear Committee, Gergő Érdi proposes to amend his import shadowing proposal #652 to clarify the behaviour of module re-exports: https://github.com/ghc-proposals/ghc-proposals/pull/678 I'd like to nominate Erik de Castro Lopo as the shepherd, as he shepherded the original proposal. 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

10 16

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

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