- ghc-steering-committee

Fwd: [haskellfoundation/tech-proposals] GHC's base libraries: Combining stability with innovation (PR #51)
by Simon Peyton Jones 12 Jul '23

12 Jul '23

Dear GHC SC CLC approves! Simon ---------- Forwarded message --------- From: ˌbodʲɪˈɡrʲim <notifications(a)github.com> Date: Tue, 11 Jul 2023 at 22:45 Subject: Re: [haskellfoundation/tech-proposals] GHC's base libraries: Combining stability with innovation (PR #51) To: haskellfoundation/tech-proposals <tech-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simon.peytonjones(a)gmail.com>, Mention < mention(a)noreply.github.com> I'm happy to announce that the proposal <https://github.com/haskellfoundation/tech-proposals/pull/51/commits/c157f56…> has been approved unanimously <https://groups.google.com/g/haskell-core-libraries/c/10SyhA9Lm98/m/Zimb2ZZU…> by CLC. — Reply to this email directly, view it on GitHub <https://github.com/haskellfoundation/tech-proposals/pull/51#issuecomment-16…>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEOY62ZSZ6RZ4LTLPSKSOLXP…> . You are receiving this because you were mentioned.Message ID: <haskellfoundation%2Ftech-proposals%2Fpull%2F51%2Fc1631552317(a)github.com>

2 1

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

GHC Steering Committee Status
by Joachim Breitner 03 Jul '23

03 Jul '23

Dear Committee, besides long discussions understanding our relationship with the CLC, we even manged to process some proposals. So let’s see what happened since the last update (May 17): * Our intraction with the CLC is now documented at https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propo… * No news from Arnaud’s quest to understand the roles of Extensions. * we were asked to review these proposals: #194: Updated partial type signatures, Shepherd: Eric (resubmission) #581: Namespaces-specified Imports, Shepherd: Moritz #586: split -Wunused-imports, Shepherd: Chris #596: sized literals in Show, Shepherd: Joachim #434: Fine-grained unused warnings, Shepherd: Chris * we have a recommendation from the shepherd about: #581: Namespaces-specified Imports, rec: accept #586: split -Wunused-imports, rec: accept #575: deprecation pragmas on instances, rec: accept #596: sized literals in Show, rec: accept * we have sent the following proposals back to revision #532: Clean up and simplify the treatment of implicit binding #493: SPECIALISE with expressions, Shepherd: Adam * we decided about the following proposals #330: Decorate exceptions with backtrace information, accepted #579: Backward compat proposal section, accepted #586: split -Wunused-imports, accepted #575: deprecation pragmas on instances, accepted So we currently have to act on the following 8 proposals, down by one from 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? #579: sized literals in Show, Shepherd: Joachim 2023-06-29: Assigned to Joachim 2023-06-29: Joachim recommends acceptance two 👍, rather incontroversial. Will merge in a few days #581: Namespaces-specified Imports, Shepherd: Moritz 2023-06-28: Moritz suggests acceptance. Mostly positive feedback, can probably be merged in a week’s time ## 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 #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 Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #434: Fine-grained unused warnings, Shepherd: Chris
by Joachim Breitner 03 Jul '23

03 Jul '23

Dear Committee, Jakob Brünker proposes more fine-grained control over unused warnings: https://github.com/ghc-proposals/ghc-proposals/pull/434 https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/pro… I’d like to ask Chris 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

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

29 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 29 Jun '23

29 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 29 Jun '23

29 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 27 May '23

27 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