- ghc-steering-committee

Proposal #624 on linear let-bindings; recommendation: accept
by Richard Eisenberg 13 Feb '24

13 Feb '24

Hi all, I've reviewed Arnaud's https://github.com/ghc-proposals/ghc-proposals/pull/624 <https://github.com/ghc-proposals/ghc-proposals/pull/624> and wish to recommend acceptance. The proposal is an amendment to the proposal for linear types, adding support for linear let bindings. Today, if you have f :: T %1-> T f t = let t2 = t in t2 you'll get an error because t2 is not linear. The only way to bind a linear variable is via a `case`, never a `let` or `where`. This is annoying. With this proposal, the little program above is accepted, with an inferred linearity restriction on t2. Users can also annotated their lets like `let %1 x = ... in ...`. Bindings in `where` clauses can also be inferred or annotated as linear. There is a downside, of course: linear bindings have various restrictions, chiefly that they must be strict bindings (because projections are hard with linear types) and that bindings cannot be generalized. I'm a little unsure that the choices in the proposal (particularly around generalization) are the best for users, but I think the best way to learn is to experiment. In my understanding, the community knows that -XLinearTypes is subject to revision, and so I think we should just blast ahead, revising if and when necessary. Please share your thoughts! Thanks, Richard

8 24

Proposal #625 Articulate stability goals, recommendation: strong accept
by Moritz Angermann 05 Feb '24

05 Feb '24

Hi All, Pull request 625 (https://github.com/ghc-proposals/ghc-proposals/pull/625) is not a proposal as usual, but primarily amending the readme and principles. Simon has taken the Stability discussion we have had last year, and integrated the crystalized General Rules into the readme and principles. In my opinion, we have now debated this topic sufficiently, and found a formulation that captures the intent we want to set forward for the evolution of GHC. I think this spells out clear guardrails for GHCs evolution, as well as providing reassurance to commercial users of GHC regarding backwards compatibility and migration support though deprecation cycles when breakage is needed. As such, I strongly recommend acceptance of the proposal. While there has been a recent spark in discussion of warning flags, I do not believe that discussion to be productive towards the change this proposal tries to bring. I'd like to ask the committee to cast their final votes on this amendment to the readme and principles, by the end of the coming week. Unless someone objects, I'll merge this as it is now on the 10th of February. Best, Moritz

5 4

#625 stability criteria
by Simon Peyton Jones 03 Feb '24

03 Feb '24

Moritz You are the shepherd on #625 GHC Stability Goals. I submitted it to the committee on 18 December. Could you shepherd the discussion to a close? Personally think we can just land it now, but as the shepherd that is your role. Thanks Simon

1 0

Please review #631: Set program exit code by main return type, Shepherd: Arnaud
by Adam Gundry 30 Jan '24

30 Jan '24

Dear Committee, Shea Levy proposes that the value returned by `main` should determine the exit code of the program: https://github.com/ghc-proposals/ghc-proposals/pull/631 https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-mai… I'd like to nominate Arnaud as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process 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

2 3

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

27 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 22 Jan '24

22 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 22 Jan '24

22 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 13 Jan '24

13 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