- ghc-steering-committee

Re: [ghc-steering-committee] Proposal #569: multiline string literals; Rec: accept
by Richard Eisenberg 28 Jan '24

28 Jan '24

After some conversation on the ticket, I'd like to vote for acceptance here. Richard > On Jan 1, 2024, at 9:46 AM, Richard Eisenberg <rae(a)richarde.dev> wrote: > > Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler. > > I think wisdom from other languages would be helpful here. I will post on the ticket. > > Richard > >> On Dec 31, 2023, at 12:04 PM, Eric Seidel <eric(a)seidel.io> wrote: >> >> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae(a)richarde.dev> wrote: >>> >>> On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes. >> >> I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps. >

5 12

Secretary of the GHC Steering Committee
by Simon Peyton Jones 26 Jan '24

26 Jan '24

Dear GHC Steering Committee Joachim's term of membership in the GHC SC comes to an end in March, and he wants to stand down as our Secretary. Joachim, you have done a fantastic job as our secretary, nudging us with regular status updates, making sure we hold membership nomination processes, and much more besides. You have made sure that we function well as a committee, and I for one have leaned heavily on your support. Thank you so much. Would anyone else like to be Secretary? I am delighted to say that Adam is willing to serve, but if anyone else would like to join in or share the role, that would be great too. Thank you Adam! RSVP! Thanks again Joachim. Simon

6 8

GHC Steering Committee Status
by Joachim Breitner 23 Jan '24

23 Jan '24

Dear Committee, I guess it’s time for a final status summary for me, to leave this place in good order for Adam to take over. Indeed, it is long due, the last one was on Sept 9. What happened since then? * Our chairs, the Simons, will serve another term. * GHC2024 proposed, discussed, voted upon and accepted. Although now there is pushback against making it the out-of-the-box experience, which is stalling the MR. If someone feels strongly, they should probably make a proposal. * Simon introduced a spreadsheet to keep better track of ongoing proposals: https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu… * We had various discussions around stability in various venues, eventually converging in a document at https://docs.google.com/document/d/1sX_rXHx8Mj3Kae9GalR2BwZ5-xzl7UpnpMBwl4d… and the proposal at https://github.com/ghc-proposals/ghc-proposals/pull/625 * we were asked to review these proposals: #571: -Wsevere, Shepherd: Adam #569: multiline string literals, Shepherd: Eric #612: -fhpc tix file changes, Shepherd: Moritz #606: 281 to use atype instead of ktype, Shepherd: Richard #624: Linear lets, Shepherd: Richard #626: Visible Forall in Types, Shepherd: Arnaud #625: Stability Goals, Shepherd: Moritz * we have a recommendation from the shepherd about: #434: Fine-grained unused warnings, rec: accept #609: Amend or-patterns to use ;, rec: accept #571: -Wsevere, rec: accept #526: Applicative Comprehensions, rec: accept #493: SPECIALISE with expressions, rec: accept #626: Amendment of Visible Forall in Types, recommendation: Accept #569: multiline string literals; Rec: accept #624: linear let-bindings; recommendation: accept * we have sent the following proposals back to revision #193: Updated partial type signatures #526: Applicative Comprehensions (dormant) #536: Type-level literals as a sep language extension * we decided about the following proposals #583: HasField redesign, accept #626: Amendment of Visible Forall in Types, accept #493: SPECIALISE with expressions: accept #585: Amend Or Patterns (merged as #609), accept So we currently have to act on the following 9 proposals, same number than last time (but luckily different proposals). ## 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 2023-12-11: Vlads most recent push for a resolution Last suggestion was a “conditional accept”. Guess we should do that. #569: Multi-line string literals, Shepherd: Eric Acceptance pending, I believe #434: Fine-grained unused warnings, Shepherd: Chris 2023-07-90: Assigned to Chris 2023-09-09: Acceptance suggested Mostly positive responses #624: linear let-bindings 2023-12-07: Assigned to Richard 2024-01-06: Acceptance recommended ## Waiting for shepherd recommendation #597: Constraints synonyms in deriving heads 2023-07-25 Assigned to Moritz #606: 281 to use atype instead of ktype, 2023-11-30 Assigned to Richard #608: no implicit bindings with -XPatternSignatures 2023-08-17: Assinged to Richard #612: -fhpc tix file changes 2023-09-27: Assigned to Moritz #625: Stability Goals 2023-12-18: Assigned to Moritz With that I’d like to say thanks you all for bearing with my secretarial whims throughout the years and never ever once complaining about my sometimes Machiavellian shephard assignments. And thanks in particular to Adam to take over so readily; I believe the proposals are in good hands with you. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

#493: SPECIALISE with expressions, rec: accept
by Adam Gundry 23 Jan '24

23 Jan '24

Dear all, Richard and Simon propose to generalise SPECIALISE pragmas to allow expressions, not just type signatures: https://github.com/ghc-proposals/ghc-proposals/pull/493 https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-… This does not add anything fundamentally new, because such SPECIALISE pragmas can be translated using the existing RULES machinery, but it does make several idioms substantially more convenient: * Using type applications in a SPECIALISE pragma to avoid repetition * Manual call-pattern specialisation * Loop unrolling Thus I propose we accept this proposal. Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

7 9

#626: Amendment of Visible Forall in Types, recommendation: Accept
by Arnaud Spiwack 15 Jan '24

15 Jan '24

Dear all, Vlad is proposing to amend his own proposal https://github.com/ghc-proposals/ghc-proposals/pull/626 Being an amendment, it's, as always, not as straightforward to consume, but Vlad gives us a good summary of the changes in his pull-request description. All in all, it's almost entirely straightforward clarification. There are two items of notice: patterns for visible forall arguments were specified as: only variable or wildcard. The amendment changes it to allow data constructors applied to (0 or more) patterns as well. The amended version is consistent with how patterns for invisible forall arguments are specified. The second, and this one is for Moritz, is a small change in the parsing of view patterns (it does break two packages at least on Hackage, but I actually don't quite understand how the change can affect semantics. It's that tiny. Vlad proposes 3 releases with warning before effecting the change). Maybe there's a third item: `p -> q` parses differently depending on whether ViewPattern or RequiredTypeArguments (or both) is turned on. This is kind of icky, I suppose. But in the case where both are on, then ViewPattern wins, so there's no real harm in it. Do pay some attention to the new items in the alternatives section. Anyway, I recommend we accept. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

3 7

Modifiers and #512: NoFieldSelectors
by Vladislav Zavialov 14 Jan '24

14 Jan '24

Dear Committee Members, Our previous discussion regarding #512 was inconclusive. Thread 1: https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002… Thread 2: https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003… #512 is the proposal that introduces per-declaration, per-constructor, and per-field NoFieldSelectors annotations. I'm not quite sure how to summarize the discussion because everyone seems to have a unique view. But it all revolves around a syntactic issue: should the proposal use pragma-based syntax or modifiers-based syntax? Here are two facts to inform your opinion: 1. The Modifiers proposal is accepted, and it makes sense to use it for the proposed feature 2. The Modifiers proposal is, however, unimplemented So at the moment #512 says that we'd first introduce the pragma-based syntax, and when Modifiers are implemented we could deprecate the pragma-based syntax in favor of Modifiers. I am *strongly* opposed to introducing a feature that we know is destined for deprecation. But not everyone shares this attitude, apparently, so let's vote. Here are the options. Select all that you find acceptable (multiple-choice): * [ ] Accept the proposal with pragma-based syntax, then deprecate it and switch to modifiers-based syntax * [ ] Accept the proposal with pragma-based syntax, do not switch to modifiers-based syntax * [ ] Revise the proposal to use modifiers-based syntax and then accept * [ ] Reject the proposal regardless of syntax Before you vote, let me try to sway you towards the "revise" option. If we choose to revise, I volunteer to implement Modifiers in time for GHC 9.12. I believe Modifiers are a splendid idea and I envision many good uses for them. Vlad

6 6

GHC2024 tally
by Joachim Breitner 10 Jan '24

10 Jan '24

Dear committee, with all votes in (thanks!), the following extensions made quorum to form GHC2024: DataKinds DerivingStrategies DisambiguateRecordFields ExplicitNamespaces GADTs (and the implied MonoLocalBinds) LambdaCase RoleAnnotations See the full tally in the proposal: https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposa… Any final thoughts? Should we hold off accepting that in light of #628 (I don’t hope so). Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

GHC2024 voting
by Joachim Breitner 08 Jan '24

08 Jan '24

Dear Committee, there isn't much discussion, but maybe a silent consensus that we should go ahead with this? So please cast your vote about each of the following extensions; simply by replying to this email and putting an x next to those extensions you think should be part of GHC2024. * [ ] DataKinds * [ ] DefaultSignatures * [ ] DerivingStrategies * [ ] DisambiguateRecordFields * [ ] ExplicitNamespaces * [ ] GADTs with MonoLocalBinds * [ ] GADTs without MonoLocalBinds * [ ] LambdaCase * [ ] RoleAnnotations * [ ] TypeData * [ ] TypeFamilies * [ ] BlockArguments As per the process (#372) the quorum for inclusion is _7 votes_ out of the 10 current committee members. So it takes only four “no”s to block an extension. I’m putting GADTs in two both variants on the ballot. If “GADTs with MonoLocalBinds” makes it in, then its in, and only if not we look at “GADTs without MonoLocalBinds”. So it may make sense to vote in favor of both. Ballot boxes are upen until Jan 8th, but it is probably better for everyone if votes are casted sooner. Maybe we can do it within a week? Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

12 19

Please review #625: Stability Goals, Shepherd: Moritz
by Joachim Breitner 08 Jan '24

08 Jan '24

Dear Committee, Simon wrote up the new Stability policy: https://github.com/ghc-proposals/ghc-proposals/pull/625 https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princ… Given that Moritz has stability very high on his agenda, I suggest he shepherds this through the process. 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 1

Please review #569: multiline string literals, Shepherd: Eric
by Joachim Breitner 01 Jan '24

01 Jan '24

Dear Committee, Brandon Chinn has a proposal for multiline string literals. Let the bikeshedding begin. https://github.com/ghc-proposals/ghc-proposals/pull/569 https://github.com/brandonchinn178/ghc-proposals/blob/multiline-strings/pro… I’d like to nominate Eric as the shepherd. 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/

4 6