May 2021 - ghc-steering-committee

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

#371: Stop treating ~ magically. Rec: weak accept
by Richard Eisenberg 10 May '21

10 May '21

Hi all, I am shepherding proposal #371. Proposal: https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/00… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/371 Summary: Currently, the type equality operator (~) is always in scope, but you can use it only if -XGADTs or -XTypeFamilies is enabled. The proposal instead changes this arrangement to export (~) from Data.Type.Equality (an existing module in `base`), and requiring -XTypeOperators to use it (as we do for all other infix operators in types). There is an 8-release migration plan, where for 6 releases, all uses of (~) that do not import it from Data.Type.Equality will get a warning telling the user to import Data.Type.Equality. The motivation for the proposal is uniformity: the goal is to treat (~) just like other type operators. Recommendation: I'm very much on the fence on this one, but in the end fall into the "accept" camp. The goal here is to achieve a simple cleanup in the language design (and implementation). It's a worthy goal, but it's disruptive. However, I think the disruption is small enough that it motivates the change. The fix for affected users is quite quick, and large-scale Haskell users probably already have a custom prelude that could make the change even easier to accommodate. Note also that TypeOperators is part of GHC2021, and so the change will likely only be a new import. What do others think? Without dissent, I will mark this proposal as accepted in two weeks. Thanks, Richard

6 16