December 2024 - ghc-steering-committee

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

#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

Intended meaning of "Needs revision" label
by Jakob Brünker 07 Dec '24

07 Dec '24

Hi all, I've so far essentially been using the "Needs revision" label to indicate that the next concrete step has to be taken by the author, regardless of how big the changes I suggest are. After I did this yesterday, VitWW commented <https://github.com/ghc-proposals/ghc-proposals/pull/621#issuecomment-252329…>, essentially saying it's only intended for cases where major rewrites are required. >From what I can tell, in past proposals, if relatively minor changes came up during the shepherding phase, sometimes "Needs revision" was used, and sometimes not. Is there a guideline I should follow, or that you tend to follow here? Jakob

3 6

Please review #682: Explicit Level Imports
by Adam Gundry 02 Dec '24

02 Dec '24

Dear Committee, Matthew Pickering, Rodrigo Mesquita and I propose to introduce Explicit Level Imports as a mechanism for TH code to be more precise about its dependencies: https://github.com/ghc-proposals/ghc-proposals/pull/682 https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/pro… I'd like to nominate Arnaud Spiwack 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

1 0

Please review #621: Linear Constraints
by Adam Gundry 02 Dec '24

02 Dec '24

Dear Committee, Jack Hughes and Arnaud Spiwack propose to introduce Linear Constraints in order to reduce boilerplate when using linear types: https://github.com/ghc-proposals/ghc-proposals/pull/621 https://github.com/tweag/ghc-proposals/blob/linear-constraints/proposals/06… I'd like to nominate Jakob Brünker 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

1 0