- ghc-steering-committee

Stepping down for now
by Cale Gibbard 10 Jul '21

10 Jul '21

I've been having trouble finding time and energy to keep track of GHC steering committee stuff of late, so it's probably best if my place was assigned to someone else. I'll still be around of course, given that my work with Obsidian has me doing GHC development right now, but it's hard to do that, and then also find spare time for this. Thanks! - Cale

2 1

GHC Steering Committee Status
by Joachim Breitner 01 Jul '21

01 Jul '21

Dear Committee, I had some busy months, so this status update is a bit later than expected… but you were all reasonably busy without me, so that’s fine. Over the summer I’ll be away from a laptop for a few weeks, so more than usually please keep tabs on your open tasks, and listen to Tom's nudges. So here’s the delta since May 17th. * Simon suggests a better way to keep tabs on what’s going on. Please join the that discussion! * Iavor left the committee. 👋 * we were asked to review these proposals: #351: NoIncomplete, Shepherd: Vitaly #281: Visible 'forall' in terms, Shepherd: Richard #390: Fine-grained pragmas, Shepherd: Vitaly (back from revision) * we have a recommendation from the shepherd about: #409: Exportable named defaults (partial accept) #283: Local modules (again) (accept) #351: NoIncomplete (accept) #281: Visible "forall" in terms (accept) #412: Explicit Splice Imports (accept) * we have sent the following proposals back to revision #400: Constrained COMPLETE sets (but it’s back already) * we decided about the following proposals #378: support the design for dependent types (accept) We currently have to act on the following 9 proposals, up by 1. ## Waiting for committee decision #281: Visible 'forall' in types of terms, Shepherd: Richard Richard recommends to accep this. It kicked off a discussion about points that one could argue have been covered by #378 already. Conversation has stalled since a month. Simon M, Richard, can you make progress on your conversation? #283: Local modules, Shepherd: Arnaud Arnaud recommends to accepts, and wants more opinions. Please give it! #302: Lambda expressions with guards and multiple clauses, Shepherd: SPJ Committee is preparing a vote #351: NoIncomplete, Shepherd: Vitaly Looks like it’s going to be rejected, since people are partial to -Wpartial instead. Waiting for the author to concur. #392: Clarify modifiers design principle (Shepherd: Alejandro) One comment only so far, please add more. #409: Exportable named defaults, Shepherd: Eric Deliberations about import behavior is going on. #412: splice imports, Shepherd: Vladislav Positive feedback so far. Shall we accept it, Vladislav? ## Waiting for Shepherd action #390: Fine-grained pragmas, Shepherd: Vitaly Vitaly, this is back from revision. What do you think about it? #400: Constrained COMPLETE sets, Shepherd: Vladislav Waiting for recommendation. Vladislav, the author says they addressed your concerns, and it’s now again in your court. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Proposal #302: `\of`
by Richard Eisenberg 01 Jul '21

01 Jul '21

Hi all, Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves. PR: https://github.com/ghc-proposals/ghc-proposals/pull/302 Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-… Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075… The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea: mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y) The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual. I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time. Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax. Richard

10 29

#351: NoIncomplete, rec: accept
by Vitaly Bragilevsky 11 Jun '21

11 Jun '21

Dear Committee, We have been discussing the NoIncomplete pragma proposal by John Ericson for quite a long time. I think it's ready for acceptance. The proposal itself: https://github.com/ghc-proposals/ghc-proposals/pull/351 The rendered version: https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness… The proposal aims to introduce the NoIncomplete pragma that would prohibit programs which have a source of incompleteness (in patterns, in methods) in them. There is also the new -fdefer-incompleteness-errors flag. I think this feature comes quite handy in education. I'd use it all the time with my students. Please comment here or in the GitHub thread if you see any problems with this proposal. Vitaly

5 4

Please review #281: Visible 'forall' in types of terms, Shepherd: Richard
by Joachim Breitner 27 May '21

27 May '21

Dear Committee, this is your secretary speaking: Visible 'forall' in types of terms has been proposed by Vladislav https://github.com/ghc-proposals/ghc-proposals/pull/281 https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… This was just resubmitted, given that #378 was accepted. The previous shepherd was Iavor; I am suggesting Richard as the new shepherd, as he was heavily involved in the Github thread already. 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

Recommendation for #378: support the design for dependent types
by Simon Peyton Jones 26 May '21

26 May '21

Dear GHC steering committee OK Richard has now revised the "Design for Dependent Types" proposal, and has resubmitted it. As we asked, it now includes the design sketch that constitutes the direction of travel advocated in the proposal, rather than merely referring to it. Here it is once more<https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/…> I propose acceptance. Remember: * We would not be accepting every detail of the design in Section 4 - rather, we expect further specific proposals as we move in the direction described in the proposal. So we should not debate the fine print of Section 4. * We would be accepting that the proposal describes a direction of travel that we are happy with. That in turn gives people the confidence to invest efforts in those more detailed proposals. As the "Proposed change specification" says: "When evaluating new proposals, the GHC committee would consider compatibility with the design sketch below. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features." Any views? Questions of clarification or technical questions belong on the comment stream. Thanks Simon From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org> On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 06 April 2021 13:58 To: ghc-steering-committee(a)haskell.org Subject: Re: [ghc-steering-committee] Recommendation for #378: support the design for dependent types Richard and I have discussed this. We concluded that we'd put it back into "Needs revision" status. He's going to expand it (substantially) to include the proposed design sketch of dependent types on the GHC wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. Then he'll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail. Simon From: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Sent: 29 March 2021 13:17 To: ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Recommendation for #378: support the design for dependent types Dear GHC Steering Committee I'm recommending acceptance of Proposal #378: Support the design for dependent types<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> As you'll see, there is a lot of useful context, but the payload is pretty simple When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features. Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly. See also the committee's Review Criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language. Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever. Any views? Let's try to converge rapidly.... the proposal has been substantially refined by a lot of debate. Simon

8 16

Stepping down from the committee
by Iavor Diatchki 22 May '21

22 May '21

Hello, I think it is time for me to step down from the GHC committee---lately I find that I don't have the enthusiasm I used to have for reviewing or discussing proposals, so it makes sense to make space for someone who is passionate about doing this work. Thanks for working with me, and I am looking forward to having a beer with you all at ICFP once the world reopens! -Iavor

7 6

Please review #351: NoIncomplete, Shepherd: Vitaly
by Joachim Breitner 20 May '21

20 May '21

Dear Committee, this is your secretary speaking: The NoIncomplete pragma has been proposed by John Ericson https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness… This was shepherded by Iavor, who stepped down, and I suggest Vitaly takes over. Vitaly, maybe comment on the Github thread in an encouraging way, to reduce frustration by the author about the longer than usual delay. 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

GHC Steering Committee Status
by Joachim Breitner 17 May '21

17 May '21

Dear Committee, are are keeping up a healthy pace, it seems, so time another status update. So here’s the delta since April 5th. * we were asked to review these proposals: #415: OPAQUE pragma (Shepherd: Tom) #412: splice imports (Shepherd: Vladislav) #392: Clarify modifiers design principle (Shepherd: Alejandro) #351: NoIncomplete (back from revision, Shepherd: Iavor) #302: Lambda expressions with guards and multiple clauses (back from revision, Shepherd: Cale) * we have a recommendation from the shepherd about: #402: Stable GADT syntax (back from revision, accept) #378: support the design for dependent types (accept) #371: Stop treating ~ magically (back from revision, weak accept) #415: OPAQUE pragma (accept) #392: Clarify modifiers design principle (recommendation: acceptance) * we have sent the following proposals back to revision -none- * we decided about the following proposals #402: Stable GADT syntax (accept) #371: Stop treating ~ magically (accept) #415: OPAQUE pragma (accept) We currently have to act on the following 8 proposals, up by 2. ## Waiting for committee decision #378: Support ergonomic dependent types, Shepherd: Simon PJ Recommendation is to accept, a few people have voiced their opinion, but Simon rightfully asked for more. #392: Clarify modifiers design principle (Shepherd: Alejandro) One comment only so far, please add more. ## Waiting for Shepherd action #283: Local modules, Shepherd: Arnaud Waiting for recommendation. No action since a while. Arnaud, can you pick this up? #302: Lambda expressions with guards and multiple clauses, Shepherd: Cale This is back from revision, ready to be picked up. #351: NoIncomplete, Shepherd: Iavor This is back from revision, ready to be picked up. #400: Constrained COMPLETE sets, Shepherd: Cale Waiting for recommendation. No action since three months. Cale, can you drive this forward? #409: Exportable named defaults, Shepherd: Eric Waiting for recommendation. No action since two months. Eric, any recommendation so far? #412: splice imports (Shepherd: Vladislav) Waiting for recommendation. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #415: OPAQUE pragma, Shepherd: Tom
by Joachim Breitner 17 May '21

17 May '21

Dear Committe, OPAQUE pragma has been proposed by Christiaan Baaij https://github.com/ghc-proposals/ghc-proposals/pull/415 https://github.com/christiaanb/ghc-proposals/blob/master/proposals/0000-opa… I’ll propose Tom 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/

6 8