October 2024 - ghc-steering-committee

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

11 Apr '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 17

Please review #673: Amendment to -jsem proposal #540
by Adam Gundry 10 Nov '24

10 Nov '24

Dear Committee, Zubin Duggal proposes to amend proposal #540, which introduced the -jsem parallelism control mechanism, so that it can avoid incompatibilities arising from different system C library implementations: https://github.com/ghc-proposals/ghc-proposals/pull/673 https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.r… I'd like to nominate Eric Seidel as the shepherd, since he was the shepherd of 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

8 13

Re: [ghc-steering-committee] Statistical analysis of GHC proposals
by Simon Peyton Jones 30 Oct '24

30 Oct '24

Dear Andrew Thank you -- that's very interesting. GHC SC: do look below! I'm not quite sure what, if anything, we should do in the light of this information. Simon On Sun, 27 Oct 2024 at 23:06, Andrew Lelechenko <andrew.lelechenko(a)gmail.com> wrote: > Hi Simon, > > I’ve been exploring GitHub API capabilities by gathering data on GHC > proposals. I wonder if any of the numbers below might be interesting to > reflect on for GHC SC. > > Total number of GHC proposals: 441 > Rate of proposals: 5 per month > Approved proposals: 149 > Need revision: 30 > Declined proposals: 16 > > Median time from creation to decision: 101 days > Average time from creation to decision: 181 days > Median time from creation to approval: 100 days > Average time from creation to approval: 165 days > Fastest approval: > 8 days for "Adjust warning category syntax" > 2nd fastest approval: > 11 days for "Remove dot from characters allowed in overloaded > labels" > 2nd slowest approval: > 980 days for "Fine-grained unused warnings" > Slowest approval: > 1112 days for "Decorate exceptions with backtrace information" > > Total activity: 15999 comments > Median activity per proposal: 23 comments > Average activity per proposal: 36 comments > Median activity per approved proposal: 31 comments > Average activity per approved proposal: 51 comments > Least active approved proposal: > 1 comment for "Amend the Higher Order Patterns proposal" > 2nd least active approved proposal: > 2 comments for "Amend 281 visible forall to work without > ScopedTypeVariables" > 2nd most active: > 313 comments for "Lambda expressions with guards and multiple > clauses (was: `\\ of`, -XMultiWayLambda)" > Most active: > 519 comments for "RecordDotSyntax language extension proposal" > > Open proposals: 117 > Median age for open proposals: 1105 days > Average age for open proposals: 1215 days > Newest open proposal: > 12 days for "Clarify CRLF behavior in multiline strings" > Oldest open proposal: > 2960 days for "Mutable constructor fields" > > Best regards, > Andrew

3 3

Please review #669: Initial categorization of language extensions
by Adam Gundry 29 Oct '24

29 Oct '24

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

1 0

Please review #678: Amendment to ImportShadowing
by Adam Gundry 21 Oct '24

21 Oct '24

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

9 12