- ghc-steering-committee

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

13 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

#390: Fine-grained pragmas, recommendation: accept
by Vitaly Bragilevsky 18 Sep '21

18 Sep '21

Dear Committee, Our own Alejandro has been proposed Fine-grained pragmas for classes, families, and instances https://github.com/ghc-proposals/ghc-proposals/pull/390 https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/000… His idea is to bring the flexibility of overlaps/overlapping/overlappable pragmas to termination checking, type inference, and constraint solving. Alejandro proposes to introduce the following %-modifiers (as in already accepted #370, https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-m… ): %NoTerminationCheck %LiberalCoverage %LiberalInjectivity %Overlapping %Overlappable %Overlaps to liberate conditions for classes and instances, type families, forall-types, etc. The first three modifiers can be used instead of the scary-sounding UndecidableInstances extension. The last three modifiers are supposed to be used instead of the overlap*-pragmas for instances we already have. Note that this proposal doesn't suggest deprecating those extensions and pragmas. I think that this proposal goes in the right direction and recommend accepting it. As far as I understand, all the committee members, including those with terms about to expire, have the right to either support this proposal or to raise a voice against it either here or at https://github.com/ghc-proposals/ghc-proposals/pull/390. Regards, Vitaly

5 7

Proposal #412: Explicit Splice Imports; rec: accept
by Vladislav Zavialov (int-index) 14 Sep '21

14 Sep '21

Dear Committee, Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration. Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0… Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412 The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation. All of the above are achieved by introducing a new form of import called a splice-import. Compare: import M import splice H Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices. At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax. Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation. Let me know what you think. - Vlad

6 6

GHC Steering Committee Status
by Joachim Breitner 14 Sep '21

14 Sep '21

Dear Committee, I hope you all had a lovely summer, an interesting ICFP and Haskell Love and other conferences, and are slowly moving back into action. What has happened since the last status (on July 1st)? * Simon suggested a better way to keep tabs on what’s going on. I’ll try to keep https://github.com/ghc-proposals/ghc-proposals/wiki/Status as up to date as the latest status email. I ran out of time today, so I did not yet try to make the format tabular and prettier. Sorry, next time! But I added a time stamp to each that roughly corresponds to the latest state change. * Cale has stepped down. Thanks for your contributions! * we were asked to review these proposals: #319: NoFallibleDo proposal (resubmission) #425: Invisible binders in type declarations, Shepherd: Richard * we have a recommendation from the shepherd about: #390: Fine-grained pragmas (accept) #319: NoFallibleDo proposal (reject) * we have sent the following proposals back to revision #390: Fine-grained pragmas #315: NoIncomplete (author wants to revisit) * we decided about the following proposals none this round? We currently have to act on the following 9 proposals, same as last round. ## Waiting for committee decision #281: Visible 'forall' in types of terms, Shepherd: Richard 2021-07-19: After still some more discussion, Richard again recommends to accept this, answering Simon M’s questions. Simon, are you fine with that? #283: Local modules, Shepherd: Arnaud 2021-05-20: Arnaud recommends to accepts, and wants more opinions. Opinions still sparse. Please give it! #302: Lambda expressions with guards and multiple clauses, Shepherd: SPJ 2021-07-29: Vote done, one open question about pragma design. #319: NoFallibleDo, Shepherd: Alejandro 2021-07-23: Rejection recommended Committee comments please? #392: Clarify modifiers design principle (Shepherd: Alejandro) 2021-07-23: Alejandro asked for more eyes. Discussion about grammar and compatibility with #390 open #409: Exportable named defaults, Shepherd: Eric 2021-09-10: SPJ wants to have a last look, reminder is set #412: splice imports, Shepherd: Vladislav 2021-06-24: Acceptance recommended Positive feedback so far, but more discussion Shall we accept it, Vladislav? ## Waiting for Shepherd action #400: Constrained COMPLETE sets, Shepherd: Vladislav 2021-06-22: Waiting for recommendation. Vladislav, time to get active! #425: Invisible binders in type declarations, Shepherd: Richard 2021-08-13: Waiting for recommendation. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #400: Constrained COMPLETE sets, Shepherd: Cale
by Joachim Breitner 14 Sep '21

14 Sep '21

Dear Committee, this is your secretary speaking: Constrained COMPLETE sets has been proposed by Sebastian Graph https://github.com/ghc-proposals/ghc-proposals/pull/400 https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/pr… This proposal tries to solve the same issue as Cale’s #399, and essentially has slightly different syntax. I therefore suggest that Cale is the shepherd, and hashes out with Sebastian the details of syntax so that they can both get behind it, and then makes a recommendation. 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 3