- ghc-steering-committee

Please review #413: GHC Maintainer Preview, Shepherd: Vlad
by Joachim Breitner 31 Oct '21

31 Oct '21

Dear Committee, this is your secretary speaking: GHC Maintainer Preview, a change to GHC's release process, has been proposed by Hécate Moonlight. https://github.com/ghc-proposals/ghc-proposals/pull/413 https://github.com/Kleidukos/ghc-proposals/blob/patch-1/proposals/0000-ghc-… I propose Vladislav as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

#433: the Unsatisfiable constraint; recommendation: accept
by Tom Harding 28 Oct '21

28 Oct '21

Hi all, Firstly, apologies for the radio silence - I’ve apparently been having some undiscovered email trouble (perhaps even since joining the committee), and so I’m now going to be using my usual, and hopefully far more reliable, email address. With that said, I’d like to recommend proposal #433 <https://github.com/ghc-proposals/ghc-proposals/pull/433> for acceptance. The proposal does a good job of outlining the difference between this and the current TypeError mechanism, and I think the case is well justified. Certainly, the ability to bypass fundep checks in error case “instances” immediately brought to mind a handful of places in my own libraries that could benefit from this check. I think the thread already contains a lot of committee activity, but I welcome any further comments! Thanks, Tom

4 3

#283: Local modules (again), recommendation: accept
by Spiwack, Arnaud 19 Oct '21

19 Oct '21

Dear all, It is time to review the local modules proposal, from our own Richard Eisenberg, again. In fact it’s been time for a while, and I must apologise to Richard for not having understood that. Sorry, Richard. Link: https://github.com/ghc-proposals/ghc-proposals/pull/283 Since the last time, the proposal has been both simplified and made more precise. The main issues solved by this proposal are - The ability to export qualified names from modules - The ability to define functions with qualified names within a module ( *e.g.* you could have both T.f and U.f). - The ability to locally refer to qualified data as unqualified (suppose Set.map is in scope, then the proposal lets you write let import module Set in map f (map g some_set). I think these are three important issues, and the proposal makes a good case that they ought to be solved together. I also think that the specification is clear and doesn’t leave any dark corner. Caveat: I have contributed to writing the current specification, so I may be missing some flaws. The proposal does introduce a somewhat byzantine semantic difference between module X and module qualified X in export lists. This is to keep the current meaning of module X which is already not very intuitive (cf https://ro-che.info/articles/2012-12-25-haskell-module-system-p1 ). I think this is unavoidable. There are also 3 optional pieces of specification that we are asked to rule on (§4). I’m personally in favour of option 1. I’m weakly in favour of option 3 (with a preference for the variant described in Alternative 7). On the other hand option 2 seems to add a bit too much syntactic subtlety to be worth it (though if we choose option 2, I see no reason not to accept Alternative 3 as well). /Arnaud

8 23

Please review #433: the Unsatisfiable constraint, Shepherd: Tom
by Joachim Breitner 17 Oct '21

17 Oct '21

Dear Committee, this is your secretary speaking: Unsatisfiable has been proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/433 https://github.com/adamgundry/ghc-proposals/blob/unsatisfiable/proposals/00… I propose Tom Harding as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Visible forall: 3-Year Anniversary
by Vladislav Zavialov (int-index) 14 Oct '21

14 Oct '21

Dear GHC Steering Committee, Today (10 Oct, 2021) marks three years since the pull request for the #281 “Visible forall” proposal was opened. https://github.com/ghc-proposals/ghc-proposals/pull/281 There has been a lot of discussion, which led to numerous refinements and improvements to the proposal text and its content. When the initial version of the proposal was written, it wasn’t clear if this feature would be a good addition to Haskell. But now that #378 “Design for dependent types” has been accepted, the job of #281 “Visible forall” is merely to elaborate the details of a design that we already agreed on. Because of its reduced scope, I hope there won’t be a 4th anniversary. So I invite everyone to take a look at the current iteration of the proposal and vote on it. The proposal text is at: https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… - Vlad

3 3

GHC20xx review; GHC2022 yes or no?
by Joachim Breitner 11 Oct '21

11 Oct '21

Hi Committee, when we defined the process for GHC20xx, as written in https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-g… we wrote Likely, the first iteration of this process will be vastly different from the following ones: The first one is expected to add a large number of uncontroversial extensions; so the next iteration will likely only make a smaller, but more controversial change. Therefore, this proposal does not commit to a fixed cadence. Instead, 6 months after the first release of a version of GHC that supports a GHC20xx set, we evaluate the outcome, the process, and the perceived need of a next release. At that time we will refine the processes, if needed, and set a cadence. The first version of GHC that supported GHC20xx is 9.2, released in March. So we should do this evaluation now. My impression is that 9.2 hasn’t reached the masses yet: NixOS stable doesn’t even have it, and the default is at 8.10. Stackage LTS is at 8.10, and nightly at 9.0 Debian is at 8.8. So it seems premature to try to evaluate its impact, and what, if anything, we should do differently for a hypothetical GHC2022. So I suggest we postpone this review for another half year or so. Also, I don’t see why GHC2022 would be different than GHC2021. Not that much has changed about GHC and its set of “should-be-default” extensions since last year, has it? So I suggest we don’t work on defining GHC2022, and the next update will be GHC2023 (or later). What do you think, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5

Please review #409: Exportable named defaults, Shepherd: Eric
by Joachim Breitner 01 Oct '21

01 Oct '21

Dear Committe, Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/pro… I propose Eric as the Shepherd. This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 36

Proposal #400: COMPLETE set signatures; rec: accept
by Vladislav Zavialov (int-index) 23 Sep '21

23 Sep '21

Dear Committee, Proposal #400 "COMPLETE set signatures” by Sebastian Graf has been submitted for our consideration. Read it here: https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/pr… Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/400 The proposal presents an alternative treatment for type annotations on COMPLETE pragmas. Today one could write {-# COMPLETE P, Q :: Either #-} where P and Q are some pattern synonyms. But this isn’t even well-kinded. Instead, the author proposes that we ask our users to write {-# COMPLETE P, Q :: Either l r #-} By requiring a proper type on the RHS, we also gain the ability to talk about more advanced use cases (described in the proposal). I recommend acceptance. In fact, I learned about the way these annotations are treated today only from reading the proposal, and it came as a surprise to me. Using proper, well-kinded types there, seems like the right thing to do even if we ignore the new use cases it enables. Let me know what you think. - Vlad

7 6

Stepping down
by Alejandro Serrano Mena 21 Sep '21

21 Sep '21

Hello everybody, In the last time I hadn’t had the energy to follow many of the discussions in this committee, and I don’t think this will change soon, so I would like to step down from the committee. If you think it’s OK, I can keep shepherding the proposal which was assigned to me (NoFallibleDo), since it doesn’t feel right to put that on somebody else’s shoulders. Kind regards, Alejandro

4 3

Proposal #302: Multiway lambda: time to vote
by Simon Peyton Jones 21 Sep '21

21 Sep '21

Friends Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. I have not heard from Tom or Vitaly, I think, but I'll take silence for agreement with the ballot list. So it is time to vote! Please go here<https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAI…>, and vote. Feel free to add pros/cons to the list on that page. Please vote by next Thursday, 22 July, at the latest. It's a balance of judgement, for sure, not technically complicated. Simon From: Simon Peyton Jones <simonpj(a)microsoft.com> Sent: 28 June 2021 10:45 To: ghc-steering-committee(a)haskell.org Cc: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) Dear Steering Committee Two weeks ago I asked * Are there any other alternatives you strongly want on the ballot? I got these responses * Joachim, Simon, Alejandro, Arnaud: nothing to add * Vitaly, Eric, Tom, Richard, Vlad: no response I'd love to hear from the five of you, please. I want to get a decision on this, and I can't do that if I don't hear from you. Thanks Simon From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org<mailto:ghc-steering-committee-bounces@haskell.org>> On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 15 June 2021 13:52 To: Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>>; ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) | I'd like to reassing shepherding of this one. | | It seems to be clear that we want "something like this", there are many ways | to skin the cat, so it comes down to opinion and what we need is a decision | (or a call to votes). As with anything that's possibly quite opinionated, | it's good to have an authorative voice, so in this case, Simon PJ. | | Simon, can you either come up with a "all things considered, I think this | variant is the (narrowly) the best" recommendation or, alternative, a | "please vote on the following options" verdict? OK, to remind everyone * Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> * Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax. The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives * Option (1) \cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } * Lives alongside \case, but allows multiple patterns * Other keywords are possible, but I think it must be a variant on \case * Option (4) Same, but use \case as the keyword * Incompatible with existing \case => extended transition period, unhappy users * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. * Option (X). Reject the proposal. Personally I favour (1). I'm relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I've decided I like \cases precisely because it's the plural of \case, which is exactly what is going on. I think we'll end up having to vote on this, which is fine when it's a judgement call about syntax. But first: * Are there any other alternatives you strongly want on the ballot? I say "strongly" because I don't want to open up a big new debate... we at the stage of trying to narrow options. Thanks Simon

9 22