- ghc-steering-committee

Please review #571: -Wsevere, Shepherd: Adam
by Joachim Breitner 12 Oct '23

12 Oct '23

Dear Committee, based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a warning group -Wsevere for on-by-defaults, error-by-default warnings, and initially fill it with missing-methods and missing-fields. https://github.com/ghc-proposals/ghc-proposals/pull/571 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-… I’d like to nominate Adam as the shepherd, who already reviewed it a bit on Github. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

9 51

GHC2024 timeline
by Joachim Breitner 11 Oct '23

11 Oct '23

Dear Committee, like every year so far, I will make a push to define a new GHC20xx. Maybe this year it will happen… TL;DR: If you want GHC2024, head to https://github.com/ghc-proposals/ghc-proposals/pull/613 and tell us what it should look like. I am proposing the following procedure and timeline: Phase 1 (now): Nominations and discussion The community (including us) nominates extensions for inclusion (or removal) for GHC2024, relative to GHC2021, at https://github.com/ghc-proposals/ghc-proposals/pull/613 together, and everyone can help refining the rationales/pros/cons. I have taken the list from last year to seed this document I propose to conclude this by end of October. Phase 2 (November): Committee deliberation Based on that list, we do what we do best: discuss. Until end of November Phase 3 (early Decemb): Voting Finally, we vote. Last year, we first had a “should do we GHC20xx” vote, which (had it not been rejected) would be followed by a vote where each nominated extension can be yay’ed/nay’ed individually. I guess we can do the same this year. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Amend or patterns (#522) to use p1 ; p2 (#609)
by Chris Dornan 08 Oct '23

08 Oct '23

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a4… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance ## Summary This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns. The syntax of the old proposal, ```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ``` is replaced with ```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ``` or indeed ```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ``` (Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.) The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production. ## Recommendation The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

10 22

#526: Applicative Comprehensions (rec: accept)
by Simon Marlow 03 Oct '23

03 Oct '23

Dear committee, #526 proposes a new extension ApplicativeComprehensions (implying MonadComprehensions). It would provide the equivalent of the current ApplicativeDo desugaring for do-expressions to list comprehensions. - Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/526> - Rendered <https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicati…> The extension itself is relatively uncontroversial, but there are some unresolved quirks in the original ApplicativeDo extension which made us uneasy about extending it. However, after various discussions I'm going to propose accepting this proposal in its current state. Rationale: - It doesn't make things worse, and the implementation isn't likely to add significant complexity. - It retains consistency between ApplicativeDo and ApplicativeComprehensions (in contrast to the idea of making ApplicativeComprehensions perform a simpler desugaring, which came up during the discussion) - A future proposal can add a simpler version of the desugaring for both extensions later. Cheers Simon

8 9

Please review #612: -fhpc tix file changes, Shepherd: Moritz
by Joachim Breitner 27 Sep '23

27 Sep '23

Dear Committee, David Binder suggests to change how -fhpc handles existing tix files by default: https://github.com/ghc-proposals/ghc-proposals/pull/612 https://github.com/BinderDavid/ghc-proposals/blob/change-fhpc-semantics/pro… I’d like to nominate Moritz as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Warnings
by Simon Peyton Jones 26 Sep '23

26 Sep '23

Dear GHC SC You may or may not have been following GHC ticket #22141 <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge request !11314 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>. The story is this: - There is a bug in GHC that allows programs to use DataKinds without the -XDataKinds extension. - The MR fixes the bug. - But of course that will mean that some programs that previously compiled (exploiting the bug) will now fail to compile (correctly). It seems like an example of our (GR2) discussion, but with a very different flavour than the (3+4=8) example. Personally I think we should do it -- with a deprecation cycle saying "You need DataKinds for this program, and you don't have it on, but you will need it in the next release". I don't want us to grandfather bugs into GHC indefinitely -- although you could argue that the status quo does little harm, I suppose. Any views? We will have some idea of the impact on head.hackage shortly. *And specifically: do you want a GHC proposal for this change?* Simon

6 6

Template too large, removed direct link
by Joachim Breitner 18 Sep '23

18 Sep '23

Hi, we used to have a direct link in our README to start a new template pre-filled with the template, but that only worked as long as our template text was short enough to fit into an URL, and would just give an error message now. I have removed that from the README for now. It requires proposal authors to understand enough git to know how to create a new file and copy some other file into it. Maybe not too high a hurdle. We can add the link back if we have shrunk our template to a sensible size again… these things grow like nothing else, besides maybe bureaucracy. If someone makes a heroic effort to make the template more concise without losing anything important (I think the endorsement section can go as it is unused, but that alone is not enough), that would be great! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

GHC steering committee status
by Simon Peyton Jones 13 Sep '23

13 Sep '23

Dear GHC steering committee Re GHC proposals I was talking to Simon M about - Making the shepherd's job easier and quicker - Providing a way for members of the committee to say (explicitly) "I don't have an opinion about this proposal" and thus recuse themselves. Explicit recusal is better than "silence means assent" because silence can, and often does, mean "I'm under water and not listening". With that in mind, I want to revive my suggestion of running an online spreadsheet <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu…>to describe the state of proposals that are in our active purview. That is, I'm not proposing to show proposals that are under discussion by the community, or accepted etc -- just the ones that are in our inbox, *where the next action is ours.* That makes it much easier to see our current inbox, without looking back for Jocahim's last email and then adding deltas for all the emails since -- which I cannot do in my head. Specifically, I have *a column for each committee member's vote. * That should make it easy for the shepherd to see who is yet to express an opinion, which I always find difficult. As I say above, I am very uncomfortable with "silence means assent" for any but the smallest proposals. *I suggest instead that if there is a proposal where you feel unable to offer an opinion, due to lack of expertise, or lack of time, you can say "recuse" meaning that you explicitly want to stand down from this particular proposal.* (Somehow "abstain" carries a connotation of conflict of interest or something, but it amounts to the same thing.) If you are too under water to even recuse yourself, maybe it's time to step down. So in columns F to O we should see explicit responses from every committee member, in a timely way. Joachim doesn't like spreadsheets like this because they can easily get out of date. But it must be better than manually trawling email. *And it is up to each of us (not Joachim) to fill in our own column for proposals in our inbox.* If we don't like it, we can change it. You all have edit rights. I have populated it with data from Joachim's message of 2 Sept, but there has been some action since then, so shepherds please update it. This is not Joachim's task! Thanks Simon

5 7

Fine-Grained Unused Warnings (#42)
by Chris Dornan 09 Sep '23

09 Sep '23

Proposal: Fine-Grained Unused Warnings (#42) Author: Jakob Brünker Rendered proposal: https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/pro… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434 Recommendation: Acceptance ## Summary GHC currently warns equally about any superfluous binding that it discovers, regardless of whether the definition is unreferenced anywhere itself, or is merely mentioned by other definitions that are similarly superfluous. The proposal proposes to replace these warnings with just the warnings about definitions that are not referenced anywhere, but list within those warnings the entities it references that would otherwise not be required. The same information is being conveyed under this proposal as previously, but in a more structured manner. The proposal is careful to ensure the -Wunused-* controls (-Wunused-top-binds, etc.) are respected, so the subwarnings of transitively unused entities are only listed if their corresponding -Wunused-* control is active. As Jakob points out in the proposal, getting these warnings into some structure is partly motivated by IDE usage where the 'additional [transitive] warnings take up a lot of valuable screen real estate'. ## Example [From the proposal] In the following code, module Foo () import Data.List as L foo = L.intercalate `intercalate` is transitively unused, since it is only used by `foo`, which is unused. The warning that's produced will be Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: ‘foo’ as a consequence the following imports are transitively unused [-Wunused-imports]: Data.List imported at foo.hs:3:1: The warning about transitively unused bindings only appears if both the warning flag for the unused binding (in this case -Wunused-top-binds) and the the one for the transitively unused binding itself (in this case -Wunused-imports) are enabled. ## Recommendation This proposal is not at all disruptive (arguably to the extent of not requiring a GHC proposal review), is well thought out, and can improve the GHC/IDE UI so I recommend that we accept it.

4 4

GHC Steering Committee Status
by Joachim Breitner 04 Sep '23

04 Sep '23

Dear Committee, time for another status email, in particular because I need an up-to-date update to get stats for Simon’s famous report at HIW on Monday. Hope to see some of you there! Let’s see what has happened since July 3 * Arnaud did round 3 of his language extension policy investigation. * we were asked to review these proposals: #597: Constraints synonyms in deriving heads, Shepherd: Moritz #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, Sepherd: Joachim #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard #583: HasField redesign, Shepherd: Arnaud #609: (p1; p2) for or-patterns, Shepherd: Chris #607: Amendments clarify treatment of term variables in types, Shepherd: Vlad #605: visible forall to work without ScopedTypeVariables, Shepherd: Joachim #601: Extension lifecycle, Shepherd: Simon PJ * we have a recommendation from the shepherd about: #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec: accept #605: visible forall to work without ScopedTypeVariables, rec: accept #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept) #583: HasField redesign, rec: accept #601: Extension lifecycle, rec: accept * we have sent the following proposals back to revision #601: Extension lifecycle * we decided about the following proposals #596: sized literals in Show, accept #581: Namespaces-specified Imports, accept #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, accept #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept) #605: visible forall to work without ScopedTypeVariables, accept So we currently have to act on the following 9 proposals, up one since last time: ## Waiting for committee decision #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad 2022-09-03: Assigned to Baldur 2022-10-02: Reassignd to Vlad 2022-11-30: Vlad recommends rejection This needs to be picked up again, it has been lingering too long! #536: Type-level literals as a sep language extension, Shepherd: Vlad 2023-02-16 Assigned to Vlad 2023-03-06 Vlad recommends acceptance Some hesitancy in the committee to introduce this extension, the ongoing policy clarification process might guide us, but maybe we can resolve this earlier? #583: HasField redesign, rec: accept 2023-08-30 Arnaud recommends acceptance ## Waiting for shepherd recommendation #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M Simon, please cast your recommendation! #585: Amend Or Patterns, Shepherd: Richard 2023-04-11: Assigned to Richard There are votes on syntax going on, ran by Sebastian Graf. Maybe this should be in “needs revision” until they are through. Richard, I’ll leave this to you #609 seems to be related, not sure if we need both. #194: Updated partial type signatures, Shepherd: Eric 2023-05-25: Came back from needs revision #434: Fine-grained unused warnings, Shepherd: Chris 2023-07-02: Assigned to Chris #597: Constraints synonyms in deriving heads, Shepherd: Moritz 2023-07-25: Assigned to Moritz #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard 2023-08-17: Assigned to Richard Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 3