- ghc-steering-committee

#604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec: accept
by Joachim Breitner 03 Aug '23

03 Aug '23

Dear committee, John Ericsson in https://github.com/ghc-proposals/ghc-proposals/pull/604 proposes an amendment to #448. I’ll shepherd this myself. Status Quo: ScopedTypeVariables implies TypeAbstractions. New behavior: TypeAbstractions needs to be enabled explicitly. (Plus, as a compat feature, ScopedTypeVariables&TypeApplications enable TypeAbstractions, with a deprecation warning upon use.) John makes a good argument that it’s odd to expand the meaning of an existing extension like ScopedTypeVariables without need, and the proposed way sounds good to me, so I recommend to accept this. This is a minor change and would be good to have clarity soon. If no discussion happens, I’ll merge in a week. I am particularly keen on feedback from Richard (original author) and Arnaud (original shepherd), of course. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 5

Feedback on GHC2021 on Discourse
by Joachim Breitner 31 Jul '23

31 Jul '23

Hi, for those who are not following discourse, someone kicked up a thread asking for opinions on GHC2021: https://discourse.haskell.org/t/anybody-using-ghc2021/7095?u=nomeata It’s mostly very positive and encouraging (and I hope helps us overcome the anxiety about this and define an even better GHC2024). Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #597: Constraints synonyms in deriving heads, Shepherd: Moritz
by Joachim Breitner 25 Jul '23

25 Jul '23

Dear Committee, Grigorii Gerasev suggests to allow constraints type synonyms in deriving heads again. https://github.com/ghc-proposals/ghc-proposals/pull/597 https://github.com/uhbif19/ghc-proposals/blob/uhbif19/allow-constraint-type… I’d like to assign this to Moritz (mostly because most of the committee already sits on a proposal… gentle nudge). 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

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

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/tech-proposals/pull/51/c1631552317(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