May 2023 - ghc-steering-committee

Please review #194: Updated partial type signatures, Shepherd: Eric
by Joachim Breitner 03 Sep '23

03 Sep '23

Dear Committee, Richard resubmits updated partial type signatures: https://github.com/ghc-proposals/ghc-proposals/pull/194 https://github.com/goldfirere/ghc-proposals/blob/updated-partial-type-sigs/… I’d like to ask Eric 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/

2 4

Language Extension Policy – Round 2
by Arnaud Spiwack 06 Jul '23

06 Jul '23

Dear all, In Round 1', we have gathered no less than 13 use-cases (see below) found in the community for Haskellers to motivate the need for extensions. Some of these use-cases are specific to a pretty definite list of extensions, some are not. Some extensions fall squarely in one use-case, some don't. Use-cases are not a classification of extensions, they're a classification of justifications for extensions to exist. Surely we've missed some, but it's alright to not be fully exhaustive. In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail. In this round, I'm asking you, for each X∈{1,…,13}, to answer the following questions: X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form) I'll be on holiday next week, and will tally the results on the first week on May. The 13 use-cases are 1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability) 2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language) 3. Restrict the use of novel features since the last established standard/report. 4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters) 5. Name/refer to a particular feature when talking/writing/searching about it. 6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax) 7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with. 8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely. 10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 13. CPP (this one is very unique isn't it?)

8 19

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

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