- ghc-steering-committee

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

#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

Please review #412: splice imports, Shepherd: Vladislav
by Joachim Breitner 30 Apr '21

30 Apr '21

Dear Committe, Explicit Splice Imports has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/412 https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0… I’ll 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/

1 0

Proposal #402 (changes to GADT syntax); rec: accept
by Richard Eisenberg 21 Apr '21

21 Apr '21

Hi GHCSC, I am the shepherd for Proposal #402, which has been submitted for our consideration. Proposal text: https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-g… PR discussion: https://github.com/ghc-proposals/ghc-proposals/pull/402 ----------------- Proposal Summary: The proposal changes a few aspects of GADT constructor syntax, in part to make them simpler, and in part to make them more expressive. Only non-record syntax is treated by this proposal; GADT record constructors are entirely unaffected. The two changes are: 1. Drop support for parentheses around result types in GADT constructor signatures. 2. Add support for nested quantifiers in GADT constructor signatures. Examples & motivation: 1. This would now be rejected: data T where MkT :: Int -> (Bool -> T) Those parentheses are not allowed. On the other hand data S where MkS :: Int -> Bool -> (S) remains accepted. This change is mainly to simplify the implementation, but it also helps users understand that the thing after `MkS ::` really is not a type: it's a list of constructor arguments written in a concrete syntax that looks like a type. See the proposal for more explanation of how this is not a type. 2. This would now be accepted: data Q a where MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show a => Q (a,b) Note the appearance of `forall a ->`, `forall b.`, and `Show a =>` after visible arguments. Constructors with forall ... -> syntax (such as our MkQ) will not be allowed in expressions or patterns (that would require #281), but will be allowed in types. This change is a generalization of the syntax we have today, and it allows library authors more flexibility in designing interfaces, as they can now choose where type arguments should be written in a constructor. ------------------------ Recommendation: I recommend acceptance. 1. Dropping the parentheses sounds trivial, but keeping them means we have to do extra work in the design of our data structures to remember the parentheses. Because constructor "types" aren't types, this information isn't otherwise needed. 2. This generalization increases our expressiveness and removes what may feel like an artificial limitation. Furthermore, it is necessary in the case where we might have later arguments depend on earlier ones (possible for promoted constructors). Please share opinions on acceptance/rejection here, or technical thoughts on the ticket itself. I will accept in two weeks if there are no objections. Thanks! Richard

7 18

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

06 Apr '21

Dear GHC Steering Committee I'm recommending acceptance of Proposal #378: Support the design for dependent types<https://github.com/ghc-proposals/ghc-proposals/pull/378> 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://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>. 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://github.com/ghc-proposals/ghc-proposals/#review-criteria>: 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

6 6