- ghc-steering-committee

Please mention both PR number and title in the email subject
by Joachim Breitner 28 Jun '23

28 Jun '23

Dear Shepherds, you’ll make my live easier if the email thread you start has both the PR number and the title in the subject line. A good example is #330: Decorate exceptions with backtrace information, rec: accept (but any subject line is better than no email, so thanks for your service in either case!) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please consider GHC Proposal #575 for acceptance.
by Moritz Angermann 28 Jun '23

28 Jun '23

Dear Steering Committee, I strongly endorse GHC Proposal #575 <https://github.com/ghc-proposals/ghc-proposals/pull/575>, which suggests the introduction of deprecation pragmas on instances. The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities. The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience. In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration. Best Regards, Moritz

7 9

Split -Wunused-imports (recommend accept)
by Chris Dornan 28 Jun '23

28 Jun '23

Dear Committee, Georgi Lyubenov has a simple proposal to improve the quality of life for many package maintainers that I recommend that we accept. ## Split -Wunused-imports Rendered proposal: <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/prop…> Discussion of proposal: <https://github.com/ghc-proposals/ghc-proposals/pull/586> ### Summary (Straight from the proposal.) We propose to split the -Wunused-imports warning into two parts: - warn on actual unused imports - warn on duplicate imports while also not including the second in -Wall. This will greatly reduce "churn" for library authors. ## In more Detail As we know, many Haskell developers, including significant commercial projects, incorporate -Wall -Werror into their workflow at some stage. To this end it is important that we minimise 'false negatives', whereby the compiler emits 'frivolous' warnings. This proposal identifies an important class of -Wall warnings that many package maintainers appear to regard quite bothersome, namely when the compiler warns that import statement is superflous even when it is importing an entity that is being used by the module. The issue is the way `-Wunused-imports` works, which will issue a warning for the following program. ```haskell import X -- exports some function @f@ import y -- exports the same function @f@ g = f ``` The compiler will warn that the second Y import is redundant. Many developers do not want to be warned about this. As far as they are concerned each import is yielding enties that are in use and the fact that one of them can be removed is just not interesting. In contrast, developers that use -Wall do want to be warned about the following. ```haskell import X -- exports some function @f@ import Z -- does not export f g = f ``` Here our module has a completely false dependency on Z which should be cleaned up at the point that warnings are cleaned up. This proposal proposes modifying -Wunused-imports so that it will warn about the second example but stay silent for the first, and adds a -Wduplicate-imports that will issue a warning for the the first example. In effect the enabling of both warnings in the new proposal will restore the current -Wunused-imports behaviour. -Wall should *not* enable -Wduplicate-imports but is avilable to those developers that rely on the current behaviour of -Wunused-imports (which some clearly do). ## Recommendation I recommend that we accept this proposal.

5 7

Please review #579: Backward compat proposal section, Shepherd: Simon PJ
by Joachim Breitner 06 Jun '23

06 Jun '23

Dear Committee, Adam proposes adding a section on backward compatibility to the proposal template: https://github.com/ghc-proposals/ghc-proposals/pull/579 Richard said that this, even although likely uncontroverisal, should have broad committee visibility, so I’m assigning this to Simon PJ (as the chair) to shepherd this. 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/

3 7

Advice for MRs about ImplicitForAll/ImplicitBinds
by Torsten Schmits 26 May '23

26 May '23

Dear members of the committee, I'm struggling to make a decision about whether to merge a proposal implementation that could wait for an amendment. Please have a look at my post on Gitlab for an explanation: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8629#note_500738 Thanks for your time, Torsten

2 1

Please review#586: split -Wunused-imports, Shepherd: Chris
by Joachim Breitner 25 May '23

25 May '23

Dear Committee, Georgi Lyubenov and Torsten Schmits propose to split -Wunused-imports. https://github.com/ghc-proposals/ghc-proposals/pull/586 https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/prop… I’d like to ask Chris to shepherd this proposal. Note that the authors became luke warm about the “meta warning” part of the proposal, and thus asks us (and hence foremost Chris) to cast a judgement call on it. 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

#330: Decorate exceptions with backtrace information, rec: accept
by Vladislav Zavialov 25 May '23

25 May '23

Dear Committee, Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here: https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-ex… The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively. This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care. I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this. Please take a look at the proposal text and share your thoughts either here or directly on GitHub. - Vlad

5 9

Please review #581: Namespaces-specified Imports, Shepherd: Moritz
by Joachim Breitner 25 May '23

25 May '23

Dear Committee, Adam Gundry, Artyom Kuznetsov and Chris Dornan propose Namespace-specified imports: https://github.com/ghc-proposals/ghc-proposals/pull/581 https://github.com/adamgundry/ghc-proposals/blob/namespace-specified-import… I’d like to ask Moritz to shepherd this proposal. 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

GHC Steering Committee Status
by Joachim Breitner 24 May '23

24 May '23

Dear Committee, we had some relatively quiet two weeks on this mailing list, but that quiet doesn’t really fit to the relatively long backlog. Let’s clear it out a bit, if we can! What has happened since the last one update (March 16)? * Arnaud continues the quest to understand the roles of Extensions. * we were asked to review these proposals: #579: Backward compat proposal section, Shepherd: Simon PJ #575: Deprecated instances, Shepherd: Moritz #585: Amend Or Patterns, Shepherd: Richard #493: SPECIALISE with expressions, Shepherd: Adam * we have a recommendation from the shepherd about: #536: Type-level literals as a separate language extension, rec: accept #579: Backward compat proposal section, rec: accept * we have sent the following proposals back to revision #330: Decorate exceptions with backtrace information, Shepherd: Vlad * we decided about the following proposals #540: parallelism semaphores, rec: accept So we currently have to act on the following 8 proposals, up again by 2: ## Waiting for committee decision #532: Clean up implicit binding, Shepherd: Arnaud 2022-08-23: Assigned to Arnaud Sent back for revision 2022-11-27: Resubmitted 2022-12-14: Arnaud recommends acceptance 2023-01-17: Arnaud picks up the conversation again. Silence since. #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 Turned into a discussion of Modifiers, and then into silence. Where are we on this one? #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? #579: Backward compat proposal section, Shepherd: Simon PJ 2023-03-30: Assigned to Simon 2023-03-30: Simon recommends acceptance Adam had a question that went unanswerd. Can we resolve this? ## Waiting for shepherd recommendation #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M Simon, can you cast your recommendation? #585: Amend Or Patterns, Shepherd: Richard 2023-04-11: Assigned to Richard #575: Deprecated instances, Shepherd: Moritz 2023-04-06: Assigned to Moritz #493: SPECIALISE with expressions, Shepherd: Adam 2023-05-17: Assigned to Adam Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #493: SPECIALISE with expressions, Shepherd: Adam
by Joachim Breitner 17 May '23

17 May '23

Dear Committee, Richard proposes that the SPECIALIZE pragma should understand expressions, not just types: https://github.com/ghc-proposals/ghc-proposals/pull/493 https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-… I’d like to ask Adam to shepherd this proposal. 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