January 2024 - ghc-steering-committee

Please review #617: Add -experimental flag, Shepherd: Simon M
by Adam Gundry 22 Mar '24

22 Mar '24

Dear Committee, Moritz proposes to add a new flag, -experimental, to guard experimental features: https://github.com/ghc-proposals/ghc-proposals/pull/617 https://github.com/angerman/ghc-proposals/blob/std-experimental/proposals/0… I’d like to nominate Simon Marlow 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

3 2

Proposal #606: small syntax change around types in terms; recommendation: vote
by Richard Eisenberg 26 Feb '24

26 Feb '24

Proposal #606 <https://github.com/ghc-proposals/ghc-proposals/pull/606> has been submitted to the committee, by Vlad. This proposal makes a tiny change. Suppose we have `f :: forall (x :: Type) -> x -> ...` (this is part of -XRequiredTypeArguments). Then (as proposed) we can write `y = f (type Int -> Int) abs ...`. The `type` keyword here is to signal that what comes is a type: it should be parsed as a type and name-resolved as a type. This might matter if there is, say, a constructor Int in scope. The proposal at hand is whether to accept the above program or to require extra parentheses, thusly: `y = f (type (Int -> Int)) abs ...`. That's it -- that's the entire proposal. (It says we should _not_ accept the former, without parentheses.) The motivation is to avoid surprising users. Normally when we have `word1 word2 -> word3`, word1 and word2 will associate more closely than the arrow. Yet the first example has `type Int -> Int` where the arrow binds more tightly. Because `type` is a keyword, this is no challenge to parse and is not ambiguous -- it's just perhaps confusing to users. There was some debate in the proposal, but in my perusal, not a clear indication toward any particular direction. The most rigorous statement I could find is that the new syntax is a subset of the original, and so we can easily reverse this decision later. I propose we vote on the matter. We have two choices: 1. Original syntax: allow `(type Int -> Int)` as an argument. 2. Amended syntax: require `(type (Int -> Int))` as an argument. -------------------------------- My vote: 1. There are many keywords in Haskell, and we are used to parsing these differently. For example, if we have `f (do x <- blah ...)`, we know quite well that the <- is within the `do`, not the other way around. Ditto `case`: we don't require scrutinees to be parenthesized. I posit that the strangeness some have felt around `(type Int -> Int)` is (understandable) confusion in the face of novelty. But the `type` herald will not be novel forever, and I think we'll enjoy having fewer parentheses in our code in the long run. (I might be arguing for "2 today, then 1 tomorrow". But let's just skip the intermediate step and do 1 now.) I welcome your opinions and votes. It would be great to conclude this in the next 2 weeks, by Feb 7. Thanks! Richard

6 6

Proposal #608, -XPatternSignatureBinds. Rec: accept
by Richard Eisenberg 26 Feb '24

26 Feb '24

John Ericson has submitted proposal #608 <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding -XPatternSignatureBinds. The proposal is an amendment and is thus a little harder to consume. I recommend reading the summary here. Proposed change: The proposed -XPatternSignatureBinds takes a piece out from -XPatternSignatures: with only -XPatternSignatures and not -XPatternSignatureBinds, a pattern signature can mention in-scope type variables but can never bind fresh ones. With -XPatternSignatureBinds, an appearance of an out-of-scope type variable in a pattern signature will cause the variable to be bound to the type it unifies with. -XScopedTypeVariables will imply -XPatternSignatures -XPatternSignatureBinds (and a few more), so the behavior of -XScopedTypeVariables is completely unchanged. Note that -XPatternSignatures is currently deprecated (and has been so for a long time), so a change in behavior there is not so bad. Motivation for the change: - It is awkward to have a rule in a language where scoping behavior depends on what else is in scope. This can confound e.g. tools meant to find the bindings sites of a variable occurrence. - The implicit binding we have today plays poorly with the plan to allow users to pretend GHC has a unified namespace. That is, suppose x is in scope as a term variable, and then we have f (... :: ... x ...) = ... . Should that x be bound implicitly there or not? It's pretty unclear. By separating out -XPatternSignatureBinds from -XPatternSignatures, users of the latter are insulated from worrying about this potential future change. My opinion: - John has argued that this will make future namespace changes easier. I disagree with this assessment, because -XScopedTypeVariables is utterly pervasive. So the problem that this change is supposed to solve becomes only a tiny bit smaller, benefiting only those users who carefully enable -XPatternSignatures but not, say, -XScopedTypeVariables. - But in the end, I don't care all that much. I've come to the opinion that we shouldn't worry about the distinction between warnings and extensions. The net effect of this proposal is to promote a warning into an extension (because we previously had -Wpattern-signature-binds). So if we shouldn't worry about this distinction, then this proposal is a no-op on the aspects of the language we should care about, and thus accepting and rejecting have the same effect. (This little analysis only makes sense because the features are so new -- there's no broad re-education to do or back-compat issues.) - Accepting will make at least one person (John) happy. And I don't note anyone who would become unhappy. More happy people is more better. So I recommend acceptance. :) Please let us know your thoughts! Richard

9 28

Proposal #612: Change semantics of -fhpc to not accumulate data over multiple runs, rec: accept
by Moritz Angermann 25 Feb '24

25 Feb '24

Dear Committee members, In Proposal #612 <https://github.com/ghc-proposals/ghc-proposals/pull/612>, David Binder suggests changing the semantics from `-fhpc` to auto-ingest existing .tix files for accumulation, towards _not_ auto-ingesting them and instead overwriting the .tix file with the coverage of the latest run. I agree with his assessment that the current behaviour easily leads to unexpected surprises. He suggests adding a flag --read-tix-file= to control this behaviour and defaulting that to _no_, with a grace and deprecation period prior informing the user that the currently accumulating feature will change in a future GHC release. Adding the flag to control this behaviour is fairly uncontroversial I hope, however I'd like you to. Weight in on the default. Should we change the default behaviour, or only add the flag? I'd recommend changing the default to --read-tix-file=no after a deprecation period. Best, Moritz

8 11

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

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