- ghc-steering-committee

Re: [ghc-steering-committee] #686: Amendment to MultilineStrings, recommendation: accept
by Sebastian Graf 11 Mar '25

11 Mar '25

I vote accept.

1 0

Re: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Malte Ott 11 Mar '25

11 Mar '25

> Please reply with your preference order amongst these options. My vote > is B > A > C > D. > > Thanks, > > Adam I have the same preference. When we allow foo."bar baz" The next question is if we want to go crazy the nix way with foo.${bar}" which is the same as getField @bar foo (instead of getField @"bar" foo). Might become interesting with dependent types.^^ This E-Mail isn’t technically a reply, because I haven’t received anything from the mailinglist since your note about the delivery issues. Best, Malte

1 0

#682: Explicit Level Imports, recommendation: accept
by Arnaud Spiwack 07 Mar '25

07 Mar '25

Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better. But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay? Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only. They introduce a new extension-XNoImplicitStagePersistence which disables that, and a little bit of syntax to specify the stage of imports. That's it. But it comes with severe limitations, most importantly: you can't ever use a symbol defined in the current module in a quote or splice of this current module, typed template Haskell is turned off. For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward. The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

9 38

Please review #686: Fix spec for string gaps in multiline strings
by Adam Gundry 04 Mar '25

04 Mar '25

Dear Committee, Brandon Chinn proposes to amend proposal #569, which introduced MultilineStrings, to correct its interaction with string gaps: https://github.com/ghc-proposals/ghc-proposals/pull/686 I'd like to nominate Malte as the shepherd, since he already engaged on the proposal thread. 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

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

Please review #680: Clarify CRLF behavior in multiline strings (amendment to #569)
by Adam Gundry 21 Nov '24

21 Nov '24

Dear Committee, Brandon Chinn proposes to amend proposal #569, which introduced MultilineStrings, to clarify its treatment of \r\n vs \n: https://github.com/ghc-proposals/ghc-proposals/pull/680 Sebastian has volunteered to act as 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 13

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