- ghc-steering-committee

Re: [ghc-steering-committee] Proposal #608, -XPatternSignatureBinds. Rec: accept
by Richard Eisenberg 13 Mar '24

13 Mar '24

Given the quiet here -- and the fact that this proposal seems to have a pretty small impact -- I've accepted. Richard > On Feb 26, 2024, at 8:29 AM, Richard Eisenberg <rae(a)richarde.dev> wrote: > > > >> On Jan 29, 2024, at 6:03 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> >> I might be a bit confused, but doesn't this proposal change the meaning of an existing extension (PatternSignatures)? In which case shouldn't we do it properly according to our stability principles and either introduce the new behaviour as a new extension, or restrict the change to GHC2024 and later only? >> > > Picking up this thread again (sorry for the delay). > > As a reminder to all, about where we stand: This is about a small change to the deprecated extension -XPatternSignatures (which has been deprecated for at least as long as I've been doing Haskell). I personally don't see much merit in the change (it seems to achieve its goal only in a world where -XScopedTypeVariables is somehow deprecated, and that world seems unlikely to me), but neither do I see much downside. John Ericson, the proposer, sees an upside to the change, as does Joachim. We had basically settled leaning toward acceptance. Simon M wonders above about how this interacts with our stability principles. > > In response to Simon: I think this is fine w.r.t. our stability principles, which include (GR3), saying that any change should come with a deprecation period. -XPatternSignatures has been deprecated for over a decade, which I think is sufficiently long. On the other hand, the deprecation doesn't describe the upcoming change, but I still think it's OK. > > Richard

1 0

Re: [ghc-steering-committee] Proposal #606: small syntax change around types in terms; recommendation: vote
by Richard Eisenberg 13 Mar '24

13 Mar '24

Let's call this one accepted. I've merged the MR. Richard > On Feb 26, 2024, at 8:42 AM, Richard Eisenberg <rae(a)richarde.dev> wrote: > > I've been on the fence, as have others here. Simon PJ describes himself as being far from the fence -- and in the same place as Vlad, our proposer and intrepid implementer. So while I'm not deeply convinced in my soul about this, I think the right choice as a committee is to go with option (2) in this thread (which is what the proposer is asking for). > > I don't see much of a reason to keep extending this debate (everyone who is saying they care strongly is getting their way), but out of courtesy let's extend this to the end of the month (one extra day this year!). If I don't hear further comments, I'll accept this on Thursday. > > Thanks! > Richard > >> On Jan 25, 2024, at 7:07 AM, Simon Peyton Jones <simon.peytonjones(a)gmail.com <mailto:simon.peytonjones@gmail.com>> wrote: >> >> I vote (2), fairly strongly >> >> Remember this comment from Vlad: >> >> @phadej <https://github.com/phadej> For what it's worth, this was my initial thinking when I put ktype there, so past me agrees with you. What changed my opinion is that two years later (i.e. now) I looked at the examples like fn (type Int -> [a]) and had to double check the specification if it was supposed to be fn ((type Int) -> [a]) or fn (type (Int -> [a])). >> >> The point is that the `type` namespace changer can appear deep within a type. It's not like "@"! For exmaple >> fn ((type K) -> [a]) >> makes perfect sense. fn has a required type argument, but in the (type K) sub-part of the type do we switch to the type namespace. (Maybe K is in scope also as a data constructor.) Without the parens, do you really want to wonder about how this parses? >> fn (type K -> [a]) >> >> I prefer code that is slightly longer, but much clearer, than saving two characters but requiring reference to the user manual to parse. >> >> Let's make it simple and unambiguous for now. If it seems painful in practice we can debate liberalising it. >> >> Simon >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee(a)haskell.org <mailto:ghc-steering-committee@haskell.org> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >

1 0

Welcome Malte and Matthías, and other membership changes
by Adam Gundry 09 Mar '24

09 Mar '24

Dear all, Following the recent nomination round, the committee is delighted to welcome Malte Ott and Matthías Páll Gissurarson as new members. Thank you both for your willingness to volunteer. I will add your details to the GitHub repo, and you are encouraged to contribute to the discussion of any of the proposals under committee review. Richard Eisenberg, Joachim Breitner and Vladislav Zavialov are reaching the end of their terms, and have decided to step down. On behalf of the Haskell community, we are very grateful for your dedicated service over the years, which has been instrumental in helping GHC flourish. Given that this results in a net reduction in size of the committee, we have decided to open a second round of nominations where we will consider appointing up to 3 more members. I will post an update to the announcement on Discourse [1], and I strongly encourage all members of the committee to consider whom they could personally invite to join us. Best wishes, Adam [1] https://discourse.haskell.org/t/ghc-steering-committee-call-for-nominations… -- 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

6 11

Please review #638: Prefix form for MkSolo# (amendment of #475)
by Adam Gundry 06 Mar '24

06 Mar '24

Dear Committee, Vlad proposes to amend Richard's proposal #475 (Non-punning list and tuple syntax) to define an unambiguous prefix form for the Solo# constructor: https://github.com/ghc-proposals/ghc-proposals/pull/638 I'd like to nominate Matthías as the shepherd (welcome Matthías!). 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

1 0

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

Please review #592: Scoped kind variables in standalone kind signatures
by Adam Gundry 25 Feb '24

25 Feb '24

Dear Committee, Vlad proposes to amend StandaloneKindSignatures to support scoped kind variables: https://github.com/ghc-proposals/ghc-proposals/pull/592 https://github.com/int-index/ghc-proposals/blob/scoped-saks/proposals/0054-… 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, 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

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

Shepherding
by Simon Peyton Jones 22 Feb '24

22 Feb '24

Dear shepherds We still have eight GHC proposals in our inbox, some dating back quite a long way. I know that progress is being made on some (thank you), but others seem to have stalled. Please could you make time to push our debate forward? It need not take long. But if the shepherd does not push onward, no one else does, and we really owe our authors a timely response. I would much prefer not to have to nag you. I feel bad doing so; but I also feel bad not doing so. Thanks! Spreadsheet here <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu…>. Do keep it up to date. Simon #434 Unused warnings Chris 2 Jul 2023 #608 -XPatternSignatures without implicit binds Richard 17 Aug 2023 #612 -fhpc tix file changes Moritz 27 Sep 2023 #606 Amendment to #281: atype not ktype Richard 29 Nov 2023 #617 Add -experimental flag Simon M 25 Jan 2024 #631 Type of main fixes return code Arnaud 27 Jan 2024 #592 Scoped kind variables in SAKS Eric 8 Feb 2024 #632 Phased introduction of GHC2024 Adam 15 Feb 2024

1 0

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