July 2023 - ghc-steering-committee

Please review #601: Extension lifecycle, Shepherd: Simon PJ
by Joachim Breitner 03 Sep '23

03 Sep '23

Dear Committee, David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so. https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycl… Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ. 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/

10 22

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

Language Extension Policy – Round 3
by Arnaud Spiwack 30 Aug '23

30 Aug '23

Dear all, For this round, I'd like to build on the results of last round [1]. One thing that strikes me in the results, bearing in mind that 6 out of 10 members answered the question directly, and that none of this is without dissent anyway, is that there seems to be a general feeling that extension should not stay forever. What I'm reading is that most respondents seem to believe that when an extension becomes part of GHC20xx, it should be removed (with a deprecation period, I'd imagine): if you want the feature, use GHC20xx. Now, before I explore this question further, I should acknowledge that this doesn't directly help answering the questions that I set to resolve when this all began. Namely, under what principles do we judge extensions (in particular whether a proposal should be one of several extensions). But I think it's likely to help. I'm starting with this conversation because it's relatively concrete, probably less controversial than other questions, and as such, I'm hoping that it'll help us discuss the more difficult questions with a little more understanding of what we collectively believe. Let's explore what it would mean for an extension to be removed. - The extension wouldn't appear in `$ ghc --show-options` (currently `$ ghc --show-options | grep '\-X'` has 268 lines, almost every extension accounts for 2 lines) - The programmer can't turn the extension on or off directly - The documentation, in the user manual, of the corresponding feature would be moved from the “Language extension” section to somewhere else (maybe a new section “Language features”? Not sure what is natural here) - Error messages about the feature not being activated would stop suggesting you use the extension, but instead that you use one of the appropriate GHC20xx. - For some extension, we could provide a warning (off by default) to allow those who want to avoid the corresponding to disallow it in their codebase. But certainly not all extensions would be turned into warnings: I don't anticipate anybody will want to specifically avoid -XBinaryLiteral for instance. - Am I forgetting something? It doesn't mean that the extension must disappear in the implementation of GHC: this is an implementation detail (maybe it'll be beneficial for some extensions to be removed and other not, I don't feel capable of anticipating this). But the extension would not be visible or accessible to the user. Now the question is: ignoring the question of whether we have time to retroactively do this, does this look like this would be part of your ideal vision for GHC. If not, please argue. [1] https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmec… -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

8 12

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

02 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 11 Jul '23

11 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