- ghc-steering-committee

#632: Phased introduction of GHC2024
by Adam Gundry 22 Apr '24

22 Apr '24

Dear committee, In #632, I propose amending the GHC2024 proposal to specify that the default language used by ghc/ghci when run directly will remain GHC2021 for now, since changing to GHC2024 is not backwards compatible. (This does not affect Cabal packages either way, since Cabal specifies its own default.) https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposal… On the discussion thread, some people expressed a preference that GHC should default to the latest language edition anyway. There is also Richard's suggestion of wider changes of approach in #636. However, given that the GHC 9.10 fork date is fast approaching, introducing GHC2024 but not making it the default seems like the best short-term solution to me. We can always reassess our approach to this for future releases as part of the wider discussion. If you object to the proposed approach, please speak up ASAP. Otherwise I plan to merge in a week or so. 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

9 20

Fine-Grained Unused Warnings (#42)
by Chris Dornan 19 Apr '24

19 Apr '24

Proposal: Fine-Grained Unused Warnings (#42) Author: Jakob Brünker Rendered proposal: https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/pro… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434 Recommendation: Acceptance ## Summary The proposal partitions warning about unused identifiers into a) bindings that are truly unused (not mentioned anywhere) and b) bindings that are mentioned exclusively in code that is itself (transitively) unused, and suppresses the latter unless the -freport-indirectly-unused-bindings flag is specified. The proposal is concise with some well-chosen examples and I recommend everyone at least skim it. I propose that we accept this proposal if nobody objects by the start of next week (Monday, 2024-02-19). Chris

6 14

Please review #640: Fix quantification order for a `op` b and a %m -> b
by Adam Gundry 16 Apr '24

16 Apr '24

Dear Committee, Vlad proposes to change the order of implicit quantification for type variables occurring as type operators or in multiplicity annotations: https://github.com/ghc-proposals/ghc-proposals/pull/640 https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantificati… I'd like to nominate Malte as the shepherd (welcome Malte!). 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

8 15

Proposal #638: Prefix form for MkSolo# (Recommend Accept)
by Matthías Páll Gissurarson 14 Apr '24

14 Apr '24

Greetings committee! In [proposal #638](https://github.com/ghc-proposals/ghc-proposals/pull/638), @int-index proposes that we introduce a prefix form of MkSolo#, and apparent oversight in proposal #475 [Non-punning list and tuple syntax]( https://github.com/ghc-proposals/ghc-proposals/pull/475) Previously, you would write `(# a #)` to construct a `Solo# a`. But the question is: what would be the prefix form of this constructor? It can't be `(# #)`, because this is already defined as a constructor of `Unit#`! This amendment proposes the `MkSolo#` constructor, having us write `MkSolo# a` for the prefix form. The discussion seems unanimous, after care was taken to clarify that a fully applied `MkSolo# a` would still be pretty printed as `(# a #)`, avoiding programmer confusion. It seems quite straightforward to me, so: I recommend accepting this amendment to #475. -- -- Matthías Páll Gissurarson <http://mpg.is/>

5 11

Update on nomination round
by Adam Gundry 26 Mar '24

26 Mar '24

Hi everyone, Just a quick update on the current nomination round, which we started earlier this month following Malte and Matthías joining: so far I've received 4 nominations. We were originally planning to accept up to 3 new members depending on the applications we receive, though we can of course reconsider this. I intend to allow another week or so for nominations, then distribute the nominations privately for consideration by the committee. So if you are still planning to encourage someone to apply, please do so ASAP. 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

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

23 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

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