June 2023 - ghc-steering-committee

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

02 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

Base library organisation
by Simon Peyton Jones 17 Jul '23

17 Jul '23

Dear GHC Steering Committee Over the last few weeks, Ben Gamari and I have been discussing with Andrew and Julian from the Core Libraries Committee how to make the Core Libraries Committee and the GHC developers work together more fluidly; and that includes the GHC Steering Committee. We now have a fairly well fleshed out proposal here. <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propo…> I hope you like it. As far as this committee is concerned there are two particular points of note 1. We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees. 2. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve *changing *existing types and functions. It is clearly unproductive for us to debate such things at length, and only *then *to land it on the CLC. Section 5.1 also suggests that proposals should explicitly (in a separate section) call out - What new types and functions it defines - What existing types and functions are changed. We should add that to our template. At the moment we are just sharing the proposal with relevant stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any rough edges before making it public. So, any views? Personally I think this is a Big Step Forward. Simon

8 20

Please consider GHC Proposal #581 for acceptance.
by Moritz Angermann 15 Jul '23

15 Jul '23

Dear Steering Committee, Adam, Artyom and Chris wrote the Namespace-specified imports proposal <https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks to make importing more impressive, allowing import statements to choose from the type and data namespaces explicitly. I believe this proposal adds value in expressiveness to import statements. After the last syntax refinement comes naturally to the language. I recommend acceptance of this proposal. Best regards, Moritz

7 7

#596: sized literals in Show, rec: accept
by Joachim Breitner 15 Jul '23

15 Jul '23

Dear committee, Krzysztof Gogolewski in https://github.com/ghc-proposals/ghc-proposals/pull/596 amends the sized literals proposal so that GHC uses the syntax 42#Int8 instead of (intToInt8# 42#) in the stock derived Show instances for data types with sized unboxed numbers. Implementation is also ready. Now that we have a syntax for these literals it’s clear that we want to use them in the show instances. There is no risk of breaking Show-Read-roundtripping, as Read instances cannot be derived (at the moment). This is a change in behavior of Show, so we should think for a moment how this affects stability. But none of the libraries in libraries/, in particularly not base, are affected by this change, according to Krzysztof. So I recommend to accept this. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 6

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 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