December 2023 - ghc-steering-committee

#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

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

GHC Committe Chairs term
by Joachim Breitner 22 Dec '23

22 Dec '23

Dear Simon and Simon, your current three terms on the committee end soon (Feb 2024). The bylaws say that you will stay on the committee without renomination and electing if you wish to do so (and the rest of the committee agrees with majority). Therefore I ask: do you want to stay on the committee for another term? (If you do I already register my vote to support this outcome, with four more such votes from non-chair-members we’ll have fulfilled this little ceremony.) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 2

GHC stability
by Simon Peyton Jones 22 Dec '23

22 Dec '23

Dear Jose, GHC Steering Group, and HF Stability Group There has been quite a lot of recent discussion about actions we could take to promote GHC stability. In an effort to gather these threads together I have written *GHC Staibility State of Play* <https://docs.google.com/document/d/1sX_rXHx8Mj3Kae9GalR2BwZ5-xzl7UpnpMBwl4d…> It articulates the Big Goal, and some discussions that are going on around it. Jose, I think that the Big Goal could be a helpful focus for HF. I'm not sure which of the strands is highest priority (causes most friction for users) so HF's guidance about that would be helpful. It would be great to move some of this forward. Simon

1 0

Please review #626: Visible Forall in Types, Shepherd: Arnaud
by Joachim Breitner 10 Dec '23

10 Dec '23

Dear Committee, Vladislav proposes to support visible forall in types of terms better: https://github.com/ghc-proposals/ghc-proposals/pull/626 https://github.com/ghc-proposals/ghc-proposals/pull/626/files 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, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #624: Linear lets, Shepherd: Richard
by Joachim Breitner 07 Dec '23

07 Dec '23

Dear Committee, Arnaud wants to amend linear types with linear lets: https://github.com/ghc-proposals/ghc-proposals/pull/624 https://github.com/ghc-proposals/ghc-proposals/pull/624/files I’d like to nominate Richard as the shepherd, given that he shepherded the Linear Types. But if you have too much on your plate, feel free to reassign to someone else. 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/

1 0