- ghc-steering-committee

Please review #207: type variables in quotations, Shepherd: Richard
by Joachim Breitner 07 Mar '19

07 Mar '19

Dear Committee, this is your secretary speaking: type variables in quotations has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/207 https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-c… I propose Richard as the Shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #209: Levity Polymorphic Lift, Shepherd: Eric Seidel
by Joachim Breitner 27 Feb '19

27 Feb '19

Dear Committee, this is your secretary speaking: Levity polymorphic lift has been proposed by Alec Theiault https://github.com/ghc-proposals/ghc-proposals/pull/209 https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/p… I propose Erid Seidel as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

[Proposal] #193: Make `forall` a keyword in type (recommendation: accept)
by Eric Seidel 14 Feb '19

14 Feb '19

This proposal suggests making `forall` a keyword at the type-level. `forall` is currently only a keyword when `-XExplicitForAll` is enabled. This change would avoid a potentially confusing situation where the meaning of a type can change based on which extensions are enabled. For example, ``` f2 :: forall a -> a -> a ``` with no extensions, the `forall a` would be interpreted as two regular type variables. But if we enable the upcoming "visible dependent quantification" extension (I assume there's an extension involved here somewhere, the proposal doesn't say), the `forall a` would be interpreted as a *single* dependently quantified type variable `a`. The only concerns are that this change could break existing programs, and that it moves us further away from the standard. I'd be very suspicious of any programs that used `forall` as a type variable, as that's just ripe for confusion. And it's a very small step away from the standard, so I don't think that should stand in the proposal's way either. I recommend we accept the proposal.

3 4

Proposal #167 (Deprecated Entities): Request for comments
by Vitaly Bragilevsky 08 Feb '19

08 Feb '19

Dear Committee, I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/000…) It is proposed to extend DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. Simon suggested another alternative to make DEPRECATED pragmas positional (in consistency with the deprecating modules). I like the positional alternative more, as it enables more fine-grained control over deprecated entities and can be extended to deprecating unnamed entities (like type class instances). It seems the author is okay with rewriting the proposal, but the current proposal is already implemented. So, the question is: do we want it quick or good? I am not ready to answer this question and come up with the recommendation on the proposal yet. Please, comment on the following issues: a) which form of the DEPRECATED pragma you prefer, b) do you see any potential drawbacks of the positional form, c) are there any caveats with deprecating instances. Your comments are very welcome either here or on GitHub ( https://github.com/ghc-proposals/ghc-proposals/pull/167) Thanks, Vitaly

6 11

Please review #155: Type Variable in Lambdas, Shepherd: Iavor
by Joachim Breitner 06 Feb '19

06 Feb '19

Dear Committee, this is your secretary speaking: Richard wants to bind Type variables in lambda.: https://github.com/ghc-proposals/ghc-proposals/pull/155 https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000… I propose Iavor Diatchki the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #193: forall keyword, Shepherd: Eric
by Joachim Breitner 05 Feb '19

05 Feb '19

Dear Committee, this is your secretary speaking: make `forall` a keyword proposed by Richard: https://github.com/ghc-proposals/ghc-proposals/pull/193 https://github.com/goldfirere/ghc-proposals/blob/forall-keyword/proposals/0… I propose Eris Seidel as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #203: PtrRep, Shepherd: Simon PJ
by Joachim Breitner 03 Feb '19

03 Feb '19

Dear Committee, this is your secretary speaking: PtrRep has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/203 https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000… I propose Simon PJ as the shepherd (he already glimpsed at it, so hopefully already has an opinion.) Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Status
by Joachim Breitner 27 Jan '19

27 Jan '19

Dear committee, another quiet month. There are a few proposals that are desperately waiting for action from Manuel, Ben and Chris. Here is what happened: * were asked to review these proposals: -none- * got a recommendation from shepherds about: #158 Add setField to HasField (rec: accept) * decided about the following proposals -none- (But new, unsubmitted proposals are on the horizon.) We currently have to act on the following 6 proposals, down one because the Or pattern proposal got withdrawn. liftTyped https://github.com/ghc-proposals/ghc-proposals/pull/175 Shepherd: Ben Status: Acceptance recommended, more discussion happening, it seems. record-set-field proposal https://github.com/ghc-proposals/ghc-proposals/pull/158 Shepherd: Yav Status: Acceptance recommended, discussion about fundeps vs. tf. Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Still waiting for recommendation. Manuel? Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Still waiting for recommendation. This is pretty old! ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Met with some reservation. Chris, please pick this up again. Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: reject Status: Chris, you still need to write the rejection reasons to the ticket. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

2 1

Bundling patterns with type synonyms (#28)
by Christopher Allen 27 Jan '19

27 Jan '19

The proposal I'm reviewing is: Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski https://github.com/ghc-proposals/ghc-proposals/pull/28 Having reviewed the proposal and gone through some of the GHC Trac history, I think we should accept this proposal. There are a couple of open questions, ambiguities, and potential downsides but the overall complexity of the proposal doesn't cause me great concern. Cheers, Chris Allen

5 11

Discussion for #158 "Add `setFild` to `HasField`"
by Iavor Diatchki 23 Jan '19

23 Jan '19

Hello, let's start the discussion on proposal #158. After some discussion on the pull request the proposal was changed, so that instead of adding another method, it now proposes to remove the existing method `getField`, and add a new method `hasField`, which allows to both access and change the value of a field. After the proposal the class would look like this -- `x` is the name of the field, `r` is the type of the record, `a` is the type of the field class HasField x r a | x r -> a where hasField :: r -> (a -> r, a) In addition, we'd provide two functions `getField` and `setField` which are defined in terms of `hasField`. The proposal may break existing code, if it defines manual instances of `HasField`, however, code that just uses the functionality will continue working as before. `HasField` is relatively new, and there aren't many reasons to define custom instances of it, so it is expected that breaking code would not be a big issue. This seems like a reasonably simple change, that adds new functionality, so I recommend that we accept the change. -Iavor

3 6