January 2024 - ghc-steering-committee

#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 tally
by Joachim Breitner 09 Jan '24

09 Jan '24

Dear committee, with all votes in (thanks!), the following extensions made quorum to form GHC2024: DataKinds DerivingStrategies DisambiguateRecordFields ExplicitNamespaces GADTs (and the implied MonoLocalBinds) LambdaCase RoleAnnotations See the full tally in the proposal: https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposa… Any final thoughts? Should we hold off accepting that in light of #628 (I don’t hope so). Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

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