- ghc-steering-committee

#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

GHC Steering Comittee Status
by Joachim Breitner 05 Apr '21

05 Apr '21

Dear Committee, an easterly status update. The last 1½ was relatively active, and we have a solit throughput. Keep it up! So here’s the delta since last month. * Vladislav joined! Also Iavor, Richard and me re-joined. * we were asked to review these proposals: #405: Split RecordDotSyntax, Shepherd: Simon PJ #403: lexical structure of numbers and identifiers, Shepherd: Arnaud #400: Constrained COMPLETE sets, Shepherd: Cale #402: Stable GADT constructor syntax, Shepherd: Richard #378: Support ergonomic dependent types, Shepherd: Simon PJ #283: Local modules, Shepherd: Arnaud #396: Defaulting plugins, Shepherd: Vladislav #371: Stop treating ~ magically, Shepherd: Richard #409: Exportable named defaults, Shepherd: Eric * we have a recommendation from the shepherd about: #390: Fine-grained pragmas, recommendation: accept #405: Split RecordDotSyntax, rec: accept #403: Cleanup lexical structure, recommendation: accept #367: Clarify primops using unboxed sums, rec: reject #402: Changes to GADT syntax; rec: accept #378: support the design for dependent types, rec: accept #371: Stop treating ~ magically. rec: weak accept * we have sent the following proposals back to revision #381: Visible 'forall' in types of terms #302: \of #390: Fine-grained pragmas * we decided about the following proposals #369: Add sumToTag# (accept) #403: Cleanup lexical structure (accept) #367: Clarify primops using unboxed sums (reject) #405: Split RecordDotSyntax (accept) #403: Cleanup lexical structure (accept) We currently have to act on the following 6 proposals, up by 1. ## Waiting for committee decision #402: Stable GADT constructor syntax, Shepherd: Richard Recommendation is to accept. There is some ongoing discussion if extra parents should be continued to be allowed. #371: Stop treating ~ magically, Shepherd: Richard Recommendation is to accept. Some ongoing discussion about whether exporting ~ might be pragmatic choice. #378: Support ergonomic dependent types, Shepherd: Simon PJ Recommendation is to accept, but there are some doubts that this is a proper proposal that should be addressed first. I expect some more soul-searching here. ## Waiting for Shepherd action #283: Local modules, Shepherd: Arnaud Waiting for recommendation. #400: Constrained COMPLETE sets, Shepherd: Cale Waiting for recommendation. #409: Exportable named defaults, Shepherd: Eric Waiting for recommendation. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #371: Exporting ~ from Data.Type.Equality, Shepherd: Richard
by Joachim Breitner 27 Mar '21

27 Mar '21

Dear Committe, Exporting ~ from Data.Type.Equality has been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/371 https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/00… This looks rather small, and Richard has already vetted and refined this, in particular about the migration story, so I think he could just as well shepherd this through. 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

Please review #396: Defaulting plugins, Shepherd: Vladislav
by Joachim Breitner 19 Mar '21

19 Mar '21

Dear Committe, Defaulting Plugins has been proposed by Andrei Barbu https://github.com/ghc-proposals/ghc-proposals/pull/396 https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaulti… I propose Vladislav, as our newest member, to shepherd this. 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

Please review #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
by Joachim Breitner 19 Mar '21

19 Mar '21

Dear Committee, this is your secretary speaking: Clarify primops using unboxed sum has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/367 https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals… I’ll propose Simon Marlow 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/

7 9

Please review #283: Local modules, Shepherd: Arnaud
by Joachim Breitner 17 Mar '21

17 Mar '21

[Corrected message] Dear Committe, Local modules has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/283 https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/00… This is actually a re-submission, so the Shepherd was and still is Arnaud. (Sorry, Vladislav, but you’ll get something to do soon I am sure :-)) 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

Please review #283: Local modules, Shepherd: Vladislav
by Joachim Breitner 17 Mar '21

17 Mar '21

Dear Committe, Local modules has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/283 https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/00… I propose Vladislav, as our newest member, to be the shepherd for this gem. 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